CTO代行で最初の90日にやること

「CTOが足りない。とりあえず強い人を入れたい。」——採用も業務委託も、最初の期待はここに寄りがちだ。

だが現場で詰まるのは、コードを書く人手ではない。意思決定が止まり、優先順位が毎週変わり、技術負債の話ばかりして事業指標と接続しない状態だ。CTO代行は「優秀なエンジニアを置く」仕事ではない。事業の速度を落とさず、技術判断の質を上げる仕事だ。

参画直後の90日で何を見て、何を止め、何を動かすか。ここを外すと、どれだけ優秀な人材を入れても現場は変わらない。

結論：90日で固定する成果物

時点	やること	成果物
最初の2週間	事実収集（改善提案は後）	現状の事実リスト
30日	優先順位の合意	1枚の優先順位表
60日	小さく速い勝ち	完了見込みの改善2〜3件
90日	次四半期の投資案	守り／攻め／組織の3案以内

「全部直すロードマップ」は90日の成果にしない。合意と実行の型を残す。

現場で見た、最初の90日の分岐

匿名化した一例だ。シリーズA直後のプロダクト組織に、週3日のCTO代行で入った。依頼内容は「技術負債の解消と採用の加速」だった。

最初の2週間で分かった事実は違った。

• リリースは月1未満。障害の事後検証が残っていない
• 優先順位はチャットの温度感で週次に変わる
• 「負債」と呼ばれていたものの半分は、事業KPIに効かない美化要望だった

もし初月にリファクタ一括着手していたら、現場の信頼は得られても四半期の数字は動かなかった。代わりにやったのは、障害Runbookの整備と、リリース承認のボトルネック1箇所の除去だ。60日時点で「変わった」実感が出てから、認証まわりの守り投資を次四半期案に載せた。

依頼文面のまま動くのではなく、事実で依頼を書き換えられるかが分岐点になる。

1. 最初の2週間: 事実だけを集める

最初にやるべきは、改善案の提示ではない。現状の事実を揃えることだ。

• プロダクトの売上・離脱・問い合わせの構造
• リリース頻度、障害履歴、オンコールの実態
• 意思決定がどこで止まっているか
• 誰が何を「決められない」のか

この段階で「技術的負債を全部直す」は禁句だ。事業インパクトの大きい論点だけを残す。経営への最初の報告は、感想ではなく事実の表で行う。

2. 30日目: 優先順位を1枚に落とす

30日目までに、経営・事業・開発の三者で合意できる優先順位表を作る。

観点	問い	例
事業	今四半期で守るべきKPIは何か	解約率、リードタイム
技術	止めると死ぬリスクは何か	認証基盤、決済、データ整合
組織	誰が何を決められるか	設計判断、採用、予算

優先順位が1枚にまとまらない組織は、優秀な個人が増えるほど摩擦が増える。CTO代行の仕事は、ここを先に整えることだ。

3. 60日目: 小さく速い勝ちを作る

60日目までに、90日以内に完了する改善を2〜3件走らせる。

• リリースのボトルネック1つを除去する
• 障害対応のRunbookを整備する
• 重要KPIのダッシュボードを1枚作る

大規模リプレイスより、現場が「変わった」と実感できる勝ちの方が、次の投資判断を早める。勝ちが見えないまま戦略資料だけ増えると、代行は「また来たコンサルタント」になる。

4. 90日目: 次の四半期の投資案を出す

90日目には、次四半期の技術投資案を3案以内で提示する。

1. 守り: 止めると事業が止まる領域への投資
2. 攻め: 新規収益・効率化に直結する投資
3. 組織: 採用・評価・開発生産性への投資

CTO代行の価値は、コードを書く量では測れない。事業の速度とリスクのバランスを、経営と現場の両方で説明できる状態を作れるかどうかだ。

判断軸：CTO代行を入れる／まだ社内で足りる

状況	推奨
技術判断が経営に届かず、毎回同じ議論が繰り返される	代行・顧問を検討する
実装の人手不足が主で、優先順位は明確	まず採用／業務委託の増員
「とりあえず強い人」で負債一掃を期待している	期待値を90日の型に合わせるまで始めない
意思決定者が不在で、誰も優先順位を確定できない	代行より先に責任者を決める

次に確認すること

1. 90日の成功条件は「何が決まる／何が動く」か書けているか
2. 週あたりの稼働と意思決定への参加範囲は合意したか
3. 最初の2週間で見る事実リストはあるか
4. 大規模リプレイスを初手にしない合意はあるか
5. 60日時点の「小さな勝ち」候補は出せるか
6. 90日後に残す成果物（表・案）は何か

よくある質問

Q. 最初からフルタイムである必要がありますか？

多くの場合、最初の90日は週2〜3日でも足りる。重要なのは稼働日数より、優先順位会議と障害・リリースの意思決定に入れることだ。

Q. 既存のテックリードがいる場合、役割が被りませんか？

被らせない。テックリードが実装とチーム運営、代行が事業接続と投資判断、と分ける。境界が曖昧なまま入ると両方とも動きにくくなる。

まとめ

CTO代行の最初の90日は、英雄的な改修ではなく、事実・優先順位・小さな勝ち・次の投資案を残す期間だ。

依頼どおりに動くより、事実で依頼を更新できるかが成果を分ける。そこが整えば、その先の採用も開発も速くなる。

---

CTO代行・技術顧問の相談は、お問い合わせフォーム からどうぞ。