帳票ベンダ・インタビュー
第1回：ウイングアーク テクノロジーズ株式会社

山田祥寛（http://www.wings.msn.to/）
2005/2/5

---

オープン・スタンダードな環境に適用できる統合帳票基盤

　「帳票設計ツール」と一口にいっても、単に帳票そのものの開発を効率化すればそれで良いというものではない。帳票開発は、実にさまざまな要素が伴うものであるからだ。ウイングアークでは「帳票開発」に必要な要素を大きく4つに分類し、それぞれのカテゴリに対して統合的な帳票基盤を提供しているのが特徴だ。ウイングアークがとらえる帳票開発のカテゴリは以下のとおり（表1）。

帳票設計 データ・インターフェイス 帳票運用 入力フォーム

表1　帳票開発の4カテゴリ

　以下では、これら4つのカテゴリに対して、ウイングアークがどのようなソリューションを提供しているのか、具体的な製品ラインアップと照らし合わせながら紹介していこう。

●帳票設計
　いうまでもなく、帳票それ自体の設計は帳票開発全体の中でも最も大きな工数を占めるものだ。帳票設計を効率化することは、帳票開発自体を効率化するための大きな第一歩でもある。

　ウイングアーク社が提供する帳票設計ツール「Super Visual Formade（以降、SVF）」（画面1）は、そうした意味で「統合帳票基盤」の最も基本となるツールであるといってもよい。

画面1　SVFのデザインモードの画面

　SVFでは帳票設計のすべてをGUIベースで行うことができる。つまり、プログラムに精通していない人間でも簡単に帳票が設計できるのみならず、帳票に変更があった場合にも簡単に修正を行うことができる。帳票にアプリケーション・データを割り当てるにも、Microsoft Accessのクエリー機能にもよく似たGUIベースのウィザードから行うことができるのも大きな特徴だろう。

　また、システム構築に先立って、すでに紙で運用している帳票、あるいは、Microsoft WordやExcelで用意されている帳票が存在するケースも多くあるだろう。そのような場合には、既存帳票のイメージ読み込みが役に立つ。つまり、既存の帳票データを「.doc」「.xls」、または画像ファイルを介して読み込み、SVF上で利用可能なデータに変換することができる。これらインポート機能によって、一から帳票設計を行わなくても済むため、帳票開発は大幅に効率化できるというわけだ。もちろん、細部の修正が必要である場合には、SVF上で細部の修正を行うことも可能だ。

●帳票運用
　帳票の電子化に伴って、帳票の出力形態は大きく多様化した。メインフレームの世界ではもっぱら紙によるセンター出力がメインであったが、分散環境の浸透に伴って、PDF、HTML、CSV、TIFFなど多様なファイルフォーマットでの出力、また、各拠点のプリンタサーバやFAXサーバ、メールサーバへの出力など、1つの帳票ですら複数の出力形態を持つケースは少なくない。

　異なる形式での出力は、従来、開発者に対して過大な負荷を課したものであるが、ウイングアークでは各種形式に対応した製品が提供されている。SVF for Web、同for FaxPress、同for JavaPrintなどがそれだ。これらの製品群を適用することで、あらかじめ用意した1個の帳票データから必要に応じて思うがままの出力を行うことができる。

ウイングアーク 営業本部マーケティング部マネージャ谷口功氏

　また、ウイングアークの出力ソリューションで強調しておくべきは、いわゆるプリンタサーバの「コマンド印刷」に対応している点だろう。

　谷口氏は、コマンド印刷についてこう語る。「従来、多くの帳票ソリューションは『イメージ印刷』にのみ対応しているのが常でした。イメージ印刷は、その名のとおり、印刷イメージそのものを出力するため、出力先のプリンタを意識しなくてもよいという利点があります」。しかし、半面で、スプール量が肥大化しやすかったり、プリンタの機能を最大限に引き出せなかったりという問題もあるという。

　半面、「コマンド印刷」はプリンタのコマンドを直接に発行する。そのため、スプール量はイメージ印刷のおよそ10分の1にまで抑えられるという利点がある。これは、ネットワーク上で大量の帳票発行を行ううえでは大きな強みだ。そして、これを支えているのが、同社独自のプリンタ・ドライバ技術だ。

●データ・インターフェイス
　帳票開発を行ううえで、上位アプリケーションと帳票アプリケーションとが密に連携していることは保守性という意味で好ましくない。出力先、形式に合わせて、結局は上位アプリケーションそのものに手を加えなければならない可能性が出てくるためだ。

　そこで、ウイングアークは帳票アプリケーションと上位アプリケーションの疎な関係を保証するデータ・インターフェイスを「統合帳票基盤」の重要な一要素として位置付けている。谷口氏はデータ・インターフェイスについて「テキスト形式のインターフェイスだけを提供しているツールは多いが、上位アプリケーションによっては、プログラムレスによりデータ取得を可能にするクエリー機能が有効」と述べ、同社のデータ・インターフェイスをテキスト／CVS形式、XML／固定長形式、クエリーのダイレクトアクセス形式で提供する理由を説明した。ウイングアークでデータ・インターフェイス部を担う製品は、「Universal Connector/X」「Dr.Sum」の2製品だ。

　帳票ソリューションの中でもテキストベースのインターフェイスを持っているものは少なくないが、Universal Connector/Xではそれに加え、XML形式や固定長データにも対応し、また、JDBCやODBC、SQL-Netなどの標準的なデータ・インターフェイスにも対応して既存のデータベース・サーバから直接にデータを抽出できる（ダイレクトクエリー）のも大きな強みだ。

　片や、Dr.Sumはもっぱらエンドユーザー向けの多次元集計検索インターフェイスだ。帳票と一口にいっても、社外向けや税務上の確証を目的とした「定型帳票」だけではない。社内の経営戦略会議や経営者への報告を目的とした「非定型帳票」――月間売り上げや顧客分析などの、いわゆる「レポート」は、社内に多く存在するはずだ。そのようなレポートを作成するために、これまでどのような方法が用いられてきただろうか。ユーザー部門からシステム運用部門にデータ抽出の依頼が提出され、運用部門で出力されたデータを、ユーザー部門でまたあらためてExcelなどで集計していたというのが実情ではないだろうか。これは、リアルタイムに情報を取得できないのみならず、システム運用部門に負荷が集中する原因ともなる。ユーザー部門、システム運用部門いずれにとっても、これは不幸なことだ。

　しかし、Dr.Sumを利用することでユーザーはあらかじめ用意された「データキューブ」（基幹システムから分析用に取り出された多次元データベース）に対して、Excelやブラウザなどから直接にアクセスすることができる（画面2）。

画面2　Dr.SumのExcelアドインを使用している画面

　これによって、リアルタイムな経営データを、システム運用部門の手を煩わせることなく入手することができるのだ。また、Dr.Sumはデータキューブの更新に当たって追記方式を取っているため、更新に負荷が掛からず、限りなく基幹システムとの同期を取ることができる。

●入力フォーム
　そして、最後に取り上げるのが「入力フォーム」の世界だ。

　これまではもっぱら出力の側の観点に立って「帳票」を見てきたが、当然、入力に際しても帳票は欠かせない。しかし、従来のシステムでは電子フォームといってもHTMLベースで独自のフォームを構築するケースがほとんどであった。つまり、エンドユーザーからして見れば、最終的な出力帳票をイメージしながら入力が行えないため、決して使い勝手が良いとはいえなかった。これを嫌って、HTML＋CSS（JavaScript）ベースでオリジナルの帳票に限りなく近いフォーマットを実現することも可能ではあるが、これは多大な工数を要するうえに、何かしら帳票に変更が発生した場合の影響度合いは大きい。

　しかし、フォーム生成ツールであるVisual Conformを利用することで、オリジナルに限りなく近い入力帳票をGUIベースで簡単に作成できる。要は、先述したSVFの入力フォーム対応版といっても良いだろう。Visual Conformで作成した入力フォームは、そのまま出力帳票に変換することができるので、入力から出力までの一連のワークフローで一貫した帳票を、エンドユーザーは利用できるというわけだ（図1）。

図1　左から右へと一連のワークフローで生成される帳票

ウイングアーク テクノロジーズが考える今後の課題

　以上、ウイングアークが取り組む「統合帳票基盤」について、「帳票設計」「帳票運用」「データ・インターフェイス」「入力フォーム」という4つの視点から見てきた。しかし、ウイングアークの魅力はこうした豊富な製品ラインアップだけではない。「統合帳票基盤」と既存のアプリケーション層とを連携する「実践型実装モデル」（図2）の提案は、ウイングアークならではの知的財産であるといえるだろう。

　実践型実装モデルの定義について、谷口氏は以下のように説明した。「実践型実装モデルとは、帳票アプリケーションの上流下流を占める、プラットフォームやミドルウェア、物理的なプリントサーバまで、各種ソフトウェア／ハードウェアとの組み合わせを効率的に行うための実装モデルです」。いまさらいうまでもなく、オープン化のトレンドは、さまざまなミドルウェアとの組み合わせを可能にしたというわけだ。

　しかし、無限に存在する組み合わせのパターンと、組み合わせごとの検証が開発者の負担をいや増しているのも事実だ。そうした開発者のために、「実践型実装モデル」は大きな資産であるといえるだろう。開発者は帳票アプリケーションと自身のアプリケーションとを結び付けるためにさまざまな資料をあさる必要はない。「実践型実装モデル」が提供する多くの連携モデルが、開発者の検証の負荷を大幅に低減してくれるというわけだ。

図2　実践型実証モデルを表現した図

　これら連携モデルの一端は、同社が展開する帳票連携サイト「帳票iワールド」でも公開されており、同社では今後、本サイトの連携モデルをより強化することで、帳票ソリューションの総合力を高めていくという。

　繰り返しではあるが、帳票開発は必ずしも帳票それ自体の設計だけにクローズされるものではない。システム全体の中でどのように組み込んでいくかが、システムとしての開発生産性や保守性を左右するものでもある。そうした意味で、ウイングアークの「統合帳票基盤」は大きな強みでもあり、同社の今後の動向に期待したい。

---

前のページへ

目次：帳票ベンダインタビュー（1）
	どのようにして「帳票」技術が必要になったか
	ウイングアークが考える今後の課題とは？

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）