あるユーザー企業のシステム部門に勤めるエンジニアのAさんは、営業部門のB主任から「パッケージソフトを使って営業支援システムを構築したいので相談に乗ってほしい」という依頼を受けました。まずはパッケージの選定をしたいというので、Aさんは「自分が選定する立場だったら、代表的なパッケージ同士の機能比較表を要求する」と考え、代表的な製品について調べることにしました。
さっそく、パッケージを使った営業支援システム構築の実績が豊富なITベンダー5社の協力を得て、各パッケージの機能の違いをまとめます。顧客管理、案件管理、活動管理といった主要機能ごとに、説明用の機能比較表を作成しました。
数日後、Aさんは、営業部門に対して主要パッケージにおける機能の違いを説明し、どれを採用するのか決めてほしいと伝えました。すると、営業部門のB主任は苦虫をかみつぶしたような顔で、「そもそも各機能が、具体的にどのような場面で使えるのか、使ったらどんな効果が見込めるのかが分からない。ちゃんと説明してほしい」と言ってきました。
「営業支援システムについて基本的なことも分かっていないなら、初めからそう言ってほしかった」。Aさんは、腹の底でそう思いましたが、改めて説明用の資料を作りミーティングを開くことにしました。
上司に経過報告をすると、「B主任も含めてうちの営業部門はITに詳しくないから、基本的な説明を求めてくるのは分かるだろう。ユーザー目線に立って考えろよ」と注意されました。「私だってユーザー目線に立って考えました。それで、パッケージ同士の機能比較表が必要だと判断したんです」。Aさんはこう反論しようとして、思いとどまりました。結果として、ユーザーの期待に応えられなかったのだから、何を言っても始まりません。
「ユーザー目線に立つとは一体どういうことだろう？」。Aさんは頭を抱えました。
人によって何を意味するかが異なる
ITエンジニアであれば誰しも一度は、「ユーザー目線に立ちなさい」と言われたことがあるでしょう。しかし、ユーザー目線に立つにはどうしたらいいのか、について具体的な指示や指導を受けたことはあるでしょうか。
ユーザーにとって本当に役立つシステムを提案したり構築・運用したりする上で、ユーザー目線に立つことは欠かせません。しかし「ユーザー目線に立つ」が何を意味するのかは、人によって異なります。しかも、誤った認識を持っているエンジニアも少なくないようです。
その典型例が、冒頭のエピソードのAさんのように「自分がユーザーだったらと考える」というものです（図1）。「もし自分がユーザーだったら、この提案はいいね！と思う」という具合に、ユーザーの反応をシミュレーションする、というわけです。
