新生ヤフーの「爆速」を可能にした「リーンスタートアップ」とは？――IBM Innovate 2013レポート（前編）

仮説をMVPで検証してみると

　検証の結果、データとしては面白いものがとれたが、電池が半日も持たないという問題が明らかになった。GPS測位を5分置きにスリープさせるなどプログラムの改善を試みたが、電池の問題は解決しなかったという。そこで、河合氏らは、アプリの方向性を再確認し、位置情報をあとで見るということで何ができるかを考えてみた。その結果、「自動ではないが正確な位置をログできるサービス」と「正確ではないが自動で位置をログできるサービス」の2つの方向性に整理してみた。社内でアンケートを取ったところ、前者のニーズは「GPSマニア」だけであり、女性など多くのユーザーは後者の機能を重視していることが分かった。

最初のMVPの問題を検証

アプローチを見直して分かったことも

　開発チームはここで、GPSによる測位をすっぱりあきらめ、携帯電話の基地局情報による大まかな位置情報を日記スタイルで確認できるアプリ（次のMVP）を社内に配布して、再び検証を行う。結果は、位置は正確ではないが、1日稼働させても電池の消費は問題ないレベルとなり、テキストによる日記風の表示は新鮮であるという評価を得た。

検証結果を修正したMVPで再び検証

あいまいなアイデアからゴールを模索しながら開発

　以上が「僕の来た道」アプリで実践されたリーンスタートアップの開発からリリースまでのプラクティスだ。厳密な仕様や要件が定められゴールが明確なプロジェクトならITILなど従来モデルも有効だが、このように、スピードが求められるプロジェクト、ちょっとしたアイデアからスタートさせたいプロジェクトの場合、リーンスタートアップが有効に機能する。

　だが、DevOpsはこれで終わりではない。リーンスタートアップの改善サイクルはリリース後も続けなければならない。ユーザー体験というのはすぐに減衰してしまうものなので、新しい機能やサービスを提案していく必要があるからだ。

しかし、評価やユーザー体験はすぐに減衰する

　河合氏は、ゴールのスコープをどこに置くかによるが、サービスのライフサイクル全体に置くなら、リーンスタートアップのスキームにより、減衰するユーザー体験をなるべく短い間隔でリフレッシュしてやり、サービスのスループットを維持していくことが重要となると述べる。

修正のリリースサイクルを短くし、高いユーザー体験を維持する

　そして、スコープのズレを意識し、スループットを高く保つためリーンスタートアップのサイクルを素早く、頻繁に続けることが「爆速」ではないかと河合氏は主張する。とはいうものの、ヤフー社内でも爆速の定義は明確ではなく、部署や立場によって違いはあるようだとする。しかし、「とにかく速くなければダメだ」というコンセンサスは着実に定着しつつあるという。

　また、爆速、リーンスタートアップは、トップダウンの強制では現場には定着しないので、トップダウンのビジョンとボトムアップのトレーニングの両輪が必要であると補足した。最後に河合氏は、リーンスタートアップの成果となる事例はまだ少ないが、次のステップとしては、この事例を増やすこと、そしてアジャイル開発やDevOpsを社を超えた横展開で進め、業界全体をよりよいものにしたいと抱負を語った。

（後編につづく）