第6章 04：コードが読めなくても正しいCTOは選べる#
非技術系の創業者を麻痺させる恐怖がある。「技術が分からないから、技術共同創業者を評価できない。」パスポートなしで国境に立たされたような告白だ。
はっきり言おう。CTOを選ぶのにコードを理解する必要はない。PythonとRustの違い、マイクロサービスとモノリスの違い、SQLとNoSQLの違いを知る必要もない。必要なのは、正しい質問と証拠を読み解く力だ。
自分が理解できない領域の人を評価すること。これは技術の問題ではない。判断力の問題だ。そして判断力には方法論がある。
行動検証メソッド#
ほとんどの人は自己評価で他者を評価する。「バックエンド開発のスキルは？」「リーダーシップを10段階で？」「あなたの強みは？」
これは無意味だ。自己評価バイアスの研究（Dunning-Kruger、1999年）が示す通り、誰もが自分を平均以上だと評価する。自己評価は美肌フィルター内蔵の鏡だ——本人が見せたいものだけが映る。
代替手段は行動検証だ。人が何をできるかではなく、何をしたかを聞く。STARフレームワークを使う——Situation（状況）、Task（課題）、Action（行動）、Result（結果）。
状況。 背景は？「チームが技術的な厳しい締め切りに直面した時のことを教えてください。」具体的な情報が必要だ——実際のプロジェクト、実際の会社、実際のタイムライン。曖昧な回答（「よくタイトなデッドラインがありました」）は危険信号だ。実際にやった人は詳細を覚えている。
課題。 本人の具体的な責任は？チームの責任ではなく、個人の責任だ。「あなた個人が何を納品する責任を負っていたか？」これでリーダーと便乗者が分かれる。本当の責任者は自分のスコープを精確に説明する。便乗者は自分の貢献をチームの成果に紛れ込ませる。
行動。 実際に何をしたか？「あなたの行動をステップごとに説明してください。」ここが金脈だ。詳細を追え。「システムのアーキテクチャを設計しました」と言われたら、追加質問：「主要な設計判断は？なぜその方法を選んだ？どんなトレードオフを受け入れた？」本当にやった人は3〜4段階深く掘れる。やっていない人は1段階目で曖昧になるか防御的になる。
結果。 何が起きたか？「成果は？成功をどう測定した？」具体的な結果が重要だ。「システムが10倍のトラフィックを処理した」は有用。「うまくいきました」は無用。そして決定的な追加質問：「もう一度やるなら、何を変える？」結果にオーナーシップを持っていた人はこれを考えている。持っていなかった人は「コミュニケーションの改善」という台本通りの答えを返す。
STARメソッドが有効なのは、行動が将来の行動の最良の予測因子だからだ——学歴でも、自己評価でも、推薦状でもない。特定の状況で、本物のプレッシャーの下で、本物の利害がある中で何をしたか——それがデータだ。
アウトプット検証：信頼しつつ確認する#
行動面接はその人の思考方法を明らかにする。だが実際のアウトプットも検証が必要だ——自分では評価できなくても。
信頼性順に3つのアプローチ：
作品を見る。 作ったものを見せてもらう——オープンソースへの貢献、サイドプロジェクト、リリース済みのプロダクト。コードを理解する必要はない。コードが存在し、具体的な成果物を指し示せることを確認するのだ。公開作品がないCTO候補は自動的に失格ではないが、他の手段で埋めるべきデータギャップだ。
第三者評価を得る。 信頼できる技術者を見つけ、候補者の作品をレビューしてもらう。友人、アドバイザー、2時間分のフィーで雇うコンサルタント。具体的な質問を与える：「このコード/プロダクト/アーキテクチャに基づいて、この人にスタートアップの技術チームを任せられるか？」有能な評価者なら午後の時間で明確なシグナルを出せる。
有償トライアルプロジェクトを実施する。 共同創業者関係にコミットする前に、小さな明確なプロジェクトで一緒に働く——2週間、明確なスコープ、具体的な成果物。これが得られる最高のデータだ。コミュニケーション方法、曖昧さへの対処、トレードオフの判断、実際のアウトプットが全て見える。悪いCTO採用のコストは数ヶ月。2週間のトライアルのコストは2週間だ。
行動面接とアウトプット検証の組み合わせが、理解できない領域でも堅実な判断基盤を与えてくれる。
価値観の整合性チェック#
技術スキルは必要条件だが十分条件ではない。CTOとの関係が崩壊する最も一般的な原因は能力ではない——価値観のミスマッチだ。
致命的なミスアラインメントの3つの次元：
スピード vs. 品質。 あなたは6週間でMVPをリリースしたい。CTOは6ヶ月かかる「ちゃんとした」アーキテクチャを望む。どちらも間違いではないが、スタートアップではスピードがほぼ常に勝つ。CTOが不完全なものを世に出すことに耐えられないなら、誰も来ない大聖堂を建てるためにランウェイを燃やすことになる。
テスト方法：自分が誇れないものをリリースした経験を聞く。思い当たらない場合、あるいは品質を主張した理由の正当化で溢れている場合——慎重に進めよ。
自律 vs. 指示。 明確な仕様と定義されたタスクを求める技術リーダーがいる。問題空間をオーナーとして持ち、自分で解決策を見つけたい人もいる。スタートアップでは後者が必要だ。質問：「問題だけ渡して仕様書がなかったら、何をする？」正しい答えはユーザーと話して判断すること。間違った答えはあなたにドキュメントを求めること。
長期 vs. 短期。 次の四半期に最適化する人と、次の5年に最適化する人がいる。スタートアップには両方を切り替えられる人が必要だ——今日のために作り、明日のために設計する。純粋な短期思考は2年目に殺す技術的負債を生む。純粋な長期思考は1年目に使えるものを何も生まない。どちらかの方向に硬直した哲学があるなら、スタートアップが求める絶え間ないコンテキストスイッチで苦労するだろう。
クロスドメイン評価の落とし穴#
堅実な方法があっても、領域横断的な評価には罠がある。
自信バイアス。 自信のある人は有能に聞こえる。特に自分が理解できない領域では。「スケーラブルな分散システム」や「イベント駆動アーキテクチャ」について権威ある口調で語るCTO候補は、非技術系創業者には天才に聞こえるかもしれない——たとえバズワードを並べているだけでも。対策は常に具体的な詳細を求めること。自信に満ちた一般論は安い。実際のプロジェクトでの実際の判断に関する具体的な詳細——それは偽造が高くつく。
ハロー効果。 履歴書の有名企業が目を眩ませる光を作る。「彼女はGoogleで5年働いた」は、個人的に何を達成したか、スタートアップの混沌にどう対処するか、ゼロから構築できるかについて、ほとんど何も教えてくれない。Googleには18万人の社員がいる。優秀な人もいる。優秀なシステムの中の普通の人もいる。履歴書はどこで働いたかを示すが、何をしたかは示さない。
技術的威圧の罠。 意図的に専門用語を使って情報の非対称性を作る候補者がいる。理解できないことがあれば、平易な言葉で説明するよう求めよ。できない、あるいはしようとしないなら——それはシグナルだ。最高の技術リーダーは複雑な概念をシンプルに説明できる。凡庸な人は複雑さの後ろに隠れる。
「後で勉強する」の罠。 いつか技術を十分に理解してCTOを適切に評価できるようになると自分に言い聞かせる。ならない——頭が悪いからではなく、他に100のことがあるからだ。意思決定をしている今、評価システムを構築せよ。もっと時間があるという架空の未来に検証を先延ばしするな。
チーム監査#
以下はあなたの演習だ——CTOだけでなく、すべての重要なチームメンバーに適用できる。
自分が深く理解していない領域のチームメンバーを1人選ぶ。マーケティング責任者、リードデザイナー、営業部長。加入以来の実績にSTARメソッドを適用する。
最も重要なプロジェクトを取り上げる：
- 状況： 始めた時の背景は？
- 課題： 具体的に何を担当していたか？
- 行動： 個人として何をしたか？（チームが何をしたかではない。）
- 結果： 測定可能な成果は？
行動と主張する能力を比較する。一致しているか？言えることと実際にやったことの間にギャップがあるか？
ミスマッチを発見したら——「リーダーシップ」を語るが行動が「参加」を示す人、「戦略的思考」を主張するが結果が「戦術的実行」を示す人——それはキャリブレーションの問題だ。チームの真の能力について不正確なデータで運営してきたことになる。
すべての重要な役職に対してこれを行う。午後の時間で済む。得られる明晰さは、数週間の推測に値する。
技術チームを率いるのに技術の専門家になる必要はない。マーケティング責任者を評価するのにマーケティングの専門家になる必要はない。必要なのは、実際の行動から実際の証拠を引き出す方法——そして、答えが不快であってもそれを使い続ける規律だ。
方法は存在する。問題は、それを使うか、直感と見栄えの良い履歴書に頼り続けるかだ。
直感には使い道がある。だが、人生で最も重要な採用決定の主要ツールにすべきではない。