組織の団結。開発チームは、新たな機能を市場に出し、これまでよりも早く変化を起こすことを目指して活動している。一方運用チームは、信頼性と安定性で評価されるものであり、基本的には変化しないことをよしとする。
これら2つの正反対の目標を1つにまとめてしまい、これらの組織を一緒に扱えば、必ずトラブルが起こる。このように、DevOpsには、組織、文化、文化的規範、ガバナンス、ポリシーなどの要素が絡んでおり、それらをいかに機能させるかが重要となる。
組織構造は、リーダーがもっとも重視すべきものの1つだ。高いパフォーマンスを得るには、小規模なグループが自律的に、自由に、そして安全に本番環境に新たな機能を導入できなくてはならず、そのたびに何百人、何千人ものほかの開発者と調整を行う必要がないような組織構造が必要となる。
DevOpsとITIL
ITILはITで世界レベルの可用性を提供するために必要なすべてのプロセスを成文化したものであり、英国商務省によって書かれたものだ。ITILは構成管理、チェンジマネジメント、リース管理、ベンダー管理などのプロセスをどう扱うべきかを定義している。
筆者の考えでは、ITILは1週間につき数百から数千の変更を行っている限りはうまくいく。しかしDevOpsでは、1日に数十万の変更を行う状況を想定しており、手動で構成管理をするやり方を維持することはできない。手動でリリースしたり、多数の変更を承認する委員会を維持することは不可能だ。
DevOpsではこの管理プロセスを自動化して予測可能にすることによりオンデマンドでできるようにし、さらに開発者によってもできるようにしているが、これはITILや監査役から見れば、異質なやり方だ。
DevOpsがビジネスに与える影響
もはや組織は、コストを下げるためにテクノロジを最適化するのではなく、スピードのためにどうテクノロジを最適化するかを考えるべき時期に来ている。
「ITの運用コストを3％削減するにはどうすればいいか」というような考え方から抜け出し、たとえばオムニチャネルを実現するには何が必要か、といったまったく異なる考え方をする必要がある。
コスト効率だけで競争に勝てることはまれだ。多くの場合、勝つためにはイノベーションと製品を市場に出す時間の短縮が必要になる。DevOpsは顧客に機能を素早く提供することを可能にする。
また、顧客の目標達成に何が役立つかを理解するために、機能を試すことができる。最近では、市場で勝ち残るためには、徹底的にさまざまなことを試してみるしかないという考え方が主流になってきている。
コストが問題になる場合もあるだろうが、製品をより早く市場に出し、競争に参加し、競争に勝つためであれば、顧客はそれに対価を払うはずだという考え方だ。
ITは組織の生き残りには非常に重要で、それなしでは生き残れない場合も多い。「これは投資に見合うほど重要なことか」という問いはもう古くなっている。問題になるのは、「この投資をすることで、実際にこの目標を達成できるか」ということだ。
従来型のウォーターフォールモデルによる大規模な開発プロジェクトでは、プロジェクトが終わるまで結果が出ない。このやり方では、開発と運用の作業を日常的に統合することもせず、テストにも投資しない。このやり方で、本当に投資が望ましい成果を生むと確信できるだろうか。これこそ、考え方を変えようとする時に、最初に話し合うべきことだ。
この記事は海外CBS Interactive発の記事を朝日インタラクティブが日本向けに編集したものです。
