開発者がアジャイルなだけでは十分な価値が生まれない、IBMのいう「DevOps」とは：IBM Rationalゼネラルマネージャ、クロックナー氏に聞く

IBMはなぜ「DevOps」という言葉に独自の意味を与えているのか。米IBMが6月に開催した「IBM Innovate 2013」で、IBMソフトウェアグループのIBM Rationalゼネラルマネージャであるクリストフ・クロックナー氏に直接たずねた内容をお伝えしたい。

[三木 泉，＠IT]

　日本IBMは7月11日に、米IBMが4月に買収したUrbanCodeのリリース自動化製品の国内発売を発表すると同時に、IBMのいう「DevOps」とは事業部門、開発部門、運用部門のすべてをカバーするものだと説明した。IBMはなぜ「DevOps」という言葉をこうした意味で使っているのか。米IBMが6月に開催した「IBM Innovate 2013」で、IBMソフトウェアグループのIBM Rationalゼネラルマネージャであるクリストフ・クロックナー（Kristof Kloeckner）氏に直接たずねた内容をお伝えしたい（こちらのInnovate 2013レポートもご覧ください）。

　IBMはDevOpsを、開発と運用の密接な結合にとどまらず、事業部門も含むプロセス全体の改善であり、さらにこれは企業としての取り組みだと定義している。IBMはDevOpsをなぜ、こうした広い意味で使っているのか。これをたずねたところ、クロックナー氏は、「人々がこれまでやってきたことを考え直すべきだというメッセージを伝えたいからだ。だからアジャイルの拡張などの呼び方はしない」と答えた。

　「IBMはこれまで、『統制のとれたアジャイルなデリバリ』という言葉を推進してきた。だが、アジャイルという言葉は開発プロセスに注目しすぎだ。そこでIBMでは、コンティニュアスデリバリを実現するために企業が整備すべきエンタープライズケイパビリティ、つまり、組織、プロセス、ツールを表現する言葉として、DevOpsを選んだ。コンティニュアスデリバリは、デリバリの加速を最もラディカルな形で実現するものだ。リーンやアジャイルは、開発者の部分で始まり、終わるものではない。フロント部分ではビジネスが関わり、バックエンドではオペレーションが関わる。一方、DevOpsの中核は常にアジャイルだ」。

　つまり、開発者がアジャイルだというだけでは不十分であり、ソフトウェアの提供と、それによる目的の達成に向けたプロセスに関与するすべての人々が緊密に連携しなければ、今後多くの企業に求められるようになるスピード（迅速で頻繁なソフトウェアリリース）と品質の両立に対応できないということを表現するために、DevOpsという言葉を使っているのだという。また、IT製品・サービスを提供する企業だけでなく、金融から製造業に至るまで、あらゆる産業で「IT化」が進展するため、このことがさらに重要になるという。

―― だが、IBMの顧客に多い大規模な組織にとっては、考え方を根本的に変えなければならないという点で、大きなチャレンジなのではないか。

IBMソフトウェアグループ IBM Rationalゼネラルマネージャ、クリストフ・クロックナー氏

　確かに大きなチャレンジだ。部署の壁を乗り越え、数多くのステークホルダーにまたがる形で事業目標を追求すべきだという考え方は、多くの企業における従来の文化と対立する。だが、非常に多くの組織で、（従来のやり方に起因する）問題が起こっている。そうでなければ、DevOpsといった言葉は要らなかった。

　ある企業では、モバイルアプリケーションをこれまでよりはるかに迅速に展開しなければならなくなっている。このアプリケーションはメインフレームに接続しなければならない。つまり、メインフレームへの変更はこれまではるかに遅いスピードで行われてきたが、こうした従来のプロセスは通用しない。モバイルとメインフレームのチームを共通のプラットフォーム、共通の情報で一緒にし、自動化を進めないと失敗する。

　最近、米国の主要銀行の1社と会ったが、まさにこのことを話してくれた。この企業は3つの問題を抱えている。エンド・ツー・エンドでの変更管理、テスト、リリース管理だ。同様な状況を他の顧客にも見ることができる。ある企業は、テストについてはうまくやれているがリリース管理はうまくないとか、リリース管理では前進しているが統合テストはうまくやれていないなどだ。

―― あなたは統制について話すが、統制はスピードを低下させるのではないか？

　統制を硬直性や過剰な儀式と混同してはならない。アジャイルと統制を両立させるには、これを実現するプラットフォームが必要だ。事業部、開発担当、運用担当が同じ情報を共有し、ハンドオフを自動化しなければならない。ハンドオフが迅速だが周到さに欠けるとか、あるいは周到だが遅いというのではどちらも不十分だ。メインフレームでは銀行のシステムが10年変わらないといったことが普通だったが、今ではこれは許されないし、逆に美しいWebサイトがあっても、メインフレームとの接続に問題があるのではだめだ。すべての社内のステークホルダーの間での共通理解がないと、最終的な成功につながらない。

　開発者は、自分がアジャイルに仕事をしているからといって他人のせいにはできない。ほかの人がインストールして運用してくれなければ、あなたのコードには価値が生まれないからだ。ただし、現在のようにプレッシャーが上や外部から来なければ、開発者と運用担当者は今でも責任を押し付け合い、喧嘩していただろう。IBM自身もこれを認識している。ソフトウェアのリリースは年1回から四半期に1回になり、クラウドについてはさらに速いサイクルで回さなければならなくなっている。