仮想通貨ホワイトペーパーの書き方：読者が理解できる構成

執筆前にどこから始めるべきですか？

まず、ペーパーが誰のためのものか、その読者が何を理解する必要があるかを決めます。短い準備手順で初稿の焦点が定まります。

1. 読者を特定する。 主な対象読者（製品ユーザー、開発者、パートナー、トークン保有者など）を選びます。
2. ペーパーの役割を設定する。 読者が読了後に何を理解すべきかを書き出します。
3. プロジェクトを平易に説明する。 問題、提案する解決策、プロジェクトの現在の段階を述べます。
4. 質問をリストアップする。 製品の使い方、システム設計、トークンの役割に関する、この読者にとって重要な質問を含めます。
5. 情報源の担当者を見つける。 各トピックについて、確認できる人物またはドキュメントを割り当てます。

AMA前夜の小さなパートナーシップチームを想像してください。彼らが必要としているのは、バラバラな主張の山ではなく、プロジェクトの簡潔な説明です。私たちは、ペーパーで説明すべきことをリストアップし、共有前にチームチェックが必要なポイントをマークする手助けをします。

チームがプロジェクトを数行の平易な文章で説明できない場合は、一旦立ち止まってください。章を書き始める前に、中心となるアイデアを一緒に練り上げましょう。この小さな中断が、繰り返しの説明や、すべての読者に同時に応えようとするペーパーを防ぐことができます。

読者にプロジェクトを理解する道筋を提供する

役立つ構成は、読者の問題からプロジェクトの解決策へと進み、システムとその未解決の疑問を説明します。コアとなる説明を早い段階に置き、読者がプロジェクトの目的を探し回らなくて済むようにします。

柔軟な順序として、短い概要から始めることができます。次に、問題と影響を受ける人々を紹介します。その次に製品と主要なユーザージャーニーを説明します。システムの設計を示し、該当する場合はトークンの役割を説明します。最後にプロジェクトの状況、依存関係、リスクを述べます。チームの詳細、情報源、開示事項は、読者が資料を評価するのに役立つ場合に追加します。

例えば、読者が製品の内容を知る前にトークン配分表を見たとします。それでは、なぜその配分が重要なのかを理解するのが難しくなるかもしれません。製品の説明を先に置き、各トークンの機能をシステムの実際の部分に結びつけましょう。

これは必須の章のリストではなく、道筋として扱ってください。ペーパーの目的に沿わない素材は省き、省略が読者にとって混乱を招く可能性がある場合はその理由を説明します。図は、誰が行動し、何が動き、ユーザーが何を観察できるかを示す場合に、流れを明確にします。図は文章による説明と一貫性を保ちます。トークンローンチチェックリストは、ペーパーが他のローンチ資料とどのように整合するかを確認するのに役立ちます。

ペーパーに何をいつ含めるべきですか？

読者がプロジェクトを理解したり、重要な主張を確認したりするのに役立つトピックを含めます。以下の表は実用的な出発点です。プロジェクトと読者に合わせて調整してください。

すべてのトピックに均等なスペースを与える必要はありません。技術的な読者には、構成要素や依存関係についてより詳細な説明が必要かもしれません。より広い読者層には、製品の流れやトークンの目的をより簡単な言葉で説明する必要があるかもしれません。いずれの場合も、専門用語は最初に登場した時点で定義します。

機能がまだ構築中であれば、稼働中ではなく計画中と明記します。トークンの数値が確定しているのか提案段階なのかを明記します。詳細がペーパーの目的の範囲外である場合は、読者が推測しなくて済むように、その旨を明確に述べます。当社のホワイトペーパーおよびライトペーパー作成のページでは、文書作成のサポートがどのように役立つかを説明しています。

読者は重要な主張をそれぞれ確認できますか？

重要な主張に明確なステータスと情報源があれば、読者はペーパーをより容易に評価できます。執筆中は、各主張を現在の事実、設計意図、仮定、または計画としてマークします。この単純な区別により、チームは将来の作業を既に利用可能なものとして提示することを防げます。

ドラフトの横に作業用の主張リストを保持します。各ポイントについて、表現、ステータス、情報源、確認できる人物を記録します。製品機能に関する記述は、デモや製品ドキュメントを参照する場合があります。システムの動作に関する記述は、技術担当者に確認を依頼します。トークンの説明は、チームの現在承認されている情報と照合します。

図、表、本文では同じ名称と用語を使用します。重要な主張に情報源がない場合は、チームが別の方法で裏付けられるかどうかを確認します。必須でなければ削除します。まだ不確かな場合は、その不確かさと原因を平易な言葉で説明します。

二次チェックとして、執筆グループ以外の誰かに、概要を読んだ後にプロジェクトを説明してもらいます。彼らがどこで躊躇したり、異なる説明をしたりするかに注目します。その箇所は、単に言葉を滑らかにするだけでなく、より明確な説明が必要な場所を示しています。

小さな作成上のミスが大きな疑問を残す

見つけにくい問題は、多くの場合セクション間のギャップです。最終レビューでは、スペルやレイアウトだけでなく、矛盾や欠落した文脈を探す必要があります。

• 曖昧な目的： 読者は誰のために製品があるのか、何を変えるのかがわからない。
• 計画が事実として書かれている： 将来の機能が今日利用可能であるかのように聞こえる。
• ラベルのないトークンの詳細： 読者は数値が何を説明しているのか、確定しているのかがわからない。
• 確認されていない主張： 設計、セキュリティ、パフォーマンスに関する記述に情報源が明記されていない。

簡単な読み合わせを試みます。プロジェクトに詳しくない人に、何が稼働中で、何が計画中で、トークンがどのように適合するかを説明してもらいます。その説明をチームの意図した説明と比較します。混乱を招く箇所を修正し、関連セクションで同じ問題がないか確認します。

ホワイトペーパーはプロジェクトを説明できますが、法的コンプライアンスを確立したり、取引所からの承認を保証したりすることはできません。それらの判断は、関連するアドバイザーやプラットフォームに委ねられており、それらのレビューや要件は文書作成者の管理外です。

作成計画が必要な場合は、ホワイトペーパー作成費用ガイドと作業内容を比較してから、どのようなサポートが適切かを判断してください。

プロジェクトの変更に合わせてペーパーを最新に保つ

公開されたペーパーは、誰かがプロジェクトの現状と整合性を保つことで有用性が維持されます。製品機能、トークンの詳細、重要な依存関係が変更されたことに気づける担当者を選びます。

明確なバージョンラベルを付け、ペーパーを改訂するたびに変更内容を記録します。散文とともに図、参照、定義された用語も再確認します。以前のバージョンが利用可能な場合は、読者にバージョン間の変更点を理解するための短い注記を提供します。

ペーパー公開後にチームが製品フローを更新したと想像します。担当者は新しいフローとペーパーを比較し、それを説明するすべての箇所を見つけます。次に、技術担当者に置き換えテキストの確認を依頼します。このチェックにより、メンテナンスが作成計画の一部となり、後付けではなくなります。

ウェブサイトの概要、トークン資料、ローンチコミュニケーションをペーパーの説明と一貫させます。もしセカンドオピニオンが必要でしたら、Brand Communityに現在のドラフトまたはメモをお送りください。対象読者と、製品、技術、トークンの詳細を確認できる人物の名前を含めてください。まずアウトラインをレビューし、執筆前に解決すべき質問を特定します。さらに実践的な読み物はブログでご覧いただけます。

仕組み

1. 読者と目的を設定するペーパーの対象者と、彼らが理解すべきことを書き出します。何が稼働中で、計画中か、未決定かをマークします。
2. 情報源と担当者を集める製品ノート、技術資料、承認済みのトークン詳細を収集します。各トピックを確認できる人物を指名します。
3. アウトラインを整理する読者の主な質問を明確な順序に並べます。執筆前に不足情報を解決します。
4. ドラフトを作成し確認する平易な言葉を使用し、仮定を明記します。関連するチームメンバーに、情報源に基づいて主張を確認してもらいます。
5. 修正とメンテナンスコメントを解決し、用語を確認し、承認済みバージョンを記録します。プロジェクトの詳細が変更された場合にペーパーをレビューする担当者を割り当てます。