サービス運用時の開発優先順位についての考察

ども、@kimihom です。

サービスに置いて必要最小限の機能(MVP) を開発して晴れてリリースして、そのあとの開発はどんな優先順位でやっていっているのかを考察してみる。

MVP 検証段階

まず MVP の要素で顧客が満足できるものなのか検証する段階では、サービスの根本を変えたりすることで顧客のニーズを満たせるサービスにするために試行錯誤することになる。全然ニーズに合わないようなサービスだったら全部ぶっ壊して違うサービスを作り始めたりすることもありうる。サービスの完全なピボットというのはもはやこの段階にしかできないことなのだから、検証段階では思い切った決断をしていくべき。

検証段階で注意しなければならないのは、ちょっとした機能追加で顧客のニーズを満たせるものにはならないということだ。本当にサービスの根本、それで顧客が受けるサービスじゃなければやる価値はほとんどないと言える。追加機能が愛されるようなサービスだったら、その追加機能をサービスのコアとしてピボットすべきである。

そのコア機能でちょっとでも一部の顧客が愛してくれるようになったら次のフェーズに進める。それまではひたすら機能をぶち壊しては作り直しの連続だ。この段階からスケールとか負荷とか考える必要は全くない。すぐにサービスぶっ壊せて、すぐに開発できるフレームワークや言語を選ぼう。

"愛され指標" については NPS が有用だろう。顧客が「あなたはこのサービスを他人に勧めたいですか？」という質問で10段階中8以上を選択したら、とてもいい傾向だ。自信を持って次に進もう。

最初の顧客獲得段階

幸いなことに自分の作った MVP で一部の顧客に愛されるようになったら、その顧客を満足させるための機能を徹底的に追及していこう。"サービスを愛する顧客" = "自分たち" である場合は楽だ。自分たちがこれがあれば絶対にサービスがもっと良くなると信じられる機能を開発すればいいだけになるからだ。自分たちでない場合は、ひたすらヒアリングしてニーズを聞き出そう。自分たちの判断で作るものを決めるのは危険だ。

その人たちが使わない機能は絶対に作ってはならない。Aさんは便利だろうけどBさんは使わない。そんな機能は存在しないほうがいいのだ。最初の顧客獲得段階はサービスを愛してくれた顧客をさらに愛してくれるようにサービス開発を続ける段階になる。

一通り満足してくれるようになるには機能開発を少なくとも半年は続ける必要が出てくるだろう。技術的にはすぐに開発できる環境に加え、すぐに機能追加を反映できるような開発環境を整える必要が出てくる。

一定数の顧客を獲得した段階

さて、一番大事なのはこのフェーズだ。あなたはそのサービスをどうしていきたいのか。その選択が重要になる。

"もっとたくさんの人に使われたい"とは誰もが思うものだが、それによって得られる答えは"機能の追加"ってことになる。これが割と安易で危険な考え方で、サービスをより複雑にしてしまう原因とも言える。Aさんは今までの機能で十分満足していたのに、どんどん複雑になっていくサービスを使っていきたいと思うだろうか。

既存の顧客に愛され続けるサービスにしたいなら、機能開発っていう選択はすべきではない。もっとしなければならないこと、それはより早く、より正確にサービスが使えるという地味な改善を続けることである。普段5秒くらいロードに時間がかかっていたのが、2秒に縮んだ！こうしたリリースを最優先で取り組むべきであり、他が絶対にできないサービスのコアを磨き続ける努力をするのが良いと言える。