この記事はMOSH Advent Calendar 20233日目の記事です。

プロダクティビティーチームの@soartec-labです。

一日目にスタートアップ企業で社内初のアドベントカレンダーを実施する技術で、アドベントカレンダーを通して組織としての新しい取り組みを行う際にもプロダクト開発の考え方を活かせた事について書きましたが、もう二週目が回ってきてしまいました。

プロダクティビティーチームとして普段は開発組織全体の生産性をシステム的なアプローチで解決する傍らプロダクトの開発プロセスや組織的なアプローチも行っている為、この記事ではプロダクト開発における開発プロセスの一つの考えを共有します。

※ 現時点では私の考えに留まっており、MOSHの開発組織として実践している内容ではありません。

背景

MOSHではプロダクトの開発におけるフィードバックサイクルの改善に目を向けており以下のような課題が見えていました。

仮説が不明瞭でユーザーの反応を見ながら検証を行いたい状況でもシステムを全て完成させる事を前提としているためリリースまでの見積もり及び実際の開発期間が長くなる
合わせてプロダクトのニーズが不明確なまま機能を作り込みすぎている

そこで、リリースステージと言う概念から、今の開発は何を目的としているのか明確にすることで、今必要な品質とデリバリーの認識を揃えたり過剰な作り込みを避けることができるかもしれないと思いアウトプットしてみます。

リリースステージ

リリースステージとはプロダクト開発のフェーズを区切り目的を明確にする考え方です。

書籍プロダクトマネジメント内では、別の書籍Product Roadmaps Relaunchedを引用し、プロダクトのロードマップの構成要素の1つとして開発ステージを4つのフェーズに分けています。

私なりに解釈してプロダクト開発においての視点で私の理解をまとめてみました。

ステージ	ゴール	実験の対象	方法	プロダクトの提供	プロダクト利用の制約
実験	問題を理解し解決する価値があるかどうかを判断する	問題の調査とソリューションの探索	プロダクションコードは書かない、オズの魔法使いやコンシェルジュなどの方法	-	-
アルファ	ソリューションが顧客にとって望ましいかどうかを判断する	最小限の機能または、適切なソリューションの実験	プロダクションコードのリリース	少数のユーザー	ユーザーの課題を解決できなかった場合は機能が変更されたり削除される可能性がある
ベータ	技術的な観点からソリューションがスケーラブルであるか判断する	プロダクション運用が可能か技術的な検証	プロダクションコードのリリース	アルファよりも多いが一部のユーザー。	技術的に不安定な場合に機能が変更されたり削除される可能性がある
GA	一般公開	-	プロダクトの一般公開	すべてのユーザー	なし

それぞれのフェーズは段階的な実験であり、前フェーズの実験が完了しないまま次のフェーズに進めるのは非効率だと考えています。

具体的には、実験フェーズで「ユーザにとって解決する価値がどうか」が判断できない、開発自体無くなる可能性がある状態でプロダクションコードを書く事や、スケーラビリティーのあるアーキテクチャを考え念入りな計画を立てても、そのフェーズにおいては過剰である可能性があるので別のよりスピードが速い実験の方法を模索したいですね。

もちろん、対応する開発によってはこのフェーズをスキップすることもありますし、既存のプロダクトに対しスピードを持って実験が出来るなら実験フェーズでプロダクションコードをリリースすることもあると思います。

リリースステージの事例

参考に段階的なリリースを行っているサービスをいくつか紹介します。

Google Workspace
- https://support.google.com/a/answer/11202276?hl=ja
Google Cloud Platform
- https://cloud.google.com/blog/ja/products/gcp/google-cloud-gets-simplified-product-launch-stages
Dropbox
- https://help.dropbox.com/ja-jp/account-settings/alpha-beta-product

まとめ

リリースステージによる段階的なリリースを活かす事で、より高速にプロダクト開発のフィードバックサイクルを回す考えについて書いてみました。皆さんのプロダクト開発における1つの観点として役に立てますと幸いです。

明日は、同じプロダクティビティチームの鳴瀬さんです！よろしくお願いします〜！