DevOpsのテキスト研修
DevOpsとは
DevOpsは、ソフトウェアを開発し、届け、運用するためのプロセスです。言葉にすれば簡単ですが、DevOpsの本質を理解することを軽く見てはいけません。書店の棚にもインターネットにも多くの定義があふれていますが、提供者の都合を優先していたり、そうでなくても説明が不十分で混乱を招いたりします。
商業的な目的のある定義の中には、DevOpsを特定のビルド・デリバリーツールやクラウド基盤と強く結びつけるものがあります。こうしたツールや基盤はDevOpsを通じてIT部門や組織の目標を達成するのに大いに役立ちます。しかし、自分たちで書いたものではないため十分な制御ができないことも多いツールをもう一つ導入したり、アプリケーションをクラウドに移行したりしただけで、組織がDevOpsでデリバリーを行っているとは言えません。古くあまり知られていないことわざに倣えば、カラスにも笑われます。
誤解を招くものの、もう少し実態に近い定義では、DevOpsを、ソフトウェア開発者、テスト担当者、本番運用エンジニアを結びつける、IT組織の仕事と人の交点と捉えます。ただし、本書の最後まで読むころには、この定義だけではどれほど味気ないかがわかるはずです。
DevOpsを定義するには、Scrum、Lean、ITIL、IDEAL（開始、定義、確立、実行、学習）、シックスシグマのDMAIC（定義、測定、分析、改善、管理）など、反復型のアジャイルソフトウェア開発やプロセス改善の枠組みに照らして考えるのが最もよい方法です。
アジャイルなScrum、Lean、ITIL、IDEAL、シックスシグマのDMAICはDevOpsを効果的に支えますが、DevOpsを、こうした手法や技法を改良、統合した上位の枠組みと捉えるものではありません。理由は単純です。アジャイルなScrumを除き、いずれもソフトウェア業界固有の課題を解決するために作られたものではありません。
DevOpsの多くの実践と原則は、リーンの考え方をソフトウェアの開発、デリバリー、運用に合わせ、試行、検証、調整を重ねて取り入れたものです。さらに、継続的デリバリー、トヨタの改善の型、制約理論、アジャイルソフトウェア開発宣言、アジャイルなインフラからも、さまざまな技法や考え方を取り入れ、応用しています。
リーンの取り組み
リーンの考え方は七つの原則にまとめられます。
- 全体を見渡し、システム思考で顧客価値を生み出します。
- 品質を工程に作り込み、作業の流れを作り、プッシュ方式ではなくプル方式を採用します。
- 可能な限り速く届けます。原材料を完成品にするまでのリードタイムを短くし、ソフトウェアであれば、アイデアを本番環境で稼働する有用な機能に変える時間を短くします。
- 学びを広げ、科学的な考え方を取り入れます。
- チームに権限を与え、謙虚に導き、一人ひとりを尊重します。
- ツール、システム、そして何より非生産的な活動に費やす時間のムダをなくします。
- 決断はできるだけ後まで待ち、必要になった時点で下します。
継続的デリバリーの取り組み
デプロイメントパイプラインを通じて、継続的デリバリーを実現します。パイプラインには、可視化、フィードバック、継続的デプロイという三つの重要な役割があります。
- 可視化 ビルド、デプロイ、テスト、リリースなど、デリバリーの仕組み全体を自分のチームや他チームの全員に見えるようにします。チーム内の協力が進み、顧客とステークホルダーにも状況が見えるようになります。
- フィードバック 問題が起きたらすぐにチームで把握し、すでに崩れたブロックの上にさらにレンガを積む前に、すばやく問題を修正します。
- 継続的デプロイ 完全に自動化されたプロセスで、テスト環境や本番環境を含む任意の環境に任意のバージョンのソフトウェアをデプロイし、リリースします。
トヨタの改善の型
トヨタの改善の型は、現状から次の状態へ、創造的かつ目的を持って進むための習慣です。四つの段階があります。
- より大きなビジョンや、進むべき方向を見据えながら……
- 現状を把握します。
- 次に、次の目標状態を定めます。
- その目標状態に向かって、継続的に試行を重ねます。その過程で対処すべき障害が見つかり、一つずつ解消していきます。
事前に道筋を予測し、計画の実施に集中する改善手法もあります。トヨタの改善の型では、途中で得た発見をもとに学び、改善を積み重ねます。チームと共に目標状態を目指しながら学び、学んだことをもとにやり方を調整します。
制約理論
ソフトウェアを届ける組織では、あなたの組織も含め、IT部門と事業部門の間にいつも相反する要求があります。事業ニーズにすばやく応えながら、本番環境の安定性と予測可能性を確保することは、IT部門が常に直面するトレードオフです。本番リリースのリスクをゼロにはできないことはご承知のとおりです。複雑なシステムでは、リスクを抑えようとすれば十分な速さを得られず、コードを本番環境にすばやくリリースしようとすれば低リスクを保証できません。
この対立には、次のように対処できます。
- IT組織を、小規模で自律的、独立して自己完結でき、緊密に協働する多数のチームに分けます。それぞれのチームを、使命を持ち、自ら判断できる単位と捉えてください。
- 各チームに割り当てるバッチサイズ、つまり仕掛かり作業の規模を小さくします。
- アイデアや要件を、本番環境で動く有用な機能に変えるまでのリードタイムを短くします。
- より速く、信頼性が高く、途切れないフィードバックループを作り、デプロイの準備が整っていることを確認します。
アジャイルソフトウェア開発宣言
DevOpsでは、アジャイルソフトウェア開発宣言が掲げる基本的な価値観に従います。
- プロセスやツールよりも個人と対話を重視する。
- 包括的なドキュメントよりも動くソフトウェアを重視する。
- 契約条件や交渉よりも顧客との協調を重視する。
- 計画に従うことよりも変化への対応を重視します。
アジャイルなインフラ
規模を問わず、私たちの組織は、おそらくあなたの組織も含め、パブリッククラウドとプライベートクラウドに専用サーバーを組み合わせたハイブリッドクラウド基盤を利用しています。これにより、コロケーションのセキュリティと、パブリッククラウドの柔軟性および拡張性の両方を享受できます。
アジャイルなインフラがDevOpsに役立つ主な理由は次のとおりです。
- 透明でシンプルな料金体系で、使った分だけ支払う。
- コードベースからテスト環境や本番環境をすばやくプロビジョニング、またはプロビジョニング解除できる（Infrastructure as Code、IaC）。
- アーキテクチャに柔軟性を持たせられます。
- 他の地域へ簡単に展開できる。
- セキュリティが向上する可能性が高い。
- 監査や追加費用なしでコンプライアンスを維持できる。
まとめ
この章では、DevOpsとは何か、そして何がDevOpsに当てはまらないのかを解説しました。また、DevOpsの土台となった主な取り組みと原則も取り上げました。
一つ注意があります。残念ながら、多くのアジャイル実践者が長年の実践で陥ってきたように、DevOpsの固定的な定義を当てはめて、自社や製品、サービス、そして何より自分のチームでの活用方法を決めつけないでください。アジャイルにもDevOpsにも、すべてに当てはまる方法はありません。
大切なのは、学び、試し、適応することだと忘れないでください。DevOpsは多くのことを可能にしますが、自分たちに合ったDevOpsのあり方と実践方法を見つけることは、人間である私たちの最も重要な務めです。Google、Amazon、Facebook、Netflix、Appleなど、DevOpsで成功を収めている組織はみな、これを行ってきました。
