ちゃんとしたシードステージのスタートアップでは、エンジニアは業務経験を「夢中だ」と表現する。大きな会社では、得られるのは最良のケースでも「楽しい」程度だ。どうしてこうなってしまうのだろう。これは避けられないのだろうか。
スタートアップを夢中になれるものにするのは何なのかを調べてみよう。エンジニアはその時間のほとんどをこのループの中で過ごすはずだ。
- 必要ならユーザと話し、ユーザの問題を見つけ出す。
- 作るべきもののアイディアを思い付く。
- 必要なら同僚とそのアイディアについて議論する。
- アイディアを実装する。
- 成功を祈りつつリリースする。お祝いするか振り返りする。それからステップ1に戻る。
10人以下の段階なら、各ステップは「楽しい」ものになり得る。
- 興味のあるユーザに直接連絡し、彼らとビールを飲んでしまえる。
- 思いついたアイディアが会社にとってもあなたにとっても価値のあるものなら、それに取り掛かるためにそれ以外のものは全て放っておける。
- そのアイディアについてほとんどすべての同僚があなたと議論するのに興味を持つ。なぜなら
- 彼らは深くコミットしている。あなたのアイディアがいいなら、あなたがそれを引き受けるよう勧めることが彼らの利益になる。あなたのアイディアが良くないなら、何が良くないのか説明することが彼らの利益になる。彼らはユーザとしても関心を持ってくれる。
- 彼らはあなたと一緒にそのアイディアに取り組みたいと思うだろう。
- 全員がコードベースの大部分をよく知っているので、彼らは役立つ考えを提供してくれる可能性が高い。
- 実装が早い。
- 使いたいツールなら何でも使える。セキュリティレビューはない。
- コードベースが小さい。すべてのことを頭の中に入れておけるので、広範囲にわたるリファクタリングを気持ちよくできる。ホットリロードが高速なので、トライアンドエラーのデバッグをすぐできる。
- 変更のマージが早い。CIには遅いテストは存在しない。安全な変更のためにPRレビューにブロックされる必要がない。masterにプッシュしてしまうことすらできるかもしれない。安全でない変更に対しては、PRレビューをお願いするのに同僚の肩を叩けばよい。
- それほど多くのユーザがいないなら、バックエンドやデータベースの破壊的変更を素早くやるのにダウンタイムも許されるだろう。
- 何でもできる！そのアイディアで株がいくらかの価値になるかもしれない。今後何年にもわたってその機能上に何かを作っていくかもしれない。歴史の本でビジョナリーとして取り上げられるかもしれない。ユーザとのパーティに参加してユーザから「このアイディアを思いついたのはあなたですか？何てこった、これこそ私を救ってくれたんです」と言われるかもしれない。チーム内の全員が深くコミットしているので、彼らはみんなあなたを応援してくれている。みんなの鼓動が同期している状態だ。
会社が大きくなるにつれて、この楽しみはステップごとに減らされていく。100人を超える段階では、ループはこんな感じになる。
- ユーザと話すのはプロダクトマネージャのためだ、バカらしい！あなたは自分の得意なことにこだわる。良くてユーザインサイトの概要と、それに基づいた合理的タスクの優先度順リストが得られるくらいだ。最悪の場合、ユーザの誤解とマネージャの自分勝手なビジョンに基づいた混乱を招くタスクリストが存在し、各タスクがなぜ重要なのか誰も説明できないということもあり得る。
- やりたいことにただ取り組むということはできない。調整はO(N^2)のコミュニケーションの混乱を招くだろう。マネージャは、他に進行中のことを考慮に入れて設計したあなた向けの計画を持っている。それら全てを終わらせた後なら自分のアイディアに取り掛かれるかもしれない。あるいは空き時間に秘密のうちにならそれらに取り組めるかもしれない。
- 自分のアイディアについて同僚と話すことはできるが、彼らはあまり興味を持ってはくれないだろう。あなたの成功から彼らは得るものが少ないのだ。実際には、昇進をあなたと争うこともあり得る。彼らには長いタスクリストがある。彼らには、やるべきことをせずにあなたと働く自由はない。そして彼らはあなたが触ろうとしているコードについて多くは覚えていない可能性が高い。
- 実装が遅い。
- すべてのツールはすでに決定されている。もっと良い新しいツールが使えるかもしれないが、一貫性を崩して導入するまでの価値はない。「あえて」一貫性を崩してはいけない。何か新しいものを使いたいなら、マネージャに聞いてセキュリティレビューチームにメールを送ろう。
- 主にレガシーな理由によりコードベースが大きい。触るのが怖いコードがたくさんあり、誰ももはや理解していないコードがたくさんある。完全なテストが、何も壊していないという自信を持つための唯一の源泉だ。たくさんのトライアンドエラーのデバッグに依存する必要があるが、コードのコンパイルにしばらくかかるが故に、それぞれのトライアンドエラーのループは遅い。
- 小さなPRが取り込まれるのに2週間かかる。CIが成功するのに20分待ち、不安定で、テストを再実行する。レビュアからのフィードバックを待つ間にマージコンフリクトが積み重なっていく。レビュアーは十分なコンテキスト知識がなく、重要な提案をするインセンティブがないので、細かいことを指摘してくるだけだ。要求された変更を加え、変更をプッシュし、20分待つ。PRごとに3回繰り返す。
- あらゆるインフラへの変更は、1000万ユーザに影響するダウンタイムやデータロスを避けるため、14ステップのプロセスから構成される。
- 3ヶ月の静かな苦労の末、何かをリリースする。金曜日のミーティングでそれをデモするチャンス、すなわちあなたが取り組んだことをCEOに見せるチャンスを得られる。本当に注意を払うのはごく少数の同僚だけだ。あなたのやったことは、社員のほとんどには何の関係もない。何人かは成功をほめてくれるだろう。マネージャは、これは次の5ヶ月の評価期間において大きな成果だと言う。最も良いケースで20%の給与増と肩書きの変更が得られる。最悪の場合、4ヶ月の間に組織変更があり、新しいマネージャがきて、やっていたプロジェクトの優先順位が下がるかなかったことになる。この会社であなたがやったことに関して、新しいマネージャを納得させる必要がある。
これは予防できるだろうか？私はそうは思わない。
注意深く見たなら、これらの問題はすべて基本的には次のことから発生していることが分かる。
- コミットの低下、それが引き起こすチームの団結の弱体化。
- N^2倍のコミュニケーション、それによるマネージャと専門化の必要性、さらにそれによる個人の力と学びの幅の狭小化。
- リスク許容性の低下、それによるあらゆるスピードの低下。
1と2は、より多くの従業員を抱えることによる避けられない結果だ。3はより多くのユーザを抱えること、そして一部は政府の規制による避けられない結果だ。
しかし、この楽しさの死を遅らせるためにできることはある。1つは、それを加速しないことだ。多くのスタートアップは、通常はやり方をそのまま持ってこられるマネージャを大企業から引き抜くことで、巨大企業のプロセスをコピーすることによる企業化を不必要に加速している。例えば、多くのスタートアップは大企業がJiraを使っていると言う理由でJiraを使う。Jiraは使ってはいけない。Y Combinatorは創造性が逆の方向に向かうよう世界に気づいてもらおうとしている。つまり、大企業がスタートアップのように運営されるべきであると言うことだ。
大企業のやり方が大企業向けであると言うだけではなく、それは時代遅れでもある。あなたのスタートアップが大きくなるまでには、組織拡大の問題に対するより良い解決法が存在しているはずだ。従って、組織拡大の痛みを経験する時には、第一原理からそれを解決しようとするか、同じサイズにも関わらずより早く進んでいる他のスタートアップからインスピレーションを得ようとするべきだ。
あなたの会社を、独立したスタートアップの集まりのような組織にしよう。実際のところあなたのできる限りそうすべきだ。Ripplingのような会社はそれをある程度実現している。しかし、あなたのプロダクトのコンポーネントは密結合されすぎていて、かつほとんどのコンポーネントはそれだけでは収益を産まないので、これは通常はそううまくは行かない。
インセンティブを賢く設計することで1は意味がある程度に遅らせることができる。これについては別のブログ記事で深掘りするつもりだ。しかしインセンティブがないことは、大量の株とバリューへの影響の力の組み合わせと同じくらい良いことだ。
さらに言えば、一番確実なのは採用を抑えることだ。間違ったマネージャへのインセンティブと、急成長する他のスタートアップのようになるよう迫る無知な投資家と、従業員1人あたりの本当のコストを理解していないことから、ほとんどの会社は早く採用しすぎていると私は考えている。ツール(特にAI関連)が良くなるにつれて、小さなチーム1つがサポートできるユーザの数は増えていく。未来の起業家たちは拡大の痛みをそれほど心配する必要はないかもしれないし、仕事は誰にとっても楽しいものになるかもしれない。
