バリュー ストリーム マップを使用してプロセス効率を評価する
"バリュー ストリーム マップ" (VSM) を作成すると、現在のリリース サイクル プロセスを分析するのに役立ちます。 VSM の目的は、チームがプロセス内のどこで価値を生み出しているか、また、どこに無駄があるかを視覚的に示すことです。 ゴールは、最小限の無駄で最大の価値を顧客に提供するプロセスに到達することです。 VSM は、価値に貢献しない領域や、製品の価値を実は低下させている領域を特定するのに役立ちます。
Tailspin 社がどのように対応するか見てみましょう。
チームの新しいメンバーである Mara は、既存プロセスの理解に役立つ VSM を作成しようとしています。 VSM を使用すると、チームが DevOps 成熟度モデルのどこに当てはまるかを把握できます。 結局のところ、成熟度の高いチームは通常、成熟度の低いチームと比べて、より速く、より大きな自信を持って、より少ないバグでリリースを行うことができます。
Mara はまだすべてを理解していないことを自覚しているので、会議室のホワイトボードに簡単な VSM を作成します。 不明点や疑問点がいくつかありますが、それは問題ではありません。 これは始まりです。 彼女はできる限りの作業を行い、それをチームと共有します。 VSM により、Tailspin が Web サイトを開発してリリースする方法を改善する最初のステップを特定するための共通の出発点が全員に示されます。
Mara のマップを見てみましょう。
現在のプロセスを理解する
Mara は会議室にチームを集めて、VSM を示します。
Mara: VSM は、プロセスが顧客に対する価値を持つ場所と、価値を生み出さずに時間を浪費している場所を測定するのに役立ちます。 このマップは、左上のソフトウェアの機能仕様から始まります。 1 つの機能だけをたどって、現在のリリース サイクル全体でどのように移動していくかを見ていきましょう。
あきれた顔をしているメンバーもいますが、Mara は突き進みます。
開発プロセス
現在、新しい機能の作成は、ソース管理でラベルを作成することから始まります 
。 ラベルを作成できるメンバーが 1 人います。それは Andy です。 ラベルは電子メールで要求します。 集中管理されたバージョン コントロール システムを使用しているため、Andy は、既存のすべてのコードがチェックインされて安定するまで待ってから、ラベルを作成します。 ラベルが作成されると、作業を開始できることを伝える電子メールを受け取ります。 このプロセスには最大で 3 日間かかりますが、顧客にとっての価値はありません。 顧客にとって価値のないものは、できるだけ時間をかけないようにする必要があります。
必要なすべてのファイルにアクセスできるようになった後、機能のコーディングに 1 人で約 4 日かかります 
。 ソース管理にアクセスするためには、社内ネットワーク上にいなければなりません。 この時間は顧客にとって価値があります。 彼らはこの機能を必要としています。
テスト プロセス
安定したビルドが完成したと判断したら、テストの準備ができたビルドがあること、およびそのビルドがどこにあるかを Amita に知らせるためにスプレッドシートを更新します 
。 彼女が通知を受け取るまでに 2 日かかります。
Amita は手動でビルドをテストします 
。 このプロセスは、コード ベースの増加に伴って長くなります。 ここでは、3 日かかるとしましょう。 その後、彼女はバグ レポートを Andy に電子メールで送ります。 テストで価値が追加されることはありませんが、テストは必要です。
その後、バグをトリアージして作業を割り当てるための時間が Andy に必要になります 。 Andy が問題を理解して、適切な開発者に渡すためにさらに 3 日かかることもあります。
運用プロセス
Amita がビルドを承認すると、彼女はそれを Tim に渡します。 Tim は、さらにテストを行うために、このビルドを運用前サーバーにデプロイする必要があります。 多くの場合、運用前サーバーは、Web サイトの実行に必要な最新のパッチや更新プログラムと同期していません。 Tim が運用前環境にデプロイして、いくつかのテストを実行するのに約 2 日かかります。 ここでも、運用前環境へのデプロイによってさらに価値は生まれませんが、必要な作業です 
。
ビルドの運用準備が整った後、リリースをデプロイするには、その前に経営陣がそれを承認する必要があります。 承認は会議で行われます。 経営陣を会議に招集して、リリースを検討するのに 4 日かかります。
その後、やっと Tim はこの機能をデプロイし、VSM の右上隅にある顧客にその機能が提供されます。 運用サーバーの構成にずれが生じ、運用前環境と同期していない場合、Tim は最初にそれを更新する必要があり、これには 1 日かかります 
。
顧客価値のメトリックを計算する
主要なパフォーマンス メトリックを参照し、自分たちの状況を確認できます。
"合計リード タイム" は、機能が顧客に提供されるまでにかかる時間のです。 ここでは、合計時間は 22 日です。 "プロセス時間" は、顧客に価値をもたらす機能に費やされた時間です。 ここでは、4 日間のコーディングに加えて、機能のデプロイに 1 日かかるため、合計で 5 日間のプロセス時間が必要になります。
"活動比率" は、次のように、プロセス時間を合計リード タイムで割った値です。
$$ {Activity \ ratio\ = \} \dfrac{Process\ {time} Total\ lead\ {time}} $$
これが、自分たちの効率です。 パーセントを求めるには、効率を 100 倍します。 結果は 0% より大きく、通常は 100% 未満です。 パーセントが高いほど、効率が高くなります。
ここでの数字を当てはめて、効率を計算します。
$${Activity\ ratio\ =\ }{\dfrac{5\ days}{22\ days}}{\ =\ .23}$$
結果を 100 倍すると、23% になります。
お分かりように、改善の余地がたくさんあります。 また、1 つの機能の開発に 22 日もかかるというのは長すぎます。
Tim: これが何の役に立つのですか?
ここから向かう先
Mara:無駄がある部分を特定できるように、現在の状況を確認するのに役立ちます。 顧客にとって価値のない時間を最小限に抑えたいと考えています。 DevOps アプローチを採用することで、効率を大きく向上させることができると確信しています。 まず、これらのステップの多くを自動化できるため、時間が確実に短縮されます。
現在のプロセスをやめることを提案しているのではありません。現在行っている作業を中断することなく、少しずつより効率的なプロセスを目指していくことができると思います。
改善できる部分をいくつか見てみましょう。
Andy: 最初から始めたほうがいいかもしれませんね。 新しい機能を開始できるように、コードにラベルをつけるのに長い時間がかかります。 ビルドとテストを行うことができるように、開発者のところに行って、彼らが持っているコードをチェックインするように依頼しなければなりません。 この作業をスピードアップする方法が分かったら、注目に値しますね。
あと、ビルド自体の時間が含まれていないことに気付きました。 現時点では、それに半日かかっています。 この時間が改善されるといいですね。
Amita: それに、開発者は、テストが必要な新しいビルドがあることを知らせるために、必ずしもスプレッドシートを更新してくれるわけではありません。 この部分が確実に行われるようにする方法があれば、時間の節約になります。
Mara: すばらしいです。 DevOps は、これらのすべての問題を解決するのに役立つと思います。
Andy: 現時点では、プロセスを変更する時間はありません。 Irwin の話を聞きましたよね。 危機的な状況なんです。
Mara: わかっています。 差し当たり、いつもやっていることを行いましょう。 ですが、プロセスにおける自分の役割についてそれぞれ検討し、どうすれば改善できるか考えることができます。 現在のプロセスと並行して小規模な変更を始めるとができます。 そうすることで、DevOps が現在の状態を妨げずに、私たちの仕事に役立つかどうかがわかります。 このマップとパフォーマンス メトリックは保管しておきます。 最終的に Azure DevOps のプラクティスを採用する場合に、数字を見直すことができます。 ある時点で VSM を更新できるかもしれません。