PDF生成を自前実装すると、なぜ6か月後に負債になるのか

「この画面をPDFで出せるようにしてください」

要件だけを見ると、小さな追加機能に見えます。

HTMLを作り、ヘッドレスブラウザでPDF化する。あるいはPDFライブラリで文字と罫線を配置する。最初の1種類を出力するだけなら、短期間で実装できることもあります。

問題は、その機能が半年後にも同じ規模であることはほとんどない点です。

最初に増えるのは、帳票の種類ではなく例外

顧客名が長い。住所が2行になる。備考欄だけ文字数が多い。明細が1ページに収まらない。印影を追加したい。会社ごとにロゴを変えたい。税率ごとに集計したい。過去の版を再発行したい。

PDF生成の保守コストは、帳票数よりも例外の組み合わせで増えます。

しかも、画面上で正しく見えることと、PDFで正しく印刷されることは同じではありません。

帳票機能を安定させるには、次の3つを分離します。

アプリケーションは、どのテンプレートへどのデータを渡すかだけを決める。デザイン変更はテンプレート側で行う。生成処理はAPIへ任せる。

この境界を作ることで、帳票の変更がアプリケーションの変更にならなくなります。

逆に、複数帳票、可変明細、日本語、顧客別デザイン、業務担当による変更、大量生成のいずれかがあるなら、生成基盤を切り出す価値が高くなります。

帳票生成は、完成後に最も変更要求が届きやすい機能の一つです。

法令、会社情報、ロゴ、振込先、注記、顧客要望、社内ルール。外部要因で書式が変わります。

比較すべきなのは、半年後、1年後に発生する変更・障害・テスト・運用を含む総コストです。

Re:port Flowは、ブラウザで作成したテンプレートへJSONデータを送り、同期・非同期・一括でPDFを生成できます。月30ファイルまで無料でAPIを試せます。