DevOps は、長い問題解決プロセスの最終段階です。DevOps 実現までの各段階では、さまざまなデジタル ツールを導入することになります。たとえば、CI/CD システム、テスト フレームワーク、モニタリング ツール、セキュリティ監査ツールなどです。これらのツールのうち、必要なものはどれでしょうか。どのツールを使えば、組織が直面している課題や、苦労や、停滞を解消できるのでしょうか。 私はさまざまな規模のチームを支援してきましたが、そのときにいつも耳にした疑問はこの 2 つでした。 「どのような組織構造にする必要があるのだろうか？」と「どのツールを導入すればよいのだろうか？」です。

どちらも悪い疑問ではありませんが、個別に答えを求めてしまうと大事なポイントを見失ってしまいます。これらの疑問への答えを一足飛びに得ようとすると、組織内で解決しようとしている問題を吟味することなく解決策を検討することになるからです。

よくある考えは、”これを使え、あれをしろ” というトップダウン モデルを採用すれば、チームのイノベーション速度が上がるというものです。一方、熱意のあるチーム リーダーの施策は異なります。新しい CI/CD ツールを導入して、メンバー全員がこのツールを利用できるようにするのです。個々のメンバー、採用された手法を守るのに適切なツールを用意することは重要です。しかし、ツールの価値や意義を十分に理解することなくツールを導入してしまうと、問題が発生します。変更を命じた人物でさえも、どうしてそれを導入したのか、どのような成果を求めていたのかを忘れてしまうことはよくあります。悲しいことに、当初の理由があいまいになるとツールはたやすく誤用され、価値が生み出されないか、マイナスの効果が生じることさえあります。

DevOps が欲しい！

DevOps をすばやく導入できさえすれば抱えている問題はすべて解決する、と確信している組織に数えきれないほど遭遇しました。

自分をこの立場に置いて、自問してみてください。「どうして組織に DevOps が必要なのだろうか？DevOps がどのような価値をもたらすと考えているのか？」と。

ここで、DevOps の正体と、誤った認識について簡単に説明しましょう。

DevOps とは、開発チームと運用チームの連携関係に特化した手法です。基本的には、文化的な観点から、インフラストラクチャに開発手法を適用し、開発サイクルに運用手法を適用します。具体的な内容を説明すると、インフラストラクチャをコードとして管理することや、再利用可能なコンポーネントを構築してイミュータブルなインフラストラクチャを作成すること (いつでも分解・破棄でき、バージョン管理や変更履歴の記録も容易です) が挙げられます。また、すべてのプロダクト コントリビューターたちが、「製品は世の中でどう役に立っているのか？」、「ユーザーはどのように操作しているのか？」など、自身が進めている作業の最終的な結果にもっと関心を持つようになります。本気で品質を意識すれば、ビジネス価値とユーザビリティの両方を意識することになります。製品開発に携わる全員が、この品質の両側面を意識し、製品がデプロイされエンドユーザーに届いたときどうなるかに関心を寄せるようになる状態。これこそ、DevOps 導入による真の成果です。

個人的な経験で言うと、こうした手法を採用するには、広範囲から支持を取り付けなくてはならず、さまざまなスキルや専門知識を持つ人々の助けが必要になるため、ソフトウェア開発チームにとっては特に難しいでしょう。それでも実現するには、部門を超えた 1 つのチームをつくり、配慮あるコミュニケーション スキルを身につける必要があります。たとえば、エンジニアがデータベースの問題についてビジネス サイドのだれかと話すときには、単に作業に関連するデータを提示するだけでなく、必要な背景情報も伝え、問題意識を持つべきポイントやその理由について強調することが大切です。

では以上を踏まえて、新しいツールを導入する必要があるか考えてみてください。必要だと言い切れない方もいらっしゃるのではないでしょうか。ツールは、手っ取り早い手段のように思えることもありますが、どんな状況にも使える万能の武器というわけではありません。私の経験からすると、新しい DevOps ツールを導入する前に、こうしたポイントを踏まえておくと、成功の確率が高まるでしょう。

変革を始める前に留意すべきこと

1. 全員の認識を統一する: DevOps 変革の目的について意識の統一を図ります。チームの全員から、解決しようとしている課題について同意を得て、足並みを揃えて課題解決に取り組むことを承諾してもらいます。

2. 必ず小さなところからスタートする: 一夜にして理想的な DevOps モデル チームを作り上げることはできません。まずは 1 つのチームから始めて、プロセス改革が組織内で有効かどうかを確認しましょう。改善が見られたら、少しずつ進めていきます。

3. 自分たちに適しているかどうか見極める: 組織によっては DevOps が適していない可能性があることも理解しておきましょう。実際、DevOps を導入しなくても長年成功を収めている企業も存在し、そうした企業にとっては社内文化や製品に対するニーズなどの面から DevOps が最適なソリューションとは言えないのです。個人的にも、著しく成功している組織の中に、ウォーターフォールが非常にうまく機能している例があることを知っています。たとえば、製品戦略において機密性が特に重要になる企業では、段階的に配信を行ってフィードバックを集めるのは現実的ではありません。大規模なリリースを行うまで、製品についてのすべての詳細を秘匿しておく必要があるからです。そのような環境で DevOps の文化を築くことは非常に難しいでしょう。

4. 常に測定する: 改善計画を実行に移す前に、現状を正確に測定しておきます (開発サイクルに○時間かかっている、など)。サイト信頼性の担当エンジニアを開発チームに招集するよりも、まず指標を測定しましょう。少し時間がたてば、取り組みの効果を確認できます。変化の前後と一定間隔で測定を行い、改善しているかどうかを確認するようにしましょう。一例を挙げると、アジャイル手法による変革が盛んに行われていたころ、多くの企業がスタンドアップ ミーティングを採用しましたが、その必要性をよく理解していないケースや、実施効果を測定していないケースが目立ちました。これでは、スタンドアップ ミーティングによって時間が節約されたどころか、無駄になっていたかもしれません。

5. なんでも自動化しようとしない: 少なくとも一度にすべてを自動化するのはやめておきましょう。DevOps に関して、インフラストラクチャのプロビジョニングと構成管理をすべて自動化しなければならないとお考えの方もいらっしゃるようですが、これは誤解です。こうしたインフラストラクチャは “コードとしてのインフラストラクチャ” と呼ばれます。中には手動のほうがうまくいくこともあり、自動化がすべての最適解となるわけではありません。また、自動化スクリプトの実行予定回数と自動化にかかる時間についても検討しましょう。そのスクリプトの使用回数が何千回にも及ぶのか、たったの 3 回なのかで、判断は変わります。さらに、場合によっては、手動の方法から始めて、実際に何が最良の自動化ソリューションとなるのかを見極めなければならないこともあります。それでも自動化を望まれる方には、アプリケーションの Docker 化が最適です。Docker 化するアプリケーションは、再利用する可能性が高いからです。本番前環境の作成を自動化するのも、自動化を実装するのに適した例ですね。では、ファイアウォール設定の自動化はどうでしょうか。現在のファイアウォール ソフトウェアの多くで API サポートが十分ではないことを考えると、自動化する価値はないかもしれません。障害に備えるのは良いことですが、障害をなくすことよりも対策を立てることに価値を置きすぎているのではないでしょうか。

次の一手

組織で DevOps への移行を検討している場合、まずは製品のデリバリー速度と品質の現状を考えてみてください。現在の課題は何でしょうか。こうした質問に対する回答を知ることで、組織内の全員が課題を理解できるようになり、最良の態勢で改善を始められます。

今後も、組織の課題分野の特定に役立ち、それらの課題解決で最も効果を発揮するツールやプロセスを自信を持って評価できるようになるエクササイズをご紹介する予定です。