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

システム開発では、ユーザーニーズを重視した開発を心掛けるようによくいわれるが、そのとおりに作成しても、その後改良に次ぐ改良を迫られる場合がある。なぜユーザーの声を忠実に再現したのに、改良が必要なのだろうか？今回はユーザーニーズについて考えてみる。

[木暮 仁，＠IT]

質問1

なぜユーザーニーズを聞いているのに、役立たないシステムになるのでしょうか？

情報システム部長です。役に立たないシステムが多いことは情報関係の雑誌でもよく取り上げられています。当社では、ユーザーニーズを的確に把握して、それを実現するように努力しているのですが、それでも役に立たないと指摘されているシステムがあります。どうして役に立たないシステムになるのでしょうか。

質問2

ユーザー部門の意見を取り入れたつもりなのに、システムへの改訂要求が多いのはなぜでしょうか？

当社では情報システムへの改訂要求が多く、情報システム部門が硬直化しています。開発に当たっては、ユーザー部門の意見を十分に取り入れたつもりなのですが……。

意見

　情報システムは業務の仕方を規制するものであり、業務改革をするには適切な情報システムが重要です。また、情報システムは「使われてナンボ」であり、実際に使うのはユーザー部門ですし、「業務をよく知っているのはユーザー部門」なので「ユーザーニーズに合致する」システムにすることが重要だといわれています。

　それは正論に違いないのですが、私はそのユーザーニーズに大きな疑問を持っています。ユーザー自身が適切なニーズを理解していないのではないか、それを金科玉条とした情報システムは必ずしも適切なものにならないのではないかという疑問です。

ユーザーは自分の仕事が分かっていない

　　　現象　　　

　業務をよく知っていて実際に情報システムを使うのはユーザーなのだから、情報システムの開発に当たっては、ユーザーニーズを満足させることが重要だといわれてきました。しかし現実には、ユーザー自身が仕事を知らず、適切なニーズを示すことができないのです。

　情報システムを構築するには、その前提としてニーズが明確になっている必要があります。そもそも、明確なニーズがあり、それを解決するのに情報システムが不可欠だと判断したからシステム化を要求したはずです。

　しかし現実には、要求分析をする段になって、ユーザーにヒアリングすると、具体的な要件になっていないとか、多様な意見があってまとめられないなど、なぜ情報化を提案したのか分からないような状態です。また、要件があいまいなままで開発が進行し、具体的な様子が見えてきた段階で新しい要件が出てきたり、先の要件を変更したりします。システム開発が完了して実施段階になってから、新しい要求や変更が指摘されることも珍しいことではありません。

　システム開発では、実際に要した費用は計画の2倍掛かり、納期は2倍になり、しかも機能は2分の1しか実現できないという「222の法則」があります。これは情報システム部門へのやゆとしていわれることが多いのですが、現実にはユーザーが要件をなかなか決定できず、後になってから変更するので、必要以上の時間と費用がかかり、要件を取り入れることができないのです。

　　　分析　　　

　どうして、ユーザーニーズが明確にならないのでしょうか？ ユーザー部門と情報システム部門のコミュニケーションをよく行うことが指摘されますが、以下のことにも留意する必要があります。

• 一般的に暗黙知を形式知にすることは難しいものです。個人の暗黙知になっている業務の仕方を、部外者が分かるような形式知にすることは困難です。聞かれれば答えられますが、自ら体系的に矛盾なく説明することはできないものです。
• 「得意先からの受注を増やしたい」というニーズは明確であっても、それを実現するにはどうすればよいか分かりません（分かっていればすでに実行しています）。ましてや、情報システムに何を要求すればよいか分かりません。何をすればよいか情報システム部門も分からないので、「得意先別売り上げ速報を作りましょう」というような、つまらないシステムにしてしまいがちです。
• ユーザーは、「商品Aがどの得意先にどれだけ販売したかを知りたい」「B得意先にどの商品がどれだけ売れているかを知りたい」という表現はできますが、それを「商品や得意先を指定して、売り上げ状況を得るようにしたい」とか、「売り上げデータを多様な切り口で検索加工できるようにしたい」というように、抽象化するクセが付いていません。情報システム部門も抽象化のクセがないと個々のニーズを実現しようとします。ところが、明示的になっていないニーズは多く存在するのですから、それが後になってから要求されることになるのは当然です。
• 実際には、プロジェクトを進める段階にならないと要求に気付かないとか、その段階になって、初めて当初の要求が不適切だと気付くことが多いのです。例えば、当初は顧客情報を入手し、マーケティングに活用することを目的としてカードシステムを提唱したのに、実際に推進を開始するとカード会員の獲得が思うように進まず、加入を妨げる個人情報などは取らないことにしようか、会員特典をする機能を強化しようというように、目的や仕様が変化することは案外多いのです。