フロント業務のIT化時代に備えよ！ 帳票・画面統合開発でプロジェクト生産性をUP

		フロント業務帳票のシステム化が始まった

　帳票は情報を載せる“情報ビークル”として、大昔から使われてきた重要な情報ツールである。コンピュータがコミュニケーションの道具として普及した現代にあっても、その重要性は失われることはない。むしろ、コンピュータと結び付くことによって、重要度は増しているといっていいかもしれない。

　とはいえ、今日の帳票利用の実態を見ると、さまざまなユーザーが状況に応じてバラバラな対応に終始している場合が多い。例えば営業職などのフロント業務ではExcelをはじめとしたOfficeアプリケーションを使用して個々人が異なるフォームのものを作成したり、データが共有化されなかったりと、パソコンは使っているものの、実際には「システム化」されていないケースが見受けられる。その一方でプレプリント用紙へ印刷する、基幹システム組み込みの印刷機能もまだまだ現役だ。このうえ、用紙に手書きといったプロセスが残っているケースもある。

　このような「システム化」ができていない状態では、ビジネスプロセスが分断され、情報の活用も業務の効率化も進まない。なぜ、こうした状態が放置されてきたのだろうか？ これまで企業のシステム化は業務が定型化している基幹部分が優先され、比較的業務や組織の変更が多いフロント業務はプログラム変更の手間がかかるため──つまり費用対効果の面から後回しにされてきたといえる。現場である営業部門では“出来る範囲の情報化”という意味でOfficeアプリケーションを使ってきたのだ。

　しかし、ここへ来てフロント業務のシステム化に取り組む企業が増えてきた。基幹システム開発が一巡し、次なる業務効率向上のターゲットとして、フロント業務が挙げられているのだ。その実現に当たっては、数多くの帳票を現場のニーズに合わせて開発しなければならず、勢い帳票開発の生産性、俊敏性がテーマになってくる。

		フロント業務のB to C帳票

　さてこのような中、一部では帳票類の「グラフィカル化」「One To One化」が進んでいる。例えば生保業界では、保険設計プランの提案書などがグラフなどを多用したカラーのものになっている。お客さまごとに異なるデータ、内容を記載するものなので、明らかに帳票だ。つまり、帳票は「情報を正確に記載する」という機能に加えて、従来の印刷パンフレットなどが担っていた「情報を分かりやすく、インパクトのあるものとして伝達する」という役割も合わせ持つようになってきているのである。

SVFX-Designerによる保険提案書の例（クリック >> 拡大）

　お客さま個々に合わせて内容を変えて表現するグラフィカルな「B to C帳票」になると、当然、デザイン的な要素が強くなる。だからといってこれをグラフィックツールで作っていたら、とても間に合うわけがない。顧客データに基づき、動的に1人1人に合わせてきちんと表示内容が変わる仕組みが必要だ。つまり、システム開発者とグラフィックデザイナーが協調するという高度な開発プロセスが求められるといえる。

　一方、データ入力の部分も「グラフィカル化」「リッチ化」が始まっている。1990年代後半ごろから広まってきたWebアプリケーションは、業務システムを直接操作するユーザーを大幅に増やしたが、HTMLの表現力の乏しさもあって、必ずしも万人に使いやすいユーザーインターフェイスが提供されてきたわけではない。紙の帳票には迷わず書き込めるのに、Webシステムではユーザーが立ちすくんでしまうという状況が発生していたのは事実だ。

　それならば、紙の帳票と同じデザインの画面を提供すればいい──そうした発想が出てくるのは、必然だ。お客さま窓口などでデータ入力を行う担当者のインターフェイスとなる「B to C帳票」では、効率的かつミスなく業務が行えるように分かりやすく、使いやすいデザインが重要となる。加えて、控えや捺印のために印刷が必要な場合、入力した内容が画面と同じレイアウトで出力されるというのは、一般のユーザーなら誰でも期待することだろう。

　しかし、これを実現するのは簡単ではなかった。入力画面と出力帳票はシステム設計上の目的が異なり、まったく別々のプロセスで開発されていた。つまり、開発者の都合をユーザーに押し付けていたのだ。

		画面・帳票の開発生産性がプロジェクトのネック

　このように画面や帳票の重要度が増しているが、システム開発プロジェクトにおいては開発件数（画面数／帳票数）が多く、かつプロジェクトの後半になってから取り掛かることになるため、時間とコストを圧迫しやすい、“難関”である。

　エンドユーザーからすれば、システムの中で唯一目に見える部分だけあって注文をつけやすく、変更要求が集中する。プロジェクトの終盤になってから、「実はこういう帳票も欲しいんだけど」という追加要求が出てくることも少なくない。

　ユーザーにとってはちょっとした項目の追加でもあっても、開発者にとってはプログラミングやち密な作業が必要になる場合があり、必ずしもすぐに対応できるとは限らない。レイアウトの変更だけならいいものの、対象データベースのレコードを変えるといったケースでは手戻りが発生する。データベースから取得したデータをそのまま表示するだけであればまだしも、取得データをプログラムで加工している場合はそのプログラムを開発したプログラマにまで戻さなければ対応できないかもしれない。「ちょっとした修正」といっても「どこまで手戻りが必要か」によって、工数が大きく変わってしまうわけだ。当然、大きな手戻りが発生すれば、開発コストも跳ね上がる。

　こうした状況を知らないユーザーからすれば、「なぜ、項目を少し増やしたり、レイアウトを若干変えるだけなのに、欲しい機能がすぐに盛り込めないのか」という不満を持つことになる。

　プロジェクトマネージャから見れば、画面・帳票の工程は最も開発工数が読めず、コスト計算ができない部分だ。にもかかわらずソフトウェアの使い勝手、そしてユーザーの満足に直結するため、あからさまに手を抜くことも難しい。順調に進んでいたプロジェクトが突如、赤字プロジェクトになってしまうのもこの工程に時間とコストを取られたから、という場合が少なくないのだ。

　その状況を打破する方法の1つが、帳票開発ツールの有効活用だ。プログラム言語によるコーディングは、開発者個々に依存する体制となる。ソフトウェアの中核を成すアルゴリズムや処理を開発するために、優れたプログラマに依存するのは致し方ないが、画面・帳票の開発に関しては属人的なプロセスを避け、開発体制／開発環境の革新を行うことで、大幅な開発工数の削減、プロジェクト遅延リスクの低減を実現することができるのだ。

		入力フォームと出力フォームを同時に開発

　帳票開発ツール「SVFX-Designer」と「StraForm-X」の2つの製品を提供するウイングアーク テクノロジーズでは、入力画面と出力帳票の開発を同時に行う開発プロセスを提唱する。

　「SVFX-Designer」は帳票の出力機能をデザインするツールだ。さまざまな帳票を自分でデザインし、それをプリントアウトしたり、PDF化するなどアウトプットを担う。カラーやグラデーション、図形などより美しく見えるようイメージ部分を強化しており、グラフィカルなデザイン帳票の作成に向いている。

　一方の「StraForm-X」は、帳票の入力画面を設計するためのツールだ。Webでさまざまなインプット画面を簡単に生成する。Excelなどで作成した既存のファイルなども、入力画面として利用できる利便性がある。帳票のシステム化といっても、1から何も作らなくても、あるものをそのまま再利用することができる。

　この2つのツールによる成果物をつなぐのが、「Design Converter」だ。これは「SVFX-Designer」で作った帳票出力画面と、「StraForm-X」の入力画面を変換することによる開発効率の向上を狙ったソフトウェアである。つまり、「SVFX-Designer」で作った帳票出力画面を入力画面として利用する、逆に「StraForm-X」で作った入力画面を出力画面として利用する、といったことが可能となるわけだ。

　もう少し詳しい使い方を解説すれば、「StraForm-X」の入力画面を出力用のフォーマットとして使う場合、例えば印刷のために微調整が必要になる場合がある。これを「SVFX-Designer」で行うというわけだ。

「SVFX-Designer」で作られた帳票出力画面を……（クリック >> 拡大）

「Design Converter」で変換

「StraForm-X」のデータになる。帳票の印字フィールドが入力画面の入力フィールドに自動変換されている（クリック >> 拡大）

　このソリューションで基本ツールとなるのは「StraForm-X」だが、必ずしも入力画面から出力帳票を作る、と決まっているわけではない。Webカルテなどのように入力と出力が1対1になっているケースでは、入力画面から出力画面を設計していくという流れが多いが、生保会社の「B to C帳票」の場合では出力シーンを想定してから入力画面の作成を行った方が分かりやすい。

　「SVFX-Designer」＋「StraForm-X」＋「Design Converter」の組み合わせの利点は、「画面デザインは1回行えばよい」というだけではない。ポイントは帳票デザインの資産化だ。

　「SVFX-Designer」と「StraForm-X」は、ホームページ作成ソフトを利用したことがあるエンドユーザーならすぐに利用できる。現実にいま、Excelの帳票を使っているのであれば、それを取り込むだけだ。あるいは、Aシステムで使っている画面をBシステムで使い回すといったことも可能になる。

　しかも帳票開発（作成）がコーディングレスになるため、「開発会社が作ったプログラムなので、変更ができない」ということが大幅に少なくなる。日常業務の中で新しい帳票を導入して新サービスをスタートする、画面レイアウトを修正して新しい機能を追加するという場合も“開発なし”にできるということもあり得る。場合によっては、システム部門ではなく、現場に帳票の変更を任せるといったことも考えられる。現場レベルでの対応が可能になれば、エンドユーザーは自分で努力すれば、自身の要求に対応できるということで満足度も高まるはずだ。

　ソフトウェア開発会社にとっても、帳票・画面作成にスキルや経験のレベルが異なる作業者を現場投入できるようになり、その分、プログラマをシステムの重要な部分に集中させることが可能となる。大量の帳票作成があるプロジェクトでも、アクティビティが単純化され、属人的制限から解放されるので、コストの計算が「人数×何カ月」で比較的クリアになるはずだ。また、カジュアルに帳票・画面作成ができるため、リアルな“ペーパープロトタイピング”としても活用できるだろう。

　帳票の“開発”をほとんどなくすことを究極の目標に作り上げた「Design Converter」。このツールができたことで、入出力の開発が一体化し、大胆な開発プロセス革新が可能となる。正しくプロセスを設計できれば、開発生産性が大幅にアップするはずだ。

　帳票の開発環境革新を目指すウイングアーク テクノロジーズ。この先のビジネスをリードしていくために、変化に柔軟に対応できる開発プロセスとツールをぜひ1度検討してほしい。