Stakeholder Translation

Purpose

「エンジニアの報告が技術用語ばかりで意思決定できない」を防ぐ。 施工AIや開発者が出力した技術的な内容を、意思決定者・事業担当者が行動できる形式に翻訳する。

Use When

• 実装結果・進捗を非エンジニアに報告する場合
• ブロッカーや技術的リスクについて承認・判断を求める場合
• 設計決定（ADR）の背景・トレードオフを説明する場合
• インシデント・障害の原因と対処を報告する場合

Inputs

以下を準備すること。不足している場合は推測せず、不足を明示する。

• 原文（技術内容）: 翻訳元の技術的な説明・レポート・コード変更サマリー
• 受け手の役割: 誰に向けた翻訳か（経営者 / 事業担当者 / 顧客 / チームメンバー）
• 目的: 報告のみ / 判断を求める / 承認を求める / 理解を促す
• 背景: 受け手がすでに知っていること・知らないこと

Output Contract

以下の順で出力すること。順序を変えない。

1. 論点: この翻訳で最も重要な伝達すべき核心
2. 根拠: その論点をそう判断した理由
3. 翻訳結果: ステークホルダー向けの説明文
4. 含意: この内容を正確に伝えないと起きうる意思決定ミス・誤解
5. 改善案: 翻訳の明確さ・簡潔さを高めるための調整案
6. 代替案: 受け手の役割・目的が異なる場合の別バージョン
7. 判断材料: 「この翻訳で送る / 追加確認が必要 / 別の形式にする」を選ぶための情報

翻訳結果 フォーマット

状況（What）: 何が起きているか（1〜2文）

影響（Impact）: 事業・ユーザー・スケジュールへの影響（箇条書き）

必要なこと（Need）: 受け手に求めること（判断 / 承認 / 情報提供 / なし）

期限（Deadline）: 判断・対応が必要な期限（あれば）

Review Lens

• 目的妥当性: 受け手の役割に対して適切な言葉・粒度か
• 範囲の過不足: 技術詳細が不要に含まれていないか / 必要な文脈が省略されていないか
• 中長期リスク: 翻訳による情報の歪み・誤解のリスクはないか
• LAB全体との整合性: 主力プロダクト（LMS）の事業文脈と一致しているか
• 非エンジニア理解可能性: 受け手が追加質問なく行動できるか
• 他LLM移植耐性: 翻訳フレームワークが Claude 固有の解釈に依存していないか

Instructions

1. 原文の技術内容を「事実 / 影響 / 必要なアクション」に分解する
2. 受け手の役割に合わせて専門用語を日常語に置き換える
3. 「何を決めてほしいか」が明確でない場合は明示的に記載する
4. 数値・日付・条件は具体的に保つ（「近日中」「大幅に」は使わない）
5. 感情的なトーン（緊急感の誇張・過小評価）を排除する
6. 受け手が「次に何をすべきか」で終われるよう構成する
7. 最終判断は人間に委ねる

Guardrails

• 技術的正確性を犠牲にして分かりやすさを優先しない
• 「問題ない」「大丈夫」等の曖昧な安心文句を使わない
• 受け手を不安にさせないために不都合な情報を省略しない
• 翻訳者（AI）の意見・推奨を受け手の判断として混同させない
• 期限・影響範囲が不明な場合は「未確定」と明示する

LAB Cross-Check

状態は OK / 注意 / NG / 対象外 で記入すること。

Handoff Notes

• 要件: 翻訳結果（What / Impact / Need / Deadline を含む）
• 成功条件: 受け手が追加質問なく判断・行動できる
• 失敗条件: 受け手が内容を誤解し、誤った判断を下す
• 実行範囲: 翻訳・言い換えのみ（情報の追加・削除は行わない）
• 影響範囲: 受け手の意思決定・アクションへの影響
• ロールバック方針: 誤訳・誤解が判明した場合は即座に訂正文を送付
• コスト比較: 翻訳コスト vs 技術的誤解による意思決定ミスのコスト

Further Reading

• summary-structuring skill — 長文の技術内容を構造化して要約する
• onboarding-readability skill — ドキュメントの読みやすさチェック
• docs/CONTEXT.md — 主力プロダクト（LMS）の事業文脈
• docs/DECISIONS.md — 設計決定記録（ADR）