目次

1. はじめに
2. 1-1. 「想定外」のギャップとは何か
3. 1-2. システム開発における「前提の食い違い」の構造
4. 2-1. 典型的な失敗事例
5. 2-2. なぜ誤解が発生するのか
6. 3-1. 発注側の視点：対策と工夫
7. 3-2. 受注側の視点：防止策と進め方
8. 4-1. 双方の認識を合わせる具体的な方法
9. 1. まとめ

---

1. はじめに

システム開発の現場では、「そんなつもりじゃなかったのに」「完成したものがイメージと違う」という事態が頻発します。これは、発注者と開発者の間で要件や期待値のすり合わせが不十分であることに起因しています。本記事では、そうした齟齬が生じる背景と、その具体的な対策方法について徹底解説します。

1-1. 「想定外」のギャップとは何か

発注者と受注者の間にある「言った・言わない」や「仕様書に書いてない」のような摩擦は、多くの企業にとって大きな問題です。以下のようなケースが代表的です：

• 発注者：ボタンを押したら自動計算してくれると思っていた
• 受注者：その処理は書かれていなかったため、実装していない

このような想定のズレ＝期待ギャップが、開発遅延や追加工数、最悪はプロジェクトの失敗につながることもあります。

1-2. システム開発における「前提の食い違い」の構造

開発におけるギャップの多くは、以下の3つの段階で発生します：

フェーズ	主な食い違いの要因
要件定義	ユーザーの「暗黙の了解」が明文化されていない
設計・実装	仕様解釈の違いや詳細未定義項目の扱いが不明瞭
テスト・受け入れ	検収基準が曖昧で期待品質とのズレが顕在化

2-1. 典型的な失敗事例

以下のような実例があります：

ケース1：業務フローを共有しないまま開発開始

• 背景：業務の属人化が進んでおり、開発側が業務の全体像を把握できていない
• 結果：ユーザーの本質的な課題を解決できないシステムが納品される

ケース2：ドキュメントの不備

• 背景：口頭やチャットでのやり取りに頼って仕様書が不完全
• 結果：受注者は仕様外の修正を「追加要件」として工数請求、発注者は「当たり前」と感じて反発

2-2. なぜ誤解が発生するのか

1. 言語化されていない期待値：ビジネス側が持つ「当たり前」は、技術側にとっては未知の要件
2. 専門用語の非対称性：業務用語 vs システム用語のすれ違い
3. ドキュメント文化の希薄化：アジャイル開発の影響で仕様書軽視が進行

3-1. 発注側の視点：対策と工夫

発注者として、以下の点を徹底することが重要です。

(1) ユースケースで要件定義する

「機能」ではなく「どう使うか」を中心に記述します。

(2) UI/UXモックを用意する

FigmaやAdobe XDなどで画面イメージを共有すると、イメージのズレが減ります。

(3) 受入基準を明文化する

「何ができていれば納品とみなすか」を文書化しておくことで、検収段階のトラブルを防ぎます。

3-2. 受注側の視点：防止策と進め方

(1) 要件レビューの場を複数設ける

仕様書が完成したら、発注者と再確認の時間を設定し、理解齟齬の解消を図ることが必要です。

(2) スプリントデモで中間レビュー

アジャイルならスプリントごとに成果物のレビューを実施することで、認識のズレを早期発見できます。

(3) 議事録・プロトコルを必ず残す

口頭合意やチャットでのやりとりも含め、記録を残し証跡管理することがトラブル防止につながります。

4-1. 双方の認識を合わせる具体的な方法

手段	説明	メリット
ワイヤーフレームの共有	初期設計段階でUIの共通認識を形成	ビジュアル的に誤解が少ない
エピック/ストーリーの導入	ユーザーストーリーを中心とした機能整理	ビジネス的意図を含めた開発が可能
定例会の記録共有	毎週の進捗報告と議事録の双方向確認	誤解や記憶違いを即修正できる

また、近年ではAIによる議事録要約・要件抽出ツール（例：Notta、Jamiroなど）も活用が進んでおり、齟齬を減らすテクノロジー的支援も有効です。

5. まとめ

システム開発の現場で「思っていたものと違う」成果物が生まれるのは、極めて一般的な問題です。しかし、発注者と受注者の双方が「認識合わせ」を意識的に行うことで、未然に多くのトラブルを防ぐことができます。

• 要件は「使い方ベース」で定義する
• モックや図を使って視覚的にすり合わせる
• 定期レビューと記録の徹底

これらを実践することで、「想定外」を「想定内」へと変えることが可能です。プロジェクト成功の鍵は、「コミュニケーション設計」にあると言えるでしょう。

[cv:issue_marketplace_engineer]