読み手が唸るドキュメントを書く5つのコツと7つのステップ
「テクノロジーに関する予測はなるべく控えているが、これに関しては自信がある。あと20年ぐらいで、文章力のある人はほとんどいなくなる。」
Yコンビネーター共同創業者ポール・グレアムが先月書いた、「Writes and Write-Nots（書ける人・書けない人）」の一節です。AIが文章を自動生成できるようになるにつれ、書く力のある人がどんどん減っていく、という予測です。
それは悪いことなのでしょうか？問題は、書くことは、考えることであり、書く力が衰えると、考える力も衰えてしまうことです。米国の数学者レスリー・ランポートは、「書かないで考えているなら、それは考えていると思い込んでいるだけ」と言います。
一方、書くことは難しいのも事実です。上手に書くためには、思考力が必要であり、考えることもまた、難しいからです。
今日は、事業の意思決定という文脈において、私が学んだ中で最も有効な5つのドキュメント作成のコツと、それを限られた時間で書く7つのステップを紹介します。
読み手が唸るドキュメントを書く5つのコツ
まずは、書き方に関する5つのコツです。当たり前と言えばそうですが、まとめてみたら、書き方というよりその根底の思考法5選になりました。
① 提案の「構造」を整える
② 良い顧客課題に焦点を当てる
③ 捨てた選択肢も見せる
④「速い思考」にも働きかける
⑤ 想定問答集をあえて見せる
① 提案の「構造」を整える
良い提案とは、「読み手が考える負担を極限まで減らした提案」と言えます。意思決定層の人ほど、一日に何度も、限られた時間内に情報を吸収し、的確な判断をしないといけないからです。そのためには、これはどんな提案で、どんな流れでできているのか、その構造がぱっと見数秒で理解できる必要があります。
構造は議題に応じたカスタマイズが必要ですが、覚えておきたい鉄板の構造は2つあります。
SCQAで流れを作る
Situation（状況）、Complication（複雑化）、Question（疑問）、Answer（答え）の流れに沿ってストーリーを構成することです。ロジカルシンキングのバイブルとも言える書籍、「考える技術・書く技術 問題解決力を伸ばすピラミッド原則」で広まりました。それぞれの意味は、ざっくり言うと以下の通りです：
S（状況）：既知情報のおさらい。「そうそう」、「今こんな感じ」
C（複雑化）：新情報。「やばい」、「大変」、「どうしよう」
Q（疑問）：この問いを解けば大丈夫
A（答え）：これが答え
このSCQA構成は、例えば以下のような場面で使えます。
S（状況）C（複雑化）Q（疑問）の例
出所：考える技術・書く技術 問題解決力を伸ばすピラミッド原則
A（答え）はピラミッド構造にする
「ロジカル・プレゼンテーション」の著者高田貴久さんは、読み手が提案に納得しない理由は2つしかないと言います。それはずばり、
本当にそうなの？（話が飛んでいる）
それだけなの？（話が抜けている）
です。この2つの落とし穴を避けるために便利なのが、「ピラミッド構造」です。
ピラミッド構造の基本構成
出所：ピラミッドストラクチャーとは？作り方や活用の具体例を紹介
図にあるように、一番上に置かれた主張が複数の根拠に支えられており、さらにそれを支える細かなファクトがある、という構造をしています。上から下に行くにつれ、「本当にそうなの？」という問いに答え、横にいくにつれ、「それだけなの？」という問いに答えていくのが特徴です。自分の提案をこの形に落とし込むと、一目瞭然で説得力のある提案になります。
ピラミッド構成にする前と後の文章の比較
出所：ピラミッドストラクチャーとは？作り方や活用の具体例を紹介
② 良い顧客課題に焦点を当てる
PMにしかできない最も大事な仕事を1つ選ぶなら、「良い顧客課題に焦点を当てる」ことです。取り組む顧客課題が間違っていたら、それをどんなに頑張って解決しても意味がないからです。逆に、大事な課題を特定でき、周りのチームメンバーも「これは取り組まないといけない課題だ」と納得してくれれば、後は様々なメンバーの力を借りながら詳細を詰めていくことができます。意思決定層も、基本的には詳細な進め方より、「これは顧客にとって大事で、大きな問題なのか」に関心があります。
他の方の言葉を借りると、PM Clubの佐々木真さんは「プロダクトは課題から考えろ」、私の元上司は「HowではなくWhyにエネルギーを注げ」と耳にタコができるほど言っていました。
それでは、良い顧客課題とは、何なのでしょうか？私の経験上、3つあります：
⑴ 顧客像が具体的である
具体的とは、「UXリサーチやりたいから参加者を集めて」と言われたら誰に打診すれば良いか想像がつくレベルです。例えば、「AWSの顧客」は漠然過ぎます。特定のニーズがあるセグメントに切り込まなくてはなりません。
⑵ 課題を裏付けるデータがある
誰かに「これが課題だ」と言われた時に気になるのは、それはただの意見なのか、データに基づいた洞察なのかです。ここで、口コミなどの定性データが複数あると、顧客の悩みが切実に感じられるようになります。さらに、そこに定量データも加わると、問題の規模感が分かり、その問題の信憑性が増します。社内データ、業界データ・トレンド、ユーザーリサーチ結果など、いくつもの出所から情報を集めると効果的です。
⑶ 解決策に言及していない
課題をすっ飛ばして解決策に入ると、他にあり得る解決策を見逃してしまいます。例えば、「顧客からメールが来たら、通知を送らないと」は課題ではありません。「サポートエンジニアが顧客メールを確認するのに1日50回もページを更新しなくてはならない」と書けば、色んな解決策を思いつくことができます。
これらの条件を満たした顧客課題を設定することで、読み手が「確かにこれは解決しなくてはならない」と感じるようになり、議論が前に進みやすくなります。
③ 捨てた選択肢も見せる
良い顧客課題が設定できたら、次はその解決策を説明しますよね。この際、読み手の頭に浮かぶ質問が、「なぜこの解決策なの？」「他にこういうのは考えなかったの？」です。人はいきなり最も良い解決策を提案されるよりも、複数の選択肢を見せてもらい、その上で一番良いものを決めたくなるものです。
その際、多くのドキュメントでプロコン表をみかけますが、これは残念かつ危ないです。プロコン表だと、「本当にこの人は考え抜いたのか」が見えず、「自分に都合の良いプロとコンを選んだんじゃないか」とも見られかねないからです。
自分の思考過程を見せるためには、次の3つを必ず示しましょう：
判断するための軸
その軸の優先順位
各選択肢の評価
これがあると、人と意見が異なる時、どこで意見が違うのかが特定しやすくなります。
判断軸が違うのか？
軸の優先順位が違うのか？
評価が違うのか？
ちなみに、この思考法は、移住先や転職先を決める時など、人生の色んな場面に使える汎用的なアプローチです。以前「開発生産性を上げるための3つの鍵」で紹介したニコル・フォースグレン博士が無料テンプレートを公開しているので、興味ある方はどうぞご活用ください。
④「速い思考」にも働きかける
心理学者のダニエル・カーネマンは、人が問題を解決しようとする際、2つの異なる「システム」を用いていると言います。
システム1（速い思考）：直感に基づいた迅速な判断
システム2（遅い思考）：情報を慎重に処理した上で下す、合理的な決定
これまでは主に「遅い思考」に働きかける方法を紹介してきましたが、「速い思考」にはどう訴えかければ良いのでしょうか？
元Amazonのディレクター、現Uberのシニア・ディレクターのイアン・マクアリスターは、次のように言います：
「トップ1%のPMは、反論や無視できない説得力のある提案をします。彼らは、データが入手可能な場合はそれを適切に活用しますが、それだけでなく、意思決定者が人員、予算、その他のリソースを提供し、その後は邪魔をしないよう説得するために、人々が持つバイアスや信念なども巧みに利用します。」
私が見てきた中で、人のバイアスや信念に訴えかける最も効果的な方法は、「会社の価値観と紐づける」ことです。
例えば、某企業で「長期思考が大事だ」「短期志向はいけない」という価値観があるとします。それなら、「今起きていることは、短期的な収益の追求であり、もっと長期視点で顧客に価値を提供しないといけない。だからこそ、これを進めるべきだ」と主張します。
すると、どうでしょう。これは社員全員で共有できている理念であり、直感的にも意識的にもそれを否定することが難しくなります。実際、私も、この論法でそれまでの方針がひっくり返る場面を見てきました。
速い思考・遅い思考の両輪で提案することで、前に進められる確率を最大化することができます。
⑤ 想定問答集をあえて見せる
Amazonのドキュメント文化で意外だったのは、Q&A（想定問答）は提案者が隠し持っておくものではなく、読んでもらうものとしてドキュメントに入れ込まれていたことです。ドキュメント形式だと、読み手もパワポプレゼンより速く情報を吸収できるので、そこで捻出した時間を活かした仕組みとも言えます。
そのQ&Aに入れる質問もさらに驚きでした。見て頂くと分かりますが、厳しめな想定問答なのです。できれば触れて欲しくない、難しい問題。
それらもあえて答えを書くことで、「これは本当に考え抜いた提案だ」という信頼感が生まれます。また、それを口にすることの気まずさもなくなるため、本音の議論がしやすくなります。
さらに、ここまで深いレベルで議論できることで、最終的な方向性についても納得感が生まれやすくなります。
提案
「今日この場で必要な意思決定やフィードバックは何ですか？」
「他にどんなアイデアを検討し、それらはなぜ提案しなかったのですか？」
「このローンチにはどんなリスクを想定していますか？」
「この提案のどの部分で最も賛否が分かれていますか？」
「初期版で最もお客様がガッカリするのはどの部分ですか？」
「ローンチしたら、どんな指標で成功を評価しますか？」
「この領域には今どんな企業がいて、我々はどう違うメリットを提供できるのですか？」
「財務的にはどんなインパクトを見込んでいますか？鍵となる前提は？」
事業計画
「この提案のどの部分で最も賛否が分かれていますか？」
「まだ表面化していないが、懸念していることは？」
「この事業部の破壊的なビジネスアイデアは？」
「過去1年で最も驚いた良いことは？どうそれに今後注力する予定？」
「過去1年の最大の失敗と学びは？今一番ガッカリしていることは？」
「今顧客から一番頻繁に寄せられている苦情は？それをどう解決する予定？」
「人員計画に収めるために諦めた取り組みで、一番辛かったのは？」
「固定費と変動費を削るための計画は？どう進捗を追う予定？」
「この事業部の戦略理念は？」
良いドキュメントを速く書く7つのステップ
さて、もう一つの悩みは、良い提案を書くだけでなく、それを限られた時間でどうやって準備するかですよね。日中書こうとしていたのに、ミーティングやバグ対応に追われ、夜になって、疲れた。。でも何か書かないと。。。という絶望感。そんな忙しい皆さんには、次の進め方をおススメします。
一言で言うと、「書くことにもプロセスがある」ということです。コードを書くのはソフトウェア作りのたった一部であるように、ドキュメントを書くのも、事前準備と、書いた後のQA（品質保証・バグ対応）が必要です。
書くことは、準備と編集が必要なプロセス
それではどんな形で進めると最も効率良く良い文章が書けるのでしょうか？私のおススメは、次の7つのステップです：
① 個別レビューを設定する
② 論点・仮説を考えながら、材料を集める
③ 言いたいことを書きなぐる
④ 構造を整える
⑤ 文章にする
⑥ 容赦なく削る。一言一句自問する
⑦ 添付資料を用意する
① 個別レビューを設定する
私がAmazonでインターンをしていた時に、今やMeta AIでLlamaモデルを作っている、元AWSの先輩PMから頂いたたった一つのアドバイスは、「早く書いて、早くフィードバックをもらおう」でした。そして本当にその通りで、私はこれを忠実に行ったからこそフルタイム採用の切符を手に入れることができました。
これが大事な理由は3つあります：
個人名を意識した資料になる。誰に読んでもらい、最終的に誰が意思決定するのかを念頭に置くため、彼らの関心事を踏まえた資料にしやすくなります。
紙に落とすと、人は急に真剣になる。ホワイトボードで、「こんな感じが良いんじゃない？」と話していたのに、それを紙に落とし込んだら、「これおかしくない？」と言われたことはありますか？それは、人が話しながら考えられることには限りがあるからです。だからこそ、口頭の合意に甘んじることなく、それを紙に落とし込み、早く人と擦り合わせることが大事です。
百戦錬磨でない限り、人の意見を完全に予見するのは不可能。どんなに一生懸命考えても、人の考えを完全に予見するのは難しいです。違う会社や業界に転職したばかりであれば、なおさらそうです。であれば、あれこれ悩むのではなく、とりあえず60点のドキュメントを持っていってフィードバックをもらうことで、お互いの時間を無駄にせずに済みます。
それでは、誰からフィードバックをもらえばよいのでしょうか？特に効果が高いのは、
議題の領域に詳しい人
議題の領域を全く知らない人
の2つです。前者は自分の思考の欠陥を指摘してくれ、後者は自分の表現を改善するヒントをくれます。
私の経験上、特に後者の人が貴重で、それもまた驚きでした。「XもYもZも分からない！」とさんざん言われて、「いや、そこに書いてあるし。。。」と心の中で思いつつ一つ一つ表現を見直すうちに、研ぎ澄まされた資料となっていきました。素人目線の『分からない』という指摘は、金言なのです。
② 論点・仮説を考えながら、材料を集める
問われる質問や言いたいポイントを考えながら、必要な情報の収集に取り掛かりましょう。調査やモックアップ、財務分析など、リードタイムな必要なものは、そのリードタイムも踏まえながら着手・依頼します。
③ 言いたいことを書きなぐる
次におススメするのは、とりあえず思いついた文章やキーワードを書きなぐることです。難しく考えずに、とりあえず書き始めることで、筆が進まない状態を打破することができます。
特に大事なのは、ここではデータは参照せず、「XX、YY」などと仮の数字を入れて、言いたいメッセージに集中することです。私はデータを探そうとするあまり脱線して、気がついたらそれに30分や1時間もかけてしまっていたことがよくありました。書く時は書く、探す時は探す、と分けることで、時間の無駄を避けることができます。
④ 構造を整える
ここまで来たら、次はSCQAやピラミッドプリンシプルを参考に構造を整理しましょう。提案があれば、全ての選択肢と、それらの判断軸、軸の優先順位、及び各選択肢の評価も明確にします。本編、想定問答、添付資料と入れる場所も分けましょう。
⑤ 文章にする
あとは、上記の構造に基づいて、それぞれを文章に落とし込んでいきます。気に入らない文章や表現で詰まってしまったら、とりあえずハイライトするなどして一度置いておき、先に進みましょう。
⑥ 容赦なく削る。一言一句自問する
ここまで来たら、いよいよ添削です。しっかり添削するか否かでドキュメントの質も大きく変わるので、ここに時間をかけましょう。
数字で語る。「大幅に」、「多少」といった曖昧な表現はNG
文章は短く。切れるなら切る
無駄な言葉は全て削る。その文字を消しても意味が伝わるなら、要らない
専門用語は避ける。使う必要があるものは辞典をつける
素人でも分かるか想像する。この領域を全く知らない人でも分かるか考える
イアン・マクアリスターは、コピーライティングについて以下のように言います。
「トップ1%のPMは、目的の達成につながる簡潔な文章を書けなければなりません。言葉が一つ一つ追加される度に、それまでの言葉の価値が希薄化してしまうことを理解している必要があります。ボタンのラベル、ナビゲーション、行動喚起文など、重要な文言については、単に『それなりの言葉』を選ぶのではなく、完璧な言葉を見つけることに時間とエネルギーを費やすべきです。」
⑦ 添付資料を用意する
ここまで来たら、提案をサポートする市場調査、顧客の口コミ・データ、財務分析や、顧客体験をイメージできるワイヤーフレームを添付します。特に、「百聞は一見に如かず」ということわざの通り、ビジュアルを入れると、書き手がどんなプロダクトを想像しているのかパッと理解することができ、議論が効率よく進みます。デザイナーがいればモックアップを用意してもらえるとベストですが、いなければ自分で用意したワイヤーフレームや、ホワイトボードの写真でもOKです。
フィードバックを基に、編集を繰り返す
ドラフトが書けたら、それをチームメンバーと共有してフィードバックをもらい、意思決定者との会議まで徐々に輪を広げて仕上げていきましょう。特に、ドラフトを通して、⑴構造は分かり易いか、⑵顧客が誰かクリアか、⑶顧客の課題はクリアで、データに基づいているか、⑷解決策に至る思考過程は明確か、⑸想定問答集は考え抜かれているか、といった質問への答えを評価し、文章を結晶化させていくことが大事です。
