パワポプレゼンの“あるある課題”

鈴木一成氏：それでは始めたいと思います。突然ですが、みなさんはこんなパワポプレゼンの会議に直面したことはありますか？

スライドで準備した感はあるんだけれども、提案の中身が考えられていない。「提案の中身」より、「提案者が誰か」に影響を受けている。それから質疑応答や議論の時間が足りない。誰かがプレゼンを遮ると議論が脱線して、もっと時間が足りなくなる。あとは、会議後に参加していなかったメンバーにニュアンスを伝えるのが難しい。

これらは、パワポプレゼンならではの欠陥と言えます。なぜこういうことが起きるのかという問題の真因に迫ると、大きく3つほど挙げられます。

まず1つ目は、人が聞きながら考える・考えられることには限りがあるということです。意図していなくても、巧みにしゃべればある程度ごまかしが効いてしまう。

2つ目は、そもそも人が聞き取れるスピードにも限りがあります。人が読む速度と比べて、聞ける速度は約2割から5割程度です。

あとは会議後の伝達も、録画していればいいんですが、それも見るのに時間がかかりますし、大事な会議をなんでもかんでも録画できる会社も稀なのかなと思います。

パワポの代わりにおすすめなのが「ドキュメントの黙読」

じゃあ、なぜ人はパワポを使うのかを考えてみると、本質的にはこれは「営業の武器」だと言えると思います。例えば、私は今「パワポよりドキュメントのほうがいいよ」というアイデアをみなさんに売っているわけです。

ただ、社内の意思決定では営業されても困るわけで、本当にやりたいのは正しい意思決定をすることですよね。そう考えると、実はパワポは適していないということが、あまり公には理解されていないんじゃないかなと思います。

これに代わる方法として使えるのが、ドキュメントの黙読です。意思決定が必要な会議では、基本は資料を読み込むことから始めて、誰もプレゼンしない。みんなが読み終わったら、その場で討議を始めるというスタイルをとります。このスタイルをとると、さっきお伝えしたような問題がクリアできるようになります。

提案の見た目より中身に時間が割けるようになって、「誰の」より「どんな」提案かに集中できる。それから、提案や想定問答を2倍から5倍ぐらいの速さで読み込んで、骨太な議論ができる。会議が終わった後は、読めばわかる提案者の分身、伝道師になります。

パワポしか使わない組織でも、ドキュメントは有効？

会社の会議の方法を変えることは1種の改革なので、「そこまでできる気がしない」という方もいるのかなと思います。ここでお伝えしたかったのは、ドキュメント文化でない会社でも、この方法は有効だということなんです。

なぜかと言うと（理由は）いくつかあるんですが、まず1つ目は、伝えたい中身に集中することで一番大事な仕事を優先できるということです。伝えたい中身が言語化できれば、それをあらゆるかたちに落とし込むのは簡単なんです。

あと、1度ドキュメントで骨子を作れば、それは無限にスケールする分身となります。特に、大きなプロジェクトで新しいメンバーがどんどん入ってくる時は、そのたびに「これを読んでね」というところから始められるので、かなり威力を発揮します。

「そんなに良いのなら、なぜどの会社でもとっくに移行していないのか？」という話なんですが、これは結論、書くことは本質的に難しいからという点に尽きるのかなと思います。上手に書くためには上手に考える必要があって、考えることは難しい。

というわけで、今日はどうしたら良いドキュメントが書けるのかという悩みに対して、私が学んできた5つのコツと7つのステップを紹介して、最後にいくつかドキュメントが役に立つ場面をお伝えしたいと思います。

忙しい意思決定層がパッと見て理解できる提案が必要

読み手が唸るドキュメントを書く5つのコツ、さっそく1つ目に入ります。1つ目は、提案の「構造」を整えることです。

良い提案というのは、読み手が考える負担を極限まで減らした提案だと言えます。意思決定層の人ほど、1日に何回も限られた時間内にその情報を吸収して、的確な判断をしないといけないからです。そのためには、提案がどんな流れでできているのか、その構造がパッと見で数秒で理解できる必要があります。

その構造は議題に応じたカスタマイズが必要なんですが、覚えておきたい鉄板の構造は2つあります。1つ目は「SCQAフレームワーク」といって、状況、複雑化、疑問、答えという流れに沿ってストーリーを作ることです。これに沿って流れを作ることで、読み手にとっては話が頭に入りやすくなります。

2つ目は、最後の答えのところをピラミッド構造にすることです。読み手が提案に納得しない理由は、基本的には「本当にそうなのか？」と「それだけなの？」の2つだと言えます。

ピラミッド構造にすると、一番上に置かれた主張が複数の根拠に支えられて、上から下にいくにつれて「本当にそうなの？」という問いに答えて、横にいくにつれて「それだけなの？」という問いに答えることができます。

それぞれの例を紹介します。SCQAは、例えば顧客の苦情に対応するためにどうするかとか、新たな規制が加わったのでそこにどう対応するか。あとは、AI技術がすごい速度で進化していてロードマップの組み替えを考えるべきかとか、PMが直面しそうなたくさんの場面で使えます。

それから、もう1つがピラミッド構造の例です。左側はパッと見てもいろんな概念が混ざっていて、結論がどこに書いてあるのかわかりにくいかなと思います。それを右側のように結論を上に置いて、その理論の構造がわかるようになると、読む前に概要がわかって頭に入りやすいドキュメントになります。

PMにとって「最も大事な仕事」とは何か

次です。2つ目のコツは「HOW」より「WHY」にエネルギーを割こう、です。私のこれまでの経験から思うのは、PMの最も大事な仕事は、良い顧客課題を見つけて、そこにチームの意識を集中させることだと思うんです。

取り組む課題が間違っていたらどんなにうまく解決しても意味がないですし、実行段階に入っていろんな困難に直面するたびに、「結局、何のためにやるのか？」ということが問われます。そのためには、数ある候補の中からなぜこの課題に時間を費やすのか、メンバーを説得することが最も大事です。

じゃあ、どうやってそのWHYをクリアにするのかに関しては、3つの要件があると思っています。1つ目は、まずは顧客像が具体的である。例えば「UXリサーチをやりたいから参加者を集めて」と言われたら、誰に打診すればいいのか想像がつくレベルです。

それから2つ目は、課題を裏付けるデータがある。これは定性・定量の両方が大事です。定性に関しては、顧客の悩みや口コミなどを通じて、切実に自分も感じられるようになるということ。それとセットで、定量的に問題の規模感がわかると信ぴょう性が増し、良い顧客課題になると思います。

3つ目は当たり前なんですが、解決策に言及していないということです。例えば「顧客からメールが来たら通知がほしい」というのは、もうすでに解決策を決めてしまっているんです。

例えばそれを「サポートエンジニアが顧客のメールを確認するのに1日50回もページを更新しないといけない」と言えば、いろんな解決策が思いつきますよね。なので、解決策に言及する前に、何が課題なのかをクリアにするのも非常に大事なのかなと思います。

「捨てた選択肢」も見せることで得られる納得感

3つ目です。「捨てた選択肢も見せる」と書いているんですが、WHYをクリアに説明した後にHOWを説明する時に、読み手がまず持つ疑問は「なぜこの解決策なのか？」「他にこういうのは考えなかったのか？」だと思うんです。

こういう時にアプローチがいくつかある中で、「プロコン表」というものをよく見かけます。左下のプロコン表を見ていただくとわかるように、そもそもこれで論点を網羅できたのかもわかりづらいですし、「正解は何？」「結局どれを選べばいいの？」ということがわからないと思うんです。

改善の方法としては、判断基準と基準の優先順位を示すと、思考過程が一目瞭然になると思います。例えば、ここではいくつかのアプローチがある中で、その判断基準を「レイテンシー（どれくらい時間がかかるか）」「アーキテクチャのシンプルさ」とか。それから「データの重複があるか」。あとは「UIへの影響」ですね。

そういったものをすべて洗い出してから、どれが一番優先順位が高くて、どれが一番優先順位が低いのかを示す。そうすると、例えば「この軸に基づいて考えると、アプローチ1が一番良いです」と言われたら納得感がありますし、もし人と意見が異なる時でも、どこで意見が違うのかが特定しやすくなります。

判断基準が違うのか、それともその基準の優先順位が違うのか、あるいはその評価が違うのかというふうに、分けて議論ができるようになります。

人には「速い思考」と「遅い思考」の2種類がある

4つ目が「速い思考」にも働きかけることです。速い思考というのは、心理学者のダニエル・カーネマンさんが唱えたことなんですが、人は問題を解決しようとする時に2つの異なるシステムを用いてる。1つ目は「速い思考」で、直観に基づいた迅速な判断。2つ目は「遅い思考」といって、情報を慎重に処理した上で下す合理的な判断です。

今までのお話は、主に遅い思考に対する方法だったのですが、じゃあ速い思考にどうやって訴えるかというところです。私が今まで見てきた中で一番効果的な方法の1つは、会社の価値観と紐づけることです。

みなさんの会社でも、会社の価値観がそれぞれあると思うんですけれども、例えば某会社では「長期思考が大事」とか「短期思考は良くない」という価値観があったとします。

その場合に、もし自分が提案してる施策がまさにその長期思考に沿っているのであれば、「今起きていることは短期的な収益の追求であって、長期視点で考える場合はこれに投資すべきです」と言えば、「確かにそれは大事だ。我々にとってこれは大事な価値観だから貫く必要がある」というふうに、無意識に、それから意識的にも働きかけることができます。

想定問答集はあえてドキュメントに載せておく

5つ目は「想定問答集をあえて見せる」です。私がドキュメント形式の会議の仕方を学ぶようになってちょっと驚きだったのが、想定問答集というものはプレゼンする人が隠し持っておくものではなくて、あえてもうドキュメントに載せておいてあることです。

ドキュメントのほうがもっと早く中身を理解できるので、これはそのメリットを活かした方法とも言えるんですが、ここにあるような想定質問を見ていただくと、けっこう厳しめな質問が多いと思うんです。

例えば「この提案のどの部分で最も賛否が分かれていますか？」「このローンチで一番お客さんがガッカリするのはどこですか？」とか。あえてそういった厳しい質問と、それに対する答えを見せることで、議論しているメンバーの間での信頼感も生まれます。

議論の中で本当に大事なポイントを俎上に載せて議論しやすくなりますし、最終的に決めたことは納得感を生むようなかたちになるので、想定問答集はけっこうパワフルな方法だなと思いました。以上が（読み手が唸るドキュメントを書く）5つのコツです。

「とりあえず60点のドキュメントで議論」でムダをなくす

鈴木一成氏：もう1つのPMにとっての悩みは、時間がない中でどうやって良いドキュメントを速く書くか、ということだと思うんです。

PMだと日々いろんな仕事があるので、たぶん自分の3割ぐらいの時間の中でこういうドキュメントを書かないといけない。その中で、どうやって時間を見つけてやるかということで、ここに「7つのステップ」とあるんですが、お伝えしたかったのは「書くことにもプロセスがある」ということです。

例えばコーディング。エンジニアに関してもコーディングは仕事の一部だけであって、その前にはいろんなプランニングと、最後にQA、品質保証やバグの対応といったものがあるように、書くことにもプロセスがあるということです。ここでは、個人的に私が大事にしている7つのステップを紹介したいと思います。

1つ目です。「個別レビューを設定する」とあるんですが、言い方を変えると「早く書いて早くフィードバックをもらう」です。まずは読み手を個人名で意識した資料にすることで、読み手の関心事を踏まえた資料にしやすくなる。

また、紙に落とすと人は急に真剣になるという傾向もあります。やはりこれは、人が話しながら考えられることには限りがあるからだと思うんです。

あとは、人の意見を完全に予見するのは難しいので、とりあえず60点のドキュメントで議論することで、お互いの時間をムダにせずに済むかなと思います。

おすすめのやり方としては、フィードバックをもらう時に効果が高いのは、議論の領域に詳しい人と、議論の領域をまったく知らない人。この2種類の方々にフィードバックをもらうことで、前者は自分の思考の欠陥を指摘してくれて、後者は自分の表現を改善するヒントをくれます。

難しく考えず、まずは言いたいことを書きなぐる

次です。レビューの日時が設定できたら、次は論点・仮説を考えながら材料を集めます。例えば「○○市場への参入をすべきか否か」という論点があったら、それをここにあるようなサブ論点にいくつか分けて仮説を考えますよね。

仮説を考えると、自ずと必要な成果物のイメージも湧いてくるので、そこでどんな材料が必要なのかがわかって、場合によっては誰の協力が必要かもクリアになります。例えばデザイナーの協力が必要とか、財務の協力が必要という場合は、その時点で必要な材料を仕込むことができます。

3つ目です。これは個人的な私のおすすめなんですが、書き始める時になんでもかんでもうまくやろうとすると筆が進まなくなっちゃうので、難しく考えずにとりあえず書き殴る、書き始める。そうすることで、いくらかの達成感を得ることができるのかなと思います。

この時に、特にデータとかを参照せずに「XX」「YY」とか仮の数字を入れて、言いたいメッセージに集中すると、さらに効率が上がるかなと思います。

不要な文章は「容赦なく削る」ことがポイント

4つ目が「構造を整える」です。先ほどお伝えしたようなSCQAやピラミッド構造、それから意思決定の基準の明確化。そういったものを通じて構造を明確にします。

5つ目は、ここまで来たらそれぞれのアイデアを文章に落とし込む。気に入らない文章や表現で詰まったら、とりあえずそれをハイライトするなどして一度置いておくと、詰まらずに前に進めていいのかなと思います。

6つ目は、容赦なく削る。「一言一句自問する」とあるんですが、ここはけっこう大事です。上手に添削できるか否かでドキュメントの質は大きく変わるので、ここに時間を投入するのは非常に大事です。

例えば、あいまいな表現を避けて数字で語る。それから文章はできるだけ短く、切れるなら切る。あとは、ムダな言葉はすべて削る。その文字を消しても意味が伝わるなら、それは要らない。そして専門用語は避けて、使う必要があるものはきちんと辞典をつける。最後に、素人でもわかるか想像するということです。

こういったことをきちんと怠らずにやることによって、ドキュメントの質はかなり磨きがかかって、大きく変わると思います。

最後に、いろんな添付資料です。先ほどの論点・仮説のところにあったような成果物でドキュメントに加えるべき資料を添付すると、ビジュアルにも説明がつく資料となります。

PMが書くと最も価値が出る3種類のドキュメント

最後です。手短に、PMが書く最も価値が出る3種類のドキュメントについて触れたいと思います。

1つ目は提案書です。Amazonではこれを「PRFAQ」「プレスリリースとよくある質問」と呼んでいます。左側にあるような「5つの顧客の質問」は、顧客は誰で、彼らの問題は何で、解決策は何か、なぜこの方法が正しいのか。あとは、どんな顧客体験を提供して、どうやって成功を定義・測定するのか。

こういうものに答えた上で、それをプレスリリースにすることによって、顧客視点に立って未来のローンチを想像する。ローンチした時の顧客のメリットだったり、その時に感じることを社内で擦り合わせることができるツールです。詳しくは私のWebサイトに記事があるので、そちらを見ていただければと思います。

それから2つ目がプロダクト戦略です。ビジョンを実現するプロダクト戦略なんですが、これはなかなか容易ではなくて。よくある失敗として既存の延長線上に過ぎなかったり、取り組みが多過ぎて結局できなかったり、日々の活動と紐づいてなかったりといった問題があります。

良いプロダクト戦略というのは、超長期を見据えた上で、今年・今週注力すべきことを明確にしてくれるものである必要があります。例えば構成例として、右にあるようなところをきちんと書くと、大きなビジョンから「今日、何をすべきか」までがきちんとつながる資料になるのかなと思います。こちらも、よろしければ私のWebサイトの記事をご覧ください。

最後がエスカレーションです。「他のチームと行き詰まったら、PMが上手に上層部を巻き込もう」とあるんですが、複数チームが関わると対立が起きることは多々あるかと思います。

変なことではなくて、プロジェクトの方向性について意見が割れているとか、キャパ不足で必要な協力が得られないとか。そういった場面で、PMは最も全チームの視点が見える立場にいるので、そういう時に上層部を上手に巻き込めると価値が出るのかなと思います。

エスカレーション資料の構成例に関しては右側にあるような内容になるんですが、こちらもよろしければ記事をご覧いただければと思います。

あと20年で「文章力のある人はほとんどいなくなる」

最後に書いたんですが、Yコンビネーターの共同創業者のポール・グレアムさんの言葉をシェアして終わりたいと思います。彼は「あと20年ぐらいで、文章力のある人がほとんどいなくなってしまう」と言っているんですね。AIに頼れるようになって、AIでまあまあの文章が書けてしまうから。

でも、冒頭でお伝えしたように、書くことは考えるために最も大事なスキルだとすると、特にチームの成功に責任を持つ我々PMたちは、書くスキル・考えるスキルを磨いていかないといけないと思います。

今日お伝えしたコツやステップも参考に、今後みなさんと書く技術・考える技術を高めていければ幸いです。今日はどうもありがとうございました。