--- title: "複数の開発会社に頼むときの役割分担｜アメリア・テクノロジー株式会社" url: https://www.ameliatechnology.co.jp/blog/multi-vendor-management/ description: "一つのシステムを複数の開発会社に分けて頼むとき（マルチベンダー）の役割分担を整理します。全体の調整の責任を発注者が負うという考え方、責任の境目の決め方、RACIによる分担の表し方、取りまとめ役（PMO）の置き方、障害のときの窓口を説明します。" updated: 2026-11-12 publisher: "アメリア・テクノロジー株式会社" --- # 複数の開発会社に頼むときの役割分担 一つのシステムを複数の開発会社に分けて頼むとき（マルチベンダー）の役割分担を整理します。全体の調整の責任を発注者が負うという考え方、責任の境目の決め方、RACIによる分担の表し方、取りまとめ役（PMO）の置き方、障害のときの窓口を説明します。 2026.11.12 [開発の発注と契約](https://www.ameliatechnology.co.jp/blog/category/outsourcing/) 執筆 [石田誠](https://www.ameliatechnology.co.jp/blog/author/ishida/)（グループCTO） 開発の発注と契約（OUTSOURCING）のコラム ## この記事の要点 - 複数の開発会社に分けて頼むと、会社どうしの調整と全体の取りまとめの責任は、IPAのモデル契約書の考え方では発注者が負います - つなぎ目の仕様と、障害の切り分けの窓口を、最初に決めておくことが大切です - RACIで作業ごとの役割を表にし、取りまとめ役（PMO）を置くと、責任の抜けや重なりを減らせます 一つのシステムを複数の開発会社に分けて頼む場合、会社どうしの調整と、全体を一つのシステムとしてまとめる責任は、IPAのモデル契約書の考え方では、発注者が負うものとされています。それぞれの開発会社は、自社が受けた部分には責任を持ちますが、ほかの会社が作る部分とのつなぎ目までは、自然には責任を持ちません。そのため、つなぎ目と役割を最初に決めておくことが大切です。 この記事では、複数の開発会社に頼む形（マルチベンダー）での役割分担の考え方を、IPA（情報処理推進機構）の「情報システム・モデル取引・契約書」を参考に整理します。 ## マルチベンダーとは マルチベンダーとは、一つのシステムや一つのプロジェクトを、複数の開発会社に分けて発注する形です。基幹のシステムはA社、Webの画面はB社、データの基盤はC社、というように、得意な分野ごとに会社を選べる点が利点です。 一方で、1つの会社にまとめて頼む形（シングルベンダー）に比べると、会社どうしの調整が増え、問題が起きたときに「どの会社の担当か」が分かりにくくなる面があります。 | 比べる点 | 1つの会社にまとめて頼む | 複数の会社に分けて頼む | |---|---|---| | 会社の選び方 | 全体を任せられる会社から選ぶ | 分野ごとに得意な会社を選べる | | 全体の調整 | 受けた会社が中心になる | 発注者が中心になる | | 問題が起きたとき | 窓口が1つ | 原因の切り分けが要る | | 特定の会社への依存 | 強くなりやすい | 分散しやすい | 特定の会社への依存を減らす考え方は[ベンダーロックインを避けるには](https://www.ameliatechnology.co.jp/blog/avoid-vendor-lock-in/)でも扱っています。 ## 全体の調整の責任は、発注者にある 複数の会社に分けて頼むとき、全体の調整の責任は発注者にある、というのがIPAのモデル契約書の考え方です。モデル契約書は、発注者がソフトウェアの開発を全体のシステムの一部として分割して発注し、連携するほかのソフトウェアを第三者が開発している場合、ほかのソフトウェアとの機能の整合、開発のスケジュールの調整、第三者と開発会社の進み具合の管理と調整について、発注者が責任を負う、という条項例を示しています。 同じ条項例では、発注者がこの調整を進めるために開発会社の協力を求める場合は、必要な条件を個別の契約で決め、開発会社はそれに従って協力する、としています。開発会社に調整の手伝いを頼むなら、その範囲と費用を契約で決めておく、ということです。 出典：[情報システム・モデル取引・契約書（第二版）（IPA）](https://www.ipa.go.jp/digital/model/model20201222.html) ## つなぎ目の責任の境目を決める 複数の会社が関わるシステムで問題が起きやすいのは、会社と会社のつなぎ目です。つなぎ目の責任の境目は、次の点を文書で決めておくとはっきりします。 1. **つなぎ方の仕様**：データの形式、やり取りの方法（API など）、エラーのときの動き 2. **仕様を決める会社と、承認する人**：どの会社が仕様の案を作り、発注者の誰が決めるか 3. **つなぎ目のテスト**：どの会社が、いつ、どの環境でテストするか 4. **仕様を変えるときの手順**：一方の会社が変えたいときに、ほかの会社にどう知らせ、誰が決めるか つなぎ方の仕様の変更は、ほかの会社の作業にも影響します。変更の手順は、会社ごとではなく、プロジェクト全体で一つにそろえておくと、食い違いが減ります（[開発の途中で仕様を変えたいときの進め方](https://www.ameliatechnology.co.jp/blog/change-request-handling/)）。 ## RACIで役割を表にする 作業ごとの役割を表にする方法として、RACI（責任分担表）がよく使われます。[RACI](https://www.ameliatechnology.co.jp/glossary/raci-chart/)とは、作業ごとに、関わる人や会社の役割を、実行する（R）、最終の責任を持つ（A）、相談を受ける（C）、結果を知らされる（I）の4つで表す方法です。 表を作るときは、作業ごとに「A」が1つだけになるようにします。Aが2つあると、どちらが最終的に決めるのか分からなくなり、Aがないと、誰も決めない作業が生まれます。たとえば、つなぎ方の仕様という作業なら、仕様の案を作る会社がR、決める発注者の担当者がA、つながる相手の会社がC、運用を受け持つ部署がI、という形です。 RACIの4つの役割 - **R**：実行する - **A**：最終の責任を持つ（作業ごとに**1つだけ**） - **C**：相談を受ける - **I**：結果を知らされる Aが2つあると誰が決めるか分からなくなり、Aがないと誰も決めない作業が生まれます ## 取りまとめ役（PMO）を置く 関わる会社が多い場合は、全体を取りまとめる役（PMO：プロジェクトマネジメントオフィス）を置く方法があります。PMOは、全体の予定と課題の一覧を管理し、会社どうしの会議を進め、決めることを発注者の決める人に上げる役割を担います。 PMOは、発注者の社内に置くこともあれば、外部の会社に頼むこともあります。外部に頼む場合でも、最終の判断と全体の調整の責任は発注者に残る、という点を押さえておきます。PMOを、開発を受け持つ会社の1つに兼ねてもらう場合は、ほかの会社との関係で中立を保てるかも考えておく必要があります。 全体の会議の場として、関わる会社が集まる定例の会議を設け、課題と決めごとを議事録に残すと、後から経緯を確かめやすくなります。発注者の側の役割は[発注する側のプロジェクト管理。担当者がすること](https://www.ameliatechnology.co.jp/blog/client-side-project-management/)で説明しています。 ## 障害のときの窓口を決めておく 公開した後に障害が起きたとき、原因がどの会社の担当部分にあるかは、すぐには分からないことが多いです。そのため、最初に連絡を受けて原因を切り分ける窓口を、1つに決めておくことが大切です。 IPAのモデル契約書（パッケージ、SaaS/ASP活用、保守・運用）の追補版は、最初の切り分けの窓口を一本にすることで、ITの専門の知識がない発注者の負担を小さくし、会社どうしの責任の押し付け合いを防ぐ、という考え方を示しています。同じ資料は、ネットワークを含むシステム全体の障害の切り分けを任せる場合には、保守の範囲とともに、不具合の調査の費用の扱いを決めておく必要があるとしています。 窓口を決めるときは、次の点もあわせて決めておきます。 - 窓口の会社が、ほかの会社に調査を頼むときの手順 - 原因が分かるまでの間の、業務を続けるための代わりの方法 - 調査の費用を、原因の会社が負担するのか、決めた形で分けるのか 保守の契約で決めることは[システムの保守契約で決めておくこと](https://www.ameliatechnology.co.jp/blog/maintenance-contract-points/)にまとめています。 ## 始める前に確かめておきたいこと 複数の会社に分けて頼む前に、次の点を発注者の側で確かめておきます。 - 全体の調整を、社内の誰が担うか。その人に十分な時間があるか - 会社どうしの情報の共有の方法（共有の課題の一覧、文書の置き場所） - 各社との秘密保持の取り決めで、ほかの会社に仕様を見せてよいか - 各社の契約で、調整への協力の範囲と費用が決まっているか 本記事は一般的な整理です。個別の契約書の内容や判断については、弁護士などの専門家にご確認ください。 ## 当社のご支援 当社は、[AIインテグレーション](https://www.ameliatechnology.co.jp/service/integration/)で、基幹システムやSaaSなど、他社が作った仕組みとつないでAIを組み込む仕事を、運用と改善まで受け持っています。必要に応じて技術者がお客様の現場に入る[FDE](https://www.ameliatechnology.co.jp/fde/)の形で、要件定義から開発・運用までを担うこともできます。どの関わり方が合うかは[関わり方](https://www.ameliatechnology.co.jp/engagement/)をご覧のうえ、[お問い合わせ](https://www.ameliatechnology.co.jp/contact/)からご相談ください。 - マルチベンダー - PMO - RACI - 契約 ## この記事に出てくる用語 - [情報システム・モデル取引・契約書（IPA）](https://www.ameliatechnology.co.jp/glossary/model-contract-ipa/) - [ベンダーロックイン](https://www.ameliatechnology.co.jp/glossary/vendor-lock-in/) - [API](https://www.ameliatechnology.co.jp/glossary/api/) - [RACI（責任分担表）](https://www.ameliatechnology.co.jp/glossary/raci-chart/) - [PMO](https://www.ameliatechnology.co.jp/glossary/pmo/) - [プロジェクトマネジメント](https://www.ameliatechnology.co.jp/glossary/project-management/) - [SaaS](https://www.ameliatechnology.co.jp/glossary/saas/) - [保守・運用](https://www.ameliatechnology.co.jp/glossary/maintenance-operation/) ## 関連する法令・指針（参考情報） - 指針 独立行政法人情報処理推進機構（IPA）「情報システム・モデル取引・契約書」（第二版（2020年12月22日）） 情報システムの受託開発（一部の企画を含む）と保守運用の取引について、モデル契約と解説をまとめた資料です。民法の改正に直接関係する論点と、それ以外の論点の両方を見直しています。 [発行元の公式ページで開く](https://www.ipa.go.jp/digital/model/model20201222.html) 法令は2026年10月21日時点の内容です。要旨は当社がまとめたもので、条文・判決・指針の全文ではありません。個別の事案への当てはめは、弁護士・社会保険労務士などの専門家にご確認ください。表記の決まりは[法令・指針の参考情報と凡例](https://www.ameliatechnology.co.jp/knowledge/legal/)をご覧ください。 この記事を書いた人 [石田誠](https://www.ameliatechnology.co.jp/blog/author/ishida/) グループCTO インターネットの黎明期から、ホスティング事業の立ち上げや、インフラ・セキュリティのプロジェクトに携わってきました。現在は、AWS・Azure へのクラウド移行の支援と、業務アプリケーションの要件定義から実装までを担っています。 このコラムは一般的な情報の提供を目的としたもので、個別の状況への助言ではありません。製品・サービスの名前と内容は、記事の更新日の時点のものです。 ## あわせて読みたい - [開発会社を替えるときの引き継ぎと、そろえておく資料](https://www.ameliatechnology.co.jp/blog/vendor-switch-handover/) - [取適法（中小受託取引適正化法）とシステム開発の発注](https://www.ameliatechnology.co.jp/blog/toriteki-act-system-development/) - [システム開発の成果物の著作権は誰のものか](https://www.ameliatechnology.co.jp/blog/software-copyright-ownership/) [開発の発注と契約のコラムを見る](https://www.ameliatechnology.co.jp/blog/category/outsourcing/) [コラムの一覧に戻る](https://www.ameliatechnology.co.jp/blog/) ## 次の一歩 ### 現場に入るチームに任せる 技術者がお客様の現場に入り、要件定義から開発・運用までを担います。 [FDEを見る](https://www.ameliatechnology.co.jp/fde/) ### まずは30分、オンラインで話してみる 何に使うかが決まっていない段階でも構いません。30分のオンライン相談は無料です。 [無料で相談する](https://www.ameliatechnology.co.jp/contact/) ## ご関心に合わせて、お選びください。 [情報を集めている方へ会社案内、AI開発の例、セキュリティ診断の報告書の見本をお送りします。資料をダウンロード](https://www.ameliatechnology.co.jp/download/)[課題が見えている方へオンラインで30分、お話をうかがいます。費用はかかりません。無料で相談する](https://www.ameliatechnology.co.jp/contact/)[進め方を決めたい方へ2〜4週間で、優先順位と計画をまとめるAI活用の診断です。診断について見る](https://www.ameliatechnology.co.jp/pricing/#diagnosis) --- 出典：アメリア・テクノロジー株式会社「複数の開発会社に頼むときの役割分担｜アメリア・テクノロジー株式会社」 https://www.ameliatechnology.co.jp/blog/multi-vendor-management/