バリューストリームマッピング

ストーリー

田

田中VPoE

問題分析のフレームワークを学んだ。次は組織全体の「価値の流れ」を可視化する手法だ。バリューストリームマッピング — VSMと呼ぶ

あなた

リーンやDevOpsの文脈でよく聞く手法ですね

あ

田

田中VPoE

そうだ。もともとはトヨタ生産方式の「物と情報の流れ図」が起源だ。これをソフトウェア開発に応用する。ポイントは、顧客に価値が届くまでの全工程を可視化すること。自チームの範囲だけでなく、組織横断で全体を見る

あなた

全体を見ると、チーム間の待ち時間とか、見えなかったムダが見えてきそうですね

あ

田

田中VPoE

まさにそこが狙いだ。ある企業では、アイデアからリリースまで60日かかっていたが、実際に価値を生んでいる作業時間はわずか8日だった。残り52日は待ち時間と手戻りだ

バリューストリームマッピングとは

定義

バリューストリームマッピング（VSM）は、顧客への価値提供プロセス全体を可視化し、ムダとボトルネックを特定するためのリーン手法です。

ソフトウェア開発VSMの基本構造

顧客の要望                                              顧客への価値提供
    │                                                        ↑
    ▼                                                        │
[企画] → [設計] → [実装] → [レビュー] → [テスト] → [デプロイ] → [運用]
 PT:3d    PT:5d    PT:10d    PT:2d      PT:3d      PT:1d     PT:-
 LT:10d   LT:12d   LT:15d   LT:5d     LT:8d      LT:3d     LT:-
 %C/A:70%  %C/A:80%  %C/A:85% %C/A:60%  %C/A:90%  %C/A:95%  %C/A:-

PT  = Process Time（実作業時間）
LT  = Lead Time（着手から完了までの時間。待ち時間を含む）
%C/A = % Complete and Accurate（手戻りなく次工程に渡せた割合）

主要なメトリクス

メトリクス	定義	計算例
リードタイム合計	全工程のLTの合計	10+12+15+5+8+3 = 53日
プロセスタイム合計	全工程のPTの合計	3+5+10+2+3+1 = 24日
プロセス効率	PT合計 / LT合計 × 100	24/53 × 100 = 45%
待ち時間合計	LT合計 - PT合計	53 - 24 = 29日

「プロセス効率が45%ということは、55%の時間は何も価値を生んでいない。この55%こそが改善のターゲットだ」 — 田中VPoE

VSMの作成手順

Step 1: スコープを定義する

項目	内容
対象プロセス	アイデアから本番リリースまで（Idea to Production）
対象チーム	関与するすべてのチーム（企画、開発、QA、インフラ、運用）
粒度	チーム間のハンドオフを含む主要プロセス
期間	直近3ヶ月の平均値

Step 2: プロセスステップを洗い出す

各ステップについて以下の情報を収集します。

収集項目	説明
ステップ名	そのプロセスの名称
担当チーム	どのチームが実施するか
プロセスタイム	実際の作業にかかる時間
リードタイム	前工程の完了から当工程の完了までの時間
%C/A	手戻りなく次工程に渡せた割合
WIP	同時に処理中の作業数
待ち時間の内訳	何を待っているのか

Step 3: 待ち時間とハンドオフを可視化する

チーム間のハンドオフと待ち時間:

開発チーム        QAチーム         インフラチーム
┌─────────┐     ┌─────────┐     ┌──────────┐
│  実装    │     │  テスト   │     │  デプロイ  │
│  PT:10d  │     │  PT:3d   │     │  PT:1d    │
└────┬─────┘     └────┬─────┘     └──────────┘
     │                │
     ▼                ▼
  [待ち: 3d]       [待ち: 4d]
  レビュー待ち     ステージング環境
                   の空き待ち

ハンドオフの問題:
  ・情報の欠落（「このPRの背景は？」）
  ・コンテキストスイッチ（受け手が別作業中）
  ・責任の空白地帯（「それは我々の担当じゃない」）

Step 4: ムダの分類と定量化

ソフトウェア開発における7つのムダ（リーンの視点）:

ムダの種類	ソフトウェア開発での例	影響度
作りすぎ	使われない機能の開発	高
待ち	レビュー待ち、承認待ち、環境待ち	極めて高
運搬	チーム間のハンドオフ、ツール間のデータ移行	中
加工そのもの	不要なドキュメント作成、過剰なプロセス	中
在庫	未リリースのコード、WIP過多	高
動作	タスクの切り替え、ツールの使い分け	中
不良	バグ、手戻り、仕様の認識齟齬	極めて高

現状VSMから改善VSMへ

現状VSM（As-Is）の例

現状: アイデアからリリースまで 53日

企画     設計     実装     レビュー   テスト    デプロイ
[10d]    [12d]    [15d]    [5d]      [8d]      [3d]
PT:3d    PT:5d    PT:10d   PT:2d     PT:3d     PT:1d
待ち:7d  待ち:7d  待ち:5d  待ち:3d   待ち:5d   待ち:2d

プロセス効率: 24/53 = 45%

改善VSM（To-Be）の目標

目標: アイデアからリリースまで 25日

企画     設計+実装        レビュー   テスト    デプロイ
[5d]     [12d]           [2d]      [4d]      [2d]
PT:3d    PT:10d          PT:1.5d   PT:3d     PT:0.5d
待ち:2d  待ち:2d         待ち:0.5d 待ち:1d   待ち:1.5d

プロセス効率: 18/25 = 72%

改善ポイント:
  ・設計と実装をクロスファンクショナルチームで統合
  ・PR小分割によるレビュー待ち時間の短縮
  ・テスト自動化による手動テスト時間の削減
  ・デプロイパイプラインの自動化

VSMワークショップの進め方

フェーズ	所要時間	内容
準備	事前	データ収集、参加者招集（各チーム代表者）
現状把握	2時間	全員で現状VSMを作成。付箋を使って壁に貼る
問題特定	1時間	待ち時間、手戻り、ボトルネックを赤で印をつける
改善案出し	1時間	各問題に対する改善案をブレスト
目標設定	1時間	改善VSM（To-Be）を作成し、目標メトリクスを定義
アクション	30分	改善アクションの優先順位付けと担当者決定

「VSMワークショップに関係するすべてのチームの代表者を呼ぶことが重要だ。一部のチームだけで作ったVSMは盲点だらけになる」 — 田中VPoE

まとめ

ポイント	内容
VSMの目的	価値提供プロセス全体を可視化し、ムダとボトルネックを特定する
主要メトリクス	リードタイム、プロセスタイム、プロセス効率、%C/A
7つのムダ	待ち、不良、在庫（WIP過多）が特に影響が大きい
As-Is → To-Be	現状VSMから改善VSMへの移行計画を策定する

チェックリスト

VSMの基本構造とメトリクスを理解した
VSMの作成手順（4ステップ）を把握した
ソフトウェア開発における7つのムダを理解した
現状VSMから改善VSMへの移行の考え方を理解した
VSMワークショップの進め方を把握した

次のステップへ

次は「ステークホルダーマッピング」を学びます。組織横断改善に関わる人々の利害関係と影響力を分析し、効果的な巻き込み戦略を立てましょう。

推定読了時間: 30分