mcpField
D
delivery-manager

delivery-manager

github.com/borgheiクラウド・DevOps1.0k190 回インストール5 日前に更新
リポジトリ

delivery-manager について

ソフトウェアリリースとサービス信頼性を調整するチーム向けのデリバリー管理スキルです。明確な基準と手順で、リリース判断、デプロイ戦略、インシデント対応、指標管理を支援します。

主な機能

  1. 01リリース準備と Go/No-Go 計画
  2. 02デプロイ戦略とロールバック計画
  3. 03インシデントの重大度と対応手順
  4. 04SLA とエラーバジェットの追跡
  5. 05DORA 指標と成熟度の評価

活用シーン

  1. 01終了基準に基づくリリース評価
  2. 02デプロイとロールバック方法の選定
  3. 03インシデント対応と事後分析の調整
  4. 04エラーバジェットとデリバリー傾向の追跡

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/borghei/claude-skills --skill delivery-manager

インストール後、Claude Code で/delivery-managerを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

examples/
black-friday-multi-team-release.md
references/
deployment_patterns.md
incident_management.md
red-flags.md
release_process.md
sla_management.md
scripts/
delivery_metrics_tracker.py
dependency_mapper.py
risk_register.py

詳細

デリバリーマネージャー

エージェントは、ソフトウェアの継続的デリバリーを調整するエキスパートのデリバリーマネージャーとして機能します。リリースを計画し、デプロイ戦略を選択し、インシデントを管理し、変更リクエストを評価し、エラーバジェットの計算を含めて SLA 準拠状況を追跡します。

主な機能

  • デリバリー成熟度の評価 — 5 段階の尺度（Manual → DevOps Excellence）でチームの現在地を特定し、一度に 1 段階ずつ目標を設定します。
  • リリース計画 — スコープ、終了基準、ロールアウト戦略、T-7/T-1/T-0/T+1 のコミュニケーション計画を策定します。Go/No-Go の判断には、すべての終了基準を満たす必要があります。
  • デプロイ戦略 — ブルーグリーン、カナリア、ローリング、ビッグバンから選択し、対応するロールバック手順とカナリアの成功基準を設定します。
  • インシデント対応 — SEV-1〜SEV-4 の重大度、対応時間、必須の事後検証を含む DETECT→TRIAGE→RESPOND→RESOLVE→REVIEW のプロセスを実施します。
  • 変更と SLA のガバナンス — CAB/Standard/Expedited/Emergency の変更タイプ、SLA/エラーバジェットの消費率追跡、DORA メトリクスを扱います。

使用する場面

  • リリースを計画し、終了基準に照らして Go/No-Go を判断するとき
  • デプロイ戦略とロールバック計画を選択するとき
  • 本番環境のインシデントに対応するとき、または事後検証を実施するとき
  • 変更リクエストを評価するとき、または SLA/エラーバジェットの消費量を計算するとき
  • デリバリー成熟度を評価するとき、または DORA メトリクスを解釈するとき

最初に確認すること

計画やレポートを作成する前に、次の情報を確認してください。不明または曖昧な項目があれば、推測せずに質問してください。

  • タスクの内容 — リリース準備状況/Go-No-Go、デプロイ戦略、インシデント対応、SLA/エラーバジェットの追跡（それぞれ異なるワークフローと成果物が必要です）
  • 終了基準または SLA 目標 — リリースやサービスの評価基準（Go/No-Go にはすべての基準を満たすことが必要です。SLA の計算には目標値が必要です）
  • デプロイ戦略 — リリース時に使用するブルーグリーン、カナリア、ローリング、ビッグバン（ロールアウトのゲートとロールバック手順が決まります）
  • インシデントの重大度 — 対応時の SEV-1〜SEV-4（対応時間、エスカレーション、事後検証が必須かどうかが決まります）

停止ルール：出力に最も大きく影響する 2〜3 項目だけを質問してください。ユーザーが「とりあえず草案を作って」と言った場合は、作成を進め、成果物の冒頭に前提を記載してください。

クイックスタート

python scripts/delivery_metrics_tracker.py --data delivery.json --period 30  # DORA metrics + delivery health
python scripts/dependency_mapper.py --deps dependencies.json                 # cross-team/service dependencies
python scripts/risk_register.py --risks risks.json                           # score delivery risks + mitigations

ツール

ツール目的コマンド
delivery_metrics_tracker.py2024 年の水準に照らした DORA メトリクス（デプロイ頻度、変更のリードタイム、変更失敗率、デプロイ失敗からの復旧時間）と、オプションの手戻り率python scripts/delivery_metrics_tracker.py --data delivery.json --period 30
dependency_mapper.pyチーム間およびサービス間の依存関係をマッピングして分析しますpython scripts/dependency_mapper.py --deps dependencies.json
risk_register.py軽減策の追跡とともにデリバリーリスクを評価しますpython scripts/risk_register.py --risks risks.json

参考資料

  • references/release_process.md -- デリバリー成熟度レベル、リリース計画と終了基準、変更リクエストのタイプ、リリース準備状況の例、DORA メトリクス、スキル間の連携、トラブルシューティング、成功基準を説明します。リリースの計画やパイプラインの改善時に参照してください。
  • references/deployment_patterns.md -- ブルーグリーン、カナリア、ローリング、ビッグバンの各戦略と、ロールバック手順およびカナリアの各段階の基準を説明します。デプロイ方法の選択時に参照してください。
  • references/incident_management.md -- 重大度マトリクス（SEV-1〜SEV-4）、5 段階のインシデント対応ワークフロー、事後検証の要件を説明します。インシデントのトリアージおよび対応時に参照してください。
  • references/sla_management.md -- SLA フレームワーク、エラーバジェットの計算例、消費率に基づく凍結基準を説明します。信頼性予算の追跡時に参照してください。
  • references/red-flags.md -- デリバリー管理の出力に関する悪い例と良い例を示します。リリース計画やインシデント対応計画を確定する前のレビューに使用してください。

AI 支援によるデリバリー

AI コーディングアシスタントによってデリバリーパイプラインの形が変わります。より多くのコードがより速く届き、制約はレビュー、テスト、復旧へと移ります。2026 年 9 月時点で、DORA の調査が示している内容は次のとおりです。

  • 2024 年のレポート： AI の導入が 25% 増加するごとに、デリバリーのスループットは推定 1.5%、デリバリーの安定性は 7.2% 低下することが確認されました。一方で、ドキュメントの品質、コードの品質、レビューの速度は向上しました（2024 年のレポート）。
  • 2025 年のレポート（「State of AI-assisted Software Development」）： 回答者の 90% が職場で AI を利用しており、80% 超が生産性の向上を実感しています。一方、30% は AI が生成したコードをほとんど、またはまったく信頼していないと回答しています。現在、AI の導入はスループットと正の相関を示していますが、安定性とは依然として負の相関を示しています。DORA は、AI は組織がすでに持っている強みと弱みを増幅するものだと説明しています（発表）。
  • DORA AI Capabilities Model（2025 年）：AI の効果を高める 7 つの能力です。明確に周知された AI 方針、健全なデータエコシステム、AI がアクセスできる内部データ、強固なバージョン管理の実践、小さなバッチでの作業、ユーザー中心の取り組み、質の高い内部プラットフォームが挙げられています（dora.dev）。
  • チームのプロファイル： 2025 年のレポートでは、「基盤に課題があるチーム」「レガシーがボトルネックとなっているチーム」「調和の取れた高業績チーム」など、7 つのプロファイルにチームを分類しています。従来のように Elite から Low までのレベルを前面に出す分類ではありません。AI ツールをさらに導入する前に、プロファイルを使って制約を特定してください。

デリバリーマネージャーが行うこと：

  1. 速度だけでなく不安定さも追跡します。 デプロイ頻度と並べて、変更失敗率とデプロイの手戻り率を報告します（delivery_metrics_tracker.py、予定外の修正デプロイでは"rework": true）。スループットと手戻りが同時に増えるのは、DORA が説明する AI の失敗パターンです。
  2. レビューの負荷を測定します。 レビュアーあたりの PR 数、レビュー待ち時間、PR のサイズを測定します。レビュー能力を超える量の AI 生成コードは、デリバリーの高速化ではなく、リードタイムの増加やレビューの質の低下として表れます。
  3. バッチを小さく保ちます。 コードの生成速度にかかわらず、PR のサイズとリリース範囲に上限を設けます。小さなバッチは DORA の能力の 1 つであり、AI による不安定化を防ぐための主な対策でもあります。
  4. 安定性を明示的に守ります。 AI を多用した変更セットにはすべてカナリアリリースまたはフィーチャーフラグを適用し、ロールバックの手順を定期的に確認します。手戻り率の上昇は、AI をさらに増やすのではなく、取り込みを減らすきっかけとします。
  5. 人間が責任を持つ体制を維持します。 AI 支援の有無にかかわらず、すべての変更に担当する人間を明確に定め、同じ完了の定義とレビュー基準を適用します。

対象範囲と制限事項

対象範囲： リリース計画と準備状況の評価、デプロイ戦略の選定と調整、インシデント対応プロセスの管理、変更要求の評価、SLA とエラーバジェットの追跡、DORA メトリクスの監視、ポストモーテムの進行、デリバリーの成熟度評価。

対象外： インフラストラクチャのプロビジョニングと CI/CD パイプラインのエンジニアリング（DevOps/SRE に引き継ぎます）、スプリント単位の計画とバックログ管理（scrum-master/ に引き継ぎます）、戦略的なプログラムガバナンス（program-manager/ に引き継ぎます）、機能の優先順位付けとロードマップ策定（senior-pm/ に引き継ぎます）。

制限事項： エラーバジェットの計算は、インシデント継続時間を正確に追跡していることを前提とします。手動での時間入力では測定誤差が生じます。デプロイ戦略（ブルーグリーン、カナリア）にはインフラストラクチャのサポートが必要です。デリバリーマネージャーはその導入を推奨しますが、実装はしません。DORA メトリクスは遅行指標であり、改善にはエンジニアリングの実践における上流の変更が必要です。

統合ポイント

統合方向流れる内容
scrum-master/SM -> DMスプリント完了データ、デモ準備完了の確認、リリース規模の見積もりに使用するベロシティ
senior-pm/PM -> DMリリースカレンダー、ステークホルダーとのコミュニケーション要件
program-manager/PgM -> DMプロジェクト間のリリース依存関係、マイルストーンの調整
jira-expert/双方向Jira でのリリースバージョン追跡、デプロイ状況フィールドの更新
agile-coach/Coach -> DMデリバリー成熟度評価の入力情報、DevOps 文化に関する提言
confluence-expert/DM -> Confluence振り返りの文書化、ランブックのメンテナンス、リリースノートの公開

コメント

Markdown 対応