仮想通貨ホワイトペーパーの書き方：懐疑的な読者にも伝わる構成

読者は何を判断できればよいのか？

クイックテスト： チーム外の誰かにドラフトを渡し、確認できない主張にすべて下線を引いてもらいましょう。どのセクションに証拠が必要かがすぐにわかります。

仮想通貨ホワイトペーパーは、読者がプロジェクトの提案内容、意図された動作、および不確定な点を理解するのに役立つものであるべきです。執筆を始める前に、誰がドキュメントを必要とし、読後に何を評価できればよいのかを決めてください。開発者にはアーキテクチャの詳細が必要かもしれません。潜在的なトークン保有者には明確なユーティリティと配布情報が必要かもしれません。パートナーにはプロジェクトの運営モデルの理解が必要かもしれません。

ドラフト作成前に、チーム向けの短いブリーフを書きましょう。以下の内容を含めます：

• 主な読者と、彼らが持ちそうな質問。
• プロジェクトが取り組む問題を、宣伝的な表現を使わずに記述。
• ドキュメントがカバーする範囲と、別のテクニカルペーパー、ロードマップ、または法的文書に属する内容。
• 読者が次に取れるアクション（例：ドキュメントの確認、チームへの連絡）。

このようなブリーフは、計画のチェックとして有用です。提案されたセクションが読者の質問に答えなかったり、プロジェクトの主張を裏付けなかったりする場合は、削除するか、そのセクションが存在する理由を説明してください。ホワイトペーパーはすべての読者に等しく対応しようとするべきではありません。プロジェクトが初期の会話のために簡潔な概要を必要とする場合、ライトペーパーの方が適切な補完となることがあります。この2つのドキュメントは、互いに繰り返すのではなく、異なる役割を持つことができます。

わかりやすい構成

優れた構成は、読者の問題から始まり、プロジェクトの提案する解決策へと進み、その設計と限界を評価するのに十分な詳細を提供します。すべてのプロジェクトに必須のアウトラインはありませんが、予測可能な順序は読者が必要な情報を見つけるのに役立ちます。

ドキュメントを次の順序で構成することを検討してください：

• 要約： 問題、提案されたアプローチ、および想定ユーザーを述べます。
• 背景とニーズ： 現在の困難とその重要性を説明します。
• 解決策とプロダクト： ユーザー体験とシステムの主要コンポーネントを説明します。
• 技術設計： 関連するアーキテクチャ、依存関係、およびコンポーネント間の相互作用を説明します。
• トークン設計： トークンが存在するかどうか、その役割、および供給と割り当てがどのように説明されているかを述べます。
• ロードマップとガバナンス： 現在の機能と計画中の作業を区別し、誰が意思決定を行うかを説明します。
• リスクと前提： 重要な依存関係、未解決の質問、および可能性のある制約を挙げます。

アウトラインをプロジェクトに合わせて調整し、その逆はしないでください。プロトコルのペーパーは、消費者向けアプリケーションの概要よりも多くの技術的説明を必要とします。図は、関係性やプロセスを明確にする場合にのみ追加し、一目で視覚情報を解釈できない読者のために、文章で説明するようにしてください。トークン情報に焦点を当てたチェックリストについては、CoinGeckoで供給を確認する方法を参照してください。ホワイトペーパー自身の供給に関する記述は、プロジェクトの記録と一致させてください。

技術的・トークンに関する主張を検証可能にする

重要な主張はそれぞれ、読者が何がそれを裏付けているかを判断できるよう、具体的に記述してください。「完全に分散化されている」や「設計上安全」といった広範な記述は、どのシステム特性を意味するのか、どのような証拠があるのか、どのようなトレードオフが残っているのかを説明していません。

重要な主張ごとに、その出典と確認責任者を記録してください。その出典は、実装済みの機能、技術文書、公開された監査、チームが承認したトークン割り当て、または明確にラベル付けされた前提である可能性があります。計画を既存の能力として提示しないでください。詳細が未決定の場合は、その旨を述べ、誰がその決定を担当するかを明記してください。

特に以下の領域に注意してください：

• アーキテクチャ： コンポーネントを挙げ、情報や資産がそれらの間をどのように移動するかを説明します。
• セキュリティ： 何がレビューされ、何がされていないかを述べます。レビューがすべてのリスクを取り除くことを暗示しないでください。
• トークンの役割： 抽象的な説明に頼るのではなく、プロダクト内での機能を説明します。
• 供給と割り当て： カテゴリ、タイミング、およびチームが実際に承認した条件を示します。
• ガバナンス： 決定権を特定し、提案された変更がどのように処理されるかを説明します。

作業用ドラフトには、主張、出典、担当者、レビューステータスを記載した証拠テーブルを保持してください。このテーブルは編集上の補助であり、それ自体が証拠になるわけではありません。公開バージョンでは、可能な限り技術用語を平易な言葉に置き換え、必要な用語は初出時に定義してください。読者は、チームの意図を推測することなく、主張を追跡できる必要があります。

執筆とレビューの工程

ドキュメントは段階的に作成し、各分野の担当者が主張を確認してから文章を洗練させてください。これにより、避けられる書き直しを減らせます。ライターは明確さを向上させることはできますが、トークンに関する決定を解決したり、チームが確定していないアーキテクチャを検証したりすることはできません。

実用的な工程は以下の通りです：

1. ソース資料を収集する。 プロダクトドキュメント、アーキテクチャノート、承認済みトークン情報、ロードマップ詳細、既存の公開声明を集めます。
2. アウトラインを設定する。 各読者の質問をセクションにマッピングし、担当者や確定した回答がないトピックをマークします。
3. 意味を重視して執筆する。 まず直接的な説明を書きます。プロジェクトの用語を一貫して使用し、用語が登場したら定義します。
4. 分野別レビューを実施する。 技術、プロダクト、トークン設計の担当者に、現在の決定とソースに照らして自分のセクションを検証するよう依頼します。
5. 編集と承認。 構成、一貫性、図、バージョン詳細、およびプロジェクトに必要な法務・コンプライアンスレビューをチェックします。

レビュアーには、漠然と「見ておいて」と頼むのではなく、具体的な依頼をしてください。例えば、エンジニアリングリーダーにはコンポーネントの説明を検証してもらい、トークン設計担当者には承認済みモデルに照らして割り当ての文言をチェックしてもらいます。マスターコピーを1つ保持し、どの変更が承認されたか、延期されたか、未解決かを記録してください。外部の執筆サポートが必要な場合は、ホワイトペーパー・ライトペーパー作成がプロジェクト資料を読者向けのドキュメントに仕上げるのに役立ちます。キックオフ前にソースパックと決定担当者を準備してください。

7項目のホワイトペーパーチェックリスト

チーム外の誰かが目にする前に、各ドラフトを以下の7項目でチェックしてください。すべての項目をクリアしていれば、Q&Aでの防御が容易になり、他のフォーマットに切り詰めるのも簡単になります。

• 1ページ目に読者と目的を明記する。
• 問題を3文以内で定義する。
• プロダクトと技術を平易な言葉で説明する。
• トークンの機能、供給、配布を説明する。
• 正直なリスクセクションを追加する。
• すべての数値を出典またはコントラクトにリンクする。
• 2名のレビュアー（技術担当1名、法務担当1名）の承認を得る。

用語の一言説明

ホワイトペーパー（平たく言えば、プロジェクトの技術、トークン、計画を説明する長文のドキュメント）。

ライトペーパーとは、概要を知りたい読者のためのホワイトペーパーの短い要約です。

信頼を損なうミス

よくあるミス： 技術セクションにマーケティング用語を混ぜてしまうこと。主張と販売コピーは分けて、読者に判断させましょう。

最も有害なホワイトペーパーのミスは、通常、不整合、根拠のない確信、およびプロジェクトを説明するどころか曖昧にする詳細です。洗練されたレイアウトは、プロダクトや互いに矛盾する主張を修復することはできません。

レビュー中は以下の問題に注意してください：

• 汎用アウトラインのコピー： プロジェクトにない機能に関するセクションは、ドキュメントの信頼性を損なう。削除するか、その関連性を説明する。
• 現在形と未来形の混在： 利用可能なもの、構築中のもの、提案のみのものを明確に区別する。
• トークン用語を定義せずに使用する： トークンがプロダクトの使用、ガバナンス、または他の明示された機能とどのように関連するかを説明する。
• 割り当ての文言を曖昧にしたままにする： 読者には一貫したカテゴリと関連条件の説明が必要であり、宣伝的な略語は不要。
• 絶対的なセキュリティやパフォーマンスの主張をする： ドキュメントが立証できない結果を主張する代わりに、設計と証拠を説明する。
• ピッチの繰り返し： ホワイトペーパーは実質的な質問に答えるべきであり、スローガンを全セクションで繰り返すものではない。
• 図がテキストと矛盾する： ラベル、フロー、バージョンを文章の説明と照合する担当者を割り当てる。

最終的な一貫性チェックでは、ホワイトペーパーをウェブサイト、ドキュメント、トークン資料、および現在のプロダクトステータスと比較してください。詳細が異なる場合は、どのソースが最新かを判断し、他方を更新します。より広範なプロジェクトローンチの流れについては、トークンローンチマーケティングチェックリストをドキュメントレビューと併せてご利用ください。

ホワイトペーパーが証明できることと、さらなるレビューが必要なこと

ホワイトペーパーはプロジェクトの設計を説明し、その主張の根拠を開示することはできますが、未決定の設計を完成させたり、専門家によるレビューを代替したりすることはできません。これは、技術的検証、法的助言、または正確なプロダクト記録の代わりではなく、保守されるプロジェクト文書として扱ってください。

限界とリスク： 技術的な説明は実装の変更に伴って古くなる可能性があり、トークンやコンプライアンスに関する質問は、責任あるプロジェクト担当者および資格のあるアドバイザーによる確認が必要です。明確なドキュメントは読者が記載された情報を精査するのに役立ちますが、システムが説明どおりに動作することを保証したり、外部の関係者がどのように解釈するかを確定したりすることはできません。

公開前に、ドキュメントを維持する担当者を割り当て、レビューのトリガーを設定してください。有用なトリガーには、プロダクト、アーキテクチャ、トークン設計、ガバナンス、またはロードマップへの重要な変更が含まれます。バージョン日付を記録し、変更内容を要約して、読者が最新情報と以前のドラフトを区別できるようにしてください。図のソースファイルを保持し、主張の承認に使用された証拠を保存してください。

ホワイトペーパーが取引所やデータプラットフォームへの申請をサポートする場合は、その事実詳細をプロジェクトの提出資料と整合させてください。ドキュメント自体がプラットフォームの審査結果を決定するわけではありません。それらの申請プロセスについては、CoinMarketCap上場およびCoinGecko上場の個別ガイドを参照してください。簡潔で一貫性のあるソースドキュメントは、チームがプロジェクトを説明するのを容易にしますが、各プラットフォームは独自の判断を行います。

ライトペーパーの方が適しているのはどんな時か？

ライトペーパーは、当面の目標が読者にコンパクトな紹介を提供することである場合に適しており、フルホワイトペーパーは、読者が設計とその前提についてより深い説明を必要とする場合に有用です。名称だけが計画を定義するわけではありません。読者が何を評価する必要があるか、そしてチームがどれだけの裏付けのある資料を準備しているかに基づいて決定してください。

ライトペーパーは、すべての技術的選択を文書化しようとせずに、問題、プロダクト、トークンの役割、および次のステップを紹介することができます。より充実したホワイトペーパーは、アーキテクチャ、ガバナンス、供給、依存関係、およびリスクについて詳しく説明できます。短いフォーマットは、重要な注意事項を隠したり、未解決の計画が確定していると暗示したりするべきではありません。両方のドキュメントが存在する場合は、各詳細についてどちらが真実のソースであるかを決定し、決定が変更されたときにそれらを一緒に更新してください。

フォーマットを選択する前に、以下の判断チェックを使用してください：

• 想定読者は提案を理解するために実装の詳細を必要としますか？
• プロジェクトの中心的な主張は、ソース資料と担当者レビューによって裏付けられていますか？
• チームは公開を計画している詳細レベルを維持する準備ができていますか？
• 今は短い概要の方が有用で、後により詳細なドキュメントを追加する方がよいですか？

ドラフトを準備する場合は、MarketingExtraに現在のバージョン、プロジェクトドキュメント、承認済みトークン情報、および技術的・プロダクトの主張を検証できる人物の名前を送ってください。私たちは資料のギャップをレビューし、明確なホワイトペーパーまたはライトペーパーの計画を立てるお手伝いをします。ホワイトペーパー作成概要から始めてください。

仕組み

1. 読者と目的を設定する誰のためにドキュメントがあり、彼らが何を理解する必要があるかを書き留めます。これを使ってホワイトペーパーに何を含めるかを決定します。
2. 現在のプロジェクトソースを収集する技術、プロダクト、トークン、ロードマップ、ガバナンスの資料を集めます。欠落している決定事項にフラグを立て、それぞれに担当者を割り当てます。
3. 主張を証拠にマッピングする重要な記述について、出典と検証者を記録します。実装済みの機能と計画・前提を分離します。
4. 執筆し、焦点を絞ったレビューを実施する読者にとってわかりやすい順序で書き、関連する分野の担当者に自分たちが管理するセクションをチェックしてもらいます。
5. ドキュメントを承認し、維持する公開前に、一貫性、バージョン詳細、図、および必要な専門家レビューをチェックします。将来の更新のために担当者を割り当てます。