日経SYSTEMS 9月号のコラムは「機能をユーザーに選ばせてはいけない」です。
A案とB案を作って提案したとき、もちろんA案だと思っていたら、B案を採用されて大慌て、みたいなことありますよね？
こうしたことが起こらないようにするにはどうしたらいいだろうか。筆者からのアドバイスはシンプルだ。「機能をユーザーに選ばせてはいけない」。
乱暴なようですが大事なことです。ユーザとは「機能の背景」である要件について議論を重ねるのです。その結果、最適な機能のカタチはソフトウェアのプロフェッショナルである我々が提示すべきことです。
もし機能を決めきれず，複数案が考えられるのなら，それは要件が不足していることを意味している。その場合，何が足りないかをつかんだうえで，「要件上，こうした情報が足りません」と，情報の追加を求めなければならない。
そして逆も大事。
ユーザーによっては，機能の実現方法を指定してくる場合もあるだろう。こうしたときは，「その機能は，何のためですか？」と質問をするとよい。それによって機能の前提となっている要件がより明確になる。そうすれば，より良い機能を提案できるかもしれないし，ユーザーが指定した方法が最適だと判断できるかもれない。
でも、意外に行われてない。もっと質問して、もっと対話しないといけない。「これだ！この機能でいける！！」みたいな確信が持てないなら要件が整理できないと言うことです。で、起きてしまうのが勝手脳内補完。そんな仕様のままで奇跡的にレビューがOKで作ったとしても、開発段階でプログラマに「なに、この機能？意味なくね？」と言われ、使い始めればユーザーにも「使えない」と言われることになります。
「言われたとおりの機能を作りました」。うん、それはね"仕事"っていわない。子どものお使い。そんなことしているようならSIer涙目なんて自業自得だよ。そんなわけでまとめ。
大事なことは，ユーザーとは要件を通じて議論することである。そして，要件の理解が正しいことを確認するために機能の実現案を提示する，というのが正しい姿である。機能の実現案をどれにするかとユーザーと議論するのは間違っている。ユーザーが興味を持つのはビジネス的な価値である。その価値をどのような機能で実現すべきかを考えることは，エンジニアの仕事である。機能の実現方法をユーザーに選ばせるというのは，自らの責任を放棄しているといえる。
あなたは責任放棄していませんか？全文は日経SYSTEMS9月号で。
