VSM (Value Stream Mapping)を書いたらリリースリードタイムが約200時間も短縮できることがわかった話
用語整理
■ VSM (Value Stream Mapping) とは？
- VSM (Value Stream Mapping) とは、「価値の流れ」を可視化した**開発プロセスを可視化する**ための手法、活動になります。
— 詳しくは、 業務プロセス可視化 : VSM (Value Stream Mapping)を参照してください。
■ リードタイム(LeadTime)とは？
- ここでは、要求が発生してからFeatureを開発→リリースするまでにかかる時間と定義します。
問題提起
- 普段、開発をしていて開発プロセスをあまり意識することは少ないかと思いますが少し客観的的見てみるとリードタイムがものすごいことになっていることがあります。
【個人的に危険と感じる開発プロセスは下記になります。】
- Featureをリリースするまでに開発作業よりも「承認 + 確認」などの調整時間のほうが長い。
- 開発工程の中で手作業が多く、自動化されていない箇所がある
- Featureの開発は終わっているのに外的要因でリリースができない状態が1週間以上ある
上記のような危険な開発プロセスのような「ムダ」は組織が大きくなればなるほど増えていくような気がします。このような「ムダ」をなくすためには
まず、開発プロセスを可視化して「ムダ」を洗い出す = VSM (ValueStream Mapping)
となります。
本題 (リードタイムを200時間短縮できることがわかった話)
VSMの作成方法に関しては、 業務プロセス可視化 : VSM (Value Stream Mapping)などを参考にしてください。
まず、VSMを作る大前提の話をするとVSMというのは大事なのは、改善ポイント(=ムダ)を見つけること です。 ※どう改善するかはまた別のレイヤーの話ということです。
では、まず下記のような自チームが開発した機能をリリースするまでのVSMを書いたとします。 できれば、データを取るために複数のVSMを書くと良いです。
まず初めにやることは、
1. どこを改善するべきかカテゴリー分けすることです。
自チームですと下記の方になりました。
2. どのカテゴリーにリードタイムがかかっているか計算
1例ですが、総リードタイムが268.5hに対して下記の比率になりました。
ポイントとして上げるのであれば、ほぼすべてのVSMがこの比率になりました。
よくよく考えるとチームの行動パターン(開発プロセス)は一緒のことが多いためです。 この時点で「開発効率」をあげてもムダだと判断できた。 つまり、リリースまでに時間がかかっているからといって、開発者を増やせばよいというのは当てはまりません。
3. 改善ポイントを定める
可視化したら、改善するべきポイントを定めます。下記ですと
- ステークホルダーとの調整
- リリース準備 + 作業 が該当します。
4. Let’s 改善
あとは、Let’s 改善していくのみです。ここのどう改善していくのかは各々の開発者やステークホルダーが議論して対策を練っていきます。 ちなみに表題にもあるとおり、自チームでは ・ステークホルダーとの調整は、不要なMTGをなくした。 ・リリース準備＋作業に関しては、CIを整備しリリース作業者の拘束時間を1m(oneClickでリリースできるように)まで短縮できました。 上記の2つの改善で約200時間の短縮につながりました。
最後の改善のポイントをあげます
まず、現状のVSM(ムダがある)を作成したら、必ず「未来のVSM」つまり「理想の開発プロセス」を記載したVSMを作成してください。 そのリードタイムの差分をとって、改善プロセスのphaseで改善していってください。
以上です。
もっと詳しいVSMの書き方については下記のブログ内にあるスライドをご覧ください。
