Close

CALMS フレームワーク

能力を評価して、DevOps ジャーニーの進捗状況を測定します。

Ian Buchanan

プリンシパル ソリューション エンジニア


CALMS は、DevOps プロセスを導入する会社の力を評価するとともに、DevOps の変革を行う中で成功を測定するための手段でもあります。『The DevOps Handbook (The DevOps ハンドブック: 理論・原則・実践のすべて)』の共著者 Jez Humble による造語で、Culture (文化)、Automation (自動化)、Lean (リーン)、Measurement (測定)、Sharing (共有) を表します。

文化 (Culture)


DevOps とは単なるプロセスや開発への異なるアプローチではなく、文化の変化です。そして、DevOps 文化で大きな役割を果たすのがコラボレーションです。

開発と IT/ 運用のプロたちが協力しないと、DevOps におけるツールの整備と自動化は何の役にも立ちません。DevOps ではツール関連の問題を解決することはできません。解決できるのは人間の問題です。

DevOps をアジャイル チームの進化であると考えてみてください。これまでと違うのは、運用が最初から含まれていることです。部門に基づくチームではなく製品の観点からチームを編成することが、成功への一歩になります。開発、QA、プロダクト マネジメント、設計、運用、プロジェクト管理、そして長期プロジェクトに必要なあらゆるスキル セットを含めるようにしましょう。1 つのチームですべてを行ったり「DevOps のプロ」を雇ったりするのではなく、シームレスに協力できる製品ベースのチームを構築することがより重要になります。

共通の目標の共有、その目標を一緒に達成するための計画立案などによって、コラボレーションを促進できます。企業によっては、製品ベースのチームに突然切り替えるのはやりすぎだし時期尚早な場合もあります。そのため、小さなことから始めていきましょう。開発チームが行っているスプリント計画セッションや毎日のスタンドアップ、スプリント デモに運用チームの該当メンバーに参加してもらえます (参加してもらうべきでしょう)。運用チームのミーティングには、重要な役割を果たしている開発者を招待します。これが、お互いの作業、アイデア、苦労を把握するアジャイルで自然な方法です。

関連資料

DevOps のメリットに関する詳細

関連資料

DevOps 文化の構築

課題や緊急事態でさえ、DevOps 文化をテストする絶好の機会となります。開発者、運用チーム、カスタマー アドボケートは、課題に対して一丸となってチームとして課題解決に当たっていますか? インシデントの事後分析は、責任のなすりつけ合いをするのではなく、次のインシデントの結果を改善することに重点を置いていますか? 答えが「はい」の場合は、組織が DevOps 文化を受け入れていることを示す良い兆候です。

大きく成功している企業ほど、すべての部門、そして組織図のすべてのレベルで DevOps 文化を導入しています。このような広い規模では、「DevOps」という用語は対象が狭すぎるので不要です。こうした企業はオープンなコミュニケーション チャネルを有しており、定期的な対話の機会を設けています。さらに、顧客を幸せにし続けることが、プロダクト マネジメントと開発チームの両方の責任であると認識しています。そして、DevOps は 1 つのチームだけの仕事ではなく、全員で行うものだということを理解しています。

自動化


自動化は反復的な手作業を排除し、反復可能なプロセスを生み出し、信頼性の高いシステムを作ります。

まだ自動化を実施していないチームでは通常、自動化の構築、テスト、デプロイ、プロビジョニングから始めることになります。開発者、テスター、運用担当者が協力する理由は、すべての人にメリットをもたらすシステムを構築する、ということだけで十分でしょう。

これまで自動化を行ったことのないチームは、継続的なデリバリーから始めましょう。これは、多くの場合はクラウドベースのインフラストラクチャを活用して、一連の自動テストによって各コードの変更を行い、自動化したデプロイによってビルドをパッケージ化して環境間でプロモートする手法です。

これを導入する理由は、人間よりもコンピューターの方がより厳密かつ忠実にテストを実行するからです。コンピューターによるテストでは、バグとセキュリティ上の不備をこれまでより早く検出できます。そして、デプロイの自動化によって環境間のドリフトを IT/ 運用に警告することで、リリース時に予想外のことが起きることを軽減します。

DevOps の大きなメリットして他にも「コードによる構成 (Configuration As Code)」があります。開発者は、信頼性が高く、メンテナンスもしやすいことから、モジュラー型で部品組み立て方式のアプリケーションを開発しようとしています。同じ考え方を、クラウドや企業の独自ネットワークでアプリケーションをホストするインフラストラクチャにも広げることができます。

DevOps の世界で起きている自動化は「コードによる構成」と「継続的デリバリー」だけではありませんが、開発チームと運用チームの壁を壊す存在であることから特にここで取り上げました。DevOps でデプロイを自動化して、共通のプロビジョニングが実施された環境に徹底的にテストされたコードを送信すれば、「自分のマシンでも問題なく動いた!」などという発言は意味のないものになります。

リーン (Lean)


ソフトウェアの話題で「リーン」という言葉を聞くと、通常は価値の低い活動を廃止して効率を向上し、決然とアジャイルを実践することを思い浮かべます。DevOps をより適切に表すのは、継続的な改善に努めて失敗を受け入れるというコンセプトであり、これが実験的なマインドセットの基礎となります。

DevOps のマインドセットは、あらゆる場所で継続的な改善の機会を認識することです。わかりやすい例としては、チームのプロセスを改善する定期的なふりかえりなどが挙げられます。わかりにくい例としては、製品の新規ユーザーに対する異なるオンボーディング アプローチの A/B テストなどが挙げられます。

アジャイル開発のおかげで継続的な改善は主流の考え方になりました。アジャイル手法を初期の段階で取り入れた人たちによって、完璧なプログラムを届けるために顧客を 6 か月待たせるより、シンプルなプロダクトを今すぐ顧客に届けることの方に価値があることが証明されました。プロダクトを継続的に改善していけば、顧客が離れていくこともなくなります。

この取り組みを行う場合、失敗を避けて通ることはできません。そのため、チームが失敗を受け止めてそこから立ち直り、学びを得ることができるようにしましょう (これを「打たれ強くなること」と言う人もいます)。ほとんど失敗することがないと、アトラシアンでは懸命に取り組んでいないと見なされます。

DevOps の観点から見ると、失敗は罰に値するような違反ではありません。物事はどこかの時点で失敗する運命にあることをチームで想定しているため、早期に失敗を見つけて短時間で修正できるような開発の進め方をしています。事後分析では、コードに問題をもたらしたチーム メンバーを突き止めることではなく、プロセスが失敗したポイントとそれを強化する方法に重点を置きましょう。どうしてでしょうか。それは、継続的な改善と失敗には密接な関係があるからです。

測定 (Measurement)


継続的な改善の取り組みが実際に効果を発揮しているかをデータなしで証明することは困難です。ありがたいことに、ユーザーがプロダクトに費やした時間、ブログ投稿が売り上げを生み出したかどうか、ログに重要なアラートが出現する頻度などのパフォーマンスを測定するツールとテクノロジーがたくさんあります。

あらゆることを測定できますが、だからといってすべてを測定する必要はなく、推奨もされていません。アジャイル開発を参考にして、まずは基本的なことから始めましょう。

開発からデプロイまでどれくらいかかりましたか。

同じバグや失敗はどれくらいの頻度で起こっていますか。

システム障害から復旧までどれくらいかかりますか。

現在自社製品を使っているユーザーはどれくらいいますか。

今週のユーザー数の増減はどれくらいですか。

しっかりとした基盤を整えることで、フィーチャーの使用状況、カスタマージャーニー、サービスレベルアグリーメント (SLA) に関して洗練された指標をより簡単に得ることができます。ロードマップの作成と、次の大きな動きに向けた仕様の策定を行うときに、こうした情報が活躍することになります。

このような充実したデータは、チームの意思決定をサポートするだけでなく、特に他の部門のチームと共有したときはさらに強力な威力を発揮します。たとえば、マーケティング チームは売り込みに利用できる魅力的な新機能を求めているとします。一方で、製品は技術的負債を多く抱えているため、大量の顧客離れが起きています。ロードマップを裏付けるユーザー データを提供することで (たとえ機能より修正プログラムに重心を置いたものでも)、合意形成と関係者との同意の取り付けを実現しやすくなります。

共有 (Sharing)


すべてのチームを高いパフォーマンスを発揮する DevOps チームに生まれ変わらせる魔法の杖があればよいのですが、実際のところ DevOps の変革にはさまざまなプラクティス、文化的な哲学、ツールが必要になります。しかし、これまでご紹介してきたとおり、開発と運用のサイロを取り壊すことには、信頼の向上、ソフトウェア リリースの迅速化、より信頼性の高いデプロイ、チームと顧客の間のフィードバック ループの改善など、大きなメリットがあります。

DevOps の導入は簡単ではありません。しかし、適切なマインドセット、取り組み、ツールがあれば、組織は大きなメリットをもたらす DevOps の変革を実現できます。

開発チームと運用チームの間に長年軋轢がある原因の大半は、共通の土台がないことです。責任を共有して成功を分かち合うことが、分断を埋めるのに大きく役立ちます。開発者は運用の最大の重荷である「障害時の呼び出し」をサポートすることで、すぐに信頼を勝ち取れます。DevOps では、アプリケーションの構築を行った人間がリリースと実行にも関与するというアイデアを重視しています。

結論


このアイデアから「構築した者が運用する」というフレーズが生まれます。これに従うことによって、チーム全体で実践的なアプローチが促進されます。ただしこれは、開発者を雇って、優れた運用担当者として作業を兼務してもらうということではありません。アプリケーションのライフサイクル全体で、開発者と運用担当者が互いにタッグを組むということです。さらに、レポートによると、ピアレビューされたコードと製品は、より良いデリバリーとパフォーマンスをもたらす唯一のレビューであることが示されています。実際、外部レビュアーは、レビューをまったく行わないのと同じくらい効果的ではありませんでした。

多くの場合、DevOps を取り入れているチームでは、エンドユーザーが見つけた問題への対応を行いながらプロダクションの問題のトラブルシューティングも行う開発者の役割を持ち回りにしています。この役割では、顧客から報告があった緊急の問題への対応、必要時のパッチの作成、顧客から報告があった不具合のバックログの作業も行います。「サポート担当の開発者」はアプリケーションが実際にどのように使われているかについて多くのことを学ぶことになります。また、運用チームと深く関わることで、開発チームは信頼を勝ち取って互いに尊重し合うようになります。

Ian Buchanan
Ian Buchanan

Ian Buchanan はアトラシアンの DevOps のプリンシパル ソリューション エンジニアです。継続的なインテグレーションとデリバリーの向上を目的とした新しい DevOps コミュニティと、Jira、Bitbucket、Bamboo アプリケーションの適用に重点的に取り組んでいます。Java と .NET の両方について広範で豊富な経験を持つ Ian Buchanan は、大企業におけるリーンとアジャイルの各プラクティスの推進者として最もよく知られています。

キャリアにおいて、企業のソフトウェア開発ツールのライフサイクルを、最初から最後まですべての段階で適切に管理してきました。組織全体のプロセス改善を推進して、生産性、品質、顧客満足度を向上させました。自己主導性と自己組織化を尊重する多国籍アジャイル チームを構築しました。会話やコーディングをしていないときには、Ian はパーサー、メタ プログラミング、ドメイン特化言語にその情熱を傾けています。


この記事を共有する
次のトピック

おすすめコンテンツ

次のリソースをブックマークして、DevOps チームのタイプに関する詳細や、アトラシアンの DevOps についての継続的な更新をご覧ください。

DevOps のイラスト

DevOps コミュニティ

DevOps のイラスト

シミュレーション ワークショップ

マップのイラスト

無料で始める

DevOps ニュースレター購読

Thank you for signing up