バリューストリームマッピング

バリュー ストリーム マッピングの歴史

多くの場合、バリュー ストリーム マッピングの起源はトヨタ自動車にあるとされています。しかし、これには諸説あります。トヨタは他の起源からこれを採用したか、リーン生産方式のコミュニティで共有されたアイデアからそれを組織的に成長させたのかもしれません。材料と情報の流れを明らかにするダイアグラムの初期バージョンは、早くも 1918 年のチャールズ・E・クノッペル著『Installing Efficiency Methods』という書籍で見つけられます。

トヨタ社内ではこのプラクティスは「材料と情報のフロー マッピング」と呼ばれて、一種の補完作業として行われました。トヨタのリーン生産方式のプラクティスの成功と活用は、1990 年代の高効率なビジネス チームの最新ベスト プラクティスとしてバリュー ストリーム マッピングを促進するのに一役買いました。

バリュー ストリーム マッピングのメリット

バリュー ストリーム マッピングはビジネスの持続可能性に欠かせません。その理由は次のとおりです。

• 無駄を削減または排除することで、会社の収益を向上させられます。さらに、根本的な原因と無駄の源を見つけられます。
• 無駄なハンドオフがバリュー ストリーム ビジュアライザーの一部として特定されると、チームは行動、文化、コミュニケーション、コラボレーションを意識的に向上させられます。
• チームは個々の意見ではなく顧客の視点に基づいて、優先順位を付けます。

バリュー ストリーム マッピングの課題

注意しないと、バリュー ストリーム マッピング自体が無駄になる可能性があります。一般的な落とし穴を回避する方法は次のとおりです。

• バリュー ストリーム マッピングを実施するための労力のレベル (LOE) では、潜在的な価値とコスト削減のバランスを取る必要があります。最初から投資収益率 (ROI) に注視してください。
• このマッピング プロセスは非常に部門横断的で複雑になる可能性があるため、バリュー ストリーム マッピングの実施にはビジネス側および製品側の経験豊富なスタッフを関与させます。
• バリュー ストリーム マッピングが実施されるときに不安と不確実性を感じるのは当たり前です。そのため、無駄を特定しようとするプロセスが過剰になる場合があります。
• ここでのステップとそこにあるステップを改善することで、確実にコスト削減できるようになります。ただし、完全なウォークスルーが完了するまでは、収益の改善に直接は繋がらない場合があります。それでも多くの場合、小さな一歩は始める際に最適な方法です。
• すぐに専門のチャート、ツール、記号の使用に飛びつかないでください。最初は鉛筆でスケッチするかホワイト ボードを使用して、アイデアの概要をまとめます。ひと段落したら、マップを適切に形式化します。無駄を削減しようとしているのであって、すでに持っている以上のものを作らないようにしてください。

全体として、バリュー ストリーム マッピングを行うことは問題ありませんが、やりすぎると問題が発生する可能性があります。

バリュー ストリーム マッピングのユース ケース

バリュー ストリーム マッピングがさまざまな業界にどのように価値をもたらせるのかを簡単に見てみましょう。このドメインは、バリュー ストリーム マップを流れるプロセス アイテムを決定します。

サプライ チェーンでは、バリュー ストリーム マッピングによって、完成した製品に影響するコストのかかる遅延を解消できます。製造業におけるバリュー ストリーム マッピングは、材料の取り扱いと情報フローの各ステップを分析することで、無駄を特定するのに役立ちます。バリュー ストリームを流れるプロセス アイテムは、材料に他なりません。

サービス業におけるバリュー ストリーム マッピングは、外部顧客への効果的かつタイムリーなサービス提供を促進する一方、内部の管理部門やオフィスでは内部顧客へのサービス提供を促進します。医療現場におけるバリュー ストリーム マッピングは、患者が質の高い治療を効果的かつ確実に受けられるようにします。バリュー ストリームを流れるプロセス アイテムは、顧客のニーズに他なりません。

どのようにバリュー ストリーム マッピングで無駄を特定して削減するか

バリュー ストリーム マッピングは、製造業で始まりました。例として、自動車工場が新車を受注して、生産するために材料を必要としているとします。会社はバリュー ストリーム マッピングを使用して、新車の生産に必要なステップの概要をまとめます。

自動車生産ステップを見直した後、会社は無駄が多いと思われる開発のハンドオフ ステージを特定します。このハンドオフ ステージでは、倉庫にある材料を生産ラインに移動するためにフォークリフトが必要です。ただし、この移動には安全上のリスクがあって時間がかかります。このインサイトから会社は、原材料倉庫を生産ラインに直接隣接させてそのままにすることを決定します。これによって効率が向上して、フォークリフトの要件が完全になくなる可能性があります。

リーン生産方式では、7 種類の一連の無駄の発生があります。

過剰生産

過剰生産は、多くのその他の形式の無駄のきっかけになります。製造製品が過剰生産されると、余分な保管、無駄な原材料、無駄な在庫で凍結資産などの不要なコストによって、さらなる無駄に繋がります。

在庫

在庫の無駄は、余剰在庫の保管と維持に伴う負債コストです。この無駄には、在庫を保管するためのスペース、保管スペースのための賃借料、輸送費、保管された製品の劣化に起因するそれぞれの無駄が含まれます。

移動

人や機械によるすべての移動のコストである移動の無駄は、最小限に抑えられます。フォークリフトと供給場所で示した前述の例は、移動の無駄と最適化の素晴らしい例です。移動の無駄には、汚染、運転車両の燃料廃棄物、保守修理、機器の故障にかかるコストを含む、多くの廃棄副産物があります。

不具合

事故が発生すると、高額な費用がかかる可能性があります。欠陥の無駄の管理は、欠陥のある最終製品に繋がる事故や不完全性を特定して軽減するための取り組みです。欠陥は交換が必要なためのコストや追加のリサイクル コストがかかったり、原材料の全損に繋がったりする可能性があります。

過剰処理

過剰処理の無駄は、不要と思われる製造コンポーネントの任意のステップを指します。たとえば、ユーザーにとって不要だった機能の追加やユーザーには見えない可能性のある製品の箇所の研磨などがあります。

待機

待機の無駄は、製造処理における任意のステップのコストです。これによって遅延と最終的な成果物への対応の遅れが発生します。待機は、照明、暖房、冷房の費用、材料のリスク、または契約終了の原因となります。

輸送

輸送の無駄は、移動の無駄と非常によく似ています。輸送の無駄では、複数の場所の間における外部輸送の移動と、移動が同じ場所内における内部移動を扱うサードパーティのパートナーシップに対応します。

ソフトウェア開発組織では、完成した製品を構築するために倉庫周辺へ原材料を物理的に移動することはありません。ソフトウェア開発では、顧客に価値を提供する具体的なユーザー エクスペリエンスにアイデアをリリースする必要があります。

ソフトウェア企業のバリュー ストリーム マッピングでは、カスタマー サポート、販売要件、競合他社の分析などのソースから「アイデアのインプット」を行います。それによって、貴重なアウトプットとしてエンド カスタマーに提供するフローを確認します。ソフトウェア開発のバリュー ストリーム マッピングのフロー ステージは、主にクロスチーム コミュニケーションに関係しています。

ユーザーが機能を要求して製品チームが機能を設計し、エンジニアが設計を受け取ってソフトウェアを構築することで、ソフトウェアがエンド ユーザーにリリースされます。ソフトウェアのバリュー ストリーム管理は、これらのステージ間で発生する無駄のポイントを特定するために使用できます。

ソフトウェア開発やその他のクリエイティブな作業で見つかった 7 種類の無駄のリストを次に示します。

部分的に完了した作業

ソフトウェアが不完全な状態で先送りにされた場合に発生します。これは、完全な仕様や自動化テスト カバレッジの欠如が原因で発生する場合があります。また、部分的に完了した作業は、より多くの更新をプッシュして不足している機能を埋めるために追加の作業が必要になるため、他の無駄が次々と発生します。

余分な機能

よく「フィーチャー クリープ」と呼ばれる余分な機能は、必要以上の作業を行うことで無駄を引き起こします。余分な機能はユーザーが直接要求するのではなく、内部における思いつきや憶測によって作成された機能です。余分な機能は痒い所に手が届く機能として表現される場合がありますが、多くの場合は実際の顧客のニーズからかけ離れた副産物です。

再学習

再学習の無駄は、内部向けドキュメントの不足からも発生する可能性があります。ソフトウェアの障害や停止が発生した場合は、停止が発生した理由とその修復方法を調査して文書化することがベスト プラクティスです。障害が再度発生して文書化されていない場合は、別の調査と修復が必要になります。

再学習の無駄は、チームや個人が不慣れなテクノロジーの学習曲線を克服する必要がある場合にも発生します。テクノロジーのトレンドは神出鬼没です。一時的な流行のフレームワークとライブラリには、市場のトレンドと誇大宣伝に刺激された経験の浅い開発者が飛び乗ります。特定の機能を構築する方法を組織がすでに知っているにもかかわらず、経験の浅い開発者は新しいフレームワークでその機能を構築する方法を再学習しなければならない可能性があります。

ハンドオフ

ハンドオフの無駄は、プロジェクトの所有者が変更されたり、役割が変更されたり、従業員の離職があったりしたときに発生します。主要なチーム メンバーが去ると、プロジェクトが経緯を把握していないチーム メンバーに渡されます。このシナリオは回避困難です。それ以外の場合ハンドオフは、不十分な管理と活動中のチーム メンバーの優先順位の変更から発生します。

ハンドオフ廃棄物は、通信パイプラインを通じて発生する可能性もあります。たとえば、DevOps チームでは、開発チームが運用チームと緊密に統合して、製品をメンテナンスに渡す際の通信エラーを防ぐことができます。これは、ハンドオフの無駄を回避する例です。

遅延

遅延は通常、プロジェクトに密接に結合された依存関係がある場合に発生します。プロジェクトのダウンストリーム実行は、アップストリームの決定またはリソースへの依存関係のために停止される場合があります。これらのタスク間の依存関係を回避するのが最善ですが、タスクを完全に切り離すのは難しい場合があります。1 つのタスクで遅延が発生すると、依存するタスクに遅延が発生する可能性があります。遅延は、無駄を次々と引き起こす可能性があります。多くの場合、ソフトウェア開発は急速に発生して、タスクはチーム メンバー間で分散されます。

タスク切り替え

タスク切り替えの無駄は、ハンドオフの無駄と同様の性質を持っています。タスクがチーム メンバー間で所有者を切り替えるときにハンドオフの無駄が発生する場合、タスク切り替えの無駄は個人に発生します。メンタル コンテキストの切り替えには高いコストがかかります。ソフトウェア エンジニアが優れたコードを最も優れた方法で生成するために達成する、メンタルのリズムや「フロー」があります。効率的な組織は、エンジニアのためにこの精神状態を最適化するために取り組みます。非効率な組織は、ミーティングやメールなどの重要ではない割り込みをエンジニアへ次々と差し挟んで、エンジニアのワークフローを混乱させます。

不具合

欠陥の無駄は、バグがソフトウェアにプッシュされたときに発生します。欠陥は部分的に完了した作業に似ていますが、部分的に完了した作業は通常では事前にわかっているのに対して欠陥は不明であるため、より無駄になる可能性があります。欠陥は顧客によって特定されて、カスタマー サポートに報告される場合があります。これによって、遅延やタスク切り替えを引き起こす高いコストがかかるパイプラインになる可能性があります。

バリュー ストリーム マッピングの記号

バリュー ストリーム マッピングの概要を示すための標準記号があります。

1. 解決しようとしている問題を決定する

どのような問題を顧客の立場から解決しようとしていますか?顧客は、製品に新しい機能や改善を提供するのに時間がかかりすぎると感じていますか?問題の説明を公開して、全員で情報を共有します。

2. 適切なチームを支援する

ただちにこれらの問題にうまく対処できる、熟達している経験豊かなチームを支援します。経営幹部は、その支援が中断されないように十分な予算を確保する必要があります。

3. プロセスの範囲を制限する

問題の説明が公開されたら、それに応じてバリュー ストリーム マッピングの範囲を制限します。リリース プロセス全体をマッピングする必要はなく、代わりに特定の領域に焦点を当てる必要がある場合があります。

4. 範囲が制限されたプロセスをマッピングする

範囲が制限されたプロセスを必ず確認してください。実際のエクスペリエンスは他の人が作成した (おそらく偏っている) ストーリーや (おそらく不完全で不正確な) ドキュメントでは替えが効かないため、このプロセスから差別化できます。

ステップを定義します。バリュー ストリーム マッピング分析を何度も実施しています。これは冗長にも思えますが、最初のパスで明らかにされなかった不足箇所を 2 回目のパスで見つけました。さらに調査したところ、3 回目 (最後) のパスで大問題が明るみになりました。

5. プロセス データを収集する

バリュー ストリーム マッピングを実施する際は、マップのデータ ボックスにあるプロセス データに注意してください。プロセス データには、関係者の人数、平均作業時間、サイクル期間、待機時間、アップタイム、ダウンタイムなどが含まれます (ただし、これらに限定されません)。

6. タイムラインを作成する

プロセス時間とリード タイムを策定します。

7. 現在のマップを評価する

探求心旺盛になってください。チームはお互いに複数の依存関係を持っていますか?リード タイムが長すぎますか? もしそうなら、原因はテスト スイートを並行して実行していない (またはできない) からですか?安定した環境がありますか? それともチームが再現できない断続的なテストの失敗が確認されましたか?

あるいは、価値があると思っているだけで顧客にとっては何の意味もないプロセス ステップがあるかもしれません。情報フローについては、フローで停滞と障害を探します。それがプッシュだったかプルだったかどうかを確認してください。

8. 将来のマップを設計する

完全な最終バージョンを完成できない場合がありますが、それは問題ありません。新しいマップが会社のビジョンと一致していることを確認してください。

また、何も確定されていません。顧客のニーズに基づいて、継続的な調整を行います。

9. 将来のマップを実装する

将来のバリュー ストリーム マッピングに従って、それが顧客にとってさらに理にかなっていることを検証します。これによって、着手した問題の説明文が解決できるはずです。KPI を定期的に監視してトレンドから学びます。全員が顧客の方向に向かっていることを確認してください。

完成品がどのように見えるかに関心がある場合は、バリュー ストリーム マップの例を次に示します。

バリュー ストリーム マッピングの継続的なデリバリーへの適用

ソフトウェア開発では、バリュー ストリーム管理によってフィードバック ループややり直しなど、アイデアから本番環境までの非効率性を明らかにできます。これは、ステップの数とやり直しの必要性を減らすのに役立ちます。プロセスをマッピングするとハンドオフが発生する場所を視覚化できるため、システムを通じて待機時間によって作業の移動が妨げられる場所も見つけられます。

定義上、継続的なデリバリー (CD) ではバリュー ストリーム マッピングを利用する必要はなく、バリュー ストリーム マッピングの知識がなくても CD パイプラインを設計して実装することは完全に可能です。

バリュー ストリーム マッピングを適切に採用すれば、ソフトウェアの設計および運用で効果が実証されている継続的改善の文化を育むことができます。このマップはバリュー ストリーム分析の結果を説明し、理解とコミュニケーションを促進する視覚的なツールを提供します。

バリュー ストリーム マッピングをチームに持ち込む理由

バリュー ストリーム マッピングをチームに持ち込む理由

バリュー ストリーム マッピングは、すべてのビジネス機能全体でプロセスを改善しようとしている業界に適用できます。ハンドオフを視覚化することで、フローを最適化してコストを削減できます。視覚化をしないと、会議時間が長くなってビジネスの成果が曖昧になることを想定できます。

バリュー ストリーム マップは、継続的な改善の促進に絶対的な効果を誇ります。ソフトウェア開発の世界では、継続的な改善は継続的なパラダイムの中心です。そこでは、継続的なデリバリー パイプラインが製品を、頻繁に、予測どおりに、持続的に顧客に提供します。アイデア化に合わせてリリースできると、顧客は満足するでしょう。

生産性の高いチームはコラボレーションにより積極的に取り込んで楽しむため、バリュー ストリーム マッピングはチーム文化の向上にも役立ちます。文化、生産性、コスト削減は、その見返りのほんの一部に過ぎません。バリュー ストリーム マッピングを、単一のバックログの優先順位付けで最上位近くに持ってくることをお勧めします。

アトラシアンの Open DevOps は、お気に入りのツールを使用して CD ベースの開発パイプラインを構築できるオープン ツールチェーン プラットフォームを提供します。Jira をバックボーンとして使用すると、バリュー ストリーム マッピングをワークフローやプロセスに統合できます。