創業期・成長期におけるプロダクト要求仕様書の書き方 – Offers MGR

はじめに

PM の仕事として、仕様書を書くタスクがあります。仕様書は、PRD（プロダクト要件仕様書）とも言われ、 Product Hunt の PDR を始めとした様々な構成の具体例があります。

ただ、チームメンバーの数や習熟度やリリースからの経過年数によって理想の仕様書というのは異なってきます。

例えば、5名以下のスタートアップでこれから新規にプロダクトを立ち上げる場合、まずは動くものを早く作ることが重視される場合があります。スピードが最優先のフェーズでは、仕様書はプロトタイプで代替され省略されることもあります。

プロダクトの立ち上げが完了し、事業の拡大に応じて関係者が増えた時、これまで暗黙知としてプロダクトに反映されていた「なぜ」「なんのために」といった目的を伝えるために仕様書を作成することもあります。

企業が成熟期に入り、組織が拡大して関わるチームが増えると、プロダクトの全容をパートナー企業のチームに伝えるために仕様書を作成することもあります。

このように、各フェーズごとにどこに注力して仕様書を書くべきかは異なってくるかと思います。その中でも今回は創業期・成長期において最低限必要となる要素は何かを見ていきます。

何を書くべきか

先程 PDR という言葉が出てきましたが、PDR は開発者、デザイナー、もしくは他の利害関係者が製品のステータスを目的を理解するために用いられるドキュメントとなります。プロダクトマネージャーはこのドキュメントを最新の状態に保つ責務を持ちます。

冒頭でも紹介しましたが、有名な PDR の具体例として、Product Hunt の PRD があります。

https://docs.google.com/document/d/1yrU5F6Gxhkfma91wf_IbZfexw8_fahbGQLW3EvwdfQI/edit

Product Hunt の PRD は以下のような構成となっており、企画をかなり詳細まで網羅するフォーマットになっています。

- 概要と目的
- 誰のために
- なぜ
- どのようなものを
　　- ユーザーのタイプ
　　- 用語集
　　- UI/画面/機能
- ブレインストーミング アイデア
- 競合分析
- 初期ユーザーと獲得戦略
- モックアップ
- 技術ノート
- マーケティング戦略
- リリース後 マーケティング戦略

しかし、上記を全て満たす仕様書は企画と開発にスピード感が求められるスタートアップにおいて、企画と計画に膨大な時間を要するためマッチしません。

ここで、創業期の段階では最低限の情報を示した mini spec（2016年頃、株式会社ペロリのテックブログで紹介されていたフォーマット）を利用することをおすすめします。

Overflow では mini spec として、以下の項目を網羅するように仕様書を書いています。

- 概要と目的
　　- 何を達成したいのか
- 誰のために
- なぜ
- 定量的なデータソース KPI
　　- マーケティング要素も含まれる場合もある
- どのようなもの
　　- UI/画面/機能
　　　　- 機能ごとの説明・目標・ユースケース
　　　　- 一般的な全体像を表すガイダンスUI/UX（全てのシナリオを網羅する必要はなく、ユーザーのワークフロー全体を説明するために利用）
- KPI（Why に KPI が含まれる場合がある）

mini spec に記載するべき要件が定まっていると、マーケティングチームや PM が開発チームに依頼をする前にどこまで仕様を詰めておく必要があるのか明確化することができます。逆に定義しておかないと、PM とデザイナー・エンジニア間での役割分担や責任範囲が曖昧になり、開発要件を詰める際にコミュニケーションエラーが発生する可能性があります。

注意するべき点

開発チームが作業を開始する前に細かい仕様が指定されている

先程役割分担や責任範囲について触れましたが、通常 WHY や WHAT をマーケティングチームや PM が定義し、その後 HOW からエンジニアやデザイナーが加わり、細かい仕様を定義していきます。

mini spec の段階で PM がどのように作るかを細かく指定する必要はありません。

メンテナンスされていない

mini spec は一度作成したら終わりではありません。ビジネス指針の変更により仕様に変更が発生することはありえます。PM はメンテナンスする責任を持ち、途中からチームに参加したメンバーが必要な項目を素早く理解できるようにしておく必要があります。

mini spec のメリット

振り返りを行うことができる

プロジェクトの KPI が明確になっているため、リリース後に KPI が達成されたのか確実にすることができます。目標が達成されなかった場合でも、振り返りを行うことで次に繋げる事ができるようになります。

役割分担の明確化

フォーマット化することで、だれがどこまでを記述するべきか、どこに責任を負うべきかを明確にすることができます。また、誰が要件定義を行っても一定の品質を保ちながらプロジェクトを進めることができるようになります。

さいごに

仕様書を作成するにあたって「何を作るか」だけが共有される場合があります。しかし、開発の背景や KPI を知らないと、指定されたものを作ることだけが目的となり、関わるメンバーから新たなアイディアや自発的な関わりは生まれてきません。

例えば社内に副業のメンバーがいる場合、WHY を積極的に共有することにより、プロダクトやドメインの理解を促すことができ、チームのメンバーとして自立的に動いてもらう助けにもなります。

Offers Manager では副業も含めた全てのメンバーが、社内でどれくらいのコミュニケーションを行えているか、アウトプットを出せているかを可視化することができます。チームメンバーが正常に稼働できているか心配な方は、まずは可視化することを検討してみてはいかがでしょうか。