# Stakeholder Translation

> 技術的な実装内容・判断・リスクを、非エンジニアのステークホルダーが理解できる言葉に変換する。「何が起きているか」「何が必要か」「何を決めてほしいか」を明確に伝える。非エンジニアへ報告・説明するときに使う。

- Skill: `thinkyou0714/stakeholder-translation` (Agent Skill)
- Install (CLI): `npx skillmds@latest add thinkyou0714/stakeholder-translation`
- Raw SKILL.md: https://api.skillmd.com/api/skills/thinkyou0714/stakeholder-translation/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: thinkyou0714 (https://skillmd.com/u/thinkyou0714)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/thinkyou0714/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

| 観点 | 状態 | 備考 |
|---|---|---|
| 自動化フロー | — | 自動化フローの状態変化が含まれているか |
| データ / 認証 / ログ | — | DB・認証・ログの問題が事業影響として説明されているか |
| 実装 / 運用フロー | — | 実装進捗・ブロッカーが行動可能な形で伝わるか |
| 非エンジニア理解可能性 | — | 追加質問なく行動できる説明か |
| 会員共有 / 再利用耐性 | — | 翻訳フォーマットが他の報告にも転用できるか |
| 他LLM移植耐性 | — | フレームワークが Claude 固有に依存していないか |

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

## Handoff Notes

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

## Further Reading

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