✅5年目PdMが要件定義で意識している門外不出の12項目
こんにちは。
「RENOSYマイページ」のプロダクトマネージャーを担当している野浪です。一つ目の記事「憑依力」プロダクトマネージャーがユーザーになりきる技術に続き、第二回では、要件定義に焦点を当ててみたいと思います。
私がこれまで不動産テックのPdMとして企画やアイディアをプロダクトで実現させてきた中で意識している事をなるべく網羅して12項目にまとめました。
今まで社内でも誰にもシェアしたことはなかったのですが、今回ついに初公開したいと思います。（と、無駄にハードルを上げてみました）
一つ一つの項目自体は当たり前なものばかりなのですが、プロダクトを進める中でふとした時に見直せるものとして使ってもらえたらと思います。
私以外のRENOSYのプロダクトマネージャーからも、PdMってどんな仕事？について書かれている記事や、戦略策定に役立つ記事もありますので興味があったらご覧ください！
私は誰？
「ネット不動産」を推進する不動産テック企業、株式会社GA technologiesでプロダクトマネージャーをしています。
4年間で不動産クラウドファンディングサービスの初期リリースや不動産投資オーナー向けアプリ等のPdMを担当し、今は不動産売却のDXを推進するため、RENOSYの売却向けマイページのプロダクトマネージャーをしています。
趣味はCポップ（中国語の歌）を聞く事と、たまに美術館に行く事です。
要件定義フェーズで必ずチェックする12項目
今日は、そんな私が要件定義の時に気をつけていること、意識していることについて説明していきたいと思います。
プロダクトマネージャーの方で、要件定義や仕様書を作る際に確認するチェック項目として、参考になりましたら幸いです。
範囲としては、プロダクト開発の上でのWHATとHOWの間、つまり企画を自ら作る、あるいは企画者から受け取ったあとから、デザイナーやエンジニアに要件や仕様を渡し、リリースする前までとします。
数も多いので、プロジェクト全般編、要件定義編、ワイヤーフレーム編と3つに分けてみました。
前提として、私が担当するプロダクトには以下のような性質があります。
・0→1プロダクトなので、MVPで素早くリリースし検証できることを重視
・プロダクト単体ではなく、リアルを含めたユーザー体験までセットで考える
・技術選定などは社内のエンジニアに一任
プロジェクト全般編
⛳️1.企画を自分ごと化できているか
これは言うまでもないことでありつつ、一番重要なことかもしれません。
企画を具現化する時に「ユーザーにとってどんな価値があるか」をPdM自身が一言で説明できるようにしています。
例えば「◯◯さんから作ってと依頼が来たから作る。」では、本来の意図からはずれた物が出来上がる可能性がありますし、そもそもリリースされずにプロジェクトが止まってしまうこともあり得ます。
自分の企画であれ、ビジネス側からの依頼であれ、ユーザーにとっての価値を自分の中で納得した状態で、自分ごと化できていることが大切です。
プロダクトに魂を入れるのは、PdMであるあなたなのです。
🎛2.ゼロから開発する以外の方法はないか
昨今はノーコード、ローコードという言葉もポピュラーになってきました。
そもそも論ですが、そのプロダクトや機能を開発せず、もっと早く、手軽に実現する方法はないかを最初に考えるようにしています。
自社開発であろうと社外への業務委託であろうと、一度に開発できる質と量には限界があります。実現されるアウトプットの可能性の幅を広げ、実はこういう実現方法もあるかも、と考えてみるのも一つの選択肢です。
🚀3.それは実現可能か
「空を飛ぶことができる竹トンボ状のデバイス」、あったらいいですよね？
きっと発売できたら大ヒット間違いなし！でもこれを現代の技術で実現できるでしょうか。（できたらいいんですけど！）
少々極端な話をしてしまいましたが...アイディアを形にする上で「実現可能か」は、避けて通れない条件です。
そしてこれはPdMがエンジニアに「これってできますか？」と質問して終わることではありません。PdMが自分の知見の中である程度答えを出せるようにしておく必要があります。
自分にとって知見が少ない領域でも、しっかりと周りを巻き込んでわかる人に聞き、答えを出せるようにしています。巻き込み力！
🛹4.最初は全ユーザーを幸せにできない事を関係者と共有
これはまた難しいのですが、まずMVPのフェーズにおいてはプロダクトを使う100%の人をハッピーにはできないと言うことを理解しなくてはなりません。
もちろん、理想は最初から全員がハッピーであることです。しかしながら、新しい価値を創造する過程においてはこの過程を経なくてはなりません。
MVP(Minimum Viable Product)の説明でよく出てくるイメージ図でも「最初から自動車を作るのではなく、最初はタイヤと板だけのスケボーから」という絵を見たことがある方も多いと思います。
🛹→🛴→🚲→🏍→🚗
その上でおおよそ利用者のうちのどれぐらいの人が満足にそのプロダクトを使えるとしたらその検証は成功か、と言うところを事前にご自身やステークホルダーの中でクリアにしておく必要があります。
それができていないと、「使えるっちゃ使えるけど全然便利じゃないね。やめよう。」となってしまい、何も検証できずに終わってしまいます。
🏛5.リーガルチェック
その具体化された機能が、プロダクトに関連する法令や各種規制、ガイドラインに沿ったものかを確認しています。
GA technologiesにはこの記事にもあるようにプロダクトの意図を理解し、法的なアドバイスをしてくれるリーガルチームがいるので、何か新しく機能を実装する際には必ずアドバイスをもらっています。
そしてこれも「確認お願いします」で終わるのではなく、自分の中に知見を溜めてある程度答えを出せるようになった上で「こういう観点で考えて問題ないと思うのですがいかがでしょうか？」と、提案するようにしています。（そのために宅建士の資格も取りました！）
また、「法的にOKだからOK」という感覚ではなく「ユーザーに誤解を招かないか」や「本来の意図と違う利用のされ方によって、ユーザーに不利益がないか」といった総合的な観点を持ちながら企画を具体化させています。
🔀6.他のプロダクトや関係者へのインパクト
そのプロダクトや機能をリリースした時に他のプロダクトと干渉する部分がないかや、社内外の関係者への影響を事前に想定し、必要な共有や調整などを行っています。
特に我々のRENOSYはリアルとテックの両方が混在しているサービスですので、ステークホルダーは多岐に渡ります。
いくらスピード重視と言っても思わぬところで当初想定していなかった影響が出る可能性がありますので、予め想定と対策を行っています。
仕様書作成編
🌱7.それはミニマムか
なぜミニマムである必要があるか。それは早くプロダクトを世に出して使われるか、価値があるかを素早く検証するためです。
最初から理想の状態にできたら最高ですが、スピードと提供価値のバランスを考慮して絶妙なポイントを探る必要があります。
🧪8.検証したいことが検証できるか
企画が具体化されていき「技術的に実現可能」な状態として全体的な仕様が見えてきたあたりでもう一度「プロジェクト全般編」を見直します。
その中でも、そもそもやりたかったことからずれてないか、検証したいことが検証できる要件になっているかと言うところは何度確認しても確認しすぎると言うことはありません。
「やりたいこと」と「できること」を溶け込ませて両立させる最大公約数を見つけるのがPdMの役割なのです。
📈9.評価可能になっているか
機能がリリースされた時に「やったー！リリースできた！よし次！」←これ私やりがちです。（コラ！）
要件定義時点で、リリース後にこのプロダクトや機能の効果を検証できる状態になっているかを確認しておきましょう。
「リリースはしましたがうまくいってるかはわかりませんでした。」ではすべての工程が無に帰してしまいます。
🙅♂️10.何をしないか
「それはミニマムか」と似ていますが、「何をするか」と同じぐらい「何をしないか」を決めることを大切にしています。
ユーザーに価値を提供したいからこそ「あれもやりたい」「こんなケースにもしっかり対応したい」といったやりたいことが溢れ出してきます。
そんな時はもう一度「何の価値提供を最速で提供したいか」に立ち返り、自らが勇気を持って「何をしないか」を定義することがPdMの責任の一つだと思っています。
これはともすれば価値提供の反対のことをするので、時折胸が張り裂けそうな時があります。
ワイヤーフレーム編
🤳11.実際の利用シナリオを想定しているか
ワイヤー＝全体的な構成・要素を配置して後はデザイナーに任せちゃおう、とは考えないようにしています。
例えば不動産に関するプロダクトのワイヤーを作る場合、左のイメージのように構成要素を並べるだけではなく、右のように実際の物件名や実際の価格、スペックなどの現実的な情報を配置します。
もちろんデザイナーやエンジニアにはプロダクトの目的や背景などを含めて情報共有しますが、情報の具体性が一番高くなるのがワイヤーフレームです。
ワイヤー上で具体性のある情報を示すことによりその後のデザイン、エンジニアリングの工程でも認識の齟齬を少なくする効果があります。
❗️12.幅広い利用ケースを想定できているか
ワイヤーで画面遷移を作る時にユーザーに一番通って欲しい画面だけを作るのではなく、様々なシチュエーションを想定してワイヤーフレームを作るようにしています。
例えば検索結果画面の仕様を考える時は、検索結果のアイテムが表示されている場合だけではなく、検索結果が0件だったら？までを考え、エンプティーステートのワイヤーまでを用意しておきます。
ただ、仕様策定時点で考えられるシチュエーションには限界がありますので、求められているスピード感やエンジニアとの連携状況を踏まえて、その範囲は変動してくると思います。
まとめ
いかがでしたでしょうか？
「このどこまでがPdMの役割か」については事業・プロダクトのフェーズや社内での役割分担によってその範囲がまったく違うと思いますし、場合によってはデザイナーやエンジニアがプロダクトマネージャーを兼務している場合もあると思います。
RENOSYの中でもPdMの役割は完全に決まっているわけではなく、個々のスキルセットやチーム構成によって役割や業務範囲はそれぞれ異なっています。
今回はあくまでも私の場合でしたが、プロダクトの要件定義フェーズにおいての比較的主要な項目をおさえたつもりではいるので、役割に関わらず参考なればと思います。
アジャイル開発だからといって、どんどん作ってダメだったら元に戻して、ではプロダクトの立ち上げやグロースのスピードはかえって遅くなってしまいます。
要件定義の精度をあげてスムーズにプロダクト開発を進めるのはプロダクトマネージャーの役割。
「やることを決める」のも「やらないことを決める」のも、あなた次第！
徹底的にユーザー目線でプロダクトを推進してくれる方募集中！
GA technologiesでは一緒に「徹底的にユーザー目線で」RENOSYの様々なプロダクトを作ってくれる、PdMやデザイナー、エンジニアなどを絶賛積極募集中です！
私たちが目指す世界観を実現するには、メンバーが足りません！
ちょっと興味あるかも、という方がいたら下のリンクからお気軽にお声がけください！
最後まで読んでいただきありがとうございました。
この記事が気に入ったらサポートをしてみませんか？