全員テックリードのエンジニアリング組織

公開:2021/02/05
更新:2021/02/05
2 min読了の目安(約2200字IDEAアイデア記事

こんにちは。ソフトウェアエンジニアの@kitasukeです。

今回は、10Xのエンジニアリング組織で実践してる「状況に応じて何でもやる」というテックリードのような働き方で、どうやってスループットを最大化しているかを紹介します。

こちらのミートアップレポートでもその点について少し触れているので、興味のある方はこちらもご覧ください。

https://10x.co.jp/articles/posts/?id=2020-10-02

前提

このアプローチはスタートアップのサイズを大前提としています。10Xは現在エンジニアが11人居て、エンジニアのレベルは全員がシニアソフトウェアエンジニア相当です。また、既存事業と並行して新規事業で新しいプロダクトを作る環境もあり、1つの大きなプロダクトだけを作る環境で適用できるかは不明です。

役割分担による問題

一般的なプロダクトチームの構成は、PM、BI、デザイナー、エンジニア(バックエンド・フロントエンド)、QA等のメンバーが居て、それぞれが役割を持っています。メンバーが個々の役割を専門知識など活かして全うして、部分最適の集合体としてチーム全体の最適化を図る方法です。この方法は成熟したプロダクトを作る場合は効果的に働きますが、一方でまだ小さなプロダクトを作る場合にはいくつか問題があります。

仕様の不一致

一番大きな問題は、チーム内で解決したい課題に対する目的や手段が不一致になる場合があります。その要因は主に下記の通り2つあります。

仕様が正確に伝わらない

大体の場合、解決したい課題は複雑なので背景や仕様も複雑になりがちです。それを分かりやすくチーム内で伝えるのは簡単ではありません。また実装の順番はバックエンド→フロントエンド→QAとなるので、伝わる情報の量や内容がずれる場合もあります。

実装の繰り返し

特にUI/UXに当てはまりますが、仕様の漏れや改善点は実装した機能を体験してみて初めて気づくこともあります。その場合は、一旦PMと仕様について相談して再度実装し直すことになります。
そのやり取りの往復が多いほど時間もかかるし、不要な実装に繋がることもあります。

チーム内の依存度

もう一つの問題は、チーム内で細かく役割が決まっているのでお互いが依存し合っていることです。他のメンバーの作業を待つことになるので、仕様が決まってもすぐに実装できない場合があります。また何らかの事情で一人でも欠けると、最悪の場合は作業が止まり進まなくなります。その際には他のチームメンバーにリソース調整をお願いするコストもかかります。

上記の解決策

仕様の不一致を避けるために仕様から実装まで横断的に見れるテックリード制を導入したり、チーム内の依存度を避けるためにメンバーの適切な配置や育成ができるエンジニアリングマネージャーの導入が良い方法だと思います。もちろん上記のような役割・役職のエンジニアが居なくても、自発的にそういう動きができれば問題ないこともあります。

10Xでの解決策

10Xでは上記に対する解決策として、全員のエンジニアがテックリードのように状況に応じて何でもやるという働き方を推奨しています。

状況に応じて何でもやる

状況に応じて何でもやるとは自分の役割・領域を超えた働きをするという意味で使っています。
例えば10Xだと、エンジニアがバックエンド・フロントエンド共に実装したり、エンジニアがPMの代わりに要件定義したり、エンジニアがBizDevと一緒にパートナーにプロダクトを持っていき議論したり、各々の強みを活かした様々な形態があります。

10Xにはプロダクト責任者が居て大きな方向性は決まっていますが現時点でPMは居ないので、エンジニアがその代わりを何らかの形で担っています。したがって、何をどう作るかを全て自分で考えられるので仕様の不一致が起きませんし、1人で大体のことを担当するので他のメンバーに依存することも少ないです。慣れない分野の内容も担当することになるのでチームで開発するより局所的に見ると時間が余計かかりますが、全体的に見ると案外この方法の方が時間がかからないという印象です。また全員のエンジニアが並列でこの動き方ができるので、エンジニアリングチームとしてのスループットも高いと思います。

注意点

例えば、インフラやプラットフォームごとのパフォーマンスチューニングなど高い専門性が必要になる分野は上記の方法では解決できません。10Xでは新規事業の方が多くたまたま必要性がそこまで高くなかっただけで、近いうちに必要性が一気に高くなります。テックリードとは別にアーキテクトを採用して対応するのが良いと思っています。

まとめ

スタートアップのように小さな実験を積み重ねてプロダクトを改善する場合は、浅く広く動ける方が総合的に効率良さそうだと思います。また仕様と実装の担当が同じだと目的と手段が上手く一致して、より良いプロダクト作りに繋がると思います。この方法は実際にやってみて思ったより効果が高いと感じたので非常におすすめです。