新機能の最初のリリースはどれくらいミニマムにするべきか？
はじめに
2024年が始まりましたね。カミナシでPMをやっているtakasuといいます。
新年早々に2023年を振り返ってのお話なのですが、昨年カミナシに入社した私が所属するチームでいちばん最初に取り組んだ「レポート出力」という機能があります。
この「レポート出力」は、開発着手から、一部ユーザーに検証版を提供するまで3ヶ月、全ユーザーに正式版を提供するまで5ヶ月というなかなかに時間をかけた機能開発だったのですが、いま振り返ると、これだけ長い時間をかける開発であれば、もっと早くユーザーに機能提供をすることでリスクヘッジをするべきだったのでは？という思いもあります。
新規プロダクトを立ち上げる時のMVPについては様々な場や書籍で語られていますが、既に立ち上がっているプロダクトにおいて「新機能の最初のリリースはどれくらいミニマムにするべきか」については、あまり語られてはいないように思えます。
今回は「スコープをミニマムに定義しているのに、リリースが遅くなりがち」という課題感をお持ちのPMや開発チームに向けて学びとなるnoteとなればと思います。
なお「リリース」という言葉には以下のように目的に合わせて様々なスタイルがありますが、本noteにおいては対象とする範囲は問わず「プロダクトを通して機能や体験をユーザーに提供すること」を「リリース」と定義しています。
・クローズドβ：一部の対象のみ限定して提供し試用してもらう状態
・オープンβ：希望者に対して広く提供し試用してもらう状態
・正式版：利用可能なすべての対象に提供し利用してもらう状態
・and more…
なぜ最初のリリースは大きくなるのか？
先述の機能開発において、PRDを書き、POの役割としてリリース要件を定めたのは他でもない私です。
また、開発着手前にも、可能な限りミニマムな要件でリリースをしようと計画・調整をしておりました。
にもかかわらず最初のリリースまで3ヶ月という期間を要してしまったのはどうしてなのでしょうか？
以下の2点がその要因だと思います。
1. なぜリリースをより早くすべきかを理解していなかったこと
2. どれくらいミニマムにすべきかの基準が不足していたこと
なぜリリースをより早くすべきなのか
主題から逸れるため詳細は割愛しますが、昨年にスクラムについて時間を割いて学習をする機会を取ったことにより、「長期間リリースをせずに開発することは、プロジェクトを大きなリスクにさらす進め方である」ということを改めて理解しました。
開発前のディスカバリーで一定のリスクを低減することはできますし当然やるべきですが、「機能を提供した結果、ユーザーに価値を感じてもらえるか」は、どれほどヒアリングを重ねようと、どれほどプロトタイプにフィードバックをもらっていようと「ユーザーに使ってもらう」まではわかりません。
つまり、ユーザーに提供しないまま開発をすることは「開発した機能が価値を提供できずに無駄になってしまうリスク」を常に抱えた状態であるといえます。
このリスクを下げるには、シンプルに「より小さくより早くリリースする」こと、それしかありません。
どれくらいミニマムにすべきか
「より小さくより早くリリースする」といっても、基準がなければその小ささや早さは、人それぞれの解釈になってしまいます。
当時の私は「想定する4つの主要なユースケースを満たすこと」をミニマムのラインとしており、特定のユースケースだけに絞ってより早く検証を開始するといった考え方は持てていませんでした。
他にもたくさんのユースケースを想定していたので、主要である4つのユースケースに絞ったことで十分ミニマムであると思っていましたし、なんなら「あのユースケースを考えると、この要件を追加する必要があるのではないか」といった「より小さくより早く」とは逆方向の検討をしていた記憶もあります。
改めて当時の自分に基準を与えるとしたら、以下の内容が良いかと思っています。
最初のリリースは、主要なユースケースのうち最小のものを満たすスコープを定義するのがよい
図で表すと以下のようなイメージです。
少し脱線しますが、今読んでいる『レガシーコードからの脱却』の第6章「小さなバッチで作る」において、MMF（最小市場化可能機能セット）という概念が紹介されています。
最小市場化可能機能セット（MMF）、ストーリーの分割などのテクニックを使ってスコープを決定する方法を理解すれば、適切なサイズの機能セットを決定するのに役立つ。
（中略）
機能（ストーリー）をさまざまな方法で整理する。テーマごと、ユーザーの種類ごと、目的など、自分に合う方法で整理すればよい。リリースできるように機能を集めていくことが求められる。これのことを最小市場化可能機能セット（MMF）と呼び、プロダクトが生き残って役立つものであるためにリリースで絶対必要なものを教えてくれる。
MMF（Minimum Marketable Feature）を意訳すると「市場に投入できる（= ユーザーに提供できる）最低限の機能」であり、これは上で述べた「最初のリリースをどれくらいミニマムにするべきか」の基準として定義した「主要なユースケースのうち最小のものを満たすスコープ」と同様の考え方と言えます。
より小さくより早くリリースするためのプラクティス
冒頭で述べた通り、リリースという言葉は必ずしも全ユーザーに正式版の機能として提供することを指しているわけではありません。
開発着手から正式版としてのリリースまでにある程度時間がかかる機能開発において「プロダクトを通してユーザーに提供した結果、価値を感じてもらえるか」をより早いタイミングで把握するには、クローズドβテストをうまく活用することがプラクティスとしてあげられます。
β（β版、βバージョン）とは、正式版をリリースする前にユーザーに試用してもらうための開発途中のテスト版のことですが、その提供範囲を特定の企業やユーザーに限るクローズドβテストを活用することで、正式版やオープンβテストに比べても、より小さいスコープでより早くユーザーにリリースすることができます。
まとめ
今回のnoteでは「新機能の最初のリリースはどれくらいミニマムにするべきか」について書かせていただきました。
・長期間リリースをせずに開発することは、プロジェクトを大きなリスクにさらす進め方である
・ 「開発した機能が価値を感じてもらえずに無駄になってしまうリスク」を減らすために、より小さくより早くリリースをすることが重要
・「より小さくより早く」の基準として、最初のリリースは、主要なユースケースのうち最小のものを満たすスコープを定義するのがよい
私自身、PMとして走りながら学んでいる毎日ですが、今後も実務の中で得た学びをnoteにまとめていきたいと思います。
少しでも参考になるところや共感するところがあれば “スキ” をぽちっと押していただけると励みになります！
また、カミナシでの開発やプロダクトマネジメントに少しでもご興味を持っていただいた方はぜひぜひカジュアルにお話しさせてください！
この記事が気に入ったらサポートをしてみませんか？