CTO不在で外部開発チームに発注する時に決めるべきこと

「開発は全部お願いします」——技術に強いメンバーが社内にいないまま外部の開発チームに発注すると、つい丸投げに近い言い方になりがちです。しかし技術の意思決定を誰がするか、コードやインフラを誰が持つかを曖昧にしたまま進めると、後になって「思ったより身動きが取れない」「別のチームに引き継げない」と気づくことになります。

この記事では、CTOがいない発注者が外部開発チームと組む際に、事前に決めておくべきことを、体制パターン・チェック項目・具体的な失敗シナリオとあわせて実務的に整理します。

「丸投げ」の何が危険か——具体的に何が起きるか

技術がわからないから任せる、という発想自体は間違っていません。問題は、何を任せて何は自分たちで握るかを分けていないことです。

丸投げの状態でよく起きる具体的なシナリオ:

• 選定理由が誰にも説明できない: 「なぜこのDB構成なのか」を聞かれても、発注側もチーム側の担当者も答えられない。半年後に別のエンジニアが入ったとき、既存構成を疑って書き直しから始めることになり、追加で数百万円のコストが発生する。
• アカウントが受注側名義のまま: ドメイン・AWS・SaaSの契約者が受注会社の個人名義。契約終了を切り出した瞬間に「移管できません、退職者名義のままです」と判明し、サービス停止のリスクを抱えたまま交渉することになる。
• 進捗が「順調です」しか返ってこない: 実際は要件の解釈違いで的外れな機能を作り込んでいたが、動くデモを見せられないまま3ヶ月が経過し、リリース直前に手戻りが発覚する。
• 契約終了時に資料が何もない: デプロイ手順もインフラ構成図も担当者の頭の中にしかなく、後任チームが「動いているものを解読する」ところから始めるため、引き継ぎだけで1〜2ヶ月かかる。

これらは技術力の問題ではなく、発注時に取り決めをしていなかったことが原因です。技術がわからなくても、取り決め自体は発注者の仕事としてできます。

技術の意思決定を誰がするか——体制パターンで決める

CTO不在の会社が最初に決めるべきは、技術的な意思決定の主体をどこに置くかです。代表的な体制は3パターンあります。

1. フルアウトソース型: 技術選定・実装とも外部チームに一任。最も手離れが良い反面、発注側にノウハウが蓄積しない。小規模MVPや検証フェーズ向き。
2. 技術顧問併用型: 実装は外部チームに任せつつ、意思決定の妥当性チェックだけ社外CTO・技術顧問を月数回のスポットで挟む。コストを抑えつつ「言われるがまま」を防げる、CTO不在企業に最も現実的な折衷案。
3. 社内担当者ブリッジ型: 非エンジニアでもよいので、進捗・仕様確認の窓口を専任で1人置く。技術判断そのものはできなくても、「約束が守られているか」を継続的に見る役割は代替できない。

どのパターンでも共通するのは、意思決定の主体と責任範囲を契約前に文書化しておくこと。ここが曖昧なまま始まると、後述の「丸投げの危険」が高確率で顕在化します。

技術選定を任せる範囲を最初に決める

任せること自体は妥当な判断ですが、任せた結果を発注側が理解できる形で残してもらう必要があります。最低限、次の3点は文書で受け取っておくべきです。

1. なぜその技術構成にしたか(選定理由。将来の変更しやすさ・採用のしやすさ・コストなど判断軸込みで)
2. その構成で何が得意で何が苦手か(想定外の負荷やスケール要件が来たときの限界)
3. 代替案として何を検討して、なぜ採らなかったか

この3点があれば、次のチームに引き継ぐときも、自社でエンジニアを採用したときも、「なぜこうなっているか」を再現できます。逆にこれがないと、動いているコードだけが残り、誰も理由を説明できない状態になります。

コードとインフラの所有権は契約前に確認する

これは技術選定より優先度が高い論点です。開発が終わった後、誰が何を持っているかを契約前にチェックリストで確認してください。

• [ ] リポジトリ: 発注側の GitHub Organization に置く。受注側の個人・組織アカウントに置かない。
• [ ] ドメイン・DNS: 発注側名義で取得・管理する。レジストラのログイン情報も発注側が保持する。
• [ ] クラウドインフラ(AWS/GCP等)のアカウント: 発注側が契約者になり、受注側には必要な権限だけ付与する。個人アカウント配下のプロジェクトにしない。
• [ ] 各種SaaS(決済・メール配信・監視ツール等)のアカウント: 同様に発注側名義。請求先も発注側のカード・請求書払いにする。
• [ ] 秘密情報(APIキー・証明書等)の保管場所: 発注側もアクセスできるパスワードマネージャ等で共有管理する。

これらを受注側名義のまま進めてしまうと、契約を終了したいと思った瞬間に「動いているものが自社のものではない」ことに気づきます。移管には時間もコストもかかり、交渉力も弱くなります。発注段階で名義を発注側に揃えておくことが、後々の自由度を守る最も確実な方法です。目安として、開発着手から1〜2週間以内にこのチェックリストを埋め終える契約設計にするのが実務的です。

進捗をどう握るか——非技術者でもできる方法

技術の中身が分からなくても、進捗は握れます。ポイントは「動くものを、決まった頻度で見る」ことです。

• 週次か隔週で、実際に触れる画面・機能を見せてもらう(スライドの進捗報告だけで判断しない)
• やることリスト(バックログ)に優先順位がついているかを確認する。何から手をつけているか分かれば、進み方の妥当性を判断しやすい
• 「今週できたこと」と「来週やること」を毎回言語化してもらう。曖昧な報告が続く場合は、要件そのものが固まっていない可能性がある
• バグや未完了項目の数を毎回同じ形式で見せてもらう(件数の増減だけでも傾向は追える)

技術的な妥当性を判断できなくても、「約束した範囲が、約束した頻度で形になっているか」は発注者でも判断できます。目安として、2回連続でデモが「準備中」「もう少しで」と先送りされるなら、要件整理からやり直すべきサインです。

契約終了時の引き継ぎを最初から想定する

外部チームとの契約は、いつか終わります。良い関係で終わる場合も、そうでない場合もあります。どちらの終わり方でも困らないように、発注段階から引き継ぎを想定しておくことが重要です。契約終了時に最低限確保すべきものは次の通りです。

• ソースコード一式(発注側のリポジトリに常時反映されている状態)
• デプロイ手順書・環境変数一覧・インフラ構成図(担当者の頭の中だけに存在しない状態)
• 「このチームでないと直せない」ブラックボックスを作らない(コメント・設計ドキュメントを残す運用にする)
• 主要な意思決定の記録(前述の技術選定理由3点)
• 定期的に、社内の誰か(技術に詳しくなくてもよい)がリポジトリやインフラの状態を一緒に確認する機会

これは受注側への不信ではなく、事業を継続させるための当然の備えです。良いチームほど、こうした引き継ぎ前提の運用を嫌がりません。すでにCTOが離脱してしまった状態からの立て直しについては、「CTOが辞めても開発を止めない」も参考にしてください。

発注前チェックリスト

契約を結ぶ前に、以下を発注側からチーム候補に確認しておくと、丸投げのリスクを大きく減らせます。

• [ ] 技術選定の意思決定プロセスと、判断理由を文書で受け取れるか
• [ ] リポジトリ・インフラ・SaaSアカウントを発注側名義にできるか
• [ ] 週次/隔週での動くものベースの進捗共有に応じてもらえるか
• [ ] 契約終了時のドキュメント・引き継ぎ範囲が契約書に明記されているか
• [ ] 特定の個人に依存しない体制(チーム制)か

まとめ

• 技術の意思決定主体は体制パターン(フルアウトソース/技術顧問併用/社内ブリッジ)から選び、契約前に文書化する。
• 技術選定は「丸投げ」ではなく「任せた理由を文書で受け取る」形にする。判断の再現性が引き継ぎの土台になる。
• コード・インフラ・各種アカウントは発注側名義で持つ。名義の所有権は契約前にチェックリストで確認する。
• 進捗は「動くものを決まった頻度で見る」ことで、技術がわからなくても握れる。

CTO不在のまま発注先を探し始めると、技術選定・所有権・進捗管理のどこかが曖昧なまま契約に進んでしまいがちです。発注先の選び方自体で迷っている場合は「開発パートナーの選び方」も参照してください。torcheees の要件整理・開発診断では、こうした取り決めも含めて課題を整理し、優先順位付きバックログと技術構成案、開発ロードマップを作成した上でMVP開発へ接続します。技術の意思決定を発注者側が握れる状態を作ってから開発に入りたい方は、お問い合わせからご相談ください。