リリース／デプロイをめぐる刺激的な議論：IBM UrbanCodeの責任者が語るDevOpsの姿

DevOpsは騒がれすぎなのか。「スクリプトを使えばいい」「スーパープログラマには自分のやりかたがある」「運用担当者の仕事がなくなるようなことはしたくない」「うちは頻繁にリリースをしないから考えなくていい」。本当にそうなのか。豊富な経験を持つUrbanCode共同創設者のマチェイ・ザワツキー氏がこれらの問いに答える。

[PR／＠IT]

　ソフトウェアの開発と提供を行うほとんどの企業・組織が、ソフトウェアのデプロイ／リリースで何らかの課題を抱えている。それでも、「スクリプトを使えばいい」「スーパープログラマには自分のやりかたがある」「運用担当者の仕事がなくなるようなことはしたくない」「うちは頻繁にリリースをしないから考えなくていい」といった声が聞こえてくる。本当にそうなのか。UrbanCodeの共同創設者でCEOであり、2013年IBMに買収されたことで、現在はIBMのデプロイ／リリース製品ライン・ディレクターを務めているマチェイ・ザワツキー（Maciej Zawadzki）氏に、これらの疑問を直接ぶつけてみた。

UrbanCode共同創設者で、現在IBMのデプロイ／リリース製品ライン責任者を務めるマチェイ・ザワツキー氏

　ザワツキー氏の経験は豊富だ。UrbanCodeの活動を通じ、1996年以来、顧客組織におけるソフトウェアのビルドにかかわる問題を解決し、その後さらにリリース／デプロイの改善に取り組んできた。UrbanCodeがリリース／デプロイの課題に取り組み始めたのは2005年。それまでアジャイル開発の波に乗ってビルド製品で成功してきたが、顧客に「あなたはビルドの問題を解決してくれたが、おかげでデプロイの問題が生まれてしまった」と指摘されたことがきっかけだったという。

　開発／ビルドと、テスト／デプロイのペースが双方とも遅かったころは問題がなかった。しかし開発／ビルドのペースが飛躍的に高まると、とたんにテスト／デプロイがボトルネックとして認識されてくる。この問題を解決するには1つの壁でなく、さまざまな壁を崩す必要があると、ザワツキー氏たちは気がついた。このため、後工程におけるあらゆるプロセスの課題に対処する製品として形にしたのが、現在の「IBM UrbanCode Deploy」「IBM UrbanCode Release」だという。

「スクリプトを使いこなしている」だけではなぜ足りないか

　継続的インテグレーションにはJenkins、デプロイにはPuppetやChefを使えば、後工程の自動化はできる。それだけで十分ではないのか。まずこれを聞いてみた。

　「スクリプトでも自動化はできる。重要なのはできるかどうかではなく、それがどれくらい役に立っているかということだ」（ザワツキー氏）。スクリプトでできる自動化は、問題の一部しか解決しないという。

　例えば開発者と運用担当者が別で、運用担当者はデプロイ・プロセスをスクリプト化しているとする。デプロイの作業自体は自動化されたとしても、開発者が電子メールなどで申請し、だれかがチケットをオープンしてからの作業になってしまう。自動化されたデプロイ・プロセスを開発者がセルフサービスとして利用できないかぎり、本当の自動化とはいえない、とザワツキー氏はいう。

　もう1つの重要なポイントは可視化だ。開発者がデプロイのボタンを押すことで自動的に作業が実行されるだけでなく、実行結果が分かりやすく示されなければならない。「○×サーバへのデプロイが失敗した」とすぐ分かり、どこが問題だったのかも明確に示されれば、開発者は即座に対応できる。

「俺はスーパープログラマ、余計な助けは要らない」の危険性

　「スーパープログラマには自分のやりかたがある」という声について、ザワツキー氏は、「スーパープログラマなら、もちろんデプロイなど簡単だし、楽しく感じることもあるかもしれない。問題は、それがあなたの貴重な時間の使い道としてふさわしいかということにある」とコメントする。

　「スーパープログラマのあなたは、いつか次のプロジェクトに取り掛からなければならない。その時、残されたものをだれがどう引き継ぐのか。次の担当者はおそらくスーパープログラマではない。プログラマですらないかもしれない。あなたのやり方をどう真似ろというのか」。

　また、アプリケーション運用の過程で、環境が変わることは往々にしてある。ではだれがスクリプトのメンテナンスをやるのか。その頃あなたは、別の面白いプロジェクトに掛かりきりになっていて、過去のプロジェクトのデプロイ・スクリプトのメンテナンスなど、決してやりたいとは思わないだろう。

「運用担当者の仕事がなくなる」という思い過ごし

　「高機能なデプロイ／リリース自動化ツールを導入すると、運用担当者の仕事がなくなる」という意見について、ザワツキー氏は「同じことの繰り返しは、人間よりコンピュータのほうが何倍も生産性が高い。あなたは同じことを繰り返すだけの仕事をしたいのか？」と問い返す。

　良いツールを導入すれば、運用担当者はデプロイ・プロセスの設計という仕事に移行できる。デプロイ作業自体はコンピュータにまかせることで、適切なプロセスは何か、どのように運用を管理していくのが正しいかを考えるといった、より重要な問題の解決に時間を割けるようになる。

「うちは頻繁にリリースするわけではない」は本当？

　ザワツキー氏は、事情が許すかぎり、大規模なリリースやアップデートを長い間隔で行うよりも、小規模なリリースやアップデートを頻繁に実施したほうが、リスクが低いと力説する。「多くの人は直感的に、アップデートの頻度を減らすほうが安全なのではないかと考える。しかし、真実はその逆だ」。また、リリースは誰にとっても怖い作業だが、経験を積むことで慣れなければ上達はできない、と同氏はいう。

　では、業界や顧客対象の関係で、頻繁にリリースを実施することはできないようなケースはどうなのか。ザワツキー氏は2つの点を指摘する。

　第一に、「継続的デリバリというのは、例えば1日10回コードを出さなければならないということではない。あなたの組織に、いざとなればそこまでリリースの頻度を高められるという能力があるということが大事だ。それはテクノロジ的な判断というより、ビジネス上の判断だからだ」。

　第二に、本番へのデプロイは年に4回くらいしかなかったとしても、テストデプロイは何度も繰り返さなければならない。「ソフトの品質をどう判断するかという問題に行き着くが、多くの組織では、考えられるテストはやりつくしたと言えるまで、ますます多くのテストをやるようになってきた。本番でもテストを実施している組織があるくらいだ」。

　すなわち、テスト段階でのフィードバックループを高速に回せるかどうかが、開発スピードに大きな影響を与えることになる。

IBM UrbanCode Deploy/Releaseは単なる自動化ツールではない

　IBM UrbanCode Deploy/Releaseを一言で表現しようとすると、「リリース／デプロイ自動化ツール」になってしまう。しかしこの製品の機能は自動化だけではない。アプリケーションサーバサーバ、データベースから負荷分散製品まで、多数の製品との統合が組み込まれており、さらにインベントリ管理、構成管理の機能も組み込まれている。開発者と運用担当者が1つのツールで、どのコードのどのバージョンが統合テスト／ステージング／デプロイのどの段階にいるのかといった情報を共有できる。また、どこでどういう構成で動いているのかも容易に確認できる。適切にテストを終えていないかぎり、勝手にデプロイができないといったコンプライアンスに寄与する機能も組み込まれている。

　リリース／デプロイにかかわる課題の本質的な解決には、単純な自動化だけでなく、上記のような機能がすべて必要だとザワツキー氏は強調する。「だからといって、われわれが顧客にはできないことをやっているとは思わない。この製品を採用してくれている組織は皆、社内に大規模な開発チームを持っている。同じようなツールをつくることもできるだろう。だが、われわれの製品は高付加価値な機能を、うまく実現できていると思う。これと同じことをやるために、社内の工数を費やしたいかどうかということだ」

　実際に、UrbanCodeを採用した企業は、それまで自社でツールのメンテナンスを行ってきたところが多いという。

　「こうした企業は、何年か自社でのツール運用を続けているうちに、社内ツールのメンテナンスだけのために専任チームを抱えているのでは、コストの節約につながらないということに気づく。ソフトウェアが商売ではないのだから、優秀なプログラマは自社の事業上の問題を解決するために働いてほしい、と考え始める」。

　例えばアプリケーションサーバがバージョンアップすると、スクリプトに変更を加えなければならなくなったりもする。このような変更への対応をいちいち自社でやっている意味はどこにあるのか。そういう疑問を感じた多くの企業が、製品を購入すれば解決できるということで、IBM UrbanCode Release/Deployを採用してきたのだという。