無料GitHub で公開

project-phase-risk-audit

大規模システムリプレース・移行プロジェクトについて、マルチベンダー管理に長けたPMOの視点で「見落とされがちな潜在リスク」を洗い出す。正常系設計や特定ベンダーの担当範囲内には現れにくい「ベンダー間の隙間」「業務影響」「異常系」の死角を、4視点の分析フレームワークで特定し、Backlog起票用のリスク表とキラークエスチョンを生成する。

要件定義・運用設計・負荷試験フェーズ特化フレームワークへの切替にも対応。総合テスト終盤・移行リハーサル前・負荷試験計画時のリスク総ざらいに使用する。

Do NOT use for 個別インシデントの根本原因分析（incident-rca）、要求の追加・変更・矛盾検証（requirement-management）、運用設計書そのものの新規作成（operations-design）。

windschord/claude_skils

インストール方法を見る

含まれるファイル（6）

SKILL.md12.8 KB
assets/templates/risk_audit_report_template_ja.md2.1 KB
references/framework_general_ja.md2.5 KB
references/framework_load_test_phase_ja.md4.5 KB
references/framework_operations_phase_ja.md3.0 KB
references/framework_requirements_phase_ja.md2.7 KB

SKILL.md（原文）

インストールする前に、エージェントに与えられる指示の中身を確認できます。

プロジェクトフェーズ別リスク監査（PMO視点）スキル

大規模システムリプレース・システム移行プロジェクトについて、マルチベンダー管理とリスクマネジメントに長けたPMOの視点で、現在見落とされている潜在的リスクを徹底的に洗い出します。

概要

このスキルは以下を提供します:

プロジェクト前提条件（概要・移行方式・参画ベンダー・現状フェーズ）の体系的なヒアリング
フェーズに応じた4視点の分析フレームワーク（汎用 / 要件定義特化 / 運用設計特化 / 負荷試験特化）
「ベンダー間の隙間」「業務影響」「異常系」など、正常系設計や特定ベンダー担当範囲の死角の特定
選択したフレームワークの4視点それぞれについて2件ずつ（計8件）、Backlog起票用のリスク・タスク表を生成
関係者定例会議向けの「キラークエスチョン」3件の生成

入力・出力・責務

入力（Inputs）

入力	必須/任意	説明
プロジェクト概要	必須	システム名、リプレース・移行の目的
移行方式・停止想定	必須	一斉切替/順次移行/計画停止の有無と期間等
参画ベンダーと役割	必須	自社PM、各ベンダーの担当範囲
現在の状況・フェーズ	必須	要件定義中/総合テスト終盤/移行リハーサル前等
分析対象データ	必須	Backlogタスク一覧、課題リスト、WBS、懸念点のメモ等
分析フレームワーク種別	任意	汎用/要件定義特化/運用設計特化/負荷試験特化/カスタム（未指定の場合は汎用）

出力（Outputs）

出力	形式	説明
リスク監査レポート	Markdown	フレームワークごとのリスク表＋キラークエスチョン3件

責務（Responsibilities）

このスキルが行うこと:

プロジェクト前提条件と分析対象データのヒアリング
フェーズに応じた分析フレームワークの選択と適用
死角リスクの特定とBacklog起票用タスク案への変換
キラークエスチョンの生成

このスキルが行わないこと:

要求・要件そのものの定義や矛盾検証（requirement-managementの領分）
運用設計書自体の新規作成（operations-design / ipa-nfr-operations-designの領分）
個別インシデントのなぜなぜ分析（incident-rcaの領分）
Backlog/課題管理ツールへの自動起票（出力はタスク案の提示までで、実際の起票はユーザーが実施）

このスキルを使用する場面

移行リハーサル前・本番切替前に、抜け漏れているリスクを総ざらいしたい場合
総合テスト終盤で、正常系は固まったが異常系や周辺業務への影響が不安な場合
要件定義フェーズで、既存仕様のブラックボックス化やFit&Gapの見落としが心配な場合
運用設計フェーズで、マルチベンダー環境の障害切り分け・責任分界に不安がある場合
負荷試験の計画段階・実施直前で、単一システムの性能テストでは見えない連鎖障害や限界突破時の挙動が不安な場合
関係者定例会議で、ベンダー間の押し付け合いを防ぐ建設的な問いかけを用意したい場合

基本的な使い方

「移行リスクを洗い出したい」「見落としているリスクがないか監査してほしい」などと依頼されたら、以下の手順で進めます。1フェーズ1応答の原則に従い、各ステップ完了ごとに結果を報告してください。

ステップ1: 分析フレームワークの選択

[project-phase-risk-audit] ステップ 1/5: 分析フレームワークの選択

【重要】AskUserQuestionツールを使用して選択させること

現在のプロジェクトフェーズに応じて、適用するフレームワークを選びます。

汎用（移行実行フェーズ向け）: 総合テスト終盤・移行リハーサル前などの実行フェーズに適した4視点（データライフサイクルと異常系／周辺アクター／時間軸の境界／マルチベンダー責任分界点）。デフォルト。
要件定義フェーズ特化: 現行仕様のブラックボックス化・非機能要件・データ移行要件・セキュリティ監査要件の4視点。
運用設計フェーズ特化: 障害時責任分界・日常運用プロセス・計画停止/パッチ適用・BCPとバックアップ復旧の4視点。
負荷試験フェーズ特化: シナリオの現実性と突発的スパイク・マルチベンダー連携と境界ボトルネック・本番同等のデータ状態とキャッシュ・限界突破時の挙動と縮退運転の4視点。負荷試験の計画段階・実施直前に使用する。
カスタム: ユーザー独自の4視点を指定してもらう。

回答に応じて、次の参照ファイルをこのタイミングで初めて読み込みます（事前一括読み込みはしない）:

選択	読み込むファイル
汎用	`references/framework_general_ja.md`
要件定義フェーズ特化	`references/framework_requirements_phase_ja.md`
運用設計フェーズ特化	`references/framework_operations_phase_ja.md`
負荷試験フェーズ特化	`references/framework_load_test_phase_ja.md`
カスタム	ユーザーに4視点の名称と観点を質問し、その場で組み立てる

ステップ2: プロジェクト前提条件のヒアリング

[project-phase-risk-audit] ステップ 2/5: プロジェクト前提条件のヒアリング

以下の4項目を確認します。1つでも不明な情報があれば、推測せず必ずAskUserQuestionツールで質問すること（CLAUDE.mdの「情報の明確性」原則に従う）。

プロジェクト概要: システム名、リプレース・移行の目的
移行方式・停止想定: 一斉切替/順次移行/計画停止の有無・期間
参画ベンダーと役割: 自社PM、ベンダーA/B/C…とそれぞれの担当範囲
現在の状況・フェーズ: 要件定義中/総合テスト終盤/移行リハーサル前等

「明示された情報」と「不明な情報」を分けて整理し、不明な情報は質問で埋めてから次のステップに進みます。

ステップ3: 分析対象データの収集

[project-phase-risk-audit] ステップ 3/5: 分析対象データの収集

Backlogのタスク一覧、課題リスト、WBS、または現状のモヤモヤしている懸念点をテキストで提供してもらいます。ユーザーがファイルパスを示した場合はReadツールで読み込みます。データが極端に大量な場合は、要点を要約してから分析に進んでよいことをユーザーに伝えます。

ステップ4: フレームワークに沿った死角の分析

[project-phase-risk-audit] ステップ 4/5: フレームワークに沿った死角の分析

ステップ1で選択または組み立てた4視点（参照ファイルを読み込んだ場合はその4視点、カスタムの場合はユーザー回答から組み立てた4視点）それぞれについて、本プロジェクト特有の「極めて漏れやすく、かつ重大な影響を及ぼす潜在リスク」を2つずつ特定します。

分析時の心構え（重要）:

正常系の設計や、特定ベンダーの担当範囲「内」だけを見ていては気づけない死角を狙う
「ベンダー間の隙間」「業務影響（IT以外のステークホルダー）」「異常系（一部失敗・時間軸の境界）」を優先的に疑う
分析対象データ（Backlog/WBS/懸念点）に既に記載がある項目は除外し、記載が無い／薄い項目を優先する
推測で断定せず、リスクの根拠を分析対象データや一般的な移行プロジェクトの失敗パターンに基づいて示す

assets/templates/risk_audit_report_template_ja.md を読み込み、そのフォーマットに沿って、視点ごとに以下の表を作成します。

潜在リスク（死角）	なぜ危険か（放置した場合の最悪のシナリオ）	起票すべき具体的なタスク名	期待される主担当（役割）

負荷試験フェーズ特化を選択した場合は、references/framework_load_test_phase_ja.mdの「出力時の表現調整」に従い、2列目の見出しを「なぜ危険か（本番で発生した場合の最悪のシナリオ）」、3列目を「起票すべき具体的な検証タスク・確認事項」に読み替えます。

ステップ5: キラークエスチョンの生成とレポート提示

[project-phase-risk-audit] ステップ 5/5: キラークエスチョンの生成とレポート提示

分析結果を踏まえ、PMが次回の関係者定例会議で「このプロジェクト、実はこの部分の考慮がすっぽり抜けていませんか？」と全員の目を覚まさせるための、強烈で具体的な問いかけを3つ作成します。

キラークエスチョンの条件:

抽象論ではなく、本プロジェクトの固有名詞（システム名・ベンダー名・日付・業務名）を含む
「誰が」「いつまでに」「どう対応するか」まで踏み込ませる問いにする
ベンダー間の責任の押し付け合いではなく、建設的な議論を誘発する言い回しにする

assets/templates/risk_audit_report_template_ja.md のフォーマットで完成したレポートを提示し、ユーザーに保存が必要か確認します。保存する場合は docs/risk-audit/[YYYY-MM-DD]-[プロジェクト名]-risk-audit.md として作成することを提案します（保存先はユーザーの指示を優先）。

フォールバック戦略

参照ファイルの読み込みに失敗した場合や、フレームワーク定義が意図通りに反映できない場合は、テンプレート（assets/templates/risk_audit_report_template_ja.md）の表構造だけを直接参照し、ステップ4の分析観点を、選択したフレームワーク定義（カスタムの場合はユーザーが回答した4視点）で代替して手動作成に切り替えます。

リソース

references/

framework_general_ja.md: 汎用フレームワーク（データライフサイクルと異常系／周辺アクター／時間軸の境界／マルチベンダー責任分界点）
framework_requirements_phase_ja.md: 要件定義フェーズ特化フレームワーク（現行仕様のブラックボックス化と非互換性／非機能要件とパフォーマンス制限／データ移行要件／セキュリティと監査要件）
framework_operations_phase_ja.md: 運用設計フェーズ特化フレームワーク（障害時の責任分界点・一次切り分け／日常運用のプロセス・権限／計画停止・パッチ適用／BCP・バックアップ復旧）
framework_load_test_phase_ja.md: 負荷試験フェーズ特化フレームワーク（シナリオの現実性と突発的スパイク／マルチベンダー連携と境界ボトルネック／本番同等のデータ状態とキャッシュ／限界突破時の挙動と縮退運転）

assets/templates/

risk_audit_report_template_ja.md: リスク監査レポートテンプレート（フレームワーク別リスク表＋キラークエスチョン）

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

ログインしてレビューを書く

同じリポジトリのスキル

概要と使いどころ

ai-code-review

無料日本語概要

指定されたPRを6観点（セキュリティ、ドキュメント乖離、可読性、ライブラリ選定、PR説明、既知脆弱性）でレビューし、人間向け・AI向けの2形式でPRにコメントする。初回レビューおよび修正後の再レビューに使用する。Do NOT use for レビューコメントへの修正適用（pr-comment-fixerを使用すること）。