翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

開発バリューストリームマップの作成

以下は、開発バリューストリームマップ (DVSM) を作成するステップです。

ステップ 1: バリューストリームを特定する

バリューストリームマッピングは、顧客に価値を提供することに重点を置きます。このバリューストリームは、できるだけ狭く定義する必要があります。理想的には、ビジネス部門から IT 部門まで、開発や運用を含むすべてのメンバーが 1 つの少人数チーム (2 枚のピザで足りる規模のチーム) としてまとまっていると仮定し、そのチームが顧客に提供できる範囲を対象とします。組織がすでにバリューストリームと製品チームで構成されている場合、開発バリューストリームは、1 つのバリューストリームとそれに関連する製品チームになります。そうでない場合、開発バリューストリームは数十のチームや何百人ものメンバーにまたがることもありますが、それでも問題ありません。

例えば、適切なバリューストリームの例としては、保険会社の顧客向け請求入力インターフェイスが考えられます。このインターフェイスには、ビジネスから IT まで、すべての部門のチームによる協力が必要です。請求部門全体を評価対象とするのは範囲が広すぎます。なぜなら、それは組織に焦点を当てており、顧客に提供される価値に焦点を当てていないからです。

ステップ 2: 開始点と終了点を定義する

バリューストリームマップの開始点は、ビジネスが成果物を定義して優先順位付けし、開始する準備が完了した時点です。各チームには、それぞれの準備完了の定義があります。組織でこの用語を定義する方法の詳細については、「Walking Through a Definition of Ready」(Scrum ブログ記事) を参照してください。多くの場合、準備完了とは、成果物が一般的なバックログから移動し、スプリントバックログで利用できるか、Kanban ボードに追加されていることを意味します。DVSM には、バックログ、絞り込み、優先順位付け、またはチームの準備完了の定義を満たすために必要なその他のステップを含めないでください。

バリューストリームマップの終了点は、チームの完了の定義です。組織でこの用語を定義する方法の詳細については、「Definition of Done」(Leading Agile のブログ記事) を参照してください。完了とは、成果物を正しく計測可能にして検証したことを意味します。理想的には、本番環境でエンドユーザーに提供され、その製品が正しく実装されて、機能し、採用されていることを示すモニタリングも含まれます。

ステップ 3: 関与するチームを特定する

DVSM は、顧客に特定の価値を提供するために必要なすべての人材、プロセス、テクノロジーにわたって適用されます。顧客に価値を提供するためにこのチームに依存関係がある場合は、そのチームを DVSM プロセスに含めてください。チームは、顧客に届けられるまでの過程で成果物に関与する場合、プロセスや成果物に関連するチケットを受け取る場合、または成果物を完成させることに影響を与える場合、依存しているとみなされます。マッピングプロセス中に新しい依存関係が発生することが多いため、最初からすべてのチームを特定しようとしなくても構いません。まずは、予想されるチームの大まかなリストから始めてください。

開発バリューストリームマップを作成する場合、一般的に次のチームが含まれます。

参加者の人数は、これらのチームを代表できる 5～8 人以内にすることを目標とします。もし、各チームを適切に代表するために 8 人以上の参加者が必要だとわかった場合は、マップを複数のセクションに分割し、それぞれを小さなグループで個別にマッピング演習として完了させることができます。その後、セクションを組み合わせて、開始から終了までの開発バリューストリームの完全なマップを作成することができます。

ステップ 4: 参加者をトレーニングする

チームが DVSM の作成に使用するツールを選択します。付箋を使ったホワイトボード、オンラインホワイトボードアプリケーション、Microsoft Visio、または Microsoft Excel を使用することもできます。共同作業の段階では 1 つのツールを使用し、その後、正式なプレゼンテーションの目的でマップを別のツールに移すこともできます。共同作業の段階のためのツールを選ぶ際には、すべての参加者が対面で出席するか、あるいはセッションにリモート参加者がいるかを考慮してください。一部の参加者がリモートの場合は、すべての参加者が平等に意見を出せるアプリケーションを選ぶこともできます。

参加者に対して、ツールとプロセスを案内します。すべての参加者が積極的にかかわり、各自でステップやデータをバリューストリームマップに追加することを前提として準備を進めます。開発バリューストリームマッピングの成功と迅速な実施には、説明責任が不可欠です。また、共同作業により、DVSM が一部の人に偏らないようにすることができます。必要に応じて、選択したツールのトレーニングを提供します。

基本的なプロセスについて参加者にトレーニングを行い、予定されたマッピングセッションの前に、選択したツールに参加者がアクセスできることを確認します。これにより、マッピングセッション中の遅延を防ぎ、チーム代表者ができるだけ早く貢献や関与を始められるようにします。

ステップ 5: バリューストリームステップをマッピングする

参加者とともに、バリューストリームの開始点と終了点の間で発生するすべてのステップを特定します。開始点と終了点を特定することからプロセスを開始し、協力して最初のいくつかのステップを定義できます。DVSM が少しずつ出来上がり、参加者が慣れてくるにつれて、参加者に対してボードにボックスやデータを自分で追加するよう促します。すべてのステップが漏れなく網羅されていることを確認するために、SDLC の知識を活用して「その次は?」と問いかけてください。

参加者には、大きなタスクを適切な大きさのステップに分割するよう促してください。特に、そのタスクに複数の所有者がかかわっている場合はそうしてください。ただし、ステップの単位が小さくなりすぎないようにしてください。ステップが多すぎると、マップを完成させることや、バリューストリーム内で最も重要な制約を特定することが困難になる可能性があります。

以下は、開発バリューストリームマップを作成する際に一般的に含まれるステップです。

ステップを順番に並べ、プロセスフローの矢印で接続します。例外やエラーが開発中に発生しなかった場合のプロセスフローであるハッピーパスを特定します。また、製品が開発プロセスのいずれかのステップで失敗した場合に発生するフローである失敗パスも特定します。

ステップ 6: 各ステップのスピードと品質を評価する

この段階では、各ステップの所有者を決定し、そのステップのスピードと、高品質な成果物がどの程度の頻度で生成されるかを評価します。その作業を誰が実行するのか、その作業が誰に引き継がれるのか、そして問題によってどのくらいの頻度で差し戻されるのかをたずねてください。

まず、各ステップの所有者を特定します。所有者とは、そのステップ内の作業を実行する責任を負うチームです。マップ上で所有権を識別しやすくするために、各チームに異なる色を割り当てることができます。1 つのステップに複数の所有者がいる場合は、そのステップを複数のより小さなステップに分割して、各チームが自主的にデータを提供し、引き継ぎが適切に考慮されるようにします。

バリューストリームマップの各ステップについて、そのステップの所有者に次の情報を提供してもらいます。データは、実体験に基づく平均的なシナリオから得られるべきであり、システムやデータソースから引き出されたものであってはなりません。多くの場合、このようなデータを取得して正規化することは、DVSM の範囲に対して手間がかかりすぎます。さらに、そのようなデータはしばしば不正確であったり、追跡や測定が困難な要素を含んでいなかったりします。作業の所有者が使用しているシステムを改善することが目的であるため、以下の指標についてしっかり把握しているその所有者を信頼しましょう。

すべてのチームが参加し、あるチームが他のチームを代表して発言しないことが重要です。各チームには、所有するステップのデータを提供し、速度と品質の両方に大きな影響を与える可能性のある引き継ぎについて議論する自主性が必要です。これにより、データを収集するために多数の人々と話すことになるかもしれません。

ステップ 7: 制約を特定する

スピードと品質に大きな影響を与える制約を特定します。

これらのステップは、ソフトウェア開発プロセスのスピードと品質を改善する最大のチャンスをもたらします。

バリューストリーム全体にわたって、すべてのステップのリードタイムまたはプロセスタイムを加算することで、バリューストリーム全体の累積リードタイムまたは累積プロセスタイムを得ることができます。また、すべてのステップの完了率と精度のスコアを掛け合わせることで、平均を求めることもできます。これは、システム全体で作業に要する時間と、特定のステップでその成果物が正しく仕上がっている確率を把握するのに役立ちます。

ステップ 8: 継続的に改善する

開発バリューストリームマップで制約を特定して優先順位を付けたら、それらを使用してソフトウェア開発プロセスの改善を推進できます。ステークホルダーやステップ所有者と協力し、引き継ぎ、無駄な時間、過剰な処理をなくすことで、スピードと品質の向上に努めます。

変更を実装したら、ステップ所有者と DVSM を再検討し、その変更が成功したかどうかを評価します。変更に基づいて DVSM を更新し、継続的な改善を推進するために新しい制約を特定して優先順位を付けます。新しい制約がマップの別の部分に現れたり、制約が低優先度から高優先度にエスカレートしたりするのはよくあることです。