ユーザの力を利用するアジャイル開発

「グーグルで必要なことはみんなソニーが教えてくれた」を読んで思ったことをメモ。

「グーグルで必要なことはみんなソニーが教えてくれた」の著者は、元ソニーのエンジニアの方がソニーで四苦八苦したプロジェクト内容とグーグルへ転職した時の雰囲気について書いていた。

気になった文章は、「走りながらユーザーの力を利用して製品の完成度を継続的に上げていく」「ネットの群衆の英知を使って問題発見と問題修復をやっていく」の二つ。

前者は、製品をすぐに作ってはユーザへフィードバックして評価してもらい、その結果を製品に取り込んで機能改善していくこと。
後者は、すぐに作った製品の完成度があまり良くなくても、ほどほどの品質で早めにリリースして、ユーザにバグ報告とバグ検証をしてもらうような仕組みを作ること。

いずれの文章もAgile開発の発想にとても良く似ている。
ポイントは、「ユーザの力を利用して継続的に製品の完成度を上げる」「ユーザの力を利用して問題発見と問題修復を継続的にやっていく」ということ。
つまり、単なる継続的改善だけでなく、ユーザのフィードバックを吸い上げてその内容を製品へ反映していく仕組みも必要なことを示唆している。

Agile開発の発想がソフトウェア業界だけでなく、ソニーのような家電製品などの業界でも必要とされている。
その事実に正直驚いた。
しかし本を読む限り、その発想を著者が在籍していた時代のソニーは理解できていなかったらしい。
著者は「日本人の完璧主義が足を引っ張っている」と言っている。

アジャイル開発の発想をITエンジニア以外に他業界の技術者が理解して実践していく環境は、現在も揃っていないのではないかと思ったりする。

その中でも、「ユーザの力を利用する」仕組みがとても難しいのだろうと思う。
製品の購入ユーザには熱心な人も入れば、アンチなユーザもいる。
彼らの声を全て正しいと仮定して製品に全て取り込むには現実的に難しい。
また、彼らの声がたくさんあるほど、重要なメッセージを見落としやすい。
そして、ユーザの声を反映した製品を更にユーザに使ってもらえるように、届ける仕組みも大事。

最近流行しているFacebookやTwitterは、そういうユーザの声をリアルタイムに集めやすい。
だからFacebookファンページでユーザの声を収集してはユーザへフィードバックしていく手法で、マーケティングをやっている会社も多いのだろう。

チケット駆動開発でよく使われるRedmineやTracも、高機能化したBTSやITSを単なるバグや課題を収集するシステムではなく、一つのポータルなシステムへ拡張していると思う。
例えば、収集したデータを各種の観点でレポートしたり、問題修復した製品をアナウンスしたり、ユーザと議論するフォーラムがあったり、製品のTipsを公開するWikiがあったりする。
それらの機能があるおかげで、ユーザと製品の開発者がリアルタイムに議論して、より良い製品へ改善していく仕組みが整うはず。

アジャイルという発想は僕はとても自然だと思う。
でも、実際の組織に当てはめて運営していくには、まだまだ何かが足りない。