銀河鉄道~ぽんこつエンジニアのブログ~

思いつきで書いています。

思い込み?

こんなことがあった。

ある機能を設計してたメンバーが、レビュー依頼を投げてきた。その中で、あるデータをテーブルAに登録するのか、テーブルBに登録するのかという問題があり、そのメンバーはテーブルAに登録するとしていた。

 

画面上の検索処理は、テーブルA、テーブルBのデータをそれぞれ起点として検索結果を表示する用になっており、どちらのテーブルに登録しても検索結果は変わらない。

 

違いは、テーブルAは登録処理が複雑で、登録データが画面上に表示されない。

 

テーブルBは登録処理がシンプルで、登録データは画面上に表示される。

 

ユーザーは私用説明の際、特に理由を説明せずに、テーブルAに登録して欲しいと言った。

 

メンバーはそれを聞いて、画面表示させたくないんだと判断しテーブルAに登録する設計を書いた。

 

レビュー時に、なぜテーブルAに登録するのか?と指摘したところ、メンバーは「テーブルAに登録してしまうと画面に表示されてしまいます。このデータは画面に表示したくないのでテーブルAに登録する設計にしました」と答えた。

 

僕「なぜ画面に出したくないって判断したのの?」

メ「ユーザーがテーブルAに登録して欲しいと言ったからです。」

僕「でもテーブルAの登録処理は複雑だから工数かかるよね?」

メ「でも画面に出したくない要望が優先ではないでしょうか?」

 

ユーザーは仕様を理解してるので、テーブルAに登録して欲しいと、わざわざ指定したのだから、画面に表示したくないんだろう、というのがメンバーの言い分。

 

ここには大きな落とし穴があって、ユーザーの気持ちを汲んでいるようにも見えるが、ユーザーは一言も「表示したくない」とは言っていない。メンバーは仕様を知ってるユーザーがテーブルAを指定しているんだから「表示したくない」に決まっていると思い込んでいる。

 

後日ユーザーに確認したところ、「たしかに表示しないのがベストだが、それで工数がかかるのならば、表示されるテーブルBに登録で構わない」との返答だった。

 

ユーザーとしては、画面表示<工数だった。

 

ここから言えることは、ユーザーがやりたいことがユーザーの最優先事項とは限らないということ。やりたいことを聞いた上で、そうやるとこうなりますけどいいですか?とメリットデメリットを聞いた上で判断してもらうことで、隠された最優先事項が見えてくる。

 

ユーザーがやりたいと言ってるからやるのではなくて、なぜやりたいのかを確認して、それを実現するためのメリットデメリットを見せた上で判断してもらうことがユーザーの最重要項目を把握することになるというお話。