開発アイテムの優先順位を付けるための補助線 

本記事は[Skillnote Advent Calendar 2024](https://qiita.com/advent-calendar/2024/skillnote)、12/11のポストです。 

株式会社Skillnoteでプロダクトマネージャー(PdM)をしている今井です。 

我々Skillnoteではスクラムの考え方を元に開発を行っていますが、その際に必要となるのがプロダクトバックログの管理です。私のようなプロダクトオーナーがプロダクトバックログアイテム（以下アイテム）の優先順位付けへの責任を持っています。 

しかし、**アイテムが生む価値の種類・方向性が違いすぎてリンゴとリンゴの比較というよりリンゴとオレンジの比較になってしまい、優先順位付けに確信が持てないよ**、ということは多いと思います。 

今回は、優先順位付けをスムーズに行う補助線として、私が使っている**アイテムの分類とそれを踏まえた留意事項**をお伝えできればと思います。 

:::note info
本稿の内容はシングルプロダクト、B to Bプロダクトである現在のSkillnoteを前提としています。対象のプロダクトや状況によって視点も変わると思いますので、その点ご理解頂けると幸いです。 
:::

 
# アイテムの三分類 

優先順位付けの補助線として、私はアイテムを三つに分類して整理することが多いです。 

一つ目は当たり前品質を達成するためのアイテム、二つ目がプロダクトの魅力を形作るアイテム、三つ目がプロダクトの対象市場を広げるアイテムです。ここでは便宜的に **「当たり前アイテム」「魅力アイテム」「拡張アイテム」** と呼びましょう。社内的にはこれらをL1, L2, L3のような形でタグ付けしています。 
 
## 当たり前アイテム (L1) 
**当たり前アイテム**とは、**お客様が我々のようなプロダクトを使うにあたり当然のものとして期待する機能・非機能のアイテム群**です。これらにはセキュリティ対応系の項目やパフォーマンス改善系の項目などが含まれますが、それと合わせて「一般的な類似サービスでできること」についても含まれます。 
 
当たり前、という言葉を引いていますのでお気づきかもしれませんが、この分類は **「狩野モデル」** の **「当たり前品質」** に対応しています。当アイテム群については「充足しても当然だが不充足だと不満を引き起こす」という「当たり前品質」の特徴を持つのです。 
 
 ![狩野モデルにおける「当たり前品質」と「魅力的品質」（狩野他 (1984)をもとに筆者作成）](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3949954/735bdbe5-b6d6-37e1-8b8c-3eaf864cec9f.png) *狩野モデルにおける「当たり前品質」と「魅力的品質」（狩野他 (1984)をもとに筆者作成）*
 
## 魅力的アイテム(L2) 
**魅力的アイテム**とは、**お客様がプロダクトを購買いただくにあたり差別化要因として働くアイテム群**です。マーケティング活動の中で我々のプロダクト上の強みとして中心的に訴える内容となりますし、現在契約中のお客様にバージョンアップとして提供した場合、非常に喜んでいただける花形アイテムといえるでしょう。 
 
こちらは狩野モデルでいう **「魅力的品質」** の特徴を持つものです。充足していれば満足を生むが、不充足であっても不満にはならないものです。一方、このようなアイテムは常に陳腐化と隣り合わせであることを留意する必要がありそうです。 
 
**プロダクトレベルでビジョンを策定している場合、ビジョンを達成するための構成要素となる機能群**と言えるでしょう。プロダクト指標をこのビジョンをベースに設定している場合、魅力的アイテムこそ指標の改善に中心的に貢献するはずであり、アイテムの優先度もプロダクト指標と開発工数見積をベースに判断すると良さそうです。 
 
 
## 拡張アイテム (L3) 
**拡張アイテム**は**対象マーケットを広げる項目群もしくはプロダクトに別の価値を与える項目群**です。これまでの対象セグメントとは異なる業種・職種・規模のお客様にプロダクトを提供するために必要と考えられる機能およびそのパッケージング、既存の対象セグメントに別の価値を感じていただきさらに貢献するためのオプション機能などが対象となります。**事業拡大の要請に答えるためにアップセル・クロスセルを促進するためのアイテム群**ともいえるでしょう。 
 
これらのアイテムは（広義の）マーケティング戦略と大きく結びつくものであり、アイテムの技術的内容だけでなく、**少なくとも価格、売り方、プロモーションなど「マーケティングの4P」レベルの検討も平行して必要**そうです。これらのアイテムは新しいチャレンジであり、アイテムによっては技術面もしくはビジネス面でのリスクや不確実性にも目配せする必要もあると考えられます。拡張アイテム内の優先度は事業性と不確実性を含めた判断になるでしょう。 
 
なお、拡張アイテムという分類は我々が現状シングルプロダクトであることを前提としています。**拡張アイテムを目的ごとにグルーピングしていくと、その中で魅力的アイテムの性質を持つものと当たり前アイテムの性質を持つものの2種類がある**ことが分かります。もっとも、複数のプロダクトが立ち上がればこの分類は不要になるかもしれません。あるグループ内の優先度付けの方法はプロダクト初期の優先度の付け方に近く、これについては次項で触れたいと思います。 
 


# 優先順位を考えるための論点 
前項でアイテムの三分類について書きましたが、各分類を一緒くたにして優先順位を付けることは現実的ではありません。実際には下記のような論点を踏まえる必要があると考えています。 
 
## 1. プロダクト初期は魅力的アイテム中心 
**若いプロダクトでは魅力的アイテムこそが購買理由になることが多い**です。初期段階の顧客ターゲットはキャズム理論で言う「アーリーアダプター」ですので、「ビジョン先行」で購買いただけることになります。そのためビジョンを実現する機能群である魅力的アイテムが重要であり、当たり前アイテムは「待って」頂けるのです。 
 
この考え方はプロダクトのMVP (Minimum Viable Product)と繋がっています。プロダクト初期で必ず通るであろうMVPの構成要素はそのプロダクト内での「魅力的アイテム」を非常に多く含みますが、**MVPは定義通り「アーリーアダプターのためのもの」であり、キャズムを超えるためには不足がある**ことも留意しなければなりません。 
 
 
## 2. キャズムを超えるには当たり前アイテムが最重要になる 
プロダクトを購買していただいたものの、実際に活用いただくためには魅力的アイテムだけでは不十分なことが多いです。**お客様のワークフローを完遂するためには、魅力的アイテムだけでなくその間をつなぐ使い勝手やセキュリティ、パフォーマンスなど当たり前アイテムが必要**になります。 
 
そのため、当たり前アイテムがどこかのタイミングで最重要課題となるのです。**キャズムを超えて多くのお客様に購買頂くためには現実的な価値の提供が必要**になりますが、ユーザーフローを回せない以上その実現は魅力的アイテムだけでは難しいでしょう。また、アーリーアダプターのお客様についても実際の業務が進まない以上、そこから先のビジネスの発展は難しいかもしれません。我々のようにMVPを達成したプロダクトの次なる道は、なめらかなユーザー体験の実現になります。 
 
特に我々のお客様である製造業の皆さまにとって（狭義の）品質は非常に重要な価値軸です。品質事故の怖さについてここで語るまでもないですが、お客様のワークフローの一翼を担う以上、お客様の最終製品における品質の責任も負っていることになるのです。品質とは鎖であり、その強さは一番弱い所の強度に依存するというたとえ話もありますが、まさに**我々がお客様の品質におけるボトルネックにならないよう、プロダクトの品質を高めていく必要がある**と思っています。 
 
また、当たり前アイテムの範囲はかなり広く、年々広がっています。「魅力的アイテム」として世に出たアイテムも時を経ることで次々と「当たり前アイテム」へと陳腐化しているのです。だからこそ、**大きいトレンドのキャッチアップや競合同質化のような観点も優先順位付けを日々見直す中で必要**になります。 
 
 
## 3. 70:20:10ルールとバックログの分離 
70%をコアビジネス、20%を成長プロジェクト、10％を新規プロジェクトに割り当てるGoogle社の70:20:10ルールは有名ですが、我々もこのようにリソース配分を割合で決めてロックする方針で進めています。 
 
当たり前アイテムが最重要と書きましたが、これに従っているといつまで経っても当たり前アイテムばかり取り組んでいる、ということになりかねません。特に拡張アイテムはプロダクトにとっての新たなチャレンジになることも多いですから、重要度高・緊急度低・難易度高のアイテムの常として、ずっと放置という可能性もあります。 
 
そのような事態への対策として、**特に拡張アイテムについては一定のリソースを張ることを約束しておくべき**です。70:20:10ルールで言うと20と10が拡張アイテムの領分ですので、開発リソースの2割程度を堅い拡張アイテム、1割を研究開発的要素を含むアイテムに充てることになります。これを運用していくために、拡張アイテム系はバックログとしても別のものとして切り出して考えています。 
 
# おわりに 

今回は開発アイテムの優先順位を付ける際に意識していることをざっと書いてみました。 

私の書いた内容はあくまで補助線であり、一つの見方に過ぎないかもしれませんが、プロダクトバックログ管理を行っている皆さまの何かしらの参考になれば嬉しいです！ 

 引き続きSkillnote Advent Calendar2024をお楽しみください！