/change-request

不明なプレースホルダーが見つかった場合や、どのツールが接続されているか確認する必要がある場合は、CONNECTORS.md をご覧ください。

影響分析、リスク評価、ロールバック計画を含めた構造化された変更要求を作成します。

使用方法

/change-request $ARGUMENTS

変更管理フレームワーク

要求を作成する際に、評価-計画-実行-継続フレームワークを適用してください。

1. 評価

• 何が変わるのか？
• 誰が影響を受けるのか？
• 変更の重要度はどの程度か？（低 / 中 / 高）
• どのような抵抗が予想されるか？

2. 計画

• コミュニケーション計画（誰に、何を、いつ、どのように）
• トレーニング計画（必要なスキル、提供方法）
• サポート計画（ヘルプデスク、チャンピオン、FAQ）
• マイルストーン付きタイムライン

3. 実行

• 「なぜ」を説明し、発表する
• トレーニングとサポートの提供
• 採用状況の監視
• 抵抗への対応

4. 継続

• 採用と有効性の測定
• 新しい行動の強化
• 残存する問題への対応
• 教訓の文書化

コミュニケーションの原則

• 何の前になぜを説明する
• 早期かつ頻繁にコミュニケーションを取る
• 複数のチャネルを使用する
• 得られるものだけでなく、失われるものを認識する
• 質問や懸念事項に対する明確な経路を提供する

出力

## 変更要求：[タイトル]
**申請者：** [名前] | **日付：** [日付] | **優先度：** [重大/高/中/低]
**ステータス：** ドラフト | 承認待ち | 承認済み | 進行中 | 完了

### 説明
[何が変わり、なぜ変わるのか]

### ビジネス上の正当性
[この変更が必要な理由 — コスト削減、コンプライアンス、効率化、リスク低減]

### 影響分析
| 領域 | 影響 | 詳細 |
|------|--------|---------|
| ユーザー | [高/中/低/なし] | [誰がどのように影響を受けるか] |
| システム | [高/中/低/なし] | [どのシステムが影響を受けるか] |
| プロセス | [高/中/低/なし] | [ワークフローの変更内容] |
| コスト | [高/中/低/なし] | [予算への影響] |

### リスク評価
| リスク | 可能性 | 影響 | 軽減策 |
|------|-----------|--------|------------|
| [リスク] | [高/中/低] | [高/中/低] | [軽減方法] |

### 実装計画
| ステップ | 担当者 | タイムライン | 依存関係 |
|------|-------|----------|--------------|
| [ステップ] | [担当者] | [日付] | [依存するもの] |

### コミュニケーション計画
| 対象者 | メッセージ | チャネル | タイミング |
|----------|---------|---------|--------|
| [誰] | [伝える内容] | [方法] | [いつ] |

### ロールバック計画
[必要に応じて変更を取り消すための段階的な計画]
- トリガー：[ロールバックするタイミング]
- ステップ：[ロールバック方法]
- 検証：[ロールバックが成功したことを確認する方法]

### 必要な承認
| 承認者 | 役職 | ステータス |
|----------|------|--------|
| [名前] | [役職] | 保留中 |

コネクターが利用可能な場合

ITSM が接続されている場合：

• 変更要求チケットを自動的に作成
• 変更諮問委員会のスケジュールと承認ワークフローを取得

プロジェクトトラッカー が接続されている場合：

• 関連する実装タスクと依存関係にリンク
• マイルストーン対比で変更進捗を追跡

チャット が接続されている場合：

• コミュニケーション計画用のステークホルダー通知を起案
• 関連するチームチャネルに変更更新を投稿

ヒント

1. 影響を具体的に示す — 「全員」は影響評価ではありません。「請求チームの200ユーザー」が該当します。
2. 常にロールバック計画を用意する — 自信があっても、失敗に備えて計画を立ててください。
3. 早期にコミュニケーションを取る — サプライズは抵抗を生みます。事前情報は支持を生みます。