Loading
|
|
|
Loading
|
| ＠IT > システム品質を向上する開発プロセス革新 |
 |
企業の情報システムを作るには、ユーザーの要求を分析・定義して、仕様を確定するという作業が不可欠だ。要求や仕様を表現する方法はいろいろと提唱されてきたが、現実の開発プロジェクトで最もよく使われているのが「画面」や「帳票」である。 DFDやERD、UMLなどの各種モデリング手法をきちんと使ったプロジェクトであっても、画面イメージが1点も提示されない──ということはほとんどないはずだ。かなりの規模のシステム開発でも、開発側がユーザーに対して画面や帳票イメージしか提出しないというケースも珍しいことではない。 これというのも、ITに詳しくないユーザーにとって画面／帳票だけが“見える”ものであり、実際に業務に登場する“実体”だからだ。勢い、ユーザーの興味は画面／帳票に集中する。 WebサイトやWebアプリの場合、HTMLで書かれたプロトタイプ画面が作られることも多いだろうし、少なくとも紙に書いたペーパープロトタイプは作成されるだろう。これらのプロトタイプ画面を叩き台にしてシステムの仕様を確定していくことになる。 一方、帳票は既存の業務の中で使われているものが示されて、「これを出力できるようにしてほしい」などと注文される。帳票からシステムの要件を読み解く作業を帳票分析というが、開発エンジニアは、業務における伝票の流れからデータフローを導き出したり、帳票の項目からデータ構造を抽出してデータベースのデータモデルを設計したりするのである。 このように企業の情報システム開発において、画面や帳票が最初に検討され、これに基づいてシステムの発注がなされる場合が非常に多い。いわば、画面や帳票が「仕様書」の役割を果たしているのである。
こうしたプロジェクトでは、最初に画面や帳票のプロトタイプで合意を得て、次に本体システムの設計・開発を進め、それに合わせて画面や帳票の開発を行う──というのが一般的な流れだろう。しかし、プロトタイプによる合意はあくまでも「だいたい、この方向で」ということを確認しただけに過ぎないことが多い。このため、プロジェクトが進む中でユーザーから「桁数を増やしてほしい」「罫線を太く」「ボタンを見やすい位置に」と細かい注文が入ることになる。 しかし最初にプロトタイプを作った担当者が、開発フェイズでもそのまま担当になるとは限らない。Webアプリなどでは、デザイナーが作った手組みのHTMLファイルをプログラマが解析して、システムから自動出力するようにしたり、PHPなどで書き直したりという方法で開発が進められるかもしれない。つまり、最初にユーザーの要望を受けて、その目的や狙いをよく知っている人間とは別の開発者がプログラミングや修正の実作業を行うということになるのだ。 帳票の場合は、最初に帳票を受け取って帳票分析を行うのは本体システムのシステムアーキテクトやデータベース設計者だ。まず、彼らが帳票に基づいて本体システムの基本設計を行う。その作業が終わってから帳票出力システムが設計・開発され、そのテスト段階になってからようやく帳票出力サンプルがユーザーに提出される。開発した帳票フォームに“ダメ出し”がされるとしても、プロジェクトの後半になってからなのだ。
しかも帳票の場合、問題になってくるのはプログラミングの難易度ではなく、作成数が膨大であることだ。取引先ごとにすべて異なる指定伝票が必要という要件ならば、その会社の取引先の数だけ伝票フォームを作らなければならない。プロジェクトの終盤になってから数百から数千の帳票を作り直しということになれば、プロジェクトのデスマーチ化※は避けられない。
こうした問題に対処するには、本体システムの開発プロセスとは別に、画面／帳票の制作だけを取り出し、その担当者が一貫したプロセスでユーザーと密なコミュニケーションを取れる環境を作ることだ。ユーザーはプロトタイプが次第に精緻になって、システムとして納品されると思っているのだから、その期待に応えられるプロジェクト体制を作るのが自然というものだろう。 むろん、そのためにはシステム全体が本体システム（ビジネスロジック）と入出力（画面／帳票）に分離されていなければならない。これは今日のエンタープライズシステムではごく一般的なアーキテクチャであり、こうした規模のシステム開発ならば、ビジネスロジックを担当する開発者と入出力を担当する開発者がそれぞれに存在するのは珍しくない。 しかし、このような複数の担当者が参加するプロジェクトでは、画面系と帳票系でも担当者が別々になることも多い。画面と帳票では開発要件が違うため、使用言語から異なるというのも当たり前、別々の開発者がアサインされるのも普通のことだ。 こうした体制で作られた業務システムではデータ入力画面と印刷出力帳票のデザインがまったく別ということが珍しくなかった。Webアプリならば、社内の入力者向けには簡易なHTMLのエントリページが用意され、そこからデータをデータベースにポストする。サブシステムとして独立して構築された伝票発行システムは、データベースから該当データを参照して伝票を発行する──こうした作りのシステムが多かったのではないだろうか？ しかし、ユーザーがデータ入力画面と印刷出力帳票のデザインが別々であることを望んでいるとは思えない。入力画面とプリントアウトが同じレイアウトになっている方が分りやすいに決まっている。開発側の都合をユーザーに押し付けているだけなのだ。
これらの問題に対して、具体的なソリューションはあるのだろうか？ 帳票開発ツールで知られるウイングアーク テクノロジーズの田中潤氏は、入力画面と出力帳票の開発を一貫かつ同時に行う開発プロセスを提唱する。 プログラミング言語や開発環境を使えば、確かにユーザーのどのような要求にも柔軟に対応できる。しかし、企業の情報システムのユーザーインターフェイスは、すでに一定のパターンが定まっており、高度なプログラミングが必要とされることはほとんどない。誰でも使える画面／帳票開発の専用ツールを使って、開発（作成）生産性を高めることが得策だといえる。 ウイングアーク テクノロジーズの「StraForm-X」と「SVFX-Designer」は、ノンプログラミングで画面／帳票を開発するツールである。 「StraForm-X」は、入力画面を設計するためのツールで、Webシステムで利用可能なインプット画面を簡単に生成することができる。Excelなどで作成した既存のファイルを取り込んで、入力画面化する機能もある。
「SVFX-Designer」は、帳票の出力機能をデザインするツールだ。カラーやグラデーション、図形などがより美しく見えるようイメージ機能が強化され、グラフィカルなデザイン帳票の作成にも対応する。
プログラマではなく、デザインやUI設計を得意とする人々にこうしたツールを使ってもらうことで、より一層ユーザーセントリック（利用者中心）なUIが作れるはずだ。そして、これらのツールを導入することで、画面／帳票開発のプロセスを本体プログラムの開発と並行したサブプロジェクトとして独立させ、これまでバラバラだった画面と帳票のデザインを同じ担当者・チームが一貫して取り組めるような体制を作り出せるのである。
これを支援するのが、ウイングアーク テクノロジーズの新製品「Design Converter」である。これは「SVFX-Designer」で作った帳票出力画面と、「StraForm-X」の入力画面を相互にデータ変換するソフトウェアだ。すなわち、「SVFX-Designer」で作った帳票出力画面を入力画面として利用したり、「StraForm-X」で作った入力画面を出力画面として利用したりできるのである。 これらを使った開発プロセスを考えてみよう。例えば、業務の現場で使われている帳票をユーザーから受け取ったとする。これを、まずは「SVFX-Designer」でデジタルフォーム化する。もちろん「帳票に新たにバーコードを付加してほしい」といった要望があれば、それを受け入れながら完成度を高めていく。このとき、同じ制作者が「SVFX-Designer」を並行利用して、その帳票で使うデータを入力する画面も担当すれば、出力帳票作成の知見とフォームデータを生かして、入力画面を効率的に作成できるだろう。
帳票や画面といったエンドユーザーに最も近いソフトウェア部品を作るに当たり、ユーザーと緊密に連絡・確認を取りながら、開発を進ちょくできるというのは大きなメリットだ。「入力と出力は、基本的に同じデザインにしよう」ということになれば、「SVFX-Designer」で作った出力帳票フォームを「Design Converter」でコンバートして「StraForm-X」に取り込み、微調整すればよい。入力画面を作っていく中で発生した変更を出力帳票にフィードバックすることも簡単だ。 「SVFX-Designer」＋「StraForm-X」＋「Design Converter」の組み合わせは、画面／帳票デザインの資産化を可能にする。これは画面／帳票作成の生産性の向上に加えて、その品質維持・向上にも役立つ。 例えば、デザインの専門家が作った雛型、あるいは現場で実際に使われて評判のよいレイアウトなどを使い回すことができるので、高度なデザインスキルのない作成者でも、ある程度の成果物を作ることが可能となる。また、「SVFX-Designer」や「StraForm-X」の使用にプログラミングスキルは不要なので、大量の帳票を作成しなければならないプロジェクトでは、一時的に単純作業者を大量投入して難局を乗り越えるということも可能だろう。 ソフトウェア開発会社にとって希少資源であるプログラマには“開発”に集中してもらい、画面／帳票の作成は別の担当者が“デザイン”として注力する体制を確立することで、開発するシステム全体の質が向上するはずだ。エンドユーザーの満足度が高まることは間違いない。 ウイングアーク テクノロジーズが提唱する画面／帳票の開発環境革新──。「Design Converter」を活用して入出力の開発を一体化することで、ユーザーセントリックなシステムの実現に道が開ける。ぜひ一度、真剣に検討してみてほしい。
提供：ウイングアーク テクノロジーズ 株式会社 企画：アイティメディア 営業局 制作：＠IT 編集部 掲載内容有効期限：2007年6月30日 |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
