DevOpsの取り掛かりとしてのバリューストリームマッピングのススメ (リモート環境対応)
CyberZでエンジニアをしている齋藤です。
私は普段はOPENREC.tvの開発メンバーでSREチームに所属しておりますが、その一方でCyberZでDevOpsを推進する活動もしております。
今回はDevOpsを推進する中で、その取り掛かりとして実施したバリューストリームマッピングについてお話しいたします。また、Miroを活用することで、リモート環境においても効率よくバリューストリームマッピングの作業を進めることができましたので、どのような方法で実施したのかもお話しできればと思います。
バリューストリームマッピングとは
バリューストリームマッピングとは、顧客に対して製品やサービスをリリースするまでの一連のプロセスを可視化する手法です。バリューストリームマッピングによって作成された図のことをバリューストリームマップと呼びます。
各プロセスにおける作業時間や無駄を洗い出していくことで、プロセスを改善するための有益な材料となり、より迅速に顧客に製品やサービスを提供できることに寄与することができます。
バリューストリームマッピングを実施した経緯
社内でDevOpsを推進していくにあたり、まず何から取り組めばいいかについて整理しました。
なお、DevOpsの推進には、書籍「The DevOps ハンドブック 理論・原則・実践のすべて」を参考にさせていただきました。
書籍にはDevOpsの原則を「3つの道」として示しています。
第1の道: フローの原則
製品やサービスをリリースするまでの一連のワークフロー(左から右)を高速化します。
第2の道: フィードバックの原則
開発フローにおける右から左への素早いフィードバックを行うことで、継続的な改善を目指します。
第3の道: 継続的な学習と実験の原則
個人が継続的な学習と実験を行い得た知識を、チームや組織に転化していく文化を作ります。
出典: 「The DevOps ハンドブック 理論・原則・実践のすべて」
第1の道の実践のためには、製品やサービスをリリースするまでのプロセスを高速化するための取り組みを行う必要があります。
そして、リリースまでの速度を向上させるためには、一連のプロセスの中でどこが問題となっていているのかをまず把握する必要があります。
また、DevOpsの実践のためには、数多くの取り組む項目がありますが、その数は多く、全てを一度に取り組むには難しいものがあります。
とりわけOPENREC.tvは開発が開始されてから7年以上の歴史がある長い開発組織となります。そのような歴史の長い組織においては、様々な経緯や事情が積み重なって現在の開発プロセスとなっており、現在の開発プロセスの形が当たり前と思ってしまい、開発プロセスを改善しようにもどこから手をつけたら良いのかを見つけるのが難しく、結局抜本的な解決策を講じられないまま、改善がなあなあになってしまいがちです。
バリューストリームマッピングを実施することで、この開発プロセスにおける問題点を洗い出すことができ、DevOpsを実践する際の対応の優先順位を提供することに貢献することが期待できます。
また、別の観点から、バリューストリームマッピングを行った経緯をお話しします。
DevOpsを推進していくにあたり、まず初めに行ったこととして、書籍「LeanとDevOpsの科学[Accelerate]」で説明されているDevOpsの24のケイパビリティについての現時点での達成状況を評価しました。
評価方法については以下の記事を参考にさせていただき、24のケイパビリティを100個のチェック項目に細分化して達成度合いを記入していき、それらのチェック項目を3つのテーマと5つのカテゴリに分類して達成状況を可視化しました。
https://note.com/suwash/n/n3329de25f826
評価のアプトプットとして、開発チーム毎の3つのテーマの達成状況を以下にグラフとして掲載しました。
3つのテーマの概要は以下の内容となっています。
・People
人・組織・文化
・Process
価値提供全体の業務プロセス
・Technology
利用しているツールや技術
全体的にみてProcessについての数値が低い結果となりました。この結果は、開発プロセスの改善が期待されるバリューストリームマッピングを実施するための動機付けとなり、DevOpsの取り掛かりとしてバリューストリームマッピングを実施するための納得感のある材料を提供することとなりました。
DevOpsをこれから推進していこうと考えている方は、現時点でのケイパビリティの強みと弱みを把握することで、何から取り組んでいけばいいかを判断するために上述したケイパビリティの評価をしてみることをお勧めいたします。
バリューストリームマッピングの流れ
バリューストリームマッピングの流れについては以下のスライドを参考にさせていただきました。
https://www.slideshare.net/TechSummit2016/app013
バリューストリームマッピングは以下のステップで実施しました。各ステップの具体的な内容については上記のスライドをご参照いただければと思います。
1. 開発サイクルに関係するシステムを確認
2. 開発サイクルの概要を確認
3. 全員でプロセスを書く
4. 手戻り率を書く
5. グルーピング
6. 無駄にマークを付けていく
7. 改善案を記載する
バリューストリームマッピングの全てのステップを終了した時点で以下のようなものが出来上がりました。
リモート参加を考慮したバリューストリームマッピングのやり方
昨今、リモートワークをされる方が増えているかと思いますが、弊社でもリモートワークをしている開発メンバーが多くいます。
今回私たちがバリューストリームマッピングを実施するにあたり、リモートでもメンバーが参加しやすい方法を考え、実践しました。
以降の内容は、バリューストリームマッピングをリモート環境下で実施する際に、どのような工夫を行ったかにフォーカスをあてて話していきます。
使用したツール
Miro
前述したスライドでは、バリューストリームマッピングをオフラインでホワイトボードを使う形で記載されておりますが、メンバーがリモートでも参加できるようにするために、「Miro(ミロ)」というサービスを活用しました。
Miroはオンライン上で共同編集が可能なホワイトボードのサービスです。
Miroの無料プランでは編集可能なボードは3つまでですが、メンバー数無制限で利用することができます。
ZoomとSlackハドル
リモートでの参加メンバーとのコミュニケーションのためにZoomとSlackのハドル機能を利用しました。
バリューストリームマッピングの開始時のオリエンテーションでZoomに集まり、その後各チームでバリューストリームマップを作成する際にはチームの判断で別途Zoomの部屋で行うかSlackのハドル機能を利用しました。Zoomのみで行う場合にはブレイクアウトルームを活用すると良いかと思います。
参加メンバー
参加メンバーは以下となっており、開発メンバーほぼ全員を含めて実施しました。
- 開発責任者
- 開発チーム
- iOSエンジニア
- Androidエンジニア
- Webフロントエンジニア
- バックエンドエンジニア
- デザイナー
開発チーム毎にそれぞれバリューストリームマップを作成しました。オフラインでホワイトボードで実施した場合にはホワイトボードのスペースが限られるために、各チームが同時にバリューストリームマップを作成することが難しいことが予想されますが、Miroを利用することで各チームが同時並行でバリューストリームマップを作成することができ、限られた時間内で効率よく作業を進めることができたと思います。
事前準備
バリューストリームマッピング当日の作業を円滑に進めるために、事前に以下の図をMiroに作成しておきました。
開発プロセスの雛形
書き手によって表記方法をブレないようにするために、予め開発プロセスの雛形を作成して、コピー&ペーストで使用できるようにしました。
「無駄」の一覧表とマークのオブジェクト
「無駄」の内容は量も多く覚えるのに時間を要するため、一覧の内容をMiro内に配置することで、すぐに見返せるようにしました。
ステップ1と2の事前洗い出し
参加メンバー全員が集まれる時間が2時間であり、時間内で全てのステップを消化できないと思ったため、ステップ1(開発サイクルに関係するシステムを確認)とステップ2(開発サイクルの概要を確認)については、事前に各チームの代表者が集まり、Miroに図を作成しておきました。
バリューストリームマッピングで明確化された課題
バリューストリームマッピングを行った結果、出てきた課題として特に多かったのは仕様書やプルリクエストのレビューの待ち時間が多く、その結果全体のリードタイムが長くなっていました。この辺りはレビューに必要な人数を減らしたり、Botがレビューを促す仕組みなどを実施するなどの改善案を決めました。
また、細かいところだとカナリア環境にデプロイする際に手動での操作が発生していたり、自動テストを行った際に実装時の小さなミスにより自動テストが失敗することで手戻り率が多いこと、テストケースの作成を一人のメンバーが行っており属人化していることなどが洗い出されました。
日頃開発業務を進める中で時折同じような課題感を感じていたこともあったような課題も多々含まれておりましたが、バリューストリームマッピングを行うことで、それらの課題によってどれだけの「無駄」が発生していたのかが可視化され、改善するための良いきっかけを作ることができました。
最後に
バリューストリームマッピングを初めて実施してみたということ、またリモートでの参加を考慮した実施ということもあり、どうなるか不安ではありましたが、思ったよりも円滑に進めることができ、改善案も多数出たので、一定の成果があったのではないかと思います。
バリューストリームマッピングによって開発プロセス上の各プロセスにおけるLT(リードタイム)とPT(プロセスタイム)が可視化されたことで、改善後の効果を定量的に計測しやすくなったと思います。
今後は改善策を進めつつ、定期的にバリューストリームを実施して改善効果を評価し、DevOpsの第1の道である開発プロセスの高速化を進めていきたいと思います。
この記事が気に入ったらサポートをしてみませんか？