Scrumを用いたALM：.NET チームのための実践ガイド

ALMは単なるツールではありません — それは規律です

アプリケーションライフサイクル管理（ALM）は、ソフトウェアを構想から廃棄まで管理するエンドツーエンドの規律です。.NET チームにとって、ALMは要件収集、アーキテクチャ、開発、テスト、デプロイ、保守、ガバナンスにまたがり、そのすべてが定義されたプロセスを通じて調整されます。

Scrumは反復的なフレームワークを提供します。ALMは規律を提供します。両者を組み合わせることで、.NET チームはアイデアから本番環境までの再現可能な道筋を得られます — しかもあらゆる段階で可視性を保ちながら。

本ガイドは、Scrumによる15年以上の.NET プロジェクト提供実績に基づいています。ライフサイクル全体、ツールの選択（Azure DevOps、GitHub、Visual Studio）、そしてデリバリーの成功を実際に予測する指標 — 見せかけの指標ではなく — を扱います。

ALMフレームワーク：5つのフェーズ、1つのリズム

ALMはソフトウェアデリバリーを、Scrumのケイデンスに直接対応する5つの相互に連携したフェーズに分解します：

重要な洞察：ALMのフェーズは順次的なウォーターフォールではありません。各スプリント内で並行して進行します。スプリントの終わりには、単なる「コード完成」ではなく、動作しテスト済みで、出荷可能な可能性のあるソフトウェアが手元にあります。

フェーズ1：実際に機能する要件と計画

プロダクトバックログ：単なるリスト以上のもの

健全なプロダクトバックログは、効果的なALMの基盤です。.NET チームにとって、各バックログ項目には次を含めるべきです：

• ユーザーストーリー：「[役割]として、[成果]のために[機能]が欲しい。」
• 受け入れ基準：「完了」を定義する、具体的でテスト可能な条件。明確にするためGiven/When/Then形式を使いましょう。
• 技術メモ：アーキテクチャの決定、データベーススキーマの変更、API契約、NuGetパッケージへの影響。
• 見積り：ストーリーポイントまたは理想時間。時間ではなく、複雑さ、労力、不確実性に基づくストーリーポイントを推奨します。
• 依存関係：この項目が依存する他のバックログ項目、外部サービス、サードパーティAPI、インフラの変更。

スプリントプランニング：コミットメントの会議

スプリントプランニングには2つのパートがあります：

パート1 — 何を：プロダクトオーナーが最優先のバックログ項目を提示します。チームは明確化のための質問をし、スコープを交渉します。アウトプット：スプリントゴール — スプリントが何を提供するかを一文で要約したもの。

パート2 — どのように：チームは各バックログ項目をタスク（通常はそれぞれ2〜8時間）に分解します。.NET プロジェクトでは、タスクにはしばしば次が含まれます：データベースマイグレーション、APIエンドポイントの実装、サービス層、単体テスト、統合テスト、フロントエンドコンポーネント、コードレビュー、ドキュメント更新。

避けるべき計画のアンチパターン：

• 「機能Xのコードを書く」のようなタスク — 曖昧すぎます。具体的な成果物に分解しましょう。
• 100%のキャパシティ計画 — 計画外の作業、バグ、コラボレーションのために20〜30%のバッファを残しましょう。
• 技術的負債の無視 — スプリントごとに少なくとも1つのバックログ項目をリファクタリングや負債削減に割り当てましょう。

フェーズ2：開発 — コードとプロセスが交わる場所

.NET チームのためのブランチ戦略

短命のフィーチャーブランチを用いたトランクベース開発モデルを推奨します：

master (always deployable)
  └── feature/dotnet9-migration (1-3 days)
  └── feature/payment-plugin-pix (1-3 days)
  └── fix/checkout-null-reference (hours)

ルール：

• 最新のmasterから分岐し、最大3日以内にマージバックする。
• 機能またはバグごとに1つのPR。小さなPRはより速くレビューされ、より早くマージされます。
• 各PRはレビュー前にCI（ビルド＋テスト）に合格しなければならない。
• 少なくとも1つの承認を必須にする。すべてのレビューコメントはマージ前に対応しなければならない。
• スカッシュマージでmasterの履歴をクリーンに保つ。

.NET のためのコードレビュー基準

コードレビューでは次を確認すべきです：

• 正確性：コードは受け入れ基準を実装しているか。エッジケースは処理されているか。
• セキュリティ：ハードコードされたシークレットがないこと。入力検証。SQLインジェクションの防止。エンドポイントでの適切な認証チェック。
• パフォーマンス：N+1クエリがないこと。最後まで非同期。適切なキャッシング。コネクションプーリング。
• テスト容易性：ロジックは静的メソッドやコントローラーではなく、注入可能なサービスにあること。依存関係はインターフェースの背後に抽象化されていること。
• 規約：プロジェクトの命名規約、フォルダ構造、コーディング標準に従っていること。

デイリースクラム：状況報告ではありません

デイリースクラムは調整の会議であり、マイクロマネジメントのツールではありません。各メンバーは次に答えます：昨日何を完了したか、今日何を完了するか、何が妨げになっているか。妨げが発生したら、スクラムマスターがそれを解決します — デイリースクラムの外で。会議は45分ではなく15分で終えるべきです。

フェーズ3：継続的インテグレーション — すべてを自動化する

.NET プロジェクトのためのCIパイプライン

フィーチャーブランチへのすべてのコミットは、次をトリガーすべきです：

1. 復元：dotnet restore — NuGetの依存関係を解決します。速度のためパッケージをキャッシュしましょう。
2. ビルド：dotnet build --configuration Release --no-restore — 最適化してコンパイルします。警告をエラーとして扱いましょう。
3. テスト：dotnet test --no-build --configuration Release — すべての単体テストと統合テストを実行します。テスト失敗時にはビルドを失敗させましょう。
4. 解析：StyleCop、SonarQube、または.NET アナライザーを実行します。新しい警告が導入された場合はマージをブロックしましょう。
5. パッケージング：ライブラリの場合はdotnet pack。アプリケーションの場合はdotnet publish。Dockerの場合はdocker build。

例：Azure DevOps YAMLパイプライン

trigger:
  branches:
    include:
      - master
      - feature/*
      - fix/*

pool:
  vmImage: 'ubuntu-latest'

variables:
  buildConfiguration: 'Release'

steps:
- task: UseDotNet@2
  inputs:
    version: '9.x'

- script: dotnet restore
  displayName: 'Restore packages'

- script: dotnet build --configuration $(buildConfiguration) --no-restore
  displayName: 'Build solution'

- script: dotnet test --no-build --configuration $(buildConfiguration) --collect:"XPlat Code Coverage"
  displayName: 'Run tests'

- task: PublishCodeCoverageResults@1
  inputs:
    codeCoverageTool: 'Cobertura'
    summaryFileLocation: '$(Agent.TempDirectory)/**/coverage.cobertura.xml'

ビルド検証テスト（BVT）

単体テストに加えて、CIの一部として実行される少数のスモークテストを含めましょう — アプリケーションが起動すること、データベースが接続すること、主要なAPIエンドポイントが200を返すこと、重要なユーザージャーニーが機能することを検証します。これらは、単体テストでは見えない環境や構成の問題を捕捉します。

フェーズ4：テストと品質 — 「私のマシンでは動く」を超えて

.NET テストピラミッド

テストの原則：確信を得られる最も低いレベルでテストを書きましょう。すべての機能にE2Eテストが必要なわけではありません — よくテストされたサービス層とデータベース層の統合テストがあれば、ブラウザ自動化よりも速く確実にほとんどのバグを捕捉できます。

スプリントレビュー：動作するソフトウェアをデモする

スプリントレビューは、スライドデッキではなく、動作しテスト済みのソフトウェアのデモンストレーションです。ユーザーに見えるとおりに機能を見せましょう。フィードバックを直接収集します。学んだことに基づいてバックログを更新します。機能がデモできないなら、それは完了していなかったということです。

フェーズ5：リリースと運用 — 完了からデプロイまで

.NET のためのリリース管理

リリースは退屈であるべきです — 自動化され、予測可能で、可逆的に。SplatDevで使っているフローは次のとおりです：

1. バージョンの引き上げ：セマンティックバージョニング（MAJOR.MINOR.PATCH）。リリース時ではなく、機能が着地したスプリント中に引き上げましょう。
2. リリースブランチ：バージョンタグを付けてmasterから切り出します。ホットフィックスのみがリリースブランチにマージされます。
3. ステージングへのデプロイ：本番環境を反映したステージング環境への自動デプロイ。回帰テストスイートを実行します。
4. スモークテスト：ステージングでの重要な経路の手動検証。スクリーンショットの証跡を取得します。
5. 本番へのデプロイ：ブルーグリーンまたはカナリアデプロイ。デプロイ後30分間、エラー率、応答時間、ビジネス指標を監視します。
6. デプロイ後の検証：リリースチェックリストに照らしてデプロイを確認します。リリースノートを更新します。

監視：ユーザーに言われる前に知る

本番環境の監視はALMの一部です — デプロイして終わりではなく、システムが健全であることを確認して初めて完了です。.NET アプリケーションの主要な指標：

• アプリケーションエラー：未処理の例外、500応答。即座にアラートを出しましょう。
• 応答時間：エンドポイントごとのP50、P95、P99レイテンシ。劣化時にアラートを出しましょう。
• スループット：1秒あたりのリクエスト数。異常時にアラートを出しましょう。
• リソース使用量：CPU、メモリ、GCの一時停止、スレッドプールの枯渇。リークに注意しましょう。
• ビジネス指標：発注数、処理された支払い、完了したサインアップ。これらこそが本当の健全性の指標です。

.NET の監視にはApplication Insights（Azure）、Datadog、またはPrometheus + Grafanaを使いましょう。構造化ログシステム（Serilog + Seq/Elasticsearch）にログを出力します — 本番のコンソール出力からデバッグしてはいけません。

実際に成功を予測するScrum指標

ほとんどのScrum指標は見せかけです。デリバリーの成果と相関するものは次のとおりです：

リードタイムとサイクルタイム

リードタイム：バックログ項目の作成からデプロイまでの時間。サイクルタイム：作業開始からデプロイまでの時間。短いほど常に良い — より小さなバッチ、より速いフィードバック、より少ない仕掛かり作業を意味します。目標：ほとんどの項目でサイクルタイムを5日未満に。

スプリントバーンダウン（注意して）

バーンダウンチャートは、残作業と時間の関係を示します。スプリント前半でフラットなバーンダウンが続き、終盤で急落する場合、チームが作業を遅く終わらせており、漸進的に提供していないことを意味します。理想的なバーンダウンは安定しています — 作業は終盤だけでなく、スプリント全体を通じて完了します。

流出欠陥

もっと早く捕捉されるべきだった、本番環境で見つかったバグ。これは単一で最も重要な品質指標です。流出欠陥数がゼロに向かっていないなら、あなたの完了の定義かテスト戦略が不十分です。

デプロイ頻度

本番環境へデプロイする頻度。卓越したパフォーマーは1日に複数回デプロイします。ほとんどの.NET チームにとって、少なくともスプリントごとに1回デプロイするのが良い目標です。デプロイ頻度がそれより低いなら、リスクをまとめすぎています。

スプリントレトロスペクティブ：実際に物事を変えるフィードバックループ

レトロスペクティブは最も重要なScrumのセレモニーであり — そして最も頻繁にスキップされるものです。毎スプリント実施しましょう。3つの質問をします：何がうまくいったか、何がうまくいかなかったか、次のスプリントで何を変えるか。そして — 決定的に重要なこととして — 1つのアクションアイテムを選び、それを実行します。同じ問題をスプリントごとに議論して何も変えないことほど、レトロスペクティブの価値を早く損なうものはありません。

ツール：.NET ALMスタック

Azure DevOps（エンタープライズ.NET チームに推奨）

Azure DevOpsは統合されたALMスイートを提供します：Azure Boards（バックログ管理、スプリントプランニング、ボード）、Azure Repos（ブランチポリシー付きのGitホスティング）、Azure Pipelines（一級の.NET サポートを備えたCI/CD）、Azure Test Plans（手動および探索的テスト）、Azure Artifacts（NuGetパッケージのホスティング）。すでにAzure上にあるチームにとって、統合はシームレスです。

GitHub + GitHub Actions（オープンソースおよびモダンなチームに推奨）

GitHubは、バックログ管理のためのProjects、作業追跡のためのIssues、CI/CDのためのActions、NuGetホスティングのためのPackagesを提供します。GitHub Advanced Securityは、コードスキャン、シークレットスキャン、依存関係レビューを追加します。Azure Boardsの深さを必要としないチームにとって、GitHubはよりシンプルで、より開発者に焦点を当てた体験を提供します。

Visual Studio + VS Code

Visual Studio Enterpriseには、ALM機能が含まれます：アーキテクチャ図、IntelliTest（自動テスト生成）、ライブ依存関係検証、コードクローン検出。これらのツールを重視するチームにとって、Enterpriseライセンスはデバッグ時間の削減によって元が取れます。

始めましょう：30日間のALM実装計画

1. 第1週：ツールチェーンをセットアップします — Azure DevOpsまたはGitHub、CIパイプライン、テストフレームワーク。完了の定義を定めます。
2. 第2週：プロダクトバックログを埋めます。最初のスプリントプランニングを実施します。デイリースクラムのリズムを確立します。
3. 第3週：最初のスプリントを完了します。動作するソフトウェアをデモします。レトロスペクティブを実施します。サイクルタイムと流出欠陥のベースラインを測定します。
4. 第4週：本番環境へデプロイします（ポリシーで求められる場合はステージングへ）。指標をレビューします。レトロスペクティブに基づいてプロセスを調整します。繰り返します。

目標は完璧なScrumではありません — 動作するソフトウェアを予測可能かつ可視的に生み出すプロセスです。シンプルに始め、すべてを測定し、漸進的に改善しましょう。

SplatDevはALM + Scrumでどのように提供するか

私たちは2009年から.NET プロジェクトを提供してきました — Scrumが主流になる前、Azure DevOpsが存在する前からです。私たちのALMコンサルティングは、本ガイドで説明した実践をチームが導入するのを支援します：バックログ管理、スプリントの規律、CI/CDパイプラインのセットアップ、テスト自動化、リリース管理。

私たちはあらゆる規模の.NET チームにALMコンサルティングを提供します — 3人のスタートアップから50人のエンタープライズチームまで。私たちの支援には通常、次が含まれます：プロセス評価、ツールのセットアップ、スプリントコーチング（あなたのチームと並行して2〜3スプリントを実施します）、そして自立への移行。

より速く、より少ないバグとより少ないストレスで.NET ソフトウェアを出荷したいですか？あなたの現在のプロセスと、ALM + Scrumが最大のインパクトを与えられる場所について話しましょう。

ALMコンサルティングを受ける

またはお問い合わせください：[email protected]