memo-stress-tester について
memo-stress-testerは、ビジネスメモが経営判断に使える状態かを評価するライティングスキルです。論理構成やナラティブを点検し、根拠の弱い主張や抜け、未完了の作業を明らかにします。
主な機能
- 01Completed Staff Workの監査
- 02SCQ構成の検証
- 03MECEによる論点確認
- 04ナラティブとFAQの点検
- 05貢献とトレードオフの評価
活用シーン
- 01経営層向け提案の提出前レビュー
- 02PRDや戦略ブリーフの査読
- 03判断に至らなかったメモの診断
- 04長いレポートの1ページ化
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ joellewis/ skill-library --skill memo-stress-testerインストール後、Claude Code で/memo-stress-testerを入力して読み込まれたか確認します。
詳細
概要
メモのストレステストとは、経営幹部の意思決定に向けたビジネス文書の「準備状況」を厳密に評価することです。論理の抜け、裏付けのない主張、「練り上げ不足」のアイデアを特定します。Amazonのナラティブ基準、ミントのピラミッド論理、そして「完成したスタッフワーク」の原則を適用することで、上司が仕上げるための草案ではなく、戦略的な行動に使える自己完結型のツールであることを確実にします。
指針となる原則
原則 1:完成したスタッフワーク(出典:Web、「Completed Staff Work Doctrine」)
単一の実行案にまとめ上げるまで、調査し、執筆し、再調査し、書き直します。「責任者」がすべきことは、承認するか却下するかだけです。上司がさらに調査や検討をしなければならないなら、スタッフワークは未完成です。
原則 2:自己完結型のナラティブ(出典:Bryar、『Working Backwards』)
メモは、補足プレゼンテーションがなくても内容が伝わるものでなければなりません。より深い思考を促し、静かにじっくり読めるナラティブであるべきです。文書が「廊下での会話で得られる背景情報」や発表者の説明に依存しているなら、ストレステストに合格しません。
原則 3:MECE の検証(出典:Minto、『The Pyramid Principle』)
根拠となる各ポイントのまとまりは、相互に排他的(重複がない)であり、全体として網羅的(抜けがない)でなければなりません。リスト内のポイントが重複していると、論理は「曖昧」です。重要な要因が欠けていると、文書は脆弱になります。
原則 4:労力より貢献(出典:Drucker、『The Effective Executive』)
メモでは、労力の中心(コスト/内部プロセス)ではなく、組織への成果と貢献に焦点を当てます。効果的なメモは、外部環境に変化をもたらすために何をすべきかを明確にします。
原則 5:「結論ファースト」の順序(出典:Minto、『The Pyramid Principle』)
推奨事項を最後に持ってくる「論理的な盛り上がり」を決して作らないでください。まず結論を述べ、その後に裏付けを示します。経営幹部は意思決定をするために報酬を得ています。何を決めるのかがわかるまで、6ページ目まで待たせてはいけません。
このスキルを使う場面
- 経営幹部に提案を提出する前。
- 同僚の PRD や戦略ブリーフをレビューするとき。
- 会議で「決定に至らなかった」または「さらなる調査が必要」となった後に文書を監査するとき。
- 長いレポートを「1ページ資料」にまとめるとき。
このスキルを使わない場面
- 論理がまだ固まっていないブレインストーミング/アイデア創出の段階。
- 意思決定を必要としない、非公式な進捗報告や状況報告。
中核となるプロセス
ステップ 1:「完成したスタッフワーク」の監査(出典:Web)
次のように問いかけます。「今日これを CEO に提示したら、CEO は『はい』か『いいえ』と答えるだけで済むだろうか?」
- 答えが「X を調べる必要があります」なら、メモは不合格です。
- 文書が読み手に暗黙のうちに残している「やること」をすべて特定します。
ステップ 2:SCQ の論理チェック(出典:Minto、『The Pyramid Principle』)
構成の流れを検証します。
- 状況: 背景は誰もが同意する内容ですか?
- 複雑化: 文書が必要になった「きっかけ」は明確ですか?
- 問い: 文書は、複雑化によって生じた実際の問いに答えていますか?
ステップ 3:MECE ストレステスト(出典:Minto、『The Pyramid Principle』)
箇条書きや根拠となるポイントのまとまりをすべて確認します。
- 重複チェック: ポイント A は、実際にはポイント B の一部ではありませんか?
- 抜けのチェック: 結論を無効にする「中間部分の欠落」はありませんか?
- 一貫性チェック: そのまとまりに含まれるすべてのポイントは、同じ「種類」ですか?
ステップ 4:Amazon の「ナラティブ」チェック(出典:Bryar、『Working Backwards』)
「PowerPoint の論理」(断片やリスト)をナラティブ形式の文章に置き換えます。
- 文書は因果関係に沿った順序になっていますか?
- 指標は、単に「結果ベース」(売上/成長)ではなく、「インプットベース」(制御可能)になっていますか?
- 最も想定される「よくある質問」5~10 件を予測し、回答していますか?
ステップ 5:ドラッカーの「貢献」フィルター(出典:ドラッカー『経営者の条件』)
「問い」を見直します。
- 組織の外部環境における成果に焦点を当てていますか?
- 取捨選択(何をしないのか)が明示されていますか?
フレームワークとモデル
Amazon の 6 ページ文書の構成(出典:ブライアー『Working Backwards』)
- はじめに: 目的と範囲。
- 目標/インプット: 達成しようとしていることと、管理可能なインプット。
- 基本方針: 意思決定を導く原則。
- 事業の現状: データと現在の状況。
- 学んだこと: これまでに明らかになったこと。
- 戦略的提案: 「完成したスタッフワーク」としての施策。
「異論」のルール(出典:ドラッカー『経営者の条件』)
文書に考え得る最も強力な反論が含まれていると、内容を厳しく検証できます。リスクや代替案に触れずに「完全な合意」を示す文書では、意思決定が「結果論」による誤りとなる可能性が高くなります。
他のスキルの呼び出し
必須のサブスキル:non-fiction-precision — 文章が検証できるほど明確になるようにします。 推奨のサブスキル:assumption-audit — 論理の根拠となるデータを検証します。
よくある間違い
- 「最後まで待たせる」提案: 文書の最後まで要点を示さないこと。(出典:ミント)
- 「意見を聞く」メモ: 「Y であるため、X を推奨します」ではなく、上司に「どう思いますか?」と尋ねること。(出典:Web、Completed Staff Work)
- 無差別な詳細の羅列: 一つの印象にもつながらない詳細を大量に盛り込むこと。(出典:マクフィー/ドラッカー)
診断チェックリスト
- 具体的で実行可能な提案がありますか?
- メモは「なぜ今なのか?」と「なぜ私たちなのか?」に答えていますか?
- 裏付けとなるすべての論点は MECE(相互排他的かつ全体網羅的)ですか?
- 文書だけで内容を把握できますか(プレゼンテーションが不要ですか)?
- 最も強力な反論に対処していますか?
出典
- ミント、バーバラ。The Pyramid Principle。第 1~3 章(論理と構成)。
- ドラッカー、ピーター。The Effective Executive。第 3 章(貢献)、第 7 章(効果的な意思決定)。
- ブライアー、コリン。Working Backwards。第 5 章(ナラティブ/6 ページ文書)。
- Wikipedia。「Completed Staff Work」。