こんにちは、asatoです。
最近、バリューストリームの効果性や健全性のことを考えています。バリューストリームの効果性や健全性を可視化したり定量的にも捉える方法を考えています。
すごく抽象的にプロダクト開発のバリューストリームを捉えるとDiscovery & Delivery
今、バリューストリームは組織やチームにおいて、多種多様な形を見せています。AIの普及によって、ますますいろいろな可能性が出てきています。これを考慮すると、共通的なバリューストリームを定義する価値はなくなる一方な気がします（もとからそうかもですが）。そこで、すごく抽象的にバリューストリームを捉えてみます。ユーザーからDiscoveryし、ユーザーにDeliveryする。以上です。
さまざまな形はあれど、「ユーザーに届けるべき価値を探索し定義する」Discoveryフェーズと、「見つけた価値を速く正しく届ける」Deliveryフェーズは共通してありそうです。
さて、このバリューストリームにおいて、ユーザーは「より大きな価値をより速く受け取る」ことができれば嬉しいはずです。ならばそれが達成されているかどうかが効果性で、それが継続的にできているかどうかが健全性になります。
アウトカム指標で効果性と健全性を可視化する
まず、提供した価値の大きさを測るには、アウトカム指標を測るしかないです。
アウトカム指標は、プロダクトがユーザーに提供したい価値が提供できているかを測る指標です。プロダクトがユーザーにより価値を提供できたときに変化する指標です。これはプロダクトや戦略によって変わるので、それぞれで定義するしかありません。
アウトカム指標を定義するのは大変ですが、まずはここが出発点なのだろうと思います。ここなくしてなんとかそれらしいアウトプットの指標を作っても、それはあまり信頼のおけないものになってしまいます。
アウトプット指標として、スループットとリードタイムを観察する
アウトカム指標は重要ですが、日々の活動からは少し遠い指標でもあります。どう頑張ればいいかに迷わないためには、アウトカム指標とリンクするアウトプット指標も重要です。
Discoveryフェーズでアウトカムを向上させるアイデアを見つけていることを前提に、スループットとリードタイムを観察することは有効です。
スループットは「どれだけの数の価値（候補）をユーザーに届けられたか」を示す指標になります。リードタイムは「どれだけの速さで価値（候補）をユーザーに届けられたか」を示す指標です。この二つの指標は仮説検証の文脈でも重要です。
ちなみにスループットもリードタイムも、バリューストリームの詳細をあまり気にしない指標です。多種多様なバリューストリームでも共通的に観察できる指標です。
リードタイムの開始点は悩みどころ
リードタイムの開始点は少し悩みます。Discoveryの終了点を開始点と見ることもできるし、DiscoveryのなかでダブルダイヤモンドでいうDefineのようなフェーズに入った点を開始点と見ることもできそうです。届けるべき価値が見えた、または検証するべき仮説が見えたというようなギアを入れ替えるタイミングを定義する必要があります。ここからは鮮度が命！みたいなやつですね。
DiscoveryはDelivery待ちに適切な在庫があればスピードを気にする必要はない
リードタイムという言葉から、Discoveryの開始点からのスピードが気になりがちになります。ですが、Discoveryはそんなに速いことがいいとは言い切れないフェーズです。速ければアウトカムに大きな影響を与えられるわけではありません。
速さを見る代わりに、Deliveryフェーズ前の在庫の山を見たほうがいいです。山が小さすぎればDeliveryフェーズの力を十二分に活かせていないことになります。逆に山が大きすぎれば、速くアイデアを定義してもDeliveryされるのはかなり後になります。アイデアが腐ってしまいます。Deliveryのスループットやリードタイムを改善する活動に取り掛かったり、アイデアの確度を上げる時間を増やしてもよいという見方ができます。
スループットやリードタイムが芳しくなければステータス別滞留数とステータス別滞留時間を分析する
スループットとリードタイムが良ければ、Deliveryの効果性と健全性はOKと判断できます。それでいてOutcomeも良ければDiscoveryの効果性と健全性もOKです。やった。
アウトプット指標が良くない場合は、**ステータス別滞留数（WIP）**とステータス別滞留時間を分析してみましょう。
ステータス別滞留数は、バリューストリームのどのステータスにどれだけの量のアイデアが滞留しているかを表したものです。ステータス別滞留時間は、バリューストリームのどのステータスにどれだけの間アイデアが滞留していたかを表したものです。これらから、ボトルネックになっているステータス（仕掛かり中や待ちが多い、作業時間や待ち時間が長い）を知ることができます。
ボトルネックがわかれば改善あるのみ！ボトルネックの改善方法もいろいろあります。ボトルネック自体の処理能力を向上させるのもそうです。他にもボトルネックの処理能力に合わせてフェーズを入れ替えたり、チームメンバーの多能工化を図ったり、不要なときはボトルネックを通らない迂回ルートをつくったり。いろいろなことが考えられます。
ステータス別滞留数とステータス別滞留時間を分析してボトルネックを特定し改善することで、アウトプットを改善し、ひいてはアウトカムを改善させることができます。
まとめ
- アウトカム指標を可視化しよう
- アウトプット指標としてスループットとリードタイムを観察しよう
- アウトプット指標がよろしくなければステータス別滞留数とステータス別滞留時間を分析してボトルネックを特定し、改善しよう
サポートもお待ちしております！
