※小説ではない※専門書 要約資料集 為替(換算)3.9万円でもらう 紐解集生成 専門 初入門 資料 作：｛作者名｝
> 学問の宇宙・応用の軌道ステーション群「作る力と生きる力シリーズ」計算機文明部 第6巻。ガイド役: Fable 5 監修 / Sonnet 5 執筆(脚本班)
> トーン規約: GAKUMON_UNIVERSE.md準拠。専門用語は初出で必ず説明する。
> **安全枠(§16.18・絶対厳守)**: 本冊に登場する依頼主・店舗・企業・製品・システムはすべて架空の事例であり、実在のいかなる企業・製品・個人とも無関係である。特定の実在企業・実在製品を名指しして批判・誹謗する文脈は一切用いない。実務で要件定義を行う際は、必ず依頼主本人・関係者との対話に基づいて要件を確定させるべきであり、本冊の架空事例をそのまま実務に流用してはならない。
> 接続先: →BOOK-0343『情報構造の設計』(確定した要件をどんなデータ構造で実現するかは、そちらが土台になる)、→BOOK-0344『文章の解析と解読』(依頼文・要望文というあいまいな自然言語を読み解く技術は、そちらと接続する)、→BOOK-0346『建築構造の基礎』(建築分野での要件定義=用途・荷重条件の確定は、そちらで扱う)。
> 水準: 一〜十二(「使いやすくしてほしい」という要望が仕様として不十分な理由という土台から、要望の奥にある目的の掘り当て、検証可能な言葉への変換、ステークホルダーの利害対立、機能要件と非機能要件の区別、要件の文章化、良い要件の検査、制約条件の洗い出し、スコープ管理、プロトタイプとデザイナー思考、要件定義書とトレーサビリティ、そして優先順位づけとトレードオフまでを扱う)。
# BOOK-0345 作る力と生きる力: 要件定義とデザイナー思考 — 「使いやすくして」をどう仕様書に変えるか
> 学問の宇宙・応用の軌道ステーション群「作る力と生きる力シリーズ」計算機文明部 第6巻。ガイド役: Fable 5 監修 / Sonnet 5 執筆(脚本班)
> トーン規約: GAKUMON_UNIVERSE.md準拠。専門用語は初出で必ず説明する。
> **安全枠(§16.18・絶対厳守)**: 本冊に登場する依頼主・店舗・企業・製品・システムはすべて架空の事例であり、実在のいかなる企業・製品・個人とも無関係である。特定の実在企業・実在製品を名指しして批判・誹謗する文脈は一切用いない。実務で要件定義を行う際は、必ず依頼主本人・関係者との対話に基づいて要件を確定させるべきであり、本冊の架空事例をそのまま実務に流用してはならない。
> 接続先: →BOOK-0343『情報構造の設計』(確定した要件をどんなデータ構造で実現するかは、そちらが土台になる)、→BOOK-0344『文章の解析と解読』(依頼文・要望文というあいまいな自然言語を読み解く技術は、そちらと接続する)、→BOOK-0346『建築構造の基礎』(建築分野での要件定義=用途・荷重条件の確定は、そちらで扱う)。
> 水準: 一〜十二(「使いやすくしてほしい」という要望が仕様として不十分な理由という土台から、要望の奥にある目的の掘り当て、検証可能な言葉への変換、ステークホルダーの利害対立、機能要件と非機能要件の区別、要件の文章化、良い要件の検査、制約条件の洗い出し、スコープ管理、プロトタイプとデザイナー思考、要件定義書とトレーサビリティ、そして優先順位づけとトレードオフまでを扱う)。
---
## 入口の物語 — 「使いやすくしてほしい」という一言
商店街の外れにある小さなパン屋「ひなたベーカリー」のオーナー、宮田路子(みやたみちこ)さんは、ある朝、駆け出しのデザイナー事務所に一本の電話をかけた。「お客さんが使いやすい注文システムを作ってほしいんです。今どき紙の予約表じゃ恥ずかしくて」。電話を受けた新人デザイナーは、二つ返事で引き受けた。「使いやすいシステム」――言葉としては明快に思えたし、世の中には注文アプリの見本もいくらでもある。彼は一週間かけて、スマートフォンで焼きたてパンの写真を選び、ボタン一つで決済まで完了する、洗練された試作品を仕上げて宮田さんに見せた。
ところが宮田さんの反応は芳しくなかった。「これじゃダメなんです。うちのお客さんは常連のお年寄りが多くて、スマホの操作なんて誰もしません。私が困っているのは、朝のピーク時間に焼きたてを求めて行列ができて、常連さんが『また今度でいいや』と諦めて帰ってしまうことなんです」。新人デザイナーは言葉を失った。「使いやすい」という一言をそのまま形にしただけで、宮田さんが本当に困っていたことには、まったく触れられていなかったのだ。
見かねた先輩デザイナーが助け船を出した。「『使いやすくしてほしい』は、依頼主の頭の中にある理想の風景をひとことに圧縮した**要望(ようぼう、水準一: 依頼主が言葉にした、まだ検証できる形になっていない願望や希望)**にすぎない。それをそのまま作ってしまうのは、地図も見ずに歩き出すのと同じだ。私たちの仕事は、その要望を、誰が読んでも同じように理解でき、できたかどうかを確かめられる**要件(ようけん、水準一: 要望を掘り下げ、検証可能な形に具体化した、実現すべき事柄の記述)**に変換することなんだ。要件が集まって整理されたものが、そのまま設計や施工の指示書になる**仕様書(しようしょ、水準一: 要件を体系的にまとめ、作り手が迷わず実現できるように整えた文書)**になる」。
この一言が、この巻の出発点になる。宮田さんの「使いやすくしてほしい」という一言を、実際に行列を減らし、常連客を離さない仕組みへと磨き上げていく過程を追いながら、曖昧な理想図を検証可能な仕様書に変える方法論――ソフトウェア開発だけでなく、建築や製品デザインにも共通する「デザイナー思考」の土台――を、一段ずつ積み上げていく。
---
## 第一章: 「使いやすくしてほしい」は仕様ではない(水準一)
### なぜ曖昧な言葉のままでは作れないのか
「使いやすい」「かっこよく」「もっと便利に」――依頼主の口から出てくる要望の多くは、こうした形容詞で語られる。形容詞そのものが悪いわけではない。むしろ、依頼主が本当に困っていることや理想としている風景を、短い言葉で伝えようとする自然な圧縮の結果である。問題は、この圧縮された言葉が、聞き手によってまったく違う形に展開されてしまう点にある。新人デザイナーは「使いやすい」を「タッチパネルで完結する会計」と展開したが、宮田さんの頭の中では「並ばずに焼きたてを受け取れること」だった。同じ一言から、まったく別の二枚の絵が浮かんでいたのである。
要望が仕様として不十分なのは、**検証できないから**である。「使いやすくなったかどうか」を、誰がどうやって確かめればよいのか、要望の言葉だけでは判定のしようがない。これに対して要件は、「朝のピーク30分間で、注文から受け渡しまでの待ち時間を平均5分以内にする」のように、達成できたかどうかを後から確かめられる形をしている。曖昧な理想図を、検証可能な文へと磨き上げること――これが要件定義という仕事の出発点である。
### 建築や製品デザインでも同じ構造がある
この構造は、ソフトウェア開発に限った話ではない。建築主が「明るい家にしてほしい」と依頼しても、それだけでは窓の大きさも方角も決まらない(→BOOK-0346)。製品デザインの現場でも、「持ちやすい取っ手にしてほしい」という要望だけでは、握る手の大きさも、素材の重さも定まらない。分野が違っても、依頼主の理想図を検証可能な要件に変換するという作業そのものは、驚くほど共通した手順を踏む。この巻では主にひなたベーカリーの事例を追いながら、折々に建築や製品デザインの例も添えていく。
---
> **定着量の目安(第一章)**: 「要望」と「要件」の違いを即座に言い分けられるようにするには、身の回りにある曖昧な依頼文(「もっと快適に」「シンプルにして」等)を10個ほど集め、それぞれについて「これは検証できるか」を自問する練習を重ねると、ほぼ確実に定着すると見込まれる。
---
## 第二章: 要望の奥にある目的を掘り当てる(水準二)
### ニーズとウォンツを見分ける
宮田さんが最初に口にした「使いやすいシステム」は、あくまで彼女が思いついた一つの解決手段(**ウォンツ〈wants〉、水準二: 依頼主が思いついた、具体的な解決手段や道具の希望**)であって、彼女が本当に解決したいこと(**ニーズ〈needs〉、水準二: 依頼主が抱えている、解決されるべき根本的な課題や困りごと**)そのものではなかった。先輩デザイナーは新人にこう教えた。「依頼主が口にする言葉のほとんどはウォンツだ。ニーズにたどり着くには、依頼主自身にもう一段、深く尋ねる必要がある」。
### 「なぜ」を繰り返して掘り下げる
先輩は宮田さんに、次のような対話を重ねた。
```
質問1: なぜ「使いやすいシステム」が欲しいのですか?
答え1: 今の紙の予約表だと、お客さんが並んで書き込むのが面倒だからです。
質問2: なぜお客さんが並ぶことが問題なのですか?
答え2: 朝の忙しい時間に行列ができて、待ちきれない常連さんが帰ってしまうからです。
質問3: なぜ常連さんが帰ってしまうと困るのですか?
答え3: 常連さんは毎日買いに来てくれる大事なお客さんで、離れてしまうと売上に直結するからです。
```
この「なぜ」を数回繰り返して根本原因にたどり着く手法は**深掘り質問(ふかぼりしつもん、水準二: 「なぜ」を繰り返し尋ねることで、要望の表面から根本的な課題〈ニーズ〉へとたどり着く聞き取りの技法)**と呼ばれる。三回ほど「なぜ」を重ねたところで、宮田さんの本当のニーズが見えてきた。「常連客が朝の行列に耐えられず離れてしまうのを防ぎたい」――これが、最初の一言「使いやすいシステム」の奥にあった、本当の目的だった。
### ステークホルダーという視点
要望を聞き取る相手は、依頼主一人とは限らない。宮田さんのほかにも、店で働くアルバイト店員や、実際にパンを買いに来る常連客も、この取り組みによって影響を受ける関係者である。こうした、要件の内容に利害を持つすべての人々を**ステークホルダー(水準二: ある取り組みの結果によって影響を受ける、または影響を与えるすべての関係者)**と呼ぶ。次章以降、宮田さん以外のステークホルダーの声も拾い上げていく。
---
> **定着量の目安(第二章)**: ニーズとウォンツを見分け、深掘り質問で根本原因にたどり着く型を身につけるには、架空の依頼文(「もっと速くしてほしい」等)に対して自分で「なぜ」を3回連続で書き出す練習を5例ほどこなすと、ほぼ定着すると見込まれる。
---
## 第三章: 曖昧な言葉を測れる言葉に変える(水準三)
### 「使いやすい」を数えられる言葉にする
ニーズがわかっても、それをそのまま作り手に渡すことはできない。「常連客が朝の行列に耐えられず離れるのを防ぎたい」という文もまだ、達成できたかどうかを確かめる物差しを持っていない。ここで必要になるのが**検証可能性(けんしょうかのうせい、水準三: ある要件について、実現できたかどうかを客観的に確認・測定できる度合い)**という考え方である。検証可能性を持たせるには、抽象的な言葉を、数えられる・測れる言葉に分解していく。
```
曖昧な要望: 「使いやすいシステムにしてほしい」
↓ 検証可能な要件へ分解
要件A: 朝のピーク時間帯(7時〜9時)における、注文から受け渡しまでの平均待ち時間を5分以内にする
要件B: 常連客が来店前に焼き上がり時刻を指定して予約できる仕組みを用意する
要件C: 予約の入力から完了までの操作を3ステップ以内で終えられるようにする
```
このように分解すると、完成後に「本当に達成できたか」を実際に時間を測ったり、操作回数を数えたりして確認できるようになる。
### 受け入れ基準という物差し
要件ごとに、「これが満たされていれば完成とみなす」という判定条件を添えておくと、依頼主と作り手のあいだで完成の基準がずれる事故を防げる。この判定条件を**受け入れ基準(うけいれきじゅん、水準三: ある要件が実現できたと認められるための、具体的で確認可能な条件)**と呼ぶ。たとえば要件Aの受け入れ基準は「開店から1週間、朝7時〜9時の待ち時間を実測し、平均が5分以内であること」のように書く。数字と確認方法がセットになっていることが、良い受け入れ基準の条件である。
---
> **定着量の目安(第三章)**: 曖昧な要望を検証可能な要件に分解し、受け入れ基準を添える型を身につけるには、身近な曖昧な要望(「もっと片付いた部屋にしたい」等)を3つ選び、それぞれに数値や確認方法を含む要件と受け入れ基準を自分で書き起こす練習をすると、ほぼ定着すると見込まれる。
---
## 第四章: 誰のための要件か — ペルソナと利害の対立(水準四)
### 声の大きい依頼主が全員を代表するとは限らない
宮田さんの要望は明確になってきたが、要件定義を宮田さん一人の言葉だけで進めるのは危険である。実際にシステムを使うのは、宮田さん本人だけでなく、レジに立つアルバイト店員や、注文する常連客たちだからだ。こうした利用者一人ひとりの典型像を具体的な人物として描いたものを**ペルソナ(水準四: ある製品やサービスを利用する典型的な人物像を、年齢・生活習慣・目的などとともに具体的に描いたもの)**と呼び、その人物が製品をどう使うかという一連の流れを**ユースケース(水準四: ある利用者が、ある目的を達成するために製品やサービスを使う、具体的な行動の一連の流れ)**と呼ぶ。
先輩デザイナーは、宮田さん以外に二人のペルソナを立てた。一人は毎朝7時半に来店する78歳の常連客・田中さん(スマートフォンの操作に不慣れ)、もう一人は週末だけ入る大学生アルバイトの高橋さん(レジ業務は初心者)である。
### 利害はしばしば衝突する
三人のペルソナが望むことを並べてみると、次のような食い違いが浮かび上がった。
```
宮田さん(オーナー): 行列を減らしたい。ただし新しい機器の導入費用は抑えたい
田中さん(常連客) : 並ばず受け取りたい。ただしスマホの複雑な操作は避けたい
高橋さん(店員) : レジ操作は簡単であってほしい。覚えることを増やしたくない
```
宮田さんが最初に思い描いた「スマホでボタン一つの注文アプリ」は、田中さんのようなスマホ操作に不慣れな常連客にとっては、かえって使いにくいものになりかねない。このように、複数のステークホルダーの要望が一つの答えでは同時に満たせない状態を**要求の衝突(ようきゅうのしょうとつ、水準四: 複数のステークホルダーの要望が、互いに矛盾したり両立が難しかったりする状態)**と呼ぶ。要求の衝突をどう裁定するかは、この巻の最終章(水準十二)で改めて扱う大きなテーマになる。
---
> **定着量の目安(第四章)**: ペルソナとユースケースを描き、要求の衝突を見つける型を身につけるには、一つのサービス(たとえば図書館の貸出手続き)について、立場の違う3人のペルソナを自分で作り、それぞれの要望を書き出して衝突点を探す練習を1〜2例行うと、感覚がつかめると見込まれる。
---
## 第五章: 機能要件と非機能要件を分ける(水準五)
### 「何をするか」と「どのくらい良いか」
要件には、大きく分けて二つの種類がある。一つは、システムが具体的に「何をするか」を定める**機能要件(きのうようけん、水準五: システムが実際に行う動作や、提供する機能そのものを定めた要件)**。もう一つは、その機能を「どのくらいの品質で」実現するかを定める**非機能要件(ひきのうようけん、水準五: 応答の速さ・使いやすさ・安全性など、機能そのものではなく、機能の質や条件を定めた要件)**である。
```
機能要件の例: 常連客が来店前に焼き上がり時刻を指定して予約できる
非機能要件の例: 予約画面の応答は1秒以内に返る/操作は3ステップ以内で完了する/
お年寄りの利用者でも文字が判読できる文字サイズにする
```
第三章で分解した「操作を3ステップ以内で終える」という要件Cは、機能ではなく品質を定めているので非機能要件にあたる。機能要件だけを満たしても、非機能要件が満たされなければ、田中さんのような利用者には結局「使いにくいもの」のままになってしまう。
### 建築における機能要件と非機能要件
この区別は建築設計にもそのまま当てはまる(→BOOK-0346)。「三部屋ある家にしてほしい」は部屋数という機能要件だが、「冬でも暖房を強くしなくても過ごせる断熱性能」は非機能要件にあたる。部屋数を満たしただけで、断熱性能が低ければ、依頼主が本当に求めていた「快適な家」にはならない。機能要件と非機能要件は、常にペアで検討する必要がある。
---
> **定着量の目安(第五章)**: 機能要件と非機能要件を即座に見分けられるようにするには、身近な製品(スマートフォンや家電など)の説明書やカタログから要件らしい文を10個ほど抜き出し、機能要件と非機能要件に仕分ける練習を行うと、ほぼ定着すると見込まれる。
---
## 第六章: 要件を文章に落とし込む型(水準六)
### 誰が・何のために・何ができるか
要件を思いつくまま箇条書きにすると、書く人によって粒度や書き方がばらばらになりやすい。そこで広く使われているのが、次のような定型文に沿って要件を書く方法である。この定型文で書かれた要件の一文を**ユーザーストーリー(水準六: 「〜としては、〜したい。なぜなら〜だからだ」という定型文の形で、利用者の立場から要件を一文にまとめたもの)**と呼ぶ。
```
型: 「〜としては、〜したい。なぜなら〜だからだ」
例1: 常連客としては、焼き上がり時刻を指定して予約したい。
なぜなら、仕事の合間に並ばずに受け取りたいからだ。
例2: アルバイト店員としては、予約の受け渡し確認をワンタップで済ませたい。
なぜなら、レジ業務と並行して素早く対応したいからだ。
例3: オーナーとしては、予約のキャンセル率を後から確認したい。
なぜなら、パンの仕込み量を調整する材料にしたいからだ。
```
「誰が」「何を」「なぜ」の三点が一文の中にそろっていることで、書き手が違っても要件の粒度がそろい、第四章のペルソナと第二章のニーズが自然と一文の中に組み込まれる。
### 受け入れ基準とセットで書く
ユーザーストーリーには、第三章で扱った受け入れ基準を添えておく。例1のユーザーストーリーであれば、「予約は開店30分前まで受け付けられる」「指定できる時刻は15分刻みで選べる」といった具体的な条件を添えることで、完成の判定がぶれなくなる。ユーザーストーリーと受け入れ基準は、いわば要件定義における最小の作業単位である。
---
> **定着量の目安(第六章)**: ユーザーストーリーの型「〜としては、〜したい。なぜなら〜だからだ」を使いこなすには、第四章で作った3人のペルソナそれぞれについて、ユーザーストーリーを2つずつ、合計6つ書いてみる練習を行うと、型が身体に馴染むと見込まれる。
---
## 第七章: 良い要件かどうかを検査する(水準七)
### 要件にも「品質検査」がある
要件を書き終えたからといって、それが良い要件とは限らない。書かれた要件そのものに欠陥がないかを検査する必要がある。よくある欠陥は、**曖昧性(あいまいせい、水準七: 一つの要件文が、複数の異なる解釈を許してしまう性質)**を残していること、複数の要件が互いに**矛盾(むじゅん、水準七: ある要件を満たそうとすると、別の要件が満たせなくなる関係)**していること、そして技術や予算の面でそもそも**実現可能性(じつげんかのうせい、水準七: ある要件が、与えられた技術・予算・期間の中で実際に達成できる見込みの度合い)**を欠いていることの三つである。
### SMART基準による点検
これらの欠陥をまとめて点検する物差しとして、**SMART基準(水準七: 要件が「具体的〈Specific〉」「測定可能〈Measurable〉」「達成可能〈Achievable〉」「関連性がある〈Relevant〉」「期限がある〈Time-bound〉」の5条件を満たしているかを点検する枠組み)**が広く使われている。
```
悪い要件の例: 「注文システムを速くする」
S(具体的か) → 何が「速い」のか不明瞭
M(測定可能か) → 数値の基準がない
A(達成可能か) → 判定不能(目標が不明瞭なため)
R(関連性) → ニーズとの結びつきが曖昧
T(期限) → いつまでに、という期限がない
良い要件への改善: 「開店から3か月以内に、朝のピーク時間帯における注文完了までの
平均時間を、紙の予約表運用時の8分から3分以内へ短縮する」
S→注文完了までの時間という具体的な対象 M→3分以内という数値
A→3か月という猶予の中で実現可能と技術検討済み R→常連客離れ防止というニーズと直結
T→開店から3か月以内という期限
```
先輩デザイナーは、第三章・第六章で作った要件のすべてに、このSMART基準を一つずつ当てはめて点検した。曖昧さが残っていた要件は、この点検作業を通じて次々と書き直されていった。
---
> **定着量の目安(第七章)**: SMART基準を使って要件の欠陥を見抜く力をつけるには、わざと曖昧に書かれた要件文を5つ用意し、それぞれどの条件(S・M・A・R・T)が欠けているかを指摘し、改善案を書き直す練習をすると、実務でも通用する水準に近づくと見込まれる。
---
## 第八章: 制約条件を洗い出す(水準八)
### どんな要件にも「枠」がある
良い要件が書けたとしても、それを無条件に全部実現できるとは限らない。予算・納期・技術・法律など、要件の実現を縛る前提条件を**制約条件(せいやくじょうけん、水準八: 予算・納期・技術水準・法規制など、要件の実現方法を制限する、動かしがたい前提条件)**と呼ぶ。宮田さんの案件では、次のような制約条件が洗い出された。
```
予算制約: 個人商店の規模であり、初期費用は30万円程度が上限
納期制約: 繁忙期(年末)の前に稼働させたい。着手から2か月以内
技術制約: 店の通信環境は家庭用回線程度で、高速なネットワークは前提にできない
法規制約: 食品を扱う店舗として、アレルギー表示など食品表示に関わる法令を守る必要がある
```
制約条件は、要件そのものではないが、どの要件をどこまで実現できるかを左右する重要な情報である。予算30万円という制約がある以上、最新の大規模なシステムを導入するという選択肢は、この時点で現実的ではなくなる。
### 建築における制約条件
建築の現場でも、制約条件は設計の出発点になる(→BOOK-0346)。敷地の広さ、建築基準法による高さ制限や日影規制、予算、工期――これらはすべて制約条件であり、依頼主の理想図は、この制約条件の枠の中でしか実現できない。制約条件を早い段階で洗い出しておくことは、後になって「そもそも実現不可能な要件を作り込んでしまった」という事態を防ぐ、要件定義の重要な工程である。
---
> **定着量の目安(第八章)**: 制約条件を漏れなく洗い出す型を身につけるには、架空の依頼案件を1つ選び、予算・納期・技術・法規制の4つの観点から、それぞれ最低1つずつ制約条件を書き出す練習を3案件分行うと、視点の抜け漏れが減ると見込まれる。
---
## 第九章: 要望は変わるものと心得る — スコープ管理(水準九)
### 「ついでに」という一言の危うさ
要件定義がひと段落し、開発が始まった矢先、宮田さんから電話がかかってきた。「ついでにクーポン機能も付けられませんか。常連さん向けの割引があると喜ばれると思うんです」。この「ついでに」は決して珍しい申し出ではない。むしろ、要件定義の途中や実現の途中で、依頼主の要望が広がっていくのはごく自然なことである。この、最初に取り決めた実現範囲を**スコープ(水準九: ある取り組みで実現すると決めた作業や機能の範囲)**と呼び、そのスコープが正式な合意なしに少しずつ膨らんでいく現象を**スコープクリープ(水準九: 小さな追加の積み重ねによって、当初のスコープが際限なく広がっていく現象)**と呼ぶ。
### 変更管理という手順
クーポン機能そのものが悪いわけではない。問題は、これを無条件に受け入れてしまうと、第八章で洗い出した納期(2か月)と予算(30万円)の制約条件を超えてしまう可能性があることだ。先輩デザイナーは、宮田さんの申し出を次の手順で扱った。
```
1. 影響評価: クーポン機能を追加すると、納期がどれだけ延び、費用がどれだけ増えるかを見積もる
(見積り結果: 追加で3週間・8万円が必要)
2. 選択肢の提示: 「クーポン機能を今回のスコープに含めると納期が3週間延びます。
今回は見送り、次のフェーズで実装する案はいかがですか」と依頼主に選択肢を示す
3. 合意と記録: 依頼主が選んだ結論(今回は見送り、次フェーズで対応)を文書に残す
```
この一連の手順を**変更管理(へんこうかんり、水準九: 要望の追加や変更が生じた際、その影響を評価し、依頼主と合意したうえで記録に残す、一連の手順)**と呼ぶ。変更を頭ごなしに断るのでも、無条件に受け入れるのでもなく、影響を見積もったうえで依頼主自身に選んでもらう――これが、要望の変化と付き合う基本姿勢である。
---
> **定着量の目安(第九章)**: スコープクリープを見抜き、変更管理の三手順(影響評価→選択肢の提示→合意と記録)を実践するには、架空の「ついでに」要望を3つ想定し、それぞれについて影響評価の見積もりと選択肢の提示文を自分で書いてみる練習が効果的である。
---
## 第十章: プロトタイプで確かめる — デザイナー思考の入口(水準十)
### 完成させる前に確かめる
要件定義書ができあがっても、それが本当に田中さんのような常連客にとって使いやすいかどうかは、実際に触ってもらうまでわからない。そこで、本格的に作り込む前に、簡単な試作品を使って要件が正しいかどうかを確かめる。紙一枚に手描きで画面の流れを描いたものを**モックアップ(水準十: 完成品の見た目や画面の流れを、簡易な形で再現した試作物)**と呼び、実際に操作の手応えまで確認できる程度に作り込んだ試作品を**プロトタイプ(水準十: 実際に操作・検証できる水準まで作り込んだ、本番前の試作品)**と呼ぶ。
先輩デザイナーは、紙に手描きした画面遷移のモックアップを持って、田中さんと高橋さんに見てもらった。田中さんは「この『予約する』のボタンがどこにあるかすぐわからない」と指摘し、高橋さんは「受け渡し確認のボタンが小さすぎて、忙しい時間帯には押し間違えそうだ」と指摘した。これらは、実際にシステムを組み上げてから気づいたのでは手戻りが大きい問題であり、紙一枚の試作品の段階で発見できたことに大きな価値があった。
### 共感から試作へ、そしてまた確かめる
このように、利用者の立場に立って課題を捉え(共感)、課題を明確にし(定義)、解決策を考え(発想)、簡易な試作品を作り(試作)、利用者に確かめてもらう(検証)という一連の循環を**デザイン思考(でざいんしこう、水準十: 利用者への共感を出発点に、課題の定義・解決策の発想・試作・検証という循環を繰り返しながら、より良い解決策に近づけていく考え方)**と呼ぶ。要件定義とデザイン思考は対立するものではなく、むしろ表裏一体である。要件定義が「何を作るべきか」を言葉で確定させる作業だとすれば、デザイン思考は、その言葉が本当に正しいかを、試作という手を動かす作業を通じて確かめ続ける営みだといえる。
### 製品デザインにおける試作
この手順は製品デザインの現場でも同じである。取っ手の形を決める前に、粘土や発泡素材で簡易な模型を作り、実際に握ってもらって確かめる――図面の上だけで「持ちやすい取っ手」を確定させることはできない。分野が違っても、「試作して確かめてから本番に進む」という順序そのものは共通している。
---
> **定着量の目安(第十章)**: モックアップ・プロトタイプ・デザイン思考の循環を体感するには、身近な小さな道具(付箋・文房具など)一つについて、紙にモックアップを描き、友人や家族に見せて感想をもらい、指摘に応じて描き直す、という一往復を実際に行ってみるとよい。
---
## 第十一章: 要件定義書としてまとめる — トレーサビリティ(水準十一)
### 散らばった要件を一つの文書にまとめる
ここまでの作業を通じて、宮田さんの案件には、機能要件・非機能要件・受け入れ基準・制約条件が数多く積み上がった。これらを整理し、誰が読んでも実現すべきことが一目でわかる形にまとめた文書を**要件定義書(ようけんていぎしょ、水準十一: 確定した要件・受け入れ基準・制約条件を体系的に整理し、依頼主と作り手の双方が合意できる形にまとめた文書)**と呼ぶ。
```
要件定義書の一例(抜粋)
--------------------------------------------------
ID 要件文 優先度 受け入れ基準
R-01 常連客が焼き上がり時刻を指定して予約 高 15分刻みで指定可・開店30分前まで受付
できる(機能要件)
R-02 予約完了までの操作は3ステップ以内 高 操作ログで平均ステップ数を計測
(非機能要件)
R-03 お年寄りでも判読できる文字サイズ 高 文字サイズ18pt以上・実利用者確認済み
(非機能要件)
R-04 クーポン機能(次フェーズで対応) 低 (今回スコープ外・変更管理記録参照)
--------------------------------------------------
```
### なぜ番号を振るのか — トレーサビリティ
それぞれの要件にR-01のような番号を振っておくと、後になって「この画面のこの機能は、どの要件を実現するために作られたのか」を追跡できるようになる。要件と、それを実現する設計・実装・検証結果とのあいだの対応関係をたどれる状態を**トレーサビリティ(水準十一: ある要件が、どの設計・実装・検証結果に対応しているかを、後から追跡できる状態)**と呼ぶ。トレーサビリティが確保されていれば、要件R-02(操作3ステップ以内)が満たされているかどうかを確認したいとき、対応する実装や検証記録をすぐに特定できる。逆に番号もつけずに要件を書き散らかしていると、後になって「この機能はそもそも誰の何のニーズのために作られたのか」がわからなくなり、変更や改善のたびに一から聞き取り直すことになりかねない。
---
> **定着量の目安(第十一章)**: 要件定義書の型とトレーサビリティの考え方を身につけるには、これまでの章で作った複数の要件・受け入れ基準を、ID・要件文・優先度・受け入れ基準の4列を持つ表にまとめ直す練習をすると、実務に近い感覚がつかめると見込まれる。
---
## 第十二章: 優先順位づけとトレードオフ(水準十二)
### 全部は同時に実現できない
要件定義書ができあがっても、第八章の制約条件(予算30万円・納期2か月)を思い出せば、洗い出したすべての要件を一度に実現することは難しいとわかる。ここで必要になるのが、要件に優先順位をつける作業である。広く使われている手法の一つが、要件を「必須〈Must〉」「実現すべき〈Should〉」「実現できれば良い〈Could〉」「今回は見送り〈Won't〉」の四段階に仕分ける**MoSCoW法(もすこーほう、水準十二: 要件を「必須〈Must〉」「実現すべき〈Should〉」「実現できれば良い〈Could〉」「今回は見送り〈Won't〉」の4区分に仕分け、限られた資源の中で何を優先するかを決める手法)**である。
```
宮田さんの案件へのMoSCoW適用(初回フェーズ)
Must (必須) : R-01 焼き上がり時刻指定予約 / R-03 お年寄りでも読める文字サイズ
Should(実現すべき) : R-02 操作3ステップ以内
Could (できれば) : 予約時のパン画像プレビュー
Won't (今回は見送り) : R-04 クーポン機能(第九章の変更管理記録どおり次フェーズへ)
```
### トレードオフを裁定する
第四章で見つかった要求の衝突――宮田さんの費用を抑えたい思いと、田中さんの「複雑な操作は避けたい」という思いは、一見両立しないように見えた。しかし優先順位づけの過程で、次のような**トレードオフ(水準十二: 複数の要件のうち、一方を優先すれば他方を犠牲にせざるを得ない、二律背反の関係とその判断)**の裁定が行われた。「スマホアプリではなく、店頭に置いた1台のタブレット端末に、店員が予約を代行入力する簡易な仕組みにする」という案である。この案は、宮田さんの費用(1台のタブレットで足りる)を抑えられ、田中さんは自分でスマホを操作する必要がなくなり(店員の高橋さんが代わりに入力する)、高橋さんの操作もR-02の3ステップ以内に収まる設計にできる。すべての要望を100%満たす答えではないが、Must要件をすべて満たしたうえで、三者の利害の落としどころを見つけた解決策になっている。
宮田さんはこの提案を見て、ようやく納得した表情を見せた。「これなら、常連さんも困らないし、私も無理なく続けられそうです」。最初の「使いやすくしてほしい」という一言から、深掘り、検証可能な要件への変換、ペルソナの洗い出し、機能要件と非機能要件の区別、SMART基準による点検、制約条件の確認、スコープ管理、プロトタイプによる検証、要件定義書へのまとめ、そして優先順位づけとトレードオフの裁定――この一連の道のりをたどって、ようやく「検証可能な仕様書」が完成したのである。
---
> **定着量の目安(第十二章)**: MoSCoW法とトレードオフの裁定を身につけるには、第十一章で作った要件定義書の表に優先度列(Must/Should/Could/Won't)を実際に書き込み、なぜその優先度にしたかを一文で説明する練習を行うと、限られた資源の中での判断力が養われると見込まれる。
---
## 三つの実践解(§16.21) — 要件定義とデザイナー思考を手で確かめる
理論を、実際に手を動かして確かめる方法を三つ紹介する。いずれも身の回りの題材だけで完結する、安全な実践解である。
1. **深掘り質問の実践**: 家族や友人に「もっと便利にしてほしい」といった曖昧な要望を一つ挙げてもらい、「なぜ」を3回以上繰り返して、その奥にある本当のニーズを一緒に掘り当ててみる。第二章の深掘り質問の型を、実際の対話で確かめる練習である。
2. **機能要件・非機能要件の仕分け実践**: 自分がふだん使っているアプリやサービスを一つ選び、その特徴を10個ほど書き出したうえで、「何をするか(機能要件)」と「どのくらい良いか(非機能要件)」の二列に仕分けてみる。第五章の区別を、身近な題材で検算する実践である。
3. **MoSCoW優先順位づけの実践**: 自分の部屋の模様替えや、身の回りの小さな改善計画を一つ選び、思いつく限りの「やりたいこと」をMust・Should・Could・Wontの四段階に仕分けてみる。第十二章の優先順位づけの型を、限られた時間や予算という制約条件の中で実際に使ってみる実践である。
---
## まとめ — 曖昧な一言から、検証可能な仕様書へ
本冊では、ひなたベーカリーの宮田路子さんの「使いやすくしてほしい」という一言から出発し、要望と要件の違い(第一章)、深掘り質問によるニーズの掘り当て(第二章)、検証可能な言葉への変換と受け入れ基準(第三章)、ペルソナとステークホルダー間の要求の衝突(第四章)、機能要件と非機能要件の区別(第五章)、ユーザーストーリーという文章の型(第六章)、SMART基準による要件の点検(第七章)、制約条件の洗い出し(第八章)、スコープ管理と変更管理(第九章)、プロトタイプとデザイン思考(第十章)、要件定義書とトレーサビリティ(第十一章)、そして優先順位づけとトレードオフの裁定(第十二章)までをたどってきた。
曖昧な理想図を、いきなり完成品に変換しようとしてはならない。理想図の奥にある本当のニーズを掘り当て、検証できる言葉に分解し、関わる人々全員の利害を洗い出し、制約条件という枠の中で優先順位をつけて裁定する――この一連の積み上げこそが、要件定義とデザイナー思考が目指す「顧客の理想図を、検証可能な仕様書に変える力」である。この力は、ソフトウェア開発だけでなく、建築(→BOOK-0346)や製品デザインなど、何かを「作る」あらゆる場面で共通して働く土台になる。
---
## 章末: 依頼の流れ図とまとめの階段図
まず、この巻を通じて宮田さんの案件がたどった流れを、簡易な図で表してみよう。
```
「使いやすくしてほしい」(要望)
│ 深掘り質問(なぜを3回)
▼
「常連客の行列離れを防ぎたい」(ニーズ)
│ 検証可能な言葉へ分解+ペルソナ洗い出し
▼
機能要件・非機能要件・受け入れ基準(SMART基準で点検)
│ 制約条件(予算30万円・納期2か月)と突き合わせ
▼
プロトタイプで田中さん・高橋さんに確認 → 要件定義書に整理
│ MoSCoW法で優先順位づけ+トレードオフの裁定
▼
「店頭タブレット代行入力方式」という検証可能な仕様書(合意)
```
続いて、本冊全体の歩みを階段図としてまとめる。
```
[水準十二] 優先順位づけとトレードオフ
MoSCoW法(Must/Should/Could/Won't)・トレードオフの裁定
▲
│ 限られた資源の中で何を実現するか決める
[水準十一] 要件定義書とトレーサビリティ
ID付きの要件一覧表(R-01〜)・要件と実装の対応追跡
▲
│ 散らばった要件を一つの文書にまとめる
[水準十] プロトタイプとデザイン思考
モックアップ→試作→検証の循環
▲
│ 作り込む前に手を動かして確かめる
[水準九] スコープ管理と変更管理
影響評価→選択肢の提示→合意と記録
▲
│ 要望は開発の途中でも変わるものと心得る
[水準八] 制約条件の洗い出し
予算・納期・技術・法規制という枠
▲
│ 実現できる範囲を先に確かめる
[水準七] 良い要件かどうかの検査
SMART基準(具体的・測定可能・達成可能・関連性・期限)
▲
│ 書いた要件そのものの品質を点検する
[水準六] 要件を文章に落とし込む型
ユーザーストーリー「〜としては、〜したい。なぜなら〜だからだ」
▲
│ 誰が読んでも粒度がそろう書き方にする
[水準五] 機能要件と非機能要件の区別
「何をするか」と「どのくらい良いか」
▲
│ 品質の側面も要件として扱う
[水準四] ペルソナと要求の衝突
宮田さん・田中さん・高橋さん、三者三様の要望
▲
│ 依頼主一人の声だけでは足りない
[水準三] 曖昧な言葉を測れる言葉に変える
検証可能性・受け入れ基準
▲
│ 数えられる・確かめられる形に分解する
[水準二] 要望の奥にある目的を掘り当てる
深掘り質問(なぜを3回)・ニーズとウォンツの区別
▲
│ 一言の奥にある本当の困りごとを探す
[水準一] 要望と要件の違い
「使いやすくして」は検証できない・要件は検証できる
安全枠: 本冊の依頼主・店舗・製品はすべて架空の事例。実務では必ず本人との対話で要件を確定する。
```
---
## 参照文献(定番教科書・一般的手法)
1. ソフトウェア要件工学の標準的教科書群(要件の分類・SMART基準・トレーサビリティなど、要件定義の基礎を扱う定番の入門書)。
2. IEEE(米国電気電子学会)29148規格「システムおよびソフトウェア工学 — ライフサイクルプロセス — 要求エンジニアリング」(要件文書の書き方に関する一般的な国際規格群)。
3. ユーザーストーリーの記法(エクストリーム・プログラミング〈XP〉など、1990年代末以降のアジャイル開発の実践の中で広まったとされる記法)。
4. MoSCoW法(1994年頃、ダイナミック・システムズ・デベロップメント・メソッド〈DSDM〉というソフトウェア開発手法の枠組みの中で紹介されたとされる優先順位づけの手法)。
5. デザイン思考の一般的な解説書(スタンフォード大学のデザインスクール〈d.school〉などが体系化を進めたとされる、共感・定義・発想・試作・検証の循環)。
---
（本冊子は現代学問宇宙図鑑シリーズ BOOK-0345。応用の軌道ステーション群・作る力と生きる力シリーズ・計算機文明部の第6巻(要件定義とデザイナー思考)。→BOOK-0343『情報構造の設計』・→BOOK-0344『文章の解析と解読』・→BOOK-0346『建築構造の基礎』と接続する。GAKUMON_UNIVERSE.md 進捗台帳・CATALOG_作る力と生きる力シリーズ.mdを参照。）
# BOOK-0345 作る力と生きる力: 要件定義とデザイナー思考 — 「使いやすくして」をどう仕様書に変えるか