目次
請求書発行の仕組みを作るとき、最初に確認しないと後戻りが大きくなる問いがあります。
**「1回の発行操作で、請求書は何枚出るのか」**です。
地味な質問に見えますが、ここを外すと痛手が大きい。1案件＝1請求書の前提で組んだ後に「請求先ごとに別PDFで」という要件が出てくると、データ構造・採番・PDF生成・集計のすべてに波及します。実案件（匿名）の経験では、この見落としで実装のうち3〜4割しか生き残らず、残る6割は書き直しになりました。
この記事では、なぜ出力の粒度がここまで効くのか、そして着手前に潰しておくべき確認質問5つを整理します。
この記事の結論
- 機能一覧より先に、出力の粒度を確定させる
- 粒度はデータ構造・採番・PDF・集計の土台になる
- 着手前の確認質問5つで手戻りの大半は防げる
出力の粒度とは｜「何を単位に1枚か」
出力の粒度とは、請求書1枚に何をまとめるかという単位のことです。
同じ「請求書を発行したい」でも、現場によって単位はまったく違います。
| 粒度の型 | 1枚の単位 | 発行操作1回で出る枚数 |
|---|---|---|
| 案件単位 | 案件ごとに1枚 | 1枚 |
| 請求先単位 | 取引先ごとに1枚（複数案件を合算） | 取引先の数だけ |
| 月次一括 | 対象月の全請求先 | 数十枚〜 |
| 分割請求 | 1案件を複数回に分けて請求 | 案件ごとに複数枚 |
依頼の言葉はどれも「請求書を自動で出したい」です。しかし作るものは、この4行でまるで違います。先に決めるべきは機能ではなく、この行のどれなのかということです。
手戻りが起きる原因｜粒度が「土台」だから
なぜ粒度のズレだけで6割も書き直しになるのか。理由は、粒度が上に乗るすべての処理の前提になっているからです。
順に見ると、影響の広さが分かります。
- データ構造：1案件＝1枚なら、明細は案件にぶら下げれば足ります。請求先単位で合算するなら、複数案件を横断してまとめる構造が要ります。テーブル設計そのものが変わります。
- 採番：請求書番号を案件ごとに振るのか、請求先ごとに振るのか。後から変えると、既に発行済みの番号との整合が崩れます。
- PDF生成：1回の操作で1ファイルなのか、宛先ごとに分割して複数ファイルなのか。ファイル名の付け方も保存先の分け方も別物になります。
- 集計・突合：経理が売上と請求を照合するとき、案件単位で見るのか請求先単位で見るのか。ここが揃っていないと、自動化しても最後は手で突き合わせることになります。
つまり粒度は「あとで直せる仕様」ではなく、建物でいう基礎です。基礎が変われば、上物は残りません。
着手前に潰しておく確認質問5つ
実案件（匿名）から整理した、着手前の確認質問です。順番にも意味があります。
1. 1回の発行操作で、請求書は何枚出ますか
最初に聞くべき問いです。「1枚」と即答されたら、それは案件単位か、請求先単位かまで確認します。ここが曖昧なまま進むケースが一番多い。
2. 1枚の請求書に、何件分の明細が載りますか
1案件だけなら単純ですが、「同じ取引先の当月分をまとめて」となると、合算のルール（対象期間・締め日・除外条件）まで決める必要があります。データ構造はここで決まります。
3. 請求書番号は、何を単位に採番しますか
案件単位か、請求先単位か、月次の通し番号か。再発行したときに番号は変わるのか、据え置くのかも同時に確認します。後から変更が効きにくい項目です。
4. PDFは1ファイルにまとめますか、宛先ごとに分けますか
まとめて印刷したいのか、取引先ごとにメール添付したいのか。用途が決まればファイル分割の方針も、ファイル名の命名規則も自然に決まります。
5. 集計や突合は、どの単位で見ますか
経理が最後に見る表の単位です。ここが1〜4とズレていると、システムは動くのに現場は電卓を叩き続けることになります。
聞く相手を間違えないこと。実際に発行している担当者に、先月の発行データを見せてもらいながら聞くのが確実です。「どんな機能が欲しいか」ではなく「先月は何回操作して何枚出したか」という事実を確認します。
要件確認の進め方｜3ステップ
- 出力の粒度を確定する：上の5つの質問で、1枚の単位と1回の枚数を書き出します。
- 1枚のサンプルを紙で作る：実データを使って、完成イメージの請求書を1枚だけ手で作ります。この時点で「あ、この項目も要る」が高い確率で出ます。紙の段階で出れば、手戻りはゼロです。
- 機能一覧を詰める：粒度が固まってから、承認フロー・再発行・保存先・メール送信といった機能を決めます。順序を逆にすると、機能を積んだ後に土台をやり直すことになります。
見た目は変えず、単位だけ先に決める
もう一つの勘所は、既存の請求書フォーマットを最初に変えようとしないことです。
現場は「いつもの書類」が変わると混乱します。レイアウトの議論を先にすると、そこで時間を使い切って、肝心の粒度が曖昧なまま実装に入ってしまう。見た目はこれまで通りにして、裏側の単位だけを先に確定させる。この順番なら、議論は短く、手戻りも小さくなります。
なお、外部の会計サービスやSaaSと連携する場合は、そちら側の採番ルールやデータの持ち方にも制約があります。仕様は変わるため、最新は公式で確認してください。
よくある質問
Q. 請求書発行システムの要件定義で、最初に確認すべきことは何ですか？ 機能一覧より先に「出力の粒度」です。1回の発行操作で請求書が何枚出るのか、何を単位に1枚とするのかを確定させます。ここを外すと採番・PDF生成・集計のすべてに影響し、大きな手戻りになります。
Q. なぜ出力の粒度を間違えると手戻りが大きいのですか？ 1枚の単位はデータ構造・請求書番号の採番・PDFの分割・集計の見方すべての土台だからです。土台が変わると上に乗る処理も作り直しになり、実装の6割程度が書き直しになることがあります。
Q. 要件確認は誰に、どう聞けばいいですか？ 実際に請求書を発行している担当者に、直近の発行データを見せてもらいながら聞くのが確実です。「機能として何が欲しいか」ではなく「先月は何回操作して何枚出したか」と事実を確認します。
まとめ
- 請求書発行の仕組みは、**機能一覧より先に「出力の粒度」**を確定させる
- 粒度はデータ構造・採番・PDF生成・集計の土台。後から変えると大半が書き直しになる
- 着手前に、枚数・明細の束ね方・採番・PDF分割・集計単位の5点を確認する
- レイアウトの議論は後回し。見た目は変えず、単位だけ先に決める
RENOYでは、請求書発行や帳票まわりの仕組みづくりを、要件の整理段階からご一緒しています。「作りたいものはあるが、何から決めればいいか分からない」という段階のご相談も歓迎です。まずはお気軽に無料個別相談（オンライン・60分）をご利用ください。サービス内容をまとめた資料は資料請求からご覧いただけます。