CTOの月次報告に何を書くか。経営会議で技術投資を決める資料

CTOの月次報告では、開発した機能や障害件数の一覧だけでは判断材料が足りません。経営者が知りたいのは、事業にどんな影響があり、放置すると何が起き、今月は何を決めればよいかです。僕なら、停止の影響、開発待ち、費用の変化を、基準との差から承認依頼まで一続きにして出します。

「問題があります」で終わる報告も、「順調です」で終わる報告も、経営会議では扱いに困ります。判断できる月報には、比較する基準、事業への影響、次の行動、その責任者、経営に求める承認があります。ただし、項目を埋めれば十分というわけではありません。数字の母数や比較条件が違えば、整った資料ほど誤った判断を招きます。

以下では、同じ架空の一組織・一システム・30日間を対象にした月次報告の記入例を使います。数値はすべて説明のための仮定で、実在企業の実績、市場相場、当サービスの料金、成果保証を示すものではありません。

CTOの月次報告は経営の承認事項から逆算する

月次報告の読み手に求められるのは、技術の専門知識より経営判断です。「障害対応を優先して新機能の公開を遅らせる」「承認待ちを減らすため事業責任者へ権限を委譲する」「費用増を受け入れて追加予算を認める」といった判断を経営が担います。CTOは、その材料を技術側から翻訳して渡します。

報告の基本単位を論点に置き、「実績」「社内基準との差」「事業への影響」「取る行動と責任者」「承認してほしいこと」を一組にします。赤や黄色だけの表示は、会議の参加者によって意味が変わります。基準を外れたら誰が何をするかまで決めて、初めて月報が運用になります。

この考え方は信頼性の管理にも共通します。2026年9月21日時点で、GoogleのSRE Workbookは、SLOを信頼性についてデータに基づく判断と技術作業の優先順位付けに使い、エラーバジェットを意思決定に使う組織的な合意が必要だと説明しています。使い切った場合の具体的な行動と担当者も方針に記します。数字と基準を具体的な行動へ接続する設計です。Google Site Reliability Engineering「Implementing SLOs」

なお、月次の資料だけで大きな投資を即断するのは危険です。同資料は、短い計測期間を素早い軌道修正に、長い期間のデータを複数四半期にまたがる投資判断に対応させています。今月の異常への対処と、中長期の構造的な投資は同じ欄に混ぜず、月次では「今決めること」と「継続観察すること」を分けます。

経営と技術の言葉をどうつなぐかは、経営と技術をつなぐ人がいないと、会議は決まらないでも整理しています。月報は、その翻訳を毎月同じ条件で行うための道具です。

停止・開発待ち・費用を一枚にした月次報告の記入例

以下は架空の記入例です。集計期間は30日間と仮定し、停止、開発待ち、費用で対象範囲を混ぜません。会議では末尾の承認依頼を先に読み、判断に必要な根拠へ戻る使い方を想定しています。

• 停止の影響：重要機能を決済と定義。計測できた決済試行200,000件のうち、停止時間帯にサービス側エラーで完了しなかった試行は600件、失敗率は0.3%（600÷200,000×100）。再試行の成否、ユニーク顧客数、売上損失とは同一視しない。対応は原因除去と再発防止策の実施、責任者と期限を記載。経営への依頼は、信頼性対応を新機能より優先するかの承認。
• 開発待ち：同じサービスで、開発チームが承認依頼を記録してから事業責任者が仕様承認するまでを計測。今月中に承認された4件は3、5、8、10営業日で、平均6.5営業日。架空の要決裁基準である5営業日を1.5営業日超過。経営への依頼は、決裁責任者の明確化または権限委譲。未解決案件は平均から漏れるため、件数と経過日数を別記。
• 費用の変化：同じ対象システム、配賦範囲、税込・割引調整後という条件で、月初の承認済み予測1,200,000円に対し実績1,500,000円。差額は300,000円、予測比では25.0%超過。架空の要承認基準10%を15.0ポイント超える。原因、翌月見込み、是正案の責任者と期限を記載し、是正案または追加予算の承認を依頼。

この3欄では、あらかじめ置いた基準を超えた時点で会議の仕事が発生します。0.3%という結果は、重要なユーザー行動に対して自社が合意した信頼性方針に照らし、優先順位を変えるか判断する材料です。5営業日と10%も、この架空組織の運用例にすぎず、普遍的な推奨値ではありません。

停止欄では、期間、全試行という母数、失敗試行の定義を固定します。GoogleのSRE Workbookも、2026年9月21日時点で、ユーザー影響を表すSLIを良好なイベント数と全イベント数の比率で捉え、分子・分母・しきい値を一貫した入力にする考え方を示しています。停止時間という値だけからは、利用の少ない時間帯と重要な取引が集中する時間帯の違いを経営者が判断できません。また、600件を600人や失った売上へ読み替えると、計測定義を越えた推測になります。月報に書けるのは、計測定義が支える範囲までです。

開発待ちを経営の詰まりとして読む

開発が遅いと聞くと、エンジニアの人数や生産性へ目が向きます。では、人数を増やせば解消するのでしょうか。実装が止まる理由には、仕様承認、法務確認、素材提供、予算決裁の待ちもあります。このような場合の詰まりは事業側の意思決定です。「開発速度が低下」と丸めた月報は、採用や外注という見当違いの投資を招きます。

2026年9月21日時点で、DORAは変更がコミットから本番配備まで進む時間や配備頻度をスループットとして扱い、即時介入を要した配備などを不安定性として分けています。また、指標はアプリケーションまたはサービス単位で捉え、文脈の異なるチームやシステムを混ぜた比較を避けるよう注意しています。DORA「Software delivery performance metrics」

月報では、対象サービスと待っている工程をそろえて開発日数を読みます。DORAのバリューストリーム管理の解説は、2026年9月21日時点で、工程間の待ち時間と引き継ぎを捉え、作業の滞留やチーム間の摩擦を特定する方法を示しています。DORA「How to use value stream mapping to improve software delivery」

架空例の平均6.5営業日は、完了した4件だけの値です。この結果を受け、誰が仕様を決裁するのか、一定期間返答がないとき誰へ権限を移すのか、いつから適用するのかを決めます。担当者への催促で済ませると、同じ詰まりが翌月も残ります。未解決案件は平均に入らないため、長く止まった案件を隠さないよう別欄に残します。結果として、技術チームへの評価と経営側の宿題を切り分けられます。

月報に載せるのは、今月の承認が必要な論点です。外部のCTOにどこまで決裁前の整理を任せるかは、CTO代行を入れると、組織の意思決定はどう変わるのかで確認できます。

費用差異から翌月の選択肢を決める

費用欄で前月比だけを示すと、今月の利用増が計画内なのか、予算統制から外れたのかを判断できません。比較対象にすべきなのは、その意思決定時に承認した予測です。しかも、対象システム、配賦範囲、税や割引の扱いが実績と同じでなければ、差額に意味はありません。

FinOps FoundationのFrameworkは、2026年9月21日時点で、実績を示す報告の中に意思決定時の見積もりも置き、予測と実績を対比できる形を示しています。FinOps Foundation「Reporting & Analytics」 また、予測差異には組織ごとの許容しきい値を設け、実績が予測を超えた、または超える見込みなら、追加予算を求めるなどの行動へつなげます。FinOps Foundation「Forecasting」

架空例では、予測1,200,000円と実績1,500,000円の差額は300,000円です。差額を予測で割ると25.0%で、要承認基準10%を15.0ポイント超えます。ここで「利用増が原因でした」と説明して終えるのは不十分です。利用増を受け入れて追加予算を承認するか、構成や利用条件を見直すか、施策を延期するかを判断します。翌月見込みと選択肢を同じ条件で示し、推奨案、実行責任者、期限まで置きます。

費用増の評価は、事業上の必要性によって変わります。必要な利用増なら、抑制より追加予算が合理的な場合があります。月報は、予測から外れた変化を経営が意図して受け入れるのか、是正するのかを決める材料になります。

欠けた月次報告は、経営会議へ載せる前に差し戻す

僕なら、停止の欄に期間・母数・失敗件数がなければ差し戻します。開発待ちの欄に、どの工程で何を待ち、誰がいつ決めれば再開するかがなければ差し戻します。費用の欄に、同じ定義の承認済み予測、差異の理由、翌月見込み、是正案または追加予算の承認依頼がなければ差し戻します。

さらに、どの欄でも行動の責任者と期限がなく、「共有」で終わるなら経営会議へは載せません。数字を出す欄には定義を添えます。精緻な数字がそろっていても、承認依頼を欠けば観測資料の域を出ません。

CTOの月次報告へ書くべきものは、停止の影響、開発待ち、費用の変化です。各項目を同じ月の事実として捉え、基準、事業影響、行動、責任者、承認へつなげます。停止対応を優先するか、決裁権を移すか、費用増を受け入れるかを判断します。数字の母数や比較条件を確認し、経営者がその場で一つでも決められるなら、月報は技術投資を動かす資料になります。