見出し画像

開発するISSUEの優先順位付け手法3つ│今週読んだ英語記事 Vol.18

miya🍊PjM・PdM


この記事の目的：

今回も引き続き、プロダクトの優先順位付けに関する記事を読んでいきます。

「今週読んだ英語記事 」マガジンの記事は、私の英語力向上を第一の目的にしています。続けることに重きをおいているので、文章の雑さなど何卒ご容赦ください🙇

HIPE：施策を評価する4つの観点（6/23）

仮説・投資（工数）・先例・ユーザー体験の4軸で施策を評価する

この記事は、施策を評価する軸として「H」「I」「P」「E」を頭文字とする4つの観点を紹介しています。

  • H：Hypotesis　仮説

    • その仮説（施策案）が、どれほどの人にインパクトを与えるのか、という点が特に重要です。

  • I：Investment　投資

    • その施策案にどれくらいの工数がかかり、リターンとしてどれくらい、KPIを動かせるのかという観点です。

  • P：Precedent　先例

    • 過去に自社や業界で成功した例を知っているほど、筋の良い仮説を立てられます。

  • E：Experience　ユーザー体験

    • 改善施策を考えていると、North Star Metricの向上に注意が向いてしまいがちです。ですが全体の体験を損なうような施策は好ましくないので、全体的なユーザー体験を再考するのが重要です。

どの観点も、施策を考えておく上では外せないですね。特に先例は、自分が知っているものをすべて、今取り組んでいるプロジェクトで活かせるわけではないので、普段から意識してたくさん収集しておいて、引き出しを増やしておけるといいよね、と思います。

MoSCoW分析（6/25)

PMP試験（PMBOK）にも登場する分析手法

最近PMP試験に向けて勉強していて、MoSCoW手法はその中でも登場していました。なので(?)日本語でも解説記事があるようです。

↑の記事中に登場する「BABOK」は、プロジェクトマネジメントの上流工程であるビジネスアナリシス版のPMBOKのようなものです。有期性のプロジェクトの中でMoSCoW分析は要求定義で使われるので、PMBOKとBABOKの両方で紹介されれるんでしょうね。

MoSCoW分析の概要

MoSCoW分析はいたってシンプルな観点で、以下の4段階に分類されます。

  • Must：交渉するまでもなく必要とされるプロダクトニーズ。

  • Should：無いとプロダクトが成り立たないわけではないが、重要な価値を担うもの。

  • Could：あるといいけどインパクトは小さいもの

  • Will not have ：今なくてもよいもの

例えばユーザーストーリーを分類するとして、この4つに分けること自体はそんなに難しく無いと思いますが、MoSCoW分析をうまく機能させるためには4つのポイントがあります。

  • 具体的なランク付けのシステムを用いる
    →何がCould，Will not haveなのかなどは特に主観によって違いが生じてしまうので、できるだけ誰が分類しても同じになるようなランク付けの方法を確立する。

  • 主要なステークホルダーに、順位付けに参加してもらうこと
    →重要な観点を見落としてしまうと優先順位付けに意味がなくなってしまうので、多くの観点を取り入れる。

  • 作成した優先順位を、組織内に公表する
    →組織内に広く公表しておくことで、後からステークホルダーに口を出されること（文句だけ言われること）を防ぐ。

特に、具体的なランク付け方法について事前に合意を取っておくことは重要ですね。プロダクトバックログを作るときに、優先度が必須でないものがふんわりしがちなので（急ぎで無いことが多いので深刻に困るかというとそうでもないですが）、決め方を決めておくのは良い手だなと思いました。

TribeRank：ワークショップ形式でわいわい順位付け（6/27）

TribeRankとは

「TribeRank」は、ワークショップ形式で開発の優先順位をつけていくフレームワークです。みんなでホワイトボードを囲みながら優先順位をつけていくのが特徴です。
TribeRankの手順は次のとおりです。

  1. アイデアを5分間でブレストする（個人作業）

  2. 考えたアイデアを、ホワイトボードに貼り付けていく

    1. 1人1つずつ、順番に貼っていきます

    2. 他の人と被ったカードは捨てます

    3. 似ているカード同士はグルーピングします

  3. アイデアを重要度順に、横一列に並べる

  4. 開発が簡単なアイデアは上に、難しいものは下にずらして縦軸を作る

  5. 開発するアイデアの基準線を引く（下の図のイメージ）

チームビルディングにも使えそう

TirbeRankは「重要度」と「簡単さ」を主観的に判断するだけのシンプルな順位付けで、数学的な重み付けをするわけでもないので、順位付けの難易度としては簡単なものだと思います。
このフレームワークの特徴として、みんなでわいわいやるワークショップ的な進め方に重きが置かれているので、参考にするとチームビルディングの一環にもなりそうです。特に、新しいチームでプロダクトを開発していく初期段階なんかではそれぞれの考え方を知るきっかけや、自分の意見が反映されているという自己効力感の醸成にも使えそうですね。

今回の記事はここまでです！読んでいただきありがとうございました。
来週も引き続き、プロダクトマネジメントに関するフレームワークを紹介していこうと思います。
いいね、フォローなどいつもありがとうございます！

この記事が気に入ったらサポートをしてみませんか？