PDF帳票の開発を頼む前に、印刷と再発行の条件を決める
PDF帳票の開発要件を、複数ページ、長文、金額丸め、版、再発行、権限の条件別検収表に整理。見積依頼の前提、納品時の確認方法、合意後に追加範囲とする境界を明確にします。
執筆・確認株式会社adding 編集部
order-guide / contract
PDF帳票の開発要件は、見本のレイアウトだけでは決まりません。見積依頼の前に必要なのは、データが複数ページへ続くとき、長文が枠に収まらないとき、金額を丸めるとき、発行後に訂正するときの期待結果です。さらに、その操作を誰に許すかまで決めます。
これらを「きれいに印刷できること」の一文にまとめず、条件・操作・期待結果の組として検収表へ落としてください。決まっていない項目は無理に確定せず、未決と明記します。そうすれば、納品時に何を確認するか、合意後の変更をどこから追加範囲とするかを同じ表で判断できます。
難しいのは、実データでしか現れない崩れと、発行後の運用を見積もり前に想像することです。以下の表は、その抜けを発注者側で洗い出すためのたたき台です。
PDF帳票の開発要件は「一枚の見本」から分解する
ページ媒体には、用紙だけでなく別々に扱う要素があります。W3Cのページ媒体仕様は、ページの大きさ・向き・余白・罫線・パディング、ヘッダー／フッター、ページ番号をそれぞれ制御対象として挙げています。また、用紙の対象サイズと向きは、固定寸法または用紙名と縦・横の組み合わせで指定するものとされています（2026年9月21日確認、W3C「CSS Paged Media Module Level 3」）。
つまり、見本どおりの一ページが出れば完成、とは限りません。運用上の提案として、まず次の項目を分離して見積依頼書へ記載します。
- 用紙サイズと縦向き・横向き
- 上下左右の余白
- 各ページに置くヘッダーとフッター
- ページ番号の表示位置と形式
- 明細が次ページへ続くときの見出し
- 表の途中で改ページするときの扱い
- 長文を折り返す、切る、別欄へ逃がす条件
この一覧は、異なるデータ量でも業務に使える出力かを判定する単位です。デザイン指定とは分け、罫線の色や文字の位置を詰める前に、ページが増えたときに情報の対応関係を失わないかを決めます。
印刷条件の検収表
次の内容は運用上の提案です。「入力・前提」は発注者が用意できるデータの特徴に置き換え、「期待結果」は実装前に開発側と合意してください。
| 条件 | 操作・確認 | 期待結果として決めること | 見積時の状態 |
|---|---|---|---|
| 通常の内容が一ページに収まる | PDFを作成し、想定する用紙で確認する | 用紙サイズ、向き、余白、ヘッダー／フッター、ページ番号 | 決定／未決 |
| 明細が複数ページになる | ページ末尾をまたぐ明細を含めて出力する | 見出しの再表示、ページ番号、前後ページでの明細のつながり | 決定／未決 |
| 一つの明細に長文が入る | 長文を含めて出力する | 折り返し、行の高さ、欄からあふれる場合の扱い | 決定／未決 |
| 表の途中で改ページする | 改ページの前後を確認する | 行を分割するか、行単位で次ページへ送るか | 決定／未決 |
| ヘッダー／フッターと本文が近接する | 各ページの上下端を確認する | 本文との重なりを許さず、必要な情報を維持する | 決定／未決 |
複数ページと長文は別条件です。明細数は少なくても、一つの備考が長ければ行の高さが変わります。両方を組み合わせたデータも受け入れ確認に含めるかを決めておくと、「単独条件では通るが、同時に起きると崩れる」という見落としを減らせます。
金額は表示桁だけでなく、丸める場所を決める
「小数を四捨五入する」だけでは、期待する合計を一意にできません。丸める桁と方式に加え、明細、小計、合計のどこで丸めるかを分ける必要があります。
OracleのBigDecimal仕様では、丸め動作を利用者が制御でき、精度と丸めモードを指定できます。演算は正確な中間結果を求めた後、必要に応じて選択した丸めモードで指定桁数へ丸めるものと説明されています（2026年9月21日確認、Oracle「BigDecimal (Java SE 25 & JDK 25)」）。この説明から、丸め方は要件として明示できると分かります。特定の実装方法を指定する根拠にはしていません。
運用上の提案として、金額の検収表は次のように分けます。
| 条件 | 合意する内容 | 検収で照合するもの |
|---|---|---|
| 丸めが必要な金額 | 丸める桁と丸め方式 | 境界値を含む入力と期待表示 |
| 明細ごとに端数が出る | 明細単位で丸めるか | 各明細の表示と計算結果 |
| 小計を表示する | 小計時に丸めるか | 明細から得る小計と表示 |
| 合計を表示する | 合計時に丸めるか | 小計との関係、最終表示 |
| 同じ金額を画面とPDFに出す | 共通の結果を使うか、表示規則を分けるか | 画面表示とPDF表示の対応 |
境界値に何を使うか、期待結果を誰が確定するかも依頼書へ残します。発注者が業務上の正解を示し、開発側が再現できる条件にしてください。「適切な丸め」という開発会社任せの表現は、期待結果を確定できません。対象は一般の作業報告書や見積書における表示の一貫性であり、税務や法定帳票としての適否は扱いません。
版と再発行は、上書き保存の話ではない
訂正後のPDFを作れるだけでは、再発行の要件は終わりません。初回発行済みの内容と訂正版をどう識別するか、過去の版を誰が見られるか、再発行した事実を何で確認するかを決めます。
運用上の提案として、帳票自体の条件と再発行台帳の条件を分けます。台帳に残す候補は、版識別子、訂正理由、発行者、発行日時です。各項目を残す要否は業務に応じて選び、見積条件にしてください。
| 状態・操作 | 帳票で決めること | 台帳で決めること | 検収の観点 |
|---|---|---|---|
| 初回発行 | 初版を識別する表示の要否 | 発行者・発行日時を残す要否 | 初回発行として区別できる |
| 内容の訂正 | 元の版との区別、訂正表示の要否 | 訂正理由と版識別子を残す要否 | 元の版と訂正版を取り違えない |
| 再発行 | 再発行表示の要否 | 再発行者・再発行日時を残す要否 | 再発行の事実を確認できる |
| 過去版の参照 | 過去版を表示・取得できるか | 参照対象の版を特定できるか | 現行版と過去版を区別できる |
ここで「再ダウンロード」と「訂正版の作成」を同じ操作にしないことが重要です。保存済みの同一版をもう一度取得する場合と、内容を変えて新しい版を作る場合では、許可したい役割も確認したい記録も異なります。
再発行の権限は操作ごとに検収する
OWASPは権限設計において、利用者の種類、公開するリソース、そのリソースに対する読取・書込・更新などの操作を列挙し、組み合わせごとに許可する操作を決めるよう推奨しています。また、設計した権限が正しく強制されることをテストし、アクセスは既定で拒否し、すべてのリクエストで権限を検証するよう推奨しています（2026年9月21日確認、OWASP「Authorization Cheat Sheet」）。
この考え方をPDF帳票へ当てはめる運用上の提案が、役割と操作の検収表です。担当者・承認者・管理者という名称は例なので、実際の職務名に置き換えます。可否は発注者が決め、空欄を残さないようにします。
| 操作 | 担当者 | 承認者 | 管理者 | 拒否時に確認すること |
|---|---|---|---|---|
| 初回発行 | 可／不可 | 可／不可 | 可／不可 | 許可のない役割では発行できない |
| 発行済み帳票の閲覧 | 可／不可 | 可／不可 | 可／不可 | 対象外の帳票を閲覧できない |
| ダウンロード | 可／不可 | 可／不可 | 可／不可 | 閲覧可でも取得不可とするか |
| 訂正版の作成 | 可／不可 | 可／不可 | 可／不可 | 元データの更新権限との関係 |
| 同一版の再発行 | 可／不可 | 可／不可 | 可／不可 | 操作記録を残す要否 |
| 過去版の取得 | 可／不可 | 可／不可 | 可／不可 | 現行版以外へのアクセス可否 |
許可される操作だけでなく、許可されない役割で拒否されることも納品時に確認します。画面上のボタンを隠すかどうかだけで判定せず、対象の操作が実際に拒否されることを期待結果にします。
権限を含む要件全体の整理には、システム開発の要件定義チェックリスト｜外注前に決める10項目も利用できます。帳票の検収表は、その中の出力、権限、受け入れ条件を具体化した資料として添付すると、依頼の前提を共有しやすくなります。
未決欄と変更欄で、追加範囲を判定する
見積依頼時にすべてを決め切れなくても構いません。ただし、空白は「開発側へ一任」なのか「後で発注者が決める」のか判別できません。運用上の提案として、各条件に決定・未決・対象外の状態を付け、未決なら決定者と決定時期を記載します。
さらに、印刷条件、丸め条件、版と再発行、操作権限のそれぞれに変更欄を設けます。合意した検収表に対し、何を、なぜ、いつ変更したかを残してください。見積時に未決だった項目や、合意後に変えた項目は、当初範囲へ当然に含めず、影響を確認して追加範囲かを判定します。見積書を比較するときの観点は、システム開発の見積もりの取り方と内訳｜妥当性の判断基準も参考になります。
発注時に渡す資料は、完成した仕様書である必要はありません。帳票見本、条件別検収表、権限表、未決・変更欄が対応していれば、開発側は決定済みの範囲と確認が必要な範囲を分けられます。
納品時には、一ページの見栄えだけでなく、複数ページと長文が重なる条件、丸めの境界、元の版と訂正版の区別、許可されない役割での拒否まで表に沿って確認します。それが、PDF帳票の「印刷できた」を、業務で使えるかどうかの判断へ変える条件です。
費用、期間、契約、法務・税務上の扱いは条件により異なります。記事の確認日とリンク先の一次情報を確認し、個別判断は専門家へご相談ください。
システム開発・発注ガイドへ戻る