要件定義の進め方

要件定義とは：作るものと作らないものを決める工程

要件定義は、システム開発の上流工程として知られています。ただ、ここで扱うのはもう少し小さな単位です。部署のダッシュボード、スプレッドシートの自動化、SaaSどうしの連携のように、数週間から数か月で作る仕組みでも、要件定義の考え方はそのまま使えます。

要件には、何ができるかを表す機能の要件と、速さ・使える時間帯・権限のような機能以外の要件があります。小さな仕組みでは、機能の一覧より先に、それを使って誰が何をするのかを決めることが、結果を大きく左右します。

小さな仕組みの要件定義でつまずくところ

規模が小さいと、要件定義を省いて作り始めることがよくあります。その結果、次のようなことが起きがちです。

• ツール名から入る：「BIを入れたい」「AIで自動化したい」から始まり、何のためかが後から問われる。
• 全部入りになる：関係者の要望を足し続け、誰の判断にも合わない画面や仕組みになる。
• 受け入れの基準がない：完成したかどうかを「動いた」で判断し、業務で使えるかを確かめない。
• 決める人がいない：要望を出す人は多いが、どれを採用するかを決める人が決まっていない。

どれも、作る技術ではなく、決め方の問題です。要件定義は、その決め方を先に揃えるための工程だと考えると、規模に関係なく必要なことが分かります。

5つのステップで進める

要件定義は、次の五つの順番で進めます。sento.groupが使うIPOAでいえば、Action（行動）から逆算して、Output、Process、Inputの順に決めていく流れです。

• ステップ1　目的：誰が、いつ、何を決める／するための仕組みかを一文にする。
• ステップ2　業務の流れ：今の業務の流れと、仕組みができた後の流れを並べて書く。
• ステップ3　データ：必要なデータは何で、どこにある値を正とするかを決める。
• ステップ4　仕組み：画面、通知、自動化など、どの形で実現するかを決める。
• ステップ5　受け入れ：一回分の実際の業務で使って、目的を果たせたかを確かめる基準を決める。

ステップ4で初めてツールや作り方が出てきます。先にツールを決めてしまうと、ステップ1から3が「そのツールでできること」に引きずられ、目的からずれた仕組みになりやすくなります。

ステップ1：目的を「誰が・いつ・何を」で書く

目的は、「効率化する」「見える化する」のような言葉で終わらせず、人と場面と行動で書きます。

• 弱い書き方：「営業の数字を見える化する」
• 強い書き方：「毎週月曜の営業会議で、営業リーダーが今週追う案件を決める」
• 弱い書き方：「請求業務を自動化する」
• 強い書き方：「毎月5営業日目までに、経理担当が請求書の送付漏れがないことを確かめられる」

上の例は説明用の仮想例です。強い書き方にすると、必要な数字や画面が自然に絞られます。この一文が書けないときは、まだ作る段階ではなく、業務の決め方を話し合う段階です。話が理想論や遠い将来の心配に流れるときは、関連記事「タイムアンドスペース法とは」の引き戻し方が役に立ちます。

ステップ2・3：業務の流れとデータを確かめる

目的が決まったら、今の業務がどう流れているかを確かめます。担当者の説明だけに頼らず、実際の帳票や画面、ファイルを見ながら書き出すのが確実です。

業務の流れは、業務フロー図にすると、誰がどこで待っているか、どこで転記しているかが見えます。次に、その流れで使うデータについて、項目ごとに「どこにある値を正とするか」「同じものを何で見分けるか」「言葉の意味は部署で揃っているか」を確かめます。ここで定義のずれが見つかったら、仕組みを作る前に揃えておくと、後の手戻りが大きく減ります。

要件定義シートを1枚にまとめる

小さな仕組みなら、要件は1枚のシートにまとめられます。欄は次の九つです。

• 目的、使う人と場面、今の業務とつまずき。
• 出力（一覧・画面・通知・帳票）、処理のルール（計算式・判定条件・例外）、入力データと正の置き場所。
• やらないこと、受け入れ基準、決める人と期限。

1枚に収まらないときは、仕組みが大きすぎるか、目的が複数混ざっているサインです。目的ごとにシートを分け、最初に作る一枚を選びます。

「やらないこと」と受け入れ基準を書く

要件定義で見落とされやすいのが、やらないことと、受け入れの基準です。

• やらないこと：今回は対象外にする部署、データ、機能を書く。「将来やるかもしれないこと」もここに置き、今回の範囲から外す。
• 受け入れ基準：「画面が表示される」ではなく、「月曜の営業会議で、リーダー全員が今週追う案件を画面から決められた」のように、一回分の業務で確かめられる形で書く。

やらないことを書くと、作っている途中で増える要望を、次の段階に回す根拠になります。受け入れ基準を業務の言葉で書くと、作る側と使う側で「完成」の意味が揃います。

説明用の仮想例：週次の営業会議の仕組み

ここでは説明用の仮想例として、週次の営業会議で使う案件一覧の仕組みを、要件定義シートに沿って書いてみます。

• 目的：毎週月曜の営業会議で、営業リーダーが今週追う案件を決める。
• 使う人と場面：営業リーダー3名と部長。会議の冒頭15分、会議室の画面で見る。
• 今の業務：営業事務が金曜に各担当のExcelを集めて一つにまとめている。担当によって列の名前と「見込み度」の基準が違う。
• 出力：今月受注予定の案件一覧（顧客名・金額・見込み度・次の約束日・担当）。
• 処理のルール：見込み度は全員共通の三段階で判定し、次の約束日が過ぎた案件を上に並べる。
• 入力データ：案件管理のSaaSを正とし、Excelでの管理はやめる。顧客名は顧客IDで見分ける。
• やらないこと：過去の受注実績の分析、個人別の成績表示。
• 受け入れ基準：二回続けて、会議の冒頭15分で全リーダーが今週追う案件を決められた。

書いてみると、「見込み度の基準を揃える」という、仕組みを作る前に決めるべき業務のルールが見つかります。要件定義の価値の多くは、こうした発見にあります。

社内外の作り手との進め方

外部に依頼する場合も、社内で作る場合も、要件定義シートを共通の資料にすると進めやすくなります。

• 見積もりの前に、目的と受け入れ基準を渡す。機能の一覧だけを渡すと、目的に合わない提案が来やすくなります。
• 決める人を一人決める。要望が出たときに、採用・保留・やらないことへの追加を決める人です。
• 途中で一度、実データで試す場面を入れる。最後にまとめて確かめるより、ずれに早く気づけます。

生成AIに要件の整理を手伝わせることもできます。その場合も、目的の一文と、今の業務の実物（帳票や画面の例）を渡すと、もっともらしいだけの要件になりにくくなります。