こんちは〜。
おせちだと伊達巻が一番好きなとよしーです。
あけましておめでとうございます。2023年ですね。
今年の抱負は、「最近どう？元気？」と気軽に声をかけられる人間になることです。
「久々の人から連絡が来たと思ったらマルチ商法だった」のパターンと間違えられないように気をつけます。
さて、この記事では年始にチーム内でValue Stream Mappingをやってみたことを紹介したいと思います。
Value Stream Mappingってなんや？
製品やサービス、機能を顧客に届けるために必要なプロセスを可視化するためのツールです
引用：https://dev.classmethod.jp/articles/value-stream-mapping/
なぜやるのか？
- 言語化できていない課題が見つかると思ったから
- 単純にいまのチームメンバーで実験的にやってみたかったから
前提条件
- 構成
- 開発者 3名
- マネージャー 1名
- ファシリテーター とよしー
- ツール：Miro
- かかった時間：2時間
やったこと
本当は開発プロセス全体でやると効果的なのかもしれないですが、スモールスタートということでCustomerSuccessチームから来る依頼のプロセスでValue Stream Mappingをしました。
まずスタートとゴールを決める
↓
スタートはユーザーから依頼が来ることに決定
↓
ゴールはユーザーが満足することに決定
↓
各プロセスを書く
↓
チーム名と必要な人数を書く （例：Dev1 = Devが1名）
↓
リードタイムを書く
※ 前のプロセスの完了から該当プロセスの完了までにかかる時間
↓
プロセスタイムを書く
※ 該当プロセス自体にかかる時間
↓
同一チームが連続して行うプロセスの場合は実線、チームが変わる場合は破線でつなぐ
↓
各プロセスのおおよその手戻り率を書く
↓
無駄にマークをつける
※ こちらの記事を参考にさせていただきました
↓
無駄が多い部分の改善案をチームで相談する
↓
ふりかえり
結果/わかったこと
- 待ちの無駄（W）が発生しているプロセスは他チームとのやりとりが関わっている部分に多いことがわかった
- 開発者のレビューの待ち問題に関しては、レビューしやすくするように粒度を小さくするように改善していく案が出た
- CustomerSuccessとのやりとりでの待ち問題に関しては、空中戦ではなく適宜直接話す改善案が出た
- 手戻り率が30%を超えている箇所が、全体のプロセスで35%以上あった
- 今回作られたValue Stream Mappingが、オンボーディングで役に立つのではという意見がメンバーから出た
- これは自分もはっとさせられた
まとめ
以上、Value Stream Mappingをやってみたの記事でした。
最近、なんとなくですが、
「あ〜なんか課題っぽいな〜」
と
「これは課題だ！」
との間には結構差があるのではないかと思っています。
そんなぼやけている課題をクリアな課題にしていくのに必要なのは、
課題の周辺にある数値だったり定性的なデータになると私は考えています。
上記のようなプロセスをふむと、課題に対する納得感も醸成されるので、当事者意識も持ちやすくなるのではないでしょうか。
Value Stream Mappingはその一助にもなるワークだと思うので個人的におすすめです。
開催にあたってまとまった時間は必要になるかもしれませんが、ぜひやってみてください。