あなた、そう、あなた：DevOps の人的問題

DevOpsという言葉を耳にしたことがあるでしょう。これは、開発者とシステム管理者が同じチームで緊密に連携し、企業が独自に開発したソフトウェアをサポートするプロセスです。

わかっています、わかっています、親愛なる読者の皆さん。あなたは AS/400 を運用して以来ずっとこれをやってきたのです。毎週のリリースは誰も本当に必要としていません。そしてもちろん、お気に入りの「これはコンサルタントがお金を稼ぐ現在の方法に過ぎない」のです。

DevOpsは、これらすべてを兼ね備えているだけでなく、それ自体が一つの存在であることを示唆しています。プログラマーとしてキャリアをスタートさせて以来、業界アナリスト、ストラテジスト、そして今ではマーケターとして、ソフトウェア開発とデリバリーのプロセスを改善する方法を学びたいという探求心が私を突き動かしてきました。DevOpsは、現状において最良の方法であるように思われます。

IT 部門はこれまで私のために何をしてくれたのでしょうか?

DevOpsを実施する主な動機は、アプリケーションの稼働時間（通常はモバイルアプリとWebアプリ）を確保すると同時に、基本的にいつでも、通常は週ごとまたは日ごとに、新しいコードを本番環境にリリースできるようにすることです。おそらく企業は、これらのメリットを、カスタム開発ソフトウェアよりも競争力のあるものにしたいと考えているでしょう。より多くの機能を提供するだけでなく、ユーザーとの短いインタラクションによるフィードバックループを活用して、アプリを継続的に改良していくことで、競争力を高めたいと考えているはずです。

ITが企業のイノベーションを支援するという夢を実際に実現するとなると、状況はあまり喜ばしいものではありません。深酒をする口実を作りたい時によく見るのが好きなチャートの一つが、カッター・コンソーシアムのこのグラフです。

イノベーションに関して言えば、わずか3年の間にITの有用性は急落しました。率直に言って、ITは最悪です。

長年DevOpsを研究してきた中で、DevOpsとはこの問題を解決する「方法」、つまりプロセスとマインドセットであることに気づきました。一方、継続的デリバリーとは「何」、つまり導入する「ツール」です。だからこそ、私は継続的デリバリーをDevOps導入の指標として捉えているのです。

CDをやるんですか？ええ、もちろんです...

継続的デリバリー (CD) は、メインフレームの時代から多くの人が行ってきたと言われるものの 1 つですが、ある調査によると、現実は通常異なります。

継続的デリバリーを実践していると考えている人は少なくありませんが、教科書的な定義と比較すると、彼らはむしろ素人であり、最も簡単なプラクティスだけを選んで、残りは省いています。

これらの数値は低いものの、前年比での成長は急速な変化と進歩を示しています。組織が改善の方法を見出しさえすれば、改善への強い意欲が生まれます。

DevOps を少し加える

継続的デリバリーのトレーサー以外にも、DevOpsが本当に主流なのかを見極める上で参考になる最新の業界調査データがあります。ガートナーは昨年秋に調査を実施しました。保守的で時代遅れだと片付けてしまいがちですが、DevOpsが主流になったかどうかを問う際にまさに必要なのは、まさにこの調査結果ではないでしょうか。

ガートナーが2015年9月に383人の回答者を対象に実施した調査は、前年比の調査ほどのインパクトはありませんが、DevOps導入の勢いが強いことを示しています。回答者の29%が実際にDevOpsを活用しており、16%が本番環境でDevOpsのアプローチを採用し、13%が試験運用中でした。DevOpsのような新しい取り組みとしては、小規模ではありますが、印象的な数字です。

挑戦することは失敗への第一歩である

常に優れた年次調査であるPuppet Labs DevOps調査のような長期的な調査は、アイデアが機能することを示していますが、DevOpsの導入となると、状況はそれほど楽観的ではありません。ソフトウェアプロセスをDevOps化したいグループと仕事をした際に、多くの場合、必要な組織的変化の規模を過小評価しています。彼らはソフトウェアをレゴキットの組み立てに例えています。優れたソフトウェアを作ることは、毎回レゴを一から作り直すようなものです。このような継続的な学習を促進するには、比喩的に言えば「イノベーション工場」を生み出すプロセスを導入する必要があります。DevOpsの考え方は、これらの「工場」の運営方法の多くを説明していますが、それは現状とは大きく異なることがよくあります。

私が学んだのは、これは本質的な問題だということです。つまり、人々が変化に抵抗するという本能が、DevOpsのマインドセットへの変革を阻んでいるのです。だからこそ、DevOpsのカルトリーダーたちは「文化」について延々と語り続けるのです。

問題は、マネージャーがチームに「The Phoenix Project」のコピーを渡せば「DevOpsをやってくれる」と勘違いしがちなことから始まります。マネージャーは、変化を円滑に進めるために、インセンティブと行動を変える必要があります。しかし、マネージャーだけではありません。スタッフもプログラムに適応する必要があります。もしかしたら、実際にプログラマーと話をしなければならないかもしれません！ あるいは、もっとひどいことに、システム管理者と話をしなければならないかもしれません！

このコラムでは、DevOps関連の話題の中でも、特にミートウェアの問題について考えてみたいと思います。続きは後ほど。®

DevOps、継続的デリバリー、アジャイルについてもっと詳しく知りたいですか？5月3日から5日まで開催されるContinuous Lifecycle Conferenceにぜひご参加ください。詳細はこちらをご覧ください。