バリューストリームマッピングをやってみた

はじめに

こんにちは、DevOps導入支援担当の藤村です。

今回はDevOps導入支援を行っていく中で欠かすことのできないバリューストリームマッピングについて、クラスメソッド社内のとあるプロジェクトで実施してみた内容をお届けします。

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

バリューストリームマッピングとは、製品やサービス、機能を顧客に届けるために必要なプロセスを可視化するためのツールです。

以前書いた、DevOps導入支援サービスのご紹介という記事の中で、DevOps導入の目的はお客様のビジネス競争力の向上のためであり、そのためには以下のステップを順に実践することが重要だと書きました。

1. お客様のリードタイムの短縮の実現
2. お客様のフィードバックループの継続的な短縮、強化の実現
3. お客様の仮説検証ループの高速化の実現

今回紹介するバリューストリームマッピングは、1番目のステップであるお客様のリードタイムの短縮の実現に対して、絶大な効果を発揮する手法です。

参考にした資料

バリューストリームマッピングの進め方は、マイクロソフト社の資料を参考にしています。この動画とスライドを見れば、全体の進め方を理解できると思います。

やったこと

準備したもの

• 皆が集まれる時間(2時間)
• 会議室 × 2
  • 今回は2拠点をGoogle Meetでつないで実施しました
• ホワイトボード
• 模造紙
• 水性ペン(4色)

参加者

• プロダクトオーナー
• 開発チーム
  • サーバサイドエンジニア
  • デザイナー
• スクラムマスター

実施したステップ

1. 開発サイクルに関係するシステムの確認

まずは開発サイクルに関係するシステムを洗い出しました。コアな部分のアーキテクチャについてはここではご紹介できませんが、開発やステージなどの環境、スマホやWebなどのUI、GitHubやCircleCIなどの開発系クラウドサービスなど、関係するシステムを色々な視点から洗い出しました。

2. 開発サイクルの概要を確認

次に、開発サイクルの概要を書き出してみました。色々と議論しましたが、最終的には資料にあるサンプルとあまり変わらないサイクルに落ち着きました。

3. 全員でプロセスを書く

いよいよ本題のプロセスを書くステップです。価値の届け先である右上のユーザーから書き始め、そこから下に線を下ろし、環境(技術)であるAWSを書きます。マイクロソフト社の資料ではその下の階層にツールを書くとありましたが、今回は省略しました。

その下にはタスクとして以下の項目を書きます。

• タスク名
• チーム(Dev、Bizなど)と必要な人数
• LT(リードタイム)
  • 前タスクの完了から該当タスクの完了までにかかる時間
• PT(プロセスタイム)
  • タスク自体にかかる時間

以降は手順をさかのぼっていく流れで右から左へタスクを追加し、タスク間を線でつなげていきます。この時同一チーム(担当者)が連続して行なうタスクの場合は実線、チーム(担当者)が変わる場合は点線でつなぎます。

4. グルーピング

マイクロソフト社の資料では、次に手戻り率を記載する流れで説明されていますが、まずは全体のLT、PTを見ることを優先したため、先にグルーピングを行ないました。ステップ2で書き出した概要の単位でタスクをグルーピングし、グループごとにLT、PTを合計します。

5. 気になるタスク、プロセスに着目する

ここまでで一旦手を動かすのを止め、PTに対してLTの値が大きいグループ、タスクに着目してみました。まず目についたのは以下のタスクのフローです。

開発レビューからステージデプロイへのフロー

• ステージデプロイ
  • Dev x 2名
  • LT: 8d
  • PT: 1h

社内承認から社内デプロイへのフロー

• 社内デプロイ
  • Dev x ２名
  • LT: 5d
  • PT: 2h

どちらもなぜLTが長くなってしまうのかをプロダクトオーナー、開発チームに確認したところ、ステージデプロイ、社内デプロイとも曜日を固定して実施しているため待ち時間が発生していることが分かりました。この辺りに改善のヒントが隠されていそうです。

一旦ここまでで初回のバリューストリームマッピングは時間切れとなりました。バリューストリームマッピングの説明時間も含めて２時間弱ぐらいの時間を使いましたが、繰り返し実施していけば、もっと速く進められると思います。

以降のステップは後日スクラムマスターと私の二人で実施しました。

6. 手戻り率を書く

本来であればステップ４で行なうべきだった手戻り発生比率を記載します。

実際に手戻りが発生している箇所は、開発内のレビュー時のみで、過去の実績から手戻り率は5%程度ということが分かりました。今のところ、プロセス中に２度ある承認時や、社内テスト、外部テストでは手戻りは発生していないそうです。

7. 無駄にマークを付けていく

マイクロソフト社の資料を参考に、無駄と考えられる箇所にマークを付けていきました。

タスクに付けたマークは以下のとおりです。

• レビュー
  • D(欠陥の無駄)
• ステージデプロイ
  • W(待ちの無駄)
• 社内デプロイ
  • W(待ちの無駄)
  • M(ハンズオフ)
  • TS(タスクの切り替え)

最終的にはこのような形になりました。

8. 改善案を検討する

ここまでで、現状のLT、PTが可視化されました。

• 全体のLT、PT
  • LT
    • 48d
  • PT
    • 20d

この結果から、こんな機能がほしいと考えてから、実際にその機能をユーザーが使うまでに48日かかっており、そのうち28日間は待ち時間になってしまっているということが分かりました。

続いて、どの部分のプロセスを見直せば、LTを短縮できるかを検討しました。

●デプロイのタイミングの改善

前述したとおり、ステージデプロイ、社内デプロイとも日を固定して実施しているために待ち時間が発生してしまっています。必要に応じて随時デプロイするようにすれば、最大で18日分(※)のLTが短縮できる可能性があります。

※写真でモザイクをかけている部分のLTも含めた日数です

●テスト -> 承認 -> デプロイで発生しているハンドオーバー(作業引き渡し)の改善

テスト実施者、承認者、デプロイ実施者、それぞれが担当が異なるため、ハンドオーバーの無駄が発生していることが分かります。この部分を、AWS Code Pipelineを使ってデプロイメントパイプラインを構築すれば、承認者がAWS マネジメントコンソール上で承認をクリックするだけで、各環境にデプロイするところまでを自動化することもできそうです。

前者の デプロイのタイミングの改善 だけではハンドオーバーが発生するため現実的には18日分のLT短縮は難しいですが、さらにハンドオーバーを止め、一連の流れを自動化することでそれに近い短縮が可能になるのではと考えています。

わかったこと

●現状のLT、PTが認識できた

改善活動を実施するかしないかは別として、現状の目安の数値を関係者全員が認識することはとても重要だと改めて感じました。

●改善ポイントが分かりやすい

プロセスを可視化し、無駄なポイントに目印をつけることで改善ポイントが見えてきました。

●リモート間でもバリューストリームマッピングは実施できる

最初に書いた通り、今回は2拠点をGoogle Meetでつないでバリューストリームマッピングを実施していました。

当初はWebカメラで壁に貼った模造紙を撮影しながら議論できればと考えていましたが、リモート側の拠点でも同じ図をホワイトボードに書き出しはじめてみたところ細部まで見渡せるため、より突っ込んだ指摘がリモート側からも沢山生まれました。冗長に感じるかもしれませんが、各拠点で同じ図を書くことによってリモートからでもバリューストリームマッピングを円滑に実施できそうだという手応えをつかめました。

今後Jamboardなどのツールが普及すれば、さらに敷居も下がると思います。

おわりに

いかがでしたでしょうか。

今回の記事では実際のバリューストリームマッピングをイメージしやすいように、可能な限り具体的な情報を公開してみました。もしご興味を持って頂けたら、今回の記事を参考にまずはやってみることをお勧めします。

そのうえで、どうもうまく可視化できないといったバリューストリームマッピングの相談や、今回の例のように改善策として上がったデプロイメントパイプラインの構築部分を支援してほしいなどの要望がありましたら、お気軽にクラスメソッド社のDevOps支援室までお問い合わせください。