chain-spec-risk-metrics

Chain Spec Risk Metrics

目次

• ワークフロー
• 一般的なパターン
• ガードレール
• クイックリファレンス

概要

このスキルでは、3つの要素を組み合わせて、包括的な計画成果物を作成します。

1. 仕様 - 作成・変更する内容を明確に定義します（範囲、要件、アプローチ、スケジュール）
2. リスク分析 - プレモーテム（「失敗したと想像してください。原因は何ですか？」）を通じて、問題になり得ることを特定し、対策を含むリスク登録簿を作成します
3. 成功指標 - 進捗を追跡し、成功を検証するための測定可能な成果を定義します

使用しない場合： 仕様のみの場合は、one-pager-prd または adr-architecture を使用してください。リスク分析のみの場合は、project-risk-register を使用してください。指標のみの場合は、metrics-tree を使用してください。代替案のブレインストーミングには、brainstorm-diverge-converge を使用してください。

簡単な例：

取り組み： モノリスをマイクロサービスに移行

仕様： 5つのサービス（認証、ユーザー、注文、在庫、決済）に分割し、API ゲートウェイと共有データパターンを導入

リスク：

• サービス間のデータ整合性の問題（高） → 補償処理を伴うサガパターンを実装
• ネットワークホップによるパフォーマンスの低下（中） → 本番トラフィックのパターンを使って負荷テストを実施

指標：

• デプロイ頻度（目標：週10回以上、ベースライン：週2回）
• API の p99 レイテンシー（目標：< 200ms、ベースライン：150ms）
• 平均復旧時間（目標：< 30min、ベースライン：2 hours）

ワークフロー

このチェックリストをコピーして、進捗を記録してください。

Chain Spec Risk Metrics Progress:
- [ ] Step 1: Gather initiative context
- [ ] Step 2: Write comprehensive specification
- [ ] Step 3: Conduct premortem and build risk register
- [ ] Step 4: Define success metrics and instrumentation
- [ ] Step 5: Validate completeness and deliver

ステップ1：取り組みの背景情報を収集する

取り組みの目標、制約（期間／予算／リソース）、ステークホルダー、現状（ベースライン）、望ましい成果についてユーザーに尋ねます。新規構築、移行、機能強化、戦略的変更のどれに該当するかを明確にします。背景情報に関する質問の全一覧は、resources/template.md を参照してください。

ステップ2：包括的な仕様を作成する

範囲（対象／対象外）、アプローチ（アーキテクチャ／方法論）、要件（機能要件／非機能要件）、依存関係、スケジュール、成功基準を網羅した詳細な仕様を作成します。標準的な取り組みには resources/template.md を使用してください。複雑な複数フェーズのプログラムについては、分解手法を説明した resources/methodology.md を参照してください。

ステップ3：プレモーテムを実施し、リスク登録簿を作成する

プレモーテム演習を実施します。「12か月後を想像してください。この取り組みは見事に失敗しました。何が起きたのでしょうか？」技術、運用、組織、外部の各側面からリスクを特定します。各リスクについて、発生可能性、影響、軽減策、担当者を記録します。プレモーテム手法とリスク登録簿の構成のセクションを参照するか、高度なリスク評価手法については resources/methodology.md を参照してください。

ステップ4：成功指標と計測手段を定義する

先行指標（早期の兆候）、遅行指標（成果を測る指標）、犠牲にしてはならないものを示すカウンター指標を特定します。各指標について、現在のベースライン、目標値、測定方法、追跡頻度を指定します。指標フレームワークを参照し、標準的な構成には resources/template.md を使用してください。

ステップ5：完全性を検証して成果物を提出する

resources/evaluators/rubric_chain_spec_risk_metrics.json を使って、成果物全体を自己チェックします。仕様が明確で実行可能であること、リスクが対策とともに網羅されていること、指標が実際の成功を測定していること、3つの要素すべてが相互に補強し合っていることを確認します。最低基準：すべての評価基準の平均スコアが3.5以上であること。

一般的なパターン

プレモーテム手法

1. 状況を設定する：「今から［6/12/24］か月後です。この取り組みは壊滅的な失敗に終わりました。」
2. 失敗の原因をブレインストーミングする：各ステークホルダーが、失敗した理由を3～5個書き出します（まずは個別に行います）
3. 分類して優先順位を付ける：似た失敗をグループ化し、発生可能性と影響度について投票します
4. リスク登録簿にまとめる：各失敗モードを、軽減計画を伴うリスクとして記録します

リスク登録簿の構成

特定した各リスクについて、以下を記録します。

• リスクの説明：具体的な失敗モード（漠然とした「プロジェクトの遅延」ではありません）
• カテゴリー：技術、運用、組織、外部
• 発生可能性：低／中／高（または確率％）
• 影響度：低／中／高（またはコストの見積もり）
• 軽減策：発生可能性または影響度を下げるために実施すること
• 担当者：このリスクを監視し、対応する人
• ステータス：未対応、軽減済み、受容済み、完了

メトリクスのフレームワーク

先行指標（将来の成功を予測します）：

• デプロイ頻度、コードレビューの速度、インシデントの検出時間

遅行指標（成果を測定します）：

• 稼働時間、ユーザーの利用状況、収益への影響、顧客満足度

カウンターメトリクス（犠牲にすることを認めないもの）：

• コード品質、チームの士気、セキュリティ体制、ユーザーのプライバシー

ガードレール

• どの要素も省略しない - リスクのない仕様には盲点があり、メトリクスのないリスクには未検証の軽減策が残ります
• 仕様を具体的にする - 「パフォーマンスを改善する」は仕様ではありません。「API の p99 レイテンシを 500ms から 200ms に短縮する」は仕様です
• リスクを定量化する - 発生可能性 × 影響度のスコアを使って優先順位を付け、すべてのリスクを同等に扱わないでください
• メトリクスを測定可能にする - 「UX を改善する」は測定できません。「チェックアウト完了率を 67% から 75% に引き上げる」は測定できます
• 担当者を割り当てる - すべてのリスクとメトリクスに、監視して対応する明確な担当者が必要です
• 前提を明示する - リソース、スケジュール、依存関係についての前提を文書化します
• カウンターメトリクスを含める - 成功のために犠牲にしてはならないものを必ず定義します
• 学びに応じて更新する - これは更新し続けるドキュメントです。マイルストーンの後に見直し、リスクやメトリクスを更新します

クイックリファレンス

コンポーネント	使用する場面	リソース
テンプレート	既知のパターンがある標準的な取り組み	resources/template.md
方法論	複雑な多段階プログラム、新たなリスクがある場合	resources/methodology.md
例	優れた内容の例を確認する	resources/examples/
評価基準	提出前に検証する	resources/evaluators/rubric_chain_spec_risk_metrics.json