ソフトウェア・デリバリーにおけるバリュー・ストリーム・マネジメントとは何か (そしてなぜ重要なのか)

2021/5月/10 - 読み終える時間: 5 分

What is Value Stream Management for Software Delivery (and why it matters) の翻訳版です。

ソフトウェア・デリバリーにおけるバリュー・ストリーム・マネジメントとは何か (そしてなぜ重要なのか)

2021年5月8日

著者: Steven Wong / Solutions Lead for HCL Software

バリューストリームマネジメント (VSM) は、最近、特にITの世界で注目を集めています。私が話をした多くの人は、これがITにおける「新たな流行」に過ぎないのではないかと問いかけています。今回のブログでは、VSMに対する私の個人的な見解と、なぜそれがソフトウェア・デリバリーにとって重要なのかを紹介したいと思います。

バリューストリームマネジメント (VSM) とは？

VSMは、組織変革のためのアプローチです。

他の多くの組織変革のアプローチとは対照的に、VSM は、お客様と、お客様が最初に組織に近づいたときに期待したものである価値を提供するための組織全体の仕事の流れに、絶え間なく焦点を当てています。

ビジネスや組織を、一方で顧客からの要求を受け、他方でサービスや製品を提供するブラックボックスと想像すると、VSM はそのブラックボックス内のハイレベルな構成要素を評価し、要求がそれらの構成要素を経由して、結果として他方でサービスや製品を顧客に提供する流れを評価することである。

バリューストリームマッピングと呼ばれる手法を用いて、組織はバリューストリーム全体の仕事の流れをマッピングする。バリューストリームマップでは、さまざまなタイプの活動、システム、情報の流れを表す表記を使用します。さらに、ある活動にどれだけの時間が費やされているか、活動の外でどれだけの時間が待たされているか、その活動の成果物の品質、可用性などを明らかにするために、具体的な測定を行います。

ここで重要なのは、VSM は可視性を重視しているということです。可視性を示すのに、フローを図式化すること以上の方法があるでしょうか。

下の図は、バリューストリームマップの一例です。

バリューストリームマップがあれば、企業や組織は、潜在的な問題がどこにあるのかを確認し、パフォーマンス低下の根本原因を明らかにし、さらに重要なことに、どこで、どのように変革し、改善すべきかを明らかにできます。

VSM は新しい手法ではありません。長い間、VSM は主に、バリューストリームが工場の製造現場にある製造業の領域で使用されていました。

2010年初頭、カレン・マーティンやマイク・オスターリングのような組織変革の第一人者が、大成功を収めた著書『バリュー・ストリーム・マッピング』で、VSM とバリュー・ストリーム・マッピングの実践をオフィスやサービス業界に広めた。How to Visualize Work and Align Leadership for Organizational Transformation を出版しました。

なぜなら、顧客が組織に求めるものは「価値」であり、すべての組織はその価値を提供するシステムを持っているからである。

組織のパフォーマンスは、そのシステム (またはバリューストリーム) がいかにうまく機能して製品やサービスを提供できるかにかかっている。

VSM はソフトウェアデリバリーにどのように利用できるか？

「ソフトウェアが世界を食っている (“software is eating the world”)」という言葉を聞いたことがある人は多いと思いますが、これは今日のビジネス環境の文脈で語られることがほとんどで、テクノロジーが私たちの生活のほぼすべての局面に浸透しているため、すべてのビジネスにソフトウェアが必要であるということを意味しています。

それは、テクノロジーが私たちの生活のほとんどすべての側面に浸透しているからです。これを受けて、企業はデジタル面でのイノベーションにますます注力するようになっています。顧客エンゲージメントを高めるオンラインサービスの展開、サプライチェーンを最適化するバックエンドサービス、迅速な意思決定のためにビジネスにリアルタイムの情報を提供するアナリティクスなどです。

多くの場合、勝者と敗者の違いは、いかに早く変化に対応できるか、ソフトウェアの変更を競合他社よりも早く、高品質に展開できるか、ということに尽きるでしょう。

この適応能力を支えているのが、2000年代初頭から導入が進んでいるアジャイルや DevOps の手法です。

このアプローチにより、IT 部門では、IT が顧客 (ほとんどの場合、企業) に提供する製品に焦点を当てたクロスファンクショナルチームが形成されました。これらの「製品」チームは、リクエストから納品までの作業と、生産現場での製品の運用を管理します。

これを VSM と関連付けると、各製品チームとバリューストリームを直接比較できます。

もちろん、これは非常に単純化された見方です。というのも、ご存知の通り、複数の製品チームの間には相互依存関係が存在するからです。IT業界では、単独で存在する製品を見つけることは非常に稀です。

むしろ、ある製品／サービス (製品／サービス A とします) が、製品／サービス B の機能や特徴を必要とし、その製品／サービス B が製品／サービス C に相互依存している場合の方が多いでしょう。

ビジネス (または顧客) からのリクエストの種類に応じて、作業の流れは、単一のチームまたは複数のチームのいずれかによって実行されます。

ここで重要なのは、ソフトウェアデリバリーにおいて VSM を効果的に行うためには、異なる粒度のバリューストリームを見ることができ、ITに寄せられるリクエストの種類が異なることが非常に重要であるということです。

VSMでソフトウェア・デリバリーを最適化するには？

先に述べたように、VSMが有効なのは、あるアクティビティから次のアクティビティへのハンドオフの間の時間、労力、リワークなどの指標を可視化するからです。

製造業におけるオリジナルのVSMでは、これらの指標は、"Gemba Walk" と呼ばれる工場の現場に実際に行って、バリューストリームを構成するアクティビティの各ステップを観察し、測定することで得られます。

ソフトウェア・デリバリーの世界では、"Gemba Walk" をする意味はないかもしれません。むしろ、もっと単純なことかもしれません。

今日のソフトウェア・デリバリー・チームは、仕事を提供するために無数のツールを使用しています。

例えば、プロジェクトの計画と追跡には、Atlassian JIRAやBroadcom Rallyなどのプロジェクト計画・追跡ツールを使用します。並行開発の管理には、Gitやエンタープライズ版のGitHub、Bitbucketなどのソース構成管理 (SCM) ツールを使用しています。テストについては、テスト管理ツールや自動テストツールを使用して、テストの実行や欠陥の管理を行います。

これらのツールは基本的に、ソフトウェアデリバリーのバリューストリームを流れる作業を記録するシステムです。つまり、物理的な "Gemba Walk" を行う代わりに、ツールからデータを取得することで同じ目的を達成することができるのです。

唯一の問題は、各ツールは、そのツールが使用されたアクティビティの記録しか持っていないということです。

つまり、バリューストリーム全体のさまざまなリポジトリに、バラバラのデータが置かれているのです。

エンド・ツー・エンドの可視化のために必要なのは、これらのツールからのすべての異種の情報を、最終的に顧客からの最初の要求に関連する単一のエンド・ツー・エンドのビューにまとめる機能です。

例えば、ソフトウェア・デリバリーのためのVSMソリューションである HCL Accelerate のスクリーンショットをご覧ください。

このビューでは、各ドットが顧客からのリクエストを表しています。ドットの色は異なる優先順位を表しており、また異なるタイプのリクエストを表していることもあります。

ドットは、ServiceNOW、JIRA、TFS、HCL Compassなどのさまざまなツールから「引き込まれ」、バリューストリームのさまざまなプロセスステップやアクティビティを表すさまざまなバブルやカラムを左から右へと流れていきます。

ドットがバリューストリームを横切って進むと、HCL Accelerate のようなVSMツールは、Github、Bitbucket、HCL VersionVault のようなコードリポジトリのような他のツールからのデータを「蓄積」し、これらは顧客からの実際のリクエストにリンクされます。

ここでは、あるリクエスト (技術的な問題) がバックログから本番まで進んだ様子を紹介します。

上の画像で明らかなように、VSMソリューションは、異種ツールからの異なるデータの断片を、リクエストの単一のエンド・ツー・エンドのフローに自動的につなぎ合わせ、各段階でプロセスステップやアクティビティに費やした時間などの詳細を記録します。

HCL Accelerate は、セキュリティスキャンやテストツールとも連携できるため、コード品質やセキュリティに関する関連データを取り込むこともできます。

上記のような単一のワークアイテムでエンド・ツー・エンドの可視性を得ることは良いことですが、より価値があるのは、継続的な改善のためのフローやトレンドに関する洞察を生み出すために、バリューストリームを流れる何百、何千ものリクエストを観察し、分析する能力です。

以下に、これらのメトリクスとインサイトの例を示します。

特定のリクエストが1日遅れることで失われる機会コストをビジネスが特定できる場合、HCL Accelerate のような VSM ツールが提供するリードタイム (アイデア出しから生産までの時間) とサイクルタイム (コードコミットから生産までの時間) を比較する機能は、優先度の高いアイテムをキューに残しておくことのコストを簡単に浮き彫りにします。

バリューストリーム内のアクティビティで計画された作業と計画されていない作業の数を観察し、計画されていない作業がどのように遅延の原因となっているか (例えば、過剰な仕掛品を作成している) を観察することで、IT は作業を計画する必要がある理由をビジネスに伝えられます。

ここでの考え方は、VSM が提供する可視性は、事実に基づいた改善の手段となり、責任のなすり合いをなくすことができるということです。また、フローの最適化に焦点を当て、フローのステップではなく、フローの最適化に焦点を当てます。

まとめ

この記事では、組織変革のための実証済みのアプローチである VSM の方法論やテクニックを紹介しました。VSM は製造業の世界で生まれたものですが、ソフトウェアが普及した今日の世界でも同じように強力で効果的な手法です。VSM の手法は似ていますが、ソフトウェア・デリバリーに VSM を適用すると、いくつかの活動を異なる方法で行うことになります。例えば、ソフトウェア・デリバリーにおける VSM は、"Gemba Walk" でメトリクスを収集する代わりに、ソフトウェア・デリバリー・チームが使用するツールからメトリクスを収集しなければなりません。

HCL Accelerate は、まさにそのような要件のためにゼロから構築された HCL Software の VSM ソリューションです。