こんにちは。トレタ VPoEの北川です。
先日、「優先順位が口癖になる危機感」という記事を見かけました。 まさに自分が普段行っていることで同様の危機感を抱えていたたので、非常にささる内容でした。
要約すると、
- 優先度の高いタスクだけをやっていると、優先度の低いタスクを着手する時期は一生訪れない
- 実装したい機能の最優先部分だけを小さくリリースした場合、残りの機能は実装されず常に及第点の品質となる
- 及第点を取ることを目標として常態化してしまうとUXや内部品質が低下し続ける
自分が携わっているプロダクトもtoBのWebアプリケーションなので、普段のプロセスにとてもあてはまります。 本来の機能をすべて実装するにはリリースが数ヶ月先になってしまうが、要望を貰っている顧客向けであれば最小限の部分が実装できた段階で、制約や制限があったとしても説明した上で提供することができます。
例えば、新しい機能を使う場合に「ここの操作は行わないようにしてください」という制約がある場合に、本来はそこを塞ぐ実装も合わせて必要ですが、一般的なユースケースで起きないのであれば優先度は低くなってしまいます。 他にも、初回の登録作業が大変だが一度登録すれば使える新しい機能といった場合、登録作業の操作性向上のタスクも同時に提供するのが本来は望ましいが、こちらも後回しになってしまいがちです。
そして残りの優先度の低いタスクを取りかかる時点では、次の課題を解消するための、これまた最小スコープに絞った高優先度タスクにシフトしてしまいます。
この問題についての自分なりのアンサーとして、MVP(Most Viable Product)のリリースはメジャーリリースとは呼ばず、βリリースと呼ぶことにしました。
正式リリースとβリリースをわける
あくまでも呼び方を変えただけですが、本来提供したい機能・体験が揃ったものを正式リリースと呼び、それに満たずに一部制約や制限を残した先行リリースをβリリースと呼ぶことにしました。 これは、開発チーム以外のセールスチームやCSチームなども含めた社内認識です。
- ユーザーに提供したい機能やUXが揃った状態を、正式リリースv1.0として定義する
- そこから逆算し、MVPとして最低限の機能を有した初回リリースを、β v0.1とする
- 正式リリースまでに刻んでリリースするものは、β v0.2、β v0.3とする
βリリースとして呼ぶことで、初回リリースはあくまでも正式リリースまでの通過点であり、正式リリースするまでのβの状態は不完全なもの、という認識を持たせます。 不完全であるため、βの途中で後回しにすることは許容されません。
ゴールは正式リリースであり、初回リリースよりも正式リリースまでをいかに早くするかを常に考える必要があります。 ただし正式リリースまでは道が長いので、途中で価値のある単位でリリースを行いフィードバックを早く得るようにします。 この考え方はちょうど先日に新しく定めた開発組織のコアバリューにも通ずるな、と感じたところです。
100点を目指さなければ100点はとれない
これは自論ですが、「１位を目指さなければ１位は取れない」、というのが経験則としてあります。
コンペの話になりますが、１位というのは他よりも勝っていなければならないので、自分たちがなんとなく満足する達成度ではせいぜい２位か３位はとれても１位はとれません。満足した時点が基準点であり、そこから他者と比較して一歩勝つために細部を磨き込むことで１位へと押し上げることができます。
到達品質においても同様の考えで、「100点を目指さなければ100点はとれない」。自分たちが最初に立てた目標通りにやると大体の場合は80点ぐらいになります。経験値の高い人なら90点以上をになることもありますが、基本的には目標よりも低い出来になります。そこからもう一段磨き込むことで100点にやっと届きます。
つまり、80点から残りの20点を埋めて100点にする努力をしない限り、100点にはなりません。 ましてや80点を目指してたまたま100点がとれるなんてことは起きないし、80点にも満たない60点くらいになります。
今回のことで言いたかったのは、ひとまず80点とれればいいや、と考えていては100点に届くことはないし、我々は良いプロダクトを作って自信を持って100点のプロダクトをユーザーに届けたいはず。 最初の出来は80点の荒削りであるとしっかりと認識し、100点にするまで手を抜かない。80点から100点に上げるための筋肉を常に鍛えること。
