ユーザーニーズを基にシステムを作るな情マネ流マーフィーの法則(31)

システム部門がシステムを構築する際、ユーザーの業務を理解し、的確にユーザーニーズを満たすことが重要だと言われている。しかし、ユーザーは往々にして自分のニーズを理解していないことが多いのだ。今回はユーザーニーズに関する法則を紹介する。

» 2010年11月18日 12時00分 公開
[木暮 仁,@IT]

 システム構築では、ユーザーニーズを満足させることが必要だと言われている。ところが、そのユーザーニーズが曲者なのだ。

情マネ流マーフィーの法則その175

ユーザーニーズは偶然により決定される


 ITベンダは「経営者の“想い”を実現すること」をウリにしている。

 そして、経営者の“想い”は明確だ。もうけたいのだ。

 しかし、その“想い”はただの願望であり、具体的なビジネスモデルになっていない。そこでITベンダが協力するのだが、ITベンダがユーザー企業の事業分野でもうける方法を知らないのは当然だ。

 “想い”は暗黙知である。暗黙知を正しく形式知に変換できる経営者は少ない。「例えば」の前提付きで「在庫が多過ぎる」と発言すれば、「在庫の削減」が重要な要件になる。

 また、コンサルタントがたまたま昨日雑誌で読んだことを思い出して、「流通の合理化は必要ですか」と質問すれば、それが特に重要ではなくても「まあ必要だね」と答える。これにより「流通合理化」が重要な要件となる。逆に、この対談でたまたま話題に上がらなかった生産分野は要件にはならない。

 ITベンダは、この対談によって得た「在庫削減」と「流通合理化」だけを絶対的な要件だとして、美しい図表を盛り込んだ文書を提出して確認を求める。経営者は、確かに話題になったことだし、この文書は論理的に正しいのだから、正しいと答える。これが「もうけること」に最適な方法なのか、これを実現する情報システムが構築されれば本当にもうかるのかを確認したのではないのだが、これが経営者の方針だとされるのである。

情マネ流マーフィーの法則その176

ユーザーニーズはシステム要件に変換する段階で矮小化される


 前回指摘した「経営戦略はIT戦略にブレークダウンするプロセスで矮小化される」と同じである。

 直接的に「在庫削減システム」を考えるのは困難である。

 そこで、在庫把握システムになり、そのための受注システムや出荷システムを構築することになる。同様に「流通合理化」は、運賃計算システムにすり替えられる。当然ながら、これらのシステムが構築されても、在庫が削減できたり、流通が合理化される保証はない。

 経営者がこれを懸念するようだったら、第1次、第2次に分けるのだと説明しよう。第1次が計画より大きな出費になるため、経営者自身が第2次を行う気持ちがなくなってくるので、“想い”が実現しない責任を回避することができる。

情マネ流マーフィーの法則その177

ユーザーニーズはユーザーすら分からない

 情報システムを計画してから廃棄するまでの寿命は長い。

 10年程度の寿命を期待するのであれば、5年後のニーズでなければならない。ところが経営環境は激変する。経営者が5年後のニーズを予測できないことは、5年前に設定した経営戦略が的外れであったこと、それに従い構築したシステムが、その後改訂を繰り返してきたことでも明白である。

 それをよく理解している経営者ならば、次のように言うであろう。「私のニーズは1つだけだ。要求したら直ちに改訂できるシステムにしてくれ」。

 ところが、現在のニーズに固執して構築した情報システムは、固執すればするほど、改訂が困難なものになってしまう。カミソリのようなシステムにするのではなく、ナタのようなシステムにする方が良いのだ(これは社内IT部門への助言である。ITベンダの立場では、むしろ固執すべきである。それにより、改訂業務の受注が保証されるのだから)。

情マネ流マーフィーの法則その178

ユーザーニーズ半減・半増の法則


 しかも、要件分析の段階で要件が確定すると考えるのはナイーブ過ぎる。

 開発が進むにつれて次第にシステムの姿が見えるようになると、多様な意見が出てくる。

 その結果、計画時のユーザーニーズの半分はシステム構築段階で取り下げられ、その分だけ新規のニーズが付け加えられる(半増程度ならよいのだが……)。その結果、222の法則(第1回)2423の法則(第5回)が顕在化されるのだ。

情マネ流マーフィーの法則その179

ユーザーニーズはシステムを納入したときに明確になる


 「見える化」のために多くの図表が作成されているが、それらの図表を「読める」ユーザーは居ない。

 何となく「まあ、これでいいだろう」と開発が始まる。開発途中での確認会議でも、欠席するか、出席しても真剣に検討しない。納入段階になり、自分の問題となった時点で、初めてじっくり検討する。そして、じっくり検討した結果、「振り出しに戻る」ような要求を出す。

 このメカニズムを熟知しているベテランは、システム設計書をSLAの交渉が始まる時点で作成する。決して、初心者のようにコーディング以前に作成するような無駄はしない。

著者紹介

▼著者名 木暮 仁(こぐれ ひとし)

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


「情マネ流マーフィーの法則」バックナンバー

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ