CTO代行から社内CTOへ引き継ぐ。契約を終える前に確かめる仕事

CTO代行からの引き継ぎが完了するのは、新任CTOが自分の権限で判断できた日です。資料の受領だけで完了とはしません。確かめる対象は、予算、障害対応、設計相談です。合意した範囲ならCTO代行の事前承認なしで決め、範囲外なら決められた相手へ自ら相談できる状態を確認します。その後に外部契約の終了日を決めるのが僕の結論です。

アカウント一覧や構成図がそろっていても、判断のたびに前任のCTO代行へ連絡するなら、意思決定はまだ社外にあります。新任CTOへ委ねる範囲も無制限にはしません。経営判断や専門外の判断まで抱え込ませず、「単独で決める範囲」と「誰に上げる範囲」を一組で渡す必要があります。

ただし、「判断できる」を本人の自己申告で済ませると、経営者は契約を終えてよいか判定できません。僕なら、三つの仕事を一枚の完了判定台帳に置き、実際の判断とその記録を確認します。

CTO代行の引き継ぎは、三つの判断を台帳で確かめる

次の台帳は、後任CTOへの引き継ぎを判定するための例です。後述する公式資料の一般原則を基に僕が提案する実務上の方法であり、原典が定める分類や義務ではありません。

台帳では、丸の数よりも判断の境界を見ます。「外部担当者がいなくても承認できるか」と「一人で決めてはいけないと気づけるか」の両方が必要です。経営者は各レーンについて、対象、権限、参照資料、相談先、実施記録が埋まったかを確認します。空欄があるレーンだけ支援を残せば、契約を続ける理由も終える条件も曖昧になりません。

CTO代行が担ってきた仕事を先に整理したい場合は、CTO代行を入れると、組織の意思決定はどう変わるのかも判断範囲を切り分ける材料になります。経営と技術の間に残る役割は、経営と技術をつなぐ人がいないと、会議は決まらないで具体化しています。引き継ぎ後、その役割を誰が持つかまで台帳に反映してください。

予算は、金額と承認経路を引き継ぐ

予算の引き継ぎでは、請求書の保管場所に加えて承認経路を渡します。新任CTOが対象費目と実績を確認でき、どこまで単独承認できるか、何を判断材料にするか、差異が出たとき誰と是正方針を決めるかを説明できる状態が必要です。そのうえで、権限内の申請を実際に単独承認できたら、このレーンを完了とします。

Microsoftの「Build a cost-conscious organization」は、コスト管理には報告範囲、リソース整理、タグ、アクセス制御による可視性が必要で、説明責任は明確に設定・共有された予算から始まるとしています。また、予算との差異が生じた場合は、クラウド戦略チームとクラウドガバナンスチームが是正方針を決める形を示しています。同ページの更新日は2023年2月28日で、内容は2026年9月21日に確認しました。

この原則を台帳へ落とすなら、申請名、対象費目と実績を確認した場所、承認範囲内と判断した根拠、差異がある場合の相談先を同じ行に残します。説明直後の一回だけ承認できても、資料を自力で見つけられなければ再現できません。判断資料を読めても、差異を誰へ上げるか不明なら単独判断の境界が欠けています。資料への到達と相談先の把握がそろって初めて、予算判断が社内へ移ったと判定できます。

障害判断は、CTO代行をバックアップに置いて試す

障害対応では、手順書を読めることと、状況に応じて判断できることを分けます。Google SRE Workbookの「On-Call」は、オンコール担当者の役割を、本番インシデントへ適切な緊急度で対応し、必要に応じて診断、影響緩和、修復、またはエスカレーションを行うことだと説明しています。公開日と更新日はページ上で確認できませんが、内容は2026年9月21日に確認しました。

同資料の新設SREチームの事例では、運用、デバッグ、ロールバック、容量追加、監視、構成説明などをチェックリストと演習で確認し、前任チームの当番をシャドーした後、新チームを主担当、前任チームをバックアップとして移行しています。この主担当の交代に、引き継ぎ判定の要点があります。研修の受講履歴を確認したうえで、後任が行動するところまで確かめます。

僕なら、模擬または実案件で新任CTOを主担当に置きます。新任CTOは利用者影響を把握し、初動の影響緩和、継続対応、社内外へのエスカレーションのどれを選ぶかを決め、判断と対応の記録を次担当へ渡します。CTO代行は先回りして指示せず、バックアップとして待ちます。

確認後は結果に加え、何を根拠に緊急度を判断したか、どこから先を自分だけで決めなかったか、次担当が記録から状況を追えるかを問います。CTO代行が口頭で補わなければ説明がつながらないなら、記録かエスカレーション条件を直し、もう一度主担当を任せます。

設計相談は、答えより参照先と更新までを見る

設計相談では、過去の決定の暗記量を問うより、必要な情報を見つけ、判断理由を説明し、決定後の文書を直せるかを確かめます。Software Engineering at Googleの「Knowledge Sharing」は、学習時に文書の誤りや欠落を更新すること、文書を発見可能にすること、古さや不正確さを報告できる手段を設けることを知識共有の実践として示しています。また、コードレビューを著者とレビュー担当者の双方にとっての学習機会と位置づけ、文書化された参照情報と専門家レビューを組み合わせる例を示しています。公開日と更新日はページ上で確認できませんが、内容は2026年9月21日に確認しました。

そこで新任CTOには、実際の設計相談を一件選び、参照先を自分で見つけ、レビューで判断理由を説明し、決定に合わせて文書を更新してもらいます。採点基準はCTO代行との答え合わせから切り離します。合意した権限内で根拠をたどり、決定を次の人が使える形へ戻せたら完了です。

社内だけで判断できない専門領域は、例外として残して構いません。例外台帳に、対象領域、相談先、呼び出す条件、参照する文書を記録します。「CTO代行に聞く」という記載は契約終了後に機能しないため、契約終了後も有効な相談経路か、社内の別の責任者へ置き換えます。設計相談の引き継ぎは、単独判断と専門家への相談を新任CTO自身が切り替えられれば完了です。

契約終了日は、三つの実施記録がそろってから決める

経営者が最後に見るのは、完了判定台帳に残った三つの実施記録です。予算では権限内の申請を承認できたかを確認します。障害判断ではCTO代行をバックアップに置いたまま初動とエスカレーションを選べたかを確認します。設計相談では参照先を見つけ、理由を説明し、文書を更新できたかを確認します。範囲外の判断についても、決めた相手へ自ら相談できたかを確かめます。納品物の数は、この判定の代わりにはなりません。

三つのどれかが未完なら、未完のレーン、残す支援、再確認する行動を台帳に書きます。契約を延長する場合も、その範囲と終了条件をこの記録に合わせます。三つが完了したら、CTO代行を判断経路から外し、社内の承認者と例外時の相談先を最終確認して契約終了日を決めます。

新任CTOへの説明を終えた時点は、CTO代行の引き継ぎにおける通過点です。予算、障害判断、設計相談について、新任CTOが合意済みの範囲を単独で判断し、範囲外を正しくエスカレーションし、その根拠を次の担当者へ残せることが完了条件です。僕なら、この三つの実施記録がそろった日を、仕事が社内へ戻った日と判定します。