システム開発の責任範囲はどこまで？発注者と開発会社が「検収間際」で揉めないための切り分け方
目次
「そこは御社の担当だと思っていました」──検収の直前に、この一言でプロジェクトの空気は一変します。
システム開発を発注したことがある人なら、身に覚えがあるはずです。開発は順調に進み、いよいよ検収（UAT）という段階になって、「この機能が入っていない」「障害が起きたのに調査が進まない」「ストア申請は誰がやるのか」といった論点が急に噴き出す。お互いに悪意はないのに、気づけば「どちらの責任か」をめぐって金額や納期の調整で険悪になっている。
この「責任範囲をめぐる揉め事」は、担当者の力量不足でも、開発会社の不誠実さでもありません。多くの場合、どこまでが開発会社の仕事で、どこからが発注者の仕事なのか、その境界線を最初に引いていなかったという構造的な問題です。境界が曖昧な領域は、平常時は誰も気にしませんが、何か問題が起きた瞬間に「押し付け合い」に変わります。
本稿では、システム開発で責任範囲が曖昧になりやすい典型的な場面を分解したうえで、発注前に何を・誰と・どの粒度で線引きしておけば揉めずに済むのかを、実際のプロジェクト事例をもとに整理します。
システム開発で「責任範囲」が曖昧なまま進むと、なぜ最後に揉めるのか
システム開発における責任範囲は、契約書に一行「開発一式」と書けば決まるものではありません。実際のプロジェクトは、無数の細かい作業の集合体です。要件を決める、仕様を固める、実装する、テストする、障害に対応する、リリース申請をする、運用する──この一つひとつに「誰がやるのか」「うまくいかなかったとき誰が責任を負うのか」という問いが潜んでいます。
法律の世界では、この責任分担を考えるための枠組みが積み上げられてきました。システム開発の契約は、成果物の完成を約束する「請負契約」と、一定の業務を適切に遂行することを約束する「準委任契約」に大きく分かれます。請負は結果を出せなかったこと自体が責任の対象になり、準委任は求められる注意を尽くしたかどうかが問われる、という違いがあります。経済産業省やIPAが公開しているモデル契約でも、工程ごとにこの契約類型を分けて考える方針が示されており、その分かれ目は「成果物の中身を具体的に特定できるかどうか」に置かれています。要件が固まっていない上流工程は準委任、仕様が確定した実装工程は請負、という具合です。
さらに、システム開発の裁判例では、ベンダー（開発会社）が負う「プロジェクトマネジメント義務」と、発注者が負う「協力義務」という二つの概念が、責任分担を判断する物差しとして使われてきました。ざっくり言えば、事業のあり方を決める意思決定は発注者の仕事、その意思決定にもとづく実行と、専門家としての助言・報告は開発会社の仕事、という分担です。開発会社に「全部おまかせ」で丸投げすると、発注者側の協力義務が果たされていないと見なされ、トラブル時に発注者にも責任が及ぶことがある、という点は知っておいて損はありません。
もっとも、現場で本当に必要なのは、こうした法的な枠組みを暗記することではありません。契約書や判例の話に持ち込む前に、日々の進行のなかで境界線を先に引き、書き残しておくこと。ここが曖昧なまま走り出すと、後工程で必ずコストと摩擦になって返ってきます。曖昧さを残すのは、その場の衝突を避ける優しさに見えて、実際には将来の揉め事を先送りしているだけなのです。
なお、責任範囲の議論の一歩手前には「そもそも何を作るかの合意」があります。言葉だけで合意して中身が揃っていないと、責任以前にモノが食い違います。この点は「合意したはず」なのに揉める理由をまとめた記事で詳しく扱っているので、あわせて読むと全体像がつかめます。
責任範囲の切り分けが難しくなる、システム開発の3つの場面
責任範囲は、平常時ではなく「何かが起きたとき」に初めて問われます。ここでは、実際のプロジェクトで境界が曖昧になりやすかった3つの場面を紹介します。自社の状況に重なるものがないか、確認してみてください。
場面1：本番環境に入れない──「見えない環境」での調査責任
セキュリティポリシーが厳格なクライアントでは、本番環境への外部アクセスが一切禁止されていることがあります。ある学校向けの生徒支援アプリ開発では、まさにこの制約がありました。障害が起きても、開発チームが本番環境に直接入って原因を確認できない。事象の特定も復旧も、クライアント側から渡されるログや伝聞を頼りに進めるしかありません。
この状況で「原因究明が遅い」と言われると、開発会社は苦しい立場に立たされます。見えない環境で、限られた情報だけで推測している以上、対応にはどうしてもリードタイムがかかるからです。ここで境界線を引かないままだと、「なぜすぐ直せないのか」という不満が、そのまま開発会社への責任追及に転じてしまいます。
場面2：リリース申請・外部連携──「作る」の外側にある作業
アプリ開発では、本番で動くコードを完成させることと、それをアプリストアに申請して世に出すことは、別の作業です。ストア申請、審査対応、外部サービスとの連携申請といった「作るの外側」の作業は、どこまでが開発会社の受託範囲なのかが曖昧になりがちです。
厄介なのは、これがクライアントの知識量によって大きく変わることです。担当者がエンジニアで申請の勘所を分かっている場合は、クライアント主導で進めて不明点だけ開発会社に聞く形が成立します。一方、まったく知見がない場合は、開発会社が一から伴走しなければ前に進みません。「どちらを前提にするか」を最初に決めていないと、リリース直前になって「そこはやってもらえると思っていた」というすれ違いが起きます。
場面3：口頭で出た要件──「言った・言わない」と要件漏れ
最も起きやすく、最も後を引くのがこれです。前述の生徒支援アプリ開発では、検収（UAT）の段階で要件漏れが発覚しました。要件定義のときにクライアントから口頭で伝えられていた要素の一つが、最終的な要件一覧に落とし込まれていなかったのです。
原因は単純です。初期の要件定義フェーズは膨大な項目であふれており、その要素は相対的に小さな部分だった。以降の打ち合わせで再び話題に上ることもなく、最終要件の説明にも含まれないまま、承認を得て開発が進んでしまった。悪意も怠慢もなく、ただ「拾い上げる仕組み」がなかったために、要件が静かにこぼれ落ちたわけです。
このケースでは、開発そのものへの致命的な影響はなく、後続の追加開発フェーズで優先度を確認しながら対応する形で収まりました。ただし、責任の所在は綺麗には割り切れませんでした。口頭で伝えたクライアント側にも、それを要件化しきれなかった開発側にも、それぞれ落ち度がある。最終的には双方に瑕疵があったという整理で、値引きという形で決着しています。「どちらが100％悪い」とは言えない、という現実こそが、口頭要件の怖さを物語っています。
「うちのプロジェクトにも、思い当たる場面がある」と感じた方へ
ここで挙げた3つの場面は、いずれも発注前の整理で防げるものばかりです。Enlytでは、要件の可視化や責任範囲の切り分けなど、発注前に押さえておきたい論点をまとめた資料を無料で公開しています。自社の進め方を点検する材料として、お役立ち資料ページからご覧ください。
責任範囲を切り分ける進め方──発注前に決めておくべき4つの境界線
では、どう切り分ければいいのか。「しっかり役割分担する」では答えになりません。具体的に、どの境界を、いつ、どんな形で決めておくかを設計する必要があります。
境界1：成果物の境界（どこまで作れば「完了」か）
まず、「何が納品されたら、この契約は果たされたことになるのか」を具体的に定義します。ここで効くのが、検収（UAT）の合格基準を先に言語化しておくことです。承認された要件一覧と検収基準が、そのまま「開発会社が責任を負う範囲」の輪郭になります。
リリース申請のような「作るの外側」の作業も、この段階で明示します。たとえば「本番で動作するコードを納品するところまでが受託範囲で、ストア申請そのものはサポートに徹する」といった線引きです。クライアントに知見がなく一から支援が必要になりそうなら、その支援を契約範囲に含めておく。ここを曖昧にすると、境界のちょうど外側で作業が宙に浮きます。
境界2：意思決定と協力の境界（丸投げにしない）
前述のとおり、事業のあり方を決める意思決定は本来クライアント側の役割で、開発会社はその決定を実行し、専門家として助言・報告する役割です。この分担を最初に共有しておくと、「決めるのは誰か」「情報を出すのは誰か」が明確になります。
ただし、Enlytが大切にしているのは、この分担を盾にして「それは御社が決めることです」と突き放さないことです。現場担当者は、上層部からの要望と厳しい社内ルールの板挟みになっていることが少なくありません。そういう場面では、開発側が技術的な実現可否やコストへの影響を材料として提供し、担当者が上層部を説得するための武器を一緒に作る。役割は分けつつ、前進は一緒に設計する。これがブリッジ役としてのディレクションです。
あわせて有効なのが、散漫になった要望を優先順位で整理した一覧表にして、視覚的に共有することです。何を今回やり、何を次フェーズに送るのかが目に見える形になっていれば、社内の合意形成も、開発側との期待値調整も、同じ一枚を見ながら進められます。
境界3：調査・対応の境界（「見えない前提」を先に合意する）
場面1のような制約がある場合、「見えない環境下では推測に限界がある」ことを、問題が起きる前にクライアントと合意しておくことが決定的に重要です。提供された情報の範囲内で調査責任を負う、という前提をあらかじめ揃えておけば、いざ障害が起きたときに「なぜ究明できないのか」という責任追及ではなく、「では、どんな情報をどう渡せば究明が進むか」という建設的な会話に切り替えられます。
境界は、起きてから引くと角が立ちます。起きる前に引いておけば、単なる前提の共有として淡々と扱えます。
境界4：承認プロセスをクリティカルパスとして扱う
見落とされがちなのが、クライアント側の社内承認フローです。新しいツールやSaaSの導入、ライブラリの利用にすら、都度の社内承認が必要で、数週間かかる──こうした組織は珍しくありません。この承認待ちは、開発会社の努力ではどうにもならないボトルネックです。
標準的な開発スピードを前提に計画を立てると、承認待ちの分だけ必ずスケジュールが破綻します。だからこそ、クライアントの承認プロセスを「発注者側の作業」ではなく、プロジェクト全体のクリティカルパス（最も余裕のない経路）として扱い、認識を合わせておく必要があります。あわせて、言われたことをそのまま受けるのではなく、「それをやるとスケジュールが破綻する」というリスクを指摘し、「これなら期限内に可能」というB案を用意する。責任範囲の設計とは、線を引くだけでなく、線の外側で起きる遅延まで織り込むことなのです。
発注前にどの論点を詰めておくべきかは、発注前に整理すべき論点をまとめた記事でも具体的に触れています。上流でここを揃えられるかどうかが、後半の揉め事を大きく左右します。
システム開発の責任範囲でつまずかないための、明日からのチェックリスト
抽象論で終わらせないために、すぐ持ち帰れる具体策をまとめます。
契約・議事録に必ず残す項目
- 検収（UAT）の合格基準──何が満たされれば「完了」なのか
- 受託範囲の外縁──ストア申請、外部連携申請、運用など「作るの外側」をどこまで担うか
- 調査・障害対応の前提──アクセスできない環境がある場合、どの情報を誰が提供し、どこまでを調査責任とするか
- 意思決定の主体──何をクライアントが決め、何を開発会社が判断してよいか
- 変更が出たときの扱い──当初の合意のどこを更新し、費用・納期にどう反映するか
要件漏れを防ぐための仕組み
- 口頭で出た要望を、その場で「要件候補」として記録に落とす担当と場所を決めておく
- 最終要件を承認する前に、「初回以降に口頭で出た話が、すべて要件一覧に反映されているか」を突き合わせる
- 議事録では「決定事項・検討事項・保留事項」を分けて書き、どこまでが確定かを曖昧にしない
- 要望は優先順位をつけた一覧表にして、今回対応する範囲と次フェーズに送る範囲を視覚的に共有する
責任範囲の会話で使うと効く問い
- 「この作業は、御社の担当ですか、弊社の担当ですか──今この場で決めておきませんか？」
- 「本番環境を確認できない前提で、障害時はどの情報をどう渡していただけますか？」
- 「社内承認には、どの工程で何週間かかる想定ですか？」
- 「この要望は、今回の要件に含める“決定”ですか、それとも次フェーズで検討する“保留”ですか？」
その場しのぎで終わらせない
一度ズレが起きたら、「今回どう収めるか」という暫定対応だけでなく、「次から同じ種類のズレをどう起こさないか」という恒久対応まで考えます。たとえば要件漏れが起きたなら、その案件を値引きで収めて終わりにせず、口頭要件を拾う仕組みそのものをチームの標準に組み込み、他の案件へ横展開する。個人の注意力に頼っている限り、同じ抜けは必ず再発します。品質は根性ではなく、仕組みで支えるものです。この「仕組みで支える」という発想については、開発プロセスの標準化に関する記事でも掘り下げています。
まとめ｜責任範囲の設計は、PM・ディレクターの仕事そのもの
「検収間際になって、責任の押し付け合いになる」という現象は、誰かのミスではなく、境界線を最初に引いていなかったことから生まれます。逆に言えば、成果物の境界、意思決定の境界、調査対応の境界、そして承認プロセスという4つの線を発注前に引いておくだけで、システム開発は驚くほど揉めなくなります。
そして、この境界を引き、書き残し、関係者の認識を揃える設計こそが、PM・ディレクターの本当の価値です。彼らは進捗を見張る管理者ではなく、曖昧さを減らし、期待値を揃え、後から起きる問題を未然に防ぎながら、立場の異なる関係者の間をつなぐブリッジ役です。責任範囲の切り分けとは、それ自体が進行品質そのものなのです。
Enlytは、システムを「作る」こと以上に、揉めずに、成果につながる形で進める設計を強みにしています。受注前の段階から要件を可視化し、責任範囲と期待値を関係者ごとに揃え、認識齟齬が生まれる前に整理する。本番環境に入れない、社内承認に時間がかかるといった制約のあるプロジェクトでも、境界を先に引くことで前進を止めない進行を、個人の力量ではなく仕組みとして持っています。
「気づけば、責任の所在をめぐって揉めている」が続いているなら、それは現場の頑張りが足りないのではなく、責任範囲の設計が抜けているサインかもしれません。自社のプロジェクトのどこに曖昧な境界が残っているか、一度棚卸ししてみることをおすすめします。
現在進行中のプロジェクトに不安がある方や、上流整理から任せられる開発パートナーをお探しの方は、お問い合わせよりお気軽にご相談ください。
あわせて読みたいEnlytのブログ
