業務委託CTOから開発体制を引き継ぐチェックリスト

週2日・月80時間といった業務委託契約で技術責任者を担ってもらっていたが、契約終了や本人都合の離任が数ヶ月後に決まっている——このタイミングで相談に来る経営者は少なくありません。急な退職と違って時間の猶予はあるはずなのに、いざ引き継ぎを始めると「何を聞けばいいのか自体が分からない」という壁にぶつかります。

業務委託CTOは常勤ではない分、意思決定の理由や進行中の細かい判断が本人の頭の中にしか残っていないことが多く、しかも週数日の稼働だと引き継ぎに割ける時間も限られます。この記事では、契約終了が見えている状態で何を・どの順番で引き継ぐべきか、後任をどう選ぶかを整理します。

なぜ業務委託CTOの引き継ぎは見落とされやすいか

常勤CTOの退職なら、後任探しと同時に引き継ぎの必要性が経営陣にも自然と意識されます。業務委託CTOの場合、次の理由で引き継ぎが軽視されがちです。

• 「もともと週数日の関与だから、大きな引き継ぎは要らないはず」という思い込み(実際には技術選定・アーキ判断の大半を1人で背負っているケースが多い)
• 契約終了日は決まっていても、引き継ぎの期日が別途設定されていないため、最終日直前まで通常業務が優先される
• 業務委託契約は成果物(コード)の納品はあっても、判断の背景は納品物に含まれないことが多い

契約終了の1〜2ヶ月前には、後述するチェックリストを使って棚卸しを始めることをお勧めします。稼働日数が少ない契約ほど、残り稼働回数から逆算した引き継ぎ計画を明示的に立てないと間に合いません。

引き継ぐべき4つのもの

1. 技術的意思決定の背景

コードそのものより、なぜその選択をしたかの方が引き継ぎの難易度が高く、かつ失われると取り返しがつきません。

• 主要な技術構成(言語・フレームワーク・DB・インフラ)を選んだ理由と、当時検討して採らなかった代替案
• 「あえてやっていないこと」の理由(例: マイクロサービス化を見送った理由、特定機能を意図的に作り込んでいない理由)
• 既知の技術的負債とその理由(時間がなくて後回しにした/意図的にシンプルに倒した、の区別)

これらは議事録やSlackのやり取りに断片的に残っていることが多いですが、体系立てて1つの文書にまとめる作業は本人にしかできません。最後の数回の稼働日を使って、ヒアリング形式で言語化してもらうのが現実的です。

2. 進行中の案件とその状態

契約終了時点で「動いている途中」のものをすべて洗い出します。

• 未マージのブランチ・レビュー待ちのPRとその意図
• 設計だけ決まっていて実装が手つかずの機能(なぜその設計にしたかも含めて)
• 外部ベンダー(開発会社・フリーランス)への発注中タスクと、その進捗確認の窓口
• 直近で発生した障害・不具合とその暫定対応(恒久対応が未実施なら、その計画も)

これを引き継がずに契約が切れると、後任は「動いているが理由の分からないブランチ」の山から着手することになり、ゼロから読み解くコストが発生します。

3. アクセス権と外部との関係

技術面より地味ですが、これが漏れると実務が止まります。

• クラウド(AWS/GCP等)・GitHub Organization・ドメイン/DNS・監視ツール・決済系SaaSのアカウントが、業務委託CTO個人の名義になっていないか
• 外部委託先(開発会社・フリーランスエンジニア)との契約窓口・稼働状況・支払い条件を誰が引き継ぐか
• 本番障害発生時の一次対応手順と、緊急連絡先(業務委託CTO本人への連絡が必要なくなった後、誰が対応するか)

業務委託契約では、初期構築時にCTO個人のメールアドレスでクラウドアカウントを作成したまま放置されているケースが実際に多く見られます。契約終了前に全アカウントの名義を棚卸しし、会社名義に移管しておく必要があります。

4. 意思決定の「型」

技術選定の結果だけでなく、どう判断していたかのパターンを引き継げると、後任の立ち上がりが早くなります。

• 新機能追加時、内製と外注をどう使い分けていたか
• リリース判断の基準(何が揃えば本番に出していいか)
• 技術的負債への向き合い方(どこまで許容し、どこから直すか)の優先順位づけの考え方

これは文書化しにくい暗黙知ですが、最後の面談で「もし次の技術判断者に一言だけアドバイスするなら」という形で聞き出すと言語化しやすくなります。

意思決定の空白をどう埋めるか

業務委託CTOがいなくなると、次の技術的意思決定を誰がするかが契約終了日から即座に空白になります。この空白は、後任が決まるまでの間、次のいずれかで埋める必要があります。

• 社内のエンジニアがいる場合: 実装力はあっても経営判断とのすり合わせ経験が薄いことが多い。最初の数ヶ月は判断の粒度を小さくし、迷ったら止まって確認するルールにする
• エンジニアが社内にいない場合: 経営者(CEO/COO)が暫定オーナーとして「何を優先するか」だけでも決める体制にする。技術の詳細判断は次項の後任候補に橋渡しする
• どちらもいない場合: 意思決定者不在のまま数週間放置すると、些細なリリース判断すら止まる。後任探しと並行して、期間限定でも技術判断を担う外部パートナーを立てるべき

後任の選択肢を比較する

契約終了後の体制は、主に3つの選択肢があります。それぞれの向き不向きを整理します。

選択肢	向いている状況	注意点
社員CTOを採用する	事業が拡大期で、技術組織を長期的に自社で育てる方針が固まっている	採用に数ヶ月〜半年かかる。採用が決まるまでの空白期間を別の手段で埋める必要がある
別の業務委託・フラクショナルCTOに切り替える	週数日の関与で十分な事業規模・開発量が続く見込み	前任者の暗黙知を新しい委託先にどう渡すかが課題。引き継ぎ資料の質がそのまま立ち上がりの速さに直結する
開発チームが自走する(技術責任者を置かない)	エンジニアが複数人おり、技術力より意思決定の橋渡しだけが必要だった	経営判断との接続役が抜け落ちやすい。誰かが明示的にその役を引き受けないと、技術と事業の方向性がずれ始める

どれを選ぶ場合でも、引き継ぎの質が後任の立ち上がり速度を決める点は共通しています。特に「別の外部CTO」「開発チーム自走」を選ぶ場合、前任者から直接ヒアリングできる期間中に資料化を終えておかないと、後から復元するコストは数倍に膨らみます。

すでに契約が終了してしまい、引き継ぎ資料もほとんど残っていない状態であれば、前任者が去った後の引き継ぎやCTO退職後も開発を止めない引き継ぎ方で、事後的な復元手順を解説しています。引き継ぎ後にコードそのものの改善へ進む際に外部チームが最初に見る観点は、既存プロダクトの改善、外部チームが最初に見る観点にまとめています。

契約終了までにやることチェックリスト

契約終了の1〜2ヶ月前を目安に、以下を稼働日ベースで計画に落とし込みます。

• [ ] 全クラウド・SaaSアカウントの名義を確認し、会社名義に移管する
• [ ] 主要な技術選定の理由と代替案を文書化してもらう(ヒアリング形式で可)
• [ ] 進行中のブランチ・PR・未実装の設計を棚卸しリストにする
• [ ] 外部委託先との契約窓口・支払い条件の引き継ぎ先を決める
• [ ] 本番障害時の一次対応手順と緊急連絡先を更新する
• [ ] 「意思決定を誰がするか」の暫定オーナーを契約終了日までに確定する
• [ ] 後任の選択肢(社員採用/別の外部CTO/自走)のどれを取るか、採用リードタイムを踏まえて逆算する

まとめ

• 業務委託CTOの引き継ぎは「稼働日数が少ないから軽い」わけではなく、技術選定の背景や意思決定の型が1人に集中している分、むしろ入念な棚卸しが要る
• 契約終了日から即座に「誰が技術判断をするか」が空白になるため、後任確定前でも暫定オーナーを置く
• 後任は社員CTO採用・別の業務委託CTO・開発チーム自走の3択で、どれを選んでも引き継ぎ資料の質が立ち上がり速度を決める

torcheees では、業務委託CTOからの引き継ぎ期にCTO/PdM右腕としての開発支援(準委任・継続的な準委任支援)で入り、進行中の開発を止めずに技術の意思決定を橋渡しします。まず現状のコード・インフラ・進行中案件を一緒に棚卸ししたい場合は、既存プロダクト改善の診断から始めることも可能です。契約終了が近づいている、あるいはすでに引き継ぎが不十分なまま体制が変わってしまった——どちらの段階でも、お問い合わせフォームからご相談ください。