システム開発を外注して、ようやく完成品が納品された。ひとまずシステムを触ってみたものの、「なんか思っていたものと違う」「あの機能はどこにいったんだろう」「こんな操作手順だったかな」——そんな感覚を覚えた方は少なくないはずです。
完成したシステムが想定と違うという状況は、決して珍しいことではありません。システム開発において、発注者と開発者の間で認識のズレが生じることは、長年にわたって業界全体が抱える課題のひとつです。
しかし問題は「想定と違う」という事実ではなく、そこから「何をどう動けばいいか分からない」という状態に陥ることです。「ベンダーに言いたいけど費用がかかるかもしれない」「自分の伝え方が悪かったのかもしれない」「今さら言っても遅いのでは」——こうした不安が行動を阻んでしまうことが多いのです。
この記事では、完成したシステムが想定と違うと感じたときに発注者が取るべき具体的な対処ステップを解説します。まずは「どのような問題が起きているか」をパターン別に整理し、次に書類確認で費用負担の判断基準を把握した上で、ベンダーへの修正依頼を適切に進める方法を説明します。「何から手をつければいいか」が明確になることを目指しています。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
完成システムが「想定と違う」と感じる4つのパターン
完成したシステムへの不満を「想定と違う」という一言でまとめてしまいがちですが、問題の本質はいくつかのパターンに分類できます。自分のケースがどれに当てはまるかを最初に把握することで、対処方法と費用負担の見通しが立てやすくなります。
パターン1: 機能が漏れている
要件定義書や仕様書に記載した機能が実装されていない、または不完全な状態で納品されたケースです。
たとえば「月次集計データをCSVでエクスポートする機能」を明記したにもかかわらず、完成品にその機能が存在しない、あるいはCSV形式ではなく別のフォーマットで出力されるといった状況が該当します。
このパターンは費用負担の観点では最も判断がシンプルです。書類に記載があれば、発注者側が無償修正を求める根拠が最も強いケースです。
パターン2: 仕様の解釈が違った
要件定義書や仕様書には記載があったものの、発注者と開発者の間で解釈が食い違い、意図と異なる実装になったケースです。
たとえば「画面上の数値をリアルタイムで更新する」という要件に対し、発注者は「ページの自動更新なしに数値が変わる」ことを期待していたが、実装されたのは「ページ更新時に最新値を表示する」という仕組みだった、といった状況です。
このパターンは要件の記載が曖昧だった場合、費用負担の交渉が必要になることがあります。議事録やメール等で「どのような説明がなされたか」を確認することが重要です。
パターン3: 使い勝手が想定と違う
機能的には要件を満たしているが、画面の操作感・UI・ワークフローの設計が期待と大きく異なるケースです。
「データの入力フォームが複数ページに分かれていて操作が煩雑」「ボタンの配置が直感的でなく、慣れるまで時間がかかる」といった状況が典型例です。
このパターンは「機能漏れ」や「解釈の違い」とは異なり、発注者が具体的なUI仕様を指定しなかった場合には発注者側の課題である可能性が高く、改善には追加費用が発生することが多いです。ただし、著しく使いにくい場合や業務上の支障が生じる場合は交渉の余地があります。
パターン4: 業務フローとかみ合わない
システム自体は正常に動作するが、自社の現場業務の流れとシステムの設計が合っていないケースです。
たとえば「受注→在庫確認→出荷指示」という業務フローで使うつもりだったシステムが、実際には「在庫確認→受注→出荷指示」の順序でしか操作できない設計になっていたり、現場の担当者が実際に使ってみると「このシステムでは今の業務ができない」という問題が発覚したりするケースです。
このパターンは、要件定義の段階で現場業務の詳細なフローを十分に伝えられていなかったことが原因であることが多く、費用負担の判断が複雑になります。
まず行うべき準備——問題を整理するための書類確認
ベンダーに連絡する前に、手元の書類を確認して「自分側の問題か・ベンダー側の問題か」を整理することが重要です。感情的に「思っていたものと違う」という主張をするのではなく、書類に基づいた客観的な根拠を持って交渉に臨むことで、問題解決が格段にスムーズになります。
確認すべき3つの書類
1. 要件定義書・仕様書
プロジェクト開始時に合意した要件定義書や機能仕様書を確認します。問題だと感じている点が「そもそも要件として明記されていたか」を確認します。
要件定義書の記載内容が曖昧な場合や、そもそも要件として記載されていなかった場合は、発注者側の課題である可能性があります。逆に、明確に記載されているにもかかわらず実装されていない場合は、開発者側への修正依頼が正当化されます。
2. 会議の議事録・メールのやり取り
要件定義書に明記されていない部分については、打ち合わせの議事録やメール上でどのような説明・合意がなされたかを確認します。口頭での約束や電子メールでの確認内容も、契約上の根拠として有効です。
裁判例でも、ステアリング・コミッティでの合意内容の判断にあたって議事録の記載内容が重視されており（川崎フォース法律事務所「システム開発プロジェクトで議事録を残しておく意味」）、議事録の有無・内容は非常に重要です。
3. 契約書・注文書
「何をどの範囲まで開発するか」を定めた契約書・注文書の内容を確認します。特に「成果物の定義」「瑕疵担保責任（契約不適合責任）の期間・内容」の条項が重要です。
「発注者責任」と「ベンダー責任」の判断基準
書類確認の結果をもとに、以下の判断基準で費用負担の目安を把握します。
状況 | 費用負担の目安 |
|---|---|
要件定義書・仕様書に記載がある → 実装されていない | ベンダー責任。無償修正を求める根拠が強い |
議事録・メールで合意されている → 実装されていない | ベンダー責任寄り。記録の内容次第で交渉の余地あり |
要件定義書に記載がなく、口頭でも確認できない | 発注者側の追加要望として有償対応になる可能性が高い |
機能は実装されているが仕様の解釈が違う | 双方の認識を確認しながら着地点を交渉する |
UIや操作感が想定と違う（仕様は満たしている） | 発注者側の追加要望として有償対応になることが多い |
問題の整理メモを作成する
書類確認が終わったら、以下の内容を記録した「問題の整理メモ」を作成します。この文書がベンダーへの修正依頼時の根拠資料になります。
- 問題の内容（どの機能・どのページ・どの操作）
- 書類上の根拠（要件定義書の何ページ、または議事録の何日付け）
- 発注者側の期待する動作
- 現状の動作との差異
- 修正の優先度（業務に支障が出るか否か）
パターン別の対処ステップ
書類確認の結果を踏まえ、パターン別の対処手順を説明します。
パターン1「機能漏れ」への対処
1. 書類で記載を確認する 要件定義書・仕様書・議事録のどこかに当該機能の記載があるかを確認します。
2. 書類を根拠に修正を依頼する 書類に記載がある場合は、その箇所を明示した上でベンダーに修正を依頼します。「仕様書の○ページ○項に記載のCSVエクスポート機能が実装されていません。仕様書に基づく修正として、対応をお願いします」という形で、書類番号・ページ数を具体的に示すことが重要です。
3. 修正期限と確認方法を合意する 修正の完了期限と、修正後の確認方法（再度の受け入れテストを行うかどうか等）をベンダーと合意します。
パターン2「仕様の解釈違い」への対処
1. 双方の認識を確認する 「発注者の意図」と「開発者が解釈した仕様」の両方を書面で整理し、どこで認識がズレたかを特定します。感情的に「違う」と主張するのではなく、「私の意図はこういう動作でした」「開発側の解釈はこういうことでしたか」という形で確認するのが効果的です。
2. 議事録・メールで合意内容を確認する 打ち合わせで口頭で伝えた内容に関する議事録やメールがあれば、それを提示して「こういう説明をした記録があります」と伝えます。
3. 着地点を交渉する 書類に記載がなく、口頭のみの合意であった場合は、費用負担を含めた交渉が必要になります。「書類に記載がなかった部分については費用をご負担いただきます」というベンダーの主張も正当な場合があります。双方が歩み寄れる着地点を見つけることが大切です。
パターン3「使い勝手の問題」への対処
1. 問題点を具体的に整理する 「直感的でない」「操作が分かりにくい」といった抽象的な表現ではなく、「画面Aから画面Bへの遷移に毎回3クリック必要で、1日に100回行う業務に支障が生じる」という具体的な影響を記録します。
2. 業務上の支障の深刻度を判断する 単なる「好みの問題」なのか「業務上の実害が出ている」のかによって、交渉の方針が変わります。業務効率に実害があるのであれば、その影響を具体的に数値化（例: 作業時間が1日あたり○分増える）することで交渉力が上がります。
3. 有償改善として依頼する 仕様を満たしているUIに関しては、改善は基本的に有償の追加開発になります。予算の観点から改善の優先度を整理し、本当に必要な改善に絞って依頼するのが現実的です。
パターン4「業務フロー不一致」への対処
1. 「システム側を変えるか・業務側を変えるか」を判断する 業務フローとシステムが合わない場合、必ずしもシステム側を修正する必要はありません。業務フローを変更（効率化）することで対応できる場合もあります。
まずは「どちらを変えた方がコスト・効果の観点で優れているか」を検討します。特に、現状の業務フロー自体が非効率だったとすれば、システムに合わせて業務を変えることが好ましい場合もあります。
2. 要件定義書を確認し、業務フローが記載されていたか確認する 業務フローが要件定義書や添付資料として提供されていたか確認します。業務フロー図を渡していた場合は、それと異なる設計になっている理由をベンダーに確認します。
3. システム修正が必要な場合は改修工数を確認する 業務フローに合わせたシステム修正が必要な場合は、どの程度の修正規模になるか（追加開発工数・費用の目安）をベンダーに確認します。要件定義書に業務フローの記載がなかった場合は有償追加になる可能性が高いですが、開発者側にも「業務フローを確認せずに設計した」という過失がある場合は費用交渉の余地があります。
ベンダーへの修正依頼の進め方——費用・交渉・記録
修正依頼は書面で行う
口頭での修正依頼は「言った・言わない」のトラブルに発展するリスクがあります。修正依頼は必ずメールや文書で記録を残すことが重要です。
修正依頼書（メール）には以下の内容を含めることが望ましいです。
- 問題の内容（具体的な箇所・症状）
- 書類上の根拠（要件定義書のどの記載に基づくか）
- 期待する修正後の動作
- 修正を求める根拠（無償修正を求める場合はその理由）
- 対応を依頼する期限
費用負担の基本的な考え方
無償修正が認められるケース:
- 要件定義書・仕様書に記載された機能が実装されていない場合
- 実装された機能にバグ・不具合がある場合（契約不適合責任・瑕疵担保責任の範囲）
有償追加になりやすいケース:
- 要件定義書に記載がなかった機能の追加
- UIや操作感の改善（仕様は満たしているが発注者の好みに合わせる変更）
- 開発後に発注者側から生じた「やっぱりこうしてほしい」という変更
なお、「仕様変更による追加費用」の詳しい仕組みについては、「システム開発の仕様変更で追加費用が発生する原因と、発注者が取れる具体的な防止策」でも詳しく解説しています。
交渉がこじれた場合の対処
ベンダーとの交渉が難航する場合は、以下の方法があります。
第三者機関の活用: IPAの「情報システム・ソフトウェア取引トラブル相談窓口」や、各都道府県の中小企業支援センター等に相談する方法があります。
ADR（裁判外紛争解決手続き）の活用: 訴訟に至る前に、第三者の調停者を介した話し合いで解決を図る方法です。システム開発のトラブルに対応した法律事務所への相談も有効な選択肢です。
ただし、多くのケースでは適切なコミュニケーションと書類の確認によって解決できます。第三者機関や法的手段は、交渉が完全に行き詰まった場合の最終手段として考えてください。
同じ失敗を繰り返さないための再発防止策
今回の問題を次回の発注に活かすために、開発プロセスの改善策をまとめます。
要件定義の質を上げる
「想定と違う」問題の多くは、要件定義の段階で発注者の意図を十分に言語化・可視化できなかったことに起因します。
次のプロジェクトでは、以下のアプローチが効果的です。
業務フロー図の作成: 自社の業務フローを図で可視化し、「誰が・どのタイミングで・何を操作するか」を明確にすることで、開発者との認識ズレを防ぐことができます。
画面モックアップの活用: 実際に開発を始める前に、画面イメージのラフスケッチや簡易モックアップを作成し、発注者・開発者双方で確認することで、UIに関する認識ズレを早期に発見できます。
要件定義書の読み合わせ: 完成した要件定義書を、開発者と発注者が一緒に声に出して読み合わせることで、解釈の違いを発見できます。「ここはどういう意味ですか」という質問を積極的に行うことが重要です。
中間確認のサイクルを設ける
完成するまで何も確認できない「ウォーターフォール型」の進め方では、完成後に初めて問題が発覚するリスクがあります。
開発の途中段階で動作するものを確認できる機会（中間レビュー・デモ）を設け、早い段階で「これは意図通りだろうか」を確認することが、最終的な手戻りを最小化します。アジャイル開発のスプリントレビューのように、2〜4週間ごとに進捗を確認する体制を組むことが理想的です。
伴走してくれる開発パートナーを選ぶ
「要件を決めたら後はお任せ」という開発体制では、発注者が途中で問題に気づくことが難しくなります。発注者に積極的に確認を求め、中間デモや定例ミーティングを通じて認識合わせを継続してくれる開発会社を選ぶことが、「完成後に想定と違う」という問題を根本的に防ぐ最も確実な方法です。
なお、システム開発の受け入れテストの具体的な進め方については「システム開発の検収・受け入れテストの進め方｜非エンジニアでもできる確認手順とチェックリスト」で詳しく解説しています。また、「なぜシステム開発プロジェクトが失敗するのか」という原因の全体像を把握したい方は「システム開発が失敗する原因とは？フェーズ別に解説する防止策と発注側のチェックポイント」もあわせてご覧ください。
完成したシステムが想定と違うと感じたとき、まずは問題を4つのパターンに分類し、手元の書類を確認することから始めましょう。書類に記載がある問題については、発注者として正当に無償修正を求める根拠があります。書類に記載のない部分については費用負担の交渉が必要になりますが、問題を整理した上で書面で依頼することで、ベンダーとの認識合わせがスムーズに進みます。
「想定と違う」という感覚を漠然と持ち続けるのではなく、この記事で紹介したステップに沿って一つずつ整理していくことで、問題解決の糸口が見えてきます。まずは手元の要件定義書・仕様書・議事録を確認するところから始めてみてください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
