プロダクトマネージャーの仕事は、本質的には「混沌」から「秩序」へと移行し続けるゲームのようなものだ。
需要プールに山積みのユーザーフィードバック、運用担当者からの緊急の要望、そして「この機能は実際にはどんな問題を解決するのか？」と疑問を呈する開発者たち…毎日あらゆる種類の情報に圧倒され、それらを整理して計画するための明確な方法がないと、「忙しそうに見えるが、製品の方向性がますます不明確になる」という窮地に陥りやすい。
本日は、プロダクトマネージャーが3つの主要な図表を使って、混沌とした要件を明確な製品設計図に変換する方法について解説します。これらの3つの図表とは、要件リスト、製品機能構造図、そして製品ロードマップです。
大量の要件を受け取った場合、すぐに図を描こうとしないでください。最初のステップは常に、分類、絞り込み、優先順位付けです。
数十、あるいは数百もの要件に直面した場合、それぞれの要件を以下の次元で分類することができます。
ソースの次元：ユーザーからのフィードバック、データ分析、競合他社の調査、経営上のニーズ、運用上のニーズ、および技術的なニーズ。
タイプ次元：機能性、最適化、ユーザーエクスペリエンス、パフォーマンス、コンプライアンス
価値の次元：コアバリュー、補助バリュー、擬似ニーズ
このステップの主な目的は、「全体像を把握する」ことです。すべての要件が分類されると、製品改善の方向性についてマクロレベルでの理解が得られます。
カノモデルは、要件を5つのタイプに分類する、要件スクリーニングのための古典的なツールです。
基本要件：これらは製品に必須の機能です。これらがなければ、ユーザーは不満を抱きます。逆に、これらがあれば、ユーザーは当然のこととして受け入れるようになります（例えば、ECアプリの決済機能など）。
望ましいニーズ：ユーザーが明確に求めているもの。これがより良く実現されるほど、ユーザーの満足度は高まります（例：検索結果の精度）。
興奮を促すニーズ：ユーザーにとって予期せぬサプライズ。サプライズがなくてもユーザーエクスペリエンスに影響はありませんが、サプライズがあれば興奮と興奮が生まれます。
差別化されていないニーズ：ユーザーはそれが実装されているかどうかに気づかないでしょう。
逆需要：そうすることで、実際にはユーザーに嫌われる可能性がある。
選考を行う際は、まず「違いなし」と「逆転」の要件を除外し、最初の3つのカテゴリーに絞って検討すると良いでしょう。
RICEモデルは、優先順位を定量化するためのツールであり、以下の4つの側面から構成されています。
リーチ（対象範囲）：この機能はどのくらいのユーザーに影響を与えますか？
影響力：あなたは個々のユーザーにどの程度の影響力を持っていますか？（通常、3、2、1、または0.5の尺度で評価されます）
自信度：上記の判断にどの程度自信がありますか？（パーセント）
労力（投入）：開発には何人日必要ですか？
計算式：RICEスコア＝（リーチ×インパクト×信頼度）／努力。スコアが高いほど優先度が高くなります。
表やマインドマップを使用できます。明確な要件リストには、要件名、情報源、KANO分類、RICEスコア、および予備的な結論を含める必要があります。
要件は明確になったが、チームが必要としているのは「実装すべき20の機能」のリストではなく、「これらの20の機能をどのようにまとめて構成するか」を示す構造図である。
製品機能構造図（製品情報アーキテクチャ図とも呼ばれる）は、製品機能の階層的な関係と論理的な構成を示します。これにより、開発者はモジュールの境界を、デザイナーはページナビゲーションを、テスターはテストケースの網羅性を理解することができます。
標準的な機能アーキテクチャ図は、通常3つのレベルで構成されています。
第一レベルモジュール：製品の最上位の機能区分であり、通常は下部のナビゲーションバーまたはコアビジネスセクション（ eコマースアプリの「ユーザーモジュール、製品モジュール、トランザクションモジュール」など）に対応します。
二次機能：各主要モジュールの下にあるコア機能（例： 「製品カテゴリ」 、 「製品表示」、 「製品管理」の下にある「製品モジュール」）
商品管理」の下にある「商品リスト」 、 「商品編集」、 「商品削除」など)。
MECE原則とは、同じレベルの機能は相互に排他的であり、重複や省略がなく、網羅的に列挙されなければならないという原則である。
ユーザーの視点：組織構造は、企業の組織構造ではなく、ユーザーの習慣に基づいて構築されるべきである。
拡張性：将来の機能拡張のための余地を残しておく。設計をあまり硬直的にしない。
ProcessOnでは、「フローチャート」または「組織図」テンプレートを直接使用して、機能構造図を作成できます。
機能アーキテクチャ図は完成し、チームは「何をすべきか」を把握している。しかし、重要な疑問が一つ残っている。「いつ実行すべきか？」
製品ロードマップは、この問いに答えるためのツールです。製品ロードマップは、製品の反復開発計画と機能リリーススケジュールを、一定期間にわたるタイムラインの形で示します。
タイムライン：製品のスケジュールに応じて、四半期ごと、隔月ごと、または月ごとの場合があります。
機能モジュール：各時点でリリースされるコア機能。
目的：各バージョンはどのような問題を解決し、どのようなビジネス目標を達成するのか？
内部ロードマップ：チーム内部での使用を目的とした、具体的な機能や開発スケジュールを含む詳細なロードマップ。
外部ロードマップ：大まかなもので、顧客や市場が理解できるように「どの方向に向かっているか」だけを示す。
戦略ロードマップ：製品ビジョンと年間戦略方向性を示す、より高レベルの視点。
ステップ1：時間スケールを決定する
まず、ロードマップの対象期間（例：6ヶ月または1年）と最小の時間単位（四半期または月）を明確にします。
ステップ2：機能のグループ化
要件リストの優先順位付けを行った後、それらを異なる期間に割り当てます。基本原則は、まず基本的な要件に対応し、次に想定される要件に対応し、最後に興味深い要件をサプライズ要素としてプロセスに織り込むことです。
ステップ3：バージョン命名
各バージョンには、例えばV2.0「基本取引版」やV2.1「マーケティング強化版」のように、意味のある名前を付けましょう。名前自体が、そのバージョンの目的を要約しています。
ステップ4：ターゲットをマークする
各時点の下に、このバージョンの主要目標を1文で要約してください。例：「グループ購入機能を導入し、新規ユーザーのコンバージョン率を20%向上させる」。
ステップ5：視覚的なプレゼンテーション
上記の情報をガントチャートまたはタイムラインで視覚化します。横軸は時間、縦軸は機能モジュールを表し、異なる色は異なる優先順位または状態を表します。
具体的な日付を約束しないでください。特に外部向けのロードマップでは、「4月15日」よりも「第2四半期」を使用する方が安全です。
余裕期間を設ける：開発中は必ず予期せぬ出来事が起こるため、タイムラインにはある程度の余裕を持たせる必要があります。
動的な調整：ロードマップは固定されたものではなく、毎月見直され、必要に応じて調整されます。
関連目標：各バージョンでは、「何をするか」だけでなく、「なぜそれを行うのか」を明確に説明する必要があります。
プロダクトマネージャーの仕事の本質は、「曖昧なもの」を「明確なもの」に変えることです。要件分析によって、様々な意見が入り混じったものを明確な優先順位を持つリストにまとめることができ、機能構造図によって、リスト上の機能項目を論理的に明確な製品アーキテクチャに変換することができ、製品ロードマップによって、静的なアーキテクチャを動的な実装スケジュールに変換することができます。
これら3つの図が明確になれば、開発者、デザイナー、テスター、運用担当者と共通の言語でコミュニケーションを取ることができます。チームは、どこに向かっているのか、なぜそこに向かっているのか、そしていつ到着するのかを把握できるようになります。
ProcessOnでは、プロダクトマネージャー向けに専用の機能テンプレートをご用意しています。要件分析シート、機能構造図テンプレート、製品ロードマップテンプレートなどです。ワンクリックで作成でき、すぐに製品計画作業を開始できます。ぜひお試しください！
無料のオンライン共同マインドマップフローチャート
