「この帳票がほしい」と言われたら、何を聞く？発注前の帳票要件整理

帳票の要件とは、何を決めること？

ここでいう帳票は、業務の記録を、仕事で確認したり判断したりできる形にまとめた表示です。紙に印刷する一覧だけを指すのではなく、画面で見る一覧なども含めて考えます。ただし、この記事の例で印刷・出力形式を決定したわけではありません。実際にどう見るかは利用者へ確認します。

要件は、見た目の希望だけでなく「誰のどんな仕事に使えればよいか」と、そのための条件です。受付番号などの欄が表示されても、確認したい依頼が対象から漏れていたり、見てはいけない範囲まで表示されたりすれば、依頼された仕事を満たせません。

発注前には、業務担当が使い方と値の意味を説明し、IT発注担当が元記録や未決事項との対応を整理します。システムの提供会社には、その条件を実現できるか、どのデータや設計が必要かを確認します。業務の意味が不明なまま、開発担当に抽出条件を推測してもらう形にはしません。

Microsoft LearnのPower BI移行ガイドも、個々の帳票の目的、見る人、その人に期待する行動、元データ、鮮度、閲覧範囲などを要件として確認する観点を挙げています。本稿はこれを質問の参考にします。資料の対象はPower BIへの個別の移行で、標準導入にも参考になるという範囲です。Power BIの採用や、この書き方を全企業に義務付ける根拠ではありません。Microsoft公式：帳票の要件を集める観点。

最初は「誰が、次に何をするか」を聞く

最初からすべての欄や条件を聞き切ろうとせず、依頼者が帳票を開く一場面を説明してもらいます。修理依頼の例なら、「未完了を見たい」という言葉を、その後の仕事につながる説明へほどきます。

1. 見る人を聞く。「この帳票を見て仕事をするのは誰ですか」。作る人や依頼した人と、実際に見る人が同じとは限りません。この例で示されている利用者は業務担当です。
2. 見つけたいものを聞く。「一覧から、どんな依頼を見つけたいですか」。最初の目的は、修理依頼のうち担当の確認が必要なものを見つけることです。「未完了」という呼び方だけで対象を確定しません。
3. 見つけた後の行動を聞く。「その依頼が見つかったら、何を確かめますか」。最初の例では、対象依頼の担当と処理状況を確かめます。帳票を眺めて終わる仕事ではありません。
4. 使う元記録を聞く。「その依頼を、どの受付記録と照らしますか」。記録の管理担当にも確認し、利用者が呼ぶ名前と、発注先が参照するデータを対応させます。

この順に聞くと、「担当者を表示したい」は、担当へ状況を聞くために必要な欄の候補だと説明できます。一方、担当別に見る目的だけを理由に、全担当の記録を誰でも閲覧できるとは決められません。使い方と権限は後で分けて確認します。

背景として参照した公開相談では、帳票要件を聞き始めたIT分析担当者が、短い会議で項目の影響やアクセス範囲まで確認できるかに悩んでいます。本人は後から質問できることや、まだ最初の案件の途中であることも述べています。本稿の設備保守会社は、その本人の職場や実案件を再現したものではありません。本人の質問と追加返信。

元の受付記録と表示欄を対応させる

使い方が見えたら、修理依頼の受付記録と、表示したい欄を照らします。この例の候補は「受付番号・受付日・現在の状態・担当者」です。同じ名前の欄が存在するだけでは、帳票が使う値として適切かは分かりません。

受付番号：どの依頼へ戻るための欄か

帳票で見つけた依頼を、元の受付記録へ戻して確認できるかを考えます。元記録を特定する方法や番号の形式は、記録管理者と提供会社へ確認します。この教材には番号の実値や形式の指定はありません。

受付日：どの出来事の日を表すか

欄名だけで解釈せず、元記録で受付日が何を示すかを確認します。対象を絞る日付と、表示する日付が同じかも分けて聞きます。未提供の日付を今日の日付などで補いません。

現在の状態：どの意味と時点の値か

状態を誰がどの条件で付け、変更するのかを聞きます。「現在」という名前でも、帳票を開いた時点の元記録と同じ鮮度とは限りません。確認待ちの意味は、この例では業務責任者へ確認予定です。

担当者：誰の何の担当を表すか

この欄を使って誰へ状況を聞くのかを確かめます。表示名から連絡先や管理権限を自動的に推定しません。担当の情報が不足している場合の扱いも、元記録の管理担当に確認します。

それぞれについて、業務上の意味、参照する元の欄、値を管理する担当、帳票での使い方を結びます。元記録に必要な情報があるなら、その利用条件と取り方を確認する作業へ進みます。見つからなければ、表示欄を増やしただけで値を作れることにはなりません。別資料から取得するのか、入力や運用の変更が必要かを、担当と発注先へ相談します。

これは帳票の仕事に必要な対応を整理する段階です。データ項目そのものの意味や更新元を詳しく決める場合は、元情報と表示用の値を分ける方法も参照できます。ここでは新しい帳票の用途と表示条件を主題にします。

対象条件・時点・更新・閲覧範囲を分ける

表示欄をそろえた後も、何を含めてよいかは残ります。特に「未完了」と「確認待ち」を同じ条件に置き換えないことが、この例の注意点です。追加質問後には確認待ちだけを対象にする案が出ていますが、適用条件は未承認です。

状態の意味と、対象を選ぶ条件

「確認待ちとは、どんな仕事がどこまで進んだ状態ですか」「その状態の依頼だけで、担当へ確認する仕事を満たせますか」と聞きます。状態名の定義と、帳票へ含める条件は別です。定義が分かっても、その条件で対象を選ぶことまで承認されたとは限りません。

業務責任者が対象条件を確認できたら、帳票に含む依頼と含まない依頼を、同じ意味で説明できる形にします。条件が決まらない場合は、確認待ちだけを対象にする案と不足する判断を下書きに残し、実装する抽出条件として確定しません。

いつの情報かと、どう更新するか

「判断に使うのは、いつの状態ですか」「元の受付記録が変わったら、帳票にはどう反映される必要がありますか」と聞きます。基準となる時点と、更新の方法・タイミングを分けます。いつの情報かが曖昧なままでは、同じ依頼を見ていても、担当が話す状態と帳票の表示が食い違う理由を確かめにくくなります。

ここでは抽出時点も更新方法も未確認です。自動更新、即時反映、定期配信などを、依頼者が決めたこととして追加しません。必要な鮮度が分かった後に、提供会社へ実現方法と制約を確認します。実現できない場合は、使う場面や更新の運用を業務担当と見直します。

利用者と、見られる範囲

「業務担当が見る」という説明に加え、どの役割の人がどの範囲の依頼を見てよいか、誰が変更してよいかを確認します。担当別の一覧を作ることと、ほかの担当の依頼まで閲覧できることは同じではありません。

閲覧範囲は、社内の権限管理を決める担当や業務責任者へ確認します。画面で隠すだけで十分かなど、実際の制御は提供会社と別に検討します。この例では閲覧範囲を決定しておらず、実際の権限付与も行いません。

図で、元記録と未承認の下書きを読み分ける

解説図を原寸で見る

この図を読んだ後の判断：元の受付記録と表示欄の候補は、同じ帳票の説明に使えます。一方、「確認待ち」を対象にしてよいか、その意味と条件を業務責任者へ確認する必要があります。時点・更新・閲覧範囲も未確認です。確認先の回答を受けて、条件と表示の下書きを直してから実装範囲を決めます。矢印を、帳票の実生成や合格の記録として扱いません。

依頼時点と追加質問後の下書きを読む

追加質問後の下書きでは、「確認待ちの依頼を担当別に見て、担当へ確認する」という目的と、対象を絞る案が具体化しています。依頼を受けた時点と同じ項目で読み比べます。質問で下書きを具体化する架空例であり、状態の意味も対象条件も承認済みではなく、帳票を作成・実行した結果ではありません。

次の二つは、この記事で使う架空の条件です。二つ目は、追加質問を受けて用途の説明を詳しくした下書きです。帳票を作って実際に確認した結果や、一つ目の不具合を直した実績ではありません。

「未確認」は、不要・ゼロ件・失敗・承認済みという意味ではありません。

追加質問後は、確認待ちの依頼を担当別に見て、担当へ状況を聞くという用途が書かれています。ただし、確認待ちの意味は確認予定で、確認待ちだけを対象にする条件は未承認です。用途の文章が具体的になったことを、条件や権限まで決まった証拠にはしません。

回答を受けたら、何をどう直す？

質問を増やすだけで終わらず、回答によって変える場所を決めます。業務の説明を聞く人、元記録を管理する人、実現方法を検討する人の回答を混ぜず、誰が何を確認したかを残します。

目的が「担当へ状況を聞く」なら

対象依頼を元記録で特定し、確認する担当をたどれる表示になっているかを検討します。必要な欄の候補を、その行動と対応付けて説明します。担当別の表示や並び順も、その仕事に役立つかを依頼者へ確かめます。

「確認待ち」の意味が一つに定まらないなら

業務責任者に、どんな仕事のどの段階を指すかを聞きます。複数の異なる仕事を同じ語で呼ぶなら、定義や条件を分ける案を検討します。語だけを一致させて、すべて同じ対象へまとめません。

対象条件の案がまだ承認されていないなら

下書きには案であることと、誰の回答が必要かを残します。用途の検討と、確定した抽出条件を分けます。対象外になりそうな依頼をどう扱うかも聞き、確認後に説明と具体例を更新します。

時点や更新の希望が実現しにくいなら

提供会社に制約を確認し、業務担当へその条件で判断できるかを聞きます。表示の時点や更新方法、利用手順を見直します。見た目が同じだからと、遅れを説明せずに採用しません。

閲覧範囲が決まらないなら

権限を決める担当へ、利用する役割と見せたい記録の範囲を確認します。未決のまま広い権限を与える前提で発注しません。用途に必要な範囲と実装方法の確認がそろうまで、その条件を保留します。

元記録に必要な情報が見つからないなら

記録管理者へ所在や意味を確認します。別の記録を使う、新たな入力を検討する、表示の対象を見直すなどの案を、追加の作業として発注先へ相談します。表示欄の追加だけで解決したことにしません。

回答が変わったら、定義だけでなく、対象条件、表示欄、使う具体例、閲覧範囲への影響も見直します。元記録の意味が変わったのに、以前の条件だけを残すと、依頼者の説明と発注先の理解が離れます。関連する部分を一緒に直し、変更した理由を伝えます。

下書きを同じ仕事で読み合わせる

レイアウトの好みを聞くだけでなく、依頼者に「この下書きで何を見つけ、次に誰へ何を確かめるか」を説明してもらいます。元の受付記録と、帳票に載せる想定の条件を同じ例で示すと、欄名だけでは気付かなかった不足を話しやすくなります。

1. 元記録へ戻れるかを見る。表示欄が、どの受付記録のどの意味に対応するかを説明します。下書きに値を置く必要がある場合は、利用が認められた資料や、担当が合意した架空例を別途用意します。この記事には実値を補いません。
2. 対象の入り方を説明する。何が含まれ、何が含まれない想定かを確認します。この教材の対象条件は未承認なので、下書き段階では「確認待ちだけを対象にする案」として読みます。
3. 次の仕事までたどる。利用者が担当へ状況を聞けるか、そのために何が不足するかを聞きます。ほかの目的が出た場合は、同じ帳票で扱うか、別の要求として分けるかを業務担当と検討します。
4. 決まったことと、残ることを分ける。誰の回答でどこを更新したかと、未承認・未確認の部分を残します。下書きを見せた事実だけで、依頼者の承認、実装、実データでの表示確認をまとめて完了にしません。

実装後は、合意した条件と、実際の表示・対象・時点・権限などを照合する確認が別に必要です。どの環境で誰が確認するかは、発注先と計画します。本稿の二条件は下書きの確認結果も本番結果も未確認で、実際の問い合わせや帳票の実行は行っていません。

既存帳票をシステム移行後も使う場合は、旧帳票へ返す数量と表示の確認が別の課題です。この記事は、新しい帳票を依頼する前の使い方と表示条件を決める説明に限定しています。

発注先への説明を具体的に書き直す

この文章には候補の欄がありますが、誰の何の仕事を助けるか、何を対象にするか、いつの状態かがありません。発注先がその穴を推測すると、依頼者が見たい対象や利用範囲とずれる可能性があります。

この書き直しは、二つ目の架空条件を説明文にしたものです。新たな承認・権限・実結果を足していません。実際の発注では、未決の条件を誰がいつまでに確認するかも担当と相談し、回答後に依頼文と下書きを更新します。期限がまだ決まっていなければ、ここで日付を作りません。

まとめ：まず一件の使い方を聞く

帳票の発注準備は、欄をそろえる前に、使う人・見つけたいもの・次の行動を確かめることから始めます。その仕事に必要な元記録と表示欄を対応させ、状態の意味、対象条件、時点、更新、閲覧範囲を分けて整理します。

回答を受けたら、条件と下書き、具体例、発注先への説明を一緒に直します。分からない条件は確認先を付けて残し、未承認の案を実装条件にしません。下書きの説明、業務上の承認、実装後の確認は別の状態です。

最初の一歩は、修理依頼の一件について「この帳票で何を見つけ、その後に誰へ何を確かめますか」と聞くことです。その答えを元の受付記録と候補の欄へ結び、まだ決められない条件を確認する相手まで明らかにしてください。