はじめに
この記事は、Microsoft Learn の下記のモジュールの中から重要と思われる内容を(筆者が勝手に抽出して)書き残しているものです。
上記のモジュールは、2020/5/1 現在、英語でのみ提供されています。日本語の内容を確認されたい方は、こちらを参照してください。※公式のものではありません
DevOpsの最初のステップ
現在のプロセスを理解する
The first step to setting up a DevOps practice is to assess your current process.
DevOps プラクティスを始める際の最初のステップは、「現在のプロセスを評価すること」とありますね。
これは、これまでウォーターフォール開発をやってきた人たちがDevOpsを導入しようとする際にありがちなだと思うのですが、DevOpsを始める=アジャイル/スクラム開発を始めるであったり、DevOpsを始める=ツールを導入するということだと勘違いする人が本当に多い。
上記は、DevOpsを推進するための手段であって、目的ではないということを理解しないといけないです。なぜ、DevOpsを始めるのか、その目的をきちんと押さえるためには、「現在のプロセスを評価すること」がとても重要なわけですね。
ちなみに、モジュール内では、以下の内容の分析を例として提示しています。
・Your existing artifacts, such as deployment packages and NuGet, as well as your container repositories.
（配置パッケージや NuGet などの既存のアーティファクト、およびコンテナーリポジトリ）
・Your existing test management tools.
（既存のテスト管理ツール）
・Your existing work management tools.
（既存の作業管理ツール）
・Recommending migration and integration strategies.
（移行・統合戦略の提案）
現在の開発プロセスや CI/CD の状況をまず理解しよう、ということですね。理解した上で、何がうまくいっているのか、何がうまくいっていないのかを評価する。
バリューストリームマップ
モジュールの中では、バリューストリームマップ (VSMs) について触れています。VSM を作成することによって、既存のプロセスの現状を理解しようということです。
なぜ VSM を作成するのかについては、モジュール内に説明があります。
Creating a value stream map, or VSM, helps you analyze your current release cycle process. The purpose of a VSM is to visually show where in the process a team creates value and where there's waste. The goal, of course, is to arrive at a process that delivers maximum value to the customer with minimum waste. A VSM can help you pinpoint those areas that either don't contribute any value or that actually reduce the value of the product.
バリューストリームマップ（VSM）を作成することで、現在のリリースサイクルプロセスを分析することができます。VSM の目的は、プロセスのどこでチームが価値を生み出し、どこで無駄があるのかを視覚的に示すことです。もちろん、目標は、無駄を最小限に抑えて最大の価値を顧客に提供するプロセスに到達することです。VSMは、価値のない部分や製品の価値を下げている部分を特定するのに役立ちます。
つまり、既存のプロセスについて理解した内容を書き起こすためにVSM を作成し、既存のプロセスにおいて価値がある部分、無駄となる部分を洗い出そう ということですね。
①は、新しい機能を作成する際に、集中型バージョン管理システムに新しい機能のためのラベル作成を行う部分のタスクを表していて、その作業に3日かかっているという内容です。これは顧客にとって何ら価値のないものなので、できるだけ時間をかけない方がいい、ということです。
②は、新機能のコーディングで、その作業に4日かかっているという内容です。新機能は顧客に求められている内容なので、顧客にとって価値ある、ということです。
こんな感じで、それぞれのプロセスを評価していくことができるようになるため、VSM は作成しよう、ということですね。
顧客価値のメトリクスを計算する
効率性を可視化する
VSM によって、既存のプロセスが価値あるものか無駄なものかを判断できるようになったのですが、これはあくまで定性的な内容のため、これらを数字の世界に落とし込んで定量的な形で可視化することが大切ということです。
モジュール内では、トータルリードタイム、プロセスタイム、活動比率 の3つを提示しています。
Total lead time is the time it takes for a feature to make it to the customer. Process time is the time spent on a feature that has value to the customer. The activity ratio is process time divided by total lead time:
トータルリードタイムとは、機能が顧客に届くまでにかかる時間のことです。プロセスタイムとは、顧客にとって価値のある機能に費やされる時間のことです。活動比率はプロセス時間をトータルリードタイムで割ったものです。
ちなみに、上記の VSM の内容をこの数式に当てはめると、活動比率は 23％ とのことです。
つまり、全体の中で、顧客にとって価値のある部分に費やされている時間は全体の23%しかなく、残りの77%のプロセスには無駄があるということになります。この無駄な部分に対して、DevOps のプラクティスを導入することで費やす時間を最小限に抑えることができないか という分析を始めることが最初のステップだと言っているわけですね。
今のプロセスを捨てろというわけではない
77%のプロセスは無駄だからすぐに捨てる、というのも、DevOpsではありません。モジュール内でも、その点について言及がされています。
I'm not suggesting we drop our current processes, but I think we can work toward a more efficient process in small increments without disrupting what we currently have in place.
今のプロセスを捨てろとは言いませんが、今のプロセスを崩さずに、少しずつ効率的なプロセスを目指していくことはできると思います。
つまり、DevOpsは既存の開発プロセスと喧嘩するものではないということです。「ウォーターフォールは時代遅れだ、今の世の中は全部DevOpsだ」と言って、DevOpsを真っ白なキャンバスから始めろ、というわけではないのです。（おそらく大半はそういうことをしてチームが崩壊します）
DevOps、とりわけスクラムの理解を進めていくとわかると思いますが、1つのスプリントをチームで達成するためには、チームの協同が必要不可欠なわけです。なのに、これまでの内容を否定し、強引にDevOpsに慣れていない人たちに対して強引に事を推し進めようとすると、周りの賛同を得られずに孤軍奮闘しているだけになる、ということですね。
さいごに
筆者は、DevOpsを学び始めて、実際の現場にも取り入れようとしていますが、事前にこのモジュールを読み進めて正解だったと思います。DevOpsに興味がある方、DevOpsを始めたけどうまくいっていない方は、こちらを一度、お読みになられるといいと思います。
2020/5/4 追記
2020/5/3 に開催した 勝手に勉強会 にて。VSM の話をした際、@kenakamu さんから追加でフィードバックがありましたので、追記します。
VSM を作成する際は利害関係者全員でやる
VSM を作成する際は、Dev 側のリーダー、Ops 側のリーダー、(また日系企業であれば特に) 押印手続きや承認手続き時に登場する人物など、評価するプロセス内に登場するステークホルダー全員がいる場でやりましょう。
なぜならば、誰かが欠けていると、その人物やチームにスポットがあたり、粗探しや批判へと突入してしまうからです。VSM の作成は、誰かを批判するために行うものではありません。
どこのプロセスに改善が見込めそうか、プロセス全体で抜け漏れがないか、といった認識を利害関係者全員で共有し、チーム全体で改善のための施策を練るために VSM は存在します。もし、誰かの批判を始めてしまうような状況になった際は、かならず止めましょう。
マイクロソフト社 Playbook
マイクロソフト社の参考情報として、以下の GitHub リポジトリを共有していただきました。
ソース管理における決まり事や、リポジトリのブランチ分岐の戦略など、様々な内容が記載されています。
1 つの参考事例として、参照してみてください。