Microsoft が DevOps を使用して計画する方法
Microsoft は、アジャイル手法を使用する世界最大の企業の 1 つです。 Microsoft は長年の経験を経て、最小のプロジェクトから Windows のような大規模な取り組みまでスケールアップする DevOps 計画プロセスを開発してきました。 この記事では、Microsoft が全社的にソフトウェア プロジェクトを計画する際に学んだ教訓と実践方法の多くについて説明します。
機器の変更
次の重要な変更により、開発と出荷のサイクルがより健全かつ効率的になります。
- 文化的な連携と自主性を促進します。
- 焦点を個人からチームに変えます。
- 新しい計画と学習戦略を作成します。
- 複数の乗組員モデルを実装します。
- コードの健全性実践を改善します。
- 透明性と説明責任を促進します。
文化的な連携と自主性を促進します
ピーター・ドラッカーは「文化は朝食の戦略を食べる」と言いました。 自律性、熟達性、目的は人間の重要な動機です。 Microsoft は、PM、開発者、デザイナーが成功する製品を構築する力を感じられるように、これらの動機を提供しようとしています。
このアプローチに貢献する 2 つの重要な要素は、調整と 自律性 です。
- 調整はトップダウンで行われ、個人とチームが自分の責任がより広範なビジネス目標とどのように一致するかを確実に理解します。
- 自律性はボトムアップで実現され、個人やチームが日々の活動や意思決定に確実に影響を与えることができます。
調整と自律性の間には微妙なバランスがあります。 調整が行き過ぎると、人々が言われたことだけを実行するという否定的な文化が生まれる可能性があります。 自主性が高すぎると、構造や方向性が欠如し、意思決定が非効率になり、計画が不十分になる可能性があります。
焦点を個人からチームに変えます
Microsoft では、人々とチームを PM、設計、エンジニアリングの 3 つのグループに編成します。
- PM は、Microsoft が何を構築するのか、そしてその理由を定義します。
- デザインは、Microsoft が構築するものを設計する責任があります。
- エンジニアリングは製品を構築し、その品質を保証します。
Microsoft チームには次の重要な特徴があります。
- 学際的
- 10 名から 12 名
- 自己管理
- 12～18か月間の明確な憲章と目標
- 物理的なチームルーム
- 独自の機能の導入
- 本番環境での独自の機能
縦割りチームを目指す
Microsoft チームは以前は水平的なチームで、すべての UI、すべてのデータ、またはすべての API をカバーしていました。 現在、Microsoft は垂直チームを目指しています。 チームは製品の各領域をエンドツーエンドで所有します。 特定の層における厳格なガイドラインにより、製品全体にわたるチーム間の均一性が保証されます。
次の図は、水平チームと垂直チームの違いを概念的に示しています。
チームの自己選択を許可する
Microsoft は約 18 か月ごとに「黄色のスティッキー演習」を実施しており、開発者は今後数年間の計画期間に製品のどの分野に取り組みたいかを選択できます。 この演習では、チームが取り組む内容を選択できるため自主性が得られ、チーム間のバランスが促進されるので組織的な連携が得られます。 この演習に参加する人々の約 80% は現在のチームに残りますが、選択肢があったため権限が与えられたと感じています。
新しい計画と学習戦略を作成します
ドワイト・アイゼンハワーは、「計画には価値がないが、計画こそがすべてだ」と言いました。 Microsoft の計画は次の構造に分かれています。
- スプリント (3 週間)
- 計画 (3 スプリント)
- シーズン（6ヶ月）
- 戦略 (12 か月)
エンジニアとチームは主にスプリントと計画を担当します。 リーダーシップは主にシーズンと戦略に責任を負います。
次の図は、Microsoft の計画戦略を示しています。
この計画構造は、計画中の学習を最大限に高めるのにも役立ちます。 チームはフィードバックを取得し、顧客が何を望んでいるのかを見つけ出し、顧客の要求を迅速かつ効率的に実装することができます。
複数の乗組員モデルを実装します
以前の方法では、バグやライブサイトのインシデントによる「中断文化」が促進されました。 Microsoft チームは、集中力を高め、気が散ることを避ける独自の方法を考案しました。 チームはスプリントごとに、フィーチャー (F クルー) と 顧客 (C クルー) の 2 つの異なるクルーに自己組織化します。
F クルーはコミットされた機能に取り組み、C クルーはライブサイトの問題や中断に対処します。 チームは、メンバーが活動をより簡単に計画できるようにローテーションのリズムを確立します。 マルチクルー モデルの詳細については、「生産性の高い顧客中心のチームを構築する」を参照してください。
コードの健全性実践を改善します
アジャイル手法に切り替える前、チームは開発フェーズの終わりにコードが完成するまで、コードのバグを蓄積させていました。 その後、チームはバグを発見し、修正に取り組みました。 この慣行によりジェットコースターのようなバグが発生し、チームが新機能を実装する代わりにバグ修正に取り組む必要があったため、チームの士気と生産性に影響を及ぼしました。
チームは現在、式 # of engineers x 5 = bug cap によって計算される バグ キャップ を実装しています。 スプリントの終了時にチームのバグ数がバグの上限を超えた場合、チームは新機能の開発を中止し、上限を下回るまでバグを修正する必要があります。 チームは現在、バグの負債を順調に返済しています。
透明性と説明責任を促進します
各スプリントの終了時に、すべてのチームは、前のスプリントで達成したことと、次のスプリントで何を行う予定かを報告するメールを送信します。
目標と主要な結果 (OKR)
チームは、組織が達成しようとしている目標を明確にしているときに最も効果的です。 Microsoft は、目標と主要な結果 (OKR) を通じてチームに明確さを提供します。
- Objectives は達成すべき目標を定義します。 目標は、重要で、具体的で、行動指向であり、理想的にはインスピレーションを与えるような意図の表明です。 目標は実際の数字ではなく、大きなアイデアを表します。
- 主要な結果 は、目的を達成するための手順を定義します。 主要な結果は、進捗状況を評価し、特定の期間における目標に対する成功を示す定量化可能な結果です。
OKR は、最も可能性の高い結果だけではなく、可能な限り最良の結果を反映します。 リーダーは慎重ではなく野心的であるように努めます。 チームに挑戦的な重要な結果を追求するよう促すことで、目標の達成が加速され、より大きな目標に向けての作業が優先されます。
OKR フレームワークを採用すると、次の理由からチームのパフォーマンスが向上します。
- すべてのチームは計画に沿って連携しています。
- チームは、活動を完了することよりも成果を達成することに重点を置きます。
- どのチームも定期的に取り組みに対して責任を負います。
OKR は製品のさまざまなレベルに存在する場合があります。 たとえば、トップレベルの製品 OKR、コンポーネント レベルの OKR、チーム レベルの OKR が存在する可能性があります。 特に目標がトップダウンで設定されている場合、OKR を調整し続けることは比較的簡単です。 発生するあらゆる対立は、組織の不整合を示す貴重な初期指標となります。
OKR の例
目的: 強力で満足度の高い顧客ベースを拡大します。
成果指標:
- 外部ネット プロモーター スコア (NPS) を 21 から 35 に増加します。
- ドキュメントの満足度が 55 から 65 に増加します。
- 新しいパイプライン フローの Apdex スコアは 0.9 です。
- ジョブのキュー時間は 5 秒以下です。
OKR の詳細については、「目標と主要な結果を使用してビジネスの成果を測定する」を参照してください。
適切なメトリクスを選ぶ
主要な結果は、そのベースとなる指標と同じくらい役に立ちます。 Microsoft は、変化に焦点を当てた先行指標を使用しています。 時間の経過とともに、これらの指標は製品の加速または減速の実際的な全体像を構築します。 Microsoft は、次の指標をよく使用します。
- 導入月次増加率の推移
- パフォーマンスの変化
- 学習時間の変化
- インシデントの頻度の変化
チームは、目標に対して価値を生まない指標を避けます。 特定の用途があるかもしれませんが、次の指標は目標に向けた進捗状況を追跡するのには役に立ちません。
- 元の見積もりの精度
- 実績時間
- コードの行数
- チーム キャパシティ
- チーム バーンダウン
- チームのベロシティ
- 検出されたバグ数
- コード カバレッジ
アジャイル前とアジャイル後
次の表は、Microsoft 開発チームがアジャイル プラクティスを採用する際に行った変更をまとめたものです。
| 以前 | クリック後 |
|---|---|
| 4～6か月のマイルストーン | 3週間のスプリント |
| 水平チーム | 縦割りチーム |
| 個人事務所 | チームルームとリモートワーク |
| 長い計画サイクル | 継続的な計画と学習 |
| PM、開発、テスト | PM、設計、エンジニアリング |
| 年間の顧客エンゲージメント | 継続的な顧客エンゲージメント |
| 機能ブランチ | 全員が本社で働いています |
| 20人以上のチーム | 8～12人のチーム |
| 秘密のロードマップ | 公開されたロードマップ |
| バグ負債 | 借金ゼロ |
| 100ページの仕様書 | パワーポイントの仕様 |
| プライベートリポジトリ | オープンソースまたはインナーソース |
| 深い組織階層 | フラット化された組織階層 |
| インストール数が成功を定義する | ユーザーの満足度が成功を定義する |
| 機能は年に 1 回出荷されます | 機能はスプリントごとに提供されます |
要点
- アジャイル サイエンスを真剣に受け止めますが、規範的になりすぎないようにしてください。 アジャイルは厳密になりすぎる可能性があります。 アジャイルの考え方と文化を成長させましょう。
- 活動ではなく結果を祝いましょう。 機能のデプロイはコード行よりも重要です。
- スプリントごとに実行してリズムとリズムを確立し、実行する必要があるすべての作業を見つけます。
- 求める行動を実現するための文化を構築します。