要件定義ができない人の共通点と抜け方｜原因は能力ではなく、決める順番にある

要件定義が「できない」のは、向き不向きではなく、決める順番の問題です。要件定義を任されたものの、何から書けばよいか分からない。聞き取りをしても要望がまとまらない。そう感じる人は少なくありません。この記事では、中小企業の非エンジニアが業務アプリやシステムを作る場面を前提に、要件定義が止まる3つのパターンと、それぞれの抜け方を説明します。

要件定義ができない人に多い3つの詰まり方

要件定義が止まる形は、言葉にできない、画面から考えてしまう、目的を絞れない、の3つに分けられます。どれも本人の能力ではなく、聞き方や決める順番で起きるものです。自分がどれに近いかが分かると、次にやることが決まります。

まず決めるのは、誰が・何を使って・どのデータとつながるか

要件定義の最初の一歩は、機能の一覧ではなく、3つの問いに1行ずつ答えることです。誰が使うか、何を使って入力するか、どのデータとつながるか。この3つが決まらないまま機能を足していくと、後から「これは誰が見るのか」「この情報はどこが正なのか」で作り直しになります。

要件定義で最初に書く3行（誰が・何を使って・どのデータとつながるか）のうち、「どのデータとつながるか」は、顧客や物件などの箱と、箱どうしの関係を線で結んだER図にすると確かめやすくなります。描き方はER図の書き方、AIに下書きさせる方法はER図をAIで作成する方法で説明しています。

要件定義が進まないとき、まず決めること｜機能要件・非機能要件・要件定義書の項目

要件定義は、現場の要望を「システムで実現すること」に翻訳し、要件定義書に残す作業です。決める中身は大きく、機能要件（何ができるか）と非機能要件（どんな条件で動くか）に分かれます。「できない」と感じる人の多くは、この2つが混ざったまま、要望を一度に整理しようとして止まります。

要件定義書は、目的と対象業務、現状の課題、利用者、機能要件、非機能要件、データの項目、対象外の順に書けば形になります。立派な文書にすることより、決まっていない所に「未決」と書いて残すことのほうが、後の手戻りを減らします。

要望が多すぎるときは、必須・あれば良い・今回はやらないに分ける

要望を全部入れようとして止まるときは、1件ずつ「これが無いと業務が回らないか」を聞いて3つに分けます。無いと業務が止まるものが「必須」、あると楽になるものが「あれば良い」、今回は作らないと決めるものが「対象外」です。対象外を書き出すことが、スコープ（作る範囲）を決めることになります。

1. 出てきた要望を、判断せずにすべて書き出す。
2. 1件ずつ「これが無いと、今の業務は止まりますか」と聞く。止まるなら必須。
3. 止まらないものは、あれば良いか対象外に振る。対象外の理由も一言残す。
4. 必須だけで最初のリリースを決め、残りは次の段階の候補として別の欄に置く。

関係者の認識ズレは、目的・範囲・決める人の3点で合わせる

要件定義で最後まで残る失敗は、書けないことより、関係者ごとに理解が違ったまま進むことです。経営者、現場の担当者、開発する側では、同じ言葉でも想像する中身が違います。目的（何を良くするために作るか）・範囲（作るものと作らないもの）・決める人（要望が割れたとき最終判断する1人）の3点を文書にして、全員で読み合わせると早く見つかります。

• 目的：何を良くするために作るか。1文で書く。
• 範囲：作るものと作らないもの。「今回はやらないこと」も書く。
• 決める人：要望が割れたとき、最終的に判断する人。1人に決める。

読み合わせでは、「分かりましたか」ではなく「この場面なら誰が何を押しますか」と具体的に聞きます。答えが人によって違えば、そこが認識のズレです。ズレは要件定義の段階で直せば文書の修正で済み、開発が進んでから見つかると作り直しになります。

言葉にできない人には、10項目を1〜5で採点してもらう

困っていることを言葉にできない相手には、文で答えさせるより、点数で答えてもらうほうが進みます。美容室のオーナーのように困りごとを言葉にできない相手には、候補を10項目に分けて並べ、それぞれを1から5で採点してもらう診断が使えます。「何に困っていますか」と聞くと止まる人でも、「予約管理は何点ですか」なら答えられます。

• 項目は10個前後にして、業務の言葉で書きます（例：予約の受け方、売上の見え方、在庫の数え方）。
• 点数は「困っている度合い」を1〜5で答えてもらいます。
• 点数の高い項目から、「最近、実際にあった場面」を1つずつ聞きます。

自分が要件を書く側のときも、同じ方法が使えます。頭の中の困りごとを、まず点数で並べてから、上位の1〜2項目だけを文章にします。

画面から考えてしまう人は、業務の流れを先に書く

「こんな画面が欲しい」から始めると、業務の流れが抜けます。不動産会社の案件管理で、カンバン型のデモを見せたところ、画面への要望が先に出そうになった場面がありました。そこで、画面の話の前に、社内の登場人物と業務の流れを整理し、そのうえで優先順位を決めることにしました（進行中の案件のため、結果はまだ出ていません）。

やり方は、紙に次の順で書くだけです。

1. 登場人物を横に並べる（営業、事務、部長など）。
2. 問い合わせが来てから契約までの出来事を、時間順に並べる。
3. 出来事ごとに、誰が何を入力し、誰が何を見るかを書く。
4. 手間がかかっている所や、情報が行き来する所に印をつける。

印のついた所が、画面や機能の候補です。流れを書いてから画面を考えると、機能が業務に紐づいた状態で決まります。業務構造を先に棚卸しする理由は要件定義の進め方でも説明しています。

目的を絞れない人は、出力の使い道を先に聞く

要望が増え続けるときは、機能の話をやめて、その出力を誰が何の判断に使うかを聞きます。不動産会社で「査定の精度を上げたい」という相談を受けたとき、中身を聞くと、その数字は社外に一切出さず、買うかどうかを社内で決めるためだけに使うものでした。社外に見せる数字ほどの精度は要らないと分かり、作る範囲が絞れました。

文章で詰まったら、デモを見せて要件を固める

文章で要件を詰められないときは、2回目のヒアリングの代わりに、動くデモや画面の絵を見せる方法があります。当社の支援でも、ヒアリングを1回で終えてからデモを作って見せる進め方を取ることがあります。2回目のヒアリングで文章のまま詰めるより、見たものに「違う」「ここを足したい」と返してもらえるため、要望が具体的になりやすいと考えています。日数や項目数が何割減ったかは、記録で数えていないため示していません。

見たものに対しては、「ここは違う」「これは要らない」と言いやすいためです。ゼロから文章にする負担を、相手に直してもらう作業へ変えられます。ただし、デモは3つの問い（誰が・何を使って・どのデータ）に答えたうえで作ります。画面だけ先に作ると、画面の好みの議論になります。

AIにコードを書かせる前に決めないと、修正の沼にはまる

AIでアプリを作る場合も、コードを書かせる前に「誰が使うか・何を使うか・どのデータとつながるか」を決めます。決めずに頼むと、動くものはできます。ただ、使う人が増えたり、データが足りなかったりするたびに直すことになり、直すほど別の所が壊れる「修正の沼」にはまりやすくなります。

3行の答えを書いてから頼めば、AIが推測で埋める部分が減ります。AIを使った進め方は要件定義をAIで進める方法に、決めずに始めた失敗例はバイブコーディングのデメリットにまとめています。

社内で進まないなら、外部に頼む線引き

要件定義の「誰が使うか・何を使うか・どのデータとつながるか」を決める人が社内に1人もいない場合、または業務の整理に割ける時間がない場合は、外部の支援を使うほうが早く進みます。要件定義の支援で何を頼めるか、費用の見積もりで何を確かめるかは要件定義のコンサルとはで説明しています。頼む前に、3行の答えを書けるだけ書いておくと、相談の最初の30分を整理に使えます。

来週の一歩｜3行を書き、書けなかった所に印をつける

作りたい業務アプリを1つ選び、「誰が」「何を使って」「どのデータとつながるか」を1行ずつ書いてください。書けなかった行が、いま決まっていない所です。その行について、誰に聞けば決まるかを1人書き添えます。効果は、書けなかった行の数が、1週間後に減っているかで測れます。

まとめ｜できないのではなく、順番が違うだけ

要件定義ができないと感じるときは、能力を疑う前に、決める順番を見直します。SalesDockは、コードの前に業務の構造を文章にする進め方で、中小企業の経営管理基盤の実装と定着を月額で支援しています。まずは3行を書くところから始めてください。

要件定義ができない人に関するよくある質問