なぜ、オーダーメードソフトは肥大してしまうのか？
＜要約＞中堅・中小企業の現場では、依然としてオーダーメードソフトの需要が高い。ところが、結果的に異常に肥大したソフトが納入されがちだ。ソフトの肥大化は、無駄な人月数が注ぎ込まれ、結果的に使い勝手の悪いソフトが納入されたという点で、ユーザーにとってもソフトウエア会社にとっても不幸な事態である。相応の予算をかけてこうした結末を招かないために、どういうポイントに気をつけるべきかを、私が過去に遭遇した失敗事例からいくつかピックアップしてみよう。
最近の中堅・中小企業のソフトウエア活用の現場では、ひと昔前のオフコン全盛時代とは様変わりし、パソコン上で使用することを前提に、リーズナブルな価格で機能豊富なパッケージソフトやASP（Application Service Provider：有償で使用するオンラインソフト）の利用が増えている。これは、ユーザーのIT関連費用の節減とITの浸透に大いに貢献しており、望ましい傾向ではある。しかし、まだまだ現場ではオーダーメードに対するニーズは強いし、現実に、日々どこかでオーダーメードによるシステム構築プロジェクトが動いていることだろう。
中堅・中小企業クラスの基幹業務系のシステムや、汎用的な顧客管理システムなどは、パッケージを使うことがおすすめである。しかし、特殊なノウハウを含んだ業務系ソフトの開発や、その企業特有の事業ノウハウと連動するソフトウエアの開発が、時として必要になるのも事実だ。
以前のコラムで、ソフトウエア構築は建築物の構築に比べて考えてみると分かりやすいと述べた。お施主さんと請負業者のやり取りや工程管理などはかなり共通する面があるが、具体的な形が目に見えにくいソフトウエア開発は、お施主さんとのコミュニケーションが遙かに難しい。事の大小はあれ、トラブルはつきものなのだ。
●肥大したソフトは、コミュニケーション不足の象徴
トラブルの原因はケースバイケースだ。しかし、どの失敗事例にも共通して言えるのは、当初の想定よりソフトウエアの機能が大きく膨らんだという結果がついてまわることだ。それを“ソフトの肥大化”と呼ぶことにしよう。そもそもユーザーが欲しがっていた機能と全くかけ離れたソフトができてしまったというケースも稀にはあるが、そこまでくると民事訴訟問題ものなので、今回は取り上げない。
ソフトの肥大化は、無駄な人月数が注ぎ込まれ、結果的に使い勝手の悪いソフトが納入されたという点で、ユーザーにとってもソフトウエア会社にとっても不幸な事態である。相応の予算をかけてオーダーメード開発を選択した結果が不幸な結末とならないために、どういうポイントに気をつけるべきかを、私が過去に遭遇した失敗事例からいくつかピックアップしてみよう。
ソフトの肥大化の顧客企業側の原因は、概ね次の6つの要素が考えられる。
（1）GUI（ユーザーインタフェース）へのこだわりすぎ
（2）帳票体裁へのこだわりすぎ
（3）めったに使わない機能まで自動化しようとしすぎ
（4）簡単に仕様を変更できると思いすぎ
（5）やり方を変えようとしなさすぎ
（6）打合わせのスキルが低すぎ（これはユーザーと業者双方の問題！）
（5）（6）については今までのコラムでも何回か触れているので、今回は詳細には説明しない。
●ユーザーにやんわりと“気付き”を促す
まずは、（1）のGUIへのこだわりすぎについてであるが、こういうケースが体験上多いようだ。
一つには、例えば、システムのリプレースを行った際などに多いのだが、今まで使っていたコンピューターの操作性をそのまま踏襲して欲しいとの要望である。オフコンをパソコンにリプレースする際には、この点が特に問題になりがちだ。具体的に言うと、マウス操作はあまり使わずに、キーボードだけで操作ができるようにしてほしいという要望に出くわすことがある。ユーザーの気持ちはよく分かる。現場の人が慣れ親しんだ操作性をそのまま引き継いだほうが、現場が混乱せずにすむということだろう。
それだけに、一概に“わがまま”だと斬って捨てる気はないが、これはマニュアル操作の車に慣れ親しんだ人が、オートマチック車はいやだと言っているようなものだ。これは、ちょっとした慣れの問題であり、パソコンの基本的操作の習熟には、最初は少々骨が折れてでも、この際積極的に取り組んでほしいところだ。今どきマウスレスのシステムを使うのであれば、そもそもWindowsなど使わなければよいのである。昔は、マウスレスのDOSというOSでも、それなりに仕事に役立つソフトウエアが動いていたのだから…。
もう一つの事例は、パッケージソフトと同等のGUIを求めるケース。この問題については既に指摘したことがあるが、何億円も投下した製品の操作性と同等の機能を求めるのは無理というものである。どうしてもその点にこだわるのなら、パッケージを使うべきだ。人間工学の領域まで考慮したインターフェースの設計が望ましいのは議論の余地がないが、あまりに属人的な好みに合わせて画面の操作性に手を加えるのは、本来のソフトウエア開発の目的から外れてしまいかねない。
（2）については、ある人から聞いた話しであるが、帳票のフォームや体裁の細かなところまでこだわるのは、どうも日本人だけらしい。欧米では、中身、つまりそこに正しい数字やデータが印字されているかどうかが全てであるらしい。もっとも、きれいな帳票が営業現場で好印象を与える国民性までは、一気に変えられないのも事実。現実的な提案としては、「帳票へのこだわりはほどほどに」「これは企業の競争力とはあまり関係のないところ。平均点が取れていれば満足すべし」といったところか。
（3）については、一年に一回しか使わないような機能をシステム化する際には、ソロバンを片手によく考えてみることである。例えば、システムの耐用年数を仮に5年とした場合、その作業を手作業でするのに一日かかるとして、5年間で3万円＊5＝15万円ポッキリ。システムで自動化するのにかかるコストが50万円だったとしたら、どちらがオトクかよーく考えてみたいところ。意外と見落としがちなポイントなのだ。
最後に、（4）の簡単に修正できると思いすぎという問題もソフトウエア開発の現場では後を絶たない。スコップで穴を掘る作業をイメージしながら考えてみると分かりやすい。業者に指定した場所に穴を掘ってもらったが、再度検証した結果、横に3メートルずれた場所に掘るべきだという結論になったとしよう。普通は、最初の穴を埋めてから新たに穴を掘るはずだ。つまり、最初の穴を掘って埋める作業にかかる人件費については、本来は依頼主が負担するしかないのだ。ソフト開発を、この喩えとまったく同じだと言っているのではない。しかし、ソフト開発のプロセスぐらい、ユーザーから見てわかりにくいものはない。仕様変更の際に、それまでに堀った穴を埋める作業は、確実になんらかのツケとなって現れることは頭に入れておくべきだ。
ソフトが肥大化していくことは、ユーザー側、ソフトウエア企業側ともに、余計なストレスと折衝とコストが発生する。今回指摘した落とし穴について、ユーザーに理解を深めていただくのが最良なのだが、少なくともソフトウエア会社が、こうした点に気を付けながら、ユーザーにやんわりと気付きを促し、歩み寄るところは互いに歩み寄るという雰囲気を演出してほしいものである。
(本記事は、「SmallBiz（スモールビズ）※」に寄稿したコラム「近藤昇の『こうして起こせ、社内情報革命』」に、「第55回 なぜ、オーダーメードソフトは肥大してしまうのか？」として、2003年8月1日に掲載されたものです。）
※日経ＢＰ社が2001年から2004年まで運営していた中堅・中小企業向け情報サイト