最適なバリューストリームマッピングソフトウェア：重要な判断基準

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-12

最適なバリューストリームマッピングソフトウェアとはどのようなものでしょうか。手法、データ、コラボレーション、規模に関する判断基準に加え、ベンダーへの質問や、オペレーション マネージャー向けの危険信号を解説します。

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

すべての工場に共通する唯一の最適なバリューストリームマッピングソフトウェアは存在しません。自社に合うツールには3つの条件があります。手法に忠実であること、自社のデータと連携できること、そしてストリームを運用する人が専門家に頼らず編集できることです。本記事では、オペレーション マネージャーやリーン推進担当者に向けて、改善を進めやすいツールと、見た目がよいだけのツールを見分けるための判断基準と質問を紹介します。自社のデータを使わずに行うベンダーのランキングは誤解を招くため、ベンダーの順位付けは行いません。

重要なポイント

• 自社工場に最適なバリューストリームマッピングソフトウェアとは、手法を損なわず、自社のデータを使い、ストリームを実際に運用する人が編集できるツールです。
• ツールが物の流れと情報の流れの両方をモデル化できるか、現状マップと将来マップの両方に対応しているか、製品ファミリー単位で作成できるかを確認してください。
• サイクルタイム、段取り替え、稼働率、歩留まりといった標準的な工程データは、自由記述のテキストではなく、ツール内の項目として持てるようにしてください。
• データの出所、更新頻度、そして誰が検証するのかを確認してください。古いデータから作られたマップは、見栄えのよいポスターにすぎません。
• 候補となるすべてのツールを、自社データを使った実際の1つの製品ファミリーで試してください。試用を拒否されたら、それ自体が答えです。

自社工場に最適なバリューストリームマッピングソフトウェアを決める要素は何でしょうか。

次の3つのテストを、この順番で考えてください。

1. 手法。 ツールはバリューストリームマッピングのロジックを維持しているか、それとも一般的なフローチャートにリーンのテンプレートを載せただけか。
2. データ。 マップは自社工場の実際の数値を保持しているか、そして再入力なしで更新できるか。
3. 人。 そのストリームを担当するチームが、実際に毎週そのツールを開くか。

1つ目のテストに落ちるツールは、研修では改善できません。2つ目のテストに落ちるツールは、すぐに古くなるマップを生みます。3つ目のテストに落ちるツールは、ワークショップが終わると使われなくなります。選定の失敗の多くは、デモで見やすい1つ目のテストだけで判断することから生じます。

このソフトウェアは手法を損なわずにいられるか。

まず、Lean Enterprise Institute（LEI）がバリューストリームマッピングをどう定義しているかを確認しましょう。それは、注文から納品までの製品を成立させる物の流れと情報の流れのすべての工程を示す図です。LEIは、このマップが製品の物理的な移動と、各工程に何をいつ作るかを伝える情報の両方を示すこと、そして両者のつながりを示せるツールは他にないと指摘しています。また、バリューストリームマッピングに関するLEIのページでは、通常は現状マップから始め、続いて将来マップを作成すること、そして1つの製品ファミリーから始めるべきことも述べられています。

これを、ツールを確認するための項目に置き換えると次のようになります。

• 2つの流れ。 工程が受け取るスケジュールや注文信号といった情報の流れを描けるか。単に箱を一列に並べるだけになっていないか。
• 現状と将来の状態。 同じ製品ファミリーについて両方を保持し、比較でき、古いバージョンも残せるか。
• 製品ファミリーを単位とする管理。 製品とマップをファミリーごとにグループ化できるか。これにより、工場内に無関係な図面が散在する事態を避けられるか。
• 標準アイコン。 LEIのバリューストリームマッピングの基礎に関する記事は、標準アイコンを使わないことを落とし穴として挙げています。他の人がマップを読みにくくなるからです。ツールは標準のアイコンセットを提供すべきで、利用者それぞれに独自のアイコンを考案させるべきではありません。
• プロセスデータを項目として持つ。 同じ記事では、各工程の下に置くプロセスデータボックスを解説しています。サイクルタイム、停止時間、稼働時間、段取り替え時間、完成度（%C/A）、稼働率などがその対象です。さらに、リードタイムを示すタイムラインも取り上げています。これらが構造化された項目であれば、ソフトウェアは合計したり、マップ同士を比較したり、ダッシュボードにデータを送ったりできます。図形内のテキストとして書かれているだけでは、それができません。
• 検証できる計算。 ツールがリードタイムや比率を表示するなら、その計算方法を確認できるべきです。たどれない数値は、懐疑的な工場長の最初の質問で崩れてしまいます。

この手法に不慣れな方は、LEIが強調している点も覚えておいてください。目標は完璧な現状マップを作ることではなく、ドックからドックまでの流れを理解することです。何もみえるようになる前に200項目の入力を求めるツールは、誤った方向へ導いてしまいます。

データはどこから取得すればよいのでしょうか？

この基準は、描画ツールとデータ主導のツールを分ける判断材料になります。

数値をマップに取り込む方法の一覧を、ベンダーに求めましょう。

• 手入力。 現場を歩いた後にチームが入力します。常に可能で、多くの場合は適切な出発点です。
• インポート。 スプレッドシートやエクスポートファイルから取り込みます。たとえばERPシステムの受注、工程順序、在庫データなどです。
• 連携。 ERPや工場の現場システムと接続し、人が介在せずに数値が更新されます。

次に、より踏み込んだ質問をしてください。

1. どの項目を自動で入力でき、どの項目は人の確認が必要ですか。
2. データの更新頻度はどのくらいで、マップ上で最終更新日を確認できますか。
3. インポートした数値が現場で見えている実態と食い違った場合、どのように修正しますか。その修正は次回のインポート後も残りますか。
4. 工場におけるデータ品質の責任者は誰ですか。この問いには、ツールは答えられません。

現実的な考え方は、システムのデータで確認すべき箇所を見つけ、現場で裏付けを取ることです。ERPの工程順序には、計画上の時間が記載されていることが多く、機械の現場で実際に起きていることとは異なります。値を実測か計画かで区別してマークできるツールであれば、その差を見えるように保てます。

誰が使い、誰が見る必要がありますか。

導入が定着するかどうかで、ツールの価値が決まります。そのため、評価の段階から実際の利用者を巻き込んでください。

• 共同編集。 複数の人が同じマップを、理想的にはブラウザ上で、ファイルをやり取りせずに編集できるべきです。ライン上でタッチスクリーンやタブレットでも使えるかを確認してください。デスクで描かれたマップは、機械のそばで描かれたマップに負けるからです。
• 変更履歴。 誰がいつ何を変更したかを把握でき、以前の状態に戻せる必要があります。
• 読み取り専用アクセス。 工場長やその他の部門は、編集ライセンスがなくてもマップを閲覧できるべきです。少なくとも、誤って変更してしまう心配がない状態であることが望まれます。
• コメントとレビュー。 フィードバックはメールのやり取りではなく、マップ上で行われるべきです。
• アクセス制御。 コストや顧客情報など、バリューストリームのデータの一部は全員に見せるべきではありません。サイト、ストリーム、役割ごとにアクセスをどう設定できるかを確認してください。

マップから得たKPIをダッシュボードに載せる場合、Microsoft環境ではPower BIが一般的な出力先です。Microsoftは、これの行レベルセキュリティをMicrosoft Learnで解説しています。フィルターを設定したロールによって、ユーザーが閲覧できる行が決まります。この制限は、ワークスペース内で閲覧者ロールを持つユーザーに適用されます。工場の数値を適切な閲覧者に共有するには便利ですが、制限できるのは行であり、列ではありません。データモデルを設計する際は、この点を考慮してください。

製品ファミリーやサイトをまたいで、どのように拡張できますか。

1つのマップは簡単に管理できます。3つの工場にまたがる20のマップは、ガバナンスの課題になります。

ベンダーに、次の点をどう扱うかを確認してください。

1. 命名と構造。 サイト、ストリーム、製品ファミリーごとにフォルダーやライブラリーを分け、利用者が適切なマップを見つけられるようにできるかどうかです。
2. 共通テンプレート。 アイコン、データ項目、KPI定義について全社標準を設けます。
3. KPIの統一。 拠点ごとにリードタイムの計算方法が違うなら、拠点間の比較には意味がありません。
4. 責任の所在。 各マップにはツール内で担当者を明記し、データが古くなったら担当者に通知が届くようにします。
5. 拠点ごとの差異。 共通標準を崩さずに、拠点独自の工程を反映できる余地が必要です。

規制の厳しい業界向けの既製テンプレートについての主張には注意してください。テンプレートは構成の整理に役立ちますが、それだけでコンプライアンスを満たすわけではありません。コンプライアンスが重要な場合は、ツールがどの具体的な文書を出力するのかを確認し、品質保証部門と内容をチェックしてください。

IT部門と購買部門は何を確認すべきでしょうか。

デモに心を奪われてから相談するのではなく、早い段階でIT部門と購買部門を巻き込んでください。

• ホスティングとセキュリティ。 データはどこに保存されるのか、また、どのようなセキュリティ関連のドキュメントが提供されているのかを確認します。
• サインイン。 既存のシングルサインオンで利用できるかどうかを確認し、パスワードを別途管理しなくて済むようにします。
• エクスポート。 すべてのマップとデータを、利用可能な形式で取り出せるかどうかを確認します。取り出せない場合、そのツールに囲い込まれることになります。
• 料金モデル。 ユーザー単位、マップ単位、拠点単位、モジュール単位のいずれでしょうか。実際に想定される閲覧者数でコストを試算してください。
• サポートとトレーニング。 マップのインポートがうまくいかないときに誰が対応するのか、また、どの言語と時間帯で対応してもらえるのかを確認します。
• ロードマップと責任の所在。 ベンダーが方針を変更した場合、その製品はどうなるのでしょうか。

回答はどのように評価し、危険信号をどう見極めればよいでしょうか。

デモの前に各評価基準に重み付けをしてください。そうすれば、見栄えの良いプレゼンテーションによって優先順位が書き換えられることを防げます。基準は、手法やデータのインポートのような必須要件と、特定のレイアウト機能のような「あれば望ましい」要件に分けます。リーン推進担当、工場長、IT部門には、それぞれの担当領域を採点してもらいます。

注意すべき危険信号は次のとおりです。

• デモでベンダーのサンプル工場しか使わず、自社のデータを一度も使わない。
• 工程データは図として描かれるだけで、数値としては保存されない。
• ベンダーが計算方法を説明できない。
• ベンダー側に、自社のような工場で働いた経験のある人がいない。
• エクスポートに関する説明があいまいか、追加費用を払わないと利用できない。

その後、実際の製品ファミリー1つでパイロットを実施します。最終候補に残ったベンダーには、自社のデータから現状のバリューストリームマップを作成してもらいます。そして、そのフローを担当することになるチームに1週間使ってもらいます。作成にかかった時間、手作業での修正回数、利用者が引き続き使いたいと感じたかどうかを記録しましょう。

よくある間違い

• 図の見栄えで判断する。 洗練されたマップでも、その裏にデータがない場合があります。
• 手法を省く。 製品ファミリーも将来像も定まっていないマップは、ソフトウェアを導入しても改善しません。
• ワークショップのためだけに購入する。 問われるのは、導入から6か月後に誰がそのツールを使っているかです。
• データ品質を無視する。 誤った数値を速くインポートしても役に立ちません。
• リーン推進チームだけで選定する。 IT部門や工場長が後から展開を止めてしまうことがあります。
• ランキングを求める。 自社の制約を考慮せずに書かれた「最良」ツールの一覧は、広告か当て推量にすぎません。

Polarisの位置づけ

パイロットに加えるデータ重視の候補を探しているなら、iFAKT Polarisを検討してみてください。iFAKTは、Polaris VSMを、データに基づくバリューストリームマッピングのためのPolarisのモジュールとして紹介しています。資材の流れと情報の流れを共同で作成でき、ブラウザー上で100%動作し、ムダやボトルネックを見える化します。iFAKTによると、SAPなどのシステムのデータはExcelにエクスポートしてツールにインポートできるとのことです。他の候補と同じ基準で評価し、自社の製品ファミリーの1つを使って判断してください。

関連して検討すべきトピック

• マップから日常業務へ。 ワークショップの後、誰がそのフローの責任を持つのか、また、週次レビューをどのように運営するのかを検討します。
• ERPデータを使ったデータ重視のマッピング。 どの項目をインポートし、どの項目を現場で計測するのか、また、その差異をどのように明示するのかを検討します。
• 将来像の描き方。 将来像マップを、担当者と期限を明記した作業計画にどのように落とし込むのかを検討します。
• バリューストリームのKPI。 フローを表すのに必要な少数の指標は何か、また、それらをダッシュボードでどのように示すのかを検討します。
• 紙かソフトウェアか。 ホワイトボードで十分な場合と、ツールの費用に見合う場合の違いを検討します。

次のステップ

最適なバリューストリームマッピングソフトウェアを選ぶには、評価基準を書き出しておくと判断しやすくなります。まず製品ファミリーを一つ選び、方法・データ・人の三つの観点から必須要件を書き出してください。そのうえで、二社のベンダーに、自社のデータを使って当該製品ファミリーをマッピングしてもらいましょう。