---

name: impact allowed-tools: Read, mcp__85fb1e59-5e90-4a78-92d2-815933ff6b3e__slack_search_public, mcp__85fb1e59-5e90-4a78-92d2-815933ff6b3e__slack_read_channel description: >- 「何を実現したいか」という生の想いを受け取り、影響の波及経路を設計し、 最適な手段の組み合わせとタイムラインを提案するスキル。パイプラインの最上流。 Use when: (1) /impact コマンドが呼ばれたとき, (2) ユーザーが「〜を広めたい」 「〜を変えたい」「〜に気づいてほしい」「どう動けばいい？」と言ったとき, (3) まだ具体的なアクションに落ちていない動機・目標を持っているとき。 入力: 実現したい想い（自由記述）+ 制約条件（任意）。 出力: 想いの構造化、ターゲット階層、アクションプラン、成功指標。

Impact Designer - 想いを影響戦略に変換するスキル

核心原則

想いは行動の前にある。「何をするか」より先に「誰の何をどう変えたいか」を明確にせよ。戦略は目的に従う。

ワークフロー

Phase 1: 入力の収集

ユーザーから以下を受け取る:

1. 想い: 実現したいこと（「〜したい」「〜が気になる」「〜を変えたい」レベルでOK）
2. 制約条件（任意）: 時間、エネルギー、関係性上の制約
3. 既に試したこと（任意）: 過去にやったが効果がなかったアクション

想いが曖昧な場合は、掘り下げ質問で構造化を促す（ただし1問のみ）:

• 「それが実現したら、誰にとって何が変わりますか？」

Phase 2: Memory参照（必須・最初に実行）

1. ../predict/references/people-memory.md を読む
   • 関係するターゲット人物の関心・前提知識・反応傾向を確認
2. ../predict/references/channel-memory.md を読む
   • 利用可能なチャンネルの性質・到達力を確認
3. ../predict/references/prediction-log.md を読む
   • 類似トピックの過去の成功パターン・失敗パターンを確認

Phase 3: 想いの構造化

「想い」を3層に分解する:

表層（言葉にしたこと）: 「〜がすごいと思った」
中層（本当の目的）: 「チームに使ってもらいたい」
根層（究極の動機）: 「AI活用による業務改善を推進したい」

構造化の問い:

• 誰が: 誰の現状・行動・認識を変えたいか
• 何を: 何を知ってほしいか / 何をしてほしいか / 何を感じてほしいか
• どう変わるか: 変化後の状態はどんなものか
• なぜ今か: なぜ今それが重要なのか

Phase 4: ターゲット分析

4.1 ターゲット階層の設定

| 層 | 定義 | 特徴 | アプローチ | |----|------|------|-----------| | 1次ターゲット | 直接の受益者。今すぐ使える・恩恵を受ける人 | 前提知識あり。説明コスト低 | 速報・共有で十分 | | 2次ターゲット | 潜在的な受益者。気づけば恩恵を受ける人 | 関連する問題意識はある | 橋渡し説明が必要 | | 3次ターゲット | 間接的影響を受ける人。文化・習慣が変わる | 前提知識がない場合も | 長期・継続的なアプローチ |

people-memory と channel-memory から、各層に該当する人・チャンネルを特定する。

4.2 インフルエンサーの特定

ターゲット集団の中で「この人が動けば他も動く」キーパーソンを特定:

• 技術的権威: その分野で信頼されている人
• 情報ハブ: 多くの人に情報を届けられる人
• 早期採用者: 新しいものを試すのが早い人

Phase 5: 手段の組み合わせ設計

5.1 手段の評価マトリクス

| 手段 | 到達力 | 説得力 | 持続力 | コスト | 適した目的 | |------|--------|--------|--------|--------|-----------| | Slack投稿 | 高 | 低〜中 | 低（流れる） | 低 | 速報・気づき共有 | | Slackスレッド | 中 | 中 | 中 | 低 | 議論・深掘り | | DM | 低（1対1） | 高 | 中 | 中 | 個別説得・関係構築 | | Cosenseページ | 中（検索） | 高 | 高（永続） | 中 | 知識の体系化・参照 | | デモ・実演 | 中 | 最高 | 高 | 高 | 使い方の体験・納得 | | MTGでの発表 | 中（出席者） | 高 | 中 | 高 | 合意形成・決定 | | コード/PR | 低（開発者） | 最高 | 高 | 高 | エンジニアへの証明 |

5.2 組み合わせ戦略

スモールスタート戦略（不確実性が高い場合）:

1. まず自分のtimesで試し打ち → 反応確認
2. 反応があれば関連チャンネルに展開
3. 興味を示した人にDMで深掘り

波及設計戦略（確信があり広めたい場合）:

1. インフルエンサーに先に届ける（DM・メンション）
2. インフルエンサーが反応したらチャンネルに展開
3. 議論が起きたらCosenseにまとめ

持続的影響戦略（文化を変えたい場合）:

1. Cosenseにナレッジを蓄積
2. 複数の機会（MTG・Slack・1on1）で一貫したメッセージ
3. 成功事例を記録して共有

Phase 6: アクションプランの生成

6.1 フェーズ分け

今日（即座）: 情報が新鮮なうちにやること 今週中: 仕込みが必要だが近いうちにやること 今月中: 中長期の波及のために仕込むこと

6.2 各アクションの設計

各アクションに以下を付与:

• 何をするか: 具体的な行動
• 使う手段: Slack/DM/Cosense/MTG等
• ターゲット: 届けたい人・チャンネル
• 使う道具: /enrich / /predict / /ripple 等
• 成功条件: このアクションが「効いた」と判断できる状態
• 撤退条件: このアクションを諦めるタイミング

6.3 コストの最小化

• 全部やらなくていい。最小の行動で最大の波及を設計する
• 「これだけやれば十分」という最低ラインを示す
• 追加でやれることをオプションとして提示

Phase 7: 出力フォーマット

## 影響戦略

### 想いの構造化
- **表層**: [ユーザーの言葉]
- **目的**: [本当にやりたいこと]
- **変化の対象**: [誰の何を変えたいか]

### ターゲット階層
| 層 | 対象 | 前提知識 | 接触手段 |
|----|------|---------|---------|
| 1次 | [名前/チャンネル] | [知識レベル] | [推奨手段] |
| 2次 | [名前/チャンネル] | [知識レベル] | [推奨手段] |
| 3次 | [名前/チャンネル] | [知識レベル] | [推奨手段] |

### キーパーソン
[インフルエンサーと、その理由]

### アクションプラン

| 順番 | いつ | アクション | 手段 | ターゲット | 道具 |
|------|------|-----------|------|----------|------|
| 1 | 今日 | [アクション] | [手段] | [対象] | [/enrich, /predict等] |
| 2 | 今週 | [アクション] | [手段] | [対象] | [道具] |
| 3 | 今月 | [アクション] | [手段] | [対象] | [道具] |

**最小実行セット**（これだけでも効果あり）:
→ [最も重要な1-2アクション]

### 成功指標
- 短期（1週間）: [具体的な状態]
- 中期（1ヶ月）: [具体的な状態]

### 次のステップ
→ まず「[最優先アクション]」から始めましょう。
→ メッセージ素材が必要なら `/enrich [骨子]` を使ってください。
→ メッセージ案ができたら `/predict #[チャンネル] [メッセージ]` で効果検証できます。

Phase 8: predict/references の更新（知見があれば）

新たに判明したターゲット情報があれば:

• people-memory: ターゲットの新たな関心・動機が判明した場合
• channel-memory: 戦略設計で活用できるチャンネル情報が判明した場合

手段の選択ガイドライン

「Slackだけ」では届かないケース

以下の場合は Slack 以外の手段を組み合わせる:

| 状況 | 理由 | 補完手段 | |------|------|---------| | ターゲットがSlackを頻繁に見ていない | 見逃しリスク | DM + Cosense | | 概念的な変化（認識・習慣の変革）を求める | 1投稿では変わらない | 継続的な投稿 + MTG | | 技術的な説得が必要 | テキストより実演 | デモ + コード | | 組織的な決定が必要 | Slackは非公式 | MTGでの合意形成 |

「投稿しない」が最善の場合

• ターゲットが既に知っている（重複ノイズになる）
• 情報が不確かで確認が必要
• 関係が薄く、Slack投稿より1on1の方が信頼を得やすい
• タイミングが悪い（チームが別の問題で消耗している）

使用例

例1: 技術の普及

ユーザー: /impact
         Cosense MCPの書き込み機能をチームに広めたい

→ 想いの構造化:
  目的: チームのナレッジ管理をAIで自動化したい
  変化の対象: チームメンバーの日常ワークフロー

→ ターゲット:
  1次: 菊池、廣田（既存MCPユーザー）
  2次: Cosense使うが未導入の人
  3次: チーム全体のAI活用文化

→ アクションプラン:
  1. 今日: #ai_stuff に速報 → /enrich → /predict
  2. 今日: 佐々木さんにDMでフィードバック（開発者との関係強化）
  3. 今週: 自分で使って体験レポートをCosenseに書く
  4. 来週MTG: 実演デモ（2次ターゲットへのリーチ）

→ 最小実行: 1と3だけでも十分な波及が期待できる

例2: 問題提起

ユーザー: /impact
         データパイプラインの障害対応が属人化していて改善したい

→ 想いの構造化:
  目的: 障害対応をチームで分担できる状態にしたい
  変化の対象: チームの運用プロセス

→ アクションプラン:
  1. 今週: 問題の現状をCosenseに整理（共有前の仕込み）
  2. 今週: チームMTGで議題として提案（合意形成が必要）
  3. 来月: 対応手順書をCosenseに作成（持続的な改善）

→ Slack投稿は補助手段。主戦場はMTG。

検索の実行ルール

predict/ripple/enrich スキルと同じルールに従う:

• クエリは短く、キーワード2つまで
• slack_search_public を優先
• 並列は最大2つ
• response_format パラメータは指定しない