日本のDevOps変革を促進するバリューストリームマッピング

アジャイルとDevOpsを組織全体に適用するための指南書『変革の軌跡』が2017年1月25日(水)に発売されます。本書の発売を記念して、マイクロソフトの牛尾剛さんにバリューストリームマッピングについて寄稿いただきました。

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

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

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

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

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

図1 バリューストリームマップ
図1

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

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

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

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

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

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

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

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

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

表1 アジャイルの導入難易度の表
アジャイルの導入難易度 権力の差(PDI) 個人の自立(IDV) 男性社会(MAS) 不確実性忌避(UAI) 長期指向(LTO)
日本 80 54 46 95 92 80
フランス 66 68 71 43 86
イタリア 65 50 76 70 75
アメリカ 49 40 91 62 46 29
イギリス 45 35 89 66 35 25
ドイツ 55 35 67 66 65 31

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

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

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

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

図2 バリューストリームマッピングに参加する人たち
図2

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

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

たとえば、⁠〇〇さん、この承認って明らかに無駄ですよね。これって削除できないですか?」と聞くと、今のところほぼ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に従って、本番からのフィードバックの速度を速める方向に注力してくとよいだろう。

表2 無駄のリスト
無駄の種類 マーク 定義
欠陥の無駄(Defects) D 誤った、抜けのある、不透明な情報や成果物。システムを破壊し、解決するのに時間と労力が必要 壊れたビルド、不正確な設定、不正確な要求
マニュアル/モーション(Manual/Motion、Handoffs) M オーバーヘッド、コーディネーション、作業引き渡し、またはセットアップや仕事の実行に関する非効率性 ミーティング、手動デプロイ、チーム間の作業引き渡し
待ちの無駄(Waiting) W 次の価値のあるステップを開始、または終了することの遅れ 承認待ち、リソースの待ち、予定されたミーティング待ち
未完了の作業(Partially Done) PD 未完了の作業、何らかの操作。他者からの入力やアクションが必要となる。欠陥とタスク切り替え、待ちを招く デプロイされていないコード、不完全な環境設定、実行中バッチ
タスクの切り替え(Task Switching) TS タスクの切り替えは、高価なコンテキストスイッチを招き、エラーが発生しやすくなる 進捗上限による無駄作業、障害による中断、アドホックなリクエスト
余分なプロセス(Extra Process) EP 価値のないステップやプロセス。たいていは、公式、非公式な標準作業に含まれる 不要な承認、不要なドキュメント、無駄なレビュー
余分な機能(Extra Feature) EF 機能、たいていは実装フェーズで追加されたもの。リクエストされていない、ビジネスに沿っていない、顧客価値がない “次に必要かもしれない⁠⁠、不要なアップデートや要求、望んでいない
ヒーローまたはヒロイン(Heroics) H 仕事を完了させる、または顧客を満足させるために、ある人に大変な負荷がかかっている状態。ボトルネック 数日必要なデプロイ、長年の知識が必要、極端な調整が必要

まとめ

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

おすすめ記事

記事・ニュース一覧