AWS Alliance HQの学習資料作成、レビュー前に上司を増やす
こんにちは。 MotherComputer のストレリチアこと yukinag です。
会社のAIアドベントカレンダーに参加しています。
みんなの記事が立派で、読んでるうちに背筋が伸びすぎて身長が2cm増えるので、今回は 社内で使える（のに胃が痛い）AI活用を持ってきました。
テーマはこれです。
- 私は AWS Alliance HQ チームで Alliance Lead を担当
- 社内向け学習資料（オンボーディング / ナレッジ） を作っている
- そして最大の敵は、AWSでも競合でもなく、レビュー会の “質問” である
資料づくり自体は楽しいんですよ。
“質問”が始まるとHPが減るだけで。
TL;DR（忙しい人向け）
- AIに「上司 / ステークホルダーがしてきそうな質問」を 先に大量生成させる
- 質問をカテゴリ分けして、想定問答を作る
- “圧強め言い換え”で事前に鍛える（胃が痛い）
- 回答は 10秒結論 → 30秒根拠 → 次アクション（宿題） の三段構えが安定
背景：Allianceの学習資料は、だいたい「よさそう」だけど、だいたい刺される
AWS Alliance HQの学習資料って、言い換えると「社内の人が上手にAWS認定取得するための地図」なんですが、レビューだとたいがいこうなります。
- 「それ、AWS公式の資料でよくない？」
- 「それ、社内Wikiでよくない？」
- 「それ、今いる？」（ここが一番痛い）
- 「で、誰がメンテするの？」
- 「で、KPIは？」
“で、KPIは？”は呪文です。唱えられると空気が変わります。
スライドが“熱意の発表”から“数字の話”に変わります。
今回の戦略：レビュー前に「上司」を増やす（人類は上司を増やしてはいけない？）
普通は「上司は一人で十分」だと思います。
でもAIを使えば、上司を増やせます（増やしてはいけないのに）。
- 上司A：CFO型（ROI / コストしか見ない）
- 上司B：セキュリティ型（リスクとコンプラで殴る）
- 上司C：現場型（“それ現場で使える？”職人）
- 上司D：経営型（意思決定のスピードを守りたい）
- 上司E：AWS詳しい型（用語の定義で詰める）
上司を十人にすると胃が痛い代わりに、穴が見える。
本番の会議が少し楽になります。…少しだけ。
まずはAIに渡す「企画要約」（ここが一番大事）
機密を入れないために、資料そのものを貼りません。
代わりに、AIに渡すのは 要約（サニタイズ） です。
企画要約（例：AWS Alliance HQ 学習資料 v1）
- 目的：社内の関係者が「AWS認定取得のいろは」を早く理解し、迷子にならずに動ける状態を作る
- 対象：営業 / プリセ / デリバリー / PM など（“Alliance初見”も想定）
- 形式：短いスライド教材＋テンプレ＋FAQ
- コンテンツ例：
- Allianceの役割・支援範囲
- AWS認定の試験範囲
- よくある問題パターンと注意点
- 問い合わせ導線（迷った時の連絡先・判断軸）
- 成功指標（例）：
- 学習完了数、アクセス数、問い合わせ重複削減
- 立ち上がり時間の短縮（自己申告でもOK）
- 連携フローの詰まり減（定性→定量へ）
- リスク：AWSプログラムや制度が変わると腐る
- 対策：バージョン管理＋“公式ソースへのリンク”中心＋更新担当明確化
ポイント：AIに “それっぽい数字” を作らせない。
ここで数字を盛ると、胃ではなく信用が死にます。
実際に使ったプロンプト（上司生成器）
1) 質問を大量に出す（まず30個）
あなたは社内レビューで容赦なく質問する上司です（失礼・人格否定は禁止）。
以下の企画要約に対して、会議で出そうな質問を30個出してください。
- 質問はカテゴリ別に：ROI/コスト、リスク/コンプラ、スケジュール、代替案、意思決定、ステークホルダー、運用/メンテ
- 各質問に「質問の意図（何を確認したいか）」を1行で付ける
- 最後に「最も痛い質問TOP5」を選ぶ
--- 企画要約 ---
（ここに貼る）
2) 圧強め言い換え（胃痛MAX）
上記の質問を「会議で実際にありそうな、やや圧のある言い方」に言い換えてください。
ただし失礼・煽り・人格否定は禁止。圧は“淡々と”かけてください。
優しいAI：褒めてくれる
上司AI：淡々と刺してくる
人間（私）：淡々とHPが減る
AI上司が実際に聞いてきがちな質問（AWS Alliance HQ版）
ここからは「ありがち」をそのまま刺しにくるパートです。胃薬の準備を推奨します。
ROI / コスト（胃に直撃）
- 「これ作ることで、何がどれだけ良くなるの？」
- 意図：投資対効果（時間 / 問い合わせ / 成果）の確認
- 「学習資料って、結局“読まれない”けど、読む前提でいい？」
- 意図：利用想定の妥当性
- 「資料作る時間で、案件やった方が早くない？」
- 意図：優先順位・機会損失
リスク / コンプラ（胃が冷える）
- 「AWSのプログラムって変わるけど、古い情報で事故らない？」
- 意図：陳腐化リスク
- 「“公式っぽい資料”に見えて誤解されない？誰の責任？」
- 意図：責任分界点
運用 / メンテ（胃が永続ダメージ）
- 「誰が更新するの？担当が異動したら？」
- 意図：運用の持続性
- 「問い合わせが来たとき、資料で解決しなかったら 結局人に来るよね？」
- 意図：サポート負荷の現実
代替案（胃が揺れる）
- 「それ、AWS公式を貼るだけじゃダメ？」
- 意図：重複の排除
- 「社内Wiki / Notion / Confluenceでよくない？ 新しく作る意味ある？」
- 意図：手段の妥当性
意思決定（胃が静かに終わる）
- 「今日この場で、何を決めたい？」
- 意図：会議の目的（そして責任の所在）
Allianceの学習資料は “良いこと” なので、反対されにくい。
でも 「運用」「責任」「指標」 が弱いと、静かに刺されます。
回答テンプレ：10秒結論 → 30秒根拠 → 次アクション（宿題）
想定問答はこの型に落とすと、会議で生き残りやすいです。
例：「AWS公式でよくない？」への回答
- 結論（10秒）：公式は使います。ただ、社内の迷子ポイントに合わせて“橋渡し”します
- 根拠（30秒）：公式は網羅的で正しい一方、社内の実務（誰に相談 / どの順で動く / 社内ルール）に落ちないので、迷子が減りづらい
- 次アクション（宿題）：公式リンクを基点にして、社内手順・判断軸・問い合わせ導線だけを薄く足します（範囲も明記します）
例：「誰が更新？」への回答
- 結論：更新オーナーを決め、更新頻度と“腐りにくい設計”で持続させます
- 根拠：中身を「固定情報（原則）」と「変動情報（リンク）」に分離し、変動は公式リンクに逃がします
- 次アクション：v1は四半期レビュー。更新担当と副担当（代替担当）を置きます
例：「KPIは？」への回答
- 結論：まず“利用”をKPIにし、次に“成果”へ段階的に寄せます
- 根拠：最初から売上直結だけ追うと、学習施策は死にます（測れないものを測ろうとして死ぬ）
- 次アクション：アクセス / 完了 / 問い合わせ重複削減 → 立ち上がり短縮 → フロー滞留削減、の順で成熟させます
KPIを聞かれて詰まる理由は「KPIが無い」ではなく、
“KPIの成熟度の設計”が無いことが多い、という学び。
上司AIガチャ（だいぶふざける）
上司は一種類ではないので、AIにも役を持たせると効きます。
CFO型（ROIで殴る）
あなたはCFOタイプの上司です。
ROI/コスト観点で質問を10個ください。各質問に意図も付けてください。
セキュリティ/監査型（責任分界で殴る）
あなたはセキュリティ/監査タイプの上司です。
コンプラ/機密/責任分界の観点で質問を10個ください。意図も付けてください。
現場リード型（“使える？”で殴る）
あなたは現場リードです。
「実務で使えるか/読まれるか/迷子が減るか」の観点で質問を10個ください。意図も付けてください。
最後にこう言います。
全部の質問を統合して「痛い順」に並べ替えてTOP10を出してください。
さらに各質問に対する“模範回答の骨子（結論→根拠→次アクション）”も添えてください。
会議前に上司が4人増えます。
ただし現実の上司は増えません（重要）。
胃だけが減ります。
注意：上司AIは強いが、たまに“それっぽい嘘”を言う
- 事実・数値・制度はAIが盛りがち → 必ず自分で確認
- 言い回しが強すぎる場合 → 「失礼禁止」「煽り禁止」を明記
- 機密は入れない → 要約で渡す
まとめ：AIは“事前に殴ってくれる先輩”として優秀
AWS Alliance HQの学習資料づくりって、作るだけなら平和なんですが、
レビューで飛んでくる質問がだいたい「運用」「責任」「指標」で胃に刺さります。
でも、AIに先にそれを全部やらせると、
- 質疑の穴が可視化される
- 想定問答が作れる
- 本番の会議が少し楽になる
というわけで、上司は一人で十分だと思ってたけど、AIで十人に増やすと、なぜか安心しました。
胃は減りました。