Value Streamの見える化と最適化＜Value Stream Mapping＞
第一回、第二回でのValue Stream Managementのお話においては、システム開発における工数と品質の数値化に関して説明しました。
Value Stream Managementでは数値として「リードタイム」を重要視しており、その分析を行うことも出来る方法が今回の主題であるValue Stream Mappingです。
～ Value Stream Mappingとは ～
Value Stream Mappingは以下のように説明されています。
“Value Stream Management の中でも、業務プロセスを「物と情報の流れ」の図によって表すことで価値を効率よく生み出す部分と無駄の多い部分を明確にし、システム開発においてはリードタイムを短くすることに大きな効果を発揮する” 以下のような図を作成してボトルネックや問題点、リスクなどの分析使用出来ます。
システム開発においてリードタイムを短くすることが可能になるものだと分かりますが、そもそもリードタイムとは何でしょうか。
リードタイムを説明すると “工程や作業の最初から最後までにかかる時間”となりますので、例えば開発したシステムのアプリをテストするためのモバイルデバイスを調達にかかる時間で考えてみます。
リードタイム ＝ ‘デバイスを入手した時間‘ － ‘デバイス調達を開始した時間’
処理全体では以下のような様々な工程が必要となるかと思います。
- 必要な機種を選定する
- 価格を調査する
- 業者を選定する
- 業者から見積りを入手する
- 予算申請を行う
- 予算許可を入手する
- 購入処理を行う
- デバイスを受け取る
この工程全体にかかる時間（期間）ですが、実際には“機種選定で議論する時間”、“業者に依頼してから見積りが来るまでの時間”、“購入してからデバイスが届くまでの時間”などのタイトルからは見えない作業や待ち時間が含まれているはずです。
このように工程を洗い出し、かかっている時間を細かい単位で分析したのち、作業の時間短縮や待ち時間の解消など改善ポイントを探すことでリードタイムの削減を進めます。
実際にはどのようにして分析を行うのか見てみましょう。
Value Stream Mappingの事前準備
Value Stream Mappingは各チーム、部署の代表者が同じ場所に集まって行います。
開発するシステムが複数のサブシステム／サービスに分かれている場合はそれぞれの代表、またセキュリティやネットワーク、データベースなどそれぞれのチームの代表およびマネージャも参加して進めます。
このため、事前の連絡やスケジュール調整が大変重要になりますので、組織を横断して声がけが可能な方の協力を得て進めて下さい。
集まってからValue Stream Mapを完成させるまで短くても半日以上の時間がかかりますので、参加者には目的と時間、当日の作業内容を伝え、事前に理解してもう必要があると思います。
Value Stream Mapping当日は参加者全員が収容可能な部屋と１０枚ほどの大きな紙、３色以上のペン（マジック）を数セット用意しておきます。
準備が整ったら、ファシリテータ（あなた）がValue Stream Mappingの概要を説明し、壁に貼った紙に対してどのようにValue Stream Mapを記入していくのか方法を説明します。
記入は参加者自身にやっていただきます。
Value Stream Mappingの分析の流れ
Value Stream Mappingは以下のような流れで実施します。
- アーキテクチャ全体象の共有
- プロセスに関するディスカッション
- プロセスの詳細を記述
- 最終確認
- 「ムダ」および「リスク」の場所や理由を記入
- 改善方法のディスカッション
アーキテクチャ全体像の共有 ： 代表者が対象システムの全体像を説明し、各チームの代表から不足点を補足説明してもらうことで、全体像を共有します。
プロセスに関するディスカッション ： システムのプロセス（流れ）を紙に書き出す前にディスカッションし、抜け漏れが無いかおおまかに確認します。
プロセスの詳細を記述 ： 壁に貼った紙の一番右にゴールを記述し、そこから左に向かって順番にプロセスを記述していきます。複数のプロセスを纏めて扱える場合は、枠で囲って分かりやすくしておきます。
また、プロセスの下にはその工程で必要な（かかった）時間を記入しておきます。
最終確認 ： 記入したプロセスを全員で確認し、間違いや漏れをチェックします。
「ムダ」や「リスク」が発生している場所や理由を記入 ： 各プロセスにおいて無駄な時間が発生していると考えている個所、問題が起こるリスクがある箇所に、その時間や理由と思われるもの（返信待ち、リソース的なボトルネック、環境やシステムのスケジュール調整不足、など）を記入していく。
改善方法のディスカッション ： 「ムダ」と思われる箇所に対して、どのようにすれば「ムダ」を減らすことが出来るのかをディスカッションします。
Value Stream Mappingのサンプル
例えば、モバイルアプリを開発しており、そのテストに非常に多くの工数がかかっているとします。そのシステムの開発にかかわるマネージャ、各開発チーム、テストチームが集まってテストに関連したプロセスをValue Stream Mappingで書き出したとします。
このサンプルでは３つの問題点でテスト作業が遅延しており、セキュリティリスクも存在していたと判明しました。
- テスト用デバイスを準備する際、他のチームが既に同じものを持っているか、自分たちがテストしたい時期にそのデバイスを借りられるかの確認に時間がかかっていた。
- テスト作業を社外で行う場合があり、開発中のモバイルアプリを社外に持ち出す必要があったため情報漏洩のリスクがあった。
- 実際にデバイスを使用してテストを行う際に、誰かが使用中の場合や故障で使用出来ないなどのケースがあり、テストが遅延する場合があった。
これらの問題点を確認し、以下のような解決策を検討することになると思います。
- テスト用モバイルデバイスを社内で一元管理し、どのようなデバイスがあり、いつテストに使用出来るのかスケジュール管理も行える環境を用意する。
- デバイスはVPNのネットワークアクセスで外部からもリモート操作可能にし、デバイスやアプリを外部に持ち出す必要が無いようにした。
- デバイスを集中管理することで重複を減らし、削減出来た分を予備のデバイス準備に回すことで故障などによる突発的な原因によるテスト遅延を防ぐことにした。
Value Stream Mappingの代表的な表記
Value Stream Mappingの表記には様々なパターンがありますので、ネットで検索して自分の担当しているシステムに合ったものを見つけていただくのが良いかと思います。
今回のサンプルは、Microsoft Power Point用に配布されていた表記パターンを使用しており、以下のような意味で使用しています。
Value Stream Mappingの体験例
参考までに私が最初にValue Stream Mappingのファシリテータを行った際の情報を記載します。
会社 ： IT系システム開発会社
対象プロジェクト ： 社内のシステム開発プロジェクト
参加者 ： 同プロジェクト内のチーム毎の代表の方々
実施時間 ： 約半日
本来は複数の部署の代表に集まっていただくべきですが、初回ということもあり普段からお付き合いのあった部署の複数チームの方に集まっていただき、気兼ねなく現状や問題点に関してディスカッションいただく場としました。
“Agile開発とそれに伴うCI/CDに取り組みたいが普段の業務が忙しくて難しい”との悩みをお持ちでしたが、開発プロセスをValue Stream Mapに書き出しビルドプロセスを見直すことで、単体テストの実施を自動化できるかもしれないと改善ポイントを見出されていました。
それぞれのチームで分かれて作業していると開発プロセスを見直すということは合意を得るのが難しいですが、集まって問題点を全員で見つけて行くと自然な形で次に取り組むべき作業を認識することが出来、モチベーション高く自主的に作業を行っていけるようでした。
Value Stream Mappingの効果
実際にValue Stream Mappingを実施した結果、以下の効果を実感することが出来ました。
- 各部署・チームの代表者が参加することで、情報共有と合意形成が可能
- それぞれが課題や解決策を考えることで、自分自身の考えで改善を進めることが可能＝＞上層部からの指示やベンダー主導のPOCよりも、自主的な活動としての認識が強く生まれる
- 上層部もオブザーバとして参加することで課題や改善必要性への理解が得られる＝＞活動の予算や工数の確保への承認が比較的容易
今回のまとめ
システム開発のプロセスを分析・改善する方法として、Value Stream Mappingが使用可能であることを説明しました。
Value Stream Mappingによって「ムダ」を見つけて改善し、リードタイムを短くすることで短期間でのシステム更新を可能にし、企業としてのDevOps導入と促進を
次回は、開発プロセスにおいて改善を進める意味・目的を改めて考える、Developer Experience（開発者体験）に関してお話いたします。
