本特集ではこれまでの取材を通じて、「DevOpsとは、変化するビジネスニーズに迅速に応えることを目的に、ITサービスをスピーディにリリース・改善できる「仕組み」を作ること」といった説明をしてきました。ツール」などフォーカスポイントが偏っていた反省もあります。した自戒も含めて、Webメディアの責任も大きいと思うのですが。DevOpsは明確な「定義」があるわけではないので、国内に入ってきた当初はある意味“言った者勝ち”で、「JenkinsやChefを使うのがDevOpsだ」「何かを自動化するのがDevOpsだ」「DevOpsは文化だ」といった捉え方をしたメディアも少なくなかったのではないでしょうか。「DevOpsとは何だろう」と多くの人が気にしている中で、そうした情報がWeb上に公開されれば、それに飛び付いて見てしまいますよね。その後、「DevOpsとは何ぞや」がきちんと考えられることなく、多数の記事が公開されてしまった。これも誤解された要因の一つかなと思います。ベンダー側も、メディアに比べると情報の出し方が遅かったように思います。確かに“言葉先行”の弊害は大きかったように思います。「言葉」に惑わされていた部分はありますね。「DevOpsは、DevとOpsが仲良くすることだよね」という理解に基づいて、「当社では開発と運用は協力し合っているからDevOpsをやっている」とか、「ウチは開発をSIerに外注しているから、そもそもできませんね」といった具合に曲解してしまう。「開発と運用が一緒になってリリースサイクルを加速する」という話ではなく、「開発と運用が協力し合う文化」といった単なる根性論のような解釈も広く流布してしまった。「何のために開発と運用が一体となって、リリースサイクルを加速しなければいけないのか」というと、「変わり続けるビジネスニーズにスピーディに応えるため」です。メディアの記事でもそこが抜け落ちているか、扱いが小さい例が多かった。国内事例が少なかったことも挙げられると思います。2015」というイベントに行ってきたんですが、米国と日本で大きく違うのは、やはり「実際に導入している企業数」だと思います。小売業の米Targetでは80デプロイ/Week、10インシデンス/month(週に80回デプロイし、月に発生する障害が10件以下)といった例があります。彼らは現場層が草の根活動から始めてトップまで話を持って行き、全社に取り組みを広げていったそうです。Americaや国防総省関係企業などもDevOpsをやっていて、それぞれがビジネスバリューを発表している。ライバルがそういうことをしていたら、「うちもやらないと負けてしまう」といった危機感を各社が抱いている。日本はギークの間で盛り上がった後、キャズムの谷が長い傾向がありますが、彼らは実際にやってみることで「こうしないとバリューが出ない」といった気付きを得て、間違っていた理解も自然に修正されていく。いう事例が日本にはあまりないですよね。日本ではDevOpsの事例というとWebサービス系企業が多いために、「DevOpsはそういう会社がやるものなんだね」というイメージが強い。日本の場合は、「事例=ツール」という理解に落ちてしまう傾向がありますよね。すると、話のポイントが本質的なところよりも、「これを入れたからDevOpsができた」といった話になってしまう。「アジャイル開発」でも同じことが起きているんです。言葉先行、プラクティス先行、ツール先行で、「導入することで何が起こるのか」という期待感が先にあり、具体的に「何が目的なのか」とか、「それをやることで現場がどうなるか、ビジネスがどうなるか」までは考えない傾向が強かった。「CIをやればDevOpsだ」といった具合に、どうしても「テクノロジー」や「プラクティス」の話がフォーカスされがちなんですね。「何かを使っていれば、そのプラクティスの名称を使える」とか、逆に「少しでも違うやり方をしていたら、その名称は使えない」とか。アジャイル開発の一手法である「スクラム」の話をしているとき、スクラムの定義から少しでも逸脱したことをやっていると、「それはスクラムじゃないよね。これ何て呼ぶの」という話になってしまう。結局、DevOpsも具体的なやり方の話に落としていくと、ツールやプラクティスの話にならざるを得ないところがあった。それを読む側からすると、DevOpsは「ツールやプラクティスの話」として映ってしまう。メディア、ベンダー、実践者、それぞれ情報が偏っている傾向が強かったと思いますね。「何をすることなのか」がフォーカスされてしまい、「なぜやる必要があるのか」という話があまり注目されてこなかった。メールマガジンをご購読ください。申し込みページへITmediaはアイティメディア株式会社の登録商標です。