はじめに
プロダクトの開発をしていると、「どの機能から作るべきか」という優先順位付けに明確な基準が欲しくなることがあります。私たちのチームでも、どの機能を開発するかどうか決めるときに「なんとなく重要そうだから」という曖昧な基準で決まることが多々ありました。
そこで今年4月から、ICEスコアという数値化された指標を導入しました。運用開始から半年ほど経過しておりますが、やるやらないの判断がスムーズになり、意思決定の効率が向上したことを実感しています。
導入前の課題
優先順位付けの工数問題と基準の不明瞭さ
従来は、明確な判断基準がないまま主観的な意見で優先度が決まることが多く、優先順位を決めるための工数がかかっていました。参加メンバーも判断に迷うことが多く、決定までに時間を要していました。
トラブル対応に押される業務改善チケット
さらに厄介だったのが、突発的なトラブル対応です。本来であれば業務改善系のチケットを進めたいのですが、「今すぐ直さないと！」という緊急対応が差し込まれ、改善チケットは後回しになることが常態化していました。
結果として、根本的な課題解決に繋がる開発がなかなか進まず、同じようなトラブルが繰り返し発生する悪循環に陥っていました。
開発効果が見えない状況
「この機能を作ったらどれくらいの効果があるのか」を事前に算出できていなかったことも大きな問題でした。開発後に「結局効果があったのだろうか？」と感じることもあり、リソース配分の最適化ができていませんでした。
ICEスコアとは・導入方法
ICEスコアは、各タスクを以下の観点で評価し、その積で優先順位を決める手法です。当社では独自に拡張し、以下の基準で運用しています。
| 項目 | 評価基準 | 詳細 |
|---|---|---|
| I（Impact） | 社内・顧客への影響度 | 売上や業務改善工数の影響 |
| C（Confidence） | 社内・社外からの要望の大きさ | 顧客や社内の業務担当からの要望度 |
| E（Ease） | 開発工数や要件の明確さ | 要件が明確で工数が少ないほど高評価 |
ICEの各項目ごとに2種類の評価基準を設けています（Impactなら社内影響と社外影響）。全部で6項目をそれぞれ評価し、以下の計算式でスコアを算出します。
- ICEスコア = (社内Impact + 社外Impact) ÷ 2 × (社内Confidence + 社外Confidence) ÷ 2 × (開発Ease + 要件Ease) ÷ 2
ユーザー価値×緊急性マトリックスの導入
いくつか既存のタスクや完了済みのタスクをスコア化してみたところ、課題が見つかりました。トラブル対応のための緊急度の高いタスクが、ICEスコア上は低く評価されてしまうのです。
ICEスコアの定義を調整することで解決できないか模索しましたが、最終的には別の評価軸を導入することにしました。それがユーザー価値×緊急性マトリックスです。タスクごとにこのマトリクスのどこに位置するかを評価し、ICEスコアの掛け値として利用することにしました。
例えば通常のタスクを1倍とすると、最適化のタスクは0.3倍という具合にICEスコアの調整をします。これにより、緊急性の高いタスクが優先的に処理されるようになりました。副次的な効果として、タスクの種別が明確になりました。トラブルや火消しのタスクが少ないと、それだけで気持ちが楽になります。
導入後の変化
優先度決定プロセスの効率化
最も大きな変化は、優先度決定のプロセスが効率化されたことです。現在も定期的な確認は継続していますが、ICEスコアという客観的な指標があることで、議論の時間が短縮されました。
スコアに基づいた明確な根拠があるため、迷いなく優先順位を決められるようになりました。
他チームへの説得力のある説明が可能
「なぜこの機能は後回しなのか」を他チームに説明する際も、以前は「ディレクション側の判断で...」といった曖昧な回答しかできませんでした。
現在は「ICEスコアが○○点で、現在対応中の案件（△△点）より低いため」と数値根拠を示せるため、納得感を得られやすくなったと感じます。
課題
運用していて見えてきた課題もあります。
ICEスコア算出にかかる工数
業務改善効果の数値化は定量的な評価が難しく、時間がかかるケースが多いです。特に「Impact」の算出では、売上への影響や業務効率化による工数削減効果を正確に見積もる必要があり、チーム内での議論や調査に時間を要することがあります。
小さめの不具合修正などでも細かくスコア算出していると、ICEスコアを利用するメリットが薄れてしまうため、このあたりはある程度割り切ってざっくりとしたスコアにするなど、効率化を図っています。
スコアの主観性
数値化しているとはいえ、各項目の評価には主観的な判断が含まれます。同じタスクでも評価者によってスコアが変わる可能性があり、チーム内での評価基準の統一が重要になります。定期的な振り返りでスコア精度の向上に努めていますが、完全に客観的な評価は難しいのが現状です。
まとめ
ICEスコア導入の最大のメリットは、主観的な議論を客観的な数値に置き換えられる ことです。完璧な指標ではありませんが、少なくとも「なんとなく」で決めていた状況からは大きく改善されました。
導入コストも低く、スプレッドシートやExcelを使っていればすぐに始められます。開発優先順位に悩んでいるチームには、ぜひ一度試してみることをおすすめします。
ただし、スコア算出自体が目的化しないよう注意が必要です。あくまで開発効率化のためのツールとして、チーム全体で納得感を持って運用することが成功の鍵だと感じています。
アドバンテッジリスクマネジメント(ARM)開発チームのテックブログです。 ARMの開発・運用にまつわる技術的な知見を投稿します。 主な技術スタックは、 Vue / Java / TypeScript / JavaScript / Python / AWS などです。
Discussion