Microsoft が DevOps を使用して計画する方法

Microsoft は、アジャイル手法を使用する世界最大の企業の 1 つです。 長年の経験から、Microsoft は、最小のプロジェクトから Windows などの大規模な取り組みまで拡張する DevOps 計画プロセスを開発してきました。 この記事では、会社全体でソフトウェア プロジェクトを計画するときに Microsoft が実装する教訓とプラクティスの多くについて説明します。

インストルメント的な変更

次の重要な変更は、開発サイクルと出荷サイクルの正常性と効率を高めるのに役立ちます。

• 文化的な整合と自律性を促進する。
• フォーカスを個人からチームに変更します。
• 新しい計画と学習戦略を作成します。
• マルチクルー モデルを実装します。
• コードの健全性実践を改善します。
• 透明性と説明責任を促進します。

文化の整合と自律性を促進する

ピーター・ドロッカーは「文化は朝食のための戦略を食べる」と言いました。自律性、習得性、目的は人間の主な動機です。 Microsoft は、これらの動機を VM、開発者、デザイナーに提供し、成功した製品を構築する権限を持つよう努めています。

このアプローチの 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クルーはライブサイトの問題と中断を扱います。 チームは、メンバーがより簡単にアクティビティを計画できるローテーションの頻度を確立します。 マルチクルー モデルの詳細については、「生産性の高 い顧客重視のチームを構築する」を参照してください。

コード健全性の手法を改善する

アジャイル手法に切り替える前は、チームは開発フェーズの終わりにコードが完成するまでバグを放置していました。 その後、Teams はバグを検出し、修正に取り組んだ。 このプラクティスでは、バグのジェットコースターが作成されました。これは、チームが新機能を実装するのではなく、バグ修正に取り組む必要があるときのチームの士気と生産性に影響を与えました。

Teams では、数式によって計算される# of engineers x 5 = bug capが実装されるようになりました。 チームのバグ数がスプリントの終了時にバグ上限を超えた場合は、新機能の作業を停止し、上限に達するまでバグを修正する必要があります。 チームはバグ負債を解消していくようになりました。

透明性と説明責任を促進する

各スプリントの最後に、すべてのチームは、前のスプリントで達成したことと、次のスプリントで何を行う予定かを報告するメールを送信します。

目標と主要な結果 (OKR)

チームは、組織が達成しようとしている目標が明確な場合に最も効果的です。 Microsoft は 、目標と主要な結果 (OKR) を通じてチームを明確にします。

• 目標は、 達成する目標を定義します。 目標は、重要で具体的で、行動指向であり、理想的にはインスピレーションを与える意図の記述です。 目標は、実際の数値ではなく、大きなアイデアを表します。
• 主要な結果 は、目標を達成するためのステップを定義します。 主要な結果は、進行状況を評価し、特定の期間の目標に対する成功を示す定量化可能な結果です。

OKR は、最も可能性の高い結果だけでなく、可能な限り最良の結果を反映します。 指導者は野心的であり、慎重でないように努める。 チームが困難な重要な結果を追求するようにプッシュすると、目標に対する加速が促進され、より大きな目標に向かって進む作業に優先順位が付けられます。

OKR フレームワークを採用すると、次の理由でチームのパフォーマンスが向上する可能性があります。

• すべてのチームが計画に 沿って配置されます 。
• チームは、アクティビティを完了するのではなく 、成果を達成 することに重点を置く。
• すべてのチームは、定期的に作業に対する 責任 を負います。

OKR は、製品のさまざまなレベルに存在する可能性があります。 たとえば、最上位レベルの製品 OKR、コンポーネント レベルの OKR、チーム レベルの OKR が存在する場合があります。 特に目標がトップダウンに設定されている場合、OKR の配置は比較的簡単です。 発生した競合は、組織のミスアラインメントの貴重な初期の指標です。

OKR の例

目的: 強力で幸せな顧客ベースを成長させる。

主な結果:

• 外部ネット プロモーター スコア (NPS) を 21 から 35 に増やします。
• ドキュメントの満足度を55から65に上げます。
• 新しいパイプライン フローの Apdex スコアは 0.9 です。
• ジョブのキュー時間は 5 秒以下です。

OKR の詳細については、「 目標と主要な結果を使用してビジネス成果を測定する」を参照してください。

適切なメトリックを選択する

主要な結果は、基になっているメトリックと同じくらい役に立ちます。 Microsoft では、変化に重点を置く主要なインジケーターを使用しています。 時間の経過とともに、これらのメトリックは、製品の加速または減速の動作画像を構築します。 Microsoft では、多くの場合、次のメトリックが使用されます。

• 導入の月次成長率の変化
• パフォーマンスの変更
• 学習時間の変更
• インシデントの頻度の変化

チームは、目標に対して価値を生み出さないメトリックを回避します。 特定の用途がある場合もありますが、次のメトリックは目標に向けた進行状況を追跡するのに役立ちません。

• 元の見積もりの精度
• 完了した時間
• コード行
• チーム容量
• チームバーンダウン
• チームの進捗速度
• 検出されたバグの数
• コード カバレッジ

アジャイルの前とアジャイル後

次の表は、アジャイル プラクティスを採用した Microsoft 開発チームが行った変更をまとめたものです。

重要なポイント

• アジャイル サイエンスを真剣に受け止めていますが、過度に規範的にしないでください。 アジャイルが厳しくなりすぎる可能性があります。 アジャイルの考え方と文化を成長させましょう。
• アクティビティではなく、結果を祝います。 機能のデプロイは、コード行を上回ります。
• リズムと周期を確立し、行う必要があるすべての作業を見つけるために、すべてのスプリントで出荷します。
• あなたが求めている行動を得るために、望む文化を築き上げましょう。