ホワイトペーパーとは——営業資料ではなく社内検討に使える知識をつくる

「ホワイトペーパーをつくる」と決まり、最初に話し合うのがページ数、PDFの表紙、ダウンロードフォームの項目になっていないだろうか。どれも配布には必要かもしれない。だが、同僚がその文書を会議へ持ち込み、「何が問題で、どの根拠から、何と何を比べ、どの条件なら判断できるか」を説明できなければ、資料は社内検討の途中で止まる。

ここでいうホワイトペーパーは、ある問題について、背景、根拠、選択肢、判断条件、限界を一つの論理で組み立て、読者が社内検討へ持ち込めるようにした文書である。これをCONTEXT編集部の実務上の定義とする。PDFであること、登録フォームの後ろにあること、長いことは定義に含めない。

営業資料が悪いわけではない。製品を知ってもらい、特徴を伝え、問い合わせや商談へ進んでもらう役割がある。問題はホワイトペーパーまで同じ約束でつくることだ。最初から自社製品だけを答えに置けば、読者は問題の範囲や代替案を確かめられない。営業資料とホワイトペーパーは、長さではなく、読者へ何を持ち帰らせるかで分けた方がよい。

「ホワイトペーパー」という名前だけでは、中身は決まらない

white paperという語は、もともと一つの厳密な書式を指しているわけではない。英国のThe National Archivesは、議会へ提出されるCommand Paperの例として、主要な政策提案であるwhite papers、協議文書であるgreen papersなどを挙げている。[1] 政策課題や提案を公にし、議会や社会が検討する文書という用例である。

ところが同館は、公式出版物の文脈でもgreen paperとwhite paperには正式な定義がなく、表題に使うと混乱を招き得ると注意する。代わりに、文書の内容や目的を明確に表すタイトルを勧めている。[2] 公文書ですら、名称だけでは内容が決まらない。

企業の公開物を見ると、語の幅はさらに広い。AWSの「Whitepapers & Guides」には、technical whitepapersだけでなく、decision guides、technical guides、reference material、reference architecture diagramsが同じ入口に並ぶ。[3] 解説、比較、技術判断、参照資料、構成例という異なる役割が、近い文脈で使われている。

この幅を無理に一つのページ数や目次へ押し込む必要はない。先に決めたいのは、読者が読み終えた後に何を判断できるかである。市場の変化を理解するのか、方式を比較するのか、経営会議で投資の条件を説明するのか、技術審査で前提と限界を確認するのか。用途が決まれば、必要な根拠と構成が決まる。

したがって、「ホワイトペーパーをPDFでつくる」は制作物の指定にすぎない。「誰が、どの問いについて、どの根拠を持って、何を決めるための文書か」が企画の中心になる。

営業資料との違いは、結論より先に問いと根拠を置けること

営業資料とホワイトペーパーの境界は、製品名を出すかどうかだけでは決まらない。製品を例にしても、問題の範囲、比較条件、限界を確かめられれば判断材料になる。反対に、製品名を伏せても、読者を不安にさせた後で自社の方式だけを唯一の答えとして示せば、論理は営業資料のままである。

違いを具体的に見るため、米国国立標準技術研究所（NIST）が2010年に公開したガイドを読んでみる。NISTのTechnology Innovation Programは、将来の公募分野を考える材料として、外部の関係者からホワイトペーパーを募った。ガイドは提出物をRFPへの回答やpre-proposalではないと明記している。[4]

求めたのは、個別プロジェクトの売り込みではなかった。広い社会課題、その規模、既存の取り組み、十分に解決されていない理由、研究方法、期待する成果、目標へ至る経路を示すことだった。個々の組織が実施したい事業より、複数の企業や研究機関が参加し得る問題設定を優先している。[4]

このガイドは終了済みの公的プログラムに固有の文書である。提出方法やページ数を企業のホワイトペーパーへ移すことはできない。それでも、「自分たちの提案」より前に「何を判断するための問題か」を置く構造は参考になる。読者が自社製品を選ぶ前に、問題の大きさ、既存手段、未解決の理由を確かめられるからだ。

営業資料は製品を候補に入れてもらうためにつくればよい。ホワイトペーパーは候補を比べるための問題と条件を共有する。その文書を読んだ結果、自社製品が候補から外れる場合があっても、比較の軸が明確なら文書の役割は果たしている。

一つの文書で、社内の違う問いをつなぐ

読者を一人に絞る、という編集の原則は有効である。ただしBtoBの検討では、一人が読んで一人で決めるとは限らない。担当者が見つけた文書を、技術、調達、財務、法務、情報セキュリティ、事業責任者が別々の問いで読む。

LinkedIn B2B Instituteは、Bain & Companyとの共同研究を基に、製品の技術性能を見るTarget Buyersと、調達、財務、法務、業務などでリスクや信頼性を確かめるHidden Buyersを分けている。前者が製品を短期候補へ入れても、後者は別の基準で検証する。[5] すべての組織がこの区分どおりに動くわけではないが、同じ案件を異なる役割が異なる問いで読むことは分かる。

技術担当者は方式が要件を満たす条件を知りたい。調達や財務は費用の範囲、代替案、継続条件を確かめる。法務やリスク担当はデータ、契約、規制、障害時の責任を見る。決裁者は何を今決め、何を次の検証へ残すかを求める。

ここで、役割ごとに別々の資料をつくるだけでは、社内に複数の事実が生まれる。営業資料では「すぐ使える」、技術資料では「特定条件で検証済み」、契約資料では「追加作業が必要」と読めれば、会議では製品より先に説明の食い違いを解かなければならない。

ホワイトペーパーの仕事は全員へ同じ文章を読ませることではない。同じ問題と根拠から、それぞれの問いへ進めるようにすることだ。要約から技術条件へ、比較表から費用の前提へ、リスクの記述から原資料へ移れる。読み始める場所は違っても、参照する事実は同じにする。

BtoBコンテンツマーケティングとは——複数の意思決定者へ情報を渡すでは、記事、導入事例、比較資料などを役割別の問いへつなぐ全体設計を扱った。ホワイトペーパーではその接続を一つの文書の中へ縮める。全員分の説明を詰め込まず、共通の根拠と分岐点を置く。

読者が持ち帰れるのは、問題から限界までの五つである

社内検討に使える文書には、少なくとも五つの要素が要る。

• 問題の範囲：誰の、どの状況で起きる問題か。含めない対象は何か
• 根拠：主張を支えるデータ、規格、観察、事例は何か。誰がどの方法で確かめたか
• 選択肢とトレードオフ：どの方法を比べ、何を得る代わりに何を引き受けるか
• 判断条件：どの条件なら採用、保留、追加検証、見送りになるか
• 限界と更新：まだ分からないこと、適用できない範囲、次に見直す時点は何か

五つは、順番に埋める目次ではない。問題の範囲が変われば、必要な根拠と比較対象が変わる。新しい証拠が出れば、判断条件を見直す。限界が分かれば、適用範囲を狭める。図の最後を更新にしたのは、そこから問題の範囲へ戻るためである。

AWS Well-Architected Frameworkは、設計判断の長所と短所を理解し、一貫した質問によって構成を見直す方法を提供する。監査ではなく、設計について対話し、改善点を見つけるための枠組みと位置付けられている。[6] 文書が渡すのは「正解」だけではない。何を問えば、自分たちの条件で判断できるかという型でもある。

出典は多ければよいわけではない。市場規模の資料が個別製品の効果を証明するわけではない。導入事例がすべての環境での再現性を保証するわけでもない。主張の近くで、どの根拠が何を支え、どこから先は言えないかを示す。技術コンテンツとは——仕様を顧客の判断材料へ変える編集で扱ったように、数値には条件、方法、限界を添える。

文章の正確さと読みやすさを対立させず、定義、例、例外を分ける考え方は、テクニカルライティングとは——正確さと分かりやすさを対立させないにもつながる。専門用語を消すより、最初に必要な定義を置き、詳しい条件へ進める読順をつくる。

PDFを作る前に、HTMLで判断材料を開く

ホワイトペーパーをPDFだけで配ると、完成品らしく見える。レイアウトを固定でき、社内で添付しやすい場面もある。一方で、読者が検索し、必要な一節へリンクし、スクリーンリーダーで読み、改訂後の最新版へ戻るには、PDFが不利になる場合がある。

GOV.UKのアクセシビリティ指針は、HTMLを第一選択とする。PDFは見つけにくく、使いにくく、保守しにくいことがあり、スクリーンリーダーで十分に機能しない場合もあると説明する。見出し構造、説明的なリンク、画像の代替テキスト、アクセシビリティ検査も求めている。[7] これは英国政府機関向けの指針であり、民間企業のすべての文書に同じ公開義務を課すものではない。それでも、配布形式を決める観点になる。

基本情報はHTMLで開き、必要なら同じ内容のPDFを用意する。HTMLには更新日と変更履歴を置く。PDFには版、発行日、最新版を確認できるHTMLのURLを示す。図表にはaltと本文で読める要約を付ける。登録フォームを使う場合も、タイトル、対象読者、問い、目次、発行元、更新日、主要な根拠を登録前に示す。読者は何を受け取るかを判断してから情報を渡せる。

検索で見つけてもらうことと、PDFをダウンロードしてもらうことは、配布の設計である。問い合わせ数はその後の成果指標になり得る。しかし、それだけで文書が社内検討に使われたとは分からない。社内で引用された章、比較に使われた表、追加で聞かれた条件、更新後も参照されたURLを見ると、知識として働いた箇所が見えてくる。

公開前には作り手ではない同僚へ文書を渡し、五つだけ確かめる。何が問題か。どの根拠を信頼できるか。何と何を比べるか。どの条件なら次へ進むか。何がまだ分からないか。読み終えた人が自分の言葉で説明できなければ、ページを増やす前に論理を直す。

製品の特徴とCTAだけが残るなら、営業資料として明確につくり直せばよい。調査結果だけが残るなら、レポートとして方法と解釈を整える。手順だけが残るなら、実装ガイドにする。ホワイトペーパーという名前を守ることより、文書の約束を読者へ正直に示す方が大切である。

ホワイトペーパーを企画するとき、最初に決めるのはページ数でもフォームでもない。読者が社内へ持ち帰る問題、根拠、選択肢、判断条件、限界である。一つの文書が複数の関係者へ同じ事実を渡し、それぞれの問いから次の判断へ進める。その状態をつくれて初めて、PDFは営業資料の付録ではなく、検討に使える知識になる。