編集可能

バリューストリームマップを描く時のポイント

Agile/DevOps関連のコンサルティングをしている @Ryuzee (吉羽龍太郎)さんがバリューストリームマップを描く時のポイントをツィートしてたのでまとめ。
バリューストリームマップ DevOps VSM
1
Ryutaro YOSHIBA @ryuzee
バリューストリームマッピングは絵を綺麗に書こうとか詳細まで全部書こうとかフォーマットに従おうとか思わなくて大丈夫で、見えるようにすることにすごく意味があるのよ。あと手書きの方が思考の跡とか認識が違ってそうな箇所がはっきり分かるので大きなホワイトボードでやってくださいませ
Ryutaro YOSHIBA @ryuzee
VSMをやるときにまず意識した方がいいのはどの範囲でやるのか?ということ。それによってどんな人に参加してほしいのかも変わってくるので。そして範囲決めであまり広くしすぎるとマップが書ききれないとか議論が発散しすぎるとかもあるので、問題そうに思える領域に絞ってみるのもOK
Ryutaro YOSHIBA @ryuzee
で範囲を決めたらその範囲の議論をするのに適切な人を集めること。現場を知らない人だけ集まっても意味がないので実作業している人を含めて集めること。意外と知らないことが見えてくるはず。マネージャーが必要かどうかはケースバイケースだけどプロセスを変える前にまず穴塞げばいいので必須じゃない
Ryutaro YOSHIBA @ryuzee
で、人が集まったらいきなりVSM書きたくなるけど、それだと抜け漏れも多いのでいまどんなことをやっているか一回流れは無視してダンプしてみるのがおすすめ。ここで付箋を使っておくとVSMに再利用できるんだけど、ためらい痕みたいなのは見えにくいので必須ではない
Ryutaro YOSHIBA @ryuzee
あとはVSM書けばいい。ここでは実際の業務をやってる人を中心に書いてもらえばOK。もし管理職の人とかリーダーがいる場合はあんまり口を出したり、それ違うんじゃないの?とか言わないこと。実は現場は違うやり方をしている可能性もあるので心理的安全性を担保してありのまま書けるように仕向ける
Ryutaro YOSHIBA @ryuzee
VSMを書いているときに心理的安全性が不足していると綺麗すぎるVSMができあがる。実際はそんなことがないのがほとんど。綺麗すぎたらファシリテーターは警戒すべき。あと当日の場作りで安全性を作っておくとよい
Ryutaro YOSHIBA @ryuzee
あとはVSM書くと手戻りが多い箇所、リードタイムが長い箇所が分かるので、具体的にどうすればいいのか考えればOK。その時の優先順位は多くは「手戻り」の割合が高い箇所を選ぶとよいことが多い。手戻りが多いとリードタイムが安定しないので、まずは直行性をあげた方がやりやすい
Ryutaro YOSHIBA @ryuzee
全体最適よりもまず穴を塞いだ方がいいし、ましてや個別最適は「問題を高速につくりだせる」だけになる可能性があるので、まず塞ぐ。塞ぐところには効率はまずは求めないで、塞いだあとに考えればおっけー。
Ryutaro YOSHIBA @ryuzee
ということで、自分のところでもVSM書いてみたいという方ご依頼お待ちしております(壮大な前フリを経由したステマ)

コメント

コメントがまだありません。感想を最初に伝えてみませんか?

ログインして広告を非表示にする
ログインして広告を非表示にする