複数の開発会社に頼むときの役割分担

一つのシステムを複数の開発会社に分けて頼む場合、会社どうしの調整と、全体を一つのシステムとしてまとめる責任は、IPAのモデル契約書の考え方では、発注者が負うものとされています。それぞれの開発会社は、自社が受けた部分には責任を持ちますが、ほかの会社が作る部分とのつなぎ目までは、自然には責任を持ちません。そのため、つなぎ目と役割を最初に決めておくことが大切です。

この記事では、複数の開発会社に頼む形（マルチベンダー）での役割分担の考え方を、IPA（情報処理推進機構）の「情報システム・モデル取引・契約書」を参考に整理します。

マルチベンダーとは

マルチベンダーとは、一つのシステムや一つのプロジェクトを、複数の開発会社に分けて発注する形です。基幹のシステムはA社、Webの画面はB社、データの基盤はC社、というように、得意な分野ごとに会社を選べる点が利点です。

一方で、1つの会社にまとめて頼む形（シングルベンダー）に比べると、会社どうしの調整が増え、問題が起きたときに「どの会社の担当か」が分かりにくくなる面があります。

特定の会社への依存を減らす考え方はベンダーロックインを避けるにはでも扱っています。

全体の調整の責任は、発注者にある

複数の会社に分けて頼むとき、全体の調整の責任は発注者にある、というのがIPAのモデル契約書の考え方です。モデル契約書は、発注者がソフトウェアの開発を全体のシステムの一部として分割して発注し、連携するほかのソフトウェアを第三者が開発している場合、ほかのソフトウェアとの機能の整合、開発のスケジュールの調整、第三者と開発会社の進み具合の管理と調整について、発注者が責任を負う、という条項例を示しています。

同じ条項例では、発注者がこの調整を進めるために開発会社の協力を求める場合は、必要な条件を個別の契約で決め、開発会社はそれに従って協力する、としています。開発会社に調整の手伝いを頼むなら、その範囲と費用を契約で決めておく、ということです。

出典：情報システム・モデル取引・契約書（第二版）（IPA）

つなぎ目の責任の境目を決める

複数の会社が関わるシステムで問題が起きやすいのは、会社と会社のつなぎ目です。つなぎ目の責任の境目は、次の点を文書で決めておくとはっきりします。

1. つなぎ方の仕様：データの形式、やり取りの方法（API など）、エラーのときの動き
2. 仕様を決める会社と、承認する人：どの会社が仕様の案を作り、発注者の誰が決めるか
3. つなぎ目のテスト：どの会社が、いつ、どの環境でテストするか
4. 仕様を変えるときの手順：一方の会社が変えたいときに、ほかの会社にどう知らせ、誰が決めるか

つなぎ方の仕様の変更は、ほかの会社の作業にも影響します。変更の手順は、会社ごとではなく、プロジェクト全体で一つにそろえておくと、食い違いが減ります（開発の途中で仕様を変えたいときの進め方）。

RACIで役割を表にする

作業ごとの役割を表にする方法として、RACI（責任分担表）がよく使われます。RACIとは、作業ごとに、関わる人や会社の役割を、実行する（R）、最終の責任を持つ（A）、相談を受ける（C）、結果を知らされる（I）の4つで表す方法です。

表を作るときは、作業ごとに「A」が1つだけになるようにします。Aが2つあると、どちらが最終的に決めるのか分からなくなり、Aがないと、誰も決めない作業が生まれます。たとえば、つなぎ方の仕様という作業なら、仕様の案を作る会社がR、決める発注者の担当者がA、つながる相手の会社がC、運用を受け持つ部署がI、という形です。

取りまとめ役（PMO）を置く

関わる会社が多い場合は、全体を取りまとめる役（PMO：プロジェクトマネジメントオフィス）を置く方法があります。PMOは、全体の予定と課題の一覧を管理し、会社どうしの会議を進め、決めることを発注者の決める人に上げる役割を担います。

PMOは、発注者の社内に置くこともあれば、外部の会社に頼むこともあります。外部に頼む場合でも、最終の判断と全体の調整の責任は発注者に残る、という点を押さえておきます。PMOを、開発を受け持つ会社の1つに兼ねてもらう場合は、ほかの会社との関係で中立を保てるかも考えておく必要があります。

全体の会議の場として、関わる会社が集まる定例の会議を設け、課題と決めごとを議事録に残すと、後から経緯を確かめやすくなります。発注者の側の役割は発注する側のプロジェクト管理。担当者がすることで説明しています。

障害のときの窓口を決めておく

公開した後に障害が起きたとき、原因がどの会社の担当部分にあるかは、すぐには分からないことが多いです。そのため、最初に連絡を受けて原因を切り分ける窓口を、1つに決めておくことが大切です。

IPAのモデル契約書（パッケージ、SaaS/ASP活用、保守・運用）の追補版は、最初の切り分けの窓口を一本にすることで、ITの専門の知識がない発注者の負担を小さくし、会社どうしの責任の押し付け合いを防ぐ、という考え方を示しています。同じ資料は、ネットワークを含むシステム全体の障害の切り分けを任せる場合には、保守の範囲とともに、不具合の調査の費用の扱いを決めておく必要があるとしています。

窓口を決めるときは、次の点もあわせて決めておきます。

• 窓口の会社が、ほかの会社に調査を頼むときの手順
• 原因が分かるまでの間の、業務を続けるための代わりの方法
• 調査の費用を、原因の会社が負担するのか、決めた形で分けるのか

保守の契約で決めることはシステムの保守契約で決めておくことにまとめています。

始める前に確かめておきたいこと

複数の会社に分けて頼む前に、次の点を発注者の側で確かめておきます。

• 全体の調整を、社内の誰が担うか。その人に十分な時間があるか
• 会社どうしの情報の共有の方法（共有の課題の一覧、文書の置き場所）
• 各社との秘密保持の取り決めで、ほかの会社に仕様を見せてよいか
• 各社の契約で、調整への協力の範囲と費用が決まっているか

本記事は一般的な整理です。個別の契約書の内容や判断については、弁護士などの専門家にご確認ください。

当社のご支援

当社は、AIインテグレーションで、基幹システムやSaaSなど、他社が作った仕組みとつないでAIを組み込む仕事を、運用と改善まで受け持っています。必要に応じて技術者がお客様の現場に入るFDEの形で、要件定義から開発・運用までを担うこともできます。どの関わり方が合うかは関わり方をご覧のうえ、お問い合わせからご相談ください。