要件定義の進め方

はい。「AIを使いたい」「この業務を効率化したい」と思っていても、何をシステム化すればよいのか分からないケースは珍しくありません。

Beekleでは、いきなり機能の話から始めるのではなく、次の点から整理します。

• 現在どんな業務をしているか
• どこで時間やコストが発生しているか
• 誰が困っているか
• 何が変われば成功なのか

その結果、曖昧だった構想が「何を作れば、何が改善するのか」まで具体化された状態で開発判断ができるようになります。最初から完成した仕様書をご用意いただく必要はありません。

原則は「業務要件＝発注側」「システム要件＝開発側」の役割分担です。ただし現実には発注側が言葉にしきれない場面も多く、その場合は無理に文書化せず別の進め方で補います。

原則として、誰が・何を・なぜやりたいか（業務要件）は現場を知っている発注側にしか書けません。一方、それを実現するシステム構成・画面設計・データモデル（システム要件）は開発側の専門領域です。「業務要件のたたき台を発注側が書く → 開発側がヒアリングしながらシステム要件に翻訳する」が最も摩擦が少ない進め方です。

とはいえ、新しい業務やまだやったことがない領域では「何が要件か自分でも分からない」段階があります。Beekleでは、無理に文書化を求めず、ざっくりヒアリングして動くデモを先に作り、それを触りながら要件を固めていく進め方も併用しています。「文書化が先、開発は後」と決めつけず、その案件に合った順序を選ぶのが現実的です。

発注側が自分でたたき台を書きたい場合は、ユーザーストーリー作成ツールでフォーマットの悩みを省けます。デモから入りたい場合はプロトタイプ無料体験からご相談ください。

「うまくいくケース」だけでなく「うまくいかないとき何が起きるか（異常系）」を一つひとつ詰めることが、抜け漏れを防ぐ一番の近道です。

抜け漏れの大半は次の3パターンに集約されます。(1) エラーが起きたときの挙動が決まっていない、(2) 利用者の役割・権限ごとの差分が決まっていない、(3) 終わったあとの扱い（履歴・削除・アーカイブ）が決まっていない。要件レビューでは「もし◯◯が起きたらどうする？」をひたすら聞いて、すぐ答えが出ないものは要件として未確定だと考えます。

進め方としては、まずユーザーストーリーで「やりたいこと」を出し、最終的に Gherkin（Given / When / Then）のような形式で受入条件を書き下していくと、異常系の検討が漏れにくくなります。最初から完璧なフォーマットを目指さず、「異常系を詰める」を目的にして合うやり方を選ぶのが現実的です。

異常系の整理のたたき台にはユーザーストーリー作成ツール、考え方はユーザーストーリーから受入条件まで繋げる流れを参考にしてください。

主語と検証可能性で区別します。要望（要求）は「顧客が何をしたいか」を主語にした願望、要件は「システムが何を満たすか」を主語にした検証可能な条件です。

例えば「営業担当が外出先からも顧客情報を確認したい」は要望（主語=顧客、抽象度=高い）、「システムは認証済みユーザーがHTTPS経由でアクセスした場合、顧客マスタを応答3秒以内で返却する」は要件（主語=システム、検証可能）です。要望のままでは「ストレスなく使える」「リアルタイムで見える」のような曖昧表現が残り、テストできません。要件レベルまで具体化されて初めて、見積もり可能・実装可能・テスト可能になります。

要望を要件に変換する流れは「要求定義 → 要件定義」の連続した工程です。詳しくは要求定義と要件定義の違いと要件定義完全ガイドを参照してください。要望のたたき台にはユーザーストーリー作成ツールが使えます。

要求定義は「顧客がやりたいことを整理する工程」、要件定義は「システムが満たすべき条件に変換する工程」です。要求は願望、要件は契約に近い性質を持ちます。

違いは3点。(1) 主語: 要求は「顧客（ユーザー）」が主語、要件は「システム」が主語、(2) 抽象度: 要求はWhatレベル（「リアルタイムで売上が見えるようにしたい」）、要件はWhat & How to ensureレベル（「最終トランザクションから30秒以内に最新値を表示し、超えた場合は管理者にアラート」）、(3) 検証可能性: 要求は曖昧で検証不能、要件は数値や条件で検証可能。

標準的な進め方は、要求定義の成果物（要求リスト）を入力として、要件定義工程で検証可能な要件文に変換します。両者を混同したまま開発に進むと、後工程で「これは作る予定じゃなかった」「思っていたのと違う」というトラブルになりがちです。詳しくは要求定義と要件定義の違いを参照してください。

要件定義は「工程」というより「対話と合意形成のプロセス」です。Beekleでは中規模プロジェクトで次の5フェーズを使っています。

1. ステークホルダー特定とゴール定義: 誰が使うのか・誰が要件を承認するのか・達成すべき数値目標は何か。最初に呼ぶ人を誤ると終盤で「聞いていない」が発生する。
2. 業務フローの可視化（As-Is／To-Be）: 現状業務と理想業務の差分を絵にする。ここで現場の例外運用が見つかる。
3. 要求収集とユーザーストーリー化: 「誰が・何を・なぜ」の3要素で要望を1行に揃える。
4. 要件の整理と優先順位付け（FM法）: ビジネス価値・現場で使えるか・技術コストの3軸で「作る／後回し／作らない」を決める。
5. 要件定義書の作成とレビュー: ここまでのアウトプットをドキュメント化し、ステークホルダー全員でレビュー。

プロジェクト規模で配分は変わりますが、フェーズ1〜2（合意形成と現状把握）に最も時間を割くのがプロジェクト破綻を防ぐコツです。詳しくは要件定義の進め方｜実プロジェクト例で学ぶ5フェーズを参照してください。

Beekleが実際の発注プロジェクトで使っている要件定義書テンプレートを無料公開しています。Word／Markdown形式でダウンロードできます。

Beekleのテンプレートは次の8章構成です: (1) プロジェクト概要（目的・成功の定義・スコープ）、(2) 関係者（ステークホルダー一覧・意思決定者）、(3) ユーザーストーリー（ペルソナとストーリー一覧）、(4) 機能要件（EARS記法で記述）、(5) 非機能要件（性能・セキュリティ・運用）、(6) データ要件、(7) 制約事項、(8) リリース計画。膨大に見えますが、最初に書くべきは1〜4までの50%。残りはベンダーと一緒に詰めれば十分間に合います。

テンプレート本体と、EARS記法・ユーザーストーリーの実例集は要件定義書テンプレート＋EARS記法とユーザーストーリーの実例集からダウンロードできます。書き始めの3要素フォーマットだけ欲しい場合はユーザーストーリー作成ツールもお試しください。

「As a 〜（誰が）／I want to 〜（何を）／So that 〜（なぜ）」の3要素で1〜3行に書きます。日本語なら「〜として、〜したい。なぜなら〜」です。

例: 「店舗マネージャーとして、商品の在庫が閾値を下回った段階で通知を受けたい。なぜなら、発注リードタイム（3日）を確保するため、欠品の3日以上前に気づきたいから」。この3要素が揃うと、開発側は「なぜ」から技術選択肢を逆算できます（例: 通知タイミングが業務上シビアなら push 通知、緩いならメールで十分、など）。

「ユーザーとして〜」と書きそうになったら、もう一段階具体的にする（「店舗マネージャーとして」）のが基本です。役割が違えば求めるものも違うからです。テンプレートと業界別の実例はユーザーストーリー書き方完全ガイドを参照してください。3要素が揃わないストーリーをツール側で弾けるので、初めての方はユーザーストーリー作成ツールを使うとブレません。

EARS（Easy Approach to Requirements Syntax）は、要件を「どんな条件で・システムが・何をする」の決まったパターンで書くための構文です。曖昧さを排除した受入条件・非機能要件を書きたい場面で使います。

もともと航空・宇宙・自動車など安全性が重視される業界で広く採用された記法で、近年はソフトウェア開発でも受入条件・非機能要件の記述に使われています。日本語の自然文でありがちな主語の省略、条件と振る舞いの混在、可能性のある状態の見落としを防げます。

5つのパターンがあります: ユビキタス（常に成立）／イベント駆動（特定操作時）／状態駆動（特定状態の間）／オプション（特定条件時のみ）／望ましくない振る舞い（不正系の応答）。ユーザーストーリーで「なぜ」を共有し、EARSで「具体的な振る舞い」を曖昧さなく定義する組み合わせが、現代の要件記述のスタンダードになりつつあります。詳しくはEARS入門｜5パターンと書き方の実例を参照してください。

Gherkin は「業務担当者が読み書きできる自然言語のまま、そのままテストとして実行できる」要件記述形式です。受入テスト・回帰テストを仕様書と統合したい場面で使います。

「Given（前提）／When（操作）／Then（結果）」の3キーワードで業務シナリオを書き、Cucumber／Behave／Playwright BDD などのツールで自動実行できます。従来の課題（ユニットテストでは業務全体が見えない／Excel仕様書は実装と乖離する／口頭確認は再現性がない）を、仕様書とテストコードを1ファイルに統合することで解決します。

ビジネスサイドが書いたシナリオがそのままCIで自動実行され続けるリグレッションテストになるのが最大のメリットです。書き方の入門と実例はGherkin入門｜Given/When/Thenでシナリオテストを書く、ユーザーストーリーから受入条件まで繋げる流れはEARS×Gherkin｜要件定義からデモ／シナリオテストまでを生成AIで一直線につなぐを参照してください。

Beekleでは業務システム／受託開発の文脈ではFM法を主に使っています。要件発散後の最初の取捨選択で「使われない機能」「無謀な機能」を客観的に弾けるためです。アジャイルのスプリント計画にはMoSCoWが向きます。

MoSCoWは Must / Should / Could / Won't の4カテゴリに振り分ける手法。学習コストが低く、意思決定が速く、「Won't」を明示できるのが強みです。アジャイル開発のスプリント計画やリリース計画で広く使われています。

FM法は書籍『システムを作らせる技術』で紹介されている手法で、要件を「ビジネス価値・現場で使えるか・技術コスト」の3軸で評価し「作る／後回し／作らない」を判断します。MoSCoWより評価軸が多い分、運用負荷は高いですが、要件が大量に発散した状態から初期スコープを絞り込む工程に強い手法です。両者の比較と使い分けの詳細はMoSCoW vs FM法 完全比較を参照してください。

要件を「ビジネス価値（★1〜3）／現場で使えるか（★1〜3）／技術コスト（低・中・高）」の3軸で評価し、「作る／後回し／作らない」に振り分ける手法です。

判定の基本: (1) どれか1軸でも最低評価（★1 / 技術コスト=高）なら作らない（使われない or 無謀）、(2) 高評価が2つ以上あれば作る、(3) その他は後回し。「3軸とも高い」要件だけ最初に作り、それ以外を引き算する考え方です。

FM法の最大の効果は「使われない機能」「無謀な機能」を客観基準で弾けること。実調査でも開発した機能の8割は使われていないと言われており、ここを切るだけで予算と納期は大きく改善します。Beekleでは無料のスコープ管理ツールでこの判定を半自動化しています。手法の詳細はスコープ管理「FM法」の使い方を参照してください。

Beekleは「発注側がWBSを引く」「フロー図を維持し続ける」の2つはやらなくていいと考えています。それよりスコープ管理と意思決定に集中するほうが、プロジェクトの成功率が上がります。

発注側が引いたWBSは、現場のリアルとズレた「希望的観測のスケジュール」になりがちです。データ調査・外部API仕様確認・既存システム整合性チェックなど、実装より準備に時間がかかる作業は外からは見えません。発注側が引いたWBSは「なんで遅れてるの？」と詰める材料にしかならず、結果として「順調です」の虚偽報告の温床になります。

フロー図も、一度は作るべきですが「最新に維持し続ける」のは現実的ではありません。代わりにストック情報として「ユーザーストーリー」「シナリオ」を握るのが発注側の正しい仕事です。スケジュールの粒度ではなく「機能の取捨選択」と「決断のスピード」で貢献するのが筋。詳しくは発注側がやらなくていい2つのことを参照してください。

「丸投げ」は失敗の元です。発注側は要件定義の意思決定者として深く関わる必要があります。ただし、関わり方は「文書化」よりも「合意形成と決断」です。

発注側がやるべきは: (1) ステークホルダー特定（誰が承認者か）、(2) ビジネスゴール（何が達成できれば成功か）を言葉にすること、(3) 業務フロー（As-Is）の整理と現場担当者への巻き込み、(4) 要望リストの優先順位付けと「作らない」決断、(5) ユーザーストーリーやシナリオでの「なぜ」の共有。一方、システム要件（システム構成・画面設計・データモデル）は開発側の専門領域です。

「ITのことはよくわからないからお任せ」だと、現場の業務フローと噛み合わないシステムができあがり、最終的に多額の投資が無駄になります。発注側のプロジェクト管理の全体像はシステム開発の進め方 完全ガイド、要件定義の責任分担は要件定義完全ガイドを参照してください。

「ユーザーストーリーで Why、EARS で What、Gherkin で How to test」の役割分担で組み合わせます。順に上流から下流へ要件を変換していくパイプラインです。

具体的には: (1) ユーザーストーリーで「誰が・何を・なぜ」の3要素を1行に揃える（Why の共有）、(2) EARS記法で受入条件と非機能要件を「どんな条件で・システムが・何をする」の構文で書く（What の確定）、(3) Gherkin（Given/When/Then）でシナリオテストを書き、デモ・受入テスト・自動テストを1本化する（How to test の固定）。

この流れに乗せると、要件・受入条件・テストが一貫したストック情報として残り、生成AIの「最初の8割を高速に書く」能力もそのまま受け止められます。具体的なつなぎ方はEARS×Gherkin｜要件定義からデモ／シナリオテストまでを生成AIで一直線につなぐを参照してください。

業務フローの全体像・ステークホルダーの関係性・現行システムの課題、の3点をまず見ます。「今どう動いているか」を絵にしないと、改善後（To-Be）の姿が描けません。

進め方は: (1) 業務フローの可視化: 誰が・何を・どのツールで・どれくらい時間をかけてやっているかをスイムレーン図などで描く、(2) ステークホルダーへのヒアリング: 経営・情シス・現場担当者・エンドユーザーそれぞれの立場で課題を聞く、(3) 課題の整理と優先順位付け: 出てきた課題に「ビジネスインパクト × 解決容易性」で優先度をつける。

ここで落ちやすいのが「例外運用」です。標準の業務フローには載っていない「実はこの場合だけ別の人が手動でやっている」が、後で要件の抜けとして顕在化します。As-Is を素早く図にするなら無料の業務フロー可視化ツール、現状分析の詳しい進め方はシステム開発の現状分析を参照してください。

言葉と静止画だけで合意を済ませず、できるだけ早い段階で「動くもの」を触ってもらうことです。「人間は動くものを触ってみるまで、自分が何を欲しかったのか分からない」という認知特性が原因なので、これを構造的に解決します。

3ステップで防げます。(1) 動くプロトタイプの早期作成: 静止画ではなくクリックできる試作品を最初に作り、現場で触ってもらう、(2) 1〜2週間ごとの週次デモ: 完成直前ではなく途中の節目ごとに動くものを見せ、フィードバックを集める、(3) 段階的な機能追加（MVP→拡張）: 一度に全機能を作らず、コア機能から順に積み上げる。

言葉だけの合意では「使いやすい画面」「直感的な操作」の解釈が人によって違うため、必ずどこかでズレが生じます。静止画でも「なんとなく良さそう」までしか分かりません。詳しくは「思ったのと違う」を防ぐ3ステップを参照してください。

規模によりますが、Beekleの目安では中規模Webシステム（開発費1,000〜3,000万円程度）で全体工数の10〜15%、期間にして1〜2ヶ月を要件定義に充てます。

システム開発費用の内訳でも「要件定義 10〜15%」が標準的な比率です。極端に短い見積もり（要件定義 5%以下）は、後工程の手戻りで結局工数が膨らむ典型パターン。一方で「要件定義に半年」のような長期化も、現場担当者の温度感が下がってプロジェクトが頓挫する原因になります。

進め方の現実解は、5フェーズに分けてフェーズ1〜2（ステークホルダー特定と業務フロー可視化）に最も時間を割くこと。ここで合意形成が崩れると、後のフェーズで何度書き直しても整合しません。詳しい目安は要件定義の進め方｜実プロジェクト例で学ぶ5フェーズとシステム開発費用の内訳完全ガイドを参照してください。

「誰がこのシステムを使うのか」「誰が要件を承認するのか」「達成すべき数値目標は何か」の3点を、要件定義の最初に整理することからはじめます。

具体的なアウトプットは「ステークホルダー一覧表」。役割（プロジェクトオーナー・業務責任者・現場担当者・情シス・経営層など）／氏名／関与レベル（決裁／承認／レビュー／情報共有）／期待アウトカムの4列で書き出します。よくある失敗は「経理部長は途中から呼べばいい」と判断して終盤で「経理処理の要件が抜けている」と発覚し、再見積もりが発生するパターン。最初に呼ぶ人を誤ると、後工程で必ず手戻りが起きます。

意思決定者と決裁ラインの整理が遅れると、開発が始まってから「この仕様は誰がOKを出すのか」で詰まり、進捗が止まります。ステークホルダーを意思決定メンバーに入れる進め方の詳細は要件定義の進め方とDX・システム開発で失敗する典型5パターンを参照してください。

二者択一ではありません。現状分析や要件ヒアリングでは時間をかけて丁寧に固め、開発フェーズに入ってからは短い周期で動くものを見せながら軌道修正するハイブリッドな進め方が現実的です。「最初から完璧に決められる」という前提のウォーターフォールも、「決めずに走り出す」アジャイルも、極端に振ると失敗します。

プロトタイプの作成スピードが劇的に上がりました。以前は数週間かかった初期画面が数日で形になることもあります。その結果、完璧な計画書を作ってから着手するよりも、早期に動くものを現場に持ち込んでフィードバックを回す進め方が主流になりつつあります。「計画の精度」よりも「検証の速度」が重要になっています。

ベンダーは技術のプロですが、あなたの会社のビジネスや現場業務のプロではありません。丸投げすると、技術的には正しくても現場の業務に合わないシステムができあがります。要件定義には発注側の関与が欠かせません。少なくとも「誰が・何のために・どんな状況で使うか」は発注側が言葉にする必要があります。