Michael Coté氏に聞く – DevOpsの導入とDevOpsDays NZの講演
Michael Coté氏はPivotalのテクニカルマーケティングディレクタであると同時に、DevOps界隈では著名なエバンジェリストであり、著作家、コメンテータだ。氏は10月のDevOpsDays NZで、‘This is not a DevOps talk’と題して講演し、自身の体験に基づいたDevOps導入成功への洞察を公開する予定である。
DevOpsDaysは、ソフトウェア開発とITインフラストラクチャ運用、およびそのインタラクションをテーマに、世界規模で開催されるテクニカルカンファレンスで、オートメーションやテスト、セキュリティ、組織文化といった話題を多く取り上げている。ニュージーランドでは2回目となるDevOpsDays NZカンファレンスは、この10月3日と4日にオークランドで開かれる予定である。
InfoQはCoté氏に、今回の講演の内容と、現在の氏の関心事について聞くことにした。
InfoQ: あなたの現在の役割と、DevOpsの世界で最も関心を持っている領域について教えてください。
Michael Coté: 今はPivotalで、主にマーケティングを担当しています。大手企業を回って、ソフトウェアのあり方を改善しようとしている人たちと話をしています。彼らの多くは、自社のビジネスのプログラムにカスタムソフトウェアを導入したいと思っています。つまり、ビジネス革新の重要なツールとしてソフトウェアを使いたいのです。
例えば、請求プロセスをスピードアップしたい – 現在の1週間を1日以内にしたい、という保険会社があります。ドローンを使った不動産被害の評価を考えている会社もあるでしょう。その他にも、例えば梱包製造業の企業が産地直送の宅配市場に参入して食品供給サービスを始めたり、あるいはその方面のビジネスを立ち上げるようなことも考えられます。あらゆるタイプの企業 – さらには政府機関も – について考えることができれば、ソフトウェアで可能なことを改善する手段はいくらでもあります。
DevOpsについて私が関心を持っているのは、この思想分野におけるプロセスとツールが真に新しいものであり、アプリケーション開発プロセスのスピードアップが可能であることが証明されているだけでなく、そのアプリが実用に耐えるものであることが実証済みである点です。例えば、私が言葉を交わした組織の大部分は、ソフトウェアの設計品質を向上するために、1週間か、場合によってはそれ以上のペースでソフトウェアをリリースしています。彼らは自分たちのソフトウェアを細かく分解することで、実際のユーザの目の前でリリースと“テスト”をしたいと考えているのです。ここで言う“テスト”とは、その週に実装した機能に関して、ユーザの問題を適切な方法で解決できているか、もしくは再考や再設計、再コーディングが必要かを確認するためのものです。
このレベルの周期でフィードバックループを運用するには、DevOpsの小道具をフル活用しないことには、とてもやっていけないでしょう。
他にも私は、DevOps(とアジャイル、その他にも気の向くまま)に関して、_The Register_にコラムを毎月書いています。このような分野で、“仮想化”や“組織”、“カラー(color)”といった言葉で表現される問題を抱えているのならば、きっと気に入って頂けると思います。
InfoQ: “This is not a DevOps talk?”という題で行われるDevOpsDays NZでの講演について、少し説明してください。
Coté: そうですね、タイトルでうたっているように、一般的な意味でのDevOpsについてはあまり取り上げていません。私が調査していることの大半は、企業が独自ソフトウェアの開発や運用、活用に失敗したり、その改善に成功したりする理由に関するものです。私たちの知っているDevOpsがそれを可能にしているのでしょうが、それ自体はユーザに直面するソフトウェアよりもスタックが低いものだと思います。DevOpsコミュニティは一般的に、ソフトウェア改善のすべての部分に対処してはいませんが、ソフトウェアを1日に数回とまでは行かなくても、毎週リリースして改善する上で必要な要素であることは間違いありません。
ですから、この講演では、“なぜソフトウェアの改善を考える必要があるのか”を取り上げて、これまで経験してきたベストプラクティスやワーストプラクティスをいくつか紹介するつもりです。講演の内容の多くは、昨年書いた“Creating Your Cloud-Native Strategy”というPDF資料にもまとめています。
InfoQ: あなたにとってDevOpsとは何ですか?
Coté: 現時点では、年次のDevOps Reportsのグラフにもあるように、素晴らしく有用なものだと思っています。それ以外に、私にとっては、“これまでのくだらない行為をやめる”、という意味もあります。
技術的でない意味では、“DevOps”とは、“今あるカスタムソフトウェアの開発と運用のあり方を改善したい”場合に使う現代用語なのだと思います。
InfoQ: 多くの組織が、今でもDevOpsのツーリングやオートメーションの面に執着しているのはなぜだと思いますか?
Coté: ツールは分かりやすく、使い始めるのが簡単だからです。それに、DevOps絶対主義的な人たちは、一般的な組織の愚かさを理解できていないことが多いのです。例えば、大部分の人たちは、あなたが想像するほど自動化を行なっていません – 毎年の調査でも、CIを実践しているのは30~40%程度に過ぎませんし、完全なCI/CDになればもっと少なくなります。ほとんどの組織が、1行のコード変更を運用開始するのに何ヶ月もかけているのです。
これはつまり、DevOps指向ツールの導入だけでも大きなメリットがある、ということになります。
それに、いわゆる“文化”に属するものは、相当な覚悟を決めるか、あるいはハードな試みがなければ、実践に移すのは困難です。長生きしたければ果物や野菜をもっとたくさん食べるように、と医者に言われるようなものです。確かにそうなのですが、ダイエット手法やサーキットトレーニングの類い、あるいは単にアドバイスを聞き入れて摂生するという宣言以上の“ツール”を使って問題解決を試みる方が、それよりもずっと手軽なのです。
InfoQ: 価値に到達する道を革新し、発見し、提供しなければならないすべての人を受け入れる、サイロの壁を越えた共同所有という約束の地は、どの程度まで実現可能なのでしょう?
Coté: 間違いなく達成可能です。全員がそれを実行するために、抵抗する人たちを締め出すか、あるいは解雇するように、上部の指導者がインセンティブを変えさえすればよいのです。これには下位レベルの人たちだけでなく、中間管理層も対象となります。それを実現するのは上級管理層であり、場合によってはCEOや取締役会なのです。
現在のサイロ構造は、それを実現した当時には意味のあるものでした。ひとつのデザインとして実現し、運用するような動機もあったのです。企業のマネージャは今、この管理構造全体を見直して、再び機能するようにしなければなりません。
InfoQ: Pivotalユーザとの仕事を通じて、企業がDevOpsの導入をより効果的に実現できるような、効果的なパターンというものは見つかりましたか?
Coté: それが講演の内容です。ぜひ見に来てください!
私のPDF資料“Crafting Your Cloud-Native Strategy”も参考になると思います。
InfoQ: いまだDevOps導入初期にある企業に対してどのようなアドバイスをしますか、あるいはツールを重視するのでしょうか?
Coté: 小さな規模から始めるべきです – 開発者や運用関係者、ビジネスやユーザに実際に向き合っている人たちで構成された、4~6人のチームを選択してください。そこで数日間を過ごしたら、2,3の初期プロジェクトを選択して取り掛かりましょう。このDevOps担当者をどこに配置するのか、どうやってやるのかといった知識や信頼は、始めてみなければ分からないと思います。
DevOpsDayz NZは10月3日と4日にオークランドで行われて、Michael Coté氏を始めとする国内外の講演者たちが、文化的、技術的な話題を提供してくれる。
この記事を評価
- 編集者評
- 編集長アクション