発注の基本

発注者責任 はっちゅうしゃせきにん

発注者ベンダーシステム開発プロジェクト管理要件定義契約
発注者責任について教えて

簡単に言うとこんな感じ!

システムを「作ってもらう側」にも、ちゃんと果たすべき責任があるってことだよ!「お金払うんだから全部やっといて」はNGで、要件をきちんと伝えたり、決断をタイムリーにしたりする義務がある。それをサボるとプロジェクトが失敗しても「発注者にも原因がある」って判断されちゃうんだ。


発注者責任とは

ITシステムの開発や導入を外部のベンダー(システム開発会社)に依頼する際、依頼する側(発注者)にも果たすべき責任と義務があるという考え方です。「お金を払っているから、あとはベンダーに任せればよい」という姿勢ではなく、発注者自身がプロジェクトに主体的に関与することが求められます。

具体的には、「何を作りたいか(要件)を明確に伝える」「疑問や確認事項に迅速に回答する」「仕様変更が生じた場合は適切に意思決定する」といった行動が発注者責任の中心です。これらを怠ると、ベンダーが正しい方向で開発を進められず、スケジュール遅延・コスト超過・品質低下といったトラブルの原因になります。

日本では経済産業省が「情報システム・モデル取引・契約書」を公表しており、発注者とベンダーの双方が対等なパートナーとして責任を分担することを推奨しています。「システム開発の失敗は全部ベンダーのせい」ではなく、発注者側の関与不足が失敗の主因になるケースが非常に多いことが、業界全体の課題として認識されています。


発注者責任の具体的な中身

発注者責任は「何をすべきか」という観点で整理すると、以下のように分類できます。

フェーズ発注者がやるべきことやらないと起きる問題
企画・要件定義業務要件・目的を明確に言語化する「言った・言わない」の仕様トラブル
契約契約範囲・成果物・検収基準を確認・合意する追加費用請求・責任の押し付け合い
開発中疑問への回答・仕様変更の意思決定を迅速に行う開発停滞・スケジュール遅延
テスト・検収自社業務に照らして動作を確認するバグを見逃したまま本番稼働
運用後問題発生時の一次判断・ベンダーへの連絡を行う障害対応の長期化・損害拡大

「甲乙の責任分担」という考え方

契約書では発注者を「」、ベンダーを「」と表記します。発注者責任は「甲の義務」として契約書に明記されることが増えており、「甲が期日までに回答しない場合、乙はスケジュール変更を申し出ることができる」といった条項が設けられるケースが一般的です。

発注者責任が問われやすい場面3選

  1. 要件定義のおまかせ:「詳しいことはよくわからないのでベンダーに考えてもらった」→ 完成物が業務に合わない
  2. 意思決定の遅延:担当者が社内調整に時間をかけすぎ、ベンダーが待ちぼうけ → 工期延長・追加費用
  3. 検収の形骸化:「動いているからOK」とサインしてしまう → 後から不具合発覚でも保証対象外

歴史と背景

  • 1990年代〜2000年代初頭:大規模システム開発の失敗事例が相次ぐ。多くの場合「ベンダーが悪い」とされていたが、発注者側の要件不明確・意思決定遅延が原因のケースも多数存在した。
  • 2007年:経済産業省が「情報システム・モデル取引・契約書」を初版公表。発注者とベンダーの役割・責任を明文化し、対等なパートナーシップを促進する枠組みを示した。
  • 2013年:同モデル契約書が改訂。アジャイル開発への対応や、多段階契約(フェーズ分割発注)の考え方が盛り込まれた。
  • 2020年:DX推進の加速に伴い、「ユーザー企業がITを他人事にしてはいけない」という議論が活発化。IPA(情報処理推進機構)が「DX白書」で発注者リテラシーの重要性を強調。
  • 現在:クラウド・SaaS活用が増える中でも、「どのサービスを選ぶか」「どう業務に組み込むか」の判断は発注者責任として引き続き重要視されている。

ベンダー責任との違い・役割分担の全体像

「発注者責任」と「ベンダー責任」は対になる概念です。どちらが何を担うのかをきちんと理解することが、健全なプロジェクト運営の第一歩です。

発注者責任 vs ベンダー責任 役割分担マップ 発注者(甲)の責任 📋 業務要件・目的の明確化 ⚡ 意思決定・回答をタイムリーに 🔍 テスト・検収の実施 📑 契約内容の確認・合意 🏢 社内調整・関係者合意形成 ⚠️ 怠ると… 「発注者にも原因あり」と判断 ベンダー(乙)の責任 🛠️ 要件に基づく設計・開発 📐 技術的な品質・性能の確保 📘 進捗・課題の報告・連絡 🔧 納品後の瑕疵対応・保守 💡 技術的な提案・助言 ⚠️ 怠ると… 債務不履行・損害賠償の対象に 対等な パートナー

「丸投げ」がNGな理由

発注者がシステム開発を完全に丸投げすると、以下のような負のスパイラルが起きます。

発注者が要件をあいまいにする

ベンダーが「たぶんこういう意味だろう」で開発を進める

完成品が業務に合わない

「こんなものを作れとは言っていない」vs「こう指示された」

追加開発費用・納期遅延・最悪は訴訟

発注者がプロジェクトに主体的に関与することが、この負のスパイラルを断ち切る唯一の方法です。


関連する規格・RFC

規格・文書内容
経産省モデル取引・契約書(2007年・2013年改訂)発注者とベンダーの役割・責任を整理した標準契約書のひな形
IPA「情報システムの信頼性向上のための取引慣行・契約に関する研究会」報告書発注者責任を含む取引慣行の課題と改善策を提言

関連用語