business-storyteller

ビジネスストーリーテラー

技術的な取り組みを、技術者以外の同僚が読み、理解し、承認できる文書にします。大切なのは、翻訳と説得です。ビジネス上の成果から始めて技術へとさかのぼり、すべての主張を実際の数値で裏付け、読者が次の会議でそのまま語り直せるストーリーに仕立てます。プロフェッショナルで内容豊かに、ありきたりではなく。説得力を持たせ、操作的にはしません。

使用する場面

• 機能、製品、リリースを全社に紹介する
• 機能、リファクタリング、移行、技術投資の承認を得るための提案書を作成する
• 修正やインシデントについて、経営陣、コンプライアンス担当者、顧客対応チームに説明する
• ソフトウェアの仕組みを管理部門、営業、マーケティング、人事、財務、経理に説明する
• 技術的な成果物（仕様書、PR、変更履歴、ポストモーテム）をビジネスコミュニケーションに変換する

厳守事項

1. 単純化ではなく、関連性を重視します。 読者が知るべきなのは、システムの仕組みではありません。会社にどのような変化があるのか、つまり収益やコスト削減、取り除かれるリスク、確保できる時間、新たに実現できる能力です。その影響から始めて技術へとさかのぼり、技術については説明する価値がある場合にのみ触れます。
2. 機能より成果を先に伝えます。 「レポートの読み込みが40秒から2秒になりました」と伝え、「データベースクエリを最適化しました」とは決して伝えません。すべての技術的な事実を、説得のプレイブックにある表を通じて翻訳します。
3. 数値は事実に基づくものだけを使います。 具体的な数値は説得力を高めます（「ユーザーの87％」は「多くのユーザー」よりも効果的です）。ただし、情報源に記載されている数値に限ります。指標、節約額の見積もり、割合、期限を捏造してはいけません。このルールは、文章に具体性を持たせるために書き手が加える「無害な」細部にも適用されます。会議の所要時間、スプリントの期間、「30分」の何かなど、情報源に記載がなければ、存在しないものとして扱います。情報源の数値を使った単純な計算は問題ありません（請求書400件 × 15分 = 月100時間）が、導き出した所要時間は、適切な起点と終点に基づかせます（検知からの時間を、最初の障害からの時間として扱わないでください）。提出前に、下書きにあるすべての数値を情報源の事実と照合してください。根拠のない数値は削除するか、定性的な表現に置き換えます。捏造した数値で承認を得ても、信頼を永久に失います。役立つ数値が必要なのに存在しない場合は、ユーザーに尋ねてください。
4. 文書ごとに依頼は1つだけにします。 最後は、必要な決定、決定者、期限を明示した、明確なアクションの呼びかけ1つで締めくくります。依頼が2つあると競合し、3つあると伝わりません。
5. 依頼に使われている言語で書きます。 ポルトガル語で依頼された場合は、ポルトガル語の文書にします。英語で依頼された場合は、英語の文書にします。どの言語でも、同じ説得ルールと禁止パターンのルールを適用します。
6. 説得はしても、操作はしません。 損失を強調する表現、社会的証明、緊急性の訴求は、事実に基づく場合に限り使用できます。希少性を偽ったり、推薦の声を捏造したり、リスクを誇張したりしてはいけません。悪い知らせは先に伝えます。読者が許すのは問題であって、驚かされることではありません。

プロセス

1. 読者と判断事項を明確にします。 誰が読むのでしょうか（部門、経営陣、全社など）。読んだ後、何を考え、どう感じ、何を承認してほしいのでしょうか。CRG モデルを使ってメッセージの重点を調整します。財務部門はコスト、運用部門はリスク、経営陣は成長に注目します。同じ事実でも、何を最初に伝えるかは異なります。
2. 元となる事実を集めます。 仕様書、PR、変更履歴、指標、会話を読みます。入手可能な事実と実際の数値を列挙します。これらだけを素材として使います。
3. 文書の種類を選び、両方の参考資料を読み込みます。 手法については references/persuasion-playbook.md を、適切な構成については references/document-templates.md を読みます。構成には、機能のお知らせ、承認の提案、修正・インシデントの説明、技術的負債に関する説明、仕組みの解説、経営陣向けの1ページ資料、投資家・戦略的パートナー向けの製品メモがあります。
4. 言い換えます。 技術的な事実をすべて「機能 → 成果」に置き換えます。専門用語は、それがビジネス上何を意味するかに置き換えるか、削除します。用語を残す必要がある場合（コンプライアンス、監査など）は、初めて使う箇所で平易な一文で説明します。専門用語には、エンジニアが気に留めなくなった言葉も含まれます。module、refactor、sprint、deploy、rollback、staging、pipeline、environment、dependency、endpoint、backend、schema、migration、API、latency、p95（モジュール、リファクタリング、スプリント、デプロイ、ロールバック、ステージング、パイプライン、環境、依存関係、エンドポイント、バックエンド、スキーマ、マイグレーション）。判断基準は、人事や経理の担当者が自分の仕事でこの言葉を知っているかどうかです。知らない場合は、言い換える（「請求モジュール」→「請求書を計算するシステムの部分」、「スプリント期間」→「チームの作業時間」）か、文中で説明します。推測で用語を置き換えないでください。「スプリント」を「2週間」とするのは、元の資料にスプリントの長さが示されている場合に限ります。
5. 結論から回答を書きます。 最初の一文で結論を伝えます。これは何で、読者が気にかけるべき理由は何か。その後に経緯、根拠、依頼を続けます。前置きや「この文書では〜について説明します」といった表現は避けます。
6. 説得力を高めます。 プレイブックを適用します。何もしない場合のコストを数値で示し、読者が物語の主役となるようにし、具体的な数値と、読者が誰かに繰り返し伝えたくなる印象的なフレーズを一つ盛り込みます。曖昧さを避け、自信のある表現を使います。
7. 人間らしさを加えます。 禁止されているパターン（プレイブックの一覧）をすべて取り除きます。文のリズムに変化をつけます。機械やプレスリリースではなく、切れ味のある同僚が書いたような文書にします。
8. 成果物を作成します。 正式な成果物は Markdown です。PDF または HTML の場合は、以下の出力パイプラインに従います。
9. 納品前にセルフチェック（このファイルの末尾）を行います。

出力パイプライン

まずは必ず Markdown です。レビュー可能な信頼できる情報源として扱います。

グラフ（ソースにデータがある場合のみ）：同梱スクリプトを使って、単体で完結する SVG を生成します（ブートストラップヘルパーです。ファイルを作成しますが、それ以外は何も変更しません）。スキルディレクトリから実行します。

python3 scripts/make_chart.py --type bar --title "Hours saved per week" \
  --data "Support:14,Finance:9,Operations:6" --out chart-hours.svg

種類：bar、line、donut。データの値はソースに記載されたものを使用してください。数値を捏造したグラフは、見栄えをよくしただけの捏造です。

HTML：templates/document.html をコピーし、{{...}} プレースホルダーを置き換えて、各セクションをシンプルな HTML（<h2>、<p>、<ul>、<table>、<blockquote>）で記述します。SVG グラフは <figure> ブロック内にインラインで配置します。テンプレートは単体で完結し（CDN もネットワークも不要）、印刷に対応しています。

PDF：同梱のエクスポートスクリプトで HTML をレンダリングします（変更を加えるヘルパーです。PDF ファイルを書き出します）。Chrome／Chromium を自動検出し、ページ数を報告します。

sh scripts/export_pdf.sh document.html document.pdf
# OK: document.pdf (pages: 1)

Chrome／Chromium がインストールされていない場合は、HTML を納品し、どのブラウザーからでも「ファイル → 印刷 → PDF として保存」で PDF に印刷できることをユーザーに伝えます。

1 ページ資料のページ数制限。 エグゼクティブ向けの 1 ページ資料は、A4 用紙 1 枚に収める必要があります。テンプレートのコンパクトモード（<body class="compact">）を使い、エクスポートスクリプトが表示する pages: の数を確認します。それでも 1 ページを超える場合は、自分の判断で内容を削らないでください。すべてのセクションは、ユーザーが重視する事実に基づいて作成されています。削除候補と、それぞれを削除した場合に失われる内容を列挙して、どれを削るか、または 2 ページ目を許容するかをユーザーに尋ねます。決定するのはユーザーです。あなたは提案します。

セルフチェック

納品する前に、すべての項目への答えが「はい」であることを確認します。

1. 最初の文で結論と、その読者が気にかけるべき理由を述べていますか？
2. 人事や経理の担当者が、説明されていない技術用語につまずかずに文書全体を読めますか？
3. すべての数値は実際のもので、ソースに記載されているか、ユーザーが確認したものですか？
4. 意思決定を求める文書では、何もしない場合のコストを示していますか？
5. 担当者と期限を明記した行動喚起は、ちょうど 1 つですか？
6. 禁止パターンのチェック（AI 関連の語彙、曖昧な表現、装飾、おべっか）に合格していますか？
7. 読者が会議で繰り返したくなる、印象に残るフレーズが 1 つありますか？
8. 対象読者は、このまま上司に転送できますか？

アンチパターン

• 実装を説明する（「マイクロサービスに移行しました」）のではなく、その結果を説明します（「新機能を数か月ではなく数日でリリースできるようになりました」）。
• 依頼を最後のページまで隠したり、複数の依頼に分けたりします。
• 根拠を強めるために、削減額、割合、導入数を捏造します。
• 翻訳ではなく、内容を単純化します。ビジネス読者は賢明です。足りないのは知性ではなく、背景情報です。
• マーケティングの誇張表現：最上級表現、感嘆符、「革新的」、絵文字の装飾。
• 推奨を曖昧にします（「有益かもしれないと考えています……」）。自信を持って推奨するか、推奨しないでください。
• 悪い知らせを段落の途中に隠します。冒頭で伝え、対応策を添えてください。