いきなりプロジェクトにアサインされて「要件定義をやって！」と言われたものの、何をどの順番で決めればいいのかわからない…という悩み。本当にいたるところで聞く悩みです。
実際の現場では、こんな“あるある”も起こりがちです。
とりあえず画面イメージから作り始めたものの、途中で事業部から「そもそも業務フローどうするんだっけ？」とツッコまれ、結局すべて作り直しに……。気づけば、何が正しいのか分からず迷子状態に。。
この記事では、こうした混乱の原因を紐解きながら、企画〜開発のプロセス全体を通してわかりやすく解説します。
特に、業務系の企画担当者や非エンジニアPM向けに、実務で再現できる「具体的な手順と考え方」を丁寧に紹介していきます。
この記事でわかること
- 要件定義で作るべき成果物の全体像
- 要件定義の段階的な進め方
- 要件定義をどこまでやれば完了なのか
要件定義とは「見積と設計のINPUTをつくる工程」
そもそも要件定義って、何のためにやるのでしょうか？？
「やりたいことを言語化するため」も、もちろんあるのですが、実際はもっと明確な目的があります。要件定義の本質はとてもシンプルで「見積と設計に必要な情報を可視化すること」です。
すなわち、要件定義を行う目的は次の2点です。
- 開発ベンダーに見積を取るため
- 設計のインプット情報とするため
この2つのために、要件定義という工程で「要件」を可視化していきます。ただし、いきなり見積が取れるレベル・設計のインプットにできるレベルで作成するのは難しいのです。
だからこそ、段階を踏んで要件を具体化していきます。その段階というのが、
- 要求定義
- 業務要件定義
- 機能要件定義
という3つの要件定義工程です。
段階を踏みながら、やりたいことを少しずつ具体化して、見積が取れる粒度・設計ができる粒度までブレイクダウンしていきます。
要件定義を含めたシステムの企画・開発の全体像を示すとこんな感じです。
このように、システム開発のプロセスとは「やりたいこと」の具体化です。
段階的に「やりたいこと」を具体化していって、最終的にはソースコードになるまで細かく具体化していきます。
要件定義の前に「前提タスク」が終わっているかチェックする
さっそく要件定義の進め方を説明したいところですが、その前に「前提タスク」が完了しているかをチェックしましょう。
要件定義は、まっさらな状態からスタートするのではなく、前工程の成果物を引き継いで（＝インプットにして）スタートします。
ということで、要件定義に入る前に、必ず以下のタスクが終わっているか確認しましょう。
ここが曖昧なまま要件定義に入ると、手戻り地獄になります。というのも、要件定義で行う作業は、上記の成果物がある前提で組まれているからです。
このような感じで、前工程の成果物と次の工程の作業は紐づいています（＝依存関係があります）。
なので、めんどくさくても、必ずこれらの作業を完了させてから要件定義に入るようにしましょう。
要件定義の“位置づけ”を理解する
改めて、企画・開発プロセスにおける要件定義の位置づけを確認しましょう。
要件定義は単独のタスクではなく、企画フェーズの成果物を具体化して、見積や設計につなげていく役割を担っています。
次のように、要件定義フェーズでは、要求定義 → 業務要件定義 → 機能要件定義 と3段階で要件を具体化していきます。
要件定義で重要なことは、見積や設計という後続の作業で何を必要としているかを知っておくことです。
そのために、可能であれば見積や設計を行う開発ベンダーのエンジニアに、「どんな要件定義書であれば見積や設計ができるか？」を確認できると、要件定義で何を作ればいいかが、ぐっとわかりやすくなります。
また、企画フェーズの成果物を受け取って要件定義を開始する、という点も重要です。もし企画フェーズでの成果物が中途半端であれば、それを受けた要件定義作業もまた中途半端になります。前工程の成果物が後工程の品質を決めるということも、覚えておきましょう。
STEP1：要求定義
要求定義では、課題・対応方針一覧をもとに要求事項を洗い出し、要求一覧を作成します。
始める前にチェック！
・課題・対応方針一覧が完成していること
要求定義で作る成果物
・要求一覧
要求定義は次のようなイメージです。
この工程では、課題・対応方針一覧を見ながら「要求」に具体化し、それを一覧として可視化していきます。ここでいう「要求」とは、対応方針で書いたことを具体化した「やりたいこと」と捉えてもらえればOKです。
要求一覧の作り方
要求一覧を作るには、まずは課題・対応方針一覧で書いたことを、1つずつ要求に具体化していきます。
今回は「ユーザーからの問い合わせ改善」を事例にとって解説していきます。
まず、前提になる課題と対応方針が以下のようなものだとします。
当たり前ですが、この対応方針をもとにシステムを開発できるかといえば、できません。抽象度が高すぎて、どんな機能や画面を作ればいいかわからないからです。
そのため、まず初めにこの方針を「要求」という形に具体化していきます。イメージとしては以下のような感じです。対応方針に対して「具体的に言うと？」という問いをくり返すことで、要求に落としていきます。
こんな感じで、対応方針を要求に具体化することができたら、最後に要求一覧としてまとめます。
※ こちらの要求一覧のフォーマットも活用してください（準備中）
最後に、課題・対応方針一覧に書いてある対応方針を要求一覧で網羅できているかをレビューしたら、要求定義は完了です。
STEP2：業務要件定義
業務要件定義では、要求一覧と As-Is業務フローをもとに、業務観点でやりたいことを整理し、業務要件一覧を作成します。
始める前にチェック！
・要求一覧が完成していること
・As-Is業務フローが完成していること
業務要件定義で作る成果物
・To-Be業務フロー
・業務要件一覧
業務要件定義では、いきなり業務要件定義書を作るのではなく、まずTo-Be業務フローを作成します。To-Be業務フローをもとに、システムをリリースした後の理想となる業務をイメージし、それを業務要件として具体化していきます。
ということで、業務要件定義は次の順序で作業を進めていきます。
- To-Be業務フロー作成
- 業務要件一覧作成
To-Be業務フローの作り方
To-Be業務フローとは、課題が解決され、要求が満たされた状態における「理想的な業務フロー」を可視化したものです。
それを作るために、次のようなイメージで作業を進めていきます。
まず、インプットとして必要になるのが、As-Is業務フローと要求一覧です。As-Is業務フローには現状の業務フローが書かれている一方で、要求一覧にはこれからやりたいことが書かれています。
なので、「要求一覧に書かれているやりたいことを実現するには、どのような業務フローを作ればよいのか？」を考え、それを可視化することが To-Be業務フローを作るという作業です。
多くの場合は、As-Is業務フローをベースにアップデートしていけばOKです。
※ こちらの業務フローのフォーマットも活用してください（準備中）
業務要件一覧の作り方
業務要件とは、業務の視点から要求を具体化したものです。なので、To-Be業務フローをもとに、業務プロセスや作業担当者の視点から要求を具体化していきます。
進め方はこんなイメージです。
まず、ベースになるのは要求一覧です。例として、すでに作った要求一覧のうち、真ん中にある「問い合わせを一元管理できること」という要求を具体化していきます。
具体化するときに参照するのが、To-Be業務フローです。
この「問い合わせを一元管理する」という要求を業務フローに落としたときにどうなっているかを、次の2つの観点で確認します。
- どの業務工程で行われるか？
- 誰が行う作業か？
この2つの観点で確認して、今回は「問い合わせ受付」の工程で、「問い合わせ担当者」がこの一元管理を行うと仮定します。
そうすると、問い合わせ受付の工程で問い合わせ担当者の目線に立ったとき、「問い合わせを一元管理する」という要求はどのように具体化できるか？を考えます。
今回で言うと、次の2つに分解できると考えました。イメージにするとこんな感じです。
同様に、それぞれの要求をTo-Be業務フローと突き合わせながら具体化していくと、次のように業務要件を可視化することができます。ポイントは、業務区分と担当者の視点になって要求を具体化していくことです。
STEP3：機能要件定義
機能要件定義では、業務要件一覧をもとに機能（システム）観点でやりたいことを具体化し、機能要件一覧を作成します。
始める前にチェック！
・業務要件一覧が完成していること
機能要件定義で作る成果物
・機能要件一覧
・非機能要件一覧（必要に応じて）
・画面一覧（画面を作る・変更する場合）
機能要件定義では、前工程で作成した業務要件一覧を機能の観点から見直し、機能として何をやりたいかを具体化していきます。
それに加え、どのような画面を作るかをまとめた画面一覧や、性能・セキュリティなど「機能ではないが必要なこと」を非機能要件としてまとめていきます。（ただし、画面一覧は画面を作る・変更する場合のみ、非機能要件一覧はシステム担当者に相談し、必要がある場合のみ作成します）
この機能要件定義では、機能の観点からやりたいことを具体化していくため、可能であればシステム担当や開発ベンダーと協力して作業することが望ましいです。
機能要件定義は次の順序で作業を進めていきます。
- 機能要件一覧作成
- 画面一覧作成
- 非機能要件一覧作成
機能要件一覧の作り方
機能要件とは、機能（システム）の視点から業務要件を具体化したものです。つまり、システムとしてどんな機能が必要か？を考えていくことになります。
進め方はこんなイメージです。
機能要件を作るには、まず既に定義した業務要件を実現するためにどんな機能が必要になるかを考えていきます。ここでは、業務要件の「問い合わせが一覧で可視化できること」を例にとります。
これを機能要件として具体化していくために、この要件を実現するにはどんな画面や機能があればよいか？を考えてみます。
例えば、
- 問い合わせを一覧で表示する画面が必要
- 一覧画面で絞り込み検索ができるとよい
といったイメージが出てきます。
さらに、機能要件では、
- どのような項目を一覧として表示するのか
- 検索するなら、どのような項目で検索できるようにしたいか
まで具体化していきます。
イメージとしては次のような感じです。
こうやって、業務観点で出した「やりたいこと」を、システムで実現するならどうすればいいかを詳細に具体化していきます。
最終的には、このように一覧としてまとめます。
業務観点でのやりたいことを、機能や画面として実現するにはどうしたらいいか？を考えるのは、システム開発経験がないと難しいものです。そのため、システム担当者など開発経験がある人と一緒にやることで、具体性のある機能要件を作ることができます。
画面一覧の作り方
画面一覧は、機能要件で洗い出された画面を一覧としてまとめたものです。作成自体はそこまで難しくありません。また、画面の新規作成や大きな変更が不要な場合は、無理に作る必要はありません。
作業のイメージはこんな感じです。
機能要件一覧に出てきた画面をまとめ、それぞれの画面の説明を追記すれば完成です。
可能であれば、画面遷移図や画面のイメージ（ワイヤーフレーム）もあると、見積や設計がスムーズになります。作成が必要かどうかは、システム担当者や開発ベンダーに相談するとよいでしょう。
非機能要件一覧の作り方
非機能要件は、「検索や表示」といった機能そのものではなく、性能やセキュリティなど、機能以外だが必須となる要件を定義します。
進め方のイメージはこんな感じです。
とはいえ、システム部門ではない企画担当者が非機能要件をイチから定義するのは非常に難しいので、システム担当や開発ベンダーと協力して作成することが望ましいです。
難しい場合は、非機能要件定義の作成も含めて見積を取り、開発ベンダーに依頼するのも現実的なやり方です。
参考までに、一般的な非機能要件で定義すべき項目の例を挙げておきます。
一般的な非機能要件の一覧
- 可用性（稼働率、冗長構成、フェイルオーバー、監視範囲など）
- 性能・スケーラビリティ（レスポンスタイム、同時アクセス数、ピーク時の負荷など）
- 信頼性・保守性（RTO/RPO、ログ方針、障害時の挙動など）
- セキュリティ（認証・認可、暗号化、脆弱性対策、アクセスログなど）
- 運用・監視（運用体制、監視ツール、アラートルール、運用手順など）
- バックアップ・リカバリ（バックアップ周期、世代数、復旧手順など）
- 移行要件（移行対象、移行方式、ダウンタイム許容など）
- 拡張性（将来の機能追加や外部連携を見据えた設計方針）
- 操作性・ユーザビリティ（UIルール、アクセシビリティなど）
- 法令・コンプライアンス（個人情報保護、業界規制、監査ログなど）
- 環境・インフラ要件（クラウド/オンプレ、ネットワーク、環境構成など）
- 開発プロセス・品質保証（テスト方針、品質基準、リリース方式など）
まとめ
ここまで要件定義の流れを説明してきました。長くなったので、最後に振り返ってみます。
まず、スタート地点になっていた課題と対応方針を見てみましょう。
この対応方針が、要件定義の各工程を経ることで、ここまで具体化されました。
要件定義の説明の中で、何度も「具体化」というワードを使ってきました。この具体化こそが要件定義の重要なポイントです。
当初のふわっとした「やりたいこと」を、いろんな切り口から具体化することで、このような機能要件までブレイクダウンすることができます。
いきなりこの粒度の要件を作ることができれば、要求定義や業務要件定義を行う必要はありません。でも、多くの場合、この粒度で抜けもれなく要件を洗い出すことは難しいのです。
だからこそ、めんどくさいかもしれませんが、いくつかの段階を踏んで要件を具体化するという手法をとる必要があります。
要件定義はどこまでやればいいのか？
最後に、「どこまで具体化すれば要件定義は終わりにしてよいのか？」という疑問があると思います。これは、プロジェクトや、実際に開発を行うエンジニアのスキルレベルにも依存します。
一番良いのは、見積やその後の設計を行うエンジニアに見てもらうことです。彼らが「これなら見積できますね」「これなら設計できますね」という返事をしてくれれば、必要な要件定義の粒度まで具体化できているということです。
逆に「これでは見積できません」と言われるのであれば、まだ具体化が足りていないということ。追加でどれくらい具体化が必要かアドバイスをもらい、再度、段階を踏んで具体化に取り組んでみてください。
長くなりましたが、みなさんの要件定義の一助になれば幸いです。
ぜひ、現場で試してみてください！
関連記事
Coming Soon…