VMwareのCEOがクラウドについて考えるときのモットーは、「妥協のない自動化」。それはInfrastructure as codeの前提にもなっています。Infrastructure as codeとは、物理的なハードウェア構成や対話的な構成ツールではなく、マシンが読み取れる定義ファイルを通じてデータセンターの管理とプロビジョニングを行うプロセスです。VMworld 2018では、顧客がパネリストとなり、環境の自動化をどのように進めているかについて意見を交わしました。その場で明らかになったのは、困難な取り組みのなかで得られた貴重な教訓でした。
VMware社エンジニアリング部門のバイスプレジデントであるHüseyin Dursun氏が、このパネルディスカッションの準備を行い、司会を務めました。同氏は、誰もが自動化とDevOpsというバズワードを知っているが、この2つはさまざまな意味を持つようになったため、要件ごとに適切に定義し直す必要があると指摘します。
「同じタスクを何度も繰り返しているので、それを自動化できるプログラムを書くと言うのなら、それは素晴らしい目標です」とDursun氏は語ります。理論上は、自動化によって効果を得られます。しかし、開発の負荷は、XKCDのコミックが示すように、実際には滑らかな曲線を描いて減少せず、手作業から解放されて時間的なゆとりが生まれることもありません。反対に、自動化のプロセスでは浮き沈みが続きます。コード化、デバッグ、再考、継続中の開発だけでなく、そもそも自動化しようとしていた手作業のプロセスのせいで時間は足りなくなるばかりです。
Dursun氏は、「素早く行動せよ、失敗を恐れるな」という考え方がもてはやされているが、それは通用しないと語り、企業が社内の壁に掲げるべきモットーは「安定したインフラストラクチャを構築し素早く行動せよ」であると提言します。
「そこで重要になるのがInfrastructure as codeなのです」とDursun氏は続けます。デジタルトランスフォーメーションの実現には非常に時間がかかり、多くの場合、数年にわたる取り組みになります。

カギを握る3要素: 人員、プロセス、テクノロジー

あらゆるデジタルトランスフォーメーションは、人員、プロセス、テクノロジーという3つの要素で成り立っています。
パネリストのChris Wahl氏は、データの管理と保護を手がけるRubrik社のチーフテクノロジストを務めています。Vester Projectの創設者兼オーナーでもあり、このコミュニティプロジェクトでVMware環境の構成管理を提供しています。同氏によれば、これまでに経験したどの現場でも、100人の開発者に対して10人の運用担当者しかいないような状況でした。「ITサービスは長年、ボトルネックとされてきました。当社では、コンピューティング、ストレージなど、データセンターで不可欠なあらゆる要素を提供することを目指しています」。IT部門は、開発部門が業務に必要とするすべての環境を実現しなければなりません。にもかかわらず、この2つの部門は、互いにあまりコミュニケーションをとっていません。
その問題を解消すべく、Wahl氏は、Rubrik社の開発者がIT運用について知ることで、IT部門が開発者のために行っている業務を理解し、運用担当者との連携を深められる取り組みを進めました。さらに、両者からなるチームを結成して、共同の目標を決め、業務を自動化されたタスクに分割できるようにしました。これでITは、開発者がまさに必要としている環境を提供でき、開発者の戦力が格段に高まりました。
「多くの開発者が、データセンターの従来の運用に関心を寄せるようになっているので、運用に対する開発者の視点がわかり、その設計をはるかに効率よく進められます」とWahl氏は語ります。「運用の人的要素は、規則的に必要となるのではなく、例外の発生に従って必要となるだけです」。

サービスとしてのユニファイドコミュニケーション、クラウド、セキュリティ運用を提供するRingCentral社でVPを務めるAshu Varshney氏は、さまざまな課題に直面していました。Varshney氏が入社したときの同社は、まだスターアップ企業で、将来に向けての準備を進めていました。そうした過渡期にまず実施したことは、自社で稼働するレガシーなベアメタルインフラストラクチャの仮想化でしたが、それだけでは十分ではありませんでした。その時点で、仮想マシン作成の自動化も始めました。これが、ポストコンフィギュレーションエンジン (同社ではPuppet) の導入にもつながり、大幅な自動化を実現できました。
「こうしたさまざまな取り組みにもかかわらず、エンジニアが新しいリリースを6週間ごとに提供するという約束を果たせていないと感じていました」とVarshney氏は語ります。「どの開発者もAmazonのような使い勝手を求めていることは明らかでした。彼らが望んでいるのはポータルであって、従来のようなITの展開モデルではなかったのです」。
だからセルフサービスポータルを実現したのだと、Varshney氏は続けます。これにより、開発者は、RingCentral社の、自社製品とサードパーティ製品のカタログに基づいて、環境を短期間で構築できるようになりました。ITの業務は、サービスとしてのインフラストラクチャのフレームワークをサポートすることだけです。
VMware社も自社で自動化のエクスペリエンスを実現するために、多くのタスクを抱えていました。同社のIT部門でシニアディレクターを務めるManoj Warrier氏によると、開発者向けの環境を展開するのに4～6週間を要していたといいます。2015年には、テスト済みの環境を週末にかけて提供できるようになりましたが、それでもさらに時間短縮が求められました。マイクロサービス、Docker、Kubernetesを使用する今日では、簡単な操作で展開を行える必要があると同氏は語ります。
「そのためのパイプラインが必要です。スマートIT実現のためには、ビジネスを積極的に受け入れなければなりません」。

自動化の文化

課題となるのは個々の技術だけではなく、文化も大きな役割を果たします。
「効率化に関してですが、とりわけアプリケーション開発においては、各自に効率化を任せても、結局は誰の効率化にもつながりません」とWahl氏は語ります。Rubrik社は開発と運用部門が共同で働くチームを作り、効率化に責任を持たせました。「その目的は、効率化を強く奨励するということを、エグゼクティブレベルから社員に明確に伝えることでした」。「300、500、1,000人の開発者がいたとします。いえ、100人でも構いません。そのチームで効率を10%高められれば、その効率化で生まれた時間を使って、10人から100人の開発者がそれぞれ別の活動を行えます」。
IT運用は従来、情報を吸い上げる場所であり、共同開発する人たちが普段いる場所ではありませんでした。しかしRubrik社では、運用チームのメンバーを開発者の近くに配置し、お互いが近い席で作業できるようにしました。これで、誰もが新しいコードや新しい機能を認識でき、同じ目標に向かって責任を持って働けるようになりました。
変化に対する大きな抵抗は、文化的な問題に起因するものだとVarshney氏は指摘します。また、新しいフレームワークを確立しようとしている一方で、現在の環境に関係のある新たな課題が存在しているとも言います。「今日の問題を解決しつつ、将来のソリューションを構築する必要がありました。そうは言っても、今日に見合うインフラストラクチャを用意できなければ、将来に意味を見いだせません」。
そうした難題を克服するために、Varshney氏は、企業が、最低限可能な製品で市場に参入して機能を追加するのと同じように、vCenter APIとの統合による、サービスとしてのインフラストラクチャの構築を開始するとともに、各イテレーションでその改善を続けました。起動力は内部、つまり問題に日々取り組んでいる人々から生まれなければならないと、同氏は語ります。
トランスフォーメーション全体にまずリーダーシップが必要であり、責任のなすり合いがあってはならないと、Warrier氏は語ります。「マインドセット全体を変える必要がありました。開発と運用がチームとして協力し、共通の目標を達成しなければなりません。そうすれば、ボタンをクリックしたり、仮想マシンをプロビジョニングしたりすることが、ビジネス成果に直接つながるようになります」。
もちろん、自動化ではツールが大きな役割を果たしますが、Dursun氏は、自身が「ツールマニア」と呼ぶ状態には注意すべきだと語ります。その状態になると、興奮、高揚感、妄想のほか、デバイスや実装において特定の機能を実現しようと熱中し過ぎるといった傾向が現れます。
Dursun氏は、こうした問題にどう対処するかをパネリストに尋ねました。
「各チームが、問題を最も効果的に解消できるツールを選択するのは当然です」とVarshney氏は語ります。「標準化しても意味がありません」。その代わりに同氏は、アラート、通知といった、さまざまなツールのアウトプットに注目します。それらをチームのメッセージングプラットフォームに統合するのです。
Warrier氏も同じく、集約につながるアウトプットと、それらの相互関係に着目します。同氏にとっての大きな問題は、構築か購入かという点にありました。
Wahl氏は、会場にいる人たちに、ITの問題を解決するために導入したはずのツールによってさらに問題が増えると述べて、昔のジョークを思い出させました。同氏は、どのツールがよいかをチームに尋ね、そのツールがもたらすリスク、つまり運用に及ぼす悪影響の可能性を特定するというアプローチをとります。さらに、こうした悪影響に確実に対処できるようにするため、当番を決めて、開発者がそのツールにすぐに対応できるようにします。

リーダーシップの重要性

最後の構成要素は人材です。「Infrastructure as codeを実現するには優れた人材が必要です」とDursun氏は語ります。「しかし、ITの配管設備とも言えるインフラストラクチャは、スタックのほかの部分に比べると魅力に欠けます。優れた人材を引き付けるにはどうすればいいのでしょうか」。
Warrier氏は、VMware社には、運用のあらゆる面を新入社員に紹介するプログラムがあると語ります。また、既存のスタッフは、開発者が運用部門に移って数か月間働く、またはその逆というように、交代でほかの部門を担当します。同氏が採用する際には、担当が開発なのか運用なのかを告げません。コードを書くエンジニアとしての役割を割り当てるだけです。
「社員は飽きてしまうことを理由に仕事を変える傾向があります」とWahl氏は指摘します。「Infrastructure as codeの興味深い利点は、あらゆる領域を担当すれば退屈しないことです」。Rubrik社では、部門を越えたチームを作るように社員に勧めています。そうすることでお互いが学び、その知識をチームに持ち帰ることができます。情熱を注げそうな新しい何かをそのプロセスで発見できるというメリットもあります。
Varshney氏の課題は、社員が製品とカスタマー・エクスペリエンスに深く関わるようにすることです。社員をつなぎ止めることができるのは主に管理者であると同氏は言います。興味を失うとともに、会社に貢献できていないと感じる社員が会社から離れていくと考えるWahl氏と同意見です。
その他に、Infrastructure as codeに必要なものは何でしょうか。Dursun氏がパネリストに尋ねます。
「Infrastructure as codeのトランスフォーメーションを進めるときに必要なのは、トップダウンでトランスフォーメーションを指揮する人たちです。それが重要になります」とWarrier氏は語ります。「私は、そのようなリーダーからこうアドバイスされました。仕事の無駄を省くべきだ。サービスオーナーになり、顧客にセルフサービスを提供できるようにする。そう考えて着手すれば、すぐに、Infrastructure as codeを提供する企業を実現できる」。
今度はVarshney氏がこう述べます。「成果を得られるという観点でInfrastructure as codeを考えると、自動化において、とりわけこうした極端な自動化においては、アジリティの優先度は2番目になります。最も重要なのは正確さです。Infrastructure as codeを実現することで、エンドカスタマーに比類のない正確さを提供できます」。
Wahl氏にとって、特に大きなメリットは透明性です。「これまでのITの構築方法と比べてみましょう。データベースサーバーの構築を私に依頼すれば、確かに私が構築したサーバーをあなたは入手できます。Infrastructure as codeを導入すると、すべてが成果物になるのです」と同氏は語ります。「そうしたデータベースサーバーを誰がどのように構築しているのかを完全に把握できるうえ、毎回、同じエクスペリエンスを得られます。さらに一貫性が、徹底したリスク解消につながります」。
トランスフォーメーションをこれから始める方のために、気軽に読める、Dursun氏お勧めの本をご紹介します。『The DevOps逆転だ!』（Gene Kim、Kevin Behr、George Spafford著）、『LeanとDevOpsの科学 [Accelerate] テクノロジーの戦略的活用が組織変革を加速する』（Nicole Forsgren、Jez Humble、Gene Kim著）、それにO'Reilly社から出版されている3冊、『SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム』と『The Site Reliability Workbook』（いずれもBetsy Beyerとその他の編者による）、『Infrastructure as Code ―クラウドにおけるサーバー管理の原則とプラクティス』（Kief Morris著）です。

Infrastructure as code: リーダーへの教訓

• Infrastructure as codeを効果的に管理するには、開発と運用部門が、パートナーシップを結ぶかのように協力し合い、お互いの分野を理解する必要があります。
• リーダーシップを重視します。責任のなすり合いをやめ、仕事の無駄を省くようにします。
• Infrastructure as codeの実現には優れた人材が必要です。そうした人材を育てましょう。
  

この記事/コンテンツは、記載されている個人の著者が執筆したものであり、必ずしもヒューレット・パッカード エンタープライズの見解を反映しているわけではありません。