本当にユーザーが欲しいものは何か？

youtubeで興味深いビデオを見つけた。

簡単に要約すると、こんかんじ。

「アイディアはいろんなところからやってくる。ユーザー、技術者、役員、分析から。

そして、アイディアが出たら、次はプロトタイプだ。きちんとアイディアを実証できるものがつくれるか？どうやってユーザーのイメージを正確にとらえるか。

イノベーションをもたらすのに一番大切なのは、イタレーションである。何かを試す、フィードバックをもらう、また新しい何かを試す。これの繰り返し。そして、ユーザーが本当に求めているものに近づいていく。

googleが成功している理由は、いいアイディアを持っているから、いいアイディアをうまく実行しているから、そしてとても小さなチームで働いているからだ。

その小さなチームの中で、技術者たちは、決断をする。何がこのサービスの一番の売りなのか？

本当にユーザーが必要としているのは何か？最高の製品をどのようにつくりあげるのか？と。」

• ユーザーが本当に欲しいものをきちんと考える。
• 小さいチームが、決断権を持って仕事を進めていく

というのは非常に考えさせられるものがあった。

以前いたプロジェクトで以下のような話を聞いた。

「お客さんがどうしても作ってほしいっていうシステムがあった。難しい案件だったけど、なんとかがんばって作った。そのシステムの構築には、数千万円かかったらしい。でも、そのシステムができて、1年くらい経つけど、実際に使われたのって2回しかないらしいんだよね」

先輩の話によると、お客さん側のシステム部とユーザーの間で認識が違っていたらしく、システム部や経営陣が作って欲しいと言っていたシステムは、実はユーザーからすると本当は必要なシステムではなかったらしい。

おそらくシステム屋さんであれば、よく聞く話だと思う。

• 実際にものを作る人
• 実際にものを使う人
• 決定を下す人

これらの間で、綿密なやりとりが無ければ、作ってみて実は要りませんでした～ってことに成りかねない。そして、これらの3種類の人間が一堂に会する機会というのはほとんどないというのが現実だと思う。

例えば、実際にものをつくる私たちシステム屋が、お客さんのユーザーと話す機会や、お客さんの意思決定権を持つひとと話すことは、ほぼない。お客さん側のシステム部という部署の人たちから要件をいただく。

細かいやりとりを抜かせば、コミュニケーションの大きな流れは以下の２つだと思う。

• ユーザー -> (開発依頼) -> システム部 -> (意思決定依頼) -> 経営陣 -> (意思決定) -> システム部 -> (開発依頼)->開発者
• 開発者 -> (要件、仕様確認) -> システム部 -> (確認) -> ユーザー -> (返答) -> システム部 -> (返答) -> 開発者

上記では、システム構築者を開発者としてまとめたが、実はこのシステム構築者も一次受け、二次受け、三次受け、・・・、オフショアなどと細かく階層化されている。

問題点は、２つある。１つは、情報の伝達が遅くなってしまうこと。２つ目は、ユーザーの真意が開発者に直接伝わらないことだ。大きい企業だと、このように階層化された情報伝達は仕方ないのだろうか？

私は、学生時代にアルバイトで社内システム（住所録管理、在庫管理、部品発注システムなど）を作ったことがある。

そのときは、「窓がぱっと出てきて、ボタンぽんって押したら、シュッてこの項目が別画面に飛んでボタン押したら、こうなって、・・・みたいなの作って欲しんだけど？」と言われ、「はい、分かりました。」というかんじで要件が確定し、早ければその日のうちに試作バージョンを作って、「こんな感じだけどどうでしょう？」と聞いて、「うーん、ここはもうちょっとこうなってた方がいいなー」と言われ、また作りなおして、・・

という感じで進めていた。

このやり方だとスピード感が全然違う。開発者である私と、ユーザーと、そして意思決定権のある社長。３人が画面を見て、どうするのかをその場で決める。そして、要件定義書や設計書というイメージしにくい文書で話をするのではなくて、実際にものを作って、それを改良していくので、ユーザー、開発者間の認識の差異が生まれにくい。

”アジャイル開発”という言葉が先進的な開発スタイルみたいな感じで語られることが多いが、私はこれが本来あるべき普通のシステム開発の姿のように思う。