専属開発チームの社外発注は、事前準備、契約、発注先の選定、発注後の立ち上げの4段階で進みます。
発注前の設計が甘いと、混乱期が長引いて初動の3カ月を失う、散会時にナレッジが残らない、AIツールを使いこなせず人月感覚から抜け出せないといった失敗が起こります。専属開発チーム構築の全体像は専属開発チーム構築の完全ガイドもあわせてご覧ください。
Webサービス開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。
- 発注前のRACI、スコープ、散会時の状態の設計
- 契約形態と、人月ベースから成果ベースへの移行
- 発注先の選定、RFP、提案評価、トライアル
- 発注後のオンボーディング、AIモブプロ、是正運用
専属開発チーム発注の事前準備
専属開発チームの発注では、いきなりベンダーに見積もりを出してもらうと、ほぼ失敗します。そこで、まず社内で決めておくべきことを整理します。
決めるべきことは、「どこまでを内製で持ち、どこから外部に任せるか」と「契約終了時にどの状態でチームを散会させたいか」の2点です。この2点を言葉にできているかで、発注スコープの精度が決まります。
発注前準備の中心に据えるのは、AI時代のRACI設計、タックマンモデルを前提としたオンボーディング設計、散会期から逆算したナレッジ設計の3つです。
AI時代のRACI再定義と発注スコープの言語化
専属開発チームの発注では、RACI（Responsible/Accountable/Consulted/Informed）を発注前に必ず作成します。RACIは、タスクごとに次の4つの役割を割り当てる仕組みです。
- 実行責任者（R）：タスクを実際に行う担当
- 説明責任者（A）：1タスクに必ず1名だけ置く（「One Boss原則」が鉄則）
- 相談先（C）：判断や助言を求める先
- 報告先（I）：結果を知らせる先
発注時点でAccountableを発注側と受注側のどちらに置くかが曖昧だと、不具合のときに責任の押し付け合いになります。AI時代のRACIで守るべき原則は、「AccountableをAIや受注側ベンダーに持たせない」ことです。
GitHub CopilotやAIコードレビューアはRやCに組み込めますが、説明責任は人間の発注側プロジェクトオーナーに残るため、AIをどのフェーズで使うかをRACI上で明示します。
発注スコープは、職位（役職）とロール（役割）を分けて書きます。
- 職位（役職）：人事上のグレードで、ジュニア/シニア/EM/VPoEなどを指す
- ロール（役割）：実務上の担当範囲で、PM/SE/プログラマー/QA/UI・UXデザイナーなどを指す
「シニアエンジニア2名」と書くより、ロールで定義してから職位を当てはめると、「ロールが揃わない」「Accountableが不在」という事態を防げます。
散会期から逆算したナレッジ移管設計
タックマンモデルでは、チームは「形成期 → 混乱期 → 統一期 → 機能期 → 散会期」の5段階で発展します。専属開発チームの発注で最も見落とされやすいのが、この最終段階の散会期から逆算する発想です。プロジェクトの終わり方を発注時に決めないと、契約満了時にナレッジが外部ベンダー側に集中し、社内に何も残らなくなります。
そこで、散会期の進め方として、「契約満了の3カ月前から並走期間を設ける」ことを発注スコープに明記します。並走期間中は、社内エンジニアと外部チームが同じスプリントに入り、ペアプロやモブプロでコードベースの構造と意思決定の背景を共有します。さらに、「アーキテクチャ意思決定記録（ADR）」と「ランブック」を、ベンダー側の納品物に含めます。
ADRには技術選定の理由を、ランブックには障害発生時の対処手順を残し、人ではなくドキュメントに知識を蓄積します。準内製化では、6カ月以上・週30時間以上関与する外部メンバーに、内部社員と同じオンボーディングと1on1の対象を適用します。そのため、心理的安全性と情報アクセス権を社員と揃える運用ルールを発注前に合意すると、契約終了時のナレッジ集中リスクが大きく下がります。
契約形態と人月ベース脱却の設計
専属開発チームの発注で最も悩むのが、契約形態の選択と単価設計です。「準委任か請負か」は、契約書の文言の問題にとどまらず、RACI上のAccountableをどちらに置くかという根本問題につながります。
さらに、AI活用が常態化した今、人月単価ベースの発注は実態と乖離します。そのため、成果ベースや成果KPI連動型への移行を、発注時に契約へ組み込むことが大切です。
準委任と請負の選び分けとRACIの整合
準委任契約は、「労務の提供」に対して報酬を支払う契約で、成果物の完成義務はベンダー側に課されません。要件が動くアジャイル前提の専属開発チームでは、準委任が標準です。ただし、準委任でもAccountable（最終的な完成責任）は発注側に残ります。
特に、発注側にPMやテックリードがいない状態で準委任を選ぶと、誰も全体に責任を持たないまま品質が崩れるリスクが高まります。一方、請負契約は「成果物の完成」に対して報酬を支払う契約で、完成責任と契約不適合責任がベンダー側に課されます。要件が固定されたウォーターフォール型や独立した単機能の開発で有効です。
6カ月〜数年の長期体制では、請負だと要件変更のたびに変更契約が必要になり、運用が硬直化します。そこで実務上の現実解は、体制全体を準委任で組み、独立性の高い納品物（インフラ構築一式、移行ツール開発など）だけを請負で切り出すハイブリッド契約です。そのうえで、準委任部分のAccountableは発注側PM、請負部分はベンダー側PMと明文化したRACI表を別紙で添付し、責任の境界を確定させます。
人月ベースから成果ベースへの脱却条項
人月単価による発注は、AIツール活用が前提の現在では実態と合わなくなっています。そこで、「1人月で何ができるか」ではなく「チームが1スプリントで何を決めたか」を成果の指標にします。たとえばKANNAのバックエンド開発では、AIがドライバー、人間がナビゲーターとなるAIモブプロが運用され、チーム全員で意思決定を行っています。
人月ベースを脱却する契約条項として、まず「ベロシティ連動型インセンティブ」を組み込みます。スプリントごとに完了したストーリーポイントの累積値が事前合意の目標を上回ると、ベンダー側に成功報酬が支払われます。実際に、学生インターン半数のチームでも、ペアプロ導入で平均ベロシティが18.8から22.0（117％）に向上しています。
次に、品質メトリクス連動型の条項を導入します。NECシステムテクノロジーはQMTX活用で年間バグ受付数を5年で約40％削減し、日立ハイテクノロジーズはF2T導入で、テスト項目漏れに起因する不具合の見逃しを11件から0件に改善しました。AI活用前提の生産性条項として、AI利用で工数が30％削減された場合の削減分の扱い（ベンダー側の利益、発注側への還元、半々）を明文化します。
内製と外注の切替閾値の定量化
専属開発チームを発注するときは、「どのロールを内製で抱え、どのロールを外注に出すか」の判断基準を明文化しておくことが大切です。「コア技術は内製、コモディティ領域は外部」というよくある切り分けは抽象的で、実務では使えません。そこで、現実的な判断基準として「採用市場で6カ月以内に充足できる職種かどうか」という、シンプルな閾値を使います。
具体的には、3つの観点でスコアリングします。一つ目の「採用充足可能性」は、6カ月以内に該当ロールを採用できる確率を経営陣が評価します。二つ目の「関与時間」は、月160時間以上の関与が必要なロールを内製化に寄せ、月40時間以下のスポット関与を外注に寄せます。
三つ目の「ナレッジ依存度」は、扱う情報が事業の核心に近いロールほど内製に寄せます。3つの観点でスコアリングし、合計点が一定値以上なら内製、未満なら外注とすることで、判断の属人化を避けられます。
発注先の選び方と評価方法
専属開発チームの発注先には、SIerやSES企業のほか、ラボ型開発会社、内製化支援企業、フリーランスエージェント、オフショアパートナーなど多様な選択肢があります。
得意領域と契約構造は大きく異なるため、自社のフェーズに合った発注先タイプを選ぶことが先決です。さらに、発注前のRFP段階で、AI時代に通用するベンダーかどうかを見抜く評価の観点を持つことが、選定の精度を決めます。
発注先タイプの整理と特徴
発注先は大きく5つに分類できます。第1のSIer・受託開発会社は、要件定義から運用まで一気通貫で支援できる反面、人月単価が高めで意思決定が硬直化しやすい傾向があります。第2のラボ型開発会社は、専属メンバーを月単位で確保できる契約形態で、長期の専属チーム発注に向いています。
第3の内製化支援企業は、社内エンジニアの採用・育成・体制構築を支援する企業で、最終的な内製化を見据えた専属チーム立ち上げに最適です。第4のフリーランスエージェント経由のチーミングは、必要なロールを個別に集めて準内製化する手法です。6カ月以上の関与を前提に1on1や評価面談を組み込むと、社員と同等の貢献を引き出せます。
第5のオフショア・ニアショアは、コストメリットがある反面、タックマンモデルの混乱期が長くなりやすく、ブリッジSEとコミュニケーションロスのコストを見込む必要があります。また、複数の発注先タイプを組み合わせるハイブリッド体制では、それぞれの責任境界を発注前にRACI上で確定させます。
AI時代のRFP設計と評価項目
発注先候補に提出するRFP（提案依頼書）には、AI時代特有の評価項目を組み込みます。まず「AIツール活用方針」の章を設け、Copilot・AIレビューア・AIモブプロの運用、AI生成コードのレビュー基準、情報セキュリティ上のAI利用ガイドラインを記述させます。AIに対する立場を明文化できないベンダーは、AI時代の開発現場に対応できていない兆候と捉えるべきです。
次に「混乱期短縮の具体策」の章を設けます。混乱期は飛ばせない前提で、短縮の方法論を提案させます。最初の2スプリント以内に意図的に対立を起こす設計、フルリモートの同期・非同期設計、ペアプロ／モブプロを混乱期短縮装置にする運用方針を、具体的に記述できるかを評価します。SaaS企業の事例のように異職種モブで設計してきたベンダーは、混乱期を短く抜けるノウハウを持つ可能性が高いです。
散会期設計の実績も確認します。契約満了時のナレッジ移管、ADRやランブックを残した実績、並走期間の設計を具体的に尋ねます。ヤフオク!開発チームのようにペアプロを「質の高いコードレビュー」と再定義してプルリクを廃止した運用や、ソニーのGDDで全体60％の品質向上を実現した実績のあるベンダーは、ナレッジを人ではなく仕組みに残す力があると判断できます。
提案評価とトライアル契約の進め方
提案評価では、価格点・技術点・体制点・カルチャー点の4観点で配点を分けます。価格点は人月単価ではなく、総額TCO（移管コスト・コミュニケーションロス・並走期間コスト込み）で比べます。技術点は、技術スライドや営業資料だけで判断せず、サンプルコードや過去のADRを実物として提出させて評価します。
体制点では、提案された専属メンバーの実在性と稼働可能性を確認します。「キーパーソンが他案件と兼務で実質稼働率50％」という事態が起きやすいため、稼働率の保証条項を契約書に明記します。カルチャー点は最も曖昧ですが、提案担当者と現場リーダーの両方と1on1を行い、心理的安全性、問題提起の文化、失敗時の振る舞いを聞き取ります。
本契約の前に、「2スプリント（4週間）のトライアル契約」を組み込むことを強く推奨します。トライアルでは、RACIの運用が機能するか、混乱期を短縮できるか、AI活用前提のスピードに追従できるかを実地で確認します。問題が見えた場合は本契約に進まず、別ベンダーに切り替えられる契約構造にしておくと、リスクを大きく下げられます。
発注後の立ち上げと混乱期短縮設計
契約締結後の最初の8週間が、専属開発チームの成否を決めます。タックマンモデルの混乱期は飛ばせない前提に立ち、いかに2スプリント以内に通過させるかが鍵です。
混乱期を放置すると形成期のまま3カ月が過ぎ、機能期に到達しないまま契約終了となるリスクが高まります。そこで、意図的に対立を引き起こす設計と、AIを使った判断力高速化の仕組みを発注時点で組み込みます。
混乱期を2スプリント以内で抜けるオンボーディング
形成期はチームが互いに様子を見ながら表面的な協力で動く期間で、ここで時間を浪費すると本音の議論が始まりません。そのため、発注後の第1スプリントの最初のレトロスペクティブに、意図的に「意見が分かれる議題」を置きます。たとえば「コードレビューを必須にすべきか、ペアプロ前提で廃止すべきか」のように、答えが一つに決まらない問いを投げ、対立を表面化させます。
第2スプリントでは、混乱期に出た論点を統一期へつなげます。次の4つのルールを「Working Agreement（チームの作業合意）」として全員で作り、毎月のレトロで見直します。
- コードレビュー：レビューの進め方
- コミュニケーション：チーム内の連絡の取り方
- 障害対応：障害が起きたときの動き方
- AIツール利用：使い方の取り決め
この対話の場を発注時点でスケジュールに組み込んでおくと、ベンダー側も「混乱期は通過必須」という前提で動けるため、形成期で止まらずに済みます。
外部メンバー向けの簡易オンボーディングでは、次の順で進めます。
- 1日目：内部社員と同じSlack、GitHub、Notionなどへのアクセス権を付与
- 2日目：1時間のセッションでアーキテクチャ全体像を共有
- 3〜5日目：ペアプロでコードベースに触れてもらう
- 1週目の終わり：レビューに参加できる状態を作る
準内製化を前提とする場合は、ウェルカムランチや雑談チャンネルにも初日から招待し、心理的安全性を築きます。
判断力獲得装置としてのAIモブプロ運用
AI時代のチーム強度は、コーディング速度ではなく「判断力の獲得速度」で決まります。AIが具体化サイクルを高速で回す前提では、人間チームが「この設計で課題が解けるか」「このコードは本番に出して良いか」を素早く決める必要があります。KANNAのバックエンドで運用された「AIがドライバー、人間がナビゲーター」のAIモブプロは、判断力の高速学習装置として機能した事例です。
発注後の最初の8週間では、AIモブプロを1日1〜2時間、チーム全員で行う時間を確保します。AIが叩き台を3分で生成し、全員で「この方向で合っているか」「この前提は妥当か」「セキュリティ的に問題ないか」を15分で議論します。これを1日10回繰り返すと、設計判断を1日100回経験することになり、チームの判断力が急速に蓄積されます。
SaaS企業のクロスファンクショナル・モブ事例では、エンジニア、デザイナー、PM、QAの異職種で設計したことで、仕様書なしレベルで設計が進み、認識ズレによる手戻りが激減しました。専属開発チームの発注後オンボーディングにこの異職種モブを取り入れると、職種間の前提共有が一気に進み、混乱期を超えた機能期で高い生産性を発揮できます。
RACI通りに動かないメンバーへの是正運用
RACIを作っても、ルール通りに動かないメンバーは必ず出ます。Accountableの人物が責任を取らない、Responsibleが期限を守らない、Consultedに入っているのに相談されないなど、現場では多様な不整合が起きます。こうした不整合を、契約条項の「段階的エスカレーション手順」に落とし込んでおくと、現場の混乱を最小化できます。
段階的エスカレーションは3レベルで設計します。レベル1は現場PMとの1on1での是正対話で、2週間以内にRACI通りの行動に戻るかを観察します。レベル2は発注側・ベンダー側双方のEMが介入する是正会議で、Working Agreementを再合意します。
最後のレベル3は、メンバー交代を含む人事判断で、ベンダー側に同等スキルのメンバーへの交代を依頼します。この3段階の手順を契約書または運用合意書に明記しておくと、感情論ではなく仕組みで運用できます。
まとめ
専属開発チームの発注を成功させる鍵は、AI時代に合わせたRACIを発注前に作り込み、タックマンモデルの混乱期を2スプリント以内で短縮し、散会期から逆算してナレッジを残す設計を組み込むことにあります。契約書の雛形を埋めるだけでは、この設計は組み込めません。
準委任と請負のハイブリッド契約、ベロシティ連動型インセンティブ、品質メトリクス連動型ペナルティ／インセンティブ、AI活用前提の生産性条項といった、人月ベースから脱却する条項を契約書に組み込みます。そうすることで、ベンダーと発注側が同じ方向を向いて成果を最大化できます。
日立ハイテクノロジーズの不具合見逃し11件→0件、NECシステムテクノロジーの年間バグ40％削減、ソニーの品質60％向上、ヤフオク!のリリース数増・残業減、学生インターン半数チームのベロシティ117％向上といった実証事例は、いずれもRACI、タックマンモデル、品質メトリクスを現場で運用しきった結果です。
発注前の設計と発注後の最初の8週間を丁寧に組み立てることが、専属開発チームの長期的な成果を決定づけます。
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を創業。