目の前の果実を捨て、将来の果実を取る 小川 誉久 2004/02/11

　オフコン・メーカーにいたとき、コンピュータ・トレードショー向けのデモ環境設置の応援要員として、展示ブースの設営に立ち会ったことがある。といっても実際には筆者はまだ駆け出しの新入社員で、先輩エンジニアによる設定作業を横から眺めていただけであるが。

　この展示ブース、客としてショーを見て回る分には、いずれもきらびやかでずいぶんと立派に見えるものだ。しかし関係者として設営に立ち会ってみると、あまりにインスタントに出来上がるのに驚かされる。会場設営のプロによる手際よい仕事ぶりがその理由の1つであることは間違いないが、それにしても小1時間もあればブースがあらかた出来上がる様を目の当たりにすると、本当にマジックでも見ているような気になる。

　しかし外からは立派に見えるブースも、裏に回れば文字通り張子の虎で、ベニア材などがそのままの姿を見せている。逆にいえば、張子の虎だから手早く設営できるわけだ（ちなみに、ショーが終わった後の撤収のスピードも速い）。

■

　昨年末、ある仕事でご一緒しているパッケージ・ソフト会社が、業容拡大のため既存のソフト販売用営業支援システムを刷新することになった。誰かよい受託開発会社を知らないかと聞かれたので、大学の同級生が経営している会社を紹介した。このパッケージ・ソフト会社はまだ設立して間もないところで、それまではOfficeアプリケーションのAccessを利用し、現場の営業担当者が適当な入力フォームを設計して営業管理に使っていた。しかし販売も順調に伸びて、スタンドアロンでしか使えないAccessではいよいよ限界を迎えたため、これを機にデータベース・システムをSQL Serverに移行し、操作用のフロントエンド・アプリケーションを作成して、複数の端末からデータにアクセスできるようにしようというのだ。

　筆者はこの業務システム開発に直接にタッチするわけではないが、友人を紹介したという都合上と後学のためという思いもあって、オブザーバー的に打ち合わせに参加させてもらった。

　それまで使っていたAccessベースのシステムは、営業担当者の経験を基に、フォーム設計とデータベース設計を同時並行的に行ったようなものだった。身近にあるアプリケーションのカスタマイズ機能を使って、取りあえず必要なデータを定義し、それを操作するためのフォームをトライ＆エラーで設計するというのは、この手の業務アプリケーションの出発点としてはありがちなものだ。筆者は入力フォームをざっと見ただけだが、エンジニアではない営業担当者が作成したものとしてはかなり本格的で立派なものだったと思う。

　このパッケージ・ソフト会社は、販社を通じてのみ製品を販売している。販売している製品も1種類しかないし、営業支援といってもそれほど複雑ではないだろうと打ち合わせ前は高をくくっていた。しかしいざ話を聞いてみると、販社や販社の担当者、顧客に応じてイレギュラーな処理が非常に多い。例えばある販社は、製品が売れたことだけ連絡してくるので、製品パッケージは知らされた顧客に直接郵送しなければならない。かと思えば別の販社は、顧客は自分たちの財産なのだから、直接製品を郵送してもらっては困るという。このソフト製品は最新情報をインターネットから提供する、ちょうどウイルス対策ソフトと同じ形式のソフトであり、基本的には1年間の契約ライセンス販売になる。しかし顧客によっては、年度をまたいだ契約はできないから月割り料金にせよという。万事この調子だ。

　こうしたイレギュラーに遭遇するたび、これまでは営業担当者がAccessのデータベースを変更し、入力フォームを変更し、あるいは運用でしのいできた。しかしその結果出来上がったものは、紆余曲折した歴史的経緯を知った担当者しか使えないアプリケーションであった。これ以上の拡張は限界に達していたわけだ。

■

　どうしてこうなってしまうのか。簡単にいえば、変化の影響を直接受けるフォーム＝ユーザー・インターフェイスを基点としてアプリケーションを開発したからだろう。RAD（Rapid Application Development）を安易に利用した業務アプリケーション開発の例といってもよいと思う。

　フォーム・デザインは直接エンド・ユーザーの目に触れるものなので、注文をつけやすく仕上がりも確認しやすい。誤解を恐れずにいえば、コンピュータやソフトウェア開発の知識などがあまりないエンド・ユーザーでも、あれこれ口を出しやすく、出来上がったものに文句もいいやすいということだ。プログラマの立場からすれば、フォーム・デザインのレベルでエンド・ユーザーの希望を一通り満たす状態にしておき、後は求められている要件をプログラムで実装すれば、ユーザーが希望する業務アプリケーションを手っ取り早く、しかも安価に開発できる。

　しかしこの方法は、エンド・ユーザーのビジネス環境を分析して、さまざまな構成要因を積み上げたものではない。ある時点のある場面を切ってみたら、切り口がその入力フォームだったというだけだ。設計した当初の状態でずっと使い続けるなら問題はないのだが、変化に合わせて改良や拡張を行おうとすると簡単に破綻してしまう。そして残念なことに、ビジネスを取り巻く環境の変化は時とともに加速を続けている。

　人間の許容力にまかせて運用でカバーすることもある程度はできるが、それにも限界がある。あるときから、それまでのアプリケーションをゴミ箱に捨てて、一から作り直す羽目になる。悪くいえば使い捨てのアプリケーション開発だ。外面を最優先にして、急場しのぎ的に使えるものを作る。どことなく急場作りの展示会ブースとダブって見えるのは筆者だけだろうか。

■

　今回筆者が目にしたのはAccessベースの業務アプリケーションだったが、Visual Basicを利用した、いわゆる2階層のC/S（クライアント／サーバ）アプリケーションの多くが、同じような問題に直面しているのではないかと思う。

　自分は専門家ではないし、不勉強な身で偉そうなことをいえる立場ではないのだが、こうした問題を解決する手段の1つがオブジェクト指向分析（Object Oriented Analysis：OOA）／オブジェクト指向設計（Object Oriented Design：OOD）なのではないかと感じている。オブジェクト指向分析・設計では、変化の影響をもろに受けるユーザー・インターフェイスを基点にするのではなく、例えば「顧客」や「製品」「在庫」など、業務を構成する本来の単位を基に業務を分析して、それらの係わりをシステム化していく。フォーム設計はその後だ。

　このため構成要素自体が大きく変わらなければ、それらのかかわり方にバリエーションを付けることは比較的たやすく、それまでに開発したソフトウェアも再利用できる可能性が高まる。逆にいえば、より柔軟で、再利用性の高いオブジェクトを構成できるかどうかが開発者に問われるところだろう。

　オブジェクト指向分析・設計が魔法の杖だとは思わない。しかしフォーム設計主導のアプリケーション開発の問題を解決してくれる手段にはなりそうだ。少なくとも試してみる価値はあるだろう。

　ただいくつか問題がある。新しい試みには何事にもオーバーヘッドがある。プログラマは、いままで培ってきたアプローチをいったん忘れて、経験のないOOA／OODのアプローチを学ばねばならない。

　また専門知識の乏しいエンド・ユーザーから見れば、最終的にはシステム内部に組み込まれて見えなくなる業務の構成要素を丹念に洗い出し、それらを組み立てるという根気のいる作業に付き合わなければならない。業務を一番知っていて、ITによる生産性向上のポイントを一番知っているのもエンド・ユーザーだからだ。そしてより重要なことに、こうしたオーバーヘッドには時間的、金銭的コストが伴う。

　プログラマにせよ、エンド・ユーザーにせよ、慣れ親しんだアプローチは手っ取り早く安上がりだ。しかしそればかりに近視眼的に固執すれば、目の前の果実は取れるかもしれないが、もっと大きな将来の果実を失いかねない。

　打ち合わせのやりとりを聞きながら、そんなことを考えた。

小川　誉久（おがわ　よしひさ）
株式会社デジタルアドバンテージ 代表取締役。東京農工大学 工学部 材料システム工学科卒。'86年 カシオ計算機株式会社 入社、オフコン向けのBASICインタープリタの開発、Cコンパイラのメンテナンスなどを行う。'89年 株式会社アスキー 出版局 第一書籍編集部入社、書籍編集者を経て、月刊スーパーアスキーの創刊に参画。'94年月刊スーパーアスキー デスク、'95年 同副編集長、'97年 同編集長に就任。'98年 月刊スーパーアスキーの休刊を機に株式会社アスキーを退職、デジタルアドバンテージを設立した。現Windows Server Insiderエディター。

「Opinion」