Pretotypingのすすめ
自分が書いた昔の記事http://mtl.recruit.co.jp/blog/2010/11/pretotyping.htmlがデッドリンクになりそうだったので転載します。
Qcon SFの初日キーノートは、GoogleのPatrick Copelandさんが"Innovation at Google...plus a manifesto"と題して、イノベーションが起きるモデルや、その進め方について紹介しました。
Top-down vs Democratic Innovation
イノベーションはトップダウンで発生する従来の方法だけでなく、特にベンチャーによくみられるような民主的な方法があります。年齢が若くAgileが大好きなほど、またMTLブログを読んでくださるような方は後者に万歳になると思いますが、結局は成功した時の「正しいそれを作る」のか「それを作るのが正しい」の違いであって、その成功率は大して変わらないといえます。
そして、"pretotyping"マニュフェストを提唱しています。
(これをみる限りGoogleも後者のイノベーションアプローチなようですね)
innovators beat ideas
何と訳すのかよくわかりませんが、TwitterやWindowsCEを例に挙げながら、もしイノベーションが必要なら、電球よりもそれを発明したエジソン(=innovator)を探せ、ということをだそうです(これが一番難しいような気がしますが)
pretotypes beat productypes
どちらも造語なので、この3語全て分からないんですけど…イノベーターにとっての悪夢は完璧な製品やサービスを作ってもそれが他の人々にとっては欲しくもないし必要でもない状態で、これを減らすために、事前に試そうということを言いたいようです。
事前に試すことをprototypingと言いますが、その前にさらにPretotypingしよう、と言っています。pretotypingの定義は以下のような感じです。
こうみると、pretotyping≒paper prototypingと考えてもいいかもしれません。これをすることで、よりよい製品サービスにブラッシュアップされていく、ということです。
data beats opinions
そのアイデア〜製品サービスが正しいかどうかは、idea<pretotypes<prototypes<実際のデータという順に信頼できます。
そのデータを得るには、結局はイテレーションを常に早く回すことでしか得られません。
また、成功の要素は必ずしもイテレーションを回せばいい訳ではなく、マーケットの状態にも影響されますが、イテレーションを早く回すことでそれに早く気付けて修正できます。
具体的にはどうしたらいい?
マニュフェストを実際のタスクに落とすと、pretotypesをいくつか行い、試しに作ってリリースしてテストをして、成功しそうかどうかの情報を得る、ということだそうです。
その指標としてFLOPというのが紹介されました。
残存ユーザー数が多いほど成功といえます。
ちなみに先頃クローズとなったGoogle Waveは
と、ユーザーが全くリピートしなかった。だから閉じた、ということが分かりますね。
まとめ
Agileというとすぐに、まずアイデアを動く状態にしてみて考えてみる、という手法になりがちですが、その前にpretotypingした方がよりそのアイデアがブラッシュアップされていいものになりそうですね。pretotypeという言葉を気に入ったので、これから僕も実践していこうと思います。