プロダクトや機能をゼロから最初に作るエンジニアは、その作ったものを改善するフェーズにおいてまるで魔法がかかったように凄まじいパフォーマンスを発揮できます。
今回はその話について書きます。
10xという名のバフ魔法
プロダクトを立ち上げた凄腕エンジニアが開発において凄まじいパフォーマンスを発揮しているのを見たことがある人もいるかもしれません。
その凄腕エンジニアは他の人が1時間かかって直すバグをわずか5分程度で直します。
機能改修も他の人が1週間かかるものをわずか半日で実装してしまいます。
その人に開発を任せると、他の人の10倍の速さで開発が完了する。まさに10xです。
プログラマの格言でも『チーム内の良いプログラマと悪いプログラマの差の差は10倍ある（100倍と言う人もいます）』というものがあるので、実際にそういう状況は様々な現場で起きているのでしょう。
その10倍の差は本当にすべて実力差？
プロダクトを立ち上げるほどの実力があるのは間違いなく優秀なエンジニアです。
しかし他のエンジニアと10倍も差があるというケースは流石に稀でしょう。
プロダクトを立ち上げるエンジニアは仕様検討も設計も実装もすべて自分でやります。
それだけでなくシステムの基盤となるアーキテクチャも作り、変数命名やクラスの責務などについても、自分の一貫した思想を元に作り上げていきます。
基本的にプログラマーは既存のプログラムを修正する場合、仕様・設計・実装の調査にほとんどの時間を使うと言われています。
またいざ自身で実装し始めるときにも、「どういう変数名にするか」「どういう単位でファイル分割するか」「どのパッケージにファイル配置するか」「この処理を実現する便利な関数・コンポーネントはないのか」…等々のことを調べながら実装する必要があります。
10xの魔法はこれらの調査時間をゼロにしてくれます。
なぜなら自分で考えた仕様・設計・実装なので、調査する必要がないからです。
つまり実力差ではなく知識差によって大きな生産性の差が生まれているということになります。
（注：チーム全体のパフォーマンスを劇的に良くする仕組みが作れる能力を10xと呼ぶこともあり、その場合に関しては知識差ではなく実力差が大きな要素となります。ただしこの記事では通常業務でのパフォーマンスのみに限った話をします。）
10xの魔法を最大限に活かすべき
実力差ではなく知識差で10倍の差が生まれているならその知識差は埋めるべきではないかと思うかもしれませんが、ちょっとお待ちください。
知識差を埋めても全員が10xになるわけではなく、全員が2x~3x程度にしかならないのです。
そうなると有名な『人月の神話』でも語られている通り、エンジニア複数人で共同作業する際に生産性は単純な足し算にはならないので、むしろ10xのエンジニアが1人で頑張るほうが短中期的にはパフォーマンスが圧倒的に高いです。
知識差を埋めても皆10xにならないのはなぜでしょう？
それは10xの魔法は民主的なプロセスによって失われてしまうからです。
知識差を埋めるということは単に情報を伝えるというだけの話でなく、歴史的な背景であったり思想であったり、仕様やコードのコンテキストを伝える必要があります。
そして知識差を埋め続けるために、仕様や設計について皆で議論したり、設計レビュー・コードレビューを行ったりと様々な議論・合意形成プロセスが必要になります。
そのプロセスの中でチームメンバーの共通認識が醸成され、属人性が低くなっていきます。
これらの議論・合意形成プロセスは一般的な企業において当然のように採用されています。
この方式のメリットは属人性が低くなることと、仕様・設計の質が高くなることです。
その一方で10xエンジニアが1人で実装していた時代にあった利点が失われてしまう問題があります。
その利点とはビジョンと機動性の高さです。
起業において創業者の思想・ビジョンが大事なのと同様、最初にプロダクトを作ったエンジニアの思想・ビジョンは大事です。
10xエンジニアは一貫性を持った思想・ビジョンを元にシステムをゼロから作り、ピボット（急激な方針転換）を頻繁に繰り返しながらそれをブラッシュアップしていきます。
複数人で開発しはじめると、民主的な合意形成が必要なため急激な方針転換ができなくなり、また『どういうコードにしていきたいのか』というビジョンが浸透するよう情報共有し続けるのに非常に労力がかかり、その結果生産性がかなり低くなってしまいます。
そういった理由で私は1人目のエンジニアが10xの状態で働いていることはむしろ歓迎すべき状況だと思っています。
実際私が今所属しているスタートアップでも、最初半年は私1人で開発し、その後1年間3人で開発し、その後1年間4人で開発しました。
そしてその後PMF（プロダクト・マーケット・フィット。つまり売れ始めた）したので、エンジニア組織を拡大することにしましたが、PMF前のフェーズでの少数精鋭での開発は大人数組織では決して出せないレベルで生産性が高かったです。
少数精鋭だと、各エンジニアが1人で機能開発を仕様検討から設計・開発まですべて行うことになるため（それがスタートアップの魅力です）、必然的にその機能における10xエンジニアになります。属人性は高いですが、個人のクリエイティビティを存分に発揮できるため、かなり高い生産性になります。
こういった理由から10xの魔法は立ち上げ期には、積極的に活用していくべきだと私は考えています。
2人目・3人目のエンジニアに求められるもの
プロダクトや機能の立ち上げに関わる2人目・3人目のエンジニアもまた違った高度なスキルが求められます。
2人目の人は1人目の人のビジョンを理解し、そのビジョンに沿って既存コードを改善し機能拡張していく必要があります。
既存コードの設計思想を読み解き理解する読解力や、その設計思想に沿って実装拡張する力が必要になります。
3人目の人は1人目・2人目の人により作られたものに対し、属人性が低くなるよう改善をしていく必要があります。
初めてそのコードを見る人でもわかりやすいようにリファクタしたりドキュメントを整備するなど様々な工夫をしていく必要があります。
10xの魔法が解けるとき
ここまで10xの状態で開発することの良さについて書いてきましたが、事業としてサステナブルなものにするためには、属人性を排除しチーム全体で開発していかなければいけません。
議論やレビューを通じてチームメンバー全体のスキルや知識レベルを底上げし、プロダクトやソースコードの質を上げていく必要があります。
組織としてスケールするフェーズになった際には、様々な人がコードを触ることになるため、10xエンジニアが活躍する場は残念ながら少なくなり別種のスキル（2人目・3人目としてのスキル）が求められるようになります。
そういったフェーズになった際には、10xエンジニアはこれまでと全く違ったマインドセットが求められることを意識したほうがいいでしょう。
