記事一覧に戻る
開発

複数の開発会社が1つのシステムに関わるとき|責任の線を引きすぎて困るのは発注側

2026年9月4日 約4分で読めます
この記事の結論

1つのシステムに複数の会社が関わるとき、役割を明確に分離できることはまずありません。責任の線を厳密に引くほど、境界で立ち往生して困るのは発注側です。FUNBREWは明らかな不利益にならない限り、他社の範疇も考慮して関わるようにしています。

基幹システムは自社開発の会社に、サイトは別の制作会社に、決済まわりはさらに別のところに。中小企業のシステムでも、複数の会社が1つの仕組みに関わっている状態は珍しくありません。この記事では、そういう案件でFUNBREWがどう関わっているか、そして責任の線を厳密に引こうとすると誰が損をするのかを書きます。

役割を明確に分離できることは、まずない

理想を言えば、担当範囲が明確に分かれていることがいちばんです。「ここから先は当社、ここから先は他社」と線が引けていれば、判断で迷いません。ただ、まずもってそんなことはありません。

境界は、システムの中で溶けている

複数の会社が関わるシステムでは、データが行き来し、画面がつながり、片方の変更がもう片方の挙動に影響します。契約書の上では範囲が分かれていても、動いているものの中では境界が溶けています。

不具合は、どちらとも言い切れない場所で起きる

そして厄介なことに、問題が起きるのはたいてい境界です。渡されたデータの形式が想定と違う、片方の仕様変更にもう片方が追随していない、両方とも仕様どおりなのに組み合わせると動かない。こうした事象は、どちらか一方の責任だと言い切れません。

システム開発をしている限り、ミスや不具合はつきものです。誰かが悪いから起きるのではなく、必ず起きるものとして扱う方が現実に合っています。

「そこは御社の責任です」を徹底すると、何が起きるか

間に立たされるのは、発注側

境界で問題が起きたとき、関わる各社が自社の責任範囲を厳密に主張したとします。技術的には、それぞれの言い分は正しいかもしれません。しかし現実に何が起きるかというと、両者の主張を聞いて調整する役目が、発注側に回ってきます。

発注側は、技術的な切り分けの判断材料を持っていません。それでも間に立たされ、双方に説明を求め、伝言を繰り返すことになります。責任の所在をはっきりさせようとした結果、いちばん専門知識のない人が最も難しい判断を背負う——これが、線を引きすぎたときに起きることです。

その間、システムは止まったままです。誰の責任かが決まっても、それだけでは動くようになりません。

FUNBREWがどう関わっているか

明らかな不利益にならない限り、他社の範疇も考慮する

そのためFUNBREWでは、明らかに不利益にならない限り、他社のシステムの範疇も考慮に入れてお手伝いするようにしています。「そこは当社の担当外です」で止めるのではなく、まず何が起きているのかを一緒に見るところから始めます。

もちろん、無制限にというわけではありません。他社の領域を全面的に引き受ければ、その工数はどこかにしわ寄せが行きます。ただ、切り分けのために調べる程度のことで話が前に進むのであれば、そこで線を引く意味はほとんどありません。

場合によっては巻き取る

状況によっては、他社の担当部分も含めてこちらで巻き取る判断をすることもあります。パートナーとしてプロジェクトに参加している以上、動かない状態を放置するより、引き受けて前に進める方が結果的に良いと考える場面があるためです。

他社が作った部分を調査するときに何が手がかりになるかは、システム引き継ぎで用意する資料は何かに書いています。

発注側が用意しておくとよいこと

複数社が関わる体制を取る場合、発注側の準備で状況はかなり変わります。

  • 各社の担当範囲を、書いたものにしておく —— 完全に分離できなくても、おおよその分担が文書になっていると、切り分けの出発点になります。
  • 連絡の経路をつくっておく —— 各社が発注側を経由してしか話せない状態は、伝言のコストが大きくなります。必要なときに開発会社同士で直接やりとりできる形にしておくと、解決が早くなります。
  • 「まず調べる」の費用を見込んでおく —— 境界の問題は、原因が分かるまで誰の担当か決まりません。調査そのものに工数がかかることを前提にしておくと、押し付け合いになりにくくなります。

発注時に何を明確にしておくべきかは小規模なシステム開発で契約書は必要か、進行中の確認については納品後に「思っていたのと違う」と言われないためにもあわせてご覧ください。

他社が関わっている案件で「これはどちらの問題ですか」と聞かれたら、まず調べます。責任の所在を先に決めても、システムは動くようになりません。順番としては、原因を特定してから費用の話をする方が、結果的に早く安く済みます。

まとめ

1つのシステムに複数の開発会社が関わるとき、役割を明確に分離できることはまずありません。データも画面もつながっているため、契約上の範囲と動いているものの境界は一致しないからです。そして問題は、たいていその境界で起きます。

各社が責任範囲を厳密に主張すると、調整役として間に立たされるのは発注側です。技術的な判断材料を持たない人が、最も難しい切り分けを背負うことになります。その間もシステムは止まったままです。

FUNBREWは、明らかな不利益にならない限り他社の範疇も考慮して関わり、場合によっては巻き取る形でプロジェクトに参加しています。複数社が関わる案件のご相談も承ります。お問い合わせよりご連絡ください。

よくある質問
複数の開発会社で担当範囲を明確に分けることはできますか。
理想ではありますが、まずもってできません。データが行き来し画面がつながっているため、契約書の上で範囲が分かれていても、動いているものの中では境界が溶けています。
境界で不具合が起きた場合、どちらの責任になりますか。
どちらか一方とは言い切れないことがほとんどです。渡されたデータの形式が想定と違う、片方の仕様変更にもう片方が追随していない、両方とも仕様どおりなのに組み合わせると動かない、といった形で起きるためです。
各社に責任範囲をはっきりさせてもらうのは良い方法ですか。
厳密に線を引くほど、調整役として間に立たされるのは発注側です。技術的な切り分けの判断材料を持たない人が最も難しい判断を背負うことになり、その間システムは止まったままになります。責任の所在が決まっても、それだけでは動くようになりません。
FUNBREWは他社の担当部分にも対応してもらえますか。
明らかに不利益にならない限り、他社のシステムの範疇も考慮してお手伝いしています。状況によっては、他社の担当部分も含めてこちらで巻き取る判断をすることもあります。
複数社体制で発注側が用意しておくとよいことは何ですか。
各社の担当範囲をおおよそでも文書にしておくこと、必要なときに開発会社同士が直接やりとりできる経路をつくっておくこと、そして原因を特定するための調査に工数がかかることを見込んでおくことの3点です。

この記事をシェア

複数社が関わる案件もご相談ください

どちらの担当か分からない状態でも、まず何が起きているかを調べるところからお手伝いします。

この記事に関連するサービス

お困りごとのご相談は無料です。まずは状況をお聞かせください。

最新情報をお届けします

IT活用のヒントやお役立ち情報を定期的にお届けします。

関連記事

開発
2026年9月4日

納品後に「思っていたのと違う」と言われないために|途中で見せることでしか防げない

システム開発で納品後に「思っていたのと違う」と言われないために何をしているか。定期的に進捗を見せる意味と、それでも起きるズレの処理(追加見積もりか、他機能を削るか)を実務から書きました。

2026年4月11日

システム開発の外注で失敗しない|発注前に確認すべき10のチェックポイント

システム開発を外注する際に事前に確認すべき10項目を解説。要件定義から契約、検収まで、失敗を防ぐチェックリストを紹介します。

開発
2026年4月4日

システム開発の検収期間の目安|期間の決め方・延長対応・トラブル防止策

システム開発の検収期間は一般的に1〜4週間が相場ですが、規模や複雑さによって大きく異なります。この記事では、検収期間の適切な設定方法、契約書への記載方法、期間延長が起きる原因と対処法、トラブルを防ぐ実践的なポイントを発注者向けに解説します。

開発
2026年3月22日

システム開発の検収チェックリスト|受け入れテストの進め方と合否判定基準【テンプレート付き】

システム開発の検収(受け入れテスト)で使えるカテゴリ別チェックリストと検収書テンプレートを公開。機能テスト・非機能テスト・UI/UX・ドキュメントの4カテゴリで抜け漏れなく確認でき、合否判定基準の決め方やよくあるトラブル対処法まで徹底解説します。

相談のハードル、下げました

まずは気軽にご相談ください

「まだ具体的に決まっていない」「とりあえず話を聞きたい」でも大丈夫。プロトタイプを見ながら、一緒にアイデアを形にしていきましょう。

相談無料 オンライン対応 1週間でプロトタイプ