VSM (Value Stream Mapping)を書いたらリリースリードタイムが約200時間も短縮できることがわかった話
用語整理
■ VSM (Value Stream Mapping) とは？
- VSM (Value Stream Mapping) とは、「価値の流れ」を可視化した開発プロセスを可視化するための手法、活動になります。
- 詳しくは、 業務プロセス可視化 : VSM (Value Stream Mapping)を参照してください。
■ リードタイム(LeadTime)とは？
- ここでは、要求が発生してからFeatureを開発→リリースするまでにかかる時間と定義します。
問題提起
- 普段、開発をしていて開発プロセスをあまり意識することは少ないかと思いますが少し客観的的見てみるとリードタイムがものすごいことになっていることがあります。
例を出します。
| No | 説明 | 図 |
|---|---|---|
| 1 | 開発者は会員登録機能を2日で開発しました。テストやコードレビューも通っていてバグもありません。機能要件もすべて満たしていていつリリースしても問題ありません。 |  |
| 2 | しかし、リリースするにはエスカレーション的に担当部署へ承認が必要になってきます。色々な人の予定を見てMTGを設置して開催するまでに2週間かかりました。この時点で2日でユーザに届けられたものが16日後になってしまいます。 |  |
| 3 | ただし、自分の部署だけでなく急に他の部署への確認も必要になったりします。別途調整役をたてて、確認するのに2週間かかりました。この時点で2日でユーザに届けられたものが30日後になってしまいます。 |  |
| 4 | 各所にリリース判断の確認をしてもらってやっとリリースできる状態になりました。しかし、リリースするためのデプロイメントパイプラインが整備されておらず手動でリリースする必要があります。リリース手順を記載したチェックリストを作成しレビューするまでに2日かかりました。 |  |
上記の例でいうと、 2日でリリースできたものが実は32日もかかってしまいました。
【個人的に危険と感じる開発プロセスは下記になります。】
→1個でも当てはまれば、あなたのチームにVSMが必要です！
| No | プロセス |
|---|---|
| 1 | Featureをリリースするまでに開発作業よりも「承認 + 確認」などの調整時間のほうが長い。 |
| 2 | 開発工程の中で手作業が多く、自動化されていない箇所がある。 |
| 3 | Featureの開発は終わっているのに外的要因でリリースができない状態が1週間以上ある |
上記のような危険な開発プロセスのような「ムダ」は組織が大きくなればなるほど増えていくような気がします。このような「ムダ」をなくすためには
まず、開発プロセスを可視化して「ムダ」を洗い出す = VSM (Value Stream 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で改善していってください。
以上です。
