部門ではなく価値の流れ（バリューストリーム）で工場を組織する方法

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

バリューストリーム型の組織は、部門ではなく製品ファミリーを中心に人を集める体制です。工場長向けに、組織形態の選択肢、6つのステップ、具体的な事例を紹介します。

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

製品ファミリーを製造する人と設備を1つの部門横断チームにまとめ、責任者を1人定め、受注から納品までの流れ全体を測定すれば、工場をバリューストリームで組織できます。大規模な組織変更をせず、段階的に進めることも可能です。本記事は、受注が5つの部門をまたぎ、それぞれが独自の目標を持っている状況で、流れに対する明確な責任者を置きたい工場長を対象としています。組織形態の選択肢、6つのステップ、具体的な事例、変革を停滞させる失敗例を解説します。

重要なポイント

• バリューストリーム型組織では、製品ファミリーの周りに1人の責任者と部門横断チームを置き、流れ全体に説明責任を持つ人を明確にします。
• 開始に大規模な組織再編は不要です。バリューストリーム・マネージャーは、機能別組織やマトリクス組織の中でもリードできます。
• 新しい組織図を描く前に、顧客側の工程の端から、製品の流れ（ルーティング）に基づいて製品ファミリーを定義してください。
• 熱処理炉のような共有リソースは共有のままになることが多いため、ストリーム間で明確なスケジュールを定めておく必要があります。
• 機能別の専門性を維持してください。たとえば、機能別の役割とバリューストリームの役割の間で人材をローテーションさせる方法があります。

バリューストリーム型組織とは何ですか？

機能別組織では、人はスキルに応じて部門に配置されます。購買、機械加工、組立、品質、物流などです。各部門には管理者と目標があります。製品はそのすべての部門を通過しますが、経路全体を所有する人はいません。

バリューストリーム型組織では、単位は製品ファミリーです。Lean Enterprise Institute（LEI）は、製品ファミリーを、類似の加工工程と共通設備を通過する製品とそのバリエーションと定義しています。その製品ファミリーの流れについて、受注から納品まで、1人の責任者と1つのチームが説明責任を負います。

書籍『Learning to See』は、その理由を示しています。企業は部門別に組織されているため、製品ファミリーの流れを所有する人がいないことが多く、各部門は自部門の最適化に走りがちです。LEI の2006年の記事the value stream managerも同じ点を指摘しています。バリューストリームは部門をまたぐため、エンドツーエンドの責任者がいなければ、局所最適が勝ってしまうのです。

なぜバリューストリーム型で組織するのですか？

機能別の工場では、次の3つの問題が繰り返し起こります。

• 局所的な目標が流れより優先される。 ある部門は大きなロットで生産することで自部門の効率目標を達成しますが、次の部門は待たされるか、仕掛品に埋もれます。
• 全体の流れを誰も見ていない。 問題は部門間を移動し、各部門は自分の担当範囲だけを修正します。
• 情報の伝達が遅い。 計画、製造、品質管理が、同じテーブルで話し合うのではなく、会議やメールを介してやり取りしている。

Mike Orzen による LEI の記事 「神話的な」バリューストリームマネージャーでは、最初の問題の例が紹介されています。ある文書管理チームが自らの処理時間を数日から数分に短縮したものの、その無駄を支援先の部門へ押し付けてしまったというものです。

バリューストリーム型の組織では、フローに影響を与える人たちを1つのチームにまとめます。また、ワークフローを顧客のニーズに合わせます。チームは顧客が何を求めているのか、そして注文が各工程をどのように進んでいくのかを把握できます。元Wiremold CEOのArt Byrneは、LEIのリーン会計に関する記事で、セル単位に編成すると、そこで作られる製品ごとの労務費と材料費が明確に見えるようになると述べています。この見通しのよさは組織構造がもたらす副次的な効果ですが、経理部門にとっても役立ちます。

選択肢にはどのようなものがあるでしょうか。

3つのレベルで考えてみてください。これは私自身の計画作成のための整理であり、標準的なモデルではありません。

1. マトリクス内のオーナー。機能別組織はそのままです。バリューストリーム・マネージャーは、影響力を通じて1つの製品ファミリーを率います。LEIの用語集によれば、この役割は機能別組織やマトリクス組織でも機能します。リソースがマネージャーの指揮下に属している必要はないためです。
2. ストリーム・チーム。製造、計画、品質、保全、物流の担当者からなるコアチームが1つのファミリーを担当し、ストリームのボード前で打ち合わせを行います。メンバーは引き続き所属機能に報告しますが、日々の優先事項はストリームから決まります。
3. 完全なバリューストリーム組織。人と設備をストリームに割り当てます。ストリームには専用のセルまたはエリア、専任のリーダー、独自の指標があります。

ほとんどの工場はレベル1または2から始めます。レベル3は、ファミリーに十分な量があり、プロセスが安定している場合に意味を持ちます。

バリューストリームで工場を編成するにはどうすればよいでしょうか。6つのステップ

1. 製品ファミリーを定義します。最初のファミリーについてバリューストリームマップを描き、ワークフローを把握します。製品を製品名ではなく、ルーティング（機械と工程の順序）でグループ分けしてください。Aaron Huntは、少量多品種環境でのマッピングに関するLEIの記事でこの点を解説しています。一見無関係に見える製品でも、同じフローを共有し、まとめるべき場合があります。
2. 開始するストリームを選びます。売上が最も大きいファミリー、または最も問題を抱えているファミリーを選びます。Huntは、売上の50％を占めるストリームを定義して改善し始めたときに大きな成長が始まったと報告しており、その達成には約1年を目標としていたとしています。これは1人の著者の経験であり、規則ではありません。
3. オーナーを任命します。大局的な視点を持つ現場の人物を選び、その人が何を決定してよいかを取り決めます。役割についてはバリューストリーム・マネージャーのエンティティをご覧ください。
4. チームを編成します。製造、計画、品質、保全、物流の担当者を含めます。バリューストリーム・マネジメントは少人数のチームで最もよく機能するため、ボード前で15分間の打ち合わせができる人数に抑えてください。
5. 共通の指標と見直しのリズムを設定します。ストリーム全体のリードタイム、納期遵守率、在庫、品質を指標とし、毎週見直します。
6. 周辺の仕組みを調整します。目標、インセンティブ、報告系統がストリームを支える必要があります。部門がまだ大ロットに対して報酬を得る仕組みのままであれば、ストリームは成果を上げられません。

機能別の専門性は維持してください。2006年のLEIの記事では、機械加工、品質、計画のスキルが失われないよう、機能別の役割とバリューストリームの役割の間で人をローテーションさせることを提案しています。

変革がうまくいっているかどうはどうすればわかるでしょうか。

最初の3か月後に3つの兆候を確認してください。第一に、異なる機能の人たちが同じボード上で同じストリームの数値について話している。第二に、機能間の引き継ぎで生じた問題は、メールでエスカレーションされるのではなく、チームが解決している。第三に、オーナーが3つの部門に問い合わせることなく、今どこでフローが滞っているかを答えられる。これらの兆候が見られない場合、その組織構造は紙の上に存在するだけです。次に取るべき措置は新しい組織図を描くことではなく、権限や指標を見直すことです。

これはアジャイル型のソフトウェア組織と比べてどうでしょうか。

ソフトウェア企業もバリューストリームを軸に組織を編成しています。アジャイル型ソフトウェア開発では、部門横断的なチームが製品を所有し、デリバリープロセスを通じて顧客への価値提供をスムーズにすることを目指します。その考え方は工場と同じです。1つのチームにエンドツーエンドのフローを任せることで、引き継ぎを待つことなく顧客に価値を届けられるようにするのです。

ソフトウェア作者のMik Kerstenは、ソフトウェアのバリューストリームを直線的なパイプラインではなく、ネットワークとして説明しています。複数のストリームがプラットフォームやサービスを共有するという考え方です。工場でも、複数のストリームが一つの炉を共有するのと同じ構造が見られます。どちらの分野でも、ビジネス価値と顧客価値を生み出すために作業の流れを管理し、価値連鎖に沿って価値がどれだけ速く顧客に届いているかを確認します。ソフトウェアのバリューストリーム管理では、チケットやパイプラインを使って作業の流れを可視化します。ソフトウェア提供プロセスはツール上に痕跡を残しますが、工場では受注、工程表、機械にその痕跡が残ります。

違いは、次の例が示すように、工場には機械、在庫、共有設備があるという点です。そのため、工場の組織設計には独自のルールが必要です。バリューストリーム管理の導入という考え方自体は共通していますが、それでも変わりはありません。うまく進めれば、どの部門も同じ作業の流れを見ることができるため、組織のパフォーマンスが向上します。

例: 一つの炉を三つのストリームで共有する

この例は架空のもので、説明しやすいように切りのよい数値を使っています。典型的な意思決定を示すためのもので、実測に基づく事例ではありません。

ある工場には従業員が120名おり、製品ファミリーは三つあります。売上比率はファミリーAが55パーセント、ファミリーBが30パーセント、ファミリーCが15パーセントです。チームはファミリーAから始めることにし、オーナーを任命します。チームは8名で構成され、計画担当者、機械加工セルと組立セルから選ばれた作業者3名、品質技術者、保全技術者、物流事務担当者、そしてオーナーが含まれます。

三つのファミリーはすべて同じ熱処理炉を使用しており、この炉は週に40時間稼働しています。週あたりの炉の必要時間は、Aが18時間、Bが14時間、Cが6時間です。合計は38時間で、利用可能な40時間の95パーセントにあたります。炉を一つのファミリーに専用で割り当てることはできません。

そこで炉は共有リソースのままとし、固定のスケジュールで運用することにしました。各ストリームに時間枠を設定し、週次の計画会議で合意します。さらに、あるファミリーが緊急の作業を求める場合は、他の二人のオーナーの合意を必要とすることも決めました。すべてのリソースがストリームに移管されるわけではありません。目的は、共有のまま残るリソースについて明確なルールを定めることです。

よくある間違い

• ファミリーを定義する前に組織を再編する。 図は工程経路の分析の後に作成します。
• 権限のないオーナーを任命する。 部門長は、オーナーが作業の流れに対して持つ権限を受け入れる必要があります。
• 負荷を確認せずに共有設備を分割する。 稼働率95パーセントの炉がその理由を示しています。
• 機能別のスキルを失う。 ローテーションや専門家コミュニティがなければ、専門知識は失われていきます。
• 古い目標を維持する。 部門ごとの効率目標は、ストリームを損なう原因になります。
• すべてを一度に始める。 一つのストリームはパイロットであり、五つ同時に始めれば停滞するプログラムになってしまいます。

ソフトウェアでどう支援できるか

ストリーム単位で組織を整えるには、事実に基づく情報が必要です。どの製品がどの機械を共有しているか、注文がどれだけ待たされているか、共有設備がどの程度負荷を受けているかといった情報です。ERPシステムの生産データは、人を動かす前にファミリーを定義し、生産能力を確認するのに役立ちます。共通のモデルがあれば、複数の部門のチームが同じ全体像をもとに議論できます。

iFAKTのPolaris VSMは、データに基づくバリューストリームマッピングのためのiFAKT Polarisのモジュールです。物の流れと情報の流れを共同でモデル化し、無駄やボトルネックを可視化します。周辺の日常的な運用の仕組みについては、リーン管理の全般的なテーマで扱われています。

次のステップ

バリューストリームの組織化は、小さく、元に戻せるステップを積み重ねるのが最も効果的です。今週は、製品を工程経路ごとに一覧にし、売上が最も大きいファミリーを選び、パイロット用のオーナーを一人指名してください。