「何を作るか」の前に「どう変えるか」 失敗しない要求定義の4ステップ
「新しく要件定義を担当することになったけど、何から手をつければいいのか……」
「そもそも要求定義と要件定義って具体的に何が違うんだろう？」
システム開発において、スケジュールの遅延や手戻りの原因の50%以上は「要件定義の不備」にあると言われています。しかし、その不備の多くは、さらに前段階の「要求定義」でボタンを掛け違えていることが原因です。
要求定義が不十分だと、どれほど最新の技術を使っても、現場に馴染まない「使われないシステム」が出来上がってしまいます。
本記事では、30年の現場経験に基づき、要求定義の役割や要件定義との違い、実戦的な進め方を解説します。
要求定義とは？要件定義との決定的な違い
要求定義を一言で言えば、「目的達成のために、業務をどう変えるか（改善・標準化）を検討し、文書化する作業」です。
よく混同される「要件定義」との違いを、一言で整理すると以下のようになります。
- 要求定義： ユーザーがやりたいこと（What）をまとめる
- 要件定義： システムがやるべきこと（How）を決める
プロセス全体における位置づけ
要件定義という大きなプロセスは、以下の図のように「1→2→3」の不可逆なステップで進みます。この順序を飛ばして「システム化」の話に入るのが、迷走の最大の原因です。
| フェーズ（ステップ） | 主な活動内容 | 焦点（フォーカス） |
|---|---|---|
| Step 1：企画構想 | 経営方針・システム化方針の決定、体制構築、計画立案 | 経営・戦略 |
| Step 2：要求定義 | 現状把握、問題抽出、要求分析、要求文書化 | 業務・プロセス |
| Step 3：要件定義 | 機能・非機能要件の整理、仕様検討、要件文書化 | システム・機能 |
要求定義は「システム化」の話に入る前に、「あるべき業務の姿（業務要件）」を決める非常に重要なプロセスなのです。
失敗しない要求定義の「4つの手順」
要求定義は、以下の4つのステップで着実に進めていきます。
① 現状（As-Is）を把握する
まずはシステム化の対象となる業務をすべて洗い出します。いきなり細部に入るのではなく、「受注」「出荷」「在庫管理」といった大きな括りから始め、徐々にドリルダウンしていくことで、漏れを防ぎます。
② 現在の業務フロー図をまとめる
洗い出した業務について、担当者にヒアリングを行いながら図解します。縦軸に登場人物、横軸に時系列をとる「スイムレーン形式」が、情報の流れを整理するのに最適です。
あわせて読みたい: 業務フローの基本的な書き方｜要件定義で失敗しないための実践ガイド
③ 問題や課題を抽出する
可視化したフローから、二重入力や時間のロス、判断基準の曖昧さなどのボトルネックを見つけ出します。これらを「要求事項」として一覧化し、お客様と「解決すべき課題」の認識を合わせます。
④ 解決策（To-Be）の策定
抽出した課題を「どう解決するか」を検討します。解決後の姿をビフォーアフター図※として描くことで、経営層や現場の方々に導入後の効果を直感的に伝えます。
※ビフォーアフター図とは： 現在の問題点（ビフォー）と解決後の姿・効果（アフター）を業務視点で対比させた図です。専門用語を避け、経営層にもメリットが伝わる内容でまとめます。可能であれば、お客様主体で作成してもらうと当事者意識が高まり、プロジェクトの推進力になります。
現場で役立つ「要求定義の重要ポイント」
実務をスムーズに進めるために、現場で意識しておきたい重要な視点です。
ステークホルダーの特定は「生命線」
プロジェクトに関わる「ステークホルダー（利害関係者）」を漏れなく把握することは、要求定義の生命線です。特定の部署だけの話を聞いて進めてしまうと、後から「あの業務が考慮されていない」という事態を招くリスクがあります。影響範囲を慎重に調査しましょう。
あわせて読みたい: 【テンプレ項目付き】ステークホルダー管理で「横槍」を防ぐ！特定・分析の実践手法とリストの作り方
「三現主義」で現状把握の質を高める
ヒアリングの言葉を鵜呑みにせず、以下の3つを組み合わせます。
- ドキュメント： 規定やマニュアルだけでなく、担当者の「個人メモ」も確認します。
- 既存システム： 実際の操作画面やデータを見て、現行仕様を正確に把握します。
- 三現主義（現場・現実・現物）： 実際に対象部署へ足を運び、使われている「現物」を見ながら、「現実」の動きを自分の目で確認します。
3階層のフロー図で全体を俯瞰する
認識のズレを防ぐため、以下の3つのレベルで図解を使い分けるのが効果的です。
- 業務プロセス関連図： 全体の流れを俯瞰する（経営層・管理職向け）
- 業務フロー： 詳細な手順を示し、課題を抽出する（現場担当者向け）
- システム化業務フロー： どの作業をシステムで行うかを明記する（要件定義への橋渡し用）
あわせて読みたい: 業務フローの書き方完全ガイド｜3つの階層で「機能漏れ・手戻り」を物理的に防ぐ実践術
解決手段は「業務」と「システム」の両面で検討する
「システムでどう解決するか」を考える前に、まずは「業務のルールを変えるだけで解決できないか」を検討します。システム化するよりも、業務フローを見直す方がコストが低く、本質的な改善につながるケースも多いものです。
優先度の高い要求に絞り込む
すべての要求を受け入れると、予算と期間が足りなくなります。「目的」に合致しているか、投資対効果（ROI）は見込めるか、緊急度は高いか、といった客観的な基準で優先順位をつけ、時には「今回は見送る」という判断を促すのもプロとしての役割です。
まとめ：手戻りを最小化し、本質的な課題を解決しよう
要求定義は、要件定義という「建物の設計」を始めるための「土台作り」です。ここで誤った情報をつかんだり、本質的な課題を見逃したりすると、後になって「使われないシステム」が出来上がってしまいます。
- 「What（業務）」を決めてから「How（システム）」へ進む
- 三現主義で「現場の真実」を掴む
- 優先順位をつけ、時には「やらない」決断を促す
これらを徹底することで、手戻りを最小限に抑え、本質的な課題を解決できるプロジェクトへと導くことができます。
業務のあるべき姿（要求）が見えてきたら、次はそれを支える「品質」の議論です。第4回では、目に見えにくいけれど疎かにすると致命的なトラブルを招く要、非機能要件をスムーズにまとめ上げるためのヒアリング術を解説します。
要件定義シリーズ：実践ガイド一覧
[第1回] 要件定義の失敗しない進め方｜現場PMが実践すべき7つの重要ポイント
[第2回] 企画構望の進め方｜要件定義の「そもそも」を固める点検ポイント
[第3回] 要求定義の具体的な進め方｜業務を可視化し課題を解く技術（本記事）
[第4回] 非機能要件の進め方｜コストと品質のバランスを最適化するヒアリング術
[第5回] 要件定義のWBS・タスク一覧｜成果物とスケジュール管理の実践ガイド
[第6回] 要件定義の準備術｜失敗しないための「体制」と「成果物」の整え方
[第7回] 業務フローの基本的な書き方｜失敗しないための実務作法
[第8回] 業務フローのフレームワーク活用術｜5W3HとAs-Is/To-Be
[第9回] 業務フローの書き方完全ガイド｜3つの階層で「機能漏れ」を防ぐ
