大規模システムリプレース・移行プロジェクトについて、マルチベンダー管理に長けたPMOの視点で「見落とされがちな潜在リスク」を洗い出す。正常系設計や特定ベンダーの担当範囲内には現れにくい「ベンダー間の隙間」「業務影響」「異常系」の死角を、4視点の分析フレームワークで特定し、Backlog起票用のリスク表とキラークエスチョンを生成する。
要件定義・運用設計・負荷試験フェーズ特化フレームワークへの切替にも対応。総合テスト終盤・移行リハーサル前・負荷試験計画時のリスク総ざらいに使用する。
Do NOT use for 個別インシデントの根本原因分析（incident-rca）、要求の追加・変更・矛盾検証（requirement-management）、運用設計書そのものの新規作成（operations-design）。
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
大規模システムリプレース・システム移行プロジェクトについて、マルチベンダー管理とリスクマネジメントに長けたPMOの視点で、現在見落とされている潜在的リスクを徹底的に洗い出します。
このスキルは以下を提供します:
| 入力 | 必須/任意 | 説明 |
|---|---|---|
| プロジェクト概要 | 必須 | システム名、リプレース・移行の目的 |
| 移行方式・停止想定 | 必須 | 一斉切替/順次移行/計画停止の有無と期間等 |
| 参画ベンダーと役割 | 必須 | 自社PM、各ベンダーの担当範囲 |
| 現在の状況・フェーズ | 必須 | 要件定義中/総合テスト終盤/移行リハーサル前 等 |
| 分析対象データ | 必須 | Backlogタスク一覧、課題リスト、WBS、懸念点のメモ等 |
| 分析フレームワーク種別 | 任意 | 汎用/要件定義特化/運用設計特化/負荷試験特化/カスタム（未指定の場合は汎用） |
| 出力 | 形式 | 説明 |
|---|---|---|
| リスク監査レポート | Markdown | フレームワークごとのリスク表＋キラークエスチョン3件 |
このスキルが行うこと:
このスキルが行わないこと:
「移行リスクを洗い出したい」「見落としているリスクがないか監査してほしい」などと依頼されたら、以下の手順で進めます。1フェーズ1応答の原則に従い、各ステップ完了ごとに結果を報告してください。
[project-phase-risk-audit] ステップ 1/5: 分析フレームワークの選択
【重要】AskUserQuestionツールを使用して選択させること
現在のプロジェクトフェーズに応じて、適用するフレームワークを選びます。
回答に応じて、次の参照ファイルをこのタイミングで初めて読み込みます（事前一括読み込みはしない）:
| 選択 | 読み込むファイル |
|---|---|
| 汎用 | 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視点の名称と観点を質問し、その場で組み立てる |
[project-phase-risk-audit] ステップ 2/5: プロジェクト前提条件のヒアリング
以下の4項目を確認します。1つでも不明な情報があれば、推測せず必ずAskUserQuestionツールで質問すること（CLAUDE.mdの「情報の明確性」原則に従う）。
「明示された情報」と「不明な情報」を分けて整理し、不明な情報は質問で埋めてから次のステップに進みます。
[project-phase-risk-audit] ステップ 3/5: 分析対象データの収集
Backlogのタスク一覧、課題リスト、WBS、または現状のモヤモヤしている懸念点をテキストで提供してもらいます。ユーザーがファイルパスを示した場合はReadツールで読み込みます。データが極端に大量な場合は、要点を要約してから分析に進んでよいことをユーザーに伝えます。
[project-phase-risk-audit] ステップ 4/5: フレームワークに沿った死角の分析
ステップ1で選択または組み立てた4視点（参照ファイルを読み込んだ場合はその4視点、カスタムの場合はユーザー回答から組み立てた4視点）それぞれについて、本プロジェクト特有の「極めて漏れやすく、かつ重大な影響を及ぼす潜在リスク」を2つずつ特定します。
分析時の心構え（重要）:
assets/templates/risk_audit_report_template_ja.md を読み込み、そのフォーマットに沿って、視点ごとに以下の表を作成します。
| 潜在リスク（死角） | なぜ危険か（放置した場合の最悪のシナリオ） | 起票すべき具体的なタスク名 | 期待される主担当（役割） |
|---|
負荷試験フェーズ特化を選択した場合は、references/framework_load_test_phase_ja.mdの「出力時の表現調整」に従い、2列目の見出しを「なぜ危険か（本番で発生した場合の最悪のシナリオ）」、3列目を「起票すべき具体的な検証タスク・確認事項」に読み替えます。
[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視点）で代替して手動作成に切り替えます。
framework_general_ja.md: 汎用フレームワーク（データライフサイクルと異常系／周辺アクター／時間軸の境界／マルチベンダー責任分界点）framework_requirements_phase_ja.md: 要件定義フェーズ特化フレームワーク（現行仕様のブラックボックス化と非互換性／非機能要件とパフォーマンス制限／データ移行要件／セキュリティと監査要件）framework_operations_phase_ja.md: 運用設計フェーズ特化フレームワーク（障害時の責任分界点・一次切り分け／日常運用のプロセス・権限／計画停止・パッチ適用／BCP・バックアップ復旧）framework_load_test_phase_ja.md: 負荷試験フェーズ特化フレームワーク（シナリオの現実性と突発的スパイク／マルチベンダー連携と境界ボトルネック／本番同等のデータ状態とキャッシュ／限界突破時の挙動と縮退運転）risk_audit_report_template_ja.md: リスク監査レポートテンプレート（フレームワーク別リスク表＋キラークエスチョン）No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
指定されたPRを6観点（セキュリティ、ドキュメント乖離、可読性、ライブラリ選定、PR説明、既知脆弱性）でレビューし、人間向け・AI向けの2形式でPRにコメントする。初回レビューおよび修正後の再レビューに使用する。Do NOT use for レビューコメントへの修正適用（pr-comment-fixerを使用すること）。
The English summary is being prepared. Showing the original description.
キャリア設計のためのデプスインタビューを実施し、本人の価値観・強み・動機を引き出す。5 Whys、ラダリング法を用いてキャリアビジョンの明確化を支援する。転職相談、自己理解、キャリアカウンセリング、1on1面談の深掘りに使用する。Do NOT use for 製品・サービスのユーザーリサーチ（depth-interviewing-productを使用すること）。
The English summary is being prepared. Showing the original description.
サービス開発のためのデプスインタビューを実施し、ユーザーの真のニーズ・課題・動機を引き出す。5 Whys、ラダリング法を用いてプロダクト開発に活かせるインサイトを発見する。ユーザーリサーチ、課題発見、ペルソナ構築、プロダクト仮説検証に使用する。Do NOT use for キャリア相談やキャリアカウンセリング（depth-interviewing-careerを使用すること）。
The English summary is being prepared. Showing the original description.
インフラメトリクスの定期調査を体系的に実施し、サービスの健全性を評価する。2層アプローチで11カテゴリのメトリクスを確認し、構造化レポートを作成する。定期的なサービス監視、障害予兆の検出、パフォーマンス評価に使用する。Do NOT use for 個別インシデントの根本原因分析（incident-rcaを使用すること）。
The English summary is being prepared. Showing the original description.
インシデント調査で根本原因を特定するためのなぜなぜ分析ファシリテーター。推測を避け、ユーザーの発言を記録し、マインドツリーで全体を可視化する。障害発生後の原因究明、ポストモーテム、再発防止策の策定に使用する。Do NOT use for 定期的なサービス健全性チェック（health-checkを使用すること）。
The English summary is being prepared. Showing the original description.
IPA非機能要求グレード2018（可用性・性能拡張性・運用保守性・移行性・セキュリティ・システム環境）の記入済み要件を入力として、運用設計書を生成する。非機能要件定義が完了しているプロジェクトの運用設計フェーズで使用する。Do NOT use for 非機能要件の定義自体（requirement-managementを使用すること）。Do NOT use for 業界調査やヒアリングから始める運用設計（operations-designを使用すること）。
The English summary is being prepared. Showing the original description.