業務システムの要件定義で、最初の打ち合わせが「どんな画面が必要ですか」から始まることがあります。 画面の話は入りやすいです。 利用者も説明しやすく、開発側もイメージを持ちやすい。
ただ、画面だけを聞いていると、あとで帳票とデータで止まります。 請求書の金額が合わない。 検索結果には出ているのにCSVには出ない。 マスタが無効になったときの扱いが決まっていない。 このあたりは、開発後半や受入テストで顔を出すと面倒です。
要件定義の最初は、画面、帳票、データを別々に聞かず、同じ業務の流れに並べて確認します。画面で入力したものが、どのデータになり、どの帳票やCSVに出るかを早めに見ます。
この記事では、受注業務を例にします。 受注検索画面、請求書、顧客マスタ、商品マスタ、受注明細を題材にして、最初に何を聞くか、どう残すかを整理します。
最初に見る対象を画面・帳票・データに分ける
画面だけ聞くと処理の入口しか分からない
要件定義の初回ヒアリングでは、画面の話が先に出やすいです。 「受注を検索したい」「一覧から詳細を開きたい」「CSVを出したい」。 ここまでは話しやすいし、画面イメージも作れます。
でも、画面は業務の入口か途中です。 入力した値がどのテーブルに残るのか。 どの帳票に出るのか。 誰が修正できるのか。 締め後に変えてよいのか。 ここを聞かないまま進めると、画面はできても業務が通りません。
tomo画面の項目名が決まっただけで安心すると、あとで「この項目は請求書にも必要でした」と戻ってきます。画面の見た目だけでは、業務の最後まで追えません。
実務では、画面項目は決まっているのに帳票の出力条件が未決、という状態がよくあります。 たとえば、受注検索画面に「値引額」があり、詳細画面にも表示される。 ところが請求書では、値引前の金額を出すのか、値引後の金額を出すのか、税額にどう反映するのかが決まっていない。 この状態で実装に入ると、請求書テストの段階で金額差異の調査になります。
画面項目が決まっていても、帳票とデータの扱いが未決なら仕様は固まっていません
帳票とデータまで並べると確認漏れが見える
最初の確認では、画面、帳票、データを1枚に並べます。 細かい設計書にする必要はありません。 まずは、どの業務で、どの画面を使い、どのデータを登録し、どの帳票やCSVに出るのかを横に置きます。
| 業務 | 画面 | データ | 帳票・出力 | 最初に聞くこと |
|---|---|---|---|---|
| 受注登録 | 受注入力画面 | 受注ヘッダ、受注明細 | 受注確認書、CSV | 誰が登録し、いつ修正できるか |
| 請求処理 | 請求対象検索画面 | 請求データ、顧客マスタ | 請求書、請求一覧CSV | 締め日、再発行、取消の扱い |
| マスタ管理 | 顧客マスタ画面 | 顧客マスタ | 宛名、送付先、取引先一覧 | 無効化した顧客を過去帳票に出すか |
この表を置くだけで、聞くべき相手も変わります。 画面操作は現場担当者に聞けます。 帳票の締めや再発行は経理や管理担当者が知っていることがあります。 データの持ち方や連携元は、既存システムの保守担当に聞かないと分からないこともあります。
要件定義で怖いのは、誰も悪気なく抜けることです。 「それは当然そうだと思っていた」が一番やっかいです。 だから最初に、画面、帳票、データを分けて見える場所へ置きます。
画面で確認する入力・検索・権限
入力項目は必須と初期値だけでは足りない
入力画面で最初に聞くのは、必須か任意か、初期値は何か、だけでは足りません。 業務システムでは、入力できる人、変更できるタイミング、エラー時の戻し方まで確認します。
受注入力画面なら、たとえば次を見ます。
| 確認項目 | 聞く内容 | 漏れたときに起きること |
|---|---|---|
| 入力形式 | 日付、金額、コード、桁数、空欄可否 | テスト時に想定外の入力で止まる |
| 初期値 | ログイン部署、当日、前回値、固定値 | 利用者ごとの初期表示が合わない |
| 変更可否 | 登録後、承認後、締め後に直せるか | 修正できてはいけないデータが変わる |
| 入力補助 | マスタ検索、候補表示、自動計算 | 入力者が毎回手で調べる |
| エラー表示 | どのタイミングで、どの文言を出すか | 原因が分からず問い合わせが増える |
「必須です」「任意です」だけでは、入力仕様としては薄いです。 たとえば顧客コードが任意でも、請求書を出すときには必須になるかもしれません。 登録時は空欄でよくても、承認時には埋める必要があるかもしれません。
入力項目は、登録時点だけでなく、後続処理で必要になるタイミングまで見ます。
検索画面は条件保持と件数上限を見る
検索画面では、検索条件の種類だけで終わらせない方がよいです。 業務でよく揉めるのは、条件保持、並び順、件数上限、CSV出力、権限差です。
受注検索画面なら、検索条件として受注日、顧客、担当者、ステータスを置きます。 ここまでは普通です。 その次に、画面を戻ったときに条件を残すのか、初期化するのかを聞きます。 一覧の初期並び順は受注日の降順なのか、登録順なのか。 検索結果が5万件になったとき、画面に出すのか、エラーにするのか、CSVだけ許すのか。
tomo検索画面は、項目数より運用時の使われ方を見ます。毎日使う画面ほど、条件保持や初期表示の小さな違いがストレスになります。
権限差も早めに聞きます。 営業担当は自分の受注だけ見える。 管理者は全件見える。 経理は請求対象だけ見える。 このような差があるなら、検索条件、一覧項目、CSV出力の列も変わることがあります。
画面で見えないデータがCSVには出る、という仕様は情報漏えいの入口になります 権限は画面表示だけでなく、出力と帳票にもかけて確認します。
帳票で確認する出力条件・集計・締め処理
帳票は見た目より先に出力タイミングを見る
帳票の確認では、レイアウトから入りたくなります。 もちろん、ロゴ、宛名、明細、合計欄、押印欄は必要です。 ただ、最初に聞くべきなのは、いつ、誰が、どの条件で出すかです。
請求書なら、月締め後にまとめて出すのか、都度発行するのか。 再発行はできるのか。 取消した受注は載せるのか。 締め後に顧客名が変わった場合、当時の名称で出すのか、現在のマスタ名で出すのか。
このあたりは、帳票レイアウトだけ見ても出ません。 帳票の項目欄に「顧客名」と書いてあっても、その顧客名が請求時点の値なのか、出力時点のマスタ値なのかで実装は変わります。 後から変えると、テーブル設計や履歴の持ち方に響きます。
帳票は、見た目の確認と同じくらい、出力タイミングの確認が効きます。締め、再発行、取消、履歴の扱いを先に聞くと、データの持ち方も決めやすくなります。
金額や件数はどの明細から集計するかを見る
請求書や集計表では、金額と件数の確認を甘く見ると後で調査になります。 受注明細から集計するのか、請求確定データから集計するのか。 返品、値引き、取消、無効明細を含めるのか。 消費税の丸めは明細単位か、請求書単位か。
金額差異の問い合わせは、たいてい説明が重くなります。 「画面では124,800円なのに、請求書では125,000円です」と言われたとき、丸め、税率、値引き、取消、締めタイミングを順番に追うことになります。 要件定義で決めていない場合、正しい金額がどちらなのかをその場で決めるところから始まります。
| 帳票項目 | 確認すること | メモに残す粒度 |
|---|---|---|
| 小計 | 値引前か値引後か | 受注明細の値引後金額を合計 |
| 消費税 | 明細単位か伝票単位か | 請求書単位で端数処理 |
| 件数 | 取消明細を含むか | 取消ステータスは件数から除外 |
| 顧客名 | 履歴値か現マスタ値か | 請求確定時の顧客名を保持 |
金額や件数は、どのデータを、どの条件で、どの単位で集計するかまで残します。 「合計金額を出す」だけでは、実装にもテストにも使いにくいです。
データで確認するマスタ・明細・連携元
マスタは存在チェックと履歴を見る
業務システムでは、マスタが正しい前提で話が進みがちです。 顧客マスタ、商品マスタ、部署マスタ、担当者マスタ。 名前だけ聞くと簡単そうですが、実際には無効、履歴、統合、コード変更があります。
顧客マスタなら、確認するのは現在の顧客名だけではありません。 過去の請求書には当時の名称を出すのか。 無効顧客は検索に出すのか。 統合された顧客コードは旧コードで検索できるのか。 新規登録時に同名顧客を警告するのか。
マスタを現在値だけで見ると、過去帳票や締め済みデータでズレます。履歴を持つのか、確定時に値をコピーするのか、参照時に最新マスタを見るのかを分けて確認します。
実務では、テストデータを作る段階でマスタ問題が出ることがあります。 画面に顧客コードを入れたら存在しない。 存在するけど無効。 商品コードはあるが販売終了。 この状態でテストを進めると、画面仕様の問題なのか、テストデータの問題なのか、切り分けに時間を使います。
だから要件定義の時点で、マスタの状態を確認対象に入れます。 「存在するか」だけでなく、「使ってよい状態か」まで見ます。
明細データは登録・更新・削除のタイミングを見る
明細データでは、いつ作られ、いつ変わり、いつ消えるのかを聞きます。 受注明細なら、受注登録時に作られる。 承認後に変更できるのか。 出荷後に数量を変えられるのか。 取消したときに物理削除するのか、取消ステータスで残すのか。
ここを決めていないと、帳票と検索結果が合わなくなります。 検索画面では取消明細を除外しているのに、集計では含めている。 CSVでは物理削除済みの明細が出ないが、監査用には必要だった。 こういう差は、要件定義で言葉にしていないと、後で発覚します。
tomo削除という言葉は特に危ないです。画面から消すだけなのか、DBから消すのか、履歴として残すのかで、後続処理への影響が変わります。
明細の確認では、正常な登録だけでなく、修正と取消を横に置きます。 それだけで、帳票、CSV、集計、監査ログの確認漏れが減ります。
聞き漏れを減らすヒアリング表
質問は業務の流れ順に並べる
ヒアリング表は、画面単位だけで作ると抜けます。 業務担当者は、画面名より作業の流れで話すことが多いからです。 受付、登録、確認、承認、出力、修正、締め。 この順番に並べると、例外処理も聞きやすくなります。
| 業務の流れ | 聞くこと | 確認対象 | 未決なら残すこと |
|---|---|---|---|
| 受付 | 誰が、どの情報を受け取るか | 入力元、添付資料、メール | 入力元の責任者 |
| 登録 | 必須項目と自動設定値 | 入力画面、マスタ | 入力できないケース |
| 確認 | 誰が何を見てOKにするか | 一覧画面、詳細画面 | 確認者と確認条件 |
| 承認 | 差戻しと代理承認の有無 | 承認画面、通知 | 期限超過時の扱い |
| 出力 | 帳票、CSV、連携のタイミング | 請求書、CSV、API | 再発行と取消時の扱い |
| 締め | 締め後に何を変えられるか | 請求データ、会計連携 | 解除できる権限 |
この表は、そのまま議事録にしてもよいです。 きれいな資料にする前に、会議中に埋める方が役に立ちます。 その場で空欄が見えると、誰に確認するかを決めやすいからです。
ヒアリング表は、完成した資料ではなく、未決を見つける道具として使います。
回答が曖昧な項目は未決のまま残す
要件定義で一番避けたいのは、曖昧な回答を決まったことにしてしまうことです。 「たぶん経理が見ると思います」 「締め後は基本的に直さないはずです」 「CSVは今と同じで大丈夫です」 このまま仕様に入れると、あとで確認し直す場所が分かりません。
未決は未決として残します。 担当者、確認先、期限、影響範囲を一緒に書きます。
未決事項: 締め後に請求先住所を変更できるか
確認先: 経理チーム 山田さん
期限: 7月31日
影響: 請求書再発行、顧客マスタ履歴、権限設定
暫定方針: 締め後は請求書の住所を変更しない前提で見積もるこうしておくと、次の打ち合わせで確認できます。 未決を隠して進めるより、見える場所に置く方がずっとましです。 要件定義は、最初から全部を決める作業ではありません。 決まっていないことを、決まっていないまま管理する作業でもあります。
仕様として残すときの形
画面・帳票・データの対応を1行で残す
確認した内容は、画面仕様、帳票仕様、データ項目定義に分けて書くことがあります。 ただ、分けた瞬間に対応関係が見えにくくなります。 最初の段階では、1行で対応を残す表を作ると後で助かります。
| 業務項目 | 画面項目 | データ項目 | 帳票・出力項目 | 確認メモ |
|---|---|---|---|---|
| 顧客名 | 受注入力 顧客名 | customer_name | 請求書 宛名 | 請求確定時の名称を保持 |
| 値引額 | 受注明細 値引額 | discount_amount | 請求書 明細金額 | 値引後金額を税計算対象にする |
| 出荷数量 | 出荷入力 数量 | shipped_quantity | 出荷一覧CSV | 取消明細は出力しない |
この表は、詳細設計の代わりではありません。 でも、仕様確認の初期段階では使いどころがあります。 画面だけ、帳票だけ、DBだけを見ていると分からないズレが見えるからです。
tomo1行でつながっていると、レビューで指摘しやすくなります。「この画面項目は請求書に出ますか」と聞けるだけで、確認の質が変わります。
例外処理は正常系の横に置く
例外処理は、最後にまとめて聞くと漏れます。 正常系の横に置いた方が拾いやすいです。 受注登録の横に取消を置く。 請求書発行の横に再発行を置く。 承認の横に差戻しと代理承認を置く。
たとえば、請求書発行なら次のように残します。
正常系: 月末締め後、経理担当が請求書を一括発行する
例外1: 請求書発行後に顧客住所が誤っていた場合、再発行する
例外2: 締め後に受注取消が発生した場合、翌月で調整する
例外3: 顧客マスタが無効の場合、請求対象から除外する
確認中: 再発行時に請求書番号を変えるかこのくらいのメモでも、後工程では助かります。 正常系だけの仕様書は読みやすいですが、テストではすぐ足りなくなります。 例外処理は、別紙に追いやるより正常系の横に置いた方が実装とテストに届きます
最後に確認相手と証跡を残す
要件定義のメモには、内容だけでなく、誰に確認したかを残します。 確認日、確認相手、未決事項、暫定方針。 これがないと、数週間後に同じ話をもう一度します。
確認日: 2026-07-30
確認相手: 経理チーム 山田さん、営業管理 佐藤さん
対象業務: 請求書発行
決定事項: 請求書の顧客名は請求確定時点の名称を保持する
未決事項: 再発行時に請求書番号を変えるか
次回確認: 2026-08-02 経理チーム定例この粒度で残しておくと、仕様変更の話になったときも戻れます。 「誰がそう言ったか」を責めるためではありません。 当時、どの前提で決めたかを確認するためです。
要件定義で最初に見るのは、きれいな資料ではありません。 画面、帳票、データが業務の中でどうつながるかです。 そのつながりを表にして、未決を隠さず、確認相手と日付を残す。 この地味な作業を先にやっておくと、実装とテストで余計な調査が減ります。
