闇 Advent Calendar 2013 が面白い。読んでたら自分も最近感じることを書きたくなったので、書いてみる。なお以下は、Webサービスを自社開発する会社に限った話と思ってください。
渾身のアイデアがこける理由
Webサービスを開発していると、いけると思ったアイデアをいざリリースしてみたら全くユーザーから使ってもらえなかった、ということに出くわす（個人的には、仕事をしていて最もやる気を削がれる瞬間の一つだ）。いかに高品質で、テストカバレッジが高く、エッジの技術を採用したプロダクト/機能でも、使われなければ何の意味もなくなる。
なぜこういうことが起きてしまうのだろう。これは殆どは、アイデアの効果予測が甘かったために起こるものだと思っている。
効果の見積もり
Webサービスの事業数値を達成する上で、僕は以下の 4 点が鉄則だと思っている。
- 自分たちが追っている目標数値は何なのか（PVをどのくらいまで伸ばすとかとか、売上げをどこまで到達させるかとか）をはっきりさせる
- 現在 ToDo リストに積まれているアイデアが、この目標数値に対してそれぞれどれだけ寄与するのかを「具体的な数字で」見積もる
- どうしても試算できないときは、アイデアの超スモールバージョンを作って A/B テストする
- アイデアのリストを、目標数値に対して寄与の大きい順から実行する
- 目標数値に寄与できるアイデアがないときは、考えて、3 に戻る
施策が失敗するということは、2 の効果見積りができていなかったか、甘かったかのどちらかだ。
アイデアの優先順位づけの議論
どの施策を優先して着手するかをチームで議論するときは、ミーティングまでに前もって効果を試算しておくことが重要だ。というか数字がはっきりで出ていれば、もはや優先度を議論する必要すらないはず。別の言い方をすると、チームで施策の優先順位付けの議論が長くなりがちなときは、効果予測の試算がきっちりできていないということなのかもしれない。
また余談だが、数字を試算せずに議論を進めてしまうと、チームで声が大きい人のアイデアが採用されがちになる、という別の悪い問題も生じてしまう。
アイデアがネタ切れしている恐怖
現在ストックされているアイデアについて、それぞれの具体的な効果数字を見積もっていくと、以下のことに気づいてしまうかもしれない。
「現在ストックされているアイデアをすべて実行しても、目標数値を達成できない。」
そしてこの問題にぶち当たったときにやるべきことは至ってシンプルで、
ことではなかろうか。
ToDo リストを消化するという思考停止
アイデアの効果を具体的な数字で見積もるという行為は、現実を直視することそのものだ。だから怖い。できるなら避けたい。
だが、そこで現実と向き合うことから逃げて、 ToDo リストを消化するだけの思考停止行為に逃げたとき、サービスは緩やかに死を迎えるのだろうと思う。
