CTOが機能しているか確認する15項目

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

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

「CTOを置いたのに、事業と開発の距離が縮まらない」。そんな悩みを持つ経営者は、CTO本人の技術力を問題にしがちです。しかし、肩書きがあることと、その役割が組織で果たされていることは別です。本人に十分な権限や情報が渡っていなければ、優秀な技術責任者でも結果を出しにくくなります。

今回は既存の記事に掲載している15項目を、経営者とCTOが一緒に使える自己点検表として整理し直します。重要なのは「何個当てはまるか」だけではありません。どの領域で、いつから、誰の判断が止まっているのかを具体的に確認することです。このリストは統計的に検証された心理検査や企業の倒産予測ではなく、対話を始めるための実務上の点検項目です。

まず、CTOの「機能」をどう定義するか

CTOがすべてのコードをレビューしたり、採用面接に毎回参加したりする必要はありません。事業の重要な決定に技術的な条件が反映され、開発チームが品質と速度の両方を考えながら動けること、将来の技術責任者が育つことが重要です。そのために、技術戦略、組織、投資判断のどこまでをCTOの責任とするかを明文化します。会社の規模によって役割は変わります。

例えば創業初期ならCTOが開発と採用を兼ねることも自然です。しかしエンジニアが数十人に増えても、CTOだけが技術選定、顧客説明、採用、評価、障害対応を抱えているなら、業務構造の見直しが必要かもしれません。役職名よりも「誰が決められているか」を見ます。

意思決定――まず3項目

1．CTOが重要な事業判断に関与できているか

新機能の優先順位、重要な顧客との契約、採用計画などがCTO抜きで確定し、実行責任だけ後から渡される状態は問題です。ただし、すべての会議に同席させるという意味ではありません。技術・納期・セキュリティに影響する判断を、事前に誰がどの情報で確認するかを決めます。判断記録に技術リスクが残っているかも確かめます。

2．CEO・CTO・PdMの決定権が明確か

事業優先順位は誰が決め、技術方式は誰が決めるのか。品質基準や例外を最終承認するのは誰か。複数の責任者が同じ判断を行うと、議論は長くなります。「責任を持つ人」と「意見を求める人」を区別し、重要な判断を一覧にします。決定者がいないのではなく、複数いて衝突していないかも確認します。

3．一度決めた方針を見直す条件があるか

市場の変化で方針を変えることは必要です。しかし、理由や影響を説明せずに変更すれば、現場は計画を信じなくなります。いつ、誰が、何を根拠に見直すかを定め、変更時には中止する仕事も明示します。方針を変えた回数より、変更がどう伝えられたかが重要です。

コミュニケーション――次の3項目

4．CEOとCTOは同じ目的を話しているか

CEOが「早く出したい」と言うとき、それは商談期限、資金繰り、検証機会のどれでしょうか。CTOが「難しい」と言うとき、それは技術的に不可能、予算が必要、品質基準に抵触する、というどの意味でしょうか。抽象語を分解し、同じ会議の後に両者が同じ決定事項を説明できるか確認します。

5．技術課題を事業影響として説明できるか

「技術負債が重い」だけでは投資判断はできません。例えば「この部分を今直さないと、新機能の検証に毎回追加の確認が必要になる」「障害が起きた場合の復旧が長くなる」と、顧客・納期・コスト・リスクに翻訳します。事業側も技術的な制約を理解できているか、対話で確かめます。

6．懸念や反対意見が会議で出ているか

全員が黙っている会議が良い会議とは限りません。判断が速い反面、異論が出せない可能性もあります。「この判断が失敗するとすれば、どこですか」と具体的に問う機会を設けます。反対意見を採用しないときには理由を説明し、発言者を不利に扱わないことも重要です。[1]

組織運営――次の3項目

7．エンジニアから改善提案が出ているか

提案が減った理由は、諦めかもしれませんし、目の前の仕事が増えたからかもしれません。すぐに意欲不足と判断しないことです。最近の改善提案を三つ挙げ、対応状況を確認します。採用されなかった提案にも理由が共有されているかが重要です。

8．チームを横断する課題の責任者がいるか

フロントエンドとバックエンド、プロダクトとインフラ、営業と開発。境界をまたぐ課題が宙に浮くと、顧客への価値提供は遅れます。具体的な顧客課題に対して、調整の責任者を一人決めます。責任者が全作業を引き取る必要はなく、判断を前に進める責任を持つという意味です。

9．障害や品質問題を学習につなげているか

障害が起きたとき、誰が悪いかだけを議論していないでしょうか。影響範囲、検知、判断、回復、再発防止策を確認します。安全上の重大な違反には責任が伴いますが、学習を妨げる人格攻撃は避ける必要があります。次回の判断に残る記録があるかが判断材料です。

採用・育成――次の3項目

10．採用辞退の理由を調べているか

候補者が辞退したことを、給与の問題だけで片づけていないでしょうか。期待する役割の説明、選考期間、働き方、技術的な挑戦の魅力も関係します。辞退者から得られた情報は、個人が特定されない範囲で傾向を確認します。少数の事例を「組織の文化が悪い証拠」と決めつけないことも大切です。

11．面接官の評価基準がそろっているか

ある人はアルゴリズム力、別の人は設計力、さらに別の人は説明力を見ている。評価対象が違うのに総合点だけを比較すると、採用判断がぶれます。役割に必要な能力と質問、評価基準を事前に整理し、面接後は具体的な行動や回答を根拠に議論します。

12．重要人材の育成・定着について対話しているか

優秀な人ほど辞めるとは一概に言えません。転職には待遇、生活環境、キャリアなど複数の理由があります。ただ、特定チームで離職が続くなら無視すべきではありません。役割への期待、成長機会、評価の納得感を確かめます。退職を引き留めることと、働き続けたい環境を整えることは分けて考えます。

開発と技術投資――最後の3項目

13．開発の遅さを分解して説明できるか

「開発が遅い」だけでは改善策を選べません。仕様確定待ち、レビュー待ち、実装、テスト、リリース承認、障害対応のどこで時間を使っているのか調べます。DORAが示す変更リードタイムやデプロイ頻度などの指標は参考になりますが、担当者ごとの順位づけではなく、チームの流れを改善するために使います。[2]

14．技術議論を事業上の選択肢に変換できるか

新技術を採用するか、既存の仕組みを維持するか。議論が続くなら、検証に必要な期間、運用負荷、リスク、撤退条件を比較します。CTOは技術を守る人であると同時に、事業が判断するための情報を提供する人です。「どの技術が好きか」から「今回何を達成するか」に焦点を戻します。

15．技術負債を継続的に評価しているか

技術負債を完全になくす必要はありません。重要なのは、何を先送りし、その結果どのような追加コストやリスクが生じているか把握することです。障害、開発速度、セキュリティ、採用難度に影響するものを優先し、対応を投資判断に載せます。「今は忙しいから」の一言だけで終わっていないか確認します。

15項目の結果をどう読めばよいか

15個中何個当てはまったかは、会話の入口にはなります。ただし「4個だから危険」「10個だから機能不全」といった点数の境界に科学的な根拠があるわけではありません。数だけではなく、事業への影響、継続期間、改善できる人がいるかを見ます。例えば、情報セキュリティ上の重大な責任不在は、一つでも優先して扱うべきです。

経営者とCTOがそれぞれ独立して項目に印を付け、回答が異なる理由を話す使い方をおすすめします。CEOはCTOの関与を十分だと感じていても、CTOは重要な判断を後から知らされているかもしれません。その差こそ対話の材料です。最終的には、今月解決すべき課題を一つ決めて、次回の会議で結果を確認します。

CEOとCTOで評価が分かれたときの読み解き方

15項目をCEOとCTOが別々に記入すると、同じ会社についても答えが違うことがあります。例えば、CEOは「事業判断にCTOが関与している」に丸を付け、CTOは「重要な判断は決まった後に知らされる」と答えるかもしれません。これはどちらかが嘘をついているということではありません。CEOは定例経営会議への出席を「関与」と考え、CTOは選択肢を比較する段階からの参加を求めている可能性があるからです。

こうした違いが見つかったら、印象の良し悪しで議論する前に、直近の決定を一件選びます。新規プロダクトへの投資や大型案件の受注、採用計画の変更など、実際に判断が必要だった出来事です。「誰がいつ候補案を出したか」「CTOが反対意見を示せる場面はあったか」「判断の期限は誰が決めたか」を振り返ります。経営者側がCTOに情報を渡せていなかったのか、CTO側が必要な説明を行えていなかったのか、両方に課題があったのかが明らかになります。

同様に、CTOが「技術負債を評価している」と答えても、CEOには投資判断に使える材料が届いていない場合があります。リファクタリングしたい箇所を一覧にしただけでは、事業影響まで評価できたとは言えません。「放置するとどんな障害・変更コストが生じるか」「何週間の対応で何が改善するか」「後回しにできる条件は何か」を示すことで、経営が判断できる情報に変わります。15項目の価値は丸の数より、このような対話の質にあります。

チェックリストを人事評価へ転用するときの注意

この15項目は、CTOの適性を科学的に診断する標準化検査ではありません。会社の成長段階、採用可能な人材、事業モデル、CEOの役割によって、理想的なCTOの働き方は異なります。例えば創業初期にはCTO自身が設計・実装を大きく担うことが合理的でも、組織が数十人になれば育成や権限委譲の比重を増やす必要があります。異なる事業段階を無視して単純な得点比較をすることは避けます。

人事評価に用いるなら、役割定義と期待成果を先に明文化し、当事者が変更できる条件を分けて考えます。開発組織の採用がうまくいかない理由が報酬水準や会社の知名度にあるのなら、CTO一人の問題ではありません。反対に、技術責任者が育成や採用にほとんど関与していないのであれば、期待する行動を具体的に話し合えます。点数を材料に責任を押し付けるのではなく、組織の機能を改善するために使ってください。

今月の最優先課題を一つに絞る

点検をしても、15項目すべてを同時に変えようとすると疲弊します。まず事業や顧客への影響が大きく、実行責任者が明確で、1か月以内に改善の手応えを確かめられる課題を選びます。「CTOに技術と事業の共通指標を毎週共有してもらう」「プロダクトの優先順位を決める会議に判断者を明確にする」といった小さな変更でも構いません。

チェックリストを使う目的は、CTOを査定して責めることではありません。経営と技術の双方に見えている事実をそろえ、今の役割と会社の成長段階が合っているかを検討することです。必要であれば役割の再設計、育成、技術顧問の活用まで選択肢を広げます。

15項目を使った「CEOとCTOのすり合わせ会議」の進め方

チェックリストを単独で回答して終えると、CEOが厳しい評価をつけ、CTOは納得できないという対立を生むことがあります。おすすめは、互いに記入した結果を持ち寄り、数が違う項目ではなく「なぜ違って見えているのか」から話すことです。例えば「CTOが重要な事業判断に関与していない」についてCEOは問題なし、CTOは問題ありと回答したとします。CEOは経営会議へ招いているつもりでも、CTOは最終決定後に実装の可否だけ尋ねられている可能性があります。必要なのは、出席回数より、選択肢を決める時点で技術側の情報が使われているかという確認です。

最初の15分は、見方が分かれた項目を二つだけ取り上げます。それぞれが最近の具体的な会議や案件を一つ挙げ、確認できる事実と解釈を分けます。次の15分で、その違いを生む意思決定の流れを紙に書きます。残り15分は「誰が」「いつまでに」「何を変えるか」を一件だけ決め、次の定例で変化を見ます。例えば、仕様変更の承認条件を決める、障害の振り返りにPdMを加える、採用要件をCEOとCTOで書き直す、といった単位です。

なお、チェックリストの結果を個人の人事評価に使う場合は注意が必要です。権限がない、採用予算がない、技術投資の優先順位を経営が決めていないといった事情はCTO本人の能力とは別です。本人の行動を評価する前に、仕事を進めるための条件が整っているかを確認してください。改善後に確認したいのは「項目の点数が下がったか」だけではなく、意思決定の待ち時間が減ったか、会議で必要な情報が揃ったか、経営と現場が同じ決定を理解しているかです。

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

役割と権限の整理、CEOとの対話、技術投資、採用・育成の判断を一人で抱え込んでいませんか。グロースウェルでは、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日ロードマップ

参考文献・出典