バリューストリームマネジメントの製造業とソフトウェアデリバリーにおける違い: 同じ名前、異なる役割

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

バリューストリームマネジメントとは何でしょうか。製造現場では製品ファミリーの物理的な流れを管理し、ソフトウェアデリバリーでは作業項目を追跡します。両者の違いを見ていきましょう。

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

バリューストリームマネジメントとは何でしょうか。誰に聞くかによって答えが変わります。製造現場では、受注から納品までの一つの製品ファミリーの物理的な流れを、責任者一名と少数の共通指標で運営することを意味します。ソフトウェアデリバリーでは、通常、アジャイルのワークフローとDevOpsパイプラインを通じて、アイデアからリリースまでの作業項目を追跡することを意味します。この記事は、検索結果、ベンダーの説明会、またはIT部門との会議でその両方の意味に出会い、それらを区別しておく必要がある業務改善マネージャーを対象としています。

重要なポイント

• 製造現場におけるバリューストリームマネジメントは、受注から納品までの一つの製品ファミリーの物理的な流れを管理するものです。ソフトウェアデリバリーでは、アイデアからリリースまでの作業項目を追跡します。
• 両分野にはリーンという共通の起源があります。待ち時間を見つけ、無駄を取り除き、価値が顧客に届くまでの時間を短縮します。
• ソフトウェアのツールは、フロータイムやフロー効率といったフロー指標と、変更リードタイムやデプロイ頻度といったDORA指標を使用します。
• 工場では、在庫、機械、段取り替え、輸送も扱いますが、ソフトウェアのフロー指標はこれらを対象にしていません。
• バリューストリームマネジメントについて読む際は、まず、その情報源が製造業を指しているのかDevOpsを指しているのかを確認してください。

それぞれの分野におけるバリューストリームマネジメントとは何か

両分野は同じ二つの言葉を使っていますが、考え方は似ています。個々の工程ではなく、顧客に価値を生み出す流れ全体を管理するということです。

製造業では、バリューストリームとは、製品を受注から納品まで届けるために必要な一連の活動を指します。Lean Enterprise Institute（LEI）は、バリューストリームを、コンセプトから発売まで、または受注から納品まで製品を届けるために必要なすべての活動（付加価値を生む活動と生まない活動の両方）と説明しています。工場では、一つの製品ファミリーの受注から納品までの流れに焦点を当てます。これを管理するには、責任者を明確に定め、共通の指標を持ち、定期的にレビューを行う必要があります。

ソフトウェアデリバリーでは、バリューストリームとは、アイデアからユーザーの手元で動くソフトウェアに至るまでの経路を指します。Planviewは、Flow Frameworkを「ソフトウェアデリバリー組織におけるバリューストリームマネジメントに対する、構造化された規範的なアプローチ」と説明しています。Planviewはソフトウェアベンダーであるため、これは一つのベンダーの見解として読んでください。作業項目は、機能、不具合、リスク、技術的負債であり、ツールはチームがそれらを追跡するシステム同士を接続します。

名前は一致していますが、日々の作業は一致していません。

このアイデアはどこから来たのでしょうか。

その根底にあるのはリーン思考です。トヨタは、生産方式が無駄を徹底的に排除し、リードタイムを短縮することを目指していると述べています。トヨタは取り除くべき問題として、ムダ（無駄）、ムラ（不均一）、ムリ（人や機械への無理な負荷）の三つを挙げています。

上記のLEIの定義には、すでに二種類の流れが含まれています。受注から納品までの業務のバリューストリームと、コンセプトから発売までの開発のバリューストリームです。つまり、このアイデアは工場の現場に限られたものではありませんでした。製品開発も一つの流れであり、ソフトウェア開発は製品開発の一種なのです。

だからこそ、2つの世界は今も同じ課題、つまり待ち時間、引き継ぎ、キュー、サイロについて語り続けています。違いは、ストリームの中を何が流れるかにあります。

工場では、バリューストリームをどのように管理するのでしょうか。

工場は物理的な流れを管理します。リーン製造における典型的な要素は次のとおりです。

1. 製品ファミリー。 類似した加工工程と設備を共有する製品群。
2. バリューストリームマップ。 現状と将来の状態における、資材と情報の流れを示す図。
3. オーナー。 多くの場合、バリューストリームマネージャーと呼ばれ、工場管理部門の支援を受けます。
4. 共通の指標。 リードタイム、在庫、納期遵守率、一発良品率などです。
5. 週次レビュー。 アクション、担当者、期日を確認します。

流れるのは資材です。資材は倉庫に保管されたり、機械の前で待たされたり、トラックで輸送されたりします。保管にはコストがかかり、スペースも使うため、在庫は中核的な指標になります。段取り替え、設備能力、シフトパターンも流れを左右します。多くの工場では、ボードの前で行う毎日のミーティングなどのリーン管理の日課も使い、ストリームを可視化しています。M365.FM のリーンマネジメントのトピックページでは、より広い全体像を確認できます。

ソフトウェアデリバリーでは、バリューストリームをどのように管理するのでしょうか。

ソフトウェアデリバリーは情報の流れを管理します。流れるのはワークアイテム、つまりアイデア、チケット、コードの変更です。物理的な在庫はありませんが、レビュー、テスト環境、リリース枠を待つことになります。

一般的に使われる指標は2種類あります。

• フローメトリクス。 Flow Framework では、フロー速度、フロー時間、フロー効率、フロー負荷、フロー分布の5つを挙げています。Planview の要約はこれらを問いの形で示しています。価値の提供は加速しているか、価値を得るまでの時間は短くなっているか、作業は上流で待たされていないか、需要が能力を上回っていないか、投資は新たな価値と既存の価値の保護にどう配分されているか、という問いです。
• DORA メトリクス。 DORA 研究プログラムは、ソフトウェアデリバリーのパフォーマンス指標を、スループット（変更のリードタイム、デプロイ頻度、デプロイ失敗からの復旧時間）と不安定性（変更失敗率、デプロイ手戻り率）に分類しています。

この分野におけるバリューストリーム管理プラットフォームは、チケットシステム、コードリポジトリ、ビルドパイプラインを接続し、チームがアイデアからリリースまで価値がどのように流れ、顧客にどれだけ早く届いているかを把握できるようにします。その結果、デリバリープロセスのバリューストリームマップが得られます。事業部門のステークホルダーは、これを使って作業がどこで待たされているかを確認し、ビジネス価値について認識を合わせます。

2つはどこが違うのでしょうか。

並べて比較すると分かりやすくなります。

• 何が流れるか。 工場では資材と注文です。ソフトウェアではワークアイテムとコードです。
• どこで待つか。 工場ではキュー、バッファ、倉庫で待ちます。ソフトウェアではバックログ、レビュー、環境で待ちます。
• 主な指標。 工場ではリードタイム、在庫、納期遵守率、歩留まりです。ソフトウェアではフロー時間、フロー効率、変更のリードタイム、デプロイ頻度です。
• 一般的なオーナー。 工場ではバリューストリームマネージャーまたは生産オペレーションの責任者です。ソフトウェアではプロダクトオーナー、プラットフォームオーナー、またはIT責任者です。
• データソース。 工場ではERP、MES、現場のデータです。ソフトウェアではチケットシステムとビルドシステムです。
• 一般的な目的。 工場ではリードタイムの短縮と安定した納品です。ソフトウェアでは変更のより速く安全なリリースです。

共通しているのは、流れ全体を見渡し、どこで待たされているのかを問う習慣です。

あなたの検索にはどちらの意味が当てはまるでしょうか。

ページを読んだり、ベンダーと打ち合わせをしたりする際には、次の簡単な判断基準を使ってください。

• 文章がチケット、パイプライン、リリース、スプリントについて述べていれば、ソフトウェアデリバリーとDevOpsの意味です。
• 注文、機械、在庫、シフト、タクト（顧客需要によって決まるペース）について述べていれば、製造業の意味です。
• 両方について述べている場合は、そのツールがどのデータを読み取るのかを確認してください。

略語のVSMは混乱のもとになります。マッピングを意味する場合もあれば、マネジメントを意味する場合もあるからです。同僚には、どちらの意味で使っているかを伝えてください。アジャイルとDevOpsの進め方を推進するIT責任者は、多くの場合ソフトウェアの意味で使っています。工場にいるバリューストリームマネージャーは、物理的な流れの意味で使っています。ボトルネックという言葉でさえ意味が変わります。工場では出力を制限する機械や工程を指しますが、ソフトウェアでは多くの場合レビューやテストの段階を指します。それでも両分野の目標は、無駄を排除し、価値が顧客に届くまでの時間を短縮することです。そのため、一方の分野で有効なアイデアは、もう一方でも検討する価値があります。

例：両方の世界で同じ計算を行う

これは架空の例です。ここに示す数値は実測値ではなく、以下の指標も、ベンダーの計算式ではなく、計画用のシンプルな指標です。

製造現場とソフトウェア開発の両方で使える指標を一つ挙げます。作業が実際に行われている時間の割合です。実際の作業時間を、経過時間の合計で割ります。

• 製造現場の場合。ある注文は、流れの中に10営業日とどまります。チームが調べたところ、その製品に対して実際に作業が行われたのは合計1日でした。割合は1÷10で、10パーセントです。
• ソフトウェアの場合。ある機能は、着手からリリースまでに暦日で20日かかります。開発者とテスターが実際に作業したのは合計3日です。割合は3÷20で、15パーセントです。

どちらの場合も、大部分の時間は待ち時間です。改善策も似ています。仕掛かり作業を制限し、引き継ぎを減らし、より小さな単位で出荷することです。違うのは、待ち時間をどこで探すかです。工場では現場を歩き、キューに積まれたパレットを数えます。ソフトウェアでは、チケットの履歴にあるタイムスタンプを確認します。

よくある間違い

• 検索結果を取り違える。DevOpsのバリューストリーム管理に関するベンダーのページは、工場の役には立ちません。
• ソフトウェアの指標を工場に持ち込む。デプロイ頻度は、加工セルにとっては意味がありません。
• 工場の指標をソフトウェアに持ち込む。在庫回転率は、バックログにあるチケットには当てはまりません。
• 共通する教訓を無視する。仕掛かり作業を制限し、フィードバックループを短くすることは、どちらの分野でも学べることです。
• 流れを定義する前にツールを購入する。どちらの分野でも、先に責任者と指標を決める必要があります。

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

工場にとって有用なツールは、生産データを扱うものです。ERPシステムや現場から得られる注文、工程手順、キャパシティ、在庫などです。これらのツールは、チケットの待ち行列ではなく、物理的な流れを可視化するのに役立ちます。

iFAKTは、シュトゥットガルトに拠点を置く、インダストリー4.0向けのコンサルティング会社兼ソフトウェアスペシャリストで、2001年に設立されました。製造業者が生産および物流プロセスを計画・最適化する支援を行い、Polarisソフトウェアを開発しています。どのベンダーを検討する場合でも、そのデータモデルが物理的な流れに適合しているかを確認してください。

次のステップ

あなたにとってバリューストリーム管理とは何でしょうか。工場を運営しているなら、それは一つの製品ファミリーの物理的な流れのことであり、ソフトウェアデリバリーの記事は脇の話題です。今週、一つの製品ファミリーを選び、その流れに責任者がいて、共有する指標が3つあるかを確認してください。