専属開発チーム構築の発注/外注/依頼/委託方法について

専属開発チームを社外パートナーへ発注したい、あるいは外部リソースをハイブリッドに組み合わせて自社の専属チームを立ち上げたいと考える企業が増えています。しかし、いざ発注となると「契約形態は準委任と請負のどちらにすべきか」「RACI上のAccountableを発注側と受注側でどう線引きするか」「人月単価以外に何を見て選ぶべきか」など、判断を迫られる論点が一気に押し寄せます。発注前の設計が甘いと、混乱期が長引いて初動の3カ月を失う、散会時にナレッジが残らない、AIツールを使いこなせず人月感覚から脱却できない、といった失敗が起こります。

本記事では、AI時代に最適化したRACIの再定義、タックマンモデルの混乱期を2スプリント以内に短縮する設計、散会期から逆算した発注スコープ設計、人月ベースから成果ベースへ脱却するための契約条項まで、専属開発チーム発注のハウツーを実務レベルで解説します。専属開発チーム構築の全体像については、専属開発チーム構築の完全ガイドもあわせてご参照ください。

専属開発チーム発注の事前準備

専属開発チームの発注は、いきなりベンダーに見積もりを出すところから始めるとほぼ失敗します。発注前にまず「どこまでを内製で持ち、どこから外部に任せるか」「契約終了時にどの状態でチームを散会させたいか」を言語化することが、発注スコープの精度を決定づけます。AI時代のRACI設計、タックマンモデル前提のオンボーディング設計、そして散会期から逆算したナレッジ設計の3点を、発注前準備の核として進めましょう。

専属開発チームの発注では、RACI（Responsible/Accountable/Consulted/Informed）を発注前に必ず作成します。RACIとは、タスクごとに「実行責任者（R）」「説明責任者（A）」「相談先（C）」「報告先（I）」を割り当てるフレームワークで、Accountableは1タスクにつき必ず1名のみという「One Boss原則」が鉄則です。発注時にAccountableを発注側に置くのか受注側に置くのかが曖昧だと、不具合発生時に責任の押し付け合いが起こります。

AI時代のRACIにおいて押さえるべき原則は、「AccountableはAIや受注側ベンダーに持たせない」というガードレールです。GitHub CopilotやAIコードレビューアはR（実行）やC（相談先）には組み込めますが、説明責任は人間の発注側プロジェクトオーナーに残します。たとえばAIが生成したコードが本番障害を起こしたとき、「AIが書いたからAIの責任」とは説明できません。発注前にAIをどのフェーズで使うかをRACI上で明示し、責任所在を曖昧にしないことが、AI時代の発注設計のスタート地点になります。

発注スコープを言語化するときは、職位（役職）とロール（役割）を分けて記述します。役職はジュニア/シニア/EM（エンジニアリングマネージャー）/VPoEといった人事上のグレードを指し、ロールはPM/SE/プログラマー/QA/UI・UXデザイナーといった実務上の担当範囲を指します。専属チーム発注では「シニアエンジニア2名」と書くのではなく「フロントエンドのシニアR、バックエンドのシニアR、QAのR、PMのA（兼テックリード）」のように、ロールベースで定義してから職位を当てはめることで、発注後に「ロールが揃わない」「Accountableが不在」という事態を防げます。

タックマンモデルでは、チームは「形成期 → 混乱期 → 統一期 → 機能期 → 散会期」の5段階で発展します。専属開発チームを発注するときに最も見落とされるのが、最終段階の散会期から逆算する発想です。プロジェクトの終わり方を発注時に決めておかないと、契約満了時に外部ベンダー側にナレッジが集中し、社内に何も残らないという事態が起こります。

散会期設計の具体的な進め方として、まず「契約満了の3カ月前から並走期間を設ける」ことを発注スコープに明記します。並走期間中は、社内エンジニアと外部チームが同じスプリントに入り、ペアプロやモブプロでコードベースの構造と意思決定の背景を共有します。次に、「アーキテクチャ意思決定記録（ADR）」と「ランブック」をベンダー側の納品物に含めます。ADRには「なぜこの技術選定にしたか」を、ランブックには「障害発生時の対処手順」を残し、人ではなくドキュメントに知識を蓄積します。

もうひとつ重要なのが、「準内製化」運用ルールの事前合意です。6カ月以上・週30時間以上関与する外部メンバーは、内部社員と同じオンボーディングを受け、1on1の対象に含めます。心理的安全性と情報アクセス権を内部社員と同水準に揃えることで、外部メンバーが安心して問題提起できる環境を作ります。この準内製化ルールを発注前に合意できていれば、契約終了時のナレッジ集中リスクが大きく下がります。

契約形態と人月ベース脱却の設計

専属開発チームの発注で最も悩むのが、契約形態の選択と単価設計です。「準委任か請負か」は単なる契約書の文言ではなく、RACI上のAccountableをどちらに置くかという根本問題に直結します。さらにAI活用が常態化した現在、人月単価ベースの発注は実態と乖離するため、成果ベースや成果KPI連動型への移行を発注時に組み込むことが重要になります。

準委任契約は「労務の提供」に対して報酬を支払う契約形態で、成果物の完成義務はベンダー側に課されません。専属開発チームのように、要件が動的に変わるアジャイル前提のプロジェクトでは準委任が標準です。ただし準委任ではAccountable（最終的な完成責任）は発注側に残ります。発注側にPMやテックリードがいない状態で準委任を選ぶと、誰も全体に責任を持たないまま開発が進み、品質が崩壊するリスクが高まります。

請負契約は「成果物の完成」に対して報酬を支払う契約で、完成責任と契約不適合責任がベンダー側に課されます。要件が固定されたウォーターフォール型プロジェクトや、独立した単機能の開発で有効です。一方で専属開発チームのように6カ月〜数年にわたって関わる長期体制では、請負契約は要件変更のたびに変更契約が必要となり、運用が硬直化します。

実務上の現実解は、ハイブリッド契約です。プロジェクト全体の体制は準委任で組み、特定の独立性が高い納品物（たとえばインフラ構築一式、移行ツール開発など）だけを請負で切り出します。このとき発注前に「準委任部分のAccountableは発注側PMが担う」「請負部分のAccountableはベンダー側PMが担う」と明文化したRACI表を契約書の別紙として添付することで、責任の境界を確定させます。

人月単価による発注は、AIツール活用が前提となった現在では実態と合わなくなっています。たとえばKANNAのバックエンド開発では「AIがドライバー、人間がナビゲーター」という形のAIモブプロが運用されており、AIが叩き台を高速生成して人間チーム全員で意思決定を行う形式に変わりました。この体制下では「1人月で何ができるか」よりも「チームとして1スプリントで何の意思決定をしたか」が成果指標になります。

人月ベースを脱却するための具体的な契約条項として、まず「ベロシティ連動型インセンティブ」を組み込みます。スプリントごとに完了したストーリーポイントの累積値が事前合意した目標を上回った場合、ベンダー側に成功報酬が支払われる仕組みです。学生インターン半数のチームでもペアプロ導入で平均ベロシティが18.8から22.0（117％）に向上した実例があり、ベロシティはチーム成果を測る現実的な指標として機能します。

次に、「品質メトリクス連動型ペナルティ／インセンティブ」を導入します。NECシステムテクノロジーがQMTX活用で年間バグ受付数を5年で約40％削減した実例のように、品質メトリクスを定義して契約条項に組み込むと、ベンダー側にも品質向上のインセンティブが生まれます。日立ハイテクノロジーズではF2T導入によりテスト項目漏れに起因する不具合の見逃しが11件から0件に改善した事例もあり、こうした数値目標を発注時に明文化することで、人月単価では測れない品質貢献を評価できるようになります。

さらに、「AI活用前提の生産性条項」も追加します。GitHub Copilot等のAIツールを使うことで生まれた生産性向上を、発注側とベンダー側でどう配分するかを事前合意します。AI利用で工数が30％削減された場合、その削減分をベンダー側の利益にするのか、発注側にコスト還元するのか、半々で分けるのかを明文化することで、AIツール導入のインセンティブを双方に持たせます。

専属開発チームを発注するとき、「どのロールを内製で抱え、どのロールを外注に出すか」の判断軸を明文化することが重要です。「コア技術は内製、コモディティ領域は外部」というよくある切り分けは抽象的で、実務では使えません。現実的な判断軸は「採用市場で6カ月以内に充足できる職種かどうか」というシンプルな閾値です。

具体的な判定の進め方として、3つの軸でスコアリングします。第1の軸は「採用充足可能性」で、6カ月以内に該当ロールを採用できる確率を経営陣で評価します。第2の軸は「関与時間」で、月160時間以上の関与が必要なロールは内製化に寄せ、月40時間以下のスポット関与は外注に寄せます。第3の軸は「ナレッジ依存度」で、そのロールが扱う情報が事業の核心に近いほど内製に寄せます。3軸でスコアリングし、合計点が一定値以上なら内製、未満なら外注とすることで、判断の属人化を避けられます。

発注先の選び方と評価方法

専属開発チームの発注先は、SIerやSES企業だけでなく、ラボ型開発会社、内製化支援企業、フリーランスエージェント、オフショアパートナーなど多様な選択肢が存在します。それぞれ得意領域と契約構造が大きく異なるため、自社のフェーズに合った発注先タイプを選ぶことが先決です。さらに発注前のRFP段階で、AI時代に通用するベンダーかどうかを見抜く評価軸を持つことが、選定精度を決めます。

発注先は大きく5つに分類できます。第1のSIer・受託開発会社は、要件定義から運用までを一気通貫で支援できる反面、人月単価が高めで意思決定が硬直化しやすい傾向があります。第2のラボ型開発会社は、専属メンバーを月単位で確保できる契約形態で、長期の専属チーム発注に向いています。第3の内製化支援企業は、社内エンジニアの採用・育成・体制構築を支援する企業で、最終的な内製化を見据えた専属チーム立ち上げに最適です。

第4のフリーランスエージェント経由のチーミングは、必要なロールを個別に集めて準内製化する手法で、6カ月以上の関与を前提に1on1や評価面談を組み込むと、社員と同等の貢献を引き出せます。第5のオフショア・ニアショアは、コストメリットがある反面、タックマンモデルの混乱期が長くなりやすく、ブリッジSEとコミュニケーションロスのコストを見込む必要があります。複数の発注先タイプを組み合わせる「ハイブリッド体制」を取る場合は、それぞれの責任境界を発注前にRACI上で確定させましょう。

発注先候補に提出するRFP（提案依頼書）には、AI時代特有の評価項目を組み込みます。まず「AIツール活用方針」の章を設け、Copilot・AIレビューア・AIモブプロをどう運用するか、AIが生成したコードのレビュー基準は何か、情報セキュリティ上のAI利用ガイドラインをどう設定するかを記述させます。AIに対する立場を明文化できないベンダーは、AI時代の開発現場に対応できていない兆候として捉えるべきです。

次に「混乱期短縮の具体策」の章を設けます。タックマンモデルの混乱期は飛ばせない前提で、各ベンダーがどう短縮するかの方法論を提案させます。最初の2スプリント以内に意図的に対立を起こす設計、フルリモート前提の同期・非同期コミュニケーション設計、ペアプロ／モブプロを混乱期短縮装置として使う運用方針などを具体的に記述できるかを評価します。SaaS企業のクロスファンクショナル・モブ事例のように、異職種モブで設計してきた経験を持つベンダーは、混乱期を短く抜けるノウハウを持っている可能性が高いです。

3つ目に「散会期設計の実績」を尋ねます。過去のプロジェクトで契約満了時にどのようなナレッジ移管を行ったか、ADRやランブックを残した実績があるか、社内エンジニアとの並走期間をどう設計したかを具体的に確認します。ヤフオク!開発チームのようにペアプロを「質の高いコードレビュー」と再定義してプルリクを廃止した運用や、ソニーのGDDで全体60％の品質向上を実現した現場主導改善活動の実績があるベンダーは、ナレッジを人ではなく仕組みに残す力があると判断できます。

提案評価では、価格点・技術点・体制点・カルチャー点の4観点で配点を分けます。価格点は人月単価ではなく総額TCO（移管コスト・コミュニケーションロス・並走期間コスト込み）で比較します。技術点はサンプルコードや過去のADRを実物として提出させて評価し、技術スライドや営業資料だけで判断しないようにします。

体制点では、提案された専属メンバーの実在性と稼働可能性を確認します。専属チームの発注では「キーパーソンが他案件と兼務で実質稼働率50％」という事態が起きやすく、稼働率の保証条項を契約書に明記しましょう。カルチャー点は最も曖昧で評価が難しい項目ですが、提案担当者と現場リーダーの両方に1on1の場を設けて、心理的安全性の捉え方・問題提起の文化・失敗時の振る舞いをヒアリングします。

本契約の前に「2スプリント（4週間）のトライアル契約」を組み込むことを強く推奨します。トライアル期間中にRACIの運用が機能するか、混乱期を短縮できるか、AI活用が前提のスピード感に追従できるかを実地で確認します。トライアルで問題が見えた場合は本契約に進まず、別ベンダーに切り替えられる契約構造を作っておくと、リスクを大きく下げられます。

発注後の立ち上げと混乱期短縮設計

契約締結後の最初の8週間が、専属開発チームの成否を決めます。タックマンモデルの混乱期は飛ばすことができない前提に立ち、いかに2スプリント以内に通過させるかが鍵です。混乱期を放置すると形成期のまま3カ月が過ぎ、機能期に到達しないまま契約終了となるリスクが高まります。意図的に対立を引き起こす設計と、AIを使った判断力高速化の仕組みを発注時点で組み込みましょう。

形成期はチームが互いに様子を見ながら表面的な協力で動く期間で、ここで時間を浪費すると本音の議論が始まりません。発注後の第1スプリントでは、意図的に「意見が分かれる議題」を最初のレトロスペクティブに置きます。たとえば「コードレビューを必須にすべきか、ヤフオク!のようにペアプロ前提で廃止すべきか」「AIが生成したコードのレビュー粒度はどこまで人間が担保するか」など、答えが一つに決まらない問いを投げ、対立を表面化させます。

第2スプリントでは、混乱期に出てきた論点を統一期へつなげる対話を設計します。Working Agreement（チームの作業合意）を全員で作り、コードレビュー・コミュニケーションルール・障害対応フロー・AIツール利用ガイドラインを明文化します。Working Agreementは1度作って終わりではなく、毎月のレトロで見直すサイクルを回します。この対話の場を発注時点でスケジュールに組み込んでおくと、ベンダー側も「混乱期は通過必須」という前提で動くため、形成期で停滞せずに済みます。

外部メンバー向けの簡易オンボーディングも重要です。1日目に内部社員と同じSlackチャンネル・GitHubリポジトリ・Notion等のドキュメント基盤へのアクセス権を付与し、2日目に既存システムのアーキテクチャ全体像を1時間のセッションで共有します。3〜5日目はペアプロを通じてコードベースに触れてもらい、1週目の終わりにはレビューに参加できる状態を作ります。準内製化を前提とする場合は、内部社員と同じウェルカムランチや雑談チャンネルにも招待し、心理的安全性を初日から構築します。

AI時代のチーム強度は、コーディング速度ではなく「判断力の獲得速度」で決まります。AIが具体化サイクルを高速で回す前提では、人間チームは「この設計で課題が解けるか」「このコードは本番に出して良いか」を高速で意思決定する必要があります。KANNAのバックエンドで運用された「AIがドライバー、人間がナビゲーター」スタイルのAIモブプロは、まさに判断力の高速学習装置として機能した事例です。

発注後の最初の8週間では、AIモブプロを1日1〜2時間、チーム全員で行う時間を確保します。AIが叩き台を3分で生成し、人間チーム全員で「この方向で合っているか」「この前提は妥当か」「セキュリティ的に問題ないか」を15分で議論します。これを1日10回繰り返すと、設計判断を1日100回経験することになり、個人の判断力ではなくチームの判断力が急速に蓄積されます。

SaaS企業のクロスファンクショナル・モブ事例では、エンジニア・デザイナー・PM・QAの異職種モブで設計することで、仕様書なしレベルで設計が進み、認識ズレによる手戻りが激減しました。専属開発チームの発注後オンボーディング期間にこの異職種モブを取り入れると、職種間の前提共有が一気に進み、混乱期を超えた後の機能期で高い生産性を発揮できます。

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週間を丁寧に組み立てることが、専属開発チームの長期的な成果を決定づけます。

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、弊社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。