なぜDevOpsは正しく理解されてこなかったのか？〜ベンダーキーパーソンが徹底討論〜（前編）：「DevOps」が誤解されてきたこれだけの理由（2/4 ページ）
IoTやFinTechトレンドの本格化に伴い、DevOpsが今あらためて企業からの注目を集めている。だがDevOpsは、いまだ正しい理解が浸透しているとは言いがたい状況だ。そこで＠IT編集部では、国内のDevOpsの取り組みをリードしてきた五人のベンダーキーパーソンによる座談会を実施した。前後編に分けてその模様をお伝えする。
DevOpsが誤解されたのは、誰のせい？ 何のため？
編集部 では一方で、DevOpsにさまざまな解釈が生まれてしまった要因は何だと思いますか？ 本特集ではこれまでの取材を通じて、「DevOpsとは、変化するビジネスニーズに迅速に応えることを目的に、ITサービスをスピーディにリリース・改善できる「仕組み」を作ること」といった説明をしてきました。
参考リンク：
- DevOps再入門（＠IT）
- 国内DevOpsトレンドは、これからが本番（＠IT）
しかし2013年、特集第1クールをスタートした当初は、「文化」「自動化ツール」などフォーカスポイントが偏っていた反省もあります。そうした自戒も含めて、Webメディアの責任も大きいと思うのですが。
川瀬氏 まず、DevOpsは明確な「定義」があるわけではないので、国内に入ってきた当初はある意味“言った者勝ち”で、「JenkinsやChefを使うのがDevOpsだ」「何かを自動化するのがDevOpsだ」「DevOpsは文化だ」といった捉え方をしたメディアも少なくなかったのではないでしょうか。「DevOpsとは何だろう」と多くの人が気にしている中で、そうした情報がWeb上に公開されれば、それに飛び付いて見てしまいますよね。その後、「DevOpsとは何ぞや」がきちんと考えられることなく、多数の記事が公開されてしまった。これも誤解された要因の一つかなと思います。ベンダー側も、メディアに比べると情報の出し方が遅かったように思います。
編集部 確かに“言葉先行”の弊害は大きかったように思います。
渡辺氏 「言葉」に惑わされていた部分はありますね。例えば「DevOpsは、DevとOpsが仲良くすることだよね」という理解に基づいて、「当社では開発と運用は協力し合っているからDevOpsをやっている」とか、「ウチは開発をSIerに外注しているから、そもそもできませんね」といった具合に曲解してしまう。「開発と運用が一緒になってリリースサイクルを加速する」という話ではなく、「開発と運用が協力し合う文化」といった単なる根性論のような解釈も広く流布してしまった。
「何のために開発と運用が一体となって、リリースサイクルを加速しなければいけないのか」というと、「変わり続けるビジネスニーズにスピーディに応えるため」です。メディアの記事でもそこが抜け落ちているか、扱いが小さい例が多かった。
牛尾氏 国内事例が少なかったことも挙げられると思います。2015年10月19〜21日に米サンフランシスコで開催された「DevOps Enterprise 2015」というイベントに行ってきたんですが、米国と日本で大きく違うのは、やはり「実際に導入している企業数」だと思います。例えば、小売業の米Targetでは80デプロイ／Week、10インシデンス／month（週に80回デプロイし、月に発生する障害が10件以下）といった例があります。すごいですよね。彼らは現場層が草の根活動から始めてトップまで話を持って行き、全社に取り組みを広げていったそうです。
参考リンク：DevOps Enterprise 2015 参加レポート（マイクロソフト「TechNet Blogs」）
Bank of Americaや国防総省関係企業などもDevOpsをやっていて、それぞれがビジネスバリューを発表している。ライバルがそういうことをしていたら、「うちもやらないと負けてしまう」といった危機感を各社が抱いている。日本はギークの間で盛り上がった後、キャズムの谷が長い傾向がありますが、彼らは実際にやってみることで「こうしないとバリューが出ない」といった気付きを得て、間違っていた理解も自然に修正されていく。
DevOpsは、ツールやプラクティスの話ではない
渡辺氏 そういう事例が日本にはあまりないですよね。また、日本ではDevOpsの事例というとWebサービス系企業が多いために、「DevOpsはそういう会社がやるものなんだね」というイメージが強い。
川瀬氏 さらに日本の場合は、「事例＝ツール」という理解に落ちてしまう傾向がありますよね。そうすると、話のポイントが本質的なところよりも、「これを入れたからDevOpsができた」といった話になってしまう。
長沢氏 「アジャイル開発」でも同じことが起きているんです。言葉先行、プラクティス先行、ツール先行で、「導入することで何が起こるのか」という期待感が先にあり、具体的に「何が目的なのか」とか、「それをやることで現場がどうなるか、ビジネスがどうなるか」までは考えない傾向が強かった。
「CIをやればDevOpsだ」といった具合に、どうしても「テクノロジー」や「プラクティス」の話がフォーカスされがちなんですね。「何かを使っていれば、そのプラクティスの名称を使える」とか、逆に「少しでも違うやり方をしていたら、その名称は使えない」とか。例えば、アジャイル開発の一手法である「スクラム」の話をしているとき、スクラムの定義から少しでも逸脱したことをやっていると、「それはスクラムじゃないよね。これ何て呼ぶの」という話になってしまう。
結局、DevOpsも具体的なやり方の話に落としていくと、ツールやプラクティスの話にならざるを得ないところがあった。それを読む側からすると、DevOpsは「ツールやプラクティスの話」として映ってしまう。メディア、ベンダー、実践者、それぞれ情報が偏っている傾向が強かったと思いますね。「何をすることなのか」がフォーカスされてしまい、「なぜやる必要があるのか」という話があまり注目されてこなかった。
Copyright © ITmedia, Inc. All Rights Reserved.