システム開発におけるユーザーニーズは絶対か？：システム部門Q＆A（16）（3/3 ページ）

[木暮 仁，＠IT]

ユーザーに費用のメカニズムを教えよう

　これまで、ユーザーニーズへの疑問を列挙してきましたが、それでも、ユーザーニーズをよく理解し、それに合致させることが重要であることはいうまでもありません。そうなると、ユーザーに適切なニーズを出させることが必要になります。それには多様な対処がありますが、ここでは費用の観点で考察します。

　ユーザーニーズを適切なものにするために、ユーザーに情報システムの開発や保守改訂における費用のメカニズムを理解させる必要があります。次に挙げた事項は当然のことで、ユーザーも常識的には理解しているのですが、深刻な問題だとは受け取っていないのです。

1．情報システム規模と費用の関係

　 情報システムの規模が大きくなると、開発や保守改訂の工数は指数的に増大することを理解させましょう。特に保守改訂では、どのプログラムを直せばよいのか、直したときに副作用はないかの確認に労力が掛かります。それはプログラム数の組み合わせの数に比例するので、規模が大きくなると極端に大変になります。

　先にも示したように、情報システムの規模は単純には要求の個数に関係します。「あったらいいな」レベルの要求が、どれほど大きな悪影響を及ぼすのかを理解させることが必要です。

　そもそも、このような要求の多くは、情報検索系システムとしてEUC（End User Computing）で対処すべきなのです。個々の帳票ではなく、どのような項目をデータベースに入れるかを要求にすればよいのです。

2．リアルタイムによる費用の増加

　ユーザーはとかく過剰機能を要求しますが、それが費用を非常に増加させていることに気付いていません。その典型的な例がデータのリアルタイム性です。

　情報の中には、現在の状況をリアルタイムで知ることが必要なものと、数時間前あるいは前日の状況で良いもの、さらには先週や先月で十分なものがあります。

　ユーザーはとかくリアルタイムを要求しがちです。ところが、リアルタイムを実現するには、データの収集方法やデータベースの管理方法など、非常に費用が掛かる機能が必要になります。しかも、1つの業務をリアルタイムにするために、ほかの業務までそうしなければならないことも生じます。さらに、リアルタイムで情報を得ても、リアルタイムに対処ができないのであれば意味がありません。

　また、ユーザーの要求が「欲しいときにリアルタイムで情報が得られる」ことと、「リアルタイムの情報が欲しい」ことを混同しており、それを情報システム部門が誤解して過剰な情報システムにしてしまうこともよくあることです。

3．手戻りによる費用

　家を建てるのに、上棟式のころになってから間取りの変更をしたら、基礎からやり直さなければならないように、情報システムの開発でも要求分析の段階で気付かなかったのが、実施段階になってから気付いて変更したりすると、莫大な費用と時間がかかります。「要求分析での5分は、プログラミング段階の1カ月、実施以後の1年」といわれます。これがユーザーには分かっていないことが多いのです。

　手戻りが起こる原因にはいろいろとありますが、どの場合もユーザーニーズが不明確なことに起因しています。

・例外処理

　通常の1万件はAの処理をするが、たまに1件は例外的にBの処理をするという場合、情報システムでは、事前にAとBの両方をプログラミングしておかなければなりません。しかも、Bの方が複雑なことが多いのです。ところが実務では1万件のAだけを教えておき、たまたまBが発生したときに初めてBを教えるのが一般的でしょう。そのような慣習があるために、ユーザーは事前にBがあることに気付かないか、ささいなことだと思っているのですね。

・全体との関連

　情報システムでは、全体が連携しています。販売部門が売り上げシステムでの返品処理を変更したら、会計システムで大きなトラブルが生じるというように、ちょっとした変更が、関係ないと思っている他部門に大きな影響を与えます。このようなことを、要求分析の段階で調査確認することが重要なのですが、とかくユーザーは自分が担当している分野以外のことには関心がありません。

・状況の変化

　トラック運行を合理化する流通システムを構築したのに、多数のトラック業者との調整ができなかったとか、顧客管理のための自社カードシステムを構築したのに、顧客属性のような個人情報を求めると会員が増やせないというように、情報システムの構築がかなり進んだころになって、当初目的としたデータが得られないとか、目的が変わってしまうことがよくあります。これは、ユーザー部門が情報システム以外の活動のマネジメントを適切に行っていないことに起因します。

4．バベルの塔による費用増加

　 社内の実業務は、厳密に用語や概念を定義しなくても遂行できます。倉庫を出荷基地やデポといっても同じものだと理解するでしょう。売り上げ、配送、出荷、転送などを混同して用いても、どうしたのかは状況から判断できます。ところが、情報システムではこのような類似語の混同は大きな問題になります。

　情報システムの開発では、ベンダが業務担当者にヒアリングをします。Aは「倉庫へ配送する」といい、Bは「出荷基地から出荷する」と、Cは「デポへ転送する」といったとき、当社の業務や用語を知らないベンダは、これがすべて同じことだと理解するでしょうか？ 案外、このようなつまらないことのためにベンダにカネを払っているのです。

　これは社内でも同じです。情報システム部門は情報システムでの定義どおり、「出荷とは、得意先へ自社倉庫から商品を出すこと」「配送とは、自社倉庫だけでなく他社からも商品を出すこと」「転送とは、自社倉庫間で商品を移動すること」と信じています。ところが甲支店では、「出荷とは得意先あてでも自社倉庫あてでも、ともかく商品を出すこと」と日常的に使っているとします。甲支店からの要求に情報システム部門は正確に応えられるでしょうか？

　さらに、甲支店の担当者がEUCで「○○倉庫の出荷実績」を出したら、現実と違う情報が出てきたので「コンピュータなんか、当てにならない」と思うのではないでしょうか？ 「コンピュータ用語を使うな。業務日常語で話せ」とよくいわれますが、それ以前に、業務日常語の統一をすることが重要なのです。

まとめ

ユーザーニーズを理解して、それに合致する情報システムを作ることが重要なことは当然であるが、ユーザーすら将来的なニーズは分かっていないのだ。

ユーザーの過剰要求により、情報システムが大規模化、複雑化することが多い。

それでユーザーニーズを金科玉条として、がんじがらめなシステムを構築するべきではない。保守改訂が容易なシステムにすることが肝心だ。

それには、システム規模を小さくすることが効果的である。情報検索系システムを普及することにより、規模を小さくできる。

ユーザーに、費用が掛かるメカニズムを教えよう。それを理解することにより、費用増加が抑えられるし、良いシステムになるのだ。

この記事に対するご意見をお寄せください　[e-mail]

筆者プロフィール

木暮 仁（こぐれ ひとし）

東京生まれ。東京工業大学卒業。コスモ石油、コスモコンピュータセンター、東京経営短期大学教授を経て、現在フリー。情報関連資格は技術士（情報工学）、中小企業診断士、ITコーディネータ、システム監査、ISMS審査員補など。経営と情報の関係につき、経営側・提供側・利用側からタテマエとホンネの双方からの検討に興味を持ち、執筆、講演、大学非常勤講師などをしている。著書は「教科書 情報と社会」「情報システム部門再入門」（ともに日科技連出版社）など多数。http://www.kogures.com/hitoshi/にて、大学での授業テキストや講演の内容などを公開している