要件定義で行うことは？目的把握・業務理解・技術選定を「漏れなく膨らませすぎず」進める実践ガイド

リード文：要件定義で本当にやるべきことを、目的の明確化→業務理解→要件化→モック検証→優先順位化→合意形成の順で整理し、スコープ肥大と業務漏れを同時に抑える実践手順としてまとめます。

🧭 テーマの主役：要件定義とは何か（30秒で説明）

要件定義を一言でいうと、「解くべき業務課題を、作るべき仕様に翻訳する工程」です。家づくりで言えば、いきなり壁紙を選ぶのではなく、まず「何人で住むのか」「在宅勤務はあるのか」「駐車場は必要か」を決めるフェーズに近いです。

IIBAの知識体系では、要件分析は「ニーズを推奨される解決策へ変換する反復的な活動」として扱われ、検証・妥当性確認・設計選択まで含むと整理されています。つまり、要件定義は単なるヒアリング議事録ではなく、意思決定の連続です。

あなたの認識どおり、要件定義の中心は「目的把握」「業務理解」「技術スタックの選定」です。そこに加えて、実務上はモックやプロトタイプによる要件詰めまで入れておくのがむしろ標準的です。GoogleのDesign Sprint文脈でも、同一週内にプロトタイプを顧客検証し、前倒しで学習サイクルを回す考え方が定着しています。

😵 動機：なぜ要件は膨らむし、なぜ業務漏れが起きるのか

要件が膨らむのは、チームがだらしないからではありません。むしろ真面目にヒアリングすると、現場から「それも必要」「これも欲しい」が自然に出てきます。問題は、要求（Wish）と要件（Must）を同じ箱に入れてしまうことです。

業務漏れはその逆で、会議では語られにくい「例外処理」「承認フロー」「障害時オペレーション」が置き去りになります。普段は問題なく回るため、関係者も忘れがちです。ところが本番では、まさにその例外が事故を起こします。筆者も「通常フローは完璧、月末締め処理だけ未定義」という案件で、テスト終盤に全員が青ざめた経験があります。

だからこそ、要件定義は「何を作るか」だけでなく、何を今回やらないかを明示する作業でもあります。

🧪 仮説：要件定義は「3層モデル」で進めると崩れにくい

ここでの仮説はシンプルです。要件定義を次の3層に分けると、膨張と漏れを同時に抑えやすくなります。

1. Why層（目的）: 何を改善したいのか。成功指標は何か。
2. How-business層（業務）: 現行業務はどう流れ、どこで詰まるのか。
3. How-system層（システム）: どの技術・構成で、どこまで実装するのか。

この3層を混ぜると、「KPIを決める会議でDB製品の比較が始まる」みたいなカオスが起きます。会議の議題ごとに層を固定すると、議論の質が急に安定します。

🔍 検証：要件定義で実際に行うべき項目

ここからは、要件定義で「やること」を実務順に具体化します。ISO/IEC/IEEE 29148系で示される観点（良い要求の特性、反復的プロセス、情報項目の定義）とも整合する形です。

1) 目的定義（Project Why）

最初に決めるべきは機能一覧ではなく、成功の物差しです。たとえば「問い合わせ一次回答時間を4時間→30分」「手作業転記を月40時間削減」のように、業務成果で置きます。

このとき便利なのは「As a / I want / so that」のユーザーストーリー形式です。Atlassianが示すように、主語（誰が）・意図（何をしたい）・価値（なぜ）が揃うと、仕様議論が“画面の好き嫌い”に流れにくくなります。

2) 業務理解（As-Is / To-Be）

次に、現行業務の流れを可視化します。ポイントは通常フローだけでなく、例外・手戻り・責任境界まで書くことです。INCOSEが挙げる活動群でも、elicitation（引き出し）だけで終わらず、analysis・management・V&Vまで含める前提になっています。

業務理解で最低限押さえる観点は次の5つです。

• 入力情報は誰がいつ作るか
• 承認は誰が何を見て判断するか
• 失敗時（差し戻し・再実行）はどう扱うか
• 監査・証跡はどこに残るか
• 月次・繁忙期・障害時で挙動が変わるか

3) 要件化（機能・非機能・制約）

業務理解をシステム要件に翻訳します。ここで「要件」を3分類すると抜け漏れが減ります。

• 機能要件: 何をできるようにするか
• 非機能要件: 性能・可用性・セキュリティ・運用性
• 制約条件: 予算、納期、既存システム連携、法令、社内標準

料理に例えると、機能要件は「何を作るか（カレー）」、非機能要件は「何分で何人分を出すか」、制約は「辛さNGの人がいるので甘口必須」です。レシピ（仕様）だけ完璧でも、提供条件が崩れれば現場は破綻します。

4) モック・プロトタイプで要件を詰める

あなたの考えは非常に実践的です。要件定義でモックを使うのは、設計フェーズの前倒しではなく、認識差分の検出装置です。

文章の要件定義書だけだと、読み手ごとに解釈がズレます。一方、モックを見ながら「このタイミングで承認通知が必要」「この入力項目は現場では不要」と会話すると、抽象論が具体論へ落ちます。Design Sprintの考え方でも、短期間プロトタイプ検証によって学習を前倒しできるのが価値です。

5) 優先順位づけとスコープ境界

要件が膨らむのを防ぐコアはここです。要件ごとに「MVPに必須か」「後続でよいか」を分けます。

6) トレーサビリティと合意形成

最後に「要件→設計→実装→テスト」を追えるようにします。これがないと、要件変更の影響範囲が読めず、修正コストが雪だるま化します。合意は口頭ではなく、版管理されたドキュメント・チケットで残すのが実務では必須です。

💡 活用事例：要件詰めをモックで前倒ししたチームの改善

ある業務システム更改プロジェクトで、当初は「要件定義2か月、設計3か月」の想定でした。ところが要件定義後半で、関係部門ごとに画面イメージの解釈が違うことが判明。要件書は読んでいたのに、誰も同じ画面を想像していなかったのです。

そこで、低コストなモックを1週間で作り、承認・差し戻し・再申請の3パターンだけを先にレビューしました。結果として、設計工程に入る前に「承認権限の粒度」「通知先」「差し戻しコメントの必須条件」を確定でき、後工程の仕様変更件数を大きく削減できました。

この事例のポイントは、モックを“見た目の議論”に使わず、業務ルールの合意形成装置として使った点です。UIの色は後で直せますが、承認責任の誤解は後で直すと高くつきます。

🔥 ハマりポイント：やりがちな4つの過ち

要件定義は、ちゃんとやっているチームほどハマります。ここではよくある失敗を「症状→原因→対処」で整理します。

1) 「要望収集会」になってしまう

症状は、ヒアリングのたびに要件が増え続けること。原因は、目的指標が曖昧で、要望を評価する軸がないことです。対処は、各要件に「どのKPIをどれだけ改善するか」を紐づけること。紐づかないものはバックログへ送る判断ができます。

2) 現場キーパーソン不在で進む

症状は、レビューで毎回「現場では無理」が出ること。原因は、決裁者中心の会議で、日々の実務担当が不在なことです。対処は、業務フローごとに“実務代表者”を定義し、必ず確認サイクルに入れることです。

3) 非機能要件が後回し

症状は、機能は動くが遅い・落ちる・運用できない。原因は、非機能要件を設計工程の話だと思い込むことです。対処は、要件定義段階でSLOや監視要件、障害時運用まで決めること。ここを後ろ倒しにすると、最終局面で火を吹きます。

4) モックを作っただけで満足する

症状は、モック会で盛り上がったのに、要件書更新が追いつかないこと。原因は、モック検証結果の反映ルールがないことです。対処は、レビュー項目ごとに「採用/保留/却下」と理由を記録し、要件IDへ反映する運用を固定することです。

🚀 取り込み方：明日から実行できる導入ステップ

理屈はわかった、でも現場では時間がない——という声に答えるため、実行単位で分けます。

今日（5分〜30分）

まずは、現在の案件で使っている要件一覧に次の3列を追加してください。

• 目的KPI
• 優先度（Must/Should/Could）
• 検証方法（レビュー/モック/テスト）

これだけで、議論の交通整理が始まります。

今週（半日〜1日）

関係者ワークショップを1回実施し、As-Is業務を1本だけ可視化します。対象は「最も事故る業務」からでOKです。そこで出た論点をモック1枚に落とし、翌日に再レビューします。短いループが大事です。

今月（2〜4週間）

要件トレーサビリティを整備します。最低でも「要件ID↔設計項目↔テスト観点」の対応を持たせ、変更時に影響範囲を即答できる状態を作ります。これができると、プロジェクトの会話が“感覚”から“根拠”に変わります。

🔄 代替アプローチ比較：文書中心 vs モック中心 vs ハイブリッド

どの進め方にも利点があります。大事なのは「案件特性に合わせて選ぶ」ことです。

✅ 要点まとめ

ここまでの話を圧縮すると、次の5点です。

• 要件定義の中心は、あなたの言うとおり「目的把握・業務理解・技術選定」で正しい。
• ただし実務では、そこにモック/プロトタイプ検証を含める方が成功率が高い。
• 要件膨張は「評価軸不足」、業務漏れは「例外業務の未可視化」で起きる。
• 3層（Why / How-business / How-system）で議論を分けると、混線が減る。
• 最後はトレーサビリティと合意記録。ここまでやって初めて“定義”になる。

📅 今後の展望：要件定義は「文書作成」から「学習設計」へ

最近は、要件定義を一度で固めるのではなく、短い検証サイクルで精度を上げる運用が主流です。背景には、ビジネス環境変化の速さと、初期仮説の不確実性があります。

今後は、AI支援による要件レビューや変更影響分析がさらに進むはずですが、結局のところ最重要なのは「目的を言語化し、関係者間で合意する力」です。道具は進化しても、ここは人間の仕事として残ります。

まとめ

要件定義で行うことは、単に要望を集めることではありません。目的を定め、業務を理解し、実装可能な要件へ翻訳し、モックで認識差分を潰し、優先順位と境界を決め、追跡可能な形で合意することです。

ここまで読んだあなたは、要件定義を「会議資料づくり」ではなく「失敗確率を下げる設計活動」として実行できるはずです。次の案件では、まず要件一覧にKPI列を1つ足すところから始めてみてください。

参考文献

1. IIBA, Requirements Analysis and Design Definition（KnowledgeHub）
   https://www.iiba.org/knowledgehub/the-business-analysis-standard/5-applying-business-analysis-tasks/5-3-business-analysis-knowledge-areas/requirements-analysis-and-design-definition/
2. ISO, ISO/IEC/IEEE 29148（Requirements engineering）
   https://www.iso.org/standard/45171.html
3. Atlassian, User stories with examples and a template
   https://www.atlassian.com/agile/project-management/user-stories
4. Google Design, 5-Day UX Design Sprint
   https://design.google/library/design-sprints
5. INCOSE, Requirements Working Group material（Elicitation / Analysis / V&V）
   https://www.incose.org/docs/default-source/events-documents/iw2022/wgis/iw2022-wgis-requirements%281%29.pdf
6. Atlassian Support, Using Jira for Requirements Management
   https://support.atlassian.com/jira/kb/using-jira-for-requirements-management/