導入の背景

自社開発のベンチャー/スタートアップでは日々開発したいものが無限にありますよね。少人数チームでは、無駄な開発をしている時間はありません。
時間をかけてかけて開発したものが実はユーザーに全く使われずコードを削除せざるを得ないなんてことがあればメンバーのモチベーション低下にもつながってしまいます。
そんな事態をなるべく避けるために、弊社ではICEスコアリングによる優先順位づけをしております。

ICEスコアリングとは

ICEスコアリングモデルは、プロダクトマネジメントにおいてタスクの優先順位を決定する際のフレームワークの1つです。特に初期段階の開発で、アイデアが流れ、チームの勢いを保つことが求められる場合に適していいるといわれています。少人数のPdMや兼任PdMの場合に適しているのではないでしょうか。

ICEはImpact（インパクト）、Confidence（信頼性）、Ease（容易さ）の頭文字をとっています。各アイデアやプロジェクトは、これら3つの要素に基づいて評価されます。

Impact（インパクト）: そのアイデアやプロジェクトが成功した場合、それが製品やビジネスに与える影響の大きさを評価します。

Confidence（信頼性）: アイデアやプロジェクトが成功する確率についての自信を評価します。これは、該当のアイデアやプロジェクトに対するデータや理解の深さによって変わります。

Ease（容易さ）: アイデアやプロジェクトを実装するための時間、コスト、労力を評価します。

これら3つの要素は数値化され、それぞれのアイデアやプロジェクトに対してICEスコアが計算されます。このスコアが高いほど、そのアイデアやプロジェクトの優先度が高くなると考えられます。

チームごとにImpactやEaseの定義をはじめに決めることが重要です。

ICEの準備

ICEスコアリングそれぞれの定義

弊社のエンジニアチームでは、Impact、Cofidence、Easeの定義を以下のように定めました。

Impact

Confidence

Ease

このため、優先順位付けのミーティングには、Ease決定のためのテックリード、Impact / Cofidence 相談のためにビジネスサイドのメンバーが参加しています。

必要なボードについての定義

弊社では、開発のためのICEスコアリングボードを2つ作成しています。

理想ボード
kaizenボード

理想ボードは会社目標のために必要な、理想のプロダクトのための機能が書かれています。
kaizenボードは会社のメンバーであれば、誰でも記入することができ、各職種が思ったことやユーザーからの要望が記入されています。

そのためkaizenボードは量が膨大になってしまうため、弊社では2ヶ月更新がなければkaizen要望から消すという方針を取ることで、数が増えすぎないようにするというバランスをとっています。

ボードはNotionで以下のように管理しています

ICEスコアリングミーティング

ICEそれぞれの定義付けができたら、スコアリングミーティングを実施します。
弊社では、

PdM
テックリード
ビジネスサイドメンバー
の3名は最低参加するようにしています。

理想の機能についてはクオーターに1度優先順位付けミーティングを行い、kaizenタスクについては、月に1度ミーティングをしています。

結論

ICEスコアリングはすごくシンプルにタスクの優先順位付けをすることができると思います。少人数でスピード感を持って開発を進めたいチームにはおすすめしたいと思います。

デメリットは個人的には2つあります。
1つ目は、ビジネスサイドに意見が優先されてしまうということです。ImpactやEaseは、ビジネスサイドの状況にかなり左右されてしまうため、開発チームとして必要なことが後回しにされがちということがあります。PdMがうまくバランスをとって、開発チームとして必要なタスクをビジネスサイドに共有していく必要があります。

2つ目は、スコアリングがかなり主観的ということです。ここもPdMのバランス感覚が問われるところですね。

今後チーム編成が変わるにつれて、必要な手法は変わってくるとは思うのですがフェーズに合わせた手法を用いて優先順位付けをおこなっていきたいですね〜

参考文献