これは ビットバンク株式会社 Advent Calendar 2020 の 8 日目の記事です。
はじめに
はじめまして。PM/QAのJackです。
プロジェクト管理の最適化のために、プロジェクト管理フレームワーク・システム開発フレームワーク（スクラム式）を今年 2 月に導入してからほぼ １０ ヶ月間経ちました。システム部を始め、全社的にソフトウェア開発においては色々と改善ができたとは言え、まだまだ課題がたくさん残っております。
今回こちらのブログを通して、どの部署でも課題解決に簡単に取り込める効果的なシンプルなやり方を紹介したいと思います。
VSMとは
- 「価値の流れ」を可視化して「プロセスを改善」 するための手法
- 価値の流れ = Value (chain) stream
- 可視化 = Mapping
- 合わせて、Value stream mapping
- 「価値の流れ」で、全体的（end to end）に効果を与えることが可能なので有名なおかつシンプルな手法である
目的と効果
-
プロセスの可視化
- どこのプロセスにどれだけの時間がかかっているかが可視化できる
- 可視化した上で、効果が高そうな改善ポイントを選べる
- すべての業務プロセスを可視化をすることで対外的に説得力が生まれる
-
プロセスの改善
- どれだけの無駄を省き、時間的・コスト的短縮ができたかを可視化できる
歴史的背景
第二次世界大戦後、トヨタの成功（TPS）によって、リーンプリンシパル・リーンマネージメント手法が世界に広がった
- TPS（リーンマネージメント）の目的は、継続的インクリメンタル改善。基本的に無駄を省いて、効率性を目指す
- VSM はリーンマネージメント手法で、生産や物流、ソフトウェア開発などの工程を改善する際に用いる、現状を把握し将来のあるべき姿を明確にするために作成されるプロセス図のこと
VSMに行く前に、
アジャイル（Agile）とリーン（Lean）は一緒ではない
| 区分 | アジャイル | リーン |
|---|---|---|
| 目的 | 短いインターバルで物事を回し、変更に柔軟に対応する | 無駄を減らし、効率性を目指す。現時点で価値を生み出していないアクティビティーを検出し、省くのが目的 |
| アプローチ | Bottom up | Top down |
| フォーカス | ソフトウェア開発の一環として扱い、短いスパーンで継続的改善をはかる | Value chain全体を対象（商品コンセプトが生まれてから〜ユーザに届くまで）とし、全体的（end to end）に効果を与える |
| プロセス | Short delivery cycles, Iterations | End to end delivery、Incremental |
ただ、アジャイルとリーンを一緒にいい感じで扱うことにより、良いもの作りができるのは間違いない
VSM作成方法（一般的）
- 用語
- リードタイム /LT (Lead Time)：プロセスが次ステップに移るまでに要した時間の合計（PT+WT）
- 実行時間 / PT (Process Time)：実際にそのプロセスを実行している時間
- 待ち時間 / WT (Wasting Time)：プロセスで待機状態の時間
- SR /完成と正確性の割合：上流プロセスから受け取ったものが手直しせずに使える割合
-
必要なもの
- 横にながーい紙 or White board
- ペン(2色)
- 必要な参加者全員
- 時間的に1.5h~3h
-
アイコンを理解する
- スタートとゴールを明確に定義する
- タスクと人数を入れる
- スタート〜ゴールのタスクを書き出す
- そして書き出したタスクごとに必要な人数を入れる
- WT、PT、LT(WT+PT)を入れる
- このステップでは、各タスクの時間に関係する値を入れていく
- 同じ担当者の場合は実線、別の場合は点線を結ぶ
- 担当者の変わり目を明確にし、スイッチングコストを意識できるようにする
- 1~4を合わせると、
- ツールを書く
- 各タスクで使っているツールを明確にし、ツールの変更に伴うスイッチングコストを意識できるようにしま
- 環境を書く
- 各ツール、タスクの環境を明確にし、環境の変更に伴うスイッチングコストを見える化しま
-
不具合がなく、正常に実行できる比率を書く
-
グルーピング
ここで、
- どのタスクが手戻りが多いか
- どのようなタスクがLTにおけるWTが多いか
- PTは一瞬なのにWTが長いタスクはどれか見えてくる
- 無駄なタスクにマークをつける
- 下記マークがよく使われている
- 改善案を記載する
Case study
1. テーマ：開発〜リリースまで
課題/問題
- Featureをリリースするまでに開発作業よりも「承認 + 確認」などの調整時間のほうが長い
- 開発工程の中で手作業が多く、自動化されていない箇所がある
- Featureの開発は終わっているのに外的要因でリリースができない状態が1週間以上ある
Know-how 1
- どこを改善するべきか、カテゴリー分けする
- 例：今回のケースだと、
- ステークホルダーとの調整
- 開発作業
- リリース準備＋作業
- どのカテゴリーに、リードタイムがかかっているか計算してみる
- 例：
- ステークホルダーとの調整：約85%（228.25h）
- 開発作業：約5%（14h）
- リリース準備＋作業：約10%（26.25%）
VSMを取り入れる（大事なのは、改善ポイント(=ムダ)を見つけること）
-
VSM作成時に使うのは、
- プロセスのタイトル
- LT（Lead time）/PT (Process time) /WT (Wasting time)
- タイムライン
-
VSMを起こすと、
Know-how 2
- 改善ポイントを定める
- 例：
- ステークホルダーとの調整
- リリース準備＋作業
- 改善を行う
- 現状のVSM
- 未来のVSM
- 未来に向けて改善
2. テーマ：End to End（企画〜ユーザに届くまで）
VSMの書き方ルールが一緒なので、下記でこのテーマに当てはまる例を上げるが、詳細は割愛する
例1：
例2：
例3：
活用法
基本的に、
- 能動的に情報を取りに行かなくてもみんなで集まってディスカッションができるようにする
- どんな人でも改善点を見つけられるようにするため、VSMを作ったら常に見えるようにしておくこと
そして、
- 改善ポイントに対するアプローチが完了したら書き直してみる
- みんなでディスカッションしながらアプローチを考えるようにしていくだけで、
無駄なところを改善する = 効果が高いところに手をつけるという習慣が定着するのでは。
最後に
- VSMはとてもシンプルかつパワフルな改善手法であり、Valueを提供している全ての業界で使われれいる
- こんな考えをお持ちの方には、VSMはおすすめ
- 課題が多数あって改善したいけど、何から変えればいいか分からない
- 将来的に目指したい方向性と現状のギャップを掴みたい
- 今のやり方って上手く行っているんだっけ？
- とにかく現状を可視化したい
- 仕事をもっと効率良くしたい
- リソース配分を良くしたい、ROIを高めたいなどなど
- End to endを「可視化し、無駄を検出し、省いていく」ためのアクションを見つけやすいので、ビットバンクでも是非活用していきたい
リーンプリンシパルがとても効果的であり、どの部署でもご活用いただけるので、「つまづいたらVSM書いてみる」的なのりで全然OKです。リーンの考え方をこれからもチャンスがあれば、色々と進めて参りますので、今後ともどうぞよろしくお願いします！
