DevOps、Agile、CICD、IaC、DevSecOps、Scrumなど、IT 業界はどんどんバズワードが増えます。しかし、これらの用語を本当に理解している人はどれだけいるのでしょうか？また、これらの用語は、本当にきちんと定義されているのでしょうか？
Agile や DevOps を導入しようにも、理解できないことは、導入もできません。
この記事では、分かるようで分からない「DevOpsの定義」と、「なぜ、DevOps や Agile の導入が難しいのか？」、そして「DevOps と Agile 導入の課題に対する解決策」を、そして、合同会社イネド・ジャパン の CEO Alex Papadimoulis, Inedo と、複数のDevOps、Agile、Scrum のコンサルティング、トレーニング会社に取材し、その内容をまとめました。
そもそも、DevOpsとは何か？
2009 年、Flickr 社の「10 deploys per day（10 デプロイ/日）」というスライドで、同社のオンラインの写真共有サービスの更新デプロイを1日に10回もしているという、当時ではかなり衝撃的な数字と、その方法を公開しました。
Flickr 社は、ツールと社内文化を変えることにより、Dev（開発部門）Ops（運用部門）が協力し、混乱なくサービスを1日10回も更新することを可能にしました。 これが、DevOps が、初めて話題になった瞬間です。
DevOps と Agile の違いは？
DevOps の手法 と Agile の手法は、実際に、共通しているところがたくさんあります。アジャイル（Agile）という言葉は日本語で「俊敏」を意味します。
アジャイルは、従来の一般的な開発手法「ウォーターフォール開発モデル」にたいする、アンチテーゼとして生まれました。ウォーターフォール開発モデルでは、ソフトウェアの要件定義⇒外部設計⇒内部設計⇒テスト設計⇒プログラム作成⇒各種テスト実行⇒運用テスト⇒納品を、ひとつずつこなしていきます。
一方で、アジャイルは要件・仕様の優先度に応じて開発プロジェクトをいくつも立ち上げて、各プロジェクトの中で短い開発サイクル（イテレーション）を繰り返します。そのため、ウォーターフォール型と比べて、プロジェクト途中で要件・仕様の変更が生じても、影響が及ぶ範囲を最小限に留められます。
このように、DevOpsとアジャイルには決定的な違いがあます。しかし、DevOps を実現するために、アジャイルモデルで開発するなど、アジャイルのためにDevOpsをするなど、両社は密接に関係しています。
なぜ、DevOps や Agile の導入が難しいのか？
Agile や DevOps の目的が誤解されています。
顧客によってそれぞれ異なるのですが、DevOpsについてはさほど精通してはいない印象を受けています。（クリエーションライン株式会社 H.A 氏）
インタビューでは、国内における DevOps の認知度の低さが浮き彫りになりました。DX、Scrum、シフトレフト、CI/CD、パイプラインなど、バズワードが多すぎて、混乱している企業が多いようです。
多くの場合、現段階ではAgile/DevOpsを正しく理解し実践できている会社はほとんどないようです。DevOps や Agile の目的が「効率化によるコスト削減」であるという誤解が多いそうです。
本来の目的は「効率化によるコスト削減」ではなく、「開発（改善）のスピードをあげ、高品質なサービスの提供を可能とし、ビジネスの機会損失を削減する」です。
Agile の背景
システム開発は、短納期化と低コスト化の流れが進んでいます。その解決策のひとつとして期待されているのが「速い・安い」を実現する「アジャイル開発」です。これが日本の実情です。しかし、残念ながら、これは Agile の本質ではありません。
システム開発の環境と、ビジネスの環境は変化が激しくなっています。「変化するビジネス環境では、ウォーターフォール型では、予測不可能な要件や変化に対応するのが難しい」という課題にたいする答えとして登場したのが Agile 開発です。
変化に対応しやすい開発モデルと、短納期と低コストの開発モデルは、違う形になるでしょう。確かに、アジャイルは、手戻りが減るため、結果的にコストが下がることもあります。しかし、要件が明らかで、変更もない開発なら、Agile のメリットはありません。ウォーターフォールのほうが効率的でしょう。
DevOps の背景
もともと開発者とシステム運用者は、役割が分かれていませんでした。しかし、テクノロジーの進化と、開発の大規模化により、専門分野が細分化され、開発と運用が別部門に別れました。
その結果、組織の壁によるコミュニケーションロスが発生するどころか、組織同士が反目するようになり、それをビジネスパフォーマンスに影響を及ぼすようになりました。
これが DevOps へのニーズが生まれた背景です。
DevOps と Agile に共通する背景
DevOps と Agile、どちらにも共通する背景があります。それは、「変化と競争の激化」です。
開発チームは、ライバルと出し抜き、業界を生き抜くために、ライバルが導入した新機能、フレームワークの更新、新たな技術、顧客の要望変更などに対応し、設計変更が余儀なくなれます。
運用チームは、変更された設計に対応するよう、インフラを設計しなければなりません。設計が、何度も変更されると、「またですが・・・」「そこをなんとか・・」というやりとりも増えます。
DevOps を導入するには、何をすればいいのか？
単純にDevとOpsが協力するのがDevOpsみたいな話しになりがちですが、実際には間違ってはいないけど、どう協力するのかが一番大事です。（アギレルゴコンサルティング株式会社 Y.K 氏）
1. 関連する部署を含めたプロジェクトチームの構築
メトリクスの共通化、ソースコードを両方が見る、インフラを自動化してインフラのコードはインフラサイドが書くが、それを Dev 側が手伝えるようにするなど、Dev と Ops がどう協力するかを考えないと DevOps は成功しない（アギレルゴコンサルティング株式会社 Y.K 氏）
週に一回だけ、DevとOpsの代表者がミーティングし、部署に戻って会議内容を共有する。それだけでは、DevOpsとは言えません。全員がリアルタイムで情報を共有し、部署や役職の垣根なくサポートし合う文化と、それを支えるためのツールを導入することが DevOps です。
ちなみに、株式会社ITプレナーズジャパン・アジアパシフィックによる、DevOps の研修は必見です。書籍「The Phoenix Project（The DevOps 逆転だ！）」を基にした、丸一日使ったゲームスタイルのワークショップ型研修です。座学はほとんどありません。
2. コミュニケーション（=文化）を変える
話すことです。とにかく対話。できればオンラインではなくFace to Faceで。対話の場をつくるということが大事です。（株式会社ITプレナーズ M.O 氏）
インタビューから見えてきたのは意外にもFace to Faceの対話不足でした。こんな基本的なことと思われがちですが、チャットツール類の発達で便利になりましたが、Face to Faceのコミュニケーションに勝るものはないようです。確かに顔をみて話すことにより、テキストだけでは読み取れない情報がたくさんあります。
直接話して少し確認をしておけば解決できるような問題が、会話していないがために後半になって大きな問題となっているというパターンが多く見受けられるそうです。
3. 現在の状況を可視化する
DevOps を、現状の課題に対する解決策として導入するなら、現状の課題を明確にしなければなりません。
Creationline,inc では、企業によってボトルネックとペインポイントと異なるため、それを明らかにするために、Value Stream Mappingをやっています。これによってプロセス全体の流れを見える化し、ボトルネックやペインポイントを特定しています。
企業は、特別な事情のもと、特別に作りあげられてきた独特の社内プロセスが存在するため、全企業に利く、万能薬のような解決法はないからです。
4. 自由に発言できる環境を作る
Creationline,inc では、かかわっているメンバー全員で、目的を共有し、自由に発言できる環境を作っています。そこからプロジェクト作成、実行、定期的な見直しを繰り返しながらプロジェクトを進めています。
天井を抜いたりとか、仕切りを無くして一部屋を大きくとか、部屋中の壁をホワイトボードにするとか、机や座席を動かせるようにしておいて目的に応じたレイアウトにすぐ変えられるなど、ジョイ・インク（Joy, Inc.）を参考に作ってるそうです。
5. 文化を変えるために、Scrumを導入する
JB では、文化を変えるために、スクラムという手法を導入しています。
Scrum では、チームでプロジェクトを進めていくうちに出る問題点を、短期的なサイクルでチーム全員が問題点を共有し、改善案をどんどんだします。問題点の共有は、担当する人や部署を非難するのではなく、改善案を全員で提案する事が目的とします。
これにより、それぞれのチームが自己組織化できます。1人ではできないことをチームで解消しようとするのがスクラムです。たとえば QA (Quality Assurance) ができない時、チームの中に QA のコンピテンシーをもつ者を取り入れたりします。
6. 自動化する
反復作業や、人間が苦手な作業、人間では時間がかかる確認作業を自動化しす。そしてそのプロセスを検証し、問題があるときには全員で案を出して修正します。
これによりツールで安定したリリース品質を保ちながら、迅速に素早く新しいサービスもしくは改善したサービスをデプロイする環境を整えていきます。
すでにコミュニケーション方法、問題の洗い出しなど完了されていて、ツール類を探しているという方は、最後のリファレンスページにある弊社ツール類を試していただければと思います。
7. ひとつの目的にこだわらない。
Agile は、変化への柔軟な対応を目的とした開発手法です。では、DevOps の目的は何でしょう？
じつは、DevOps には決まった目的はありません。「Dev と Ops の連携」というカテゴリに収まる、開発モデルや、ツール、手法、原則などは、それがコスト削減だろうと、リリース頻度の改善だろうと、すべて「DevOps」と言えます。
例えば、Infrastructure as Code の一環として、インフラを自動化するための PowerShell スクリプトを開発チームと運用チームが Otter などのツールを使って共有するとします。これにより、コードによる構成は、クリックによる構成と異なり、100台のサーバを自動で構成できるし、スクリプトを走らせるだけなら、手が空いている新人でもできるし、午前2時に自動で走らせることもできます。この自動化は、複数のメリットがあります。
ただ DevOps や Agile をやるだけではなく、自分の組織、チーム、職場が毎日わくわくするような場所に変えていってほしい。じゃなければやる意味がない。（株式会社yamaneco JB氏）
まとめ
なぜ、DX、Agile、Scrum、CICD、IaC、DevOpsなど、IT業界ではますますバズワードが増えているのでしょうか？それは、技術の進歩がそれだけ早いからです。これからも、技術革新はより加速し、より多くのバズワードが生まれ、そして、それ以上に、IT の活用で企業間に格差が生まれるでしょう。
時代は進みます。自分だけ止まっていると、後れを取ります。これからの企業には、よりアジャイルなビジネスと、それを支えるDevOps的な文化が必要になるのでしょう。
DevOps for Japan
コンプライアンスを犠牲にすることなく、現代のビジネスに必要なプロダクトをよりスピーディに
