stakeholder-update

ステークホルダー向け進捗報告スキル

このスキルでは、BLUF（結論を先に述べる）の原則に従い、経営幹部やステークホルダー向けの効果的な状況報告を作成します。

必須入力

与えられた情報をもとに作成してください。以下の情報が不足していても、完全な出力を作成してください。不足している情報は、妥当な仮定で補い、(仮定、要確認) と明記して、最後に仮定として列挙してください。中核となるテーマ自体が欠けている（書く内容が何もない）場合に限り、最初に質問してください。

• 報告対象のプロジェクトまたは製品
• 対象者（CEO、取締役会、部門横断のリーダー、投資家など。内容の詳細度や形式が変わります）
• 期間（今週／今スプリント／今月）
• 現在の状況（順調／リスクあり／ブロック中）
• 主要指標と目標に対する現在値

Brain からの読み込み／Brain への書き込み

professional-brain（brain/）が存在する場合は、質問する前に参照してください。

• まず読む： 関連する stakeholders/ ファイル（各人が重視することや以前の依頼）、context.md（語り口やトーン）、および前回の報告以降に変更された内容を把握するための最近の decisions/。
• 作成後に書き込む： 新たに明らかになった依頼、懸念、または約束を、情報源を示すタグを付けて、該当する stakeholders/ ファイルに追記してください（会議で口頭で述べられ、まだ文書化されていない内容には [verbal] を付けます）。

詳細資料

• references/status-honesty-guide.md — 🟢／🟡／🔴 の判断基準（ウォーターメロン問題、🟡が連続した場合のルール、誠実な再ベースライン設定）と、悪いニュースを伝える際の「事実 → 影響 → 対応 → 依頼」の表現方法をまとめています。状況が🟡／🔴の場合、または入力のメモが指標より楽観的に見える場合は、必ず適用してください。
• templates/update-skeleton.md — 品質チェック項目を組み込んだ、1ページの記入式報告テンプレートと送信前チェックリストです。自分で報告書を作成したいユーザーに案内してください。

報告の構成

1. BLUF（結論を先に述べる）

最も重要な情報から始めます。

• 状況：🟢 順調／🟡 リスクあり／🔴 ブロック中／✅ 完了
• 要点：現状を一文で要約
• 必要な対応：ステークホルダーに求めること（該当する場合）

2. 進捗の概要

達成事項を簡潔にまとめます。

• 今回の期間にリリースしたもの
• 達成したマイルストーン
• 主要指標の推移

箇条書きは最大3～5項目にしてください。

3. 指標ダッシュボード

主要指標

指標	現在値	目標	傾向	状況
[指標名]	[値]	[目標]	↑/→/↓	🟢/🟡/🔴

最も重要な指標を3～5個だけ含めてください。

4. リスクとブロッカー

優先度の高い問題：

• 問題：簡潔な説明
• 影響：何が危機にさらされているか
• 軽減策：その問題に対して行っていること
• 必要な支援：ステークホルダーができること（該当する場合）

経営幹部レベルで重要な問題だけを含めてください。

5. 今後のマイルストーン

今後30日間：

• マイルストーン（予定日）
• マイルストーン（予定日）

今後90日間：

• 主要マイルストーン（月）
• 主要マイルストーン（月）

6. 必要な意思決定（該当する場合）

• 決定事項：明確な説明
• 選択肢：長所と短所を含む2～3個の選択肢
• 推奨案：推奨する内容とその理由
• 期限：いつまでに決定が必要か

すべての出力の末尾に、短い 仮定と不足情報 のブロックを付けてください。入力に記載がなかったために置いた仮定と、この出力に最も大きく影響する不足情報を、2～4個の箇条書きで示します。仮定も不足情報もない場合は、その旨を1行で述べてください。

作成ガイドライン

トーン：プロフェッショナルで、簡潔かつ行動を促す表現 長さ：1ページ以内（または読了時間2分以内） 頻度：進行中のプロジェクトは毎週、保守作業は隔週

経営層向けコミュニケーションの原則：

1. プロセスではなく結論から述べる

   • ❌ 「今週は5件の実験を実施し、データを分析しました……」
   • ✅ 「最適化の結果、コンバージョン率が15％上昇しました」

2. 活動ではなく影響に焦点を当てる

   • ❌ 「顧客インタビューを12件実施しました」
   • ✅ 「導入の最大の障壁（設定の複雑さ）を特定しました」

3. 問題を早期に明らかにする

   • リスクを取り繕わない
   • 問題だけでなく、解決策を提案する
   • 必要な支援を具体的に示す

4. データで状況を伝える

   • 可能な限り数値化する
   • 一時点の状況だけでなく、傾向を示す
   • 指標をビジネス上の成果に結び付ける

5. ざっと見て把握できるようにする

   • 見出しと箇条書きを使う
   • 重要な情報を太字にする
   • 視覚的な指標（🟢🟡🔴、↑→↓）を使う

ステータスのガイドライン

🟢 順調：すべての目標を達成しており、重大なリスクはありません 🟡 要注意：進捗に影響する可能性のある問題があります 🔴 停滞：進捗を妨げる重大な問題があり、介入が必要です

更新例

# Product Update: Customer Onboarding Redesign
**Week of Jan 20, 2026**

## BLUF
**Status**: 🟡 At Risk  
**Key Takeaway**: New onboarding flow is performing well in tests (+35% completion), but launch delayed one week due to integration issues with billing system.  
**Action Needed**: Decision needed on whether to launch onboarding separately or wait for billing integration fix.

## Progress Summary
- Completed user testing with 24 participants (94% positive feedback)
- Implemented first-time user experience improvements
- Resolved 12 of 15 bugs identified in QA
- Engineering allocated resources to billing integration fix

## Key Metrics
| Metric | Current | Target | Trend | Status |
|--------|---------|--------|-------|--------|
| Onboarding Completion | 45% | 60% | → | 🟡 |
| Time to First Value | 4.2 min | 3.0 min | ↓ | 🟢 |
| Setup Support Tickets | 45/week | <30/week | ↓ | 🟢 |
| User Activation Rate | 52% | 65% | → | 🟡 |

## Risks & Blockers

**HIGH: Billing System Integration Delay**
- **Impact**: Prevents users from completing onboarding flow; delays launch by 1-2 weeks
- **Root Cause**: API deprecation by payment processor, requires code rewrite
- **Mitigation**: Engineering team reallocated resources, fix ETA Feb 3
- **Decision Needed**: Launch onboarding without payment integration or wait for fix? (See below)

**MEDIUM: Mobile Testing Coverage**
- **Impact**: Some edge cases on older Android devices not tested
- **Mitigation**: Partnering with QA to expand test matrix; running beta with internal users on diverse devices

## Upcoming Milestones

**Next 30 Days:**
- Resolve billing integration (Feb 3)
- Launch onboarding redesign (Feb 5 or Feb 12 depending on decision)
- Begin measuring impact on conversion (Feb 12)

**Next 90 Days:**
- Iterate based on production data (March)
- Extend to mobile app (April)
- Launch advanced features (May)

## Decision Needed

**Should we launch onboarding separately from billing integration?**

**Option A: Launch Now (Recommended)**
- Pros: Get 35% completion rate improvement to users immediately, gather production data, maintain momentum
- Cons: Users need to complete payment in old flow, slightly disjointed experience
- Timeline: Launch Feb 5

**Option B: Wait for Billing Fix**
- Pros: Fully integrated experience from day one, no technical debt
- Cons: Delays benefits by 2 weeks, Q1 metric targets at risk, team momentum lost
- Timeline: Launch Feb 12

**Recommendation**: Option A. The onboarding improvements are valuable independently, and the old payment flow works fine. Waiting risks missing Q1 targets and delays validated improvements from reaching users.

**Timeline**: Need decision by Jan 22 for Feb 5 launch.

---

**Questions?** Reply to this email or ping me on Slack.

頻度の目安

毎日のスタンドアップ：

• 極めて簡潔に（箇条書き3項目）
• 昨日リリースしたもの
• 今日リリースするもの
• ブロッカー

週次更新：

• 上記のテンプレート全体を使用する
• 進捗とリスクに焦点を当てる
• 1ページ以内に収める

月次レビュー：

• より詳細な指標分析
• 戦略的な振り返り
• 四半期目標の進捗
• 長めの形式（2～3ページ）も可

四半期ごとのビジネスレビュー：

• 包括的な分析
• 時系列での傾向
• 戦略的な提案
• プレゼンテーション形式

対象者に応じた調整

経営幹部向け

• ビジネスへの影響から述べる
• 会社のOKRに結び付ける
• 戦略と成果に焦点を当てる
• 技術的な詳細は最小限にする

プロダクト／エンジニアリング部門のリーダー向け

• 技術的な背景を含める
• スプリント／マイルストーンの進捗を示す
• アーキテクチャへの影響を説明する
• 技術的負債に言及する

部門横断チーム向け

• 技術的な背景とビジネス上の背景のバランスを取る
• 依存関係を明らかにする
• 必要な連携を明示する
• 依頼内容を明確にする

取締役会／投資家向け

• 指標と事業の牽引力に焦点を当てる
• 競争上の位置付け
• 市場機会
• 財務への影響

採点基準（0～40）

このスキルの出力は、提出前に必ず採点してください。32点以上が公開可能な品質です。

項目	0	5	10
要点とステータスの誠実さ	ステータスが埋もれている、または記載がなく、更新内容が活動日誌のようになっている	ステータスと要点を冒頭に示しているが、絵文字が指標を実態以上に良く見せている（外向きは緑、中身は赤）	冒頭の3行でステータス、1文の要点、依頼を示している。🟢／🟡／🔴の判定が最も悪い重要指標と一致し、その理由も記載している
指標の文脈	目標、傾向、期間比較のない生の数値	目標はあるが、指標が活動件数で、ビジネス上の成果と結び付いていない	3～5個の指標それぞれに目標、傾向、ステータスがあり、特に重要な指標は、関係する売上、顧客、または目標に結び付いている
リスクへの対応可能性	リスクが、担当者、軽減策、影響のない懸念事項として列挙されている	軽減策は記載されているが、影響が数値化されておらず、読み手が何か対応する必要があるか不明	すべてのリスクに、数値化された影響、日付または達成条件付きの軽減策、明示的な「必要な支援」（または「なし」）がある
意思決定の提示	経営幹部に自由回答式の質問を投げかけている、または意思決定事項がまったく示されていない	選択肢は列挙されているが、費用やトレードオフ、推奨案が示されていない	それぞれの意思決定に、費用を明示した2～3個の選択肢、理由を添えた明確な推奨案、決定が必要な日付と、その日付が期限となる理由がある

品質チェック

• アップデートの冒頭にBLUFを記載します。詳細に入る前に、状況、重要な要点、必要なアクションを示してください。
• すべての指標に目標との比較を含めます（数値だけを示すのではなく）。
• すべてのリスクに緩和策を記載し、ステークホルダーの対応が必要な場合は「支援が必要」フラグを付けます。
• 必要な決定には具体的な選択肢と明確な推奨案を示します。
• 全体を1ページ未満、または読了時間2分以内に収めます。

アンチパターン

• 状況評価を末尾に埋もれさせないでください。BLUFでは、最も重要な情報を最初に示します。
• 目標や前の期間との比較なしに指標を報告しないでください。文脈のない数値だけでは役に立ちません。
• 緩和策と、ステークホルダーの支援が必要であることを示す明確なフラグなしに、リスクを列挙しないでください。
• 明確な推奨案を示さず、必要な決定を質問の形で記載しないでください。エグゼクティブが必要としているのは選択肢であり、自由回答形式の質問ではありません。
• アップデートを1ページを超える長さにしないでください。それ以上必要な場合は、内容を増やすのではなく、メッセージを編集してください。

実行

チームのコミュニケーションチャネル（Slack、メール）にアクセスできるツール使用エージェント向けです。アップデートの送信は外部向けの操作であり、自動で行うことは決してありません。ツールにアクセスできないランタイムでは、このセクションは無視してください。SKILLSPEC.md §5を参照してください。

前提条件

• 最終的なアップデート文は、正確なチャネル／宛先リストを含め、一字一句そのまま人間に提示され、明示的に承認されていること。
• チャネルまたは宛先リストは、履歴から推測せず、ユーザーが指定していること。
• 状況が🔴の場合、または「要決定事項」を含む場合は、指定された意思決定者が宛先に含まれていることを確認してください。

許可される操作

• 承認済みの文面を変更せず、承認された1つのチャネルに投稿すること。または、承認済みの件名で、承認された宛先にメールを1通送信すること。
• ユーザーが指定した場所（ドキュメント、Brain、リポジトリ内のファイル）にコピーを保存すること。
• これ以外は何もしないでください。定期送信のスケジュール設定は行わないでください（その場合は、独自の承認条件があるschedule-recipeを参照してください）。承認済みの文面にない@メンションや、複数チャネルへの同時投稿も行わないでください。

検証

• メッセージがチャネル／スレッドに存在することを確認し（パーマリンクを取得）、リンクを報告してください。
• 送信したテキストが承認済みのテキストとバイト単位で一致することを確認してください。

ロールバック

• プラットフォームで可能な場合、投稿直後のメッセージを削除できるのは、人間から明示的な指示があった場合に限ります。それ以外の場合は、訂正の返信を投稿してください。
• 次の場合は停止し、人間に確認してください。チャネルが見つからない場合、投稿が部分的に失敗した場合、または送信直前の文面が承認済みの文面と一致しなくなった場合。

トリガーとなるフレーズの例

• 「状況アップデートを書いてください。」
• 「リーダー向けに進捗報告を書いてください。」
• 「ステークホルダー向けのプロジェクトアップデートを書いてください。」
• 「エグゼクティブ向けのブリーフィングを書いてください。」