開発方法の色々
では実際には、どのようにして帳票開発が行われているのでしょうか？ 大まかには、以下3つの方法が挙げられます。
- 帳票開発ツールの利用
- 完全に自作する
- Excel操作ライブラリの利用
帳票開発ツールの利用
帳票を開発する際に第一の選択肢になり得るのは「餅は餅屋」、つまり専門の帳票開発ツールを導入して開発することです。具体的には「SVF」「JasperReports」「Active Reports」といった製品が挙げられます。
これらには、エンタープライズ用途での帳票開発に必要な機能が盛り込まれています。ミリメートル単位で正確に文字や罫線を表現可能で、プリンター等と連携して帳票を高速に出力できます。製品によっては、RDBMSと連携してSQLを記述するだけで必要なデータを取得するなどの機能も包含します。
しかしながら、「細かいことにはこだわらないので、とりあえずPDFやExcelで帳票がダウンロードできればそれでいい」といったライトユースでは、いささか高機能すぎる面があり、そのライセンス費用を回収する程度の効果を得ることが難しいケースも多いでしょう。
また、多くの帳票開発ツールはその高度な機能を使いこなすために、相応の学習コストを要求することも事実です。帳票エディタはDTPソフトの使い方を覚えるのに近い学習時間を要求しますし、データ連携のための各種機能もマニュアルを参照しつつデバッグを重ね、使い方を覚えていく必要があります。デザインした帳票をプログラム上から扱うにも、高度な機能を扱うための重厚なAPIやイベント処理を使いこなすことが必要とされます。
私もこういった製品を何度か使用したことがありますが、個人的な感覚では基本的な帳票を作れるようになるまで1カ月、そこからどんな帳票でも実装できるという自信が湧いてくるまで、さらに2～3カ月を要したと記憶しています。プリンター制御やデータ連携などの高度な機能を使いこなすには、またさらに学習を重ねる必要があります。
完全に自作する
「帳票開発ツールは自システムに適さないのでは」という場合は、第二の選択肢として一から自作することが挙げられます。必要な機能だけを有するシンプルな帳票出力機能を実装するといった方針です。
この場合、帳票出力に応用できる方法としてはさまざまなものがありますが、代表的には以下2つが挙げられると思います。
- 「PDFBox」などのPDF操作ライブラリを使用する
- HTML＋CSSを用いた帳票レンダリング
PDF操作ライブラリを利用した帳票開発には困難が伴います。なぜならば、PDF操作ライブラリはあくまでもPDFファイルを構成するテキストや線、イメージといった要素を操作するための低レベルなAPIを提供しているだけで、帳票を出力するための高度なAPIは用意されていないからです（当然ですが）。
このため、罫線やテキストを配置するにも絶対座標をポイントやミリメートルといった単位に変換した上で、一つずつの要素に対しそれぞれAPIをコールしていく必要があります。このような方法によって構成された帳票はその後の仕様変更で多くの修正が生じてしまいやすく、コードから完成した帳票をイメージするのが難しいため、開発者本人しかメンテナンスできない状況に陥りがちです。
任意の図表やテキストを思い通りの書式で出力するための有名な言語としては、HTMLとCSSがあります。HTMLとCSSで帳票を構成し、ブラウザによってレンダリングした結果を何らかの方法によってPDF等に出力すれば、任意の帳票を作成することができます。特にHTMLは世の中にたくさんのテンプレートエンジンがあり、一般的なWebの開発手法が流用できる利点もあります。
しかしながら、IT系エンジニアの基礎知識のように語られることも多いHTMLやCSSは奥が深く、帳票開発という視点では、狙ったところに罫線で囲まれたボックス1つを出力するのにもそれなりの知識が要求されます。具体的には、帳票開発ではz-indexとスタックコンテキストの理解、メディアクエリ、改ページ制御等に関する知識が必要になってくるでしょう。専門的にフロントエンジニアとして取り組んできた方であれば苦もなくできる作業ではありますが、必要に応じてHTMLやCSSを学習してきた方はいささか戸惑うかもしれません。
また、クライアント側で生成した帳票を印刷したりPDFとして出力したりすることは比較的簡単ではありますが、サーバーサイドでPDF等々に出力するためには多少の工夫が必要になります。具体的には、Seleniumなどのテスト自動化ツールを使用したり、バックエンドにWebページのレンダリングエンジンを利用したHTML to PDF変換ツールなどを使ったりする必要があります。ブラウザ（レンダリングエンジン）の立ち上げや終了で消費するリソースは少なくなく、サーバー上で長期にわたって安定して稼働させるためにはそれなりのノウハウを必要とするでしょう。
筆者もこの方法を試みたことがありますが、100回に1回ほどの頻度で帳票出力処理がハングアップしてしまう現象に悩まされた記憶があります。おそらく、何らかのリソースを取得しようとしてデッドロックに陥ったのだと予想していますが、最後まで原因は分かりませんでした。ブラウザやレンダリングエンジンはサーバー上で頻繁に起動と終了を並行して繰り返すような用途は想定して作られていないでしょうし、仕方のないことかもしれません。
自作する場合と帳票開発ツールを利用した場合の注意点
これまでの経験上「出力された帳票をエンドユーザーが編集したい」というご要望は多数受けたことがあります。
PDFやHTMLをベースとした開発方法を採用すると、システムのユーザーが編集する運用は難しくなります。これは「帳票開発ツールを利用する」というパターンでも、帳票開発ツールが対応している出力形式によっては同様の問題が発生します。
そもそもなぜ出力後にユーザーが手作業で編集する必要があるかというと、例えば現場での帳票の運用方法があまりにも多岐にわたるため、それらすべてをカバーしたシステムを構築するのは費用対効果の面から現実的でないといった背景があります。
すでにDocurainを導入・運用していただいている、建築業界向けSaaSサービスを提供する某社を例にすると、作成した帳票は建築現場や細分化された組織ごとに修正を加えて独自の運用をされているケースが多いそうです。そのほかにも、その日の作業内容によって帳票の項目（例えば、KY・危険予知実施項目など）やレイアウトを変更して入力欄のサイズ調整や説明文を修正する場合もあるとのことでした。
従って、帳票はExcel形式で出力して現場・組織ごとに修正した上で印刷し、全員に配って現場で参照できるようにしています。この手作業の運用をシステム化するには開発工数の増加という問題もさることながら、エンドユーザーである作業者、職長のITリテラシーを考えてもExcelで出力した結果を修正するような運用が望ましいとして、このような結論に達しました。
この例に限らず、ユーザーが出力された帳票を手作業で修正したいケースにおいては、多くの人が手軽に編集できるExcel形式での出力を求められることが非常に多いのです。
Excel操作ライブラリの利用
前述の通り、Excelを帳票出力のためのツールとして利用しているケースはとても多いのです。グリッド形式のエディタで手軽に罫線を組み合わせることができ、かつ大抵のPCにインストールされており、多くの人が扱えるExcelを、帳票出力のための簡易的なDTPソフトとして利用することは悪くない方法です。
ところで近年は「ネ申エクセル」なるものが批判の対象となっています。これは「Excelでそこまでやるか」と思わせる重厚で複雑な機能をExcelで実現させたものです。ただ、このサイトの読者であればご存じの通り、「データ」「ビジネスロジック」「ビュー」は分割するのが通常のアーキテクチャです。Excelを単に最終的な出力形態であるビューとして使うだけで責務を明確に切り分けていれば、「ネ申エクセル」問題は発生しません。
そして、おそらくこの事実に気づいた人のほとんどが、一度はApache POI（Java）やOpen XML SDK （C#）といったExcelファイル操作ライブラリを利用して帳票出力機能を実装しようと試みたことがあるのではないでしょうか。しかし残念ながら、この方法もすでに述べたPDF操作ライブラリやHTMLを使った方法の課題を解決できるものではありません。
まず、Excelファイル操作ライブラリを使用し、まっさらのシートにゼロから帳票レイアウトを構築していくのであれば、PDFライブラリを使用するのとの違いはほとんどありません。従って、次にたどり着く手法は「Excelで作成した帳票テンプレートに独自のプレースホルダを埋め込んでおき、生成するときにそれを置換すればコーディングレスで帳票が作成できるはずだ」というものになります。しかしながらこれは想像以上に大変な作業だと気づくはずです。「動的に行が増えていく場合は？」「条件によってレイアウトが変わる場合は？」どのようにそれを実装すればいいのでしょうか。
Excelを帳票テンプレートとして実用的なものにするためには、Excelの内部仕様をよく理解する必要があります。Excelを操作するために提供されているAPIはExcel（OpenXML）フォーマットを操作するための低レベルなAPIなので、それ自体を前提知識として要求しています。例えば、スタイルを適用した行を動的に追加していき値を挿入するといった処理を一つとっても、詳しく知らない人が扱うと簡単にOutOfMemoryエラーを引き起こします（筆者は過去、実際の業務で何度か経験したことがあります）。
そのほか、Excel操作ライブラリを使用する場合にはサーバーサイドでのPDF出力が難しいといった問題もあります。
そういったことを考慮すると、1人のエンジニアが他の作業と並行して片手間で取り組むのは現実的ではなく、専門のチームを抱える必要があるでしょう。ただし、我々は帳票を作りたいのであって、高い開発工数を支払ってExcelで帳票エンジンを作ることが目的ではないのです。一般的な帳票開発ツールの一部分を独自に実装するために、帳票開発ツールを利用するためのコスト以上を支払っては本末転倒です。
