開発・新規事業
要件定義がまとまらないとき、最初に整理すること｜目的・業務・優先順位の考え方
要件定義が進まないときは、目的・業務・課題・解決方法を分けることから。コピーして使える要件整理シートと、今作る・後に回す・作らないを判断する架空例を紹介します。
資料確認・原稿更新：
「現場の要望は集めたのに、何を開発するか決まらない」。そんなときは、機能を追加して整理しようとする前に、それぞれの要望が何を解決するためのものかを確かめてみてください。
要件定義の出発点としてNicoが大切にするのは、目的、業務上の課題、解決方法を分けることです。何を実現したいかがそろうと、機能の必要性を同じ基準で話し合えるようになります。
1. 要望をそのまま機能にしない
例えば「自動通知がほしい」という要望には、対応漏れを防ぎたい、進捗を問い合わせる手間を減らしたい、担当交代時に引き継ぎたいなど、異なる目的が考えられます。目的によって、通知する相手もタイミングも変わります。
- 要望現場から出た言葉
- 目的何を良くしたいか
- 業務今の流れ
- 課題困っている点
- 解決方法機能は最後に決める
本文の考え方を整理した説明図です。
次は架空の案件管理業務を使った整理例です。
| 分ける項目 | 記入例 |
|---|---|
| 目的 | 問い合わせへの初回対応を確実に行いたい |
| 現状 | メールと表計算で担当状況を別々に管理している |
| 課題 | 未対応なのか、対応済みで記録していないのか判別できない |
| 解決案 | 担当・状態を共通管理し、必要な場合に通知する |
| 確認方法 | 未対応案件が把握でき、担当者に引き継げるか試す |
通知だけを作っても、状態の更新ルールが曖昧なら問題は残ります。業務と機能を一緒に考えることが必要です。
2. 現場の流れを一件分たどる
「普段どうしていますか」だけでなく、最近処理した一件を、受付から完了まで説明してもらいます。誰が受け取り、何を見て判断し、どこへ記録するのか。差し戻しや担当者の不在があった場合も確認します。
この段階では画面の見た目を決めきる必要はありません。まず、情報の受け渡しと判断する場面を理解します。
3. 優先順位と判断者を決める
要望ごとに、放置した場合の影響、発生頻度、他の機能の前提になるか、別の方法で対応できるかを整理します。「欲しい」という意見の強さだけで順番を決めないためです。
未決事項には、判断する人、必要な情報、決める期限を添えます。意見が割れたときは、どの目的を優先するかまで戻って確認します。
IPAの要件定義ガイド解説でも、ビジネス要求定義と要件定義マネジメントを独立したテーマとして扱っています。機能一覧に加え、事業の要求と決め方を整理する際の参考になります。出典：IPA「ユーザのための要件定義ガイド 第2版 解説動画」
4. 会議で使う要件整理シート
次の表はNicoが提案する記入用のひな形です。表を社内の文書や表計算へコピーし、困っている業務を一つ選んで記入してください。このページ上で入力・保存する機能はありません。分からない項目は無理に埋めず、「誰に確認するか」を残します。
| 記入項目 | 確認すること | 自社のメモ |
|---|---|---|
| 目指す状態 | 誰が、何をできるようになればよいか | ＿＿＿＿ |
| 現在の業務 | 受付から完了まで、誰が何を使って進めるか | ＿＿＿＿ |
| 困っている場面 | 最近の一件で、どこに手間・漏れ・迷いがあったか | ＿＿＿＿ |
| 影響と頻度 | 誰への影響があり、どのくらい発生するか | ＿＿＿＿ |
| 必須条件 | 権限、扱う情報、連携、例外対応で外せない条件は何か | ＿＿＿＿ |
| 優先する範囲 | 最初に解決することと、今回扱わないことは何か | ＿＿＿＿ |
| 完了の確認 | どの操作・業務ができれば、目的を満たしたと判断するか | ＿＿＿＿ |
| 未決事項 | 何を、誰が、どの情報を使い、いつまでに決めるか | ＿＿＿＿ |
共有する資料からは、個人情報や機密情報を除いてください。この表だけで仕様が完成するわけではありません。関係者の認識が違うところを見つけ、次に確認することを決めるための出発点です。
5. 「今作る・後に回す・作らない」を分ける
先ほどの架空の案件管理業務を使うと、次のように判断を整理できます。Nicoの顧客実績や、すべての案件に共通する推奨仕様ではありません。
| 解決案 | この例での判断 | 判断の理由・確かめること |
|---|---|---|
| 担当者と対応状態を共通管理する | 最初の対象にする | 未対応の案件を見分けるための前提になる。担当交代時にも更新できるか確認する |
| 未対応案件を自動通知する | 運用を確かめてから決める | 状態の更新ルールと確認手順を先に試し、どの通知が必要か判断する |
| 見栄えのよい集計画面を作る | 今回は対象にしない | 初回対応の漏れを防ぐ目的に対して、使う人と判断する場面がまだ説明できない |
「後に回す」は、重要でないという意味ではありません。判断に必要な情報が足りない場合は、確認する方法と見直すタイミングを決めます。権限や法令対応などの必須条件は、機能の優先順位だけで省略しないよう別に確認します。
見積もりを依頼するときは、この区分と前提条件を一緒に渡すと、どこまでを比較しているか話し合いやすくなります。見積もりを比較する際の確認項目も併せて整理できます。
最初の打ち合わせに持っていくもの
- 実現したい状態を一文で書いたもの
- 現在の業務が分かる資料や、個人情報を除いた記入例
- 特に困っている場面と、その影響
- 決まっていること・まだ決まっていないこと
- 社内で判断する人と、実際に使う人
完璧な仕様書がなくても、この情報があれば整理を始められます。Nicoは、現場と事業の話を聞き、開発チームへ渡せる要件にまとめるところから支援します。