バリューストリームマッピングでよくある失敗と回避策

Disclosure: M365.FM host Mirko Peters works at iFAKT GmbH. This page describes the company factually; paid partnerships and links are labelled as advertising.

By Mirko Peters · 2026-11-11

バリューストリームマッピングの失敗は起こしやすく、そのコストも大きくなります。対象を広げすぎること、アクションにつなげないこと、データの質が低いこと、適切でないチームで取り組むことの4つを避ける方法を解説します。

Automatically translated with AI from the original post. Read the English original

バリューストリームマッピングでよくある失敗は、対象を広げすぎること、行動につなげないこと、観察ではなく記憶に頼ること、そしてフローを知る人を外してしまうことです。本ガイドは、変化につながるマップを作りたい継続的改善マネージャー向けです。マップが失敗する場面を見てきた実務者の知見をもとに、各失敗の回避方法を解説し、1つの推測値がマップ全体の姿をどう変えるかを具体例で示して締めくくります。

重要なポイント

• バリューストリームマッピングでよくある失敗は、対象を広げすぎること、行動につなげないこと、推測や見積もりを観測データの代わりに使うこと、そして適切な人を巻き込まないことです。
• 改善の目標によって対象範囲を決めてください。1つの製品ファミリー、1つのフロー、そして1枚の用紙に収まるマップから始めれば十分です。
• マップは成果物ではありません。担当者と期限を伴う計画の出発点であり、将来状態は次の現状になります。
• 現状は現場で描き、数値は自分で確認してください。データの欠落は推測で埋める理由ではなく、発見事項として扱います。
• フローを知る人と、それを変えられる人の両方を巻き込み、マップの更新は同じチームが続けてください。

バリューストリームマッピングでよくある失敗は何ですか?

バリューストリームマッピングは、製品ファミリーの材料と情報の流れを顧客から仕入先まで描き、無駄を見つけてより良いフローを計画するための手法です。リーン生産方式の中核的なツールです。手法自体は紙の上では単純であり、だからこそチームは手順を飛ばしてしまい、VSMの失敗の多くはそこから生じます。複数の実務者が、何が問題になるかを挙げています。

• Instituto Lean ManagementのSeverino Abad氏は、Planet Leanの記事Avoiding the most common mistakes with VSMで8つの失敗を挙げています。現実と想定の混同、データの質が低いこと、重要な人物の不参加、細部での迷走、マッピングと行動の分離などが含まれます。
• Jeff Pierce氏はValue Stream Mapping Gone Wrongで9つの失敗を挙げています。不適切なチーム編成、指標の欠如、分析麻痺、行動につながらないマップなどです。
• Tom Voss氏は、Value Stream Mapping: Lessons from the Frontの中で、教訓を対象範囲、人、データ、フォローアップの4つに分類しています。

これらのリストは大きく重なっています。以下の4つのセクションでは、どのリストにも現れる失敗、つまり対象範囲、行動、データ、人について扱います。

マップの対象を広げすぎないようにするには、どうすればよいですか?

VSMの落とし穴は、多くの場合、対象範囲から始まります。Abad氏は、一度にすべてをマップしようとすると分析麻痺を招くと述べ、チームは変更対象として選んだプロセスに集中すべきだとしています。Pierce氏も同じ点を指摘しています。すべてをマップすると、チームは細部で迷子になります。

では、どの程度の詳細度が適切でしょうか。情報源によって数字が異なるのは、それぞれ異なるレベルを見ているからです。

• Christoph Roser（AllAboutLean）は、Practical Tips for Value Stream Mapping の中で、工程ボックスは4〜15個が適切な範囲であり、30個を超えるのは時間の無駄だと述べています。また、マップは1枚のA3用紙に収めるべきだとしています。収まらない場合は、情報が多すぎるということです。
• Voss は、改善目標によって詳細度を決めるべきだと述べています。工場全体のマップは全体のリードタイムに焦点を当てます。作業セルのマップには、秒単位の作業時間と個別の在庫数が必要です。経験則として、主要な流れは20〜30ステップとし、詳細は後から追加する方が、ステップを統合するよりも容易だと指摘しています。

Roser と Voss はいずれも、詳細すぎることに警鐘を鳴らしています。Voss はさらに、詳細すぎると問題が隠れ、詳細が少なすぎると重要な細部が見えなくなると付け加えています。また、マップはボトルネックが見えるようにするべきだとしています。

工場のすべてのバリューストリームを一度にマッピングするのは、規模を大きくしただけの同じ過ちです。実践的なルールは、製品ファミリーを1つと、「リードタイムはどこで費やされているのか？」のような問いを1つ選ぶことです。その問いに答える各工程ステップを、サイクルタイム、段取り替え時間、在庫とともに描きます。マップが1枚のシートを超えて広がるなら、おそらく複数のバリューストリームを描いており、それぞれに独自のマップが必要です。

行動につながらないマッピングを、どう避ければよいでしょうか？

引き出しにしまい込まれるマップは、バリューストリームマッピングの過ちの中で最もコストがかかります。Voss は、バリューストリームマップは単独の成果物ではなく、計画の出発点であり、その計画は実行されなければならないと書いています。各バリューストリーム計画の期間は約6か月に限定し、その後は将来の状態が新たな現状となり、サイクルを繰り返すべきだとしています。Pierce も同様に率直で、マップだけではバリューストリームは改善しないため、将来の状態を設計し、変更を実施すべきだと述べています。

Abad は勢いの重要性について指摘しています。優れたマップは生きたものであり、時間の経過とともに工程の変化を反映します。初期の1枚のマップを関係者への周知に使ったまま更新しないと、マップは陳腐化してしまいます。また、マップを仕事のやり方を説明するためだけに使うと、チームが現場（gemba：仕事が行われる場所）で情報収集に費やした努力が報われません。

以下のステップで、マップを行動に結びつけ続けられます。

1. 1ページの計画を作成する。 各改善について、担当者と期日を記し、マッピングのワークショップが終わるまでに作成します。
2. 改善領域ごとに担当者を1人割り当てる。 Voss は、領域ごとにプロジェクトマネージャーを置くことを推奨しています。
3. マップの後にカイゼンイベントを実施する。 カイゼンとは、小さなステップで改善を重ねることを意味します。Pierce は、まずマッピングで計画と目標を設定し、その後にイベントを実施して具体的な改善を進めることを勧めています。
4. 早期の成果を周知する。 Voss は、マップを実際の改善につなげることを手伝った従業員ほど、次のマッピングワークショップへの参加に前向きになると指摘しています。
5. 変更を1サイクル行うたびに、マップを描き直す。

データの質が低い場合や、適切でないチームで進めてしまう場合は、どう避ければよいでしょうか？

どちらの過ちも、実在しない工場を描いたマップになってしまいます。

データ。 Abad は、物事が実際にどのように起きているのか、人々がそれをどう説明するか、本来どうあるべきかを切り分けるのは難しいと指摘しています。観察ではなく推測に頼ると、このギャップは広がります。実際の情報が欠けていると、チームは平均値や古い数値を使うことになり、タクトタイムやOEE（設備総合効率）の信頼性が損なわれます。Roser も同意見です。現状のマップは現場で描くべきだと述べています。別の場所で描かれたマップは、物事がどうあるべきかを示してしまうからです。また、従業員に尋ねるだけでなく、情報は自分自身で検証すべきだとしています。

Voss は、情報に欠けがあるチームにとって有益な指摘をしています。不完全または不正確なデータ自体が流れの阻害要因であるため、データの欠落は発見事項として扱うべきだというものです。また、現状データは、時間観測、在庫数の確認、現在の品質指標によって検証することを提案しています。Pierce は、正確で最新のサイクルタイムが必要だと述べています。推定値や古い指標では、分析の質が低くなります。

人。 Pierce は、業務を理解し、リーダーを含めて変更を行う権限を持つ、部門横断的なチームを推奨しています。そうしないと、その場の誰も変更できない工程をマッピングしてしまう可能性があります。Abad は、流れを形作る非公式の専門家に、現状の定義に関わってもらうべきだと付け加えています。彼らがいなければ、マップは工程が実際にどう機能しているかを捉えられません。Voss は、同じチームがマップを継続的に更新し続けることを勧めており、それによって工程が現状に即したものであり続けるとしています。

例：1つの推測された数値が全体像をどう変えるか

これは架空の数値を使った例であり、実測に基づくケースではありません。あるチームが1つの製品ファミリーの5つの工程をマッピングします。需要は1日あたり200個、稼働日1日は25,200秒です。1個あたりの処理時間は200秒で、そのうち120秒が付加価値のある時間です。

記憶に基づく見積もり。 チームは、各工程に約1日分の在庫があると話しています。これにより待ち時間は5日、つまり5 × 25,200 = 126,000秒となります。リードタイムは126,000 + 200 = 126,200秒です。付加価値率は120 ÷ 126,200 = 約0.095%です。

実際の数量に基づく計算。 現場では、各工程の前にある在庫を数えます。結果は400個、300個、300個、200個、200個で、合計1,400個です。1日200個のペースでは、待ち時間は7日、つまり7 × 25,200 = 176,400秒になります。リードタイムは176,400 + 200 = 176,600秒です。付加価値率は120 ÷ 176,600 = 約0.068%です。

この差が意味すること。 実際のリードタイムは50,400秒、つまり2稼働日分、チームの想定より長くなっています。記憶に基づく数値より約40%多い計算です。将来の状態の目標を、記憶していた在庫の半分、2.5日に設定するとします。実際の7日に対しては、4.5日、約64%の削減が必要になり、50%ではありません。50%で計画するチームは、理由がわからないまま目標を逃すことになります。

数えるのに1時間もかかりませんでした。思い込みのせいで、チームは誤った目標を立てることになりました。

よくある間違い

スコープ、アクション、データ、人の4つ以外にも、情報源には次のような失敗が挙げられています。

• 顧客が何を価値と考えているかを思い込むこと。 Pierceは、顧客またはその代理人と話すよう助言しています。これがなければ、どの工程が付加価値を生んでいるかを判断できません。
• 戦術的な改善にマップを使うこと。 Pierceは、戦略的な方向性を合わせるためにバリューストリーム全体をマッピングし、特定の領域を深く掘り下げる際にはプロセス単位のマッピングを使うよう提案しています。
• 情報フローのルールを守らないこと。 Roserは、各プロセスには1つの情報フローがあるべきであり、情報フローは在庫で終わるべきではないと述べています。在庫は情報に基づいて行動できないからです。
• オフィス業務に工場の記号を当てはめること。 Abadは、オフィスやプロジェクトの流れは直線的ではないと指摘しています。どの部門が各活動を担当しているかを示すために、スイムレーン図を使うことを提案しています。
• 大規模な再設計を一度に行うこと。 Pierceは、小さく段階的な変更を好みます。まず一連の変更を実施し、その影響を確認してから、次の一連の変更に進みます。
• 参加者を限定すること。 Abadは、マッピングを特定の機能に限定すると現実の一部しか見えず、対立を生むおそれがあると警告しています。

ソフトウェアができること

ソフトウェアは現場を歩くことの代わりにはならず、誤ったスコープを修正することもできません。手法が明確になった後であれば、マップを最新の状態に保つのに役立ちます。iFAKT's Polaris VSMは、データに基づくバリューストリームマッピングのためのiFAKT Polarisのモジュールです。素材と情報の流れを共同でモデル化し、ムダやボトルネックを可視化します。数値の更新に使い、流れを理解している人を議論の場に残しておきましょう。

次のステップ

前回のVSMを、スコープ、アクション、データ、人の4つのテーマで見直してください。そのうえで最も弱い点から改善し、次の取り組みでバリューストリームマッピングの失敗を繰り返さないようにしましょう。