皆さんこんにちは！富士通ラーニングメディア 人材育成イノベーション事業部の佐藤です。
今回はアジャイル開発のコラム第8弾です！前回までは、アジャイル開発、スクラム、テスト駆動開発、新人研修などについてご紹介しました 。
本コラムは、アジャイル開発と一緒に押さえていただきたい「DevOps」を取り扱います。開発と運用によく見られる “壁” へ取り組むためのヒントになれば幸いです。
DevOpsとは
まずはDevOpsの概要紹介です。本コラムではDevOpsを、開発と運用のコラボレーションと定義します。DevはDevelopment（開発）、OpsはOperations（運用）の略語です。DevとOpsという2つの異なる立場のメンバーが協調し、ビジネスの成功を目指すことで、ビジネス環境の変化への対応を俊敏に取れるようにします。
開発が専門であるメンバーと、運用を専門とするメンバーは、スピードと安定性という、相反する観点に取り組む必要があります（例えば、「ニーズに合わせた機能追加の素早い提供」と、「システムの安定した稼働」など）。
DevOpsの構成要素「CLAMS」
それぞれの専門分野や立場が異なる環境で、スピードと安定性の両立を目指すのは、けして簡単ではありません。複数の要素へ目を向けて取り組む必要があります。
DevOpsの実践に必要な要素として、よく知られているのが「CLAMS」です。CLAMSは、Culture（文化）、Lean（リーン）、Automation（自動化）、Measurement（計測）、Sharing（共有）、それぞれの頭文字をとっています。いずれもDevOpsへ取り組む際のフレームワークとして活用できます。
どうやってコラボレーションしたらいいの？
ここから先は、皆さんの職場をそれぞれイメージいただきつつ、お読みいただければと思います。
「開発と運用のコラボレーション」は、昔からよく言われることです。しかし、様々な理由から、なかなか進まないようです。
そもそも、開発と運用ではお互いの責任が異なるため、「どのように取り組んだらよいか分からない」というケースが多いようです。
例えば、弊社の講習会で講師がお尋ねしたところ、以下のようなことが「分からない」との声をいただきました。
- どのような実施体制にすべきか？
- なにを最終目標（ゴール）にしたらよいか？
- 必要なツールはあるか？
- どうやって効果を測定したらよい？
- メンバー間の情報共有はどうしたらよい？
そこで以下、CLAMSの観点ですこし整理してみたいと思います。
CLAMSでの整理（例）
以下は、CLAMSでの整理例です。 ※ この例以外にも様々な整理方法があります。
Culture（文化）
コラボレーションが思うようにいかない理由の一つに、文化があります。
開発と運用は、別チームや別組織として動いていることが多く、メンバーの基本的な価値観すら異なっている場合があります。そのような状態のままでは、どのような実施体制を取ったとしても、意思疎通に時間がかかり、スピーディな対応が取りづらいです。
そのため、まずは小規模なチームを作り、中長期的な視点で、共通の文化を整えていきます。
具体的な取り組みとしては、チームで「グラウンドルール」を考え、日々の行動レベルから揃えることを行います。このような小さな取り組みから始め、お互いにとって共通の文化を形成していきます。
Lean（リーン）
コラボレーションの目的に応じて、様々な最終目標（ゴール）が考えられますが、すくなくともDevOpsでは「リーンな状態」がゴールです。
リーン（＝リーンソフトウェア開発）の考え方として、ビジネス環境の変化への対応を俊敏に取るべく、顧客（ユーザー）からのフィードバックを素早く得て、継続的に改善を繰り返します。このサイクルをこまめに回すようにします。そのために価値の提供の流れを見える化して、不要なものを排除していきます。
具体的な取り組みとしては、チームで「バリューストリームマップ」を作り、リーンで定義する「ムダ」を減らしていきます。
Automation（自動化）
開発と運用のコラボレーションを実現するには、ツールの整備も必要です。自動化により、ソフトウェアやサービスなどの開発や提供に費やす時間を短縮できるからです。
例えば、ソースコードの変更において、バージョン管理システムに反映させてから利用者にサービスを提供するまでのプロセスを自動化すると、素早くサービスを提供してフィードバックが得られるようになります。
チームで行う取り組みとしては、自動化により「デプロイメントパイプライン」を構成していきます。
Measurement（計測）
開発と運用のコラボレーションは、測定して現状を把握し、改善のサイクルを回す必要があります。
一般的に、SLAなど顧客との契約内容の達成に注目しがちですが、契約に基づく指標値では、開発と運用のコラボレーションがうまくいっているかどうかは測定できません。そこで、スピードと安定性にかかわる指標として「変更のリードタイム」、「デプロイの頻度」、「変更障害率」、「サービス復元時間」などを指標として、チームの動きを把握します。
チームとしては、数値目標の達成にこだわりすぎず、「リーンを最終ゴールとして動けているか」を確認することになります。
Sharing（共有）
開発と運用のコラボレーションで、情報共有は工夫が必要です。
というのも、異なる専門家間でのコラボレーションは、まずは小規模なチームから始めて、徐々に人数などを増やして展開します。そのため、途中から参加するメンバーがいることを前提に、これまでの経験やノウハウを共有できるようにする必要があります。
具体的には、一対一または一対多による支援（コミュニケーション）と、文書にまとめること（ドキュメンテーション）を行います。
以上、概要レベルのご説明になりましたが、CLAMSで整理したコラボレーションの例になります。
どのような取り組みであれば効果があるかは、皆さまの状況によって様々ですが、まずは状況を整理するためのフレームワークとしてCLAMSをご利用いただければと思います。
最後に…
顧客への継続的な価値提供のために、開発と運用は、お互いが協業する必要があります。
DevOpsをきっかけに、皆さまもコラボレーションへ取り組んでいただければと思います。
今回のコラムでは、開発と運用のコラボレーションと題して、DevOpsの構成要素「CLAMS」についてご紹介しました。
富士通ラーニングメディアでは、アジャイル開発に関する研修サービスを多数ご用意しています。
ぜひ、この機会に研修受講をご検討ください。
執筆者紹介
人材育成イノベーション事業部 デジタルプロセスプロジェクト所属
佐藤幸呼（さとう さちこ）
新人～若手時代、組織の中長期ビジョンと情報システム構想とのすり合わせを行うフェーズに従事。その後、情報システム開発をゼロから勉強し、ベトナムなどで学生・若手社会人とプロジェクト活動を行いました。専門分野・立場・言葉が異なる環境での仕事は、プロセス・フレームワーク・基本用語といった認識の共有が重要と考え、アジャイル開発にもその姿勢で取り組んでいます。
(2023/01/26)
