前回に続き、今回もちょっとしたプロダクト小噺をします。
前回書いた記事はこちら。
前回の話では、できる限り複雑性を排除し、一度にリリースする機能を減らそうということを書きました。人間は複雑なものを処理できないので、小さく分割することで、処理できるようになります。
ただMVPは複雑性を排除するだけが目的ではありません。それ以外にも、フィードバックサイクルが早くなり改善ができるというメリットがあります。それが今回の趣旨になります。
今日覚えて帰って欲しい単語は「フィードバックサイクル」です。
フィードバックサイクルとは
フィードバックサイクルとは、フィードバックを受けて改善を回すプロセスのことを言います。
フィードバックをもとにしたPDCAサイクルという表現でもよいですが、要は何かをリリースしたのち、フィードバックをもらい、それをもとに改善していこうという話になります。
早いフィードバックサイクルの重要性
プロジェクトでは一般的に時間が経つほど、規模が増えていくことが知られています。開発時は不確実性が多く考慮できていないことが多いためです。
ただし進んでいくと、考慮できていないことが明らかとなり、規模が拡大していきます。
規模が拡大すると、当初の狙いが不明瞭となり、本来達成したかったこと以外にも達成したいことが増えていきます。当初の狙いも決まってないプロジェクトであれば、さらに悲惨で、更に達成したいことが増えるでしょう。
そうなると、本来想定していた利用者・お客さまのニーズはどこかに行ってしまいます。
そのため、MVPを用いて、真っ先にフィードバックをもらうことが重要になります。 すぐフィードバックをもらうことができれば、規模が大きくなりすぎる前に、本当に必要な機能かをチェックすることができます。
心がけたいこと
フィードバックをすぐにもらうためには、一刻も早くリリースする必要があります。つまり、完璧なものを出そうとはせず、ある程度機能が十分ではないままリリースすることになります。
ザッカーバーグの名言のように、まずDoneすることが重要なわけです。
Done is better than perfect.
ザッカーバーグの名言
そのため、自分がチャレンジする際も周りがチャレンジする際も、Perfectではないことには文句を言わず、Doneを目指しているのだとマインドセットしていけると良いですね。
リリースすることができれば、フィードバックがもらえます。そうすれば改善していくことができます。まずはDoneを目指しましょう。
終わりに
仕事に情熱を持っているプロフェッショナルな方々は、つい完璧を目指して機能追加したくなったり、足りない機能について文句を言いたくなったりするかもしれません。
ただ完璧を目指すことによって、使わない機能の開発に時間をかけたり、調整が増えることになっては本末転倒です。
まずはDone。その後改善を意識して、モノづくりをしていけると良いかと思います。
次回は、「だったらとりあえずリリースでもよいの？」という疑問に答えていきたいと思います。
コメント