バリューストリームマッピングの重要性

みなさんの会社で，DevOps変革を推進するために，最初の第一歩として何をすべきだろうか。筆者は間違いなく「バリューストリームマッピング」をお勧めする。バリューストリームマッピングは，リーン生産方式の技法の1つであり，製品やサービスを顧客に届けるために必要なプロセスを分析するのに使用される。トヨタで使われていた手法をもとにしている。

バリューストリームマッピングの話を始める前に，Gene Kimがまとめた「DevOpsのThree Ways」についてお話ししておきたい。これは，DevOpsの3つの目的を明確にしたものだ。1つ目はアイデアを思いついてから，実際にリリースするまでのリードタイムを短縮する。次に製品からのフィードバックを迅速化する。最後にフィードバックから，学びを得るサイクルを回して，継続的で，頻繁な学びのサイクルを確立する，となっている。

バリューストリームマッピングは，最初の目的，つまり「リードタイムの短縮」に絶大なる効果を発揮する方法だ。しかし，なぜこれが日本で「特に」重要なのだろうか。それは，リードタイムの短縮に劇的な効果をもたらすだけではなく，工夫をすれば，日本で不可能とすら思われるさまざまな「うちではできない」を徹底的に破壊してくれるところにある。

図1は，筆者が頻繁に行っているバリューストリームマッピングの例だ。マイクロソフトでの実践例の1つであり，左側から右側に向かって，アイデアを思いついてから実際の本番環境にデリバリーするまでのステップをバリューストリームマップとして見える化している。単に見える化するだけではなく，リードタイムや，プロセスタイム（実行時間⁠）⁠，無駄な時間を追跡している。

この見える化によって参加者が，開発やリリースのプロセスに対して共通認識を持てるだけではなく，無駄を共有して，実際に自動化するポイントを明確にできる。

自動化だけではリードタイムは短縮できない

DevOpsのプラクティスを使うと，さまざまな自動化の技術を使うことでリードタイムの短縮が可能になる。しかし，ツールを導入したところで，リードタイムが短縮されるかどうかはわからない。たとえば，すばらしい自動化の技術を持ったメンバーがすばらしいツールを使って，デプロイプロセスの自動化を行ったとする。しかし，会社のルールで，「⁠本番環境へのデプロイの際は，紙ベースで，受け入れ承認を行ったエビデンスを作成しなければならない」と決まっていた場合，それだけで，たとえばソースコードの変更から2時間以内に本番環境へのデプロイを自動化するといった高度なリードタイムの実現が難しくなる。

そのため，DevOpsの時代になったら，自動化するだけではなく，実際にリードタイム短縮の足かせになっている「無駄」を特定して，それを改善していかなければならない。たとえばそれは，承認かもしれないし，無駄な作業かもしれない。本来自動化できるものが手動で行われているかもしれないし，誰か1人だけしかできない作業があって，そこがボトルネックになっているかもしれない。そういったリードタイムの足かせになっているところを見える化して，その改善を実施して，初めて本当にリードタイムが短くなるのだ。

しかし，会社のルールを変えるなんて日本では相当ハードルが高く感じる。そこでバリューストリームマッピングの手法が大変役に立つのだ。

上下関係をぶち壊してくれるバリューストリームマッピング

新しい技術や，考え方を日本に導入するときにいつも問題になるのが，「⁠自分のところでは無理」問題だ。新しい考えや技術を紹介しても，「⁠すばらしいんだけど，うちの会社では無理」と実施する前にあきらめてしまう問題がある。これは無理もないところがある。現場からすると，会社の方針で決まっていることを変えることは無理，もしくは難しいと感じてしまうからだ。一方，トップマネジメントからすると，実は「自社を改革して生産性を高めたい。そのためには方法などはどうでもいい」と思っているケースがほとんどだ。

一方，ミドルマネジメントからすると，新しい方法はあまり使いたくないのが本音だろう。たとえば，プロジェクトの利益率80％といった目標を持っているミドルマネジメントからすると，なぜわざわざ成功するかどうかわからない新しい方法に取り組まないといけないのだろうか。もし実施して失敗したら，評価が下がるだけなので，使いたくないと思うのはとても自然なことだ。

そのために，新しい開発，アジャイルやDevOpsなどを導入しようとしても，反対が多くてなかなか前に進まない。実際にこういった統計がある。Alistair Cockburnという著名なアジャイルコーチがまとめたデータ（※1）だ。これは世界各国のそれぞれの国でアジャイルのような考え方の導入がどの程度難しいかを示す指標である。

※1

http://www.clearlycultural.com/geert-hofstede-cultural-dimensions/power-distance-index/ を元にAlistarが集計したhttps://twitter.com/TotherAlistair/status/731591878777417729を参照。

ごらんのとおり，日本はダントツに「アジャイル／ DevOps」の導入が難しい国になっている。調査した国の中でいちばんと言ってよいだろう。これは，上下関係が厳しい，雇用制度が終身雇用を引きずっている，たくさん頑張ることが少ない工数で大きな価値を生み出すことより評価されるなど，さまざまな文化的背景があるためだ。

バリューストリームマッピングをうまく運用すれば，この壁を壊してくれるのに大変役に立つのだ。