なぜDevOpsは正しく理解されてこなかったのか？〜ベンダーキーパーソンが徹底討論〜（後編）：「DevOpsとは？」の決定版。今ハッキリさせる「正しいDevOps」実践法（2/4 ページ）
IoTやFinTechトレンドの本格化に伴い、DevOpsが今あらためて企業からの注目を集めている。だがDevOpsは、いまだ正しい理解が浸透しているとは言いがたい状況だ。そこで＠IT編集部では、国内のDevOpsの取り組みをリードしてきた五人のベンダーキーパーソンによる座談会を実施。今回は後編をお伝えする。
関係者間のコンセンサスはどう取るか？
編集部 ただDevOpsやアジャイルは、大企業の開発プロジェクトでは難しいと言われてきました。それも取り組み方によるということでしょうか。
長沢氏 大企業のプロジェクトには「大規模プロジェクト」と「大人数プロジェクト」がありますが、大人数でやろうとすると、ステークホルダーとのコンセンサスを取りにくい点で難しい面はありますね。そこで重要になるのは、やはり「プロジェクトの目的をビジネスゴールに統一する」こと。
そのために、例えば「売上」「利益」「（サービスの）ユーザー数」など明確なKPIを設定する。ビジネスゴールにつながっているなら「サイクルタイムの安定」「MTTR（平均修復時間）」といった指標があってもいいと思います。大切なのは、それをビジネス部門、Dev、Ops、その他の関係組織、それぞれに個別のKPIではなく、共通のKPIとすること。それがないと拠り所がなくなって、細分化されたサイロになってしまう。
その上で重要なのが、「サイクルタイム」と「成果物の共同所有」。ビジネス部門、開発部門、運用部門が成果物を共同所有し、透明性を持って、同じ方向を向いてやっていくこと。このサイクルタイムを短くしてビジネスの動きに合わせていくことが重要で、そこで初めて自動化ツールなど省力化の手段が必要になる――企業の方にはこのように話すと理解してくれることが多いですね。
「このやり方でいいのか」と不安に感じている企業が多く、何らかの拠り所が求められているという話がありましたが、藤井さんもおっしゃられたように、まずマニフェストがあると、部門間でコンセンサスが取れるようになってくると思います。
DevOpsは誰がリードするのか？
編集部 「目的」は各関係部門が一緒に考えることが必要という話が出ましたが、例えば皆さんがDevOps関連で顧客企業を訪問される際、関係部門の方々がその場にそろうことは多いのでしょうか？
川瀬氏 こちらから言わない限りは、全部門がそろうとことはあまりないですね。ですから極力、ビジネス部門、基盤部門、開発部門、運用部門など関係する全ての部門のキーパーソンの方を呼んでいただいて、それぞれの部門で使われている言葉の定義にも配慮しながら、一つ一つ認識を合わせていくことが必要だと思っています。DevOpsに限らず、業務改善のときと同じだと思いますが。
長沢氏 私の場合は、以前は開発部門が多かったですね。今は、小規模の企業の場合ですが、音頭を取る方が経営層であることが増えてきました。その場には、各部門のキーパーソンが全員そろっています。
編集部 そうしたスタンスは本来、大企業でも大事ですよね。
渡辺氏 そこは重要なポイントだと思います。Bank of AmericaもINGバンクも、DevOpsはCEOイニシアチブです。草の根活動を否定はしませんが、ビジネス目的に向けて組織的に活動するとなると草の根だけではできないので。
牛尾氏 そうですね。先に話した米Targetも草の根活動から始めましたが、ある段階からトップダウンに移行しているんです。組織の壁を超えたり調整したりする必要があるので、上のサポートがないとどこかで破綻する。
渡辺氏 ちなみにINGバンクは、まず開発スタイルをウォーターフォールからスクラムに3年かけて移行したそうです。その後、開発部門だけでは目的を達成できないので、2年をかけてビジネス部門、運用部門との連携体制を築いた。その上でツールを入れた。約7年かけて月に6万デプロイできるようになったんですよ。
牛尾氏 マイクロソフトのDevOps事例も同様です。一朝一夕にできないんですよ。IBMさんも海外事例を複数発表していますね。
川瀬氏 そうですね。ただ内製化の傾向が強い欧米企業に対して、日本企業はSIerへの外注割合が高いこともあって、日本企業には海外事例がリアリティを持って響きにくい側面があります。「できたらいいよね」という意識はあるのですが。
ただ興味深いのは、DevOpsの話が実現に向けて自然と発展していく企業には二つの傾向があることです。それは先ほどの話のように、一つは経営層が中心となりトップダウンでやっていこうとしている企業。もう一つは内製化を意識している企業です。
牛尾氏 やはり、経営層のコミットと内製化はDevOps実現のカギだと思います。例えば、KDDIさんは大規模企業でありながらガンガンにアジャイルを回して、マイクロサービスアーキテクチャにしていた。上の方が音頭を取って、現場にもパッションのある人がいた。基本的に現場が自ら考えて実践しており、上もあまり余計なことを言わずに、その取り組みを見守っていた。本当に素晴らしい事例です。こうした例はこれからのロールモデルになっていくのではないかと思います。
参考リンク：KDDI Cloud Blog
川瀬氏 そうですね。大規模な企業にDevOpsの話をしていると、結局、話が人事論にまで発展してしまうこともあります。つまり最終的には、人事制度、役割のモデルまで完全に変えないと、なかなか大きな改革はしにくいのかなと思うんです。そういうところも日本では浸透しない背景の一つなのかなと。
長沢氏 逆に言うと、やらざるを得ないとなったら、そこまでやるしかないんですよ。そのモチベーションがないのだったら、できないんです。モチベーションがないところに、無理やりDevOpsを勧めるのはどうかというのは、そういう意味もあるんです。
編集部 世界的に話題になった書籍『The PHOENIX PROJECT』（邦題『The DevOps 逆転だ！』）も、やらざるを得ないビジネス環境があって、それに応えるために、プロジェクトチームがスピーディに開発・リリース・改善するためのあらゆる課題を自分たちで解決していく、といったストーリーでした。その中では経営層もそうですが、現場層も一定の危機意識を持っていると思うんですよね。
藤井氏 ただ、そこで「危機意識が足りない」と言って、脅迫しちゃうのもどうかと思うんです。先の話のように、企業にはさまざまな目的があるし、そもそもの必要性は自分たちで考えることなんですから。
長沢氏 危機意識は持っていても、冷静になるべきところは冷静にならないといけない。アジャイルもInfrastructure as codeもそうですが、ほとんど変化がないシステムの領域で無理やりやってもメリットは薄いですよね。必要なのは危機感というより、今のビジネス課題を見据えてそれを解決できるよう、「地に足を着けて変化に適応して計画し実行し続けられるかどうか」だと思う。上の人たちにしても、地に足の着いていない計画には軽はずみに賛同できないですよね。
牛尾氏 ただ僕は、少しでも「やりたい」と考えているのなら、やった方がいいんじゃないかとは思います。実際、やる方法なんていくらでもあって、やろうと思ったらたいていのことはできるはずです。やらないのは、結局のところ「やりたくないのでは？」とも思ってしまいます。
Copyright © ITmedia, Inc. All Rights Reserved.