Startup CTO's Handbook - スタートアップCTOのためのハンドブック
(github.com/ZachGoldberg)- Startup CTO's Handbook の最新の書籍コンテンツを提供しており、本文はMarkdownで閲覧可能
- 書籍は Amazon と Audible で購入可能
- 最新のMarkdown版をPDFとしてレンダリングしたリンクは Coming Soon の状態で、元の原稿は現在古いバージョンとして Google doc に存在
- 追加、変更、提案、批判を今後の版に反映するための Issue とプルリクエストによる貢献を推奨
- ライセンスは、再販せず、著者名と著作権表示を維持し、以後の版を類似または同一のライセンスで公開することを条件に、コピー、改変、再配布を許可
1件のコメント
Hacker Newsのコメント
同意できる点は確かにある。たとえば すべての会議の録画 には賛成する。だが、パフォーマンス管理[0]のような部分には個人的に賛同できない内容も多い
これは必ずしも批判というより、問題領域ごとにアプローチやリーダーシップのスタイルが異なりうる、という意味だ。このガイドを不可侵のものとして受け取らないでほしい。ここに書かれていることが自分の経験と合わないなら、自分の経験をより信頼することを勧める
[0] https://twitter.com/bcantrill/status/1216491216356823040
CTOとして、その依頼をどうやって強圧的にならずにできるのかと思う
ただ、現実には本当のスキルギャップがあることも多く、マネージャーがコーチ役を担えば、誰かの成長と成果をより早められるとも思う
相手側は、今後どうやって成果を改善するかという 前向きなパフォーマンス管理 を語っている。しかし大半の会社での業績評価は、報酬や昇進の配分プロセスの中で過去の成果を順位付けする 後ろ向きの評価 に近い
前向きなプロセスは素晴らしいが、結局のところ、ある程度の過去実績の評価も必要になる
著者とは2社で一緒に働く機会があったが、ここに書かれていることが実際に実装されたとき、どれほど大きな違いを生むかは言葉では尽くしがたい
その影響はプロダクトやエンジニアリングの中だけにとどまらず、組織全体に広がる。どんな仕組みや推奨事項でも最終的には自分たちの組織に合わせて変える必要はあるが、Zachが教えるやり方 はできるだけ多く取り入れてみることを勧める
会議の録画は好きなほうだ。チームが責任のなすりつけ合いを始めたときの証拠に使いたいからではなく、会議や議論を見返せるのが本当に良い
重要な議論やアラインメントの会議で、自分の能力をかなり使わなければならない状況だと、話題に集中しながら同時にメモを取り、すべてを覚えるのは難しい。録画があると分かっていれば、会議中は集中し、良い質問をし、前提を検証することに完全に使える
翌日に通話を聞き直しながら一時停止したり、2倍速・3倍速で聞いたり、個人メモを作ったり、議事録や社内向け要約を書いたり、考えの不一致を見つけたり、自分の都合に合わせて AIノート作成ツール を回したりできる
誰かが病気だったり、義母を空港に迎えに行かなければならなかったり、同時に別の会議があったり、重要なアラインメント会議の1週間後に参加した場合にも役立つ。重要でない会議なら無視すればいいだけだし、妥当な自動削除ルールを設ければそれで済む
実際に、人が入るべきでない場所をこっそり漁ることに時間を使うとは思わないので、それは大きな問題ではないと思う
チーム会議は、話すことに自信のある人のほうへ会話を傾けがちでもある。新しく参加した人や、主言語が異なる人には特に不利だ
会議そのものに反対しているわけではない。文章より音声でのコミュニケーションをずっと好む人もいるし、良いチームなら各メンバーが好む働き方を受け入れられるべきだ
しかし、重要で、なおかつ参加者の能力を大きく要求するチーム会議なら、それは会議であるべきではない。すべての参加者が、その特定の会話において会議が最善の媒体だと判断したときにだけ会議を開くべきだ
会議はホースの前に座っているようなもので、細部は取りこぼしてしまう
会議の録画と検索が簡単なので Google Workspace に移行した。たとえばカレンダーイベントの中に録画が組み込まれている
録画するほど重要でない会議なら、おそらく開く価値すらない会議だった可能性が高い
個人的には他の人より1日に長く働いているが、それは動機づけによるものではない。重要な会議が重なることもあるし、議事録だけでは多くのニュアンスが失われる。しかも人は議事録もあまり読まない
それでも会議を録画しておけば、議事録をすばやく正確に確認できるのでとても有用だ。だから会議の録画をかなり強く推している
実際の原因を早く理解するほど、問題も早く直せる。この考え方と会社への適用方法を理解するには、元Navy SEALのJocko WillinkとLeif BabinによるExtreme Ownershipを強く勧める
非同期での会議参加は、上で述べた理由から素晴らしい。会議内の情報を検索可能にしてくれる。今では会議に自然言語処理で字幕を付けることができ、その内容はLLMが見つけられるようになる
現在、社内チャットボットをConfluenceのコンテンツで学習させており、録画された会議コンテンツにまで拡張しようとしている
少し宣伝すると、複数ソースからの入力を洞察やタスクに変えるツール https://designpro.ai を作っている。通話の文字起こしから洞察を抽出するのに使ってみたが、実際に機能することは分かっている
最近CTOになったが、最大の難しさの一つはCEOとのコミュニケーションだ。本で扱われている内容かもしれないが、索引しか読んでいない。
この8か月のあいだ、CEOはアラインメントのための会議を望まず、何も計画したがらず、ビジョンを主導しようともせず、キラー機能にしか集中しようとしない。
ユーザーにテストしてもらうためのモックアップやプロトタイプを作るのも嫌がり、作るなら美しくなければならないと言う。1週間以上かかる仕事はやりたがらず、効果的な会議も拒んだ。
私が言いたいのは、本に載っていないことこそ、まさに私が知りたいことだという点だ。ちなみに、私たちは共同創業者3人だけだ
CTOはCEOの「技術担当者」であり、その中で最も優秀か重要な技術担当者だからCTOという肩書きを与えられていた、というのに近かった。
聞くのはつらいだろうが、CEOがあなたを、立派な肩書きを持った別の従業員くらいに見ている可能性を考える必要がある。そういう考え方なら、CEOの立場では自分の意思決定にあなたを含めるのは無駄だと感じるだろう
Marcの答えはいまでも正確に覚えている。「疑いがあるなら、疑うまでもない」
こんな大きな決断がネット上のたった一つのコメントで左右されるはずがないのは分かっているが、それでも言うと、もう8か月が過ぎている。たぶん、直そうとして試せることはもう全部試したはずだ。
まだ試していないことは何が残っているのか。論理的に見て、ここで何が起こることを期待しているのか。もっと生産的な場所へ簡単に移れるのなら、この状況に人生をあとどれだけ投じるつもりなのか考えるべきだ
真面目な話、いまぶつかっていることこそが、この仕事を難しくしているポイントだ。
第一に、ほかの役員たちと1:1を設定してみるといい。CEO以外に一緒に働く役員がいるなら、いま自分がどんな状況に入ったのかについて、より多くの文脈を得られる。彼らのニーズを把握すれば、より広い組織のニーズも見えてくる。
あなたは、CEOに頼まれなくてもCEOの問題を取り除くために雇われたのだ。経営陣に溶け込む力は、実力を示す最良の方法の一つであり、必要なのは一貫性、誠実さ、オープンさ、そして本当に役立つ質問をしようとする姿勢だ。
第二に、CEOと経営陣が定期的に会っているなら参加を求め、なければ自分で計画してみるといい。理想的には、CEO以外の役員たちと先に足並みをそろえてからがよい。たとえCEOがすべての会議、あるいはほとんどの会議に来られなくても、その主導権は感謝され、信頼も築かれるだろう。
すでにそういう会議は望まないと言っているのだから、CEOに影響力のある別の役員を通じて、まず間接的に動く必要があるかもしれない。
第三に、CTOであるなら、CEOも少なくともあなたが辞めないか確認するためだけでも、ある程度定期的な1:1を望む可能性が高い。毎週、隔週、毎月など、CEOの予定に合う頻度を見つければよい。
この会議の目的は、CEOと足並みをそろえ、自分がうまくやれている領域と改善すべき領域についてフィードバックを得ることだ。これを設定できないなら、成功できる環境ではないと見なし、辞めることを勧める。
この会議を設定するのが難しいなら、まずは前の二つのアプローチを押し進めて関係を築いてから試すのがいい。どんな頻度であれ、CEOやほかの役員たちと定期的な時間をまったく確保できないなら、あなたは実際にはCTOではなく、去ることを検討すべきだ
その違いについてはここに書いたことがある: https://www.mooreds.com/wordpress/archives/2555
ただし、計画の欠如とビジョン推進の欠如は心配だ。どちらも初期段階のCEOの役割の中核だからだ。なぜそんなに短期的なことにしか集中しないのか分かっているだろうか。資金調達や販売のためにMVPを急いで進めようとしているのか、それともビジョンがないのか。その点を掘り下げて理由を理解しようとすると思う。あるいは、ほかの人たちが言うように辞めるのも一つの方法だ
必要不可欠な短期ステップを整理して、CEOが「そうだ、それでいこう」と言う段階まで行ったのか？
それとも、SOC2認証を進めようとするとCEOが「まだその段階じゃない」と言いながら、営業ピッチでは「私たちはSOC2認証に向けて進んでいます」と言うような、あの素晴らしい段階なのか？
心配しなくていい。支離滅裂なのはあなたではない
WikipediaではDevOpsをソフトウェア開発とIT運用を組み合わせた実践手法だと説明しているが、これを「開発者マシン以外の場所でビジネスソフトウェアが動くことを保証するあらゆる仕事」と訳したのは、元の定義とは少し奇妙にずれた解釈に見える。
特にDevOpsの専門家という部分がそうだ
それがよりよく伝わるように書き直してみる
ここに出てくる会社や人を一人も知らない。ほかの人たちは知っているのか気になる。
読むのに時間を使う前に言うと、そもそも「最高技術責任者」という人たちに本能的な疑いがある。読む価値はあるのだろうか？
想定読者は、専門的な経験がほとんどない、あるいはまったくない状態で、スタートアップの技術系共同創業者としてCTOの肩書きを引き継いだ人たちのように見える
この10年で3社でCTOを務めてきたし、今は年を取って忍耐力が減っただけなのかもしれないが、ほかの人たちが言うように、共同創業者としてそのままCTOになった新卒の人向けの本により近く見える。そういう人たちに技術顧問をしている。
私の経験では、この役割を長くやるほど、Accelerateのような本にある、もっと具体的な情報を求めるようになる
枯れた技術は本当に重要だ。民間部門のスタートアップはそれ自体すでに不安定な存在なのに、未検証の技術でなぜさらにリスクを増やすのか。
たとえば2013年から2016年のあいだ、MongoDBが説明しがたい形で事実上の標準データベースのようになっていた時期があった。スタートアップの3分の1くらいがMySQLやPostgresからMongoDBへ移ったように見えた。本当に完全な大混乱であり、愚かな災厄だった
そういう場合にMongoを選ぶ理由は想像しにくい。スキーマを作って更新しなくてよいので、開発初期の数日が少し速くなるくらいしかない。
問題は、データが複雑になってBIのようなものが必要になった瞬間、その初期の利点を莫大な利子付きで返済することになる点だ。
いずれにせよ、たとえデータがリレーショナルでなくても、PostgresのJSONのほうがMongoよりうまく機能する
消えていく新技術もあれば、残る技術もある。
私のキャリアの初期にはSQLがきらびやかな新技術だった。会社はネットワークデータベースを捨ててSQLに移るべきだと強く主張し、結果は非常に良かった。
従来のCに対するオブジェクト指向プログラミングも同じだった。
ある技術は結局、約束されたほどには伸びず、それを採用した組織の足かせになる。
LLM技術を責任ある形で導入するには早すぎた時期もあった。しかし、まもなく取締役会が、なぜ導入しなかったのかと尋ねる時期が来るだろう。外部向けユースケースはともかく、内部向けユースケースでは確実にそうなり得る。
CTOの難しい課題の一つは、新技術を導入するタイミング を見極めることだ。いつ枯れた技術が会社にとって最善なのか、いつなら初期段階の技術を持ち込んでもよいのか、そしていつ新技術があまりに大きな加速装置となって必ず導入すべきなのかを判断しなければならない
CTOを技術志向、人志向、外部志向の3タイプに分けたのが興味深い。
ごく初期段階のスタートアップがCTOの役割を提案している。まだ製品はなく、基本的なデモがいくつかあるだけで、プレシード投資を準備している状況だ。
この役割で最も必要なのは何だろうか。技術CTOか、人を重視するCTOか。最初は製品を開発しなければならないので、主に技術的な役割になりそうだ。だが、いつ頃から人中心のCTOへ移行するのか気になる。関連する洞察や経験があれば聞いてみたい
基本的にはその役割を担い、残りは何とか支えつつ、その仕事が多すぎるか重要になりすぎたら、ほかの二つ以上の領域を担える人を採用すればいい。
さらに答えにくい第二の問いは、彼ら、つまり他のCXOたちが、あなたに何になってほしいと思っているのかということだ。これが第一の問いを妨げることがある。場合によっては、CのないCTO、つまりやるべきことを指示され、見栄えのするデモを回し、ビジネスの「なぜ」を聞かされない技術担当者にすぎない。
「CTOとはいったい何か」について、ブックマークしているリンクがいくつかある。
http://www.startuplessonslearned.com/2008/09/what-does-start...
https://www.allthingsdistributed.com/2007/07/the_different_c...
Camille Fournierの The Manager’s Path も勧めたい
「負債を先回りして返済することは、全体的なエンジニアリングの健全性に必要な投資だ」とあったが、ある種の 技術的負債 は返すよりも債務不履行にしたほうが、全体として安くつくこともある。
プロダクトマネージャーが取り立てに来ない限りは
ただし、ある程度の規模と複雑さを持つプロジェクトが技術的破産に至るのは、この本の助言に従わなかった場合だけだ。機能を出荷するために技術的負債を無視すれば、リリースはますます難しくなり、バグもますます増えていく
本の出版おめでとう。
小さなスタートアップのCTOと上場企業のVPoEとしての経験をもとに、実践的なアイデアを共有しようと Opinionated Launch(https://opinionatedlaunch.com) を書いている。
書き始めてみると、テーマが二つに分かれることに気づいた。管理・チーム・人の側面と、技術の側面だ。私はより情熱のある 技術の側 に集中するようになったので、誰かが残りの部分を担ってくれるのはうれしい