開発者はソフトウェアを開発し、運用者はそれをテストし運用するというように、数十年に渡って企業内では開発チームと運用チームが別々に分かれていました。しかし、2009年にITコンサルタントのPatrick Deboi（パトリック・デボワ）は、開発と運用を統合し、コミュニケーションを改善し、ベストプラクティスを確立して、業務プロセス全体を改善し続けることを目指したフィードバックループを作り出す「DevOps」という言葉を生み出しました。
前回に続き、米Veeam Softwareで最高技術責任者（CTO）兼製品戦略部門シニアバイスプレジデントを務めるDanny Allanの視座を借りながら、DevOpsの成長を妨げる原因とその解決のための組織の在り方について紹介します。
仮想化技術の1つであるコンテナーは、既にあるリソースを再パッケージ化する新手法として見なされると同時に、DevOpsもソフトウェアチームの集中力を高め、活力を取り戻すことを約束するものだと見なされていました。
しかし、採用が加速しているのはコンテナーであり、コンテナーの利用をオーケストレーションする技術であるKubernetesは、常に革命的であると言われ続けています。一方で、DevOpsは、2021年に開発者とDevOpsチームを対象にGardenが発表した調査では、開発セットアップとワークフローに十分満足しており、可能な限りうまく運用できていると考えている回答者が全体のわずか11％に過ぎませんでした。また、DevOpsの世界的な専門家集団であるDevOps Instituteのレポートでは、50％以上の組織がDevOps変革への道のりが非常に困難と感じていることが分かりました。
この原因は何なのでしょうか。DevOpsは机上では良いアイデアですが、実際には効果がないのでしょうか。それとも、タスクを自動化するプロセスによって、チームが創造的なイノベーションに使えるはずの時間が犠牲になっているのでしょうか。
Allanによると、DevOpsの成長を妨げる理由の1つは、DevOpsへの過度な期待にあります。私たちが過大評価をしてしまうのは、その目的や能力を十分に理解していない時です。DevOpsを導入している組織は何千とありますが、その役割を全く同じように定義しているところはありません。DevOpsを否定する前に、チームは自分たちの組織にとってのDevOpsの価値を明確に定義し、過度な期待をリセットし、現実的なプランを策定する必要があります。そして、DevOpsがもたらすものを定義する際に、心にとどめておくべき3つのポイントがあります。
