徹底して国内で"開発し直す"

すでに国内で5万人以上のユーザー(年間で5,000ライセンス以上を出荷)を持つActiveReportsだが、ここまでの道のりは決して平坦ではなかったという。海外生まれの同ツールが日本市場でここまでたどり着いた背景には、「ローカライズを超えた"日本化"」と八巻氏が語るように、「国内で開発をし直す」というスタイルを貫いてきたことがある。

タテ罫線、余白……日本の帳票文化に対応

グレープシティ ツール事業部 テクニカルエバンジェリスト 八巻雄哉氏

八巻氏は日本の帳票文化の象徴とも言える「罫線」のズレに対する意識の違いを指摘。「0.2mmでもはみ出していると"ズレ"と判断されるのは日本ぐらい」という厳しい要求に対して実装されたのが、ガイドラインへの吸着機能だ。さらに、正確な配置を実現するために同ツールには拡大機能も搭載されている。ActiveReportsでは、欧米では馴染みの薄い「タテの罫線」を、領域をまたいで描けるようにしていることも大きなポイントだという。

線に関しては、日本では「引ける」というだけではダメで、帳票の項目間に適切かつ均等な余白が求められるケースも多い。そのため同社では、これを実現するために内側のマージンを設定する機能を搭載している。

文字の配置についても、欧米では一般的ではない均等割り付け機能が日本向けに追加され、「角丸罫線」も作れるようになっているが、このような細かな点に応えることができなければ、「日本で使える」とは言えないと八巻氏は説明する。

「ここまでやるか!?」というレベルのバーコード対応

八巻氏が本セッションで最も強調していたことの1つが、日本独自のバーコードへの対応だ。「例えば郵便カスタマバーコードやQRコード、コンビニバーコードなどがあるが、これらは日本の独自規格」とし、特に要件が厳しいとされるコンビニバーコードについて説明。

このバーコードは「ベースとなっているのは世界的に使用されているCode128という規格だが、コンビニバーコードでは『バーコードの全長は60mm以内』という要件が設定されている」とのことで、これを満たすにはプリンタの解像度やインクのにじみを考慮した出力が求められるそうだ。ActiveReportsでは「インクやトナーのにじみに対応すべく、バーの幅を補正する機能が搭載されている」とのことだが、開発支援ツールとはいえ、ここまでしないと日本では通用しないのだ。

PDFでの「表示されない」外字問題を解決

常用外の漢字など、日本にはPC上で表示できない日本語がたくさん存在する。Windows環境ではこれを「外字」として登録し機種間で共有すればさほど問題にはならないが、クロスプラットフォームでの活用が前提となるPDFでは話が別。

PDFへの外字埋め込みはAdobe Acrobatなどを使えば可能ではあるが、そもそも専用アプリケーションが必要な上、外字部分で使用しているフォントを指定する必要がある。ActiveReportsでは、フォントにかかわらず外字は必ずPDFに埋め込む設定となっており、「出力したPDF上で外字が表示されないという問題を解決できる」(八巻氏)としている。

帳票開発のネックは「資産の活用」にあり

「帳票開発のネックは資産活用にある」と語る八巻氏は、問題の解決方法としてツールの活用は不可欠だと説明する。八巻氏は「帳票開発ツールの多くは独自技術で開発されており、必要とされるスキルもツールごとに異なる」というが、これはスキルという資産の継承が課題となる。

「Javaと.NETの両方に対応したツールでは、必要なスキル負荷が増大する可能性がある」という八巻氏はActiveReportsのメリットとして、「Visual Studio統合による共通化された手順、プログラミング言語と.NET Frameworkクラスライブラリに対するスキル、既存のソースコードといった"資産"をそのまま活用できる」ことを挙げた。つまり.NETでの開発経験があれば、誰でもすぐに効率的な帳票開発が行えるということだ。

最後に八巻氏は、「ActiveReportsでは、マウス操作だけではなくコーディングによって要件に柔軟に対応できることや、ツールベースでPDFに対して電子署名やタイムスタンプを付加できる」といった同ツールの優位性をアピールし、本セッションを締めくくった。