要望、要求、要件の違いとか、基本設計、詳細設計の違いで迷わないようにするためのまとめ

# 何のため？
- たまたま「[予定通り進まないプロジェクトの進め方](https://www.amazon.co.jp/dp/B07BQQVVZR)」を読んでいたら、レストランの注文をうまくユーザーの要望・要求・仕様に例えていて分かりやすく、もう少し掘り下げて整理したいと思ったのと、システム開発の上流工程周辺（企画とか詳細設計含める）は工程やドキュメントの種類が多く自分自身よく混乱するので、改めて勉強して、まとめておくためです。
- 主観も混ざっていますので、参考程度にしていただければと思います。

# そもそもなぜ混乱しやすい？
- 概ね下記のような理由だと考えています。
    - 同じような言葉が多い
        - 要望/要求/要件
        - 設計/仕様
        - 仕様書/定義書
    - 各組織の文化的な要素もあり、会社、メンバー、業務委託構造によって、各工程やドキュメントの呼び方が若干異なることがある。
        - 要求仕様書なのか、要求定義書なのか、要件仕様書なのか、要件定義書なのか、など
        - 機能仕様書、機能要件定義書、など

# レストランの注文例
- ちなみに「[予定通り進まないプロジェクトの進め方](https://www.amazon.co.jp/dp/B07BQQVVZR)」に記述されていた要望・要求・仕様にあたるレストランの注文工程を自分なりにまとめ、基本設計と詳細設計も加えると次のようになるかと思います。ここでの仕様は要件に書き換えています。

| 要望 | 要求 | 要件 |
|---|---|---|
| レストランに来た理由 <br> ・なるべく早く空腹を満たしたい<br>・食事を楽しみたい<br>   | ホールスタッフと相談して、具体化した要求<br>・ボリューム感のあるメニュー<br>・デザートも<br>・卵アレルギーも考慮  | オーダー<br>・あんかけチャーハン、人数分<br>・アレルギーの人には卵抜き<br>・アイスクリーム人数分

| 基本設計 | 詳細設計 |
|---|---|---|
| レシピ（材料、分量）、盛り付け  | レシピ（調理方法、調理工程）、調理器具の種類  

# マイホーム作りの例
- ついでにIPA発行の「[家づくりで理解する要求明確化の勘どころ ～システム構築を成功させる要件定義のポイント～](https://www.ipa.go.jp/sec/reports/20180327.html)」を参考にすると、マイホーム作りは下記のようになるかと思います。

| 要望 | 要求 | 要件 |
|---|---|---|
| 家が欲しいと思った理由<br>・結婚するから<br>・子供がほしいから | 住宅アドバイザーと相談して、具体化した要求<br>・家族で楽しく暮らすためにリビングを広めにしたい<br>・子供の成長に合わせて、用途を変えていける間取りにしたい  | 建築家に伝える内容<br>・各部屋の用途、天井の高さ、窓の数や種類、キッチンのスペック、など  |

| 基本設計 | 詳細設計 |
|---|---|
| 設計図、間取り、素材、など  | 工法、など

# 要望、要求、要件の違いとか
- 上記例とか、諸々の文献・サイトから、要望、要求、要件、基本設計、詳細設計を次のようにまとめてみました。
- 工程的には、要望・要求・要件が「要件定義」や「要件開発」と呼ばれるようです。
- 要望は、企画書に含まれる内容にもなるかと思います。

|| 要望 | 要求 | 要件 |
|---|---|---|---|
|簡単に言うと| ~したい | （より具体的に）～したい | ～が必要です、これでお願いします<br>※ベンダーに依頼する内容  | 
|アウトプット（内容）| コンセプト<br>ユーザーニーズ<br>ビジネスニーズ<br>マーケティング<br>予算、スケジュール | 優先度を考慮した要求<br>As-Isと比較したTo-Be<br>登場人物とそれぞれの立場での要求<br>要求の目的展開（手段と目的を分別）、目的から手段の再構築した要求<br>制約（予算、工数）を反映した要求  | 機能要件、UI/UX要件<br>非機能要件<br>※抜け、漏れ、曖昧性が無い要求  |
|注意点| 一般的に下記の問題が発生しやすい。<br>手段しか書かない、または目的と手段が区別されておらず、要望側で手段に対する知見が少ないことが多く、目的と手段が矛盾する<br>分野に対する知見が少なく、要求に対して考慮すべき内容が漏れてしまう。<br>とりあえずの優先度不明の要求を入れてしまう | 左記リスクをヘッジするのが目的<br>この工程次第でプロジェクトの成功可否が決まることが多い | 一般的にこれがベンダーに依頼する内容であり、責任分岐点となるため、ベンダーとの合意が必要<br>場合によっては、この工程も含めて依頼することもある  |

|| 基本設計 | 詳細設計 |
|---|---|---|
|簡単に言うと| 要件を満たすために～と～を作る<br>ユーザーに見える部分（Input/output）について決める<br>※作り手・作り方・道具の都合も考慮する  | 基本設計で決められたものを作るために～のように作る、そのために～を使う<br>作り方、道具の説明、ユーザーに見えない部分について決める<br>※全て作り手の都合
|アウトプット（内容）| システム仕様<br>機能仕様<br>画面仕様<br>※howではなくwhatであり、基本設計なのに内容は「設計」とは言わない  | アーキテクチャ設計<br>API設計<br>クラス設計
|注意点| 実装者に依頼する内容であり<br>実装者との合意が必要  | --


# 用語定義の補足
- 仕様と設計
    - いろんなサイトで説明されていて、仕様は「what、何を作るか」を定義したもの、設計は「how、どうやって作るか」を定義したもの、という認識でいいかと思います。
        - [こちら](https://wa3.i-3-i.info/diff17document.html)のサイトがシンプルで分かりやすい
- 仕様書と定義書
    - 例えば、要求仕様書と要求定義書は何が違うのか？
        - 一般的には、要求仕様書と要件定義書であって、要求定義書とはあまり言わない
        - ちなみに要件仕様書ともあまり言わない
        - 個人的には、定義書も仕様書も大差無く、前にかかってくる言葉で使い分けるもの、と解釈しています。

# 参考サイト・文献
- [予定通り進まないプロジェクトの進め方](https://www.amazon.co.jp/dp/B07BQQVVZR)(Amazon)
- [家づくりで理解する要求明確化の勘どころ ～システム構築を成功させる要件定義のポイント～](https://www.ipa.go.jp/sec/reports/20180327.html)(DL可)
- [ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ](https://www.ipa.go.jp/ikc/reports/20190912.html)(DL可)
- [要件開発入門～要求を要件に仕上げるコツと真髄～](http://labo.mamezou.com/special/sp_007/)
- [要望・要求・要件・仕様・制約・前提の違いは？](https://qiita.com/digdagdag/items/2808205d89344ab8a3a1)
- https://wa3.i-3-i.info/diff17document.html