仮想通貨ホワイトペーパーの書き方：プロジェクトの事実を読みやすい文書に

冒頭で読者に何を確認させるべきですか？

一文の目的文は、読者にホワイトペーパー全体を検証する基準を与えます。プロジェクト、対象読者、および文書がサポートする意思決定や理解を特定する必要があります。その目的は、市場に関する広範な約束ではなく、製品に固有のものにしてください。

ドラフトを作成する前に、主たる読者を選びます。開発者はコンポーネントの動作や統合の前提条件を必要とするかもしれません。将来のユーザーは製品フローとその現在の制限を必要とするかもしれません。トークン保有者は文書化されたトークン機能とガバナンスルールを必要とするかもしれません。ホワイトペーパーは複数のグループに役立つ可能性がありますが、最初の読者を明示し、それに応じて詳細を整理します。

以下の4つのプロンプトで短いインテークノートを作成します。

• プロジェクトはどのような問題を、誰のために解決しますか？
• ユーザーまたは開発者は現在何ができますか？
• どの機能が提案中または開発中ですか？
• 読者は読了後に何を評価できるようになるべきですか？

各回答を「稼働中」「テスト済み」「計画中」「未解決」としてマークします。このステータス用語は、ロードマップの項目が利用可能な機能のように読まれるのを防ぐのに役立ちます。プロジェクトが初期段階にある場合は、まだ不明な点を明記します。次に、目的文を使用して、指名された読者がプロジェクトを理解または評価するのに役立たない箇所を削除します。

ホワイトペーパーのドキュメントマップにはどの部分を含めるべきですか？

7部構成のアウトラインは、読者をプロジェクトの問題から未解決の質問へと導くことができます。必須のテンプレートではなく、作業用マップとして扱います。このプロジェクトにとって重要なことを説明する場合にのみセクションを追加します。

有用な順序は以下の通りです。

• 要約： 問題、アプローチ、現在の開発状況。
• 問題と背景： 誰が問題に直面し、既存のアプローチでは何が未解決か。
• 製品またはプロトコル： コンポーネント、ユーザーフロー、システム境界。
• 技術設計： 関連するアーキテクチャ、依存関係、セキュリティの前提条件。
• トークン設計（該当する場合）： 機能、供給ルール、割り当て、ガバナンスの仕組み。
• ロードマップと責任： 計画された作業、意思決定の担当者、依存関係。
• リスクと未解決の質問： 既知の制限と未解決の設計上の選択。

トークンのないプロジェクトにトークンエコノミクスを追加しないでください。トークンプロジェクトの場合、コアとなる仕組みを付録に埋もれさせないでください。専門的な詳細の前に短い説明を配置します。主張をサポートするが、主要な説明を中断させる資料には付録を使用します。

ホワイトペーパーを超えたローンチ計画については、トークンローンチチェックリストを参照してください。プロジェクトの事実をホワイトペーパーと整合させてください。上場準備の概要については、CoinMarketCap上場およびCoinGecko上場のガイドを参照してください。これらのリソースは異なるタスクを扱っており、プロジェクトがプラットフォームの要件を満たしていることの証拠として使用すべきではありません。

読者はどのように主張をその出典までたどれますか？

主張のインベントリは、散文を洗練する前にどの記述に検証が必要かを示します。製品の動作、トークンの仕組み、セキュリティの前提条件、またはプロジェクトのステータスに関する重要な記述ごとに作成します。この記録により、ドラフトがまだ変更しやすいうちにギャップを可視化できます。

各エントリに4つのフィールドを使用します。正確な主張、出典または明示された前提条件、ステータス、レビュアーです。当社のデフォルトレビューでは、出典の一致、ステータスの一致、担当者の承認の3つのチェックポイントを使用します。製品マニュアルはユーザーフローの説明をサポートする場合があります。設計記録はアーキテクチャ上の決定を説明する場合があります。予測は推定値として特定し、観測された結果として提示しないでください。裏付け資料がない場合は、記述を限定するか削除します。

トークンに関する箇所には正確な定義が必要です。各供給用語の意味と、割り当てまたはリリースルールの仕組みを説明します。どのルールが文書化されており、どのルールがガバナンスまたは他の明示されたプロセスを通じて変更される可能性があるかを特定します。プロジェクトの条件がその解釈をサポートしない限り、トークンを保有することで権利が付与されることを示唆しないでください。

この記録は、将来の編集者が製品変更の影響を受けるテキストを見つけるのにも役立ちます。そのエントリをプロジェクトの現在の資料およびトークンローンチチェックリストと比較します。GeoMarketing Expertsでは、レビュアーは担当者ごとにグループ化された質問とともにマークされたドラフトを返却できます。執筆業務については、ホワイトペーパーおよびライトペーパー作成を参照してください。有償作業の範囲については、仮想通貨ホワイトペーパー料金を参照してください。

メインのペーパーにはどの程度の技術的詳細を含めるべきですか？

システム図とそのキャプションは、散文と同じストーリーを伝える必要があります。技術的詳細を使用して、コンポーネントがどのように相互作用し、その動作がどのような前提条件に依存しているかを示します。チェーン、コントラクト、または暗号用語のリストだけでは、それらの関係がなければ不十分です。

平易な言葉によるシステム概要から始めます。次に、各重要なコンポーネントをその役割、入力、出力、依存関係によって説明します。複数のアクターが関与するプロセスの場合は、誰がアクションを開始するか、システムが何をチェックするか、依存関係が利用できない場合に何が起こるかを特定します。専門用語は最初の使用時に定義します。文書全体を通じて、1つの用語を1つの意味に結びつけます。

図を使用して、フロー、信頼境界、またはデータの移動を示します。図に含まれるものと含まれないものを示すキャプションを追加します。図は、オフチェーンプロセスがスマートコントラクトによって強制されていることを示唆してはなりません。読者がホワイトペーパーの目的を超えた実装の詳細を必要とする場合は、より詳細な技術文書にリンクします。

重要な図ごとに2つのチェックを実行します。ラベルがテキストと一致することを確認し、次に技術レビュアーに図示された動作を検証するよう依頼します。各図について、目的、コンポーネント、境界、レビュアーの4つのフィールドを記録します。プロジェクトの証拠がラベルをサポートする場合にのみ、コンポーネントを「テスト済み」「監査済み」または「提案中」としてマークします。これらの説明は互換性がありません。設計が変更中の場合は、どの詳細が暫定的であるかを特定し、確定した事実として記述しないでください。

どの編集チェックが仮想通貨ホワイトペーパーのギャップを明らかにしますか？

トークンの説明とロードマップの間の矛盾は、スタイルの問題ではなく、コンテンツの欠陥です。文章の洗練に時間を費やす前に、ステータス、定義、証拠についてレビューします。これらのチェックにより、ドラフトの評価が容易になります。

• メカニズムのない約束： 結果を主張する代わりに、システムとその依存関係を説明します。
• 納品として書かれた計画： 将来の作業をラベル付けし、利用可能な機能と区別します。
• 曖昧なトークン機能： トークンがシステム内で何を行うかを説明します。
• 未定義の数値や用語： 各値やラベルが何を指すかを示します。
• 文脈のない技術用語： 用語を定義し、なぜそれが重要なのかを説明します。
• 矛盾する名前やルール： セクション間で供給の説明、ガバナンスの役割、ステータスラベルを比較します。
• 一般的な箇所： このプロジェクトの設計や責任を説明していない文言を削除します。

各セクションについて、注意深い読者がその内容から何を検証できるかを自問します。答えが不明確な場合は、出典を追加するか、前提条件を限定するか、記述を修正します。次に、順序と読みやすさについて別途編集パスを実行します。事実確認とコピー編集を分離することで、滑らかな表現が未解決の主張を隠すリスクを低減します。

レビュアーは公開前に変更をどのように記録すべきですか？

変更ログは、チームに何が変更され、その理由を記録します。主題ごとにレビューを割り当てます。エンジニアはシステムの説明をチェックし、トークン担当者は仕組みをチェックし、編集レビュアーは構造と一貫性をチェックします。法律的な評価が必要な文言は、法律顧問がレビューする必要があります。

以下の順序を使用します。

• アウトラインを確定し、現在のソース資料を収集します。
• 説明をドラフトし、資料の主張を証拠にマッピングします。
• 各主張を、それをチェックする責任者に回付します。
• コメントを解決し、実質的な変更の理由を記録します。
• リンク、図、用語、バージョンラベルを最終テキストと照合します。

担当者ごとにグループ化された質問が記載されたマーク付き文書は、次の改訂に明確な道筋を与えます。創業者は範囲とステータスを解決し、技術レビュアーはシステムの説明に集中できます。公開まで変更ログを保持することで、レビュアーはどの主張が移動したか、その理由を確認できます。

ホワイトペーパーを超えたプロジェクトコミュニケーションについては、文書を仮想通貨マーケティングガイドおよびプロジェクトの現在の技術資料と比較します。どちらもソース事実の確認の代わりとして使用しないでください。GeoMarketing Expertsでは、ドラフトレビューは資料の主張を証拠にマッピングし、担当者ごとに質問を返します。現在のアウトライン、製品ドキュメント、該当する場合はトークン資料、およびレビューが必要な主張を送信して、ホワイトペーパー作成サポートについて話し合ってください。

公開されたホワイトペーパーは何を証明しないままにしますか？

バージョンラベルと割り当てられた担当者は、読者がどの文書を読んでいるかを特定するのに役立ちます。ホワイトペーパーから現在のプロジェクト文書への経路を維持します。重要な機能、トークンルール、ガバナンスプロセス、またはプロジェクトステータスが変更された場合に、ホワイトペーパーをレビューします。プロジェクトを反映しなくなった場合は、更新するか、古いものとしてマークします。

正式な文書は、実装が記述どおりに動作することを立証したり、セキュリティを認定したりすることはできません。トークンおよびガバナンスの条件も、プロジェクトの文書化されたルールに従います。ホワイトペーパーに前提条件と未解決の依存関係を明記し、それらの資料では解決できない質問については、資格のある技術的および法的レビューを求めます。

公開前に、最終テキストが製品および統治文書と一致していることを確認します。図、用語、バージョンラベル、リンクがレビュー済みドラフトと一致していることを確認します。名前の付いたチームメンバーに将来の更新の責任を割り当て、文書が自動的に最新の状態を保つと想定しないでください。

ドラフトを開始するには、アウトライン、現在の製品ドキュメント、該当する場合はトークン資料、およびレビューが必要な主張のリストを収集します。それらの項目をGeoMarketing Expertsに送信します。次のステップは、主張から出典へのチェックと、各質問を解決する責任者向けのギャップリストです。

仕組み

1. 読者と目的を設定する主な読者と、ホワイトペーパーが彼らの評価に役立つべき内容を明示します。その役割をマーケティング、法的条件、詳細な技術文書から分離します。
2. 現在の事実を収集しラベル付けする製品、アーキテクチャ、トークン、ロードマップの資料を収集します。各項目を「稼働中」「テスト済み」「計画中」「未解決」としてマークします。
3. セクションと主張をマッピングする読者のニーズに合わせてアウトラインを構成します。重要な主張ごとに、出典とレビュアーを記録します。
4. 説明をドラフトする実装の詳細を追加する前に、システムを平易な言葉で説明します。図にはキャプションを付け、その限界を特定します。
5. ホワイトペーパーをレビューし保守する主張を適切なレビュアーに回付し、矛盾を解決し、将来の更新のための担当者を割り当てます。