外部開発チームへの発注は、契約形態を選ぶところから始まり、立ち上げ、そしてプロジェクト終了時のナレッジ移管までを一連の流れで進めるものです。その全体は、次の5つのステップで整理できます。
- ステップ1：発注先と契約形態の選定、責任分担の明文化
- ステップ2：RFPと要件定義書の準備、スコープの合意
- ステップ3：AI時代のRACIと外部チームのRoleの設計
- ステップ4：オンボーディングと、混乱期を短くする運用の整備
- ステップ5：散会期から逆算した、ナレッジ移管と契約終了後の体制の決定
外部の開発チームに発注する際、契約形態の選び方や責任分担の設計があいまいなまま進めると、後工程で手戻りやトラブルが多発します。特に近年は、生成AIの活用やフルリモートを前提とした進行が当たり前になりました。そのため、従来の請負契約や人月見積もりを中心とした発想だけでは、外部チームを使いこなすことが難しくなっています。
発注側と受注側の責任があいまいなまま走り出すと、納期遅延や品質低下が起きるだけでなく、プロジェクト終了後にナレッジが何も残らない事態に陥る企業も少なくありません。
ナレッジ移管条項の具体例や、外部人材を準内製化するための運用ルールまで踏み込み、発注プロセス全体を設計できる内容にしました。発注経験の浅い担当者から、複数のベンダーを使い分けている事業責任者まで、明日から使える実務知識をお届けします。
Webサービス開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。
▼RFP作成前に読みたい無料ホワイトペーパーはこちらをご覧ください。
・Webサービス開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブックをご覧ください。
外部開発チームへの発注方法の全体像
外部開発チームへの発注は、契約形態の選定と責任分担の明文化から、立ち上げ期のチームづくり、プロジェクト終了時の知見移管までを、一連の設計として捉える必要があります。人月で開発を頼むような単純な作業ではないため、発注フェーズで決めるべきことを最初に洗い出しておくと、後の工程でも方針がぶれにくくなります。
発注先の種類と特徴
外部開発チームの発注先は、大きく4種類に分けられます。1つ目は受託開発会社で、要件定義から運用まで一気通貫で任せられる反面、人月単価は高めで、意思決定のスピードは中程度になります。2つ目はラボ型開発を提供するベンダーです。
ラボ型は専属チームを月額契約で確保できるため、中長期で機能追加を続けるサービスに向いています。3つ目はフリーランスのエンジニア集団で、人月単価を抑えつつ即戦力を確保できます。ただし、フリーランス活用型はナレッジが個人に依存しやすく、契約終了と同時に知見が消えるリスクがあります。
4つ目はオフショア開発拠点です。コストメリットは大きいものの、ブリッジSEの介在によるコミュニケーションのロスや時差の制約が無視できません。発注先を選ぶ際は、人月単価だけで比べず、ブリッジコスト、移管コスト、ナレッジ蓄積の難易度を含む総保有コストで判断することが大切です。
契約形態と責任の所在
外部開発チームへの発注で使われる契約形態は、主に請負契約と準委任契約の二択です。請負契約は成果物を完成させる責任がベンダー側にあり、仕様が固まった案件で有効に機能します。一方、準委任契約は業務の遂行を委任する形式で、仕様が流動的なアジャイル開発で広く採用されています。
準委任は柔軟ですが、品質の責任は基本的に発注側に残ります。そのため、責任分担を明文化しないまま走り出すと、「誰が品質を担保するのか」があいまいになります。契約形態を選ぶ際の基本的な整理は、仕様変更の頻度が低く検収基準を明確にできる案件は請負、不確実性が高くスクラムで進める案件は準委任、というものです。
ただし大規模案件では、要件定義フェーズを準委任、実装フェーズを請負、運用フェーズを再び準委任に分けるハイブリッド契約も有効です。契約書に、準拠する開発手法、進捗報告の頻度、変更管理の手順、後述するRACI表を別紙として添付すると、責任分担が読み取れるようになります。
発注前に準備すべきドキュメントと要件整理
発注前の準備が足りないと、見積もり精度の低下と立ち上げ後の混乱を必ず招きます。さらに、RFPやRFIを丁寧に作り込めば、ベンダー比較の精度が上がり、契約後の認識のずれも大幅に減らせます。
RFP(提案依頼書)に盛り込むべき要素
RFPには、最低限、事業背景、解決したい課題、対象システムの現状を盛り込みます。そのほか、希望スコープや想定スケジュールを書き、予算レンジと評価基準も入れておきます。特に評価基準を曖昧にしたまま提案を集めると、ベンダーはそれぞれ異なる前提で見積もりを出すため、横並びの比較ができなくなります。
技術要件と非機能要件は、それぞれ別のセクションに書きます。運用要件とセキュリティ要件も、別のセクションにします。そのうえで、必須要件と希望要件を分けると、比較の精度が大きく上がります。
RFPの段階では、「成果物の完成イメージ」と「成功の定義」を発注側で先に固めておくことが大切です。たとえば「ユーザー獲得数を半年で1万人に伸ばすためのアプリ刷新」のように、ビジネスゴールから逆算して書くと、ベンダーも提案の解像度を上げやすくなります。逆に、ゴールが「とりあえず作り直したい」のままだと、提案はどれも似通い、本当に力のあるベンダーを見極めにくくなります。
要件定義書とスコープ合意
発注が決まったあとの要件定義フェーズでは、機能要件と非機能要件を分けて整理し、ユーザーストーリーやユースケース図に落とし込みます。住友電気工業と住友電工情報システムの事例では、データ中心設計のアプローチを徹底したことで、開発コストを約30%削減し、組立型開発によりCOBOL比で約3倍の生産性を実現しました。
こうした事例から、要件整理の質がその後のコスト構造に直結することが、定量的にも示されています。スコープ合意で見落とされがちなのが、「やらないことリスト」です。何を作るかだけでなく、何を作らないかも明文化しておかないと、開発途中で「これも当然含まれているはず」という認識ズレが必ず発生します。
スコープ外と判断した項目は、要件定義書の末尾に「スコープ外項目」として一覧にし、追加が必要になった場合の変更管理プロセスもセットで定義しておくと、後の揉め事を未然に防げます。
AI時代のRACI設計と外部チームの役割定義
外部開発チームを発注する際は、責任分担の設計が最も大切で、RACIマトリクスを使って各タスクの担当を明文化します。区分は4つあります。Responsible(実行責任)とAccountable(説明責任)で誰が実行し誰が説明するかを、Consulted(相談先)とInformed(情報共有先)で誰に相談し誰に共有するかを示します。
生成AIやコパイロットが開発現場に入る時代になり、従来のRACIには新しい考え方を組み込む必要が出てきました。
AI時代におけるRACIの再定義
AI時代のRACIでもっとも大切な原則は、「Accountableは絶対にAIに持たせない」ことです。GitHub Copilotや各種AIレビュアーは、コード生成やテストケース作成の場面で、Responsible(実行)やConsulted(相談先)として扱えます。ただし、最終的な説明責任まで負うことはできません。
AIが生成したコードで本番障害が起きた場合、その責任を負うのは常に人間である、という前提を契約書とRACI表の両方に明文化する必要があります。外部開発チームに発注する場合でも、Accountableの所在は基本的に発注側に残ります。契約形態が請負でも準委任でも、この点は変わりません。
プロジェクト全体の説明責任は、最終的に発注側のプロジェクトオーナーが負います。そのため、外部チームに任せられるのは、ResponsibleとConsultedの一部までという整理になります。また、AIプロンプトの設計やレビューも、誰が承認し、誰が再検証するかをRACI表に書き込んでおくと、運用時の混乱を減らせます。
外部チームに割り当てるRoleの設計
外部チームに割り当てるロールは、組織上の職位(ジュニア/シニア/EM)とは分けて、実務上の役割として設計します。たとえば、プロダクトマネージャー、テックリード、ソフトウェアエンジニア、QAエンジニア、UI・UXデザイナーといった役割があります。ベンダー側のPMをカウンターパートに固定し、その人物が外部チーム内のResponsibleを取りまとめると、発注側の負荷が大幅に減ります。
大切なのは「One Boss原則」です。これは、1つのタスクにつきAccountableを厳格に1名だけとする運用ルールです。これを破ると、責任の押し付け合いが起き、意思決定が止まります。
また、発注側と受注側の双方にPMを置き、両者で週次の意思決定会議を運営する、シェアードPMという形も有効です。さらに、フルリモートが前提の場合は、非同期コミュニケーションのRACI、つまり「誰がドキュメントを書くか、誰がレビューするか、誰が承認するか」まで詳しく決めておく必要があります。
外部チームの立ち上げ:混乱期を短縮する設計
チームの発展プロセスを示すタックマンモデルでは、形成期、混乱期、統一期、機能期、散会期という5段階を経るとされています。外部チームは契約期間が限られているため、混乱期を素早く抜けられるかどうかが、プロジェクトの成否を分けます。
混乱期は飛ばせません。そのため、「短縮する」発想で立ち上げを設計するのが現実的です。
形成期のオンボーディング設計
外部チームの形成期は、契約締結直後の最初の2週間が勝負になります。この期間にミッションやビジョン、成功の定義を一気に共有すると、外部メンバーは「自分もこのプロジェクトの当事者だ」と感じられるようになります。
コミュニケーションのルールやドキュメント整備の方針、緊急時のエスカレーションフローも、この期間に伝えておきます。逆に、この期間を蔑ろにすると、外部チームは指示待ちに固定化し、自律的な提案が一切出てこなくなります。
外部人材でも、6ヶ月以上かつ週30時間以上の関与が見込まれる場合は、内部社員と同じオンボーディングプログラムや1on1ライン、評価フィードバックの仕組みに乗せると有効です。この「準内製化」ルールを導入すると、心理的安全性が高まり、改善提案や問題提起も活発になります。リモート前提でも、初週に対面合宿を行うと、関係構築のスピードを上げられます。
混乱期を2スプリント以内で抜ける手法
混乱期は、意図的に対立を起こすことで早期に通過させられます。最初の2スプリント以内に、技術選定や設計方針についてあえて議論を仕掛け、外部チームと内部チームの間で本音をぶつけ合う場を作ります。議論が長引いても結論に向かえるよう、RACI表に基づいて「最終的な意思決定者は誰か」を明確にしておきます。
KANNAのバックエンド開発チームでは、AIをドライバー、人間をナビゲーターとして配置するAIモブプロを導入しています。AIが叩き台を高速で生成し、人間のチーム全員でその設計の妥当性を議論します。こうして判断力の高速学習が進み、混乱期の対立を建設的な議論に変換することに成功しました。
SaaS企業の事例では、エンジニアとデザイナーに、PMとQAも加えた異職種モブを組みました。仕様書なしのレベルで設計が進み、認識ズレによる手戻りが激減したという報告もあります。こうしたモブプロは、外部チームを巻き込んでも、混乱期を短くする有効な方法になります。
散会期から逆算した契約設計とナレッジ移管
外部開発チームの発注で見落とされがちなのが、プロジェクト終了時の散会期です。契約期間が終わった途端に外部メンバーが離脱すると、暗黙知が一気に失われます。その結果、保守フェーズで誰も触れないシステムが残るケースが頻発します。
散会期から逆算して契約条項を設計すると、ナレッジを社内に確実に残せる体制を作れます。
ナレッジ移管条項の具体的な書き方
ナレッジ移管条項は、契約書本文に独立した章として設けることを推奨します。移管の対象と手段は、この章に具体的に書いておきます。
- 移管対象ドキュメントの種類と更新頻度
- 最終納品形式
- 移管期間中の対応工数
- 口頭での質疑応答セッションの実施回数
- ソースコードリポジトリのアクセス権の移譲手順
「プロジェクト終了の2ヶ月前から週1回、合計8回のナレッジ移管セッションをベンダー側が実施する」というレベルまで条項に書き込めば、終了間際の駆け込み対応を防げます。そのうえで、残す資料と終了後の質問対応も具体的に書き込みます。
- 設計ドキュメント、運用手順書、テスト仕様書、障害対応履歴を最新化した状態でリポジトリに格納する
- 主要モジュールごとに動画形式の説明資料(各15分以上)を残す
- 契約終了後3ヶ月間は、月10時間以内であれば質問対応に応じる
日立ハイテクノロジーズでは、設計書とテスト仕様の並行作成を徹底したことで、テスト項目漏れに起因する不具合の見逃しを11件から0件まで削減しました。現場アンケートでは、67%が漏れ防止の効果を実感したと報告されています。こうした整備は、外部チーム解散後の保守品質に直結します。
契約終了後の保守体制と知的財産
契約終了後の保守体制は、発注側で内製化するか、別のベンダーに移管するか、元のベンダーに保守契約を継続するかの3パターンに分かれます。どのパターンを選ぶにせよ、ソースコードの著作権やドキュメントの利用権を契約書で明確にしておく必要があります。第三者ライブラリのライセンス管理と、機密保持義務の存続期間も押さえておきます。
特に、保守期間中に発注側で改修を加える可能性があるなら、元ベンダー側のコードへの改変権を発注側に帰属させる条項が欠かせません。NECシステムテクノロジーでは、品質メトリクスを徹底し、年間バグ受付数を5年で約40%減、納期遅れを3年で約30%改善、生産性を約20%向上させました。
「100件のバグ目標に99件見つけてもまだ1件あると考え再レビューする」という独自の徹底文化が、成果に直結しています。外部チームとの契約終了後も、こうした品質メトリクスを計測し続けるには、計測ツールの利用権、データの所有権、運用ノウハウのマニュアル化までを契約書に盛り込むのが理想です。散会期の運用まで踏み込めば、プロジェクトを途切れさせず継続できる体制になります。
外部発注で失敗しないための実務ポイント
外部開発チームへの発注は、契約を交わした後の運用まで含めて考える必要があります。日々の運用で生じる細かな判断や、メンバーが入れ替わったときの対応、AIツール導入時の責任の再定義を押さえておくと、失敗の確率を大幅に下げられます。
RACI通りに動かないメンバーへの対応
RACI表を作っても、運用が始まると「ルール通りに動かないメンバー」が必ず出てきます。Accountableに指定された人物が責任を取らない、Responsibleの担当者が報告を怠る、Consultedの相談先が応答しないといった事象が起きることもあります。
そのため、こうした事象が起きたときの是正プロセスは、最初から段階的なエスカレーション手順として定めておくことが大切です。1段階目は当事者間の対話、2段階目は両社PMによる仲介、3段階目はステアリングコミッティへの上申という流れを契約書に明記しておくと、揉め事が長引くのを防げます。
外部チームは所属会社の上司との関係が絡むため、発注側が直接叱責すると関係が悪化するおそれがあります。そこで、事実に基づいて定量的に問題を示し、改善提案を添えたフィードバックを行う運用ルールを最初に共有すると、ベンダー側も建設的に応じやすくなります。さらに、月次の振り返り会(レトロスペクティブ)を合同で行い、KPTやFun/Done/Learnで改善活動に位置づけるのも有効です。
AIツール導入時の契約見直しポイント
外部チームがGitHub CopilotやAIレビュアーを業務に導入する際は、機密情報の取り扱いと、AIに学習されるリスクを契約書で見直す必要があります。加えて、生成コードの著作権と、ライセンス順守の責任の所在も再定義します。AIツールの導入前後では、品質メトリクスを並行して計測し、生産性と品質の変化を定量的に把握することが重要です。
条項の例には、発注側のソースコードが外部AIサービスの学習データに使われないことを保証する条項や、生成物の著作権が発注側に帰属することを明示する条項があります。ほかにも、AIが生成したコードに第三者ライブラリの一部が混入した場合の責任分担条項が該当します。AIをモブプロやペアプロに組み込むと、外部チームの生産性を一段引き上げられる可能性があります。
ソニーのPCアプリ開発(GDD)では、現場主導の改善活動で全体品質が60%向上し、ピアレビューの不具合検出率は1.92件/時と、一般的なコードインスペクションの値(約0.29件/時)の約6.6倍に達しました。ヤフオク!ではペアプロを質の高いレビューと再定義し、プルリク経由のレビューを廃止して本番ブランチに直接マージする運用で、約2年でリリース数増と残業減を両立させました。
まとめ
外部開発チームへの発注は、契約形態を選ぶところから始まり、RFPを作り込み、AI時代を踏まえてRACIを再定義する流れで進みます。そのうえで、混乱期を短くする立ち上げを設計し、散会期から逆算してナレッジ移管条項を整えることが、成功の鍵になります。
Accountableは絶対にAIや外部ベンダーには任せず、発注側の人間に残すという原則を守ります。さらに、One Boss原則で1タスク1名の説明責任者を厳格に定めると、責任の押し付け合いを防げます。
タックマンモデルの混乱期は飛ばせない前提で、最初の2スプリント以内に意図的な議論を仕掛けて短縮する、AIモブプロや異職種モブを活用して判断力を高速で蓄積する、といった具体策が有効です。また、散会期に向けては、ナレッジ移管セッションの頻度や、ドキュメントの納品形式、契約終了後のサポート時間まで条項に書き込み、保守フェーズでの困りごとを未然に防ぎます。
日立ハイテクノロジーズは不具合の見逃しを11件から0件に、NECシステムテクノロジーは年間バグ受付数を約40%減らしました。ソニーは品質を60%向上させ、ヤフオク!は残業減を実現しています。こうした定量的な事例が示すように、丁寧な設計は数字として成果に直結します。
RFP作成前に読みたい資料として、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」と「【2026年最新版】AI駆動開発の完全ガイドブック」を用意しています。
株式会社riplaは、コンサルティングから開発まで一気通貫で支援できるパートナーです。発注設計とRACIの再定義を一緒に進め、契約条項の整備からナレッジ移管まで、幅広く伴走しています。
外部リソースを内製チームと同等の品質で運用したい、AI時代の責任分担を再設計したい、散会期からの逆算で契約を組み立てたいというご相談がありましたら、ぜひお気軽にお問い合わせください。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。