データに基づくバリューストリームマッピング：ストップウォッチではなくERPデータを使う

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

デジタルのバリューストリームマッピングは、ERPと現場データからマップを作成します。必要なデータ、手順、限界、管理職向けの具体例を紹介します。

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

デジタルのバリューストリームマッピングは、ストップウォッチと1日分の観察ではなく、記録済みデータからバリューストリームマップを作成します。受注、工程表、在庫記録、生産実績フィードバックにより、多数の受注についてのサイクルタイム、待ち時間、在庫を一度に把握できます。本ガイドは、ERPデータを持ち、手作業によるマッピングをどこまでデータで置き換えられるかを知りたい工場長を対象としています。必要なデータ、段階的なマップ作成手順、具体例が示す内容、そしてデータだけでは誤解を招く点を説明します。

重要なポイント

• デジタルのバリューストリームマッピングは、ストップウォッチと1日の観察ではなく、受注、工程表、在庫、生産実績フィードバックなどの記録済みデータからマップを作成します。
• 従来のマップは一時点のスナップショットです。データを使えば、受注ごとに時間や在庫がどれだけばらつくかを示せます。これは一度の現場歩行では見えません。
• ERPデータからは通常、需要、受注、工程表、在庫が得られます。現場のシステムは、工程ごとの実際の開始・終了時刻と数量を加えます。
• データの信頼性は、その裏にある登録の質で決まります。数値を信用する前に、現場を歩いて流れを確認し、数値が何を意味するのかを確かめてください。
• データは どこを見るべきかを見つけること、そしてマップを頻繁に更新することに使ってください。原因の理解には現場歩行を使い、チームと改善策について合意してください。

なぜストップウォッチとスナップショットでは不十分なのですか。

バリューストリームマッピングは、リーンのプロセスマッピング手法です。通常は製品ファミリーごとに、製品やサービスを顧客に届けるための材料と情報の流れを描きます。工場には製品ファミリーごとに複数のバリューストリームがあり、それぞれに個別のバリューストリームマップが必要です。従来の手法は現場では有効ですが、限界もあります。ダルムシュタット工科大学（TU Darmstadt）の生産管理・技術・工作機械研究所（PTW）は、データ支援型バリューストリーム手法についてのページで、その限界を次のように挙げています。

• バリューストリームマップは静的です。スナップショットと推定に基づいており、ばらつきを捉えられません。
• 時間、在庫、主要指標を手作業で記録するため、マッピングを繰り返すには非常に手間がかかります。
• このモデリング言語は単純な直線的な流れに適しているため、分岐する流れや複数の製品ファミリーは捉えにくいです。
• どの工程を選び、正しいデータをどう記録するかは、ユーザーの経験に左右されます。

PTWは最初の産業界プロジェクトについて、顧客需要、製品ファミリーの生産量比率、共有リソースへの設備割り当てが、専門家の最初の推定値と比べてそれぞれ20パーセント以上修正されたとも報告しています。これは研究プロジェクトの結果であり、お客様の工場には当てはまらないかもしれません。ただし、推定値はデータと照合して確認する価値があることを示しています。

手作業によるマッピングには、もう一つの弱点があります。AllAboutLeanのChristoph Roserは、従業員に聞くだけでは理想的な状態しか分からず、現実は分からないと指摘しています。重要なのは標準からの逸脱です。彼は、現状を現場で自ら書き出し、情報を自分で確認することを勧めています。彼の記事Practical Tips for Value Stream Mappingでは、読者コメントの中で、現場観察で得たデータはMESなどの報告システムのデータと照合すべきだとも指摘されています。この照合は双方向に働きます。データで現場観察を検証し、現場観察でデータを検証するのです。

デジタルバリューストリームマッピングとは何で、どのようなデータを使うのでしょうか。

デジタルバリューストリームマッピングは、データドリブンVSMやデータベースVSMとも呼ばれ、システム上の記録からバリューストリームマップを作成する手法です。PTWは、トランザクションデータから製品・工程マトリックスを構築する方法や、生産フィードバックとイベントデータを使ってプロセスマイニングを行う方法を解説しています。プロセスマイニングは実際の工程の流れを再構築し、スループット、処理時間、待ち時間などの指標を導き出します。Paryanto、Faizin、Frankeによる2026年の論文Improving Manufacturing Line Design Efficiency Using Digital Value Stream Mapping（Journal of Manufacturing and Materials Processing掲載）は、手作業で集計された静的なデータではなく、リアルタイムの稼働データを用いるフレームワークを提案しています。

データの大部分は、次の2種類のシステムから供給されます。

• 企業資源計画（ERP）。 組織全体にわたる購買、在庫、受注などの取引を結び付ける業務ソフトウェアです。通常、需要、受注、工程表（ルーティング）、在庫の情報を保持しています。
• 製造実行システム（MES）。 作業指示や工程に対する現場の生産実績を記録する現場向けソフトウェアです。ある工程で実際に消費された材料などが含まれます。実際の所要時間と数量を提供します。

以下は経験則として私が行ったマッピングであり、出典に基づくルールではありませんが、データはバリューストリームマップに次のように反映されます。

• 顧客ボックス: 受注履歴から得た1日または1週間あたりの需要。
• 製品ファミリー: 同じ工程表と設備を共有する受注。
• 工程ボックス: 工程表に含まれる作業。
• データボックス: 生産フィードバックから得たサイクルタイム、処理時間、段取り替え時間。
• 在庫の三角形: 在庫記録を1日あたりの需要で割り、在庫日数に換算した値。
• 情報の流れ: 受注や計画が現場にどのように発行・指示されるか。

データに基づくバリューストリームマップは、どのような手順で作成するのでしょうか。

1. 製品ファミリーと期間を選択します。 通常の変動を含められるだけの週数を取り、祝日を含む週は避けます。
2. データを抽出します。 対象のファミリーについて、受注、工程表、在庫、生産フィードバックを取り出します。ベストプラクティスの一つは、生データのエクスポートを保存し、すべての数値を追跡できるようにしておくことです。
3. データを整備します。 テスト用の受注、重複、明らかな入力ミスを取り除きます。各フィールドの意味は、データを入力する担当者に確認します。
4. 指標を計算します。 受注ごとに処理時間、待ち時間、リードタイムを算出します。平均値だけでなく、中央値と範囲も報告します。
5. マップを描きます。 数値を通常のデータボックスとタイムラインに配置します。1分で読めるバリューストリームマップを作成し、抽出の手順は繰り返し実行できるワークフローとして保存して、毎月更新できるようにします。
6. 実際の流れを歩いて確認します。 バリューストリームマップを現場と照合します。2つの工程で在庫を自ら数え、複数のサイクルを観察します。
7. 改善策について合意します。 将来の状態を描き、最も大きなギャップを選び、測定可能な目標を設定し、担当者を割り当てます。変更後にはバリューストリームマップを描き直します。生産、計画、物流の関係者とも共有します。

例：ストップウォッチとデータが一つの工程について示すもの

これは架空の数値を用いた説明のための例であり、実測された事例ではありません。ある工場長が一つの製品ファミリーをマッピングします。需要は1日280個で、1勤務日は25,200秒です。したがってタクトタイムは25,200 ÷ 280 = 90秒になります。

ストップウォッチ。 現場を歩いて溶接ステーションの時間を計測すると、経験豊富なオペレーターが調子のよい日に行った場合で、1個あたり85秒でした。タクトタイムを下回るため、溶接は問題なさそうに見えます。

データ。 4週間分の生産実績フィードバックでは、1個あたりの平均は98秒です。これには、現場確認の日には誰も見ていなかった短時間の停止、手直しのループ、シフトごとの作業速度の低下が含まれています。98秒の場合、溶接の1日あたりの生産数は25,200 ÷ 98 = 約257個です。需要は280個なので、1日あたり約23個、8パーセントの不足になります。溶接はタクトタイムを超えており、ボトルネックです。

待ち時間。 現場確認では、溶接の前に2日分の在庫があることがわかりました。10件の受注記録から、待ち時間(日数)は0.5、0.5、1、1、1.5、2、2、2.5、3、6でした。合計は20なので平均は2日、中央値は1.75日です。10件に1件は6日待たされています。顧客が覚えているのは平均値ではなく6日待った受注なので、平均だけでなく範囲も重要です。

教訓は次のとおりです。ストップウォッチと現場確認によって、もっともらしい全体像は得られました。しかし、データによって、それらが見落としていた2つの点が明らかになりました。このフローでの主な非効率は待ち時間であり、その手前に在庫があることは、上流での過剰生産の兆候です。また、データは注目すべき箇所も示します。溶接と、最も長く待たされている受注です。その理由を明らかにするのが現場確認です。

データに基づくマッピングの限界は何でしょうか?

データは、人が何を入力したかの記録であり、入力された内容が必ずしも実際の作業と一致するとは限りません。オペレーターは、シフトの終わりにまとめて一括入力することがあります。そのため、開始時刻と終了時刻は作業そのものではなく、入力のタイミングを示しています。在庫記録は現場の実態より遅れることもあります。建物間の移動のように、そもそも入力がない作業もあります。待ち時間は、誰も記録しない場所に隠れていることが多いのです。

また、データは理由までは教えてくれません。オペレーターがカートンを取りに40メートル歩いていることや、治具の固定が難しいことは、データからはわかりません。これを知るには、今でも現場、つまり作業が行われている場所(現地現物)に行く必要があります。データは「まずどこを見るべきか」を示す手がかりであり、バリューストリームマップを頻繁に更新するための手段として活用してください。一方、現場確認は理解を深めるための手段です。両方を使って、ムダを特定し、継続的なプロセス改善における小さな変更である改善の一歩を選びましょう。目的は完璧な地図を作ることではなく、フローを最適化することです。両方を実施すれば、それぞれが互いの誤りを補正します。

よくある間違い

• データを盲目的に信頼すること。 各項目がいつ、どのように入力されているかを確認してください。遅れた入力や一括入力は、サイクルタイムを歪めます。
• 現場確認を省くこと。 机上だけで作成したマップは、システムに記録されていることは示しても、工場で実際に行われていることは示しません。
• 平均値だけを使うこと。 良好な平均値の裏に、1つの長い待ち時間が隠れている場合があります。中央値と範囲を示してください。
• すべての製品ファミリーを一度にマッピングすること。 まずは1つの製品ファミリーから始め、後で範囲を広げてください。
• 情報フローを忘れること。 データは資材がどのように動いたかを示します。しかし、スケジュールや受注が現場にどのように届くのかは、別途確認する必要があります。
• データを整理する前にツールを購入すること。 ツールは誤った数値をより速く表示するだけです。まずは入力内容を修正してください。

ソフトウェアはどのように役立つか

データの抽出、整理、結合を手作業で行うには時間がかかり、しかもその作業は繰り返し必要になります。iFAKT の Polaris VSM は、データに基づくバリューストリームマッピングのための iFAKT Polaris のモジュールです。資材フローと情報フローを共同でモデル化し、ムダやボトルネックを可視化します。どのツールを使う場合でも、データの入力方法を確認し、最初のマップを現場で実際に見ている状況と比較してください。

次のステップ

1つの製品ファミリーについて、需要、ルーティング、在庫、生産実績フィードバックを保持しているシステムを一覧にし、各数値を誰がいつ入力しているかを確認してください。そのうえで、その製品ファミリーの4週間分のデータを使ってデジタルのバリューストリームマッピングを試し、フローを現場で歩いて結果を検証してください。