

## 目次

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

---

## 1. はじめに

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

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

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

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

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

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

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

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

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

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

### ケース1：業務フローを共有しないまま開発開始
- **背景**：業務の属人化が進んでおり、開発側が業務の全体像を把握できていない
- **結果**：ユーザーの本質的な課題を解決できないシステムが納品される

### ケース2：ドキュメントの不備
- **背景**：口頭やチャットでのやり取りに頼って仕様書が不完全
- **結果**：受注者は仕様外の修正を「追加要件」として工数請求、発注者は「当たり前」と感じて反発

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

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

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

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

### (1) ユースケースで要件定義する
「機能」ではなく「どう使うか」を中心に記述します。

![img](/mosaic-code.jpg)

### (2) UI/UXモックを用意する
FigmaやAdobe XDなどで画面イメージを共有すると、イメージのズレが減ります。

### (3) 受入基準を明文化する
「何ができていれば納品とみなすか」を文書化しておくことで、検収段階のトラブルを防ぎます。

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

### (1) 要件レビューの場を複数設ける
仕様書が完成したら、発注者と再確認の時間を設定し、**理解齟齬の解消**を図ることが必要です。

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

### (3) 議事録・プロトコルを必ず残す
口頭合意やチャットでのやりとりも含め、記録を残し**証跡管理**することがトラブル防止につながります。

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

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

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

## 5. まとめ

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

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

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

[cv:issue_marketplace_engineer]





## 目次

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

---

## 1. はじめに

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

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

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

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

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

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

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

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

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

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

### ケース1：業務フローを共有しないまま開発開始
- **背景**：業務の属人化が進んでおり、開発側が業務の全体像を把握できていない
- **結果**：ユーザーの本質的な課題を解決できないシステムが納品される

### ケース2：ドキュメントの不備
- **背景**：口頭やチャットでのやり取りに頼って仕様書が不完全
- **結果**：受注者は仕様外の修正を「追加要件」として工数請求、発注者は「当たり前」と感じて反発

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

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

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

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

### (1) ユースケースで要件定義する
「機能」ではなく「どう使うか」を中心に記述します。

```markdown
例：× 売上登録画面を作る → ○ 営業担当が1クリックで当日売上を記録・確認できる
```

### (2) UI/UXモックを用意する
FigmaやAdobe XDなどで画面イメージを共有すると、イメージのズレが減ります。

### (3) 受入基準を明文化する
「何ができていれば納品とみなすか」を文書化しておくことで、検収段階のトラブルを防ぎます。

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

### (1) 要件レビューの場を複数設ける
仕様書が完成したら、発注者と再確認の時間を設定し、**理解齟齬の解消**を図ることが必要です。

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

### (3) 議事録・プロトコルを必ず残す
口頭合意やチャットでのやりとりも含め、記録を残し**証跡管理**することがトラブル防止につながります。

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

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

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

## 5. まとめ

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

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

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

[![image](https://firebasestorage.googleapis.com/v0/b/issue-pro-42602.appspot.com/o/topics%2F17fa658b-53c7-4ca0-a28b-e588ed1bd371?alt=media&token=2c00afff-85ff-4428-8d15-696ab676dcb0)](https://i-ssue.com/lp/check_salary)



目次

続きは、単価診断を受けたエンジニア限定で公開中（30秒）

続きは、
単価診断を受けたエンジニア限定で公開中（30秒）