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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

「自分たちでもできる！」と思う心がリードタイムを短縮する

バリューストリームマッピングのセッションを日本で実施する場合は、まず1つのプロジェクト／サービスに的を絞って、そのプロジェクトのDev、Ops、QA、UCD、プロダクトオーナー、マネージャーなどの関係者に参加してもらう。できれば全員に。そして、重要なことは、開発プロセスを変更できる権限を持っている人（つまり偉い人）に参加してもらうことである。

なぜ、「⁠開発のプロセスを変更できる権限を持っている人」に参加してもらうのだろうか。

バリューストリームマッピングを実施して、プロセスやリードタイムを見える化していると、誰の目にも「無駄」が明らかになってくる。しかし、現場のメンバーだけでは、無駄だとわかっていても「会社で決まってしまっていることだから……」と考えてしまい、改善につながらない場合が多い。ところが、そこに、開発プロセスを変える権限を持った人がいたら、その人に対して発言を促して聞いてみればよい。

たとえば、「⁠〇〇さん、この承認って明らかに無駄ですよね。これって削除できないですか？」と聞くと、今のところほぼ100％次のような答えが返ってくる。「⁠削除しちゃいましょう。リードタイムが短くなるなら大歓迎だよ⁠」⁠。

偉い人からすると、新しいことを導入して、リードタイムが短くなるなら方法などどうでもよいのである。しかも、追加でお金がかかるわけでもない。単に「やり方」を変えるだけなのだから。そういう発言を聞いていると、現場のメンバーも「あ、プロセス変えちゃっていいんだ」と認識してくるので、どんどん議論が活発になって、自ら「無駄」を指摘して、みんなと共有できるようになってくる。

このプロセスが日本で効果的な理由は他にもある。単に数字だけで「効率化」されることを言われても誰も納得しないが、自分が自らやってみて、「⁠無駄」を発見・共有する。そして、次にその無駄を削除したり、自動化したりして、解決策を一緒に考えることによって自分たちでも無理なく改善するだけで、リードタイムが劇的に短くなるという効果が明らかになるからだ。つまり「自分でできる！」と思えるのである。これは大変重要なことだ。

ミドルマネジメントにも安心を与えること

バリューストリームマッピングがもたらす効果として、重要なことは「わかりやすさ」だ。その場にいなかった人、たとえばCEOクラスの人にとっても、成果が説明しやすい。バリューストリームマッピングを実施すると、各プロセスのリードタイムがわかるので、それを合計すると、現在のリードタイムが明確になる。そして、無駄を省いて、新しいプロセスを考えて、自動化をどうしていくかを考えていくと、実現可能なリードタイムが簡単に算出できる。たとえば筆者が実際に行った例では、バリューストリームマッピングを実施することによって、現在のリードタイムが8.5ヵ月であったが、それが1週間まで無理なく短縮できるとわかった。

DevOpsの変革を実施することで、リードタイムが8.5ヵ月から1週間になったらそれはとてつもないビジネスバリューだ。たとえば、CXXの役職の人に「DevOps を導入すると、現在のリードタイムが8.5ヵ月なんですが、これが1週間になる見込みなんです。やってもいいですね？」と言って誰が反対するのだろうか。

つまり、圧倒的にわかりやすいのだ。

すると、かなり上位まで改善プロジェクトのコミットを得られるようになる。そうなったときに、しっかりトップを巻き込んで、この改善活動にチャレンジしたミドルマネジメントは、たとえ失敗しても高い評価を与えるというコミットを得ておくとよい。そうすれば、ミドルマネジ メントのほうも安心してこの改善活動に参加できる。

よく、ミドルマネジメントが石頭で反対ばかりする、と言う人がいるが、重要なことはその人を否定することではなく、理解することだ。そこには絶対的にその人にとって重要な理屈が存在する。それはたいていは「恐れ」だ。だから、その「恐れ」を取り除いてあげればよいだけなのだ。

たった4時間のワークショップがデリバリーを劇的に改善する

バリューストリームマッピングは、1つのプロジェクトにつき4時間程度で実施できる。もちろん、このワークショップを実施した後に、実際にプロセスを変更したり、自動化を実施したりする必要がある。しかし、プロセスを変えるにしろ、自動化するにしろ、ここで作られたマップがあればその後がとても明確で、簡単になる。そして、チーム全員を巻き込んでいることで、共通認識、自分たちでもできるという思いがあるため、ムードもかなり良くなるのだ。

筆者はバリューストリームマッピングを実施した後には、「⁠ハックフェスト」という活動をお勧めしている。エキスパートとともに、バリューストリームマッピングで発見した「無駄」のうち、自動化できる部分を実際にハッカソンで自動化してしまうのだ。だいたい3日から5日程度で実施している。そうすると、実際にリードタイムが劇的に短縮される。

その後、定期的に改善の様子をモニタリングしていくと、どんどんリードタイムが短くなってくる。筆者が実施した他の例でも、13日だったリードタイムが数ヵ月で2日になった。他の例ではなんと8.5カ月が実際に1週間に短縮された。劇的な効果だ。ただし、この場合も、無理にあわててリードタイムを短くしないことだ。チームの改善にはチームのペースがある。ただ、定期的にモニターして、どの程度リードタイムが短くなったかの計測とデモを共有するようにして、自分たちのペースで改善する。

すると、あわてなくてもすぐにリードタイムは短くなるのだ。ただし、バリューストリームマッピングは、2時間以内にデリバリーできるほど自動化できているチームには、あまり有効でない場合もある。そのケースでは、Gene KimのThree Waysに従って、本番からのフィードバックの速度を速める方向に注力してくとよいだろう。

まとめ

バリューストリームマッピングは、リードタイムの短縮だけではなく、日本では変革の効果を劇的に高める効果があり、大変お勧めの技法だ。興味のある人は次のプレゼンテーションの資料を公開しているので参照されたい。