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

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

アドベントカレンダー3週目です。

前回の記事では、リリースステージによる段階的なリリースにより、高速にプロダクト開発のフィードバックサイクルを回す考えについて書いてみました。

この記事ではリリースステージ毎に「今のアウトプットが何のためのアウトプットなのか」という目的を認識する事で適切なアウトプットを選択するヒントになる考えを紹介します。

学習のための開発と収益のための開発

を分けて考えることが説明されています。

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

実験は提供する価値の学習のためのアウトプットになります。
例えば、以下の様な方法を用いてプロダクションコードを書く前にユーザにとって解決する必要がある課題なのか見極めます。

アルファでは実験によって得た課題をプロダクトで解決できるのかを検証する学習のためのアウトプットになります。

この段階ではまだ収益のためのアウトプットではなく優先するのは学習なので、できる早く出来る限り早く検証を進めたいので、既存のプロダクトに影響を与えなければ短期的なスピードを優先させて品質を犠牲にすることも受け入れて良いと考えています。

うまくいかなかったものは破棄する前提で、収益を生むためのアウトプットでは無いため、プロダクトとして価値が届けられることを確認してから持続的でスケール可能なやり方に変換すれば良いと考えています。

まさに技術的負債ではあるので、返済の計画を持った上で負債を借り入れ、プロダクトのステージが前に進んだら返却を行う技術面でのマネジメントが必要になります。

ベータ以降は、収益のためのアウトプットに目的が代わります。持続的でスケール可能なプロダクトにするための技術的な検証を含めた開発になります。
そのため、エンドユーザーが増えた場合のスケーラビリティーや、継続的な機能改善の為の内部品質が求められます。

GAでは新しい開発はありません。全てのユーザに向けて機能がリリースされている状況なので運用を通して適切にプロダクト価値が届けられているか、言い換えると、収益のためのアウトプットが目的通り収益を生んでいるかを確認します。

まとめ

リリースステージ毎に「今のアウトプットが何のためのアウトプットなのか」という目的を認識する事で適切なアウトプットを選択するヒントになる考えを紹介しました。
今のステージがどこなのか、それにより適切なアウトプットは何なのかを認識することでプロダクトのアウトカムを最大化させる手助けなれば幸いです。

明日は、まっすーさんです！よろしくお願いします〜！