帳票と同一デザインを実現可能なPDF

図2●PDFのフォーム機能と電子メールを活用して申請書のりん議を処理 コメット情報は，Acrobatのフォーム機能で紙の申請書と同じデザインの電子申請書を作成，電子メールを活用したワークフローにより処理する。上長や部門長の承認は，Acrobatの電子署名機能を利用している

　PDFファイルは，あらゆるアプリケーションの印刷出力から自動的に作成でき，実際の帳票と全く同じレイアウトを実現できる。紙の帳票をスキャナで取り込むことも可能だ。

　コメット情報は，人事・総務・経理関係など約50種類の紙の申請書をすべてPDF化した。フォームに必要事項を入力し，電子メールに添付して上長に送信する。上長は内容を確認し，電子署名を付けて部門長に送信するといった電子申請ワークフローを実現した（図2[拡大表示]）。最終的にPDFのフォーム内容をCSVに変換し，会計ソフトなどにインポートしている。

　同社では，それまで，紙の申請書に上長や部門長が承認印を押す形で，りん議を処理していた。最終的に，経理部の担当者が端末から入力していた。地方や海外に出張している社員は，本社に戻ったあとに申請する形態をとっており，処理を迅速化するためシステム化に踏み切った。

　PDFを採用する決め手になったのは，「紙の申請書と見た目も同じインタフェースが実現でき，ユーザー教育が最小限で済む」（コメット情報 取締役社長 名和豊氏）点である。同じくPDFで保険の新規申し込みを処理するシステムを構築したアクサ生命保険も「ユーザー・インタフェースを帳票と同じレイアウトにすることで，直感的にデータの入力が可能になった」（アクサ生命保険 ITプランニング ビジネス リレーションシップ マネージャー 横川英樹氏）と高く評価している。

ファイル容量や特有の概念に注意

　FlashとPDFは，業務システムのフロントエンドとしての実績はまだ少ない。そのため，開発環境やノウハウの蓄積など未整備な点もある。

　2002年3月に発売された，Flashのオーサリング・ツールであるFlash MX＊3は，フォームやボタンをデザインする機能や，デバッガなどを備え，業務システム開発機能を強化した。しかし，Visual Studioなど業務アプリケーション開発ツールと比べれば，機能は改良の余地がある。

　そもそもFlashはアニメーション・ツールとして作成されたものであり「フレーム（映像の1コマ）など特有の概念の理解が不可欠」と羽生氏は指摘する。またFlashでは，なるべく早く実行を始められるようにするため，データをダウンロード途中に実行を始める。そのため，回線速度によって挙動が変わる場合もある。データがすべて順番通り届くかどうかも保証されない。このような特有の仕様を理解し「クライアントのFlash側で，サーバーへ発行したリクエストを記憶しておくなどの工夫が必要」（羽生氏）となる。

　一方，PDFファイルについては，ファイル容量が大きくなりやすい点に注意したい。アクサ生命保険では当初，PDFファイルをサーバー側に保存してクライアントにダウンロードして利用していたが，入力チェックなどのスクリプトを組み込んだ結果，申込書1枚当たり約600K～800Kバイトに膨らんでしまった。本社と営業拠点は64Kや128Kビット/秒のフレーム・リレーで接続しているところもあり，ダウンロード処理に100秒くらいかかることもあったという。

　結果的に，PDFファイルをあらかじめクライアントPCに配布しておき，フォームに入力したデータのみをサーバーとやり取りする方式で乗り切った。コメット情報では，「電子承認印の数が増えるとファイル容量が1Mバイトを超えたケースもある」という。

　コメット情報では，PDFの保存機能の有無でも戸惑った。当初，フロントエンドには無償のAcrobat Readerを採用する方向で検討していたが，Acrobat Readerにはフォームにデータを入力後，ローカルPC上で保存する機能は付属していない。そのため，ファイルの保存機能を有する有償のAcrobat Approval＊4を採用した。1ユーザー当たり3000円ほどライセンス料が発生したが「この金額で同様のシステムを構築する方法はまずない」と費用対効果には満足している。

　フォームの開発は，Acrobat上で帳票上にマウス操作でフォームやスクリプトを張り付けて行う。デバッガなどの開発支援機能は低い。また，帳票そのものをデザインするツールは付属していない＊5。既存の帳票を利用するか，WordやExcelなどで帳票を作成する必要がある。