開発チームの発注は、発注前の準備からベンダー選定、契約形態の設計、PM/SMの確保、散会期からの逆算までを順に進めます。
- ステップ1：発注パターンと契約形態、責任の所在の整理
- ステップ2：RACIと役割の設計、発注前の意思決定の明確化
- ステップ3：PM・SMの確保と、外部統括ロールの条件の設定
- ステップ4：タックマンモデルを踏まえたオンボーディングの設計
- ステップ5：散会期からの逆算による、引き継ぎと動的契約の整備
人月単価の安いベンダーを選ぶだけでは決まらず、発注側は契約の使い分けや責任の所在、外部メンバーの受け入れまで決めておく必要があります。AI/コパイロットの台頭、フリーランス活用の一般化、フルリモート前提の働き方など、開発体制を取り巻く環境が変わるなかで、発注側に求められる責任設計のレベルは年々上がっています。
Webサービス開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。
開発チーム構築の発注・外注・委託の全体像
開発チーム構築の発注は、ベンダーに実装作業を任せる業務委託というより、自社の内製組織と外部リソースを一つのチームとして機能させる「組織設計の外注」に近いものです。そのうえで発注側は、採用市場の充足可能性、関与時間、ナレッジ依存度の3軸で、内製と外注の境界を引き直します。
外部メンバーが内部社員と同じレベルでチームに溶け込めるよう、オンボーディングや心理的安全性、1on1の運用ルールを設計する必要があります。
発注対象は職種別に明確にします。PM（プロジェクトマネージャー）、SM（スクラムマスター）、SE、プログラマー、QA、UI/UXデザイナーといった実務上のロールと、ジュニア/シニア/EM/VPoEといった職位を切り分けます。その切り分けをもとに、どの粒度で外部に委託するかを設計します。
AI時代には、AIプロンプトエンジニアやAI統括ロールを置く構成も増えています。また、Copilotやレビュー支援AIをRACI上のR（実行）やC（相談先）に位置づける発注設計が、現実解として広がっています。
発注パターンと契約形態の使い分け
開発チームの発注パターンは大きく3種類に分けられます。1つ目は、ベンダーに開発会社をまるごと借りるラボ型・準委任契約です。2つ目は、要件と納期を確定させて成果物を発注する請負契約、3つ目は、フリーランスや個人事業主に職能単位で発注するスポット契約です。
準委任は、仕様変更が多い不確実な領域や、内製チームと混成で動かしたい場面に適しています。一方で請負は、要件が固まっていて、Accountableをベンダー側に明確に委ねられる場面で選ばれます。また、混合運用する場合は、機能単位や工程単位で契約モデルを切り分け、契約書とRACI表を突き合わせて確認します。
契約形態の選択は、後述するRACI設計と一体で考える必要があります。請負契約ではベンダー側にA（Accountable）が寄りやすく、準委任契約では発注側にAが残ります。そのため、「Accountableは1タスクにつき1名のみ（One Boss原則）」を守るには、契約形態とRACIの粒度を同時に設計しなければなりません。
内製と外注の切替閾値（採用市場・関与時間・ナレッジ依存）
「コアは内製、手足は外注」というスローガンは抽象的で、現場の発注判断には使いにくいのが実情です。そこで、実務に耐える切替閾値を3軸で測ります。第1に採用市場での充足可能性（6ヶ月以内に正社員で採用できる職種か）、第2に関与時間（週30時間以上か未満か）、第3にナレッジ依存度（独自ドメイン知識を持たないと判断できないか）です。
3軸のうち2軸以上が「外部依存OK」に振れる職種は、外注で問題なく進められます。一方、2軸以上が「内製必須」なら、採用に時間をかけてでも内製化を狙います。特に注意したいのは、6ヶ月以上かつ週30時間以上関与する外部人材です。
このゾーンに入る外部人材は実態としてチームの一員であり、内部社員と同等のオンボーディング、1on1、人事評価ラインに乗せる「準内製化」運用が必要です。契約上は外部でも、運用上は内製と同じ枠組みで扱う発想がないと、心理的安全性の格差からエンゲージメントが落ち、属人化と退職リスクが連鎖的に高まります。
発注前に準備すべきRACIと役割設計
発注前に最も重要な作業は、自社内のRACI（Responsible/Accountable/Consulted/Informed）を確定させることです。
RACIは、「誰が手を動かすか」「誰が説明責任を負うか」「誰に相談するか」「誰に共有するか」を1タスクごとに定める責任分担表です。Accountableは1タスクにつき必ず1名だけ置くという、One Boss原則が前提になります。
発注前にRACIを固めずに見積依頼を送ると、見積りに含まれる範囲がベンダーごとに大きく異なります。その結果、後工程で責任の押し付け合いが多発します。
AI時代のRACI再定義（Accountableは人間のみ）
GitHub CopilotやAIレビュー支援ツールが標準装備となった現在、従来のRACIをそのまま使い続けると、責任の所在が曖昧になります。AI時代の再定義原則はシンプルで、「Accountable（説明責任）はAIに持たせず、必ず人間が負う」ことが大前提となります。AIはR（実行）やC（相談先）には入れても、Aには置きません。
コード生成、初稿レビュー、テストケース生成といった具体作業は、AIをR/Cに据えて高速化します。一方で最終的な品質責任は、人間のシニアエンジニアやリードに集約するため、発注書や仕様書でもAIの利用範囲を明文化することが推奨されます。
たとえば、「設計レビューでコード生成AIをC（相談先）として使う」「ただし、最終的な品質のAccountableは発注先のテックリードが負う」という条項を契約書に入れておくと、後工程のトラブルを防げます。特に外注先が社内ガイドラインを持っていない場合は、発注側がAI利用範囲とRACI上の位置づけを提示する責任を負います。
3階層意思決定モデル（戦略・戦術・実行）
発注規模が大きくなるほど、意思決定の階層を意図的に設計する必要が出てきます。戦略レベルはステアリングコミッティが担当し、プロジェクトのスコープ拡大、予算追加、方向転換を意思決定します。戦術レベルはPMが担当し、スプリント計画、優先順位、リスク管理を判断します。
実行レベルは現場が担当し、技術選定、実装方針、日々の品質判断を行います。3階層の境界を明文化せずに発注すると、現場に丸投げするか過剰に介入するかのどちらかに振れ、コストか品質のいずれかが破綻します。
そのため発注書には、階層ごとの意思決定権限を必ず書き込みます。たとえば「予算30%超過の判断はステアリング、スプリント内の優先順位入れ替えはPM、技術スタック内の細部選択は現場テックリード」というように、具体的な閾値と権限境界を明示します。境界が曖昧な領域は、意図的にPM階層に集約して、現場の判断疲弊を防ぎます。
PM・SMの発注と外部統括ロールの設計
開発チームの発注で最も難易度が高いのは、エンジニアではなく、PM（プロジェクトマネージャー）とSM（スクラムマスター）の確保です。
実装メンバーは比較的市場流動性が高く、外注で埋めやすい一方で、PM・SMには事業ドメインの理解、社内政治のナビゲーション、ベンダーマネジメントを兼ね備える必要があります。そのため、外注で確保するのが難しいロールとなります。
発注前に、PM・SMを自社内で確保するか、シェアードPM型で外部から借りるかを確定させることが、プロジェクト立ち上げの成否を分けます。
シェアードPM・外部PMを借りる場合の発注条件
シェアードPM（複数プロジェクト兼務型）を外部から借りる場合は、稼働率を明確にすることが必須です。週30時間未満の関与でPMロールを担わせると、意思決定が遅れ、現場が独自判断で動いてしまう「PM空洞化」が起こります。
発注側は、次の2点を契約と体制に組み込みます。
- 稼働コミット：「最低稼働40%、定例参加率100%、緊急時の即応SLA48時間以内」などの定量的な条件を契約書に書き込む
- 意思決定への導線：外部PMが自社のステアリングコミッティに直接アクセスできる経路を整備する
PM・SMを外部発注するもう1つの選択肢は、開発会社のラボ型契約に「PMロール込み」で含めるパターンです。この場合、「PMの説明責任の範囲」を契約書に明記しないと、PMが自社の利益（追加見積を取りやすくする）に動いてしまうリスクが残ります。
発注側は、「PMはプロジェクトの全体利益に対してAccountableを負う」「自社の追加売上を優先しない」旨を契約条項に書き、第三者によるレトロスペクティブで定期的に検証します。
EM/VPoEは内製、SMは外注可という現実解
EM（エンジニアリングマネージャー）とVPoEは、自社の人事評価、キャリア設計、採用方針を握るロールのため、原則として外注できません。一方でSM（スクラムマスター）は、アジャイル運用のファシリテーションが中心のため、外部のアジャイルコーチや認定スクラムマスター（CSM）を時限的に外注する選択肢が現実的です。
立ち上げから6ヶ月程度はベテランSMを外部から借りてチームを整え、その後は内部メンバーにSM役を移譲する設計が、多くの企業で採られています。SMを外注する際は、「SMは技術的決定権を持たない」というルールを明文化することが注意点です。
SMがプロセスの司会者として優秀でも、技術選定やアーキテクチャ決定に踏み込むと、本来Accountableを負うべきテックリードの権限を侵食します。そのため発注書には、「SMはプロセスの最適化と障害除去に責任を持ち、技術判断はテックリードに帰属させる」と明記し、職務境界を明確にします。
タックマンモデルにおける混乱期短縮の発注設計
外部チームと内部社員の混成編成では、タックマンモデルの「形成期 → 混乱期 → 統一期 → 機能期 → 散会期」のうち、混乱期をいかに短縮するかが発注成功の最大要因となります。混乱期は必ず通過するフェーズで、スキップはできません。
そこで、混乱期に意図的に小規模な対立を起こさせ、最初の2スプリント以内に通過させる設計が現実解となります。さらに、発注書には「立ち上げから2週間以内に、外部メンバーを含む全員参加のキックオフ・ワークショップを実施する」旨を明記します。
意図的に対立を起こす「短縮型キックオフ」
混乱期の短縮には、最初のスプリントで「全員参加の技術選定議論」を意図的に設定し、外部メンバーにも遠慮なく異論を出してもらう場を作るコツがあります。表面的に「仲良くスタート」しようとすると、潜在的な対立が水面下に残り、機能期に入ってから爆発する事態を招きます。
発注側は、初週の進め方を次のとおりベンダーと取り決めます。
- 方針の共有：初週の議論で対立を歓迎する方針を、事前にベンダーへ伝えます。
- 本音の扱い：対立がない場合は、本音を言えていない兆候として扱う運用を決めておきます。
- 心理的安全性の閾値：どこまでの異論を許容するかの基準を明示します。
- ペアプロ・モブプロ：混乱期短縮の有効な装置となります。
SaaS企業のクロスファンクショナル・モブ事例では、エンジニア・デザイナー・PM・QAの異職種モブで設計議論を行った結果、仕様書なしレベルで設計が進み、認識ズレによる手戻りが激減したという実証があります。学生インターン半数のチームでペアプロを導入した事例では、平均ベロシティが18.8から22.0（117%）まで向上しました。
発注書には導入計画と工数を明記し、初期の混乱期投資としてベンダーと合意します。
外部人材のオンボーディング設計
準内製化の対象となる外部人材（6ヶ月以上・週30時間以上）には、内部社員と同等のオンボーディングを設計します。具体的には、初日のウェルカムミーティング、初週の1on1（PMと直属リード）、初月のメンター制度を経て、3ヶ月目のフィードバック面談まで、内部社員と同じ枠組みで行います。
発注書には「外部メンバーも内部メンバーと同等のオンボーディングプロセスに参加させる」旨を明記し、ベンダー側にもこの運用への協力を契約条項で求めます。外部メンバーの心理的安全性も、発注時に詰めておきます。
リモート前提のチームでは、雑談から生まれる学習機会が減るため、「雑談チャンネル」「週1の非業務テーマMTG」「気軽な質問用のテキストチャネル」を意図的に設計します。発注書のスコープには書きにくいものの、ベンダーへのSOW（Statement of Work）の運用ルール欄に書けば、ベンダー側のメンバーにも周知できます。
散会期から逆算する契約設計とナレッジ移管
発注で見落とされがちなのが、タックマンモデルの最終フェーズである「散会期」からの逆算です。プロジェクト終了時に外部チームが解散した瞬間、属人化していたナレッジが一気に消え、運用フェーズで品質が急落するケースが頻発します。
そのため、発注時点で散会期を見据え、ドキュメント、暗黙知の蓄積方針、契約終了時の引き継ぎ責任を契約書に組み込む発想が必要です。これを怠ると、契約終了後に追加コストでベンダーを再雇用せざるを得ず、総コストが想定の2倍以上に膨らむ事態を招きます。
契約終了時の引き継ぎ条項とドキュメント納品
契約書には「契約終了時の引き継ぎ責任」を必ず明文化します。具体的には、ADR（アーキテクチャ・デシジョン・レコード）と運用ランブックなど、運用フェーズで必要となるものを納品物リストに含めます。また、オンコール手順書、テストケース一覧、依存ライブラリのバージョン管理表も納品物に含めます。
引き継ぎの工数も発注時点で見積もり、契約終了の1〜2ヶ月前から段階的にナレッジ移管を進める設計とします。引き継ぎの完了を検収条件に含めるのが、発注側にとって最も安全な契約形態です。暗黙知の移管はドキュメントだけでは不十分なため、可能であれば契約終了の2ヶ月前から、内部社員と外部メンバーのペアプロ・モブプロを集中投下し、暗黙知を直接転送します。
ヤフオク!の開発チーム事例では、ペアプロを「質の高いコードレビュー」と再定義しました。プルリク経由のレビューを廃止して本番ブランチに直接マージするという思い切った運用を採用し、導入から約2年でリリース数増・残業減を達成しています。また、引き継ぎフェーズでも、この発想を応用してペアプロを暗黙知の伝達装置として位置づけます。
人員入れ替わりを前提とした動的契約
長期プロジェクトでは、外部メンバーの入れ替わりが必ず発生します。新規メンバーが参画するたびに「形成期/混乱期」に戻る現象（リフォーミング）が起き、ベロシティが一時的に落ちます。
そのため発注書には、「メンバー入れ替わり時の引き継ぎ工数」「新規参画メンバーのオンボーディング工数」「ベロシティ低下を許容する移行期間」を見積もりに含め、ベンダー側と事前に合意します。これらを予算化していないと、入れ替わりのたびに発注側がコストを追加で負担する、不公平な構造になりがちです。
動的な人員管理には、ローテーションルールも必要です。たとえば「特定メンバーへの依存度が30%を超えたら、強制的にナレッジ共有セッションを行う」「主要担当者の連続休暇を年1回必須化し、属人化を検出する」といったルールがあります。これを発注書に書き込み、リスクの早期発見を仕組み化します。
品質改善KPIと連動した発注運用
発注後の運用フェーズでは、品質改善KPIを契約に組み込み、ベンダーの動機を発注側のゴールと一致させます。単なる人月単価×時間の契約だと、ベンダーは「指示どおり動く」インセンティブしか持たず、品質向上に主体的に取り組む動機が薄くなります。
そこでKPI連動型の契約では、報酬と指標を連動させ、品質改善の上振れをベンダー側に還元する仕組みを設計します。指標には、不具合検出率、出荷後欠陥数、ベロシティ向上率などを使います。
定量事例で見るKPI連動の効果
品質改善KPIを徹底した企業事例は、契約交渉の説得材料としても有効です。日立ハイテクノロジーズではF2T導入により、設計書とテスト仕様の並行作成を進めました。テスト項目漏れに起因する不具合の見逃しを11件から0件まで削減し、現場アンケートでは67%が漏れ防止効果を実感したと報告しています。
NECシステムテクノロジーではQMTX活用により、年間バグ受付数を5年で約40%減、納期遅れを3年で約30%改善、生産性を約20%向上させています。「100件のバグ目標に99件見つけてもまだ1件あると考え再レビューする」という徹底文化が、定量効果を生んでいます。ソニーのPCアプリ開発（GDD）では、現場主導の改善で品質が全体60%向上しました。
ソニーのピアレビューの不具合検出率は1.92件/時で、一般的なコードインスペクション値（約0.29件/時）の約6.6倍を達成しました。さらに、住友電気工業ではデータ中心設計で開発コスト30%削減、組立型開発でCOBOL比約3倍の生産性向上、出荷後欠陥数も半減しています。これらを参考KPIとしてベンダーに示し、同水準の改善を目標に契約条項へ書き込むのが現実的です。
KPI連動契約と是正プロセスの組み込み
KPI連動契約では、報酬の一定割合（一般的には10〜20%）を成果連動部分に切り分け、品質指標の達成度に応じて支払います。指標は3〜5個に絞り、不具合密度、リードタイム、デプロイ頻度、MTTR、ベロシティなど、定量測定できるものを採用します。指標を増やしすぎると測定コストが膨らむため、ベンダー側の数字合わせを防ぎつつ、本質的な少数の指標に集中させます。
RACIが守られないメンバーへの是正プロセスも、発注時に明文化します。「Accountableが説明責任を果たさない」「期日どおりに動かない」「コミットメントが守られない」といった逸脱が起きた際、誰がいつ介入するかを段階的なエスカレーションとして設計します。第1段階はPMからの口頭フィードバック、第2段階はEMからのフォーマル指摘です。
第3段階では、ベンダー側マネジメントへの正式報告と是正計画書の提出を求め、第4段階では契約条項に基づくメンバー入れ替え要請を行います。この4段階を契約書に書き込むのが、標準的な形です。
まとめ
開発チームの発注・外注・依頼・委託は、単なるリソース調達ではなく、組織設計の外注として捉え直す必要があります。
AI時代のRACI再定義では、「Accountableは人間のみ」を原則とし、AIはR（実行）やC（相談先）に位置づけることで、責任の所在を明確にします。
タックマンモデルの混乱期はスキップできませんが、2スプリント以内に短縮する設計は可能です。そのためには、意図的な対立と、ペアプロ・モブプロの集中投下が有効です。
散会期からの逆算契約では、引き継ぎフェーズの工数、ナレッジ移管、人員入れ替わりへの動的対応を、発注時点で契約書に組み込んでおくことが、運用フェーズの破綻を防ぐ最大の予防策となります。
PM・SMの発注では、シェアードPMの稼働コミット、SMの職務境界の明文化、EM・VPoEの内製維持という現実解を採用します。さらに、品質改善KPIと連動した契約によって、日立の11→0件、NEC40%減、ソニー60%向上といった実証事例と同水準の改善を狙います。
これらを発注前のRACI設計、契約条項、運用ルールに反映させることで、外部チームを発注しながらも、自社の中核能力として蓄積する開発体制を実現できます。
▼RFP作成前に読みたい無料ホワイトペーパーはこちらをご覧ください。
・Webサービス開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブックをご覧ください。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。