プロダクトマネージャーの必須スキルである「言語化」を活かす　最強の言語化ツール・Notionを活用した情報の一元管理法

自己紹介

佐々木真氏（以下、佐々真）：じゃあやっていきたいと思いますので、よろしくお願いします。タイトルが「Notion×プロダクト作り最強活用法」というところですが、今日は15分しか時間がないので、できるだけエッセンスをお伝えできればなと思っています。

あらためて自己紹介です。私はTwitterにはこのアイコンでいます。佐々木真と申します。プロダクトマネージャーで、PM　Clubの主催者をしています。過去に事業売却したり、起業したり、現在はIT企業で顧問をしたり。あとは、シンガポールの法人で取締役をやっていたりもするので、「何やってんだかよくわかんねぇ」みたいなこともありますが、Twitterではプロダクトマネージャーで通っているかなと思っています。というところでよろしくお願いします。

プロダクトマネージャーの仕事は曖昧になりやすい

まず前提です。「プロダクトマネージャーのお仕事って、みなさん何だと思いますか？」というところで、今日はPMじゃない人もけっこういるので、ちょっと想像をしてみてもらいたいなと思っています。

「プロダクトマネージャーの仕事とは？」で、パッと頭に浮かぶものって何でしょうか？　これはたぶん、人によってけっこう違うんですよね。社長とかエンジニアとかデザイナーとか、立場によっても違います。もちろんPM自身でもけっこう揺れます。

（スライドを示して）一般的に言われるプロダクトマネージャーのスキルは、だいたいこんなものだと思っています。プロダクトマネージャーは、UXとテクノロジーとビジネスの3つの軸があるかなと思っています。

一般的にはこう言われますが、現実はこっちです。マジでなんでも求められます。プロジェクトマネージメントだったりUXだったり、テクノロジー、ビジネス、マーケティング、データアナリティクス、リーガル、ビジネスデベロップメント。なんでも期待されるということが現実的にあり、「何をやるんだ」みたいなところがけっこう曖昧になるところが1つあります。

（スライドを示して）現実問題（としては）、こんな感じで整理ができますが、ビジネスからUX、テクノロジー、マーケティングは多岐にわたるというところで、恐ろしいのが、これは会社によってけっこう違うんですよね。会社によって求める期待値が違ったり、PMに求めるものが違うというところがあります。

Notionプロダクト作り活用法を語るためには、その前に「PMって何すんのよ」をはっきりさせましょう。それは「言語化」にあります。

プロダクトマネージャーに求められる「言語化」

最も、自分の仕事の「言語化」を求められるのがプロダクトマネージャーの仕事の役割でもあります。やはり自分の仕事をまず定義できないと、プロダクトマネージャーはやっていけません。「ここはやります」「これはやりません」「やれません」とまず線引きしないといけないというところが、まず大前提としてあります。

プロダクトマネージャーにとって言語化は基本的なスキルであって、そして最強のスキルでもあります。逆に言うと、プロダクトマネージャーが自分の仕事を言語化できない場合、けっこうつらい目に遭うんですよ。「えっ、これできないの？」「あれ、できないの？」ってムチャ振りをされたり、もしくは、自分が本来やるべきことに集中できないとか、けっこうあります。

なので、前提として、まずプロダクトマネージャーがNotionを使う時に気をつけなきゃいけないことは、まず言語化をすることなんです。

プロダクトマネージャーの代表的なアウトプットはいろいろありますが、（スライドを示して）こういったものがあります。例えば、顧客フィードバックであったり、あとはPRD（Product Requirements Document）と呼ばれる仕様書みたいなものです。あとはガントチャートやロードマップを作ったりします。

ほかにもメチャクチャいろいろとあります。会社によっては事業計画書を作らされたりとか、あとはエンジニアのGitHubの中のレポジトリ内を見る話だったり、チケットの管理みたいなこともあったりします。あとは、改善の施策としてグロースのKPIみたいなものの数値を見るみたいなところもあります。

ただ、たぶんすべてのPMがやらなければならないことの代表は、だいたいこの3つになるかなと思っています。

Notionのテンプレートを活用したPRDと顧客フィードバックの管理

具体的にどうすればよいのかというと、「はい、みなさん、用意しました」ということで、ちょうど先週、プロダクトマネージャー向けのWikiがNotionの公式のテンプレ集から出ました。先日プロダクトマネージャーのWikiはもう公開されているので、どなたでも使えます。これをどうやって使っているのかを、今日はお話しできればなと思っています。

何を使うのかみたいなところでいうと、まずPRDとロードマップというところが1つありますと。これはプロダクトマネージャーあるあるだと思いますが、PRDに何を書けばいいのかわからないという問題がけっこうあるんですよね。

会社によっても違う、人によっても違う。求められるものがわからないという時に、「これを書いておけば、とりあえずエンジニアと連絡は取れるだろう」とか、「ほかの部署の人に説明ができるだろう」みたいなところの粒度感で、まずPRDのテンプレートが1つあります。

もう1個が、顧客フィードバックの管理表です。やはりこちらが一番大事かなと思っています。プロダクトマネージャーの仕事で一番大事なのって、顧客のニーズを把握することなんですよね。となった時に、顧客のニーズを把握して、それをどう機能開発に落とし込むかを考えなきゃいけないんですけれど、そのもとになる顧客フィードバックをやらない人がけっこう多いんですよ。

プロダクトマネージャーの仕事というと、先ほど言ったみたいに「PRDを書くことだよね」となる人がけっこう多いんですけれど、その中でも特に、その前提になる顧客フィードバックがあります。

やはり1ヶ所に情報をまとめるというのは、Notionのすごく強いところでもあるんですよね。例えば、お客さんが具体的にどういうTier、希望によってお客さんの属性を分けたりします。どういう企業セグメントで分けているのかと、あとは企業名、起きている課題を集約するのがすごく大事なんですよ。

エンジニアのみなさんと会話する時、「この機能本当にやるの？」という会話ってけっこうあるんですよ。もしくは上司の人とかにも言われたりします。「この機能って本当にやる価値あるのか？」みたいな。

あと、PRDとかを書いていても、横から他の機能を差し込まれたりするんですよね。こういった時に、すべてのプロダクトマネージャーが一番意識しなきゃいけないのは、実は顧客フィードバック管理表なんですよね。

プロダクトマネージャーって、意外とみんなこれが抜けがちです。私は複数のIT企業で顧問していますが、これをやっているところは、僕が知っている限り、フィードバックをしっかり管理している会社は1社たりとも見たことがないんですよ。

顧客フィードバック管理表に機能を書くな

プロダクト作りでフィードバックをなぜ力説しているかみたいな話ですが、これ、マジで大事なんですよ。すべての原点がここで、プロダクトマネージャーもエンジニアもデザイナーも、すべてがここから始まると言っても過言ではないところです。

（スライドを示して）テンプレートは、僕自身が顧問先とかで実際に使うことが多いので、誰でも使えるように作って公開しています。どなたでも使えますのでぜひご利用ください。

使う時のポイントです。フィードバックでは、まず課題を絶対書いてください。今日の話は全部忘れていいので、これだけ覚えてくださいという感じですが、「顧客フィードバック管理表に機能を書くな」というのは鉄則です。もう1回言いますね。「機能を書くな、課題を書け」。今日（の内容は）全部忘れていいので、本当にこれだけ覚えてほしいなと思っています。

ここに具体的にありますが、PRDは先ほども言ったように機能ではなく課題を書く場所です。「こういう機能が必要です」「こういう仕様で作りましょう」というのを書くことも間違いではないんですか、フィードバック管理表に機能を書くと絶対に間違いが起きるんですよ。

（スライドを示し）この例で書いてありますが、「通知機能がないので更新されても気づかない」みたいなのがあります。これは悪い例で書いています。課題は、「更新に気づきにくい」というところですが、これを解決する方法に、通知機能かどうかというのは別に関係ないです。

なので、まず課題を書きましょう。何が起きているのかをまず把握します。それを一覧で書いた上でPRDを作るところがすごく大事で、何が言いたいかというと、課題を把握していないと、その機能を本当に作るべきなのかがわからないんですよ。

例えばSaaSとかでよくあるのが、CSVで書き出せるようにしてほしいとか、そういう要望があったりするんですよね。でも、CSVで書き出した時点で「本当にそれってクラウドでやる意味あるんだっけ？」みたいな議論が起きるんですよ。

「それって本当にいいんだっけ」「やっていいんだっけ」みたいなことを考えるのがプロダクトマネージャーの仕事ですが、その背景を探るためには、まず課題が何かを把握できていないとまったく意味がない。その課題をわかった上で、何をやるかはみんなで考えればよいという話なんですよね。

Notionを活用するメリットは、エンジニアと同じ目線になれること

僕はNotionでPRDを作っていますが、Notionでやると何がいいかというと、エンジニアの人と一緒の目線でやれるんですよ。エンジニアって、GitHubで完結したがるところがあるんです。レポジトリがあるというのもあるし、あとはチケットがあるというのもあるので、GitHubでやりたいというのがすごくある。

一方で、「本当にそれをやるべきなのか」という議論は、エンジニアのみなさんだけだとけっこう抜けたりするんですよ。そういう会話をする時に、Notionで情報を、課題をまとめて、その機能を一元で管理するというところが、やはりものすごく大事なんですよね。なので、解決したい課題から何がしたいのかを一気通貫でやれるところがすごく大事なんだと思っていて。

GitHubってアカウントを持っている人しかアクセスできなかったり、GitHubをあまり触ったことがない人だと、「どこを触っていいのかわからない」みたいなこともあるんですよね。チケットがどこにあるのかとか。（GitHubは）けっこう特殊なUIをしているので、慣れないと使いにくいというのもある。そういった時に、Notionを使って一覧でやるところがすごく大事になってきます。

特に情報が分断しやすいのが、ビジネスサイドと開発サイドなんですよね。PMやっていると一度は必ず経験すると思うんですけど。

言い方はアレですが、「上司がなんかゴニョゴニョ言ってきた」とか、「CSやサポートのチームからこういうことを言われた」ということの受け皿がPMで、開発サイドに落とす時に実際どうするのかみたいな。その背景を伝えられないのが、けっこうあるあるなミステイクなんですよね。

なぜこれをやるのかという温度感をわかっているのがPMだけというのは、実は組織としてすごく不健全です。エンジニアが社内下請けみたいになっている会社ってけっこうあるんですよ。

その中で、開発サイドは「文系営業なんか……んだよ！」みたいな感じになって。開発サイドはそう思っているし、ビジネスサイドは「なんであいつらはすぐ作らないんだ。こんなに要望があるのに」というハレーションが起きたりします。

ものすごくあるあるなんですよね。組織がでかくなると、この問題は僕が見ている観測範囲で90パーセントの割合で起きます。それが起きる原因は、やはり情報が見えてないないんですよ。どれくらいの要望があるのか、どれぐらい課題があるのかを可視化ができていないのと、逆にそれをどう対応しているのかが見えていなかったりするので。

PMがやるべきは情報の一元管理と周知徹底をすること

なのでPMがやるべきことは、まず情報を一元管理することというのが1つあります。ここからすべてが始まります。先ほど言ったように、言語化ができなければPMの仕事は始まりません。

言語化が苦手な人も、PMを目指す以上は必ず（言語化する道を）通らなければいけません。あとPMのもう1個の大事な役割が、チーム内で周知徹底をするところです。「ここに情報がありますよ」ということを徹底する人って、実はすごく大事なんですよ。集めただけだと意外と見られないのは、これも組織のあるあるです。

なので、情報を一元管理した後に周知徹底するところが実はPMにとっては大事で、なので「デザインだったらこう」「エンジニアリングだったらこう」という話だったり、「ビジネスだったらこう」というところを一元管理してオーガナイズするのがPMがやるべきことなので、ここがすごく大事になってきます。

Notionの最大の強みには“The all-in-one workspace”、「最強の言語化ツールです」というところがあります。やはりここが一番強いところで、やはりビジネス側も開発サイドも、1つの場所で言語化ができるのが一番いいなと思っています。

佐々木氏の実際の使い方

先ほどテンプレートの使い方を含めて「このように解決している」というところと、「こんな感じでやる」というところ。先ほどので僕がどのように言語化しているかみたいなところで、顧問先の情報が入っていないので、参考になってしまいますが。例えば、バックログやPRD。

あとはちょっと上級者向けですが、プロダクトマネージャーがオリジナルで作ってるといいなという、RICE（Reach, Impact, Confidence, Effort）スコアというものがあります。

RICEスコアは優先順位を決めるためのフレームワークです。関数を組んでそれぞれを入れていくと優先度が出て、どれから優先順位つけるかみたいところをロジックで可視化できたりもします。

あと、ちょうど今日リリースされていましたが、Figmaのデザインを埋め込めるようになりました。個人的にはメチャクチャありがたいです。（スライドを示して）これは僕のFigmaですが、こんな感じで、中でデザインが確認できるようになったりしています。

PMには「あのワイヤーフレームどこ行った問題」とか、Figmaとかを見に行く手間がけっこうあったりしますが、これがあると「ああ、こうだ。こうなっていた、こうなっていた」みたいな話で。（スライドを示して）これは僕が作った、記事用の画像ですが、このようなかたちで管理ができたりとか。

あと、リリース・プロセスとか、PMが整理しなきゃいけないものの1つに、「どうやったらデプロイできるのか」みたいなものがあると思います。そういったところをバックログを更新して、クオリティ担保の作業のQAをする。その後デプロイしますよと。

このリリースプロセスは意外と会社によって違ったりします。QAの専門の部署があったりなかったりも違うし、スタートアップだとテスト環境に入れてそのまま出しちゃうよみたいなこともあったりするので。そこは会社によって違うので、そのあたりを言語化するとか。

先ほどのフィードバック管理表とか、Amplitudeとかデータ分析性も埋め込みができるので、ここでKPIとかも追えます。

あとはミーティングの議事録です。（スライドを示して）これも僕が公開しているテンプレートですが、PMに業務を依頼する時に何をするのかみたいな業務内容であったりなどがあるので、こちらを見ていただくと、PMが用意しなきゃいけないドキュメント一式があるかなと思っています。

これはおまけですが、PM Clubに参加いただいた方は見ていますが、ポータルページがこんな感じで作られています。

まず「Read Me」（というページ）で「コミュニティはこんな感じですよ」というところとか、PM Clubを楽しむコツであったりとか。あとは中の取組みでとか活動ログをこんな感じでやっていますと。オフ会であったり読書会であったりとかをこのようにやっています。

Notionで特に僕はこの使い方がすごく好きなんですけど。ウェルカムボードとして使うのはすごくいいなと思っています。特に開発チームとかで、PMが最初に説明しなきゃいけないことってものすごく多いんですよ。「デプロイはこうします」という話もそうですし、「体制はこうです。なのであなたはこの人に何を聞いてください」みたいなこともあったりします。

そういった言語化をする時に、ポータルページみたいなものを1個作っておいて、ここにすべて載っているという情報にすると、いちいち確認しなくていいよねというところがあります。

あとは、僕（の会社）もSlackのチャンネルが「どうなっているんだ」ということになっていたので、「こんなチャンネルがありますよ」というところで、「参加してね」とURLつけたりとか、「このような使い方をしています」というところがあったりもします。