nob-git-dev 伝わるビジネス文書
目的
会話や断片的な情報を、元の文脈を知らない第三者が理解・判断・行動できる日本語文書へ再構成する。 表面的な要約ではなく、読者の疑問に沿って論理を組み直す。
参照する資料
- 常に references/writing-principles.md を読み、文章原則を適用する。
- 新しい概念、仕組み、判断基準を説明するときは references/concept-staircase.md を読む。
- 文書形式を決めるときは references/document-patterns.md を読む。
- 最終稿を出す前に references/evaluation-rubric.md で監査する。
- 成果物ファイルを作る場合は、用途に合う assets/ のテンプレートを複製して使う。
作業手順
1. 執筆条件を定める
次を入力から特定する。
- 想定読者
- 文書の目的
- 読後に理解・判断・実行してほしいこと
- 文書形式と長さ
- 必ず残すべき事実
- 不確実な情報の扱い
指定がなくても作業を止めず、結果を大きく変えない範囲で妥当な前提を置く。前提が重要な場合だけ、完成稿の後に短く明示する。
2. 情報を分類する
執筆前に、入力を次へ分ける。
- 確認できる事実
- 発言者または資料による解釈
- 未検証の仮説
- 提案
- 決定事項
- 採用しなかった案
- 未解決事項
- 次の行動
入力にない事実を補わない。矛盾する情報を一つに丸めない。推測を事実に格上げしない。
3. 読者の疑問を並べる
会話の時系列ではなく、初見の読者が抱く疑問の順に構成する。
基本順序を次とする。
- これは何の話か
- なぜ重要か
- 何が起きているか
- 従来の理解では何が足りないか
- どのように考えるべきか
- 根拠は何か
- 何を決める、または実行するのか
- 何が未解決か
内容に応じて不要な問いを削る。
4. 構成を作る
各節を一つの問いへの回答にする。見出しを単なる分類名ではなく、問い、結論、または意味のある要約にする。 各節の結論を次節の前提として使い、論理を一段ずつ進める。
新概念の説明では、次の順序を優先する。
観察できる現象 → 矛盾 → 既存説明の限界 → 原因仮説 → 概念の命名と定義 → 適用 → 行動
5. 初稿を書く
- 結論または中心問題を早い段階で示す。
- 主張と根拠を近くに置く。
- 数字や事例を示したら、その意味まで説明する。
- 抽象説明が続いたら、具体例、比較、観察可能な事実のいずれかを置く。
- 長い説明の後に短い要約文を置き、リズムを作る。
- 問いを置いたら、直後または同じ節で答える。
- 専門用語を初出時に短く説明する。
- 事実、解釈、仮説、提案の確度を表現で区別する。
6. 意味を監査する
元の入力と照合し、次を確認する。
- 重要な事実や決定が欠けていないか
- 発言者の意図を強めたり弱めたりしていないか
- 因果関係を飛躍させていないか
- 根拠のない断定を加えていないか
- 未解決事項を解決済みに見せていないか
問題があれば構成から直す。表現だけで隠さない。
7. 読みやすさを監査する
- 冒頭だけで目的と要点が分かるか
- 一つの段落に中心メッセージが一つだけあるか
- 各段落の冒頭から役割を判断できるか
- 「これ」「それ」の参照先が明確か
- 接続表現が実際の論理関係と一致しているか
- 重複、前置き、内容のない強調を削れているか
- 読者が次に何をすべきか分かるか
8. 完成稿を渡す
完成した文書を先に提示する。作業過程や自己評価は、求められない限り付けない。 重要な前提、確認できなかった情報、未解決事項がある場合だけ、完成稿の後に短くまとめる。
文体上の境界
- 特定の存命作家の固有表現、口癖、比喩、語彙の組み合わせを再現しない。
- 参考文章からは、構成、論理展開、具体化、読者案内など一般化可能な技法だけを使う。
- 強い一般化、人格攻撃、世代や集団への決めつけ、根拠のない予言を引き継がない。
- 読みやすさのために内容を単純化しすぎない。
- 自信のある文体と、主張の確度を混同しない。
書き直しの優先順位
文字数を削る場合も、次の順に保護する。
- 結論と目的
- 結論を支える因果関係
- 重要な事実と決定
- 未解決事項と次の行動
- 具体例
- 補足説明
意味を保てない場合は、無理に指定文字数へ収めず、何を省略したかを明示する。