プロダクトマネージャーが知っておきたい5つのフレームワークとは

はじめまして、エンジニアスタイル編集部です！

コラムページでは、ITフリーランスに向けてお役立ち情報を発信します。Twitterではホットな案件を紹介してまいりますので、ぜひフォローをお願いいたします！
本記事が、皆様の参考になれば幸いです。

経験がまだ少ない方にもわかりやすく説明するために、初歩的な内容も記載しております。記事も長いので、実務経験豊富な方は、ぜひ目次から関心のある項目を選択してください。

エンジニアスタイルは、最高単価390万円、国内最大級のITフリーランス・副業案件検索サービスです。PdMのフリーランス・副業案件一覧をご覧いただけますのであわせてご確認ください。

プロダクトマネージャーが知っておきたい定性型定量型のフレームワーク

顧客のニーズや製品が目指すべきビジネス目標を明確にし、それを達成するためにスケジュール管理やコスト管理などのマネジメント業務を行い、プロジェクトチームを牽引することがプロダクトマネージャーの仕事です。

IT企業であれば顧客へ提供するIT機器やサービス、ソフトウエア、アプリケーションなどの開発・販売の全体指揮者・総合責任者という立場に該当します。

ITプロダクトの競争が激化する昨今、プロダクトマネージャーの仕事は重要度を増しています。

そんなプロダクトマネージャーの業務は、フレームワークを活用することで、効率化を図ることも可能です。

まずはプロダクトマネージャーが知っておきたい定性型のフレームワークを3つご紹介いたします。定性型とは、数値化することができない目標のことを指します。数字で現れる結果よりも、そこにいたるまでのプロセスに着目していることが多いです。目指すべき目標を言語化したものと言い換えてもいいでしょう。

プロダクトマネージャーとして働いている方や、フレームワークを活用して業務の効率化を図りたいと考えている方は、ぜひ参考にしてみてください。

THE PRODUCT VISION BOARD

まず初めに紹介するのは、「THE PRODUCT VISION BOARD」というフレームワークです。プロダクトマネージャーとして働いている方であれば、名前に見覚えがあるという方も多いのではないかと思います。

プロダクトマネージャーが活用するフレームワークの定番ともいえるTHE PRODUCT VISION BOARDですが、実際にはどのような特徴が挙げられるのでしょうか。詳しく解説していきます。

概要

THE PRODUCT VISION BOARDは、プロダクト開発のビジョンを可視化するフレームワークです。

プロダクト開発のビジョンとは「会社全体のミッションに則した形で、プロダクトを通して対象となる市場に対し、どのような価値を提供し、何を実現するのかを明確かつ簡潔にまとめたもの」を指します。

具体例として、Amazonが提供している電子書籍サービスのKindleについて見ていきましょう。Kindleのプロダクトビジョンは以下の通りです。

• あらゆる言語で書かれた、絶版も含めたすべての本を60秒以内に利用できるようにします
• 文庫本より薄くて軽く、200冊の本を収納できます
• Kindleは長文読書の目的で作られたものです。Kindleは、近年急増している集中が散漫になる情報収集ツールの氾濫に対抗して、長時間の集中を持続させる世界へと移行していくことを願っています

このように、開発する製品の価値やその製品が目指すべき地位を明確にし、商品としてどのように展開していくのかを示したものがプロダクトビジョンです。

THE PRODUCT VISION BOARDの考え方には4つの軸があります。

• これからつくるプロダクトにはどのようなニーズがあるのか
• これからつくるプロダクトは誰をターゲットにしているのか
• 自社の資源でこれからつくるプロダクトを生産できるのか
• このプロダクトを販売したら、売上高と利益はどれくらいになるか

このフレームワークを活用することによって、製品のニーズ、ターゲット、実現可能性、ゴールを明確にすることができます。

メリット

THE PRODUCT VISION BOARDを活用するメリットは、製品の開発するうえでその必要性や商品化した際の価値を明確にすることができる点です。

企画立案の際にこちらのフレームワークを用いれば、プロジェクトメンバーに対する説明にも役立てることができます。

デメリット

THE PRODUCT VISION BOARDのデメリットとして、事業価値と開発の複雑性が考慮されないという点があります。顧客のニーズとプロダクトの目指すべき姿を考えるフレームワークなので、本当に実現できるかどうかについては熟考する必要があるでしょう。

Product Prioritization Framework

次に紹介するフレームワークは、「Product Prioritization Framework」です。

プロダクト開発において機能の優先順位を決めることは重要なことです。

Product Prioritization Frameworkは、そんな機能の優先順位を決める業務に特化したフレームワークとなっています。

概要

Product Prioritization Frameworkは、プロダクトに搭載する機能の優先順位を決める際に用いられるフレームワークで、「利用頻度の高さ」と「意外性の有無」を軸に、製品にとって必要な機能を決めていくというものとなっています。

例えば、アパレルメーカーが衣類を発売するとき、「デザイン性」や「使用感」、そして「価格」などの機能を持たせる必要があります。

低価格の製品を作った場合には、多くの人に手に取ってもらいやすくなりますが、競合製品に比べ、使用感は劣ってしまいます。また、デザイン性を優先すれば、魅力的な製品になりますが、価格面では不利になってしまうでしょう。

これらの機能の優先順位を決めるために活用できるのが、Product Prioritization Frameworkです。

Product Prioritization Frameworkの各象限について紹介します。

• must-have：製品にとって搭載されることが一般的である機能のこと
• Wow!：ユーザーに新たな体験をもたらす機能であり、製品の「売り」となる
• neat：搭載されていたら嬉しい、できればあったほうが良い機能のこと
• who cares：あってもなくてもいい機能のこと

プロダクトをこのフレームワークに合わせることで、優先順位の整理を行うことができます。

メリット

Product Prioritization Frameworkは、このフレームワークを活用するプロダクトマネージャー以外の人にとっても見やすく、分かりやすいものです。

そのため、製品の開発において、必要な機能を話し合う際に活用することができるでしょう。スタートアップミーティングの際に役立てることができる点が、メリットであると言えます。

デメリット

Product Prioritization Frameworkを使用するデメリットは、製品のジャンルが同じである場合だと、成果を発揮しにくいという点です。例えば、先ほど例に出したアパレルメーカーでは、1年で何度も「Tシャツ」を発売するかと思いますが、開発のたびにこのフレームワークを用いても、目新しい結果は出にくいでしょう。

業務の効率化を図れるという点においては非常に優秀ですが、使えるタイミングは限られています。

666ロードマップ

次に紹介するのが「666ロードマップ」です。

このフレームワークは、プロダクトの発売後、そのライフサイクルを見据えて企業利益と顧客満足度を最大化するために使用します。

概要

666ロードマップは、プロダクトの発売後の、6週間目で考えること、6カ月目で考えること、6年目で考えることを決めるフレームワークです。

具体的には、

• プロダクトの販売後、6週間後に市場アンケートを取り、ユーザーの意見を確認する
• 販売から6か月後、売上高目標の達成度を測る
• 販売から6年後、プロダクトの大幅リニューアルを実行する

このように、「6」という数字が関わる期間にプロダクトの見直しを行い、その価値が常に最大化されるように手を加えることを目的としています。

この「666」という数字は、聖書を参考にしていると言われています。日本人にとっては馴染みのない数字かもしれませんが、実際に当てはめてみるとこの期間は実に絶妙です。

プロダクトを販売してみた後、数字は「4」になったり、「8」になったりと変動するかもしれませんが、この考え方を軸として持っておくことは重要です。

メリット

666ロードマップのメリットは、プロダクト販売後に関する議論をチーム全体で行う際に役立つという点です。このフレームワークを用いれば、プロダクトの展開について明示的に示すことができるので、健全な意見のやり取りを行うことができるでしょう。

デメリット

666ロードマップを使用するデメリットは、定期的に議論を繰り返す必要がある点です。プロダクトの展開は時流に即す必要があります。価値を最大化するためには定期的なミーティングが必要です。

また、プロダクト部門と事業部門が異なる目標を掲げている場合には機能しづらいと言えるでしょう。

プロダクトマネージャーが知っておきたい定量型のフレームワーク

次に、プロダクトマネージャーが知っておきたい定量型のフレームワークについて紹介していきます。

定量型という言葉の通り、数値や数量で表れる業務を効率的に進めるための考え方について説明します。

定性的な考え方に対し、定量的な考え方は数字という明確な結果を導くことができるため、新人のプロダクトマネージャーの方でもフレームワークを取り入れやすいのではないでしょうか。

今回紹介する2つのフレームワークは、多くのプロダクトマネージャーが実際の業務で取り入れているものです。フレームワークを活用することで、考えを自動化することができ、業務の効率化を図ることも可能となるでしょう。ぜひ参考にしてみて下さい。

RICE

まず紹介するのは「RICE」というフレームワークです。

定量型フレームワークとして非常に有名なRICEですが、実際にはどのような考え方なのでしょうか。詳しく解説していきます。

概要

RICEは、Reach（リーチ数）、Impact（インパクト）、Confidence（確度）、Effort（投下労力）の頭文字をとった言葉です。プロダクトの機能やイニシアチブを4項目で評価して、スコアとして産出します。

4項目の評価基準は以下の通りです。

• Reach：影響を与える人の数
• Impact：ユーザー1人当たりに与えることができる影響度（大規模＝3倍、大規模＝2倍、中規模＝1倍、小規模＝0.5倍、小規模＝0.25倍）
• Confidence：見積もりに対する自信（高＝100％、中＝80％、低＝50％）
• Effort：プロジェクトに必要な労力、人数

これを

（Reach×Impact×Confidence）　÷　Effort　＝　スコア（RICE）

このように割り出すのがRICEです。

プロダクトマネジメントの取っ掛かりとして活用することができます。

メリット

RICEを使用するメリットは、すぐに実行でき、評価項目を相対的に比較できるので、実践的であるという点です。

このフレームワークはプロダクトマネジメント初心者でも着手しやすいと言われています。多大な業務の何から手を付けていいかわからないといった状況のときは、RICEを活用することをおすすめします。

デメリット

RICEを使用するデメリットは、機能同士の相互依存関係を考慮していない点や、戦略ステップやユーザー体験との整合性がない点が挙げられます。データを数値化して考えるうえで、これらは仕方のないことですが、このような要因を考慮してRICEを活用するためには、やはりある程度の経験が必要となります。

初心者の方は何度か見直しを行い、実際の結果とすり合わせるのがベターです。

MoSCoWメソッド

次に紹介するのは、「MoSCoWメソッド」というフレームワークです。

こちらは要件定義の際に用いられるフレームワークで、プロジェクトにおける要件の優先順位を決めることができます。詳しく説明していきます。

概要

MoSCoWメソッドは、Must（対応必須）、Should（対応すべき）、Could（できれば対応）、Won’t（対応不要）の4項目から優先順位を決めていくフレームワークです。

それぞれが要件における重要度を表しています。具体的には

• Must：プロジェクトで必ず対応しなければならない要件、満たされなければ営業活動ができない
• Should：要件が満たされないと影響を受けるユーザーやステークホルダーが多い、あればより良くなるもの
• Could：要件が満たされなくともプロジェクトは進行するが、満たせばより良くなる、Should要件よりも重要度は低い
• Won’t：対応する必要のない要件

このように分類されます。

顧客やユーザーによりプロダクトへさまざまな注文がつけられることで、要件が複雑化し、開発側が混乱してしまうことがあります。そのような事態を避けるために、このMoSCoWメソッドは存在します。プロダクトにおける要件の重要度を明確にすることで、業務の効率化、プロダクトの価値の最大化を図ることができるでしょう。

メリット

MoSCoWメソッドを活用するメリットは、プロジェクトチームの業務効率を高めることができる点と、プロダクトの価値を高めることができる点にあります。

プロダクトにとって必要な要件を精査してから開発に取り組むため、プロジェクトチームとの連携も取りやすく、必要最低限の業務のみでゴールにたどり着くことができます。

また、ユーザーのニーズについてミーティングを行うことで、本当に必要な要件が満たされたプロダクトを実現することができるでしょう。

デメリット

MoSCoWメソッドを活用するデメリットとして、優先順位が同程度の要件しかない場合だと、あまり効果が上げられないというものがあります。ほとんどの要件がMustやSouldの場合は、プロジェクトの進行に影響を与えません。

しかし、MoSCoWメソッドを活用するタイミングによっては、要件の優先順位が変動する場合もあります。そのため、一度行って終了とはせずに、要件を見直すタイミングで、再度MoSCoWメソッドを行うことをおすすめします。

プロダクトマネジメントのフレームワークを活用する際の注意点とは

プロダクトマネジメントのフレームワークを活用する際の注意点について解説していきます。

優先度付のロジックを定期的に見直す

優先順位を決めるフレームワークを活用する際には、そのロジックを定期的に見直しましょう。

優先順位付けは検証を行っていたとしても、リリース後、ユーザーが価値を感じるまでは仮説でしかありません。リリース後のユーザーの反応を確認し、その順位を定期的に見直すことが重要です。

プロダクトの最大価値を引き出し続けるためには、時流を読んでその都度アップデートしていかなければなりません。

フレームワークは一度用いて終了とせず、定期的にそのロジックを見直して活用していきましょう。

状況の変化に応じて優先度も変化する

先ほどお話した通り、フレームワークにおける優先順位は、状況に応じて変化します。

例えば、法律がプロジェクト中に変わった場合、その影響を受ける要件については、優先順位が変動することがあります。

プロダクト開発でフレームワークを活用する場合は、1度使って終わりではなく、販売後も活用し、時流に合わせてアップデートしていくことが大切です。

常にユーザーとビジネスインパクトを念頭に入れる

プロダクトマネージャーの仕事はプロダクト開発・販売の全体指揮を執り、企業利益と顧客満足度を最大化することです。

フレームワークを活用して業務を効率的に進めることも重要ですが、頭を使わずに仕事に取り組んでしまえば、ルーチンワーク化してしまうことも十分にあります。

ユーザーとビジネスインパクトを念頭に置き、プロダクトの価値を最大限引き出すためには何が必要なのかを考えながら取り組むことが大切です。

まとめ

今回はプロダクトマネージャーが知っておきたい5つのフレームワークについて紹介していきました。

フレームワークをうまく活用することで、プロダクトマネージャーの業務は効率化を図ることも可能ですし、当てはめてクリアできる単純業務をスムーズに終わらせることで、複雑な創造業務に時間をしっかりと割くこともできるようになります。

プロダクトマネージャーとしての活躍を目指している方は、ぜひフレームワークを活用してみてください。

今回紹介した情報が参考になれば幸いです。

SNSシェア

• X
• facebook
• hatebu
• LINE
• pocket

CATEGORY

学習

TAGS

PdM フレームワーク