PMとして仕様を考える時のTips

新機能の仕様作成はPMが担当するでしょう。しかし、仕様を作成する時の気をつける部分を新人メンバーに教えるのがなかなか難しいです。 そのため、今回仕様検討時に意識すべきことを言語化してみます。

※具体的な内部仕様や設計はエンジニアの仕事なので、今回の記事ではスコープ外とします

ファクトベースで、インサイトを洞察する

プロダクトの仕様を考えるときに、解釈と事実を分けて考えることが基本となります。 解釈で物事を考えると、自分とユーザーの意見に乖離が生じてしまうでしょう。 あくまでユーザーはこう考えているという事実（課題）ベースでユーザーを考えることで、仕様がユーザーの課題に沿った良いものになると思います。

ここで注意しなければいけないのは、ユーザーの声を真に受けてはいけないということです。 ユーザーは自分の考えられる範囲でしか要望を上げられないし、そもそも何が問題なのかユーザー自身ではわかっていないことが多いです。 従って、「ユーザーの要望を生み出している根本の課題はなんだろう？」と洞察してみて下さい。

洞察のコツは以下の記事に詳しく記載してるので、参考にしてみて下さい。　

kyo9bo.hatenablog.com

仕様書が機能の共通認識になる

前提として、PM、PMM、エンジニア、デザイナー、QAなど立場や役割が違うステークホルダーがプロダクトに関わっているでしょう。プロダクトを考えてコミュニケーションする際、その共通認識として仕様書を介してやり取りが発生することを念頭において仕様書を書くべきです。

組織によっても異なりますが、仕様書を読み得る人によって情報の粒度を調整することが必要だと思います。

将来のメンバーが見ることを念頭におこう

将来のメンバーは、当然ながら現在の文脈（コンテキスト）は理解しておらず、仕様書からどうしてこの仕様になったのか推測し、読み取ろうとするでしょう。この時間の経過と将来を意識して、仕様書を書くべきです。

現在のメンバーが理解できない仕様はもってのほかで、「どうしてこの仕様になったか」という部分を言語化して仕様検討しないと、将来のメンバーはより理解できないでしょう。

従って、文脈を確認してない将来のメンバーが見ることを念頭に、全てに理由付けして深く思考したうえで仕様を作成してみることをお勧めします。

実現可能性を検証する

当然ながら、実現できない仕様は意味がないです。（完全に意味がないわけではないが、プロダクトに反映させれるかどうかという点では意味はない） なので、仕様を検討する過程で、「そもそも技術的に実現可能なのか」、「コストがかかりすぎて実質不可能ではないか」を意識して仕様を考えましょう。エンジニアとの連携が重要です。

最小機能でv1をリリースする

新機能だったり、プロダクトのfirst releaseだったり、リリースする時に小さくリリースする方が良い場合が多いです。 機能が多すぎると本当に必要な機能がユーザーに伝わらないかもしれないし、開発コストとメンテコストが高くなります。

機能を絞って最小機能でユーザーに提供することでフィードバックも得られるので、検証のサイクルもより早く回せます。プロダクトをグロースしていくという観点では、最小機能でv1をリリースする方が良いでしょう。

アップデートや他の新機能とのコンフリクトを意識する

仕様を検討するときは該当機能に目線がいってしまうが、アップデートしたり他の機能との住み分けを意識する必要があります。 「この機能があるから他の機能が開発できない」「この機能の仕様、アップデートしづらい」といった問題になると、後から改修が必要になり、開発コスト、しいてはユーザーの認知負荷が高くなってしまいます。

現状で考えられ得るアップデートや新機能が搭載された際、「これは邪魔しない機能かどうか」といった点を意識して検討することで、プロダクトの今後のグロースに対して許容度の高い仕様になるでしょう。

まとめ

仕様作成するときのTipsを記載してみました。 色々あるが、組織やプロダクトによって意識すべきポイントは異なるが、ぜひ参考にしてみて下さいmm