要件定義で必要な5つのステップ
機能一覧から始めず、現場業務とデータの流れから要件を組み立てる
Copyright © 2026 LWP 山中 一弘
本資料は、出典を明記いただければ、商用・非商用を問わず、ご自由に複製・改変・再配布していただけます。なお、著作権表示は改変せず、そのまま記載してご利用くださいますようお願いいたします。
記事要約
要件定義というと、機能一覧、画面一覧、帳票一覧、テーブル定義を作る作業だと思われがちです。しかし、現場業務を十分に理解しないままそれらを作ると、システムとしては作れても、業務として回らないものになる危険があります。
要件定義で最初に見るべきものは、機能ではなく業務です。誰が、いつ、何を見て、何を判断し、どのデータを次の担当者やシステムへ渡しているのかを復元する必要があります。
この記事では、要件定義を5つのステップに分けて整理します。現場業務の把握、全体概要と業務フロー、データフローと業務ルール、正本データとあるべき業務、最後に機能・画面・帳票・運用へ落とし込むという順番です。
本記事の対象とゴール
想定読者
業務システム、業務マクロ、Excel業務改善の要件定義を担当する人
顧客や現場担当者から要望を聞き、仕様へ整理する立場の人
機能一覧や画面一覧から要件定義を始めてよいのか迷っている人
現行業務の手作業や例外処理を、どこまで要件として扱うべきか判断したい人
本記事で得られること
要件定義をどの順番で進めるべきかが分かります。
現場業務、業務フロー、データフロー、正本データ、機能定義の関係が整理できます。
手作業や例外処理を安易に削らず、業務上の意味を確認する判断軸が得られます。
顧客や現場担当者へ、抽象的な専門用語を使わずに確認事項を伝えやすくなります。
本記事で扱わないこと
個別システムの詳細な画面設計
データベースの物理設計や具体的なSQL設計
特定業界の制度要件、法令要件、会計基準の詳細
要件定義書テンプレートの全項目解説
先に結論
要件定義は、機能一覧を作る作業から始めるものではありません。
最初に行うべきことは、現場に分散している業務を集め直し、誰が何をしているのか、どのデータがどこから来てどこへ渡るのか、どの判断や例外処理が業務を支えているのかを整理することです。
そのうえで、どのデータを正本とするか、何を残し、何を自動化し、何を別の処理主体へ移すかを決めます。機能、画面、帳票、権限、運用は、その後に導かれるものです。
第1章 現場業務を把握する
要件定義の第一歩は、現場で実際に行われている業務を理解することです。
1.1 機能ではなく業務から見る
業務システムを作る話になると、すぐに「どんな機能が必要か」「どんな画面が必要か」という話に進みがちです。しかし、その前に確認すべきなのは、現場で何が起きているかです。
多くの業務は、一人の担当者や一つの部署だけで完結していません。営業、現場担当、管理部門、経理、システム担当、外部取引先、Excel、帳票、メール、共有フォルダ、基幹システムなどに分散しています。
そのため、要件定義では、まず分散している業務を集め直し、全体として何が行われているのかを復元します。
1.2 確認すべきこと
現場業務を把握するときは、少なくとも次を確認します。
誰が、いつ、何をしているか
どの部署、担当者、システム、Excel、帳票が関係しているか
どのデータを見て、何を判断しているか
どこで入力、確認、修正、承認、出力が行われているか
どこに手作業、例外処理、現場の工夫があるか
なぜその作業が残っているのか
ここで重要なのは、手作業や例外処理を最初から無駄と決めつけないことです。
一見非効率に見える作業にも、過去のトラブル防止、責任分界、証跡確保、取引先都合、締め処理、既存システムの制約などの理由が隠れていることがあります。
1.3 現物を確認する
要件定義では、聞き取りだけでなく現物確認が必要です。
現場で使われているExcel、CSV、帳票、メール、手順書、出力結果、共有フォルダ、基幹システムの画面を確認します。現物を見ることで、口頭説明だけでは出てこない判断条件、例外、手修正、運用上の工夫が見えてきます。
現行業務を理解しないまま不要な作業として削ると、業務上必要な安全装置を壊す危険があります。
第2章 全体概要と業務フローを整理する
現場業務を把握したら、次に業務全体の構造を見える形にします。
2.1 全体概要図で関係者と道具を置く
全体概要図では、関係する部署、人、システム、Excel、帳票、外部サービス、データベースなどを一枚の地図として整理します。
業務は抽象的に存在しているのではありません。必ず特定の部署、人、システム、ファイル、帳票に結びついています。どの場所でどの業務が行われているのかを置いていくことで、業務の全体像が見えます。
2.2 業務フローで処理主体を明らかにする
業務フローでは、作業の順番だけでなく、処理主体を明らかにします。
確認すべきことは次のとおりです。
業務に関係する処理主体は何か
どの部署や担当者が、どの作業を担っているか
どのシステム、Excel、帳票、ファイルが使われているか
作業はどの順番で進むか
どこで判断、確認、承認、差し戻しが発生するか
外部との接点はどこか
業務の開始点と終了点はどこか
業務フローは、単なる手順一覧ではありません。誰が処理主体なのか、どこで判断が入るのか、どのタイミングで次の処理主体へ渡るのかを明らかにするためのものです。
2.3 局所最適を避ける
全体概要と業務フローがないまま要件を作ると、ある部署だけに都合のよい局所最適なシステムになりやすくなります。
たとえば、入力担当者にとって楽な画面でも、確認担当者に必要な情報が欠けていれば、後工程で手戻りが発生します。逆に、管理者に便利な集計でも、現場入力の負荷が高すぎれば運用が続きません。
要件定義では、処理主体ごとの都合をつなぎ、業務全体として成立する形を探す必要があります。
第3章 データフローと業務ルールを明らかにする
業務フローだけでは、業務の本質は十分に見えません。
3.1 業務はデータが変化する流れでもある
業務フローは、誰が何をするかを整理するには有効です。しかし、データがどこから来て、どこで加工され、何に変わり、どこへ渡るかは見えにくい場合があります。
業務とは、人が作業することだけではありません。入力されたデータが、処理主体によって判断、加工、確認され、次のデータ、帳票、記録に変わっていく流れでもあります。
そのため、要件定義では業務フローとあわせてデータフローを整理します。
3.2 データフローで確認すること
データフローでは、次を確認します。
どのデータが入力されるか
入力データは、どの処理主体に渡るか
どこで確認、補正、集計、変換されるか
変換後に、どのデータ、帳票、ファイル、仕訳、レポートになるか
どのデータが次工程の根拠になるか
どのデータが一時データで、どのデータが正式な記録なのか
どのデータが証跡として保存されるべきか
ここまで整理すると、単なる作業手順ではなく、業務が何を根拠に進んでいるのかが見えるようになります。
3.3 業務ルールを拾い上げる
データフローを追うと、業務ルールが見えてきます。
たとえば、処理対象になる条件、除外される条件、参照するマスタ、優先する値、確定するタイミング、締め後の修正方法、例外時の判断者などです。
これらは、画面項目や機能名だけを見ていても拾えません。現場の制約、工夫、例外処理の中に隠れています。
一見無駄に見える作業であっても、監査証跡、責任分界、取引先対応、過去トラブルの防止、マスタ不備の補完などの意味を持つ場合があります。要件定義では、こうした現場の工夫を隠れた要件として扱います。
第4章 正本データ・あるべき業務・データ構造を決める
現行業務、業務フロー、データフロー、業務ルールが見えてきたら、次にあるべき業務を定義します。
4.1 BeforeとAfterを単純に並べない
よくある誤りは、現状を十分に分解しないまま「現状は手作業、今後はシステム化」「現状はExcel、今後はデータベース化」と単純化することです。
しかし、本来のAfterは、Beforeを分解したうえで再構成するものです。
現行業務のうち何を残すか、何を自動化するか、何を廃止するか、何を別の処理主体に移すかを判断します。さらに、どの判断をシステム化し、どの判断を人間に残し、どのチェックを必須にし、どの例外処理を運用で扱うかを決めます。
4.2 正本データを決める
特に重要なのが、正本データの決定です。
業務では、同じようなデータが複数の場所に存在することがあります。Excel、CSV、基幹システム、会計システム、メール添付ファイル、帳票、手修正後のファイルなどです。
どのデータが正式な記録なのかを決めないままシステム化すると、後で必ず不整合が起きます。
正本データを決めるときは、次を確認します。
どのデータを正本とするか
どのデータは一時データか
どのデータは再生成可能か
どのデータは証跡として保存するか
誰が入力責任を持つか
誰が確認責任を持つか
誰が修正できるか
締め後に変更できるか
変更履歴を残すか
4.3 データ構造は結果として出てくる
テーブル定義は、最初に作るものではありません。
業務イベント、データフロー、正本データ、業務ルールを整理した結果として、必要なデータ構造が見えてきます。マスタ、トランザクション、履歴、集計、帳票出力、証跡データは、この段階で整理します。
データ構造を先に決めると、現場の責任分界や例外処理が抜け落ちることがあります。業務からデータへ進む順番を守ることが重要です。
第5章 機能・画面・帳票・運用に落とし込む
最後に、整理した業務とデータを、システム要件として具体化します。
5.1 機能は業務とデータから導く
入力、取込、検索、更新、チェック、承認、集計、出力、連携、権限管理などの機能は、単独で存在するものではありません。
業務フローとデータフローの中で必要だから存在します。
たとえば、入力機能は、誰がどのデータを責任を持って登録するのかが決まって初めて意味を持ちます。承認機能は、どの判断を誰が確定するのかが決まって初めて設計できます。出力機能は、どの時点のどのデータを、誰または何に渡すのかが決まって初めて定義できます。
5.2 画面・帳票・権限・運用の位置づけ
画面は、業務そのものではありません。業務とデータに対する操作インターフェースです。
帳票も、単なる印刷物ではありません。ある時点のデータを、人間や外部に渡すための表現形式です。
権限は、処理主体と責任分界の表現です。
運用は、例外処理、締め処理、修正、障害対応、手戻り対応を成立させるための仕組みです。
この位置づけを間違えると、画面や帳票を作っているのに、業務が回らないという状態になります。
5.3 機能一覧から始めない
機能一覧や画面一覧から要件定義を始めると、見た目には仕様が進んでいるように見えます。しかし、業務とデータの根拠がない機能は、後から説明できなくなります。
要件定義では、現場業務、業務フロー、データフロー、正本データ、あるべき業務を整理した後で、それらを機能、画面、帳票、権限、運用、非機能へ落とし込みます。
第6章 実務では言い換えて進める
この進め方は正攻法ですが、現場では重く見えることがあります。
6.1 専門用語をそのまま出さない
顧客や現場担当者に、いきなり「DFDを作ります」「ERを整理します」と言うと、抽象的に聞こえたり、負担が大きく感じられたりします。
実務では、次のように言い換えると通りやすくなります。
どのデータが、どこから来て、どこに渡るかを確認します。
関係する部署、ファイル、システム、帳票を一枚にまとめます。
誰が、いつ、何を確認して、次に何を渡しているかを整理します。
手作業が残っている理由を確認します。
どのデータを正とするかを決めます。
専門用語を避けることは、内容を薄めることではありません。相手が確認しやすい言葉に置き換えることで、要件定義の精度は上がります。
6.2 要件定義は要望集めではない
要件定義とは、単に要望を集める作業ではありません。
現場に分散している業務を復元し、処理主体、業務フロー、データフロー、業務ルール、正本データを整理したうえで、あるべき業務を機能、画面、帳票、運用へ落とし込む作業です。
要望は重要です。しかし、要望だけでは業務は設計できません。要望の背景にある業務、データ、責任、制約を確認して初めて、システムとして実装できる要件になります。
まとめ
要件定義で必要な流れは、次の5ステップです。
現場業務を把握する。
全体概要と業務フローを整理する。
データフローと業務ルールを明らかにする。
正本データ、あるべき業務、データ構造を決める。
機能、画面、帳票、運用に落とし込む。
この順番を守る理由は、要件定義の目的が機能を並べることではなく、業務として成立する仕組みを定義することだからです。
現場業務を見ずに機能へ進むと、作れるが使えないシステムになります。業務フローだけでデータを見ないと、処理の根拠が抜けます。正本データを決めないまま設計すると、不整合が残ります。
要件定義は、現場に散らばっている業務とデータを集め直し、あるべき業務へ組み直す作業です。その結果として、機能、画面、帳票、権限、運用が決まります。
出典メモ
元原稿: C:\Users\hoehoe\Downloads\requirements_definition_steps.md
記事化日: 2026-06-11
原稿種別: ユーザー所有Markdown原稿
編集方針: 原稿の5ステップ構成と主張を保持し、LWP公開記事標準の冒頭構成、著作権表示、対象とゴール、先に結論、章立てを補った。