スタートアップ CTO ハンドブック
(github.com/ZachGoldberg)スタートアップ CTO ハンドブック
高性能なエンジニアリングチームのための必須スキルとベストプラクティス
はじめに
- 常に学び続けること: 著者は幼い頃からコンピュータとソフトウェアプログラミングに情熱を持っており、それを通じて継続的な学習の重要性を理解した。技術リーダーとして成功するには、絶えず学び、成長し続けることが重要である。
- スタートアップの技術リーダーのジレンマ: ほとんどのスタートアップには技術系の共同創業者がおり、彼らは初期のコードベースを書き、最初のエンジニアを採用する。しかしチームが成長するにつれて、技術リーダーはマネジメントの役割へ移行する必要があり、その過程でリーダーシップスキルが不足している場合がある。
著者紹介
- 著者は複数のスタートアップで経験を積み、技術リーダーとしての役割を担ってきた。さまざまなスタートアップでの経験を通じて、技術リーダーシップに必要な多様なスキルと課題を理解するようになった。
この本の使い方
- この本はソフトウェアエンジニアリングチームを管理するリーダーのための参考書であり、さまざまなトピックを独立した章として扱っている。各章ではテーマを紹介し、概要を提供し、ベストプラクティスを提示する。
ビジネスプロセス
- ビジネスプロセスを説明することで、問題解決の出発点を提供する。チームや会社の規模に応じて、プロセスを調整し拡張する必要がある。
人と文化
マネジメントの基本原則
- マネジメントの黄金律: チームの成果がマネージャーの成果を測る基準である。メンバーがベストを尽くせるよう支援しなければならない。
- 専門スキルツリー: 技術リーダーシップのためには、技術だけでなくマネジメントスキルにも投資する必要がある。
継続的改善
- カイゼン: チームも個人も継続的な改善を追求すべきである。ミスを改善の機会として捉えるべきである。
コーチング
- マネージャーは、メンバーがベストを尽くせるよう支援するコーチの役割を果たすべきである。
マネジメントメンターを見つける
- リーダーシップへの移行のためには、マネジメントメンターを見つけることが重要である。適切なメンターを通じて、リーダーシップスキルを向上させることができる。
1:1 ミーティング
- 1:1 ミーティングはメンバーとの関係を築き、彼らの強みと弱みを把握して、ベストを尽くせるよう支援する機会である。
スキップレベルミーティング
- 定期的にマネージャーの直属の報告先ではないメンバーと面談し、多様な視点を収集することで、ビジネスを改善できる。
マネージャーのためのコーチング
- ミドルマネージャーの成果は組織の成果にとって重要である。継続的な教育と支援を通じてマネージャーを育成すべきである。
エンジニアとの 1:1 ミーティング
- エンジニアとの 1:1 ミーティングは、彼らが直面している問題を聞き、解決策を見つけられるよう支援する機会である。ミーティングの目的を明確にし、生産的な対話を導く必要がある。
1件のコメント
Hacker Newsの意見
こういう文書を見るときは、まず自分が詳しく知っている部分に行って、何と言っているか確認することにしている。ここではPCI DSSやSOC 2監査の準備と実施には通常6〜12カ月かかるので、土壇場で認証を取ろうとするなと言っているが、スタートアップにはほぼ逆の助言をしたい
特にSOC 2の証明は取りやすく、発注書が絡む前から先回りしてお金を使うのは無駄だ。もちろん、シングルサインオンの設定や保護されたGitブランチのように、後で証明の土台になるものは早めにやっておくのがよいが、SOC 2を取る予定がなくてもいずれにせよ行うべき基本的なベストプラクティスに近い。大口顧客が要求していないなら、SOC 2をやる必要はないと思う。この文書の他の部分も誰かに点検してもらえるとよさそうだ
BI用のリードレプリカとそこそこの可視化ツールをつなげればかなり長く持ちこたえられるし、Snowflakeのようなものに5〜6桁の金額を使うまでは十分だ
資金状況によっては、Secureframeのような自動SOC 2準拠チェックリストサービスを使う費用は数千ドル程度で済むことがあり、ベストプラクティスに従わせてくれるだけでなく、SOC 2に合った独特の形で整理してくれるので監査も楽になる。すでに非準拠のプロセスが深く組み込まれた組織をSOC 2の道に乗せるためにかかる開発・プロジェクト管理の時間に比べれば、大きな投資ではない
SOC 2の証明を簡単に取れるという話も、この話題について他の人から聞いたことと真逆だ。普通は非常に難しく時間がかかると聞いていたので、自分が何を見落としているのか気になる。本当に簡単なことなら、自分が間違っていてほしい
VPやCTOになるとコーディングをやめるという話をよく見る。マネジメント能力がコーディング能力ではないことは分かるが、なぜ人々がキーボードを置いて自分の第一のスーパーパワーを無駄にするのか理解しにくい
最初から最後まで技術的なCTOであり続けることはできる。チームと会社を、積極的な貢献、保守、オンコール対応が必要なサービスのように扱い、同時に一人でもチームと一緒でも自ら手を動かして作るべきだ
本当の問題は、キャリアの早い段階でコーディングする時間のない役割に就くことだ。ホワイトボードに箱を描くだけで会議を渡り歩くアーキテクト役や、実質的には管理職なのに「テックリード」と名付けられた役割を受け入れるようなことだ。コードを書かないことに慣れ、数年後に新しい仕事を探さなければならなくなったとき、プログラミングキャリアのかなりの部分をコードを書かずに過ごしたという事実と向き合いながら、コーディング職の面接を受けることになる。多くの人にとって勘はすぐには戻らない
自分の時間は、他の人が解けない問題を解決することに使う方がはるかによかった。たまにごく単純な変更を引き受け、自分たちのプロセスを自分で通ってみて、どこを改善できるか確認することはあった。夜や週末にはコーディングを続けていたが、同じ感覚ではなく、時間が経つと少し錆びつくのは避けられない。それでもサバティカル中に一日中手を動かしてコーディングするのは本当に楽しかった
レビューや設計会議はできるが、中核的な作業を受け持つと結局問題が起きる
VP/CTOが書けるコードは、チームの他の誰かも書けるし、ひょっとするとよりうまく書けるかもしれない。一方で列挙した他の仕事は、社内でVP/CTOが最も得意である可能性が高い。チームと会社にとってより重要な仕事のために、実務的な技術作業をほとんど手放すのはかなり合理的な判断だ
コーディングを続けるという考えは良いが、通常それが報酬を受け取る理由ではない。自分を非常に強い開発者だと思っているが、そういう開発者はCTOの給与より低いコストで雇える。より高価なCTOがその仕事をするのは非効率だ。ちなみに数年後に個人貢献者に戻り、残りのキャリアもそうするつもりだ
同期式チャットというものは存在しないと言いたい
同期式である必要があるなら、チャットウィンドウでやるべきではない。少なくとも「数分間リアルタイムチャットに集中しよう」と合意した場合でない限り。リモートなら電話し、現場なら対面で話すべきだ。チャットにメッセージを投げて即答を期待してはいけない
「2チーム」体制で恨みが生じなかった事例があるのか気になる。人々が自然に未来チームへ移りたがらない場合もあったのだろうか
紙の上では良いアイデアに見えるが、実際にうまく機能するとは信じにくい。私が見た中で最も近い形は、デザインシステムやコンポーネントのようなサービスを作って他のチームに使わせるライブラリチーム程度だった
その責任さえ果たしていれば、残りの時間は会社に価値があると見なされる仕事を自由にできた。かなり良い取引だった。他の人たちは、その小さなチームが汚れ仕事を引き受けてくれることに感謝していたし、保守チームは余った時間でずっと気になっていたことを直したり研究したりできるので喜んでいた。細部は忘れたが、かなり素晴らしい改善や研究成果が出ていた記憶がある。そのチームの人たちが非常に優秀で自律的だったことも成功に役立ったが、コストも余計にかかった
実際に、完全に分かれたチームがうまく機能していた場所をいくつか経験した。ゲームではエンジンチームとゲームチームを考えればよい。以前の役割の一つでは、ゲームチーム内でも6〜12週間かかる機能を担当してリリースした後、保守・アップデート・技術的負債に対応していた。リリースしたばかりのものが主な焦点ではあるが、以前の作業に戻る時間もあり、他のチームも同じ循環にいて、6〜8週間後に新機能にオンボーディングする、という形を繰り返していた
固定チームとして扱わず、人々が毎スプリント、つまり2週間ごとに行き来する作業フローとして扱った。約3カ月はうまく回ったが、その後は合わなくなり、その頃には組織が大きくなって、チームをビジネス能力やドメイン中心に再編した
こういう資料は聖書のように使うためのものではなく、責任と関心事を広く見渡してくれる点が良い
優れた助言者がいるか、本当に優秀な人の下で働いた経験がない限り、この立場になったとき、誰かが隣に座って気にかけるべきことのリストを教えてくれるわけではない。各セクションごとに「私たちの答えは何か？」「同意するか？」「私たちのプロセスの方が優れているか？」「自分が見落としているものは何か？」と問いかけさせてくれるので役に立つ
「2チーム」の分離がここまで明示されているとは。まともなものをリリースするコストが大きくなりすぎるまで、リリースを続けさせる素晴らしい方法だ
最初にソフトウェアを作った人たちへ戻るフィードバックループを断ち切ると、その人たちは一時的により幸せになり、他の人たちは一時的により不幸になる。すると機能チームは二度と邪魔されたくなくなり、顧客チームは何かをきちんと直すためのリソースを受け取れなくなる
さらに悪いのは、機能チームが行を出荷する方法以外、何も学べない点だ。時間が経つほど遅く高くつくようになる理由は、良いソフトウェア開発における唯一の適合度関数、つまり否定的なフィードバックを開発の源泉へ再統合する過程を取り除いてしまったからだ。本物のCTOリーダーシップハンドブックなら、「開発者がリリースしている間にも改善できるよう助けるのはあなたの責任であり、開発者たちが常にそれを好むとは限らない」と明確に言うべきだ
営業が後押しする機能チームと、顧客担当者が後押しする保守チームの間でマージコンフリクトも起きる。「顧客チーム」が後で抜け出す段階のように描かれている以上、どちらが優先順位争いに勝つかは明らかだ。「個々のエンジニア、特にジュニアが学び成長するためのもう一つの道」という言葉は、結局「シニアが尻拭いを嫌がるのでジュニアにやらせる」と聞こえる
こうしたチームは、機能をデプロイしてバグを直す仕事を見下し、問題を過度に抽象化しようとする人たちを引き寄せる傾向がある。バグを直す代わりに、バグが最初から生まれないようにすると言って、ますます複雑な抽象化を作り、結果は目に見えている
顧客、とりわけ非技術系の顧客は、一貫したプロダクトビジョンを持っておらず、他の計画とは関係なく目先の修正だけを求めることが多い。顧客同士がコミュニケーションしていないため、フィードバックが衝突することもある。この負担を開発者に載せると、開発者はコードベースを理解し適切に保守する技術力に加えて、すべてのコミュニケーションまで管理しなければならず、思慮深い判断を下すには、すべての開発者が同じ一貫したビジョンを持っていなければならない。最近のように開発者がインフラまで管理する役割なら、実質的に二つか三つの仕事を一人でやっているようなものだ
人々はこの方式をずっと好んでいたように思う。常にバグばかり直すことに疲弊することもなく、あなたが洞察深く指摘したフィードバックの断絶も避けられたからだ
この時点で何度面接をしてきたか数えきれないほどなので、少し同意しにくい。難しい点の1つは、受付段階では応募者が多すぎる、あるいは多くなり得ること、そしてこの段階では通常、採用チームが応募者とやり取りすることだ
例のような質問を入れるのはよいが、資格のない候補者をふるい落とすには、はい/いいえや尺度型ではない質問が必要だ。私は明確な答えがある、ごく簡単な質問を好む。JavaScriptに「非常に慣れている」と答えておきながら、
===が何かを知らない人が驚くほど多い。だから「JavaScriptの厳密等価演算子は何か」のような質問をする。JavaScriptプログラマーなら誰でも知っているが、この質問1つだけで応募者プールの50%がふるい落とされ、組織の時間を非常に大きく節約してくれるカルチャーフィットの話が多いが、そのかなりの部分は、会社に害を及ぼす隠れた差別の層を引き上げているように見える。文化的な開放性は成功要因であり、差別は逆方向に導くものだと思う
「最高のリーダーは成功率を追跡し、採用ミスを認めることを恐れず、ゆっくり採用して素早く解雇する」という文を見ると、JWZ（Jamie Zawinski）がこのサイトを指すreferrerヘッダーを検知したときに表示する画像を貼りたくなる。Jamie ZawinskiがY Combinatorについて何と言ったか、Googleで探せばよい。彼はNetscape Navigatorをオープンソースとして公開するというNetscapeの決定と、そのブラウザレンダリングエンジンにつながった作業の大部分に功績のある人物でもある。だからFirefoxがある
初期に勤めた会社の1つでは、採用基準からカルチャーフィットと呼べるものをすべて禁止しようとした。その結果、何人かは入社してすぐ会社を嫌いになり、数週間から数か月で辞めていった。ある候補者は計画と予測可能性を重視し、以前の会社は動きが速すぎると不満を述べていた。私たちはスタートアップで、予想どおり彼は会社を嫌った。しかし採用決定の過程でそうした懸念を口にすることはできなかった。「カルチャーフィット」であり、差別につながり得ると見なされたからだ。同じようなことがさらに何度か起きた後、その方針は静かに消え、再びエンジニアリング文化との両立可能性を評価できるようになった
「カルチャーフィット」は概して、コミュニケーション効率と高い信頼を得る代わりに、思考の多様性を一部手放す取引だ。人々はすでにどう振る舞うべきか、互いに何を期待すべきかを知っているので、多くの指針を設ける必要はないが、集団思考や関連する認知バイアスにはより弱くなる。「この船には虹のあらゆる色があるが、われわれクリンゴンでさえクリンゴンは悪だと思っている」という感じだ
「説明動画ライブラリを作れ」という助言が良いのかはよく分からない。UIやアニメーションのような特定のものには筋が通るかもしれない
しかし一般には、テキストを読むことの方が動画を見るより効率的だ。急いでいるときにテキスト内の重要な部分へ移動するのも、動画よりはるかに簡単だ