当サイトの記事は編集部がIPAなど公的機関の公開資料と読者の声を調べて独自に執筆しています。
要件定義を任されたものの、「何から手をつければいいのか、そもそも何がわからないのかもわからない」と悩んでいませんか。
結論から言うと、要件定義が難しいと感じる理由は、人・情報・時間の三つに分けると見えてきて、それぞれに打ち手があります。
この記事では、つまずきやすい場面と原因、すぐに試せる打ち手を表で紹介します。
要件定義が難しいと感じるのは、あなただけではありません
要件定義は、答えが最初から用意されていない仕事です。
だから難しく感じるのは自然なことで、能力が足りないせいではありません。
要件定義（RD：Requirements Definition）は、システムで何を実現するかを関係者で決める工程です。
プログラムを書く仕事なら、「動くかどうか」で正解が分かりますよね。
一方で要件定義は、関係者の考えをすり合わせて「これで行こう」と決める仕事です。
正解を探すというより、正解を一緒に作る仕事なんです。
『ほかの人はうまくやれているのに、自分だけ分からない』と感じる方もいるかもしれません。
実は、経験を積んだ人でも要件定義には苦労します。
難しさの正体を知っておくだけで、焦りはかなり減りますよ。
要件定義の難しさは、ほかの工程とどこが違う？
ほかの工程と比べると、要件定義ならではの難しさが見えてきます。
| 比べる点 | 要件定義 | 設計や開発 |
|---|---|---|
| 答えのありか | 関係者の頭の中にあり、話し合って決める | 要件定義書や設計書に書かれている |
| 相手 | 業務部門、責任者、開発チームなど立場の違う人 | 主に開発チームの中 |
| 正しさの確かめ方 | 関係者が合意したか | 動くか、仕様どおりか |
| 決まらない時の影響 | 後の工程すべてに響く | その部分の作業に響く |
難しさを感じやすいタイミング
要件定義の難しさは、ずっと同じ強さで続くわけではありません。
感じやすいタイミングは、だいたい次の三つです。
- 始めたばかりで、業務の言葉や流れがまだ分からない時
- 要望が出そろい、どれを優先するか決めなければならない時
- 承認の直前に、決まっていなかった点が見つかった時
どのタイミングも、多くの人が同じように悩むところです。
「今はこの段階だから難しいんだ」と分かるだけでも、気持ちが少し落ち着きますよ。
要件定義の目的そのものを確かめたい方は、要件定義の目的もあわせてどうぞ。
難しさを「人・情報・時間」の三つに分けてみる
つまずきの原因は、人（関わる人の考え）、情報（材料の足りなさ）、時間（決める時期の制約）のどれかに分けられることが多いです。
原因の種類が分かれば、打ち手も選びやすくなります。
『なんとなく難しい』のままだと、何を直せばいいか分かりませんよね。
そこで、つまずきを三つの種類に分けてみましょう。
つまずきの原因と打ち手の表
ここでは、架空の「工場の設備点検の記録を、紙の点検表からタブレット入力に変える場合」を例に並べます。
| 種類 | よくあるつまずき | 原因 | 打ち手の例 |
|---|---|---|---|
| 人 | 現場と管理部門で、ほしいものが食い違う | 立場によって目的が違う | 目的を一文で書き、責任者に優先順位を決めてもらう |
| 人 | 「お任せします」と言われて決まらない | 決める人がはっきりしない | 案を二つ作り、選んでもらう形にする |
| 人 | 打ち合わせで発言が少ない | 何を聞かれているか分からない | 選択肢や記入例を見せて質問する |
| 情報 | 今の業務の流れが分からない | 業務が人の頭の中にしかない | 実際の点検表を見せてもらい、業務フロー図にする |
| 情報 | 例外の対応が後から出てくる | いつもの流れしか聞いていない | 「うまくいかない時はどうしますか」と聞く |
| 情報 | 言葉の意味が人によって違う | 用語の定義がない | 用語集を作り、意味をそろえる |
| 時間 | 決めきれないまま期限が来る | 決めることの順番が決まっていない | 決まらない点を課題管理表に移し、期限を決める |
| 時間 | 後から要望が追加される | 範囲を合意していない | 「今回はやらないこと」も書いて合意する |
| 時間 | 打ち合わせの時間が取れない | 現場の担当者が忙しい | 確認したいことを事前に送り、短い時間で済ませる |
この表のどこに自分のつまずきが当てはまるか、一度見比べてみてください。
「人」のつまずき：考えが食い違う
いちばん多いのが、関わる人の考えが食い違うことです。
点検の例なら、現場は「入力の手間を減らしたい」、管理部門は「記録を細かく残したい」と考えているかもしれません。
どちらも正しいので、エンジニアや担当者が勝手にどちらかを選ぶと、後で揉めてしまいます。
「現場の入力を減らすことと、記録を細かく残すことは、どちらを優先しましょうか」
「まずは入力の漏れをなくしたいので、項目は必要なものだけに絞ってください」
こんなふうに、決める立場の人に優先順位を言葉にしてもらうのが近道です。
「情報」のつまずき：材料が足りない
次に多いのが、決めるための材料が足りないことです。
業務のやり方が文書になっておらず、ベテランの頭の中にしかない、というのはよくある話ですよね。
この場合は、話を聞くだけでなく、実物を見せてもらうのがおすすめです。
紙の点検表を一枚見せてもらうだけで、どんな項目を、どの順番で書いているかが分かります。
「時間」のつまずき：決める時期が合わない
三つ目は、時間のつまずきです。
全部を決めてから次へ進もうとすると、いつまでも終わらないことがあります。
決めきれない点は、課題として一覧に移し、「誰が、いつまでに決めるか」を書いて先へ進みましょう。
自分のつまずきがどれか、チェックしてみよう
今まさに困っている方は、次の項目で当てはまるものを数えてみてください。
- 関係者の言うことが、人によって違う（人）
- 誰が最終的に決めるのか、はっきりしない（人）
- 今の業務のやり方を、文書で確かめられない（情報）
- 同じ言葉を、部署によって違う意味で使っている（情報）
- 決めることが多すぎて、期限に間に合いそうにない（時間）
- 一度決めたことが、後から何度も変わる（時間）
当てはまる項目が多い種類から手をつけると、効き目が出やすいです。
例えば「人」が多いなら、まずは決める人をはっきりさせることから始めてみましょう。
決まっていないことを残すのは、失敗ではありません。
「決まっていないことが分かっている」状態にしておくことが大事なんです。
「何がわからないのかわからない」時の抜け出し方
要件定義がわからない時は、わからないことを「言葉」「流れ」「決まり」「範囲」の四つに分けて書き出してみましょう。
書き出すだけで、誰に何を聞けばいいかが見えてきます。
要件定義を初めて担当すると、打ち合わせの後に『結局、何が決まったんだろう』とぼんやりすることもありますよね。
これは、わからないことが頭の中で混ざっている状態です。
わからないことを四つに分ける
| わからないことの種類 | 例（点検の案件） | 聞く相手 |
|---|---|---|
| 言葉 | 「日常点検」と「定期点検」は何が違うのか | 現場の担当者 |
| 流れ | 点検で異常が見つかった後、誰に連絡するのか | 現場の責任者 |
| 決まり | 点検の記録は、どのくらいの期間残す必要があるのか | 管理部門 |
| 範囲 | 修理の依頼まで今回のシステムで扱うのか | プロジェクトの責任者 |
わからないことを書き出す時は、思いついた順でかまいません。
あとで四つの種類に振り分けると、聞く相手ごとにまとめて質問できます。
質問は「選べる形」にすると答えてもらいやすい
「どうしたいですか？」と聞くと、相手も考え込んでしまいます。
「異常が見つかったら、点検した人がその場で連絡しますか、それとも一日の終わりにまとめて報告しますか」と、選べる形で聞いてみてください。
答えやすい質問は、打ち合わせの時間を短くしてくれますよ。
- わからないことを四つの種類に分けたか
- 聞く相手ごとに質問をまとめたか
- 質問を、選べる形や記入例つきにしたか
- 前回の宿題がどうなったかを確認する時間を取ったか
要件定義の全体の流れを先に知っておくと、今どこで迷っているかも分かりやすくなります。
要件定義の進め方・手順で、順番を確かめておくのもおすすめです。
つまずきやすい場面と、その時の動き方
要件定義のつまずきは、だいたい決まった場面で起きます。
場面ごとに「こう動く」と決めておくと、慌てずに済みます。
ここからは、要件定義の途中でよく起きる場面を、順番に見ていきましょう。
場面1：ヒアリングで要望が出てこない
「何か困っていることはありますか」と聞いても、「特にないです」と返ってくることがあります。
これは、困っていないのではなく、困りごとに慣れてしまっていることが多いんです。
その時は、作業を一つずつ一緒にたどってみましょう。
「点検表を書いた後は、どこに持っていきますか」
「事務所の棚に置いて、月末に管理部門がまとめて取りに来ます」
「月末までの間に、記録を探したくなることはありませんか」
「あります。急ぎで過去の記録を見たい時、棚を全部めくっています」
こうして流れをたどると、言葉にならなかった困りごとが出てきます。
場面2：要望が多すぎてまとまらない
逆に、要望が次々に出てまとまらないこともあります。
その時は、要望を全部受け止めたうえで、目的に照らして優先順位をつけます。
| 要望（例） | 目的とのつながり | 扱い（例） |
|---|---|---|
| 点検の結果をその場で入力したい | 入力漏れをなくす目的に直結 | 今回の対象 |
| 過去の記録をすぐに探したい | 記録を活用する目的につながる | 今回の対象 |
| 点検の写真を残したい | あると便利だが、目的には間接的 | 責任者と相談 |
| 修理業者への発注までつなげたい | 今回の目的の外 | 次の段階で検討 |
「次の段階で検討」と書いておけば、要望を出した人も納得しやすくなります。
場面3：設計に入ってから要件が追加される
要件定義が終わり、設計に入ってから「この項目も入れてほしい」と言われることもあります。
これは、どの案件でも起こりうることです。
大事なのは、追加を断るかどうかより、変更として扱う手順を決めておくことです。
- 追加の要望と、その理由を記録する
- 目的とつながるか、今回の範囲に入るかを確かめる
- 予算や期間への影響を開発側が見積もる
- 責任者が、今回入れるか次の段階にするかを決める
- 決まった内容を要件定義書と議事録に反映する
打ち合わせの場で「それくらいなら入れられます」と軽く引き受けてしまうケースです。
小さな追加でも積み重なると、予定どおりに終わらなくなります。
場面4：非機能要件で何を決めればいいかわからない
機能の話はできても、性能や運用の話になると止まってしまうこともあります。
『どのくらいの速さなら十分か、と聞かれても困る』と感じますよね。
その時は、IPAの「非機能要求グレード」が手がかりになります。
可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6つの大項目に分け、各項目のレベルを0〜5の段階から選ぶ方式です。
点検の例なら、「タブレットが使えない時は、紙の点検表で代わりに記録できればよい」といった業務の目線から話すと、発注側も答えやすくなります。
場面5：レビューで何も指摘が出ない
要件定義書を配ってレビューをお願いしても、「特に問題ありません」で終わってしまうことがあります。
一見順調に見えますが、実は読まれていないだけ、ということも少なくありません。
その時は、読む人ごとに「ここだけ見てください」と範囲を絞ってお願いしてみましょう。
| 読む人 | 見てほしい範囲（例） | 聞き方の例 |
|---|---|---|
| 現場の担当者 | 業務フロー図と、点検の入力項目 | 「いつもの点検で、書く項目に抜けはありませんか」 |
| 管理部門 | 記録の保管と、集計の帳票 | 「月末の集計に、この帳票で足りますか」 |
| 責任者 | 目的、範囲、今回やらないこと | 「この範囲で進めてよいか、決めていただけますか」 |
| 開発チーム | 機能要件と非機能要件 | 「この書き方で、設計とテストに進めますか」 |
範囲と問いがはっきりすると、具体的な指摘が返ってきやすくなります。
指摘が出るのは、要件定義書が良くなっている証拠なんです。
要件定義ガイド
まずは型をそろえよう｜要件定義書のテンプレートと記入例
章立て・各章に書くこと・1行の記入例をひとつの表にまとめました。白紙から書き始める前に、型を手元に置いておきましょう。
無料要件定義書のテンプレートを見る当サイトの記事ページに移動します。
一人で抱えないための相談のしかた
要件定義は、一人で抱え込むほど難しくなる仕事です。
「誰に、何を、いつ相談するか」を決めておくと、行き詰まった時に動きやすくなります。
要件定義を任されると、『自分が全部まとめなければ』と思い込みがちですよね。
でも、要件定義は関係者と一緒に決める仕事なので、相談するのは当たり前のことなんです。
| 困りごと | 相談する相手（例） | 相談のしかた |
|---|---|---|
| 業務の流れが分からない | 現場の担当者 | 実際の作業を見せてもらう |
| 優先順位が決まらない | プロジェクトの責任者 | 選択肢と、それぞれの影響を並べて渡す |
| 実現できるか分からない | 開発チームのメンバー | 要望と目的をセットで伝えて聞く |
| 進め方に迷う | 社内の経験者 | 今の課題管理表を見せて助言をもらう |
誰が要件定義のどこを担うのかは、要件定義は誰がやる？SE・エンジニアの役割で立場ごとに紹介しています。
また、要件定義を少しずつ身につけたい方には、要件定義のスキルを未経験から身につける方法も参考になります。
よくある相談に答えます
要件定義が難しい、わからないと感じている方の、よくある相談を要約してお答えします。
仕事の依頼を受けた時点で何を作るかは決まっているはずなのに、なぜわざわざ要件定義をするのか、という相談です。
依頼を受けた時点で決まっているのは、多くの場合「こうしたい」という要求までです。
要求は、利用者や発注者の希望のことで、それを予算・期間・技術を踏まえて「システムで実現すると合意したこと」が要件です。
例えば「点検を楽にしたい」という要求だけでは、何をどこまで作れば完成なのかが決まりません。
その間を埋めるのが要件定義なんです。
初めて要件定義を担当していて、抜け漏れのない完全なものにしたいが、どう進めればいいか、という相談です。
その気持ち、とてもよく分かります。
ただ、最初から完全な要件定義を目指すと、いつまでも終わらなくなりがちです。
まずは「決まったこと」と「決まっていないこと」を分けて書き、決まっていないことに担当者と期限をつけてみてください。
抜け漏れの確認には、業務の流れを一つずつたどる方法と、非機能要求グレードの大項目に沿って見直す方法が役立ちます。
要件定義、外部設計、内部設計、開発、運用保守のうち、どれがいちばん難しいのか、という相談です。
どの工程にも難しさがあるので、一つに決めるのは難しいところです。
ただ、要件定義には「答えを関係者と一緒に作る」という、ほかの工程にはない難しさがあります。
そして、要件定義でのずれは後の工程すべてに響くので、難しいと言われることが多いんですね。
逆に言えば、要件定義で目的と範囲がそろっていれば、後の工程はぐっと進めやすくなります。
難しさの分だけ、時間と手をかける価値のある工程だと考えてみてください。
焦らず、一つずつ決めていけば大丈夫です。
よくある質問
要件定義が難しいと感じるのは、経験が足りないからですか？
経験が増えると楽になる部分はありますが、経験者でも要件定義には苦労します。答えを関係者と一緒に作る仕事なので、難しさを感じるのは自然なことです。
要件定義がわからない時、まず何をすればいいですか？
わからないことを「言葉」「流れ」「決まり」「範囲」の四つに分けて書き出してみてください。誰に何を聞けばいいかが見えてきます。
要件定義で揉めないためのコツはありますか？
目的を一文で書いて共有することと、「今回はやらないこと」も書いて合意することです。決めた人と理由を議事録に残しておくと、後で揉めにくくなります。
要件定義の勉強に役立つ資料はありますか？
IPAが2019年に公開した「ユーザのための要件定義ガイド 第2版」は、発注側の目線で要件定義のつまずきと解決のコツをまとめた資料です。発注側の考え方を知る手がかりになります。
まとめ
- 要件定義が難しいのは、答えを関係者と一緒に作る仕事だから
- つまずきは、人・情報・時間の三つに分けると打ち手を選びやすい
- わからない時は、言葉・流れ・決まり・範囲に分けて書き出す
- 要件の追加や非機能要件など、つまずく場面ごとの動き方を決めておく
- 一人で抱えず、困りごとに合わせて相談する相手を決めておく
要件定義の全体像からおさらいしたい方は、要件定義とはに戻って読んでみてください。
コメント