PM2年目が学んだプロダクト作りで外せないポイント - パート1

初めまして、ミツモアのプロダクトマネージャー歴2年目の仲井です。現在、ToB向けのVertical SaaSのPMをしています。

ミツモアでは日々営業、カスタマーサクセスチーム（CS）、PM、エンジニア、デザイナーが密にコミュニケーションをとりながら、一丸となってプロダクトに磨きをかけています。

そのコミュニケーションのもとになるのがPRDとなっているため、誰が読んでも作るものを簡単に想像・理解できるものにする必要があります。

今回は、私が2年間右往左往し続けて学んだPRDの記述方法を新米プロダクトマネージャーに向けてご紹介します。

はじめに

私は前職が食品関係だったため、ITに関しては右も左もわからず非常に苦労しました。仕事の進め方もそうですし、何よりも知らない単語が飛び交っていて毎回調べていたのを思い出します。

読者の中にIT初心者の方もいらっしゃると思いますので、今回お話しするPRDとはなんぞやという話からします。

PRDとはProduct Requirement Documentsの略で、プロダクト要求仕様書のことです。これを元にデザイナー、エンジニアが仕様を把握してプロダクトを作っていくため認識の齟齬が生まれないようにする必要があります。

一般的には以下が記載されていることが大事だとされています。

1. 誰がオーナーシップを持って
2. どういう目的で
3. 何を
4. いつまでに作るのか 今回は中でも特に2が大事ですよということをお伝えします。

「目的」には何を書くべきか

PRDに記載すべき「目的」の内容としては大きく背景と提供すべき価値に分かれると考えています。

• 背景
  • どういう事情があってその機能を作る必要があるのかを記載します。これをもとに機能要件の取捨選択、実装優先順位等を判断することになるため、関係者の認識が揃うような記述を心がけましょう。
    • OK記載例：現在は売上管理という機能を提供しているが、これだけでは一連の業務が完結していない。一部の業務、具体的にはxxの処理だけ外部のシステムを利用している関係で、二重入力の手間が発生しており、我々が大切にしている「シームレスな体験」を提供できていないのが現状である。
    • NG記載例：現在はAという機能を提供しているが、Bという機能を作ることでユーザー体験向上が望まれ、結果的にchurn rateの低下に繋がる。
  • 前者の例は実際にユーザーがどういう課題を抱えていて、その結果どういうUXを毀損しているのかを言語化できているが、後者は機能と結果についてのみ説明している。これでは何が問題で解決策として適切な手段の選定ができない。
• 提供すべき価値
  • 機能を作ることで、社内的、社外的（顧客、関係者）にどういう価値をもたらすのかを記載します。これがブレてしまうと判断に迷った時の優先順位や作るもの自体が変わってしまいかねないです。
    • OK記載例：リアルタイムに収支情報が可視化されることで、収支のバランスが芳しくない時にマネージャーが迅速にフォローできる。結果、適切な利益率の確保に繋がる。
    • NG記載例：売上、原価、経費を一覧で確認できる。
  • 前者は価値としてどういう効果があるかということを記載しており、後者は機能の説明をしてしまっています。機能の説明は機能要件として記載すべき内容なので、ここでは「価値」を記載して読者との目線合わせをするのが大切です。私も最初は機能について書いてしまい、何度もレビューで修正されていました。その経験があったからこそ、「提供価値」って何だろう？それによって何が良くなるんだろう？と深く考える習慣がつきました。

書くために必要な情報収集

私が普段から意識していることは2点あります。

1 . ユーザーの生の声に触れて、解決策を導く

我々は日々「xxができるようにして欲しい」という要望をいただきます。ユーザーから直接聞くこともあれば、CS担当者から間接的に聞くこともあります。この時に大切なのはできるだけ一次情報に触れるということです。元々の課題が我々の耳に届く頃には全然違う情報として加工されていることがあるからです。

【情報の流れ】

ユーザーが直面している課題→ユーザーの解釈→営業・CSの中で認識した事実→営業・CSの解釈

もちろん全て顧客に直接聞くことは難しいため、最低限以下を確認する癖をつけています。

ユーザーの業務内容 操作の流れ どこでどういう課題に直面したか ユーザー、営業、CSにはそれぞれの専門分野があり、プロダクトの機能について考えるプロではないので、意見を鵜呑みにして開発を進めるとつぎはぎのプロダクトができてしまいます。これではミツモアのバリューの1つである、「理想からの逆算」と真逆の方向に突き進んでしまいます。

そのため、できるだけ解像度高く「事実」をヒヤリングした上で、理想の業務を実現するための機能としてどうあるべきかを定義するのが我々PMの仕事なのかなと思います。

2 . 汎用的な機能を提供する

課題解決をしようとすると、どうしても目の前の事象に囚われたまま解決策を出してしまいがちです。（今でもたまにやってしまいます）これを繰り返していくと顧客の数だけ線形的に開発が増えていき、リソースを割くべき開発に着手できなくなります。

　　　　　　 　

もちろん全て理想通りにはいかないこともありますが、たとえ少しの間工数が増えてもさまざまなシーンに使えるクリティカルな機能を考え抜くことで開発速度が速くなり、顧客満足度の向上にも寄与します。これこそがPM業務の醍醐味であり、PMの腕の見せ所だと思います。（いい解決策が浮かんだときは少しの間余韻に浸ることもあります）

まとめ

PRDを書く時には何の目的でどういう人にどんな価値・体験を届けたいかを、なるべくわかりやすく言語化することが欠かせません。そのためにも、ユーザーがプロダクトをどう使い、どんな悩みを抱えているのかを日頃から確認する機会を持ちましょう。

私がPMになりたての頃、解決すべき問題がわからない時に、顧客に何度もヒヤリングをさせていただきました。この時に解像度高く業務内容、課題を理解できたおかげで良い解決策を導き出すことができました。価値を提供した結果顧客から感謝され、信頼されたときの喜びもひとしおでした。

新米PMの皆さんも、質の高いインプットとアウトプットを繰り返すことで要件定義の精度が上がり、困難な課題にも臆することなく立ち向かえるようになることを願っています。