CTO・VPoEの組織改善90日ロードマップ

“心に残った言葉を、選択してシェア。

CTO・VPoEとエンジニア組織の実践ガイド｜第10回

この連載では、「優秀なのに嫌われる上司」から始まり、CTOの役割、組織の危険サイン、開発の遅さ、経営と技術のすれ違い、メンター、外部CTO、感情とEQまで扱ってきました。ここまで読むと、課題が複数つながっていることに気づくかもしれません。問題は、どこから変えればよいか分からないことです。

そこで最後の第10回では、CTO・VPoEと経営者が一緒に使える「90日間の組織改善ロードマップ」を紹介します。90日という期間は、変化を保証する魔法の期限ではありません。現状を確かめ、小さな施策を試し、その結果を確認するための計画の一例です。組織の規模や問題の深刻さによって、期間や順序は調整してください。

いきなり制度や人を変えないことが最初の原則

技術組織の問題に気づくと、CTOを交代させる、評価制度を刷新する、会議を増やす、といった大きな施策を考えたくなります。しかし原因が十分に分かっていない段階で対策を決めると、違う問題を解こうとしてしまいます。例えば開発の遅さが仕様承認の待ち時間にあるなら、エンジニアを増やしても改善しない可能性があります。

最初に確認したいのは、事業への影響が大きい問題は何か、どんな事実があるか、まだ分かっていないことは何かです。個人の性格、部署の印象、根拠のない評判だけで優先順位を決めないことです。役割の設計、技術の状態、人の関係を分けて見ます。

1〜30日：現状を見える形にする

第1週．CEOとCTOの期待値をそろえる

CEOとCTOが別々に「今期、技術組織に期待する成果」を三つ挙げます。開発速度、品質、採用、技術戦略、顧客への提供価値など、言葉が同じでも意味が違う場合があります。互いの回答を比較し、役割と権限が一致しているかを確かめます。CEOが決めること、CTOが決めること、PdM・EMへ任せることも確認します。

この時点ですべてを決める必要はありません。ただし「誰が何を決めるか不明」という状態を残すなら、いつまでに誰が決めるかを記録します。議論の結論が次の会議まで行方不明にならないことが重要です。

第2週．開発の流れを一つの案件で確認する

最近遅れた案件、品質に問題が起きた案件などを一つ選びます。顧客の要望から仕様、実装、レビュー、テスト、本番反映までを時系列で並べ、実作業と待ち時間を分けます。変更リードタイムやデプロイ頻度など、DORAの指標も参考になりますが、数字を責任追及に使わないことが必要です。[1]

どの段階で滞留したか分かれば、改善策は変わります。要件確定待ちなら意思決定を、レビュー待ちなら開発プロセスを、障害対応の繰り返しなら技術投資を見直します。問題の種類に合わせて対策を考えます。

第3週．チームの意見と事実を集める

1on1や振り返りを通して、仕事で困っていることや、改善したい条件を聞きます。質問は「誰が悪いですか」ではなく、「どの仕事で止まりますか」「何があれば進めやすいですか」と具体化します。個人の感情を無理に話させず、回答の取り扱いにも配慮します。

心理的安全性に関する研究は、質問や失敗の共有をしやすいチーム環境が学習行動と関連することを示しています。ただし、発言量だけで安全性を測れるわけではなく、業務上の条件と合わせて確認する必要があります。[2]

第4週．最優先の問題を一つ決める

経営者、CTO、現場から得た情報を並べ、事業への影響、改善の実行可能性、放置した場合のリスクから優先順位を付けます。一度にすべての問題を直そうとしないことが大切です。例えば「プロダクトの優先順位が毎週変わる」という課題が大きければ、まずその判断方法を決めます。

ここまでの成果は、完成した改革計画ではありません。今起きている問題の説明と、次の30日で何を検証するかについて共通認識ができた状態です。

31〜60日：小さく改善策を試す

判断の責任者を明確にする

止まっている判断を一つ選び、最終決定者、助言者、実行者を明示します。例えば機能の優先順位はPdM、技術方式はテックリード、重大なリスクの例外はCTOが判断する、といった分担です。人数の少ない会社では兼務もありますが、誰が判断するかが分かることは重要です。

会議を「報告する場」から「決める場」へ

各会議の目的を確認します。決定事項がない定例は、非同期の共有で足りるかもしれません。決めるべき会議では、前提、選択肢、必要な判断と期限を事前に示します。会議後には決定事項、理由、担当者、見直し条件を残します。議事録の長さより、次に何を行うかが明確かどうかを見ます。

開発プロセスを一箇所だけ改善する

第2週で見つけた滞留を減らします。レビュー待ちなら変更を小さくし、レビュー担当の稼働を確保する。リリースの手間なら自動化を進める。要件の手戻りなら事前に確認すべき条件をそろえる。改善の前後で、待ち時間、手戻り、品質、現場の負担を比較します。

CTO・VPoEの役割と時間を見直す

CTOがすべての設計と承認を抱えているなら、一部をテックリードやEMへ渡します。ただし「任せる」と言うだけでは機能しません。判断できる範囲、相談条件、品質基準を定めます。管理職本人が使う時間を空け、技術戦略、採用・育成、経営との対話に向けます。

61〜90日：効果を確かめ、続ける仕組みにする

実際に何が変わったかを振り返る

施策の開始前に決めた指標や行動を確認します。レビュー待ちが短くなったか、未決事項が減ったか、障害の報告が早くなったか。数字が改善していても残業が増えているなら持続しないかもしれません。成果と負担の両方を見ます。

改善が見られなくても、その施策が無駄だったとは限りません。想定した原因が違った可能性があります。「何が起きたか」「何を学んだか」「次にどの仮説を試すか」を整理します。最初の判断が間違っていたときに修正できること自体が、組織の能力です。

評価・採用・育成へ反映する

会議や権限の改善が進んでも、評価が個人の短期成果だけを重視していれば、協働の行動は定着しにくい場合があります。管理職に求める行動、技術専門職に求める貢献を分けて考えます。評価基準を変更する場合は、何を重視するかを本人へ説明し、公正に運用します。

また、CTOやVPoEの仕事が属人化していないか確認します。次にその役割を担う候補者を育てる、重要判断を記録する、他者が説明できる状態にすることは、組織の持続性につながります。

次の90日で変えることを決める

90日目に完成を宣言するのではなく、改善が続く仕組みを決めます。優先課題は何か、進捗を誰が見るのか、技術投資をどの会議で判断するのか。必要な情報と相談相手を確保します。改善は一度のイベントではなく、仕事の中で繰り返す活動です。

外部の支援はいつ必要か

社内で判断し、改善を進められるなら外部支援は必須ではありません。一方で、技術責任者に相談相手がいない、CEOとCTOの認識差が埋まらない、複数の部門をまたぐ問題を整理する人がいない場合には、社外の視点が役立つ可能性があります。

必要なのがCTO本人の判断支援ならメンタリング、技術方式の専門的な評価なら技術顧問、一定期間の実務責任の補完なら外部CTOと、目的によって選びます。支援内容、権限、守秘、費用、社内への引き継ぎを確認したうえで判断します。

90日間の進み具合を示す指標の選び方

組織改善を進めると、経営会議で「何が改善したか」を尋ねられます。しかし、このとき単純に開発速度だけを成果とすると、品質を犠牲にする行動を促すかもしれません。指標は、改善したい課題と対応させて選びます。例えば仕様確定の遅れが主要因なら、意思決定が必要になってから確定するまでの時間を測る。コードレビューの滞留が課題なら、レビュー依頼から最初の応答までの時間を見る。重要なのは、原因と指標のつながりです。

あわせて、悪化させてはいけない品質や事業上の条件を確認します。リリースが速くなっても障害が増えれば、会社としての成果は損なわれます。採用の人数が増えても、受け入れや育成が追いつかなければ組織の負担は高まります。数値を使う場合は、対象期間、定義、測定方法をそろえ、変化の背景を言葉で説明します。小規模組織では一件の障害や退職で割合が大きく変わるため、率だけで比較しないようにします。

創業期・成長期・成熟期では進め方が違う

創業期の小さなチームでは、過度に細かな権限表や委員会をつくる必要はないかもしれません。むしろCEOと技術責任者が何を優先するかを短い時間で確認し、顧客の反応を見ながら改善することが重要です。一方で、開発チームが複数に増えた成長期には、全件をCTOが決める仕組みがボトルネックになります。チームごとの判断権限、共通の品質基準、横断する問題の扱い方を整える必要があります。

さらに事業が複雑になった会社では、既存システムの安定性と新規開発の投資を両立させることが課題になります。今期の短期成果だけでなく、数年先の保守や採用可能な人材、セキュリティリスクまで含めて技術投資を判断します。同じ「90日間の改善」でも、何を優先すべきかは組織の状況によって変わります。このロードマップは一律の処方箋ではなく、自社の問題に合わせて使う枠組みです。

第90日に経営者とCTOが確認する五つの問い

90日目には、取り組みを実施したかだけでなく、何を学んだかを確認します。「最初に想定した問題は本当に主要因だったか」「意思決定の責任者は明確になったか」「現場が以前より早く相談できるようになったか」「開発の速度と品質の両方を説明できるか」「次の90日で一つだけ変えるなら何か」。五つの問いに具体的な出来事を交えて答えられれば、改善活動は単なる行事から組織の学習へと近づきます。

もし成果が出なかったとしても、取り組みが無意味だったとは限りません。仮説が違った、課題が大きすぎた、権限が不足した、事業の優先順位が途中で変わったなど、原因を整理できます。失敗を理由にすべての取り組みを止めるのではなく、何を変えれば次の検証が有効になるかを考えます。CEOとCTOがその過程を共有すること自体が、技術と経営の関係を改善する第一歩です。

連載で学んだことを、次の90日に残す

第1回から第9回までに扱ったのは、上司の言動、CTOの機能、組織の不調、開発の遅れ、CEOとCTOの役割、メンタリング、外部CTO、感情、EQの実践でした。別々の問題に見えても、同じ会社の中で結びついていることがあります。だからこそ、すべての記事の対策を一度に実施するのではなく、今の事業で最も重要な問題を選び、その原因に合う方法を試すことが大切です。

90日が終わった段階で、改善した点だけでなく、なお判断できていない問題も残します。次の担当者が読んでも状況を理解できる記録があれば、担当者の異動や経営判断の変更があっても、改善活動を続けやすくなります。

まとめ：90日間で目指すのは「改善を続けられる組織」

組織の問題は、気合いだけで解決するものではありません。事実を確認し、原因を分け、判断者と期限を明確にし、小さな改善を試す。この順番を守ることが重要です。制度の変更や人の入れ替えが必要な場合もありますが、まず現在の構造を理解することから始めます。

最初の一歩として、CEOとCTOが今期の重要課題を三つ書き出し、比較してみてください。そこから見えた認識差が、改善計画をつくる出発点になります。本連載で扱った知識を、実際の判断と行動へつなげることが第10回の目的です。

90日を経過しても改善しなかった場合の見直し方

改善策を試しても変化が見られないことはあります。そのとき「社員の意識が足りない」と決めつけるのではなく、前提を再確認します。例えば、レビュー待ち時間を減らそうとしたのに短縮できなかったなら、レビュアーの人数が足りないのか、変更単位が大きいのか、緊急対応が常に割り込んでいるのか、原因は複数考えられます。改善策がうまくいかなかったという事実も、次の判断材料になります。

また、組織の感情的な関係が悪化している場合、業務プロセスの改善だけで信頼がすぐに回復するとは限りません。以前の強い指摘や説明不足が続いていたなら、過去の経緯を確認し、再発を防ぐ具体的な行動を積み重ねる必要があります。ハラスメントなど深刻な事案が含まれる場合は、通常の1on1や外部メンターの面談だけで処理せず、適切な人事・法務・専門窓口へつなぐことも欠かせません。

次の90日を計画するときは、最初に掲げた目標をそのまま延長しないことも重要です。技術組織の成長段階、顧客の状況、資金計画、採用状況が変われば、改善の優先順位も変わります。「前回は何を試したか」「どの条件が想定と違ったか」「次に解くべき制約は何か」をCEOとCTOが一緒に確認する。その対話を続けられることこそ、ロードマップの最も重要な成果です。

CTO・VPoE向け顧問・メンタリングについて

グロースウェルでは、技術責任者本人の判断と行動を支える顧問・メンタリングを、月1回60分のオンライン面談を基本に提供しています。経営との期待値調整、開発の優先順位、採用・育成、組織の課題について、何から取り組むかを一緒に整理します。技術責任者本人や育成を考える経営者からご相談いただけます。

CTO・VPoE向け顧問・メンタリング ／ お問い合わせ

CTO・VPoEとエンジニア組織の実践ガイド｜全10回

1. 第1回：優秀なのに嫌われる上司の特徴と改善策
2. 第2回：CTO機能チェックリスト15項目
3. 第3回：エンジニア組織崩壊の兆候20選
4. 第4回：開発が遅い会社の共通点
5. 第5回：CTOがいるのに事業が進まない理由
6. 第6回：経営者・CTOにメンターは必要か
7. 第7回：外部CTO・技術顧問・メンタリングの違い
8. 第8回：なぜエンジニア組織は感情で崩れるのか
9. 第9回：CTO・VPoEのEQ実践法
10. 第10回：CTO・VPoEの組織改善90日ロードマップ（この記事）

参考文献・出典