なぜDevOpsは正しく理解されてこなかったのか？〜ベンダーキーパーソンが徹底討論〜（前編）：「DevOps」が誤解されてきたこれだけの理由（3/4 ページ）
IoTやFinTechトレンドの本格化に伴い、DevOpsが今あらためて企業からの注目を集めている。だがDevOpsは、いまだ正しい理解が浸透しているとは言いがたい状況だ。そこで＠IT編集部では、国内のDevOpsの取り組みをリードしてきた五人のベンダーキーパーソンによる座談会を実施した。前後編に分けてその模様をお伝えする。
みんな「定義」を欲しがっている
藤井氏 「アジャイル開発でも同じことが起きていた」という話ですが、私はアジャイル開発が登場したとき、「定義」に対する期待値が変わったと感じたんです。それまではITILやCMMI（Capability Maturity Model Integration）のように、ある組織が定義を定め、テクノロジーのエリアも規定し、ゴールやマチュリティモデル（成熟度モデル）も用意するなど、明確な判断指標があった。換言すれば「それをやっているから安心できる」という定義があった。
しかしアジャイル開発ではそこが完全に変わってしまい、「定義」ではなく「マニフェスト」になってしまった。つまり、「マニフェストですから、実現手段は自由に選んでいいんです。フリーハンドでやってください」と言われた瞬間に、プロセス思考で来た人たちは、何をしていいか分からなくなってしまった。
それと同様に、（アジャイルを核とする）DevOpsも「実現手段は自分たちが自由に選んでいいんだ」「手段の選択肢を自由に選んで、自分たちがやり方を決めていくんだ」というところまで理解されていない。つまり「誤解」ではなく「腹落ちしていない」。
みんなどこかで「これをやることがDevOpsだ」といった「明確なToDoリスト」を探しているのではないでしょうか。そうすると、ベンダーによってツールのラインアップが広かったり狭かったりするため、それぞれDevOpsについて言っていることが違うように見える。それは「手段としてそろえている選択肢」が違うだけで、DevOpsについては各ベンダーとも同じことを言っている。こうしたことがDevOpsが分からなくなっている、どうしたらいいのか迷っている原因なのではないでしょうか。
編集部 アジャイルの軸となったリーン開発について、「あるチームには薬でも、それが別のチームにとっては毒となる」として、どう実践するかは「状況に応じて行われるべきだ」としたポッペンディーク夫妻の指摘も思い出されますね。
参考リンク：書籍でたどる「リーン」の本質（＠IT）
藤井氏 当然、組織によってやり方は違いますし、運用を外部に委託しているケースもあれば、インハウスでやっているケースもある。全てを同じスキームで語れるわけはないですよね。そうなると、「何をするか」は自分たちで決めていくしかない。でも、それはベンダーが示すことはできない。この期待のズレが、「ベンダーによって言うことが違う」ということになっているように思います。
長沢氏 「自分たちのやっていることは世の中とずれているんじゃないのか」「自分たちは何かを誤解しているんじゃないのか」という不安があるんですよ。私はいろんな企業の現場に呼ばれるんですが、訪問企業の3割ほどから「ウチでやっていることはアジャイルと言っていいのか」「DevOpsと呼んでかまわないのか」とよく聞かれます。
編集部 そこで「定義」のような拠り所が欲しくなる。
長沢氏 そこで私がお話しするのは、「今やっていることが、ビジネスフォーカスになっているか」「その目標に向かって、組織全体で同じ方向を向いて議論できているか」ということ。そうすると「あ、それはできているからいいのかな」という企業もあります。まずはそこを確認するといいように思います。
藤井氏 ただ大企業の場合、いろいろな部門がさまざまなことをやっているので、中には「DevOpsを導入する意味のない安定した領域」もある。注意したいのは、そうしたところにまで「これがトレンドですよ」と、無理にDevOpsを訴求するのもどうかということです。
一つの企業の中でも、「短時間での判断がビジネスの勝敗を決める」という領域もあれば、「保守が主体で改善を目的としていない領域」「ムダをなくしていく領域」など、いろんな領域がある。つまり「ビジネス目的が明確なところと、そうでないところ」をひとくくりにして、「ビジネスゴールを見据えて」といった話をしても、「そうでないところ」にとっては抽象度の高い話になってしまう。
適用領域の判断に役立つ「SoE／SoR」。しかし、これも基準でしかない
渡辺氏 その点、DevOpsの適用領域を考える際によく使われる「SoE（System of Engagement）／SoR（System of Record）」という言葉も、だいぶ浸透してきたなと思います。アプリケーション開発にしてもインフラ選択にしても、「スピードや変化への対応力が重要なSoE」と「データ保全性や安定性が重要なSoR」といった切り分けを一つの基準にして、プラクティスの適用や手段選択の在り方を考える傾向は強まっていると思います。
DevOpsとITILの適用領域。ガートナーではSoE／SoRの二つではなく、「System of Record（SoR：記録システム）」「System of Differentiation（SoD：差別化システム）」「System of Innovation（SoI：革新システム）」の三つに分類。SoIの領域に近づくほどDevOpsが向いており、SoRに近づくほどウォーターフォールやITILが向くとしている（提供：ガートナー／特集第2回「DevOps再入門〜DevOpsが生きる領域、ITILが生きる領域〜」より）
川瀬氏 ただ、SoEだけがDevOpsに向いていて、SoRではDevOpsは必要ないかというと、必ずしもそうではありません。実際、海外の金融機関などではSoRの領域でもDevOpsを適用している例がある。つまり「自社においてDevOpsが必要な領域」を自分たちで見極めることと、「その最適なやり方を自分たちで決め、実現手段の選択肢も自由に選んでいくんだ」というスタンスが非常に重要なわけです。
参考リンク：NationwideのDevOps導入事例（IBM）
Copyright © ITmedia, Inc. All Rights Reserved.