プロトタイピング手法の落とし穴
既に自社のシステム化を果たした経営者の中には、ベンダーからシステム構築の際に、実際の画面イメージを見せられ、その上でシステムの説明を受けた経験のある方もいらっしゃるのではないだろうか。
このような設計工程上の手法を、「プロトタイピング」という。そもそもは「雛形を使う」といった意味で、現在では主として、システム開発の画面設計を確定させるために用いられることが多い。その目的は、最初にユーザーとイメージのすり合わせをして無駄な作業を省き、コストを削減するところにある。手法としてはかなり以前から存在するが、特にWindowsの登場以来しばしば用いられるようになっている。
システム開発時、ベンダーは必ず設計書を作る。これは、画面・帳票・内部機能・データベース設計に大きく分類されるが、このうち内部機能やデータベース設計などは、専門家でもなければ内容を理解することは難しい。いきおい、エンドユーザーは直感的に理解できる画面や帳票に重点的に目が行くことになる。そして、画面イメージだけなら変更や修正も簡単に行なうことができる。
●背後の工程が見えないためにユーザーの要求がエスカレート
「ユーザーに画面イメージを見せる」というやり方は、確かにシステム化をスムーズにする一つの便法のように思える。ところが現実には、それこそがベンダーに大きな負担を与え、中小企業のシステム化を遅らせたりするのだから、皮肉なものである。どうしてそうなるのか。それはまさに「画面だけにユーザーの注意が向かう」からである。先にも述べたように、ツールを使えばこうした画面イメージの変更は簡単にできる。それを見たユーザーは「システムの変更も簡単なのだろう」と思い込んでしまうのだ。
だが、実際にその画面の変更が「動くシステム」として機能するためには、そのバックグラウンドにあるデータベースや入力項目のエラー制御、カーソル移動のコントロールなどに大幅な修正を施さなければならない。当然人的な負担も余計にかかり、コストだって増大する。しかし、最初に画面イメージが簡単に変更できることを見たユーザーは、仕様変更に伴う追加コストの支払いをなかなか認めない。
話を分かりやすくするために、一戸建ての家を新築する場合に置き換えてみよう。潤沢な建設資金が取れない中、建築家は既製の建築資材やマニュアル化された工法を採用することにより、コスト削減を狙った設計図を作る。ところが顧客はそれを見て、「やはりトイレはここに」とか「台所のレイアウトを変更したい」などと要望を出してくるとしよう。
その要求を設計図に反映させることは簡単だ。だが、もし本当にその通りに作るとなれば、配管・配線を変更したり、場合によっては基礎工事そのものから作り直さねばならなくなる場合もある。時間もかかり、コストもかさむ。おそらく住宅ならば「ここを変更すると、これだけコストが増大しますよ」という話は通りやすいだろう。何といっても身近な耐久消費財だし、どんな資材を使っているか、どれだけ工数が増すかといったことは「目に見える」からだ。
ところが、これがシステム構築となるとそうはいかない。大部分の人にとっては、実際にSEがどんな仕事をしているかなど知るはずもなく、だから画面が簡単に変更できるのと同じ気安さで、システムの変更を要求してくる。たった1ヵ所の画面修正が、システムの設計思想まで覆すことになる場合もあるのに…。それは先の建築の例でいうと、一度掘った穴を埋めて掘り直すのと同じことなのだ。変更を実地に反映させることの大変さは、システム構築という現場でも同じなのである。
●ベンダーとユーザーの相互理解がなければ、中小企業のIT化は進まない
そもそも、中小企業の開発案件は100万円程度かそれ以下の小ぶりなものが多い。だからベンダーはプロトタイピングで効率的に話を進めようとするのだが、これがかえって墓穴を掘っている。システム構築の場合は、様々な要素が複雑にからみあっている中に何とか妥協点を見つけてやりくりするわけだから、修正コストは単純に穴を掘るのとは比較にならない額にもなる。現に私は、プロトタイピングを使って開発を進めた結果顧客の要求が増大し、追加コストの支払いにも応じてもらえずに当初の3倍くらいの原価がかかってしまい、ほとんど利益にならなかったというベンダーの例を知っている。これでは全くもって本末転倒である。
特に昨今は、優れたユーザーインタフェース機能を持ったパッケージソフトが多く出回っていて、このこともユーザーの「わがまま」がエスカレートする一因となっている。というのも、そういうソフトに慣れたユーザーは、これから作るシステムにもそれと同じだけのクオリティーを要求しがちだからだ。しかしそうした製品は、実は何億円という開発研究費をかけて開発されたものであり、大量のパッケージを売ることによって開発費を回収する。そもそもシステム開発の発想が違っているのだ。
システムにとって本当に大切なのは、GUI（グラフィック・ユーザー・インタフェース）の見栄えより、「きちんとした業務フロー」を踏まえ、「正しく入力」した情報が「正しく出力」されることであるはずだ。企業経営者は、システムの本質を理解することが絶対に必要である。何もプログラムを書けとはいわないが、どういうステップでシステムが書かれ、どういう仕組みで動くのか、おぼろげながら知っておいてもらいたい。そのことを承知せずに、GUIだけにこだわるのは、システム化の本質を見失いかねない愚行といえる（気持ちは分からないでもないが）。そして本質を見失ったままドタバタで構築されたシステムは、どこかに綻びがあることは目に見えている。
ベンダー側は、面倒くさいからといって、充分な説明やコミュニケーションを図らないまま、ユーザー受けだけをねらってプロトタイピングを行なうべきではない。なぜこの手法を採っているのか、画面変更と実際のシステムがどのように影響しあっているかを伝える努力が必要である。少々ユーザーに煙たがられてもやむを得ない。完成したシステムがきちんと稼働すれば、最終的にユーザーは評価してくれる。結果的に、以後のユーザーとの関係強化にもつながるのだ。
ベンダーとユーザーが相手の立場を理解しつつ、システムの本質の部分できちんとせめぎ合うこと…それなしにこの悪循環を断ち切る方法はあり得ないだろうと私は思う。
(本記事は、「SmallBiz（スモールビズ）※」に寄稿したコラム「近藤昇の『こうして起こせ、社内情報革命』」に、「第35回 プロトタイピング手法の落とし穴」として、2002年10月21日に掲載されたものです。）
※日経ＢＰ社が2001年から2004年まで運営していた中堅・中小企業向け情報サイト