ミツカリ社の開発タスク優先度決定ロジックの歴史と悩み

こんにちは、ミツカリCTOの塚本こと、つかびー(@tsukaby0) です。

今回の記事では当社(主に私)が今まで検討してきたタスクの優先度決定ロジックについて、その歴史や悩みについて紹介したいと思います。

優先順位付けに関して「うちはこうしています、こうすると良いですよ！」といったアドバイスがあれば、ぜひXなどで私まで教えてください！

結論
背景: 無駄なことはしたくない
優先順位付けの重要性
歴史
おわり

結論

RICE、独自スコアリング、WSJFなど様々な手法を試したが、どれも「小さい改善タスクが高スコアになる」問題があった
ICEスコアリングをベースとしつつ、改善と挑戦（実験）のバジェットを50:50で分けることにした
改善スプリントはICEスコア順に実施し、挑戦スプリントは経営戦略・事業戦略ベースで決定する
ROIではなく機会費用の視点で考えることで、「良い時間の使い方か？」ではなく「最良の時間の使い方か？」と問える

背景: 無駄なことはしたくない

おそらくほとんどの人が無駄なことはしたくない、効果があることをしたい、限られた時間で最大の成果を出したい、というようなことを考えると思います。

私もその中の一人であり、時間は有効に使いたいと考えています。できる限り最短でビジネスを伸ばして、顧客への提供価値を高めたいです。

私のプロフェッショナルとしてのソフトウェア開発経験はそろそろ15年になります(アマを含めると20年)。

過去様々なものを開発してきて以下のようなことを考えたことは何度もあります。

「これって作る意味あったのかな？」
「作ったけど全然使われていないし、やる意味なかったな」

全てが無駄だった訳ではないと思いますし、失敗から学べることもあるとは思います。しかし最終的には成功したいわけなので、可能な限り無駄なことはしたくありません。

そこで優先順位付けが大事だということ、また仕事の価値を高めることが大事だという考えに至ります。

優先順位付けの重要性

スタートアップはとにかくやりたいこと、やるべきことが多く、しかしながら使える人員や時間はかなり限られているという厳しい状況に置かれていることが多いと思います。

当社もそうです。

そんな中では本当に価値ある仕事だけに力を割くべきであり、徹底した優先度管理が求められます。この辺りについては同郷出身で私のPdMの先生でもある、Kosuke Moriさんが以下のnoteを書いているので、参考になると思います。

note.com

とにかく優先順位付けが大事であり、優先度の低い、価値の低い仕事にはNoを突き付けるべきです。PdMやプログラマに限りませんが、やらないことを決めるという勇気を持つことが大事です。

歴史

優先順位付けが大事だと力説しましたが、私がそれをうまくやれてきたかと言われると自信はありません。うまくできていたのであれば当社は今よりもっと成長していたはずです。

自信はありませんが、私の悩みや当社の歴史は誰かのためになるかもしれないので、今回恥を承知で公開してみようと思います。

1. 感覚による優先順位付け

私が当社に入社したタイミング(2018年)は井上という前任のCTOがいました。余談ですが、彼は私の友人でもあり、昔はよく一緒にスプラトゥーンをプレイしていました。元Google(US)出身のエンジニアで今でも技術力では敵わない部分が多いなと思っています。

彼はもともとSpreadsheetでタスクを管理しており、大中小のようなラベルで優先度付けを行っていました。これはおそらく感覚だったのかなと思います。彼がCTOでありPdMでもあったし、創業者でもあったので方向性は明確だったのかもしれません。そのため、おそらくは感覚方式でも問題なかったのかもしれませんが、とにかくそういう状況でした。

これが問題だったのかどうかは今でもよくわかりませんが、データの扱いづらさや情報共有のしづらさ、詳細な内容の記述のしづらさ、色々な問題があったので、私の方でWrikeというタスク管理ツールを提案して導入に至りました。

2. タスクの価値による優先順位付け

その次(2019年)は、Wrike上にタスクの価値(タスク完了によって期待できる売上、ARR)を入力するようになりました。例えばECサイトを例にすると、「後で買うためのお気に入り機能追加」というようなタスクに対して「ARR 300万円」というような感じで記入して、それを元に判断する方法です。

この運用は全く徹底されませんでした。規模の大きいタスクだけでもタスクの価値を入れよう、というルールにしましたが、それでも入力されているタスクは20%ほどでした。理由は簡単で、以下のような欠点がありました。

価値を見積もるのがとても難しい
価値は高いが、そもそも本当にその売上分増えるのか？という疑念が付きまとう
価値は高くても、製品のコンセプトや方向性に沿わないなどの戦略との不一致が気になる

こういった問題からこの頃も感覚による優先順位付けがメインになっていました。

3. RICEスコア

優先順位付けに迷った時に調べるとよく出てくるメソッドとして、RICEがあります。

www.atlassian.com

詳細は上記記事に譲りますが、 Reach * Impact * Confidence / Effort で計算します。

一つ前の方法の時に課題になっていた、「本当にその売上分増えるのか？」という問題、つまり成功率という点が Confidence で考慮されています。

さらに Effort によって工数まで加味されています。

詳しくは覚えていませんが、2020年初頭に一瞬だけこれを使っていました。一見万能に見えますが、これでスコアリングしたときにうまくいかないという直感がありました。

これでスコアを付けてみると、小さい改善タスクばかりスコアが高くなってしまいます。そのため、このスコアを信じて開発していると「本当にこのまま小さい改善だけ積み上げていくだけで良いのか？」という疑念が出てきました。結果的にスコアは参考にしながらも感覚で決めるという運用になっていました。

小さい改善タスクばかりが高スコアになるのは計算式的には仕方がありません。例えばECサイトを例にして計算してみようと思います。

タスクA: 購入ボタンの色をグレーからオレンジに変更

項目	値	説明
Reach	10,000	月間訪問ユーザー全員が対象
Impact	1	小さい改善(スケール: 0.25〜3)
Confidence	80%	A/Bテストの知見があり確度が高い
Effort	0.5人日	CSSの変更のみ

RICEスコア = 10,000 × 1 × 0.8 ÷ 0.5 = 16,000

タスクB: お気に入り機能の追加

項目	値	説明
Reach	3,000	月間訪問ユーザーの30%が利用想定
Impact	2	中程度の影響(リピート率向上)
Confidence	50%	類似機能の実績がなく不確実
Effort	30人日	DB設計、API、UI実装が必要

RICEスコア = 3,000 × 2 × 0.5 ÷ 30 = 100

このように計算すると、ボタンの色変更(16,000)がお気に入り機能(100)よりも圧倒的に高いです。

もちろんすぐに終わるのだし、スコア的には高いのだからそれをやるのが正解なのかもしれませんが、スタートアップが作るまだまだ発展途上のソフトウェアがそのような開発スタイルで良いのかは疑問です。

R,I,C,Eのスコアの付け方が良くないという問題もあると思いますが、点数付けを工夫しても限界がありそうな気がしていました。そのため、すぐに次の方法を考えました。

4. 独自の重み付けスコアリング

RICEがしっくり来なかったので、自分で計算式を作ればいいのではという考えから実施しました。

この方法は2020年〜2024年まで使っていました。

具体的な計算式は以下のように設計しました。

開発価値 = ((売上貢献度 * 0.5) + (ユーザビリティ * 0.2) + (人事課題解決力 * 0.2) + (その他の課題解決 * 0.1)) / 工数(人月)

人事課題解決力としているのは、弊社はHR Tech SaaSだからであり、メインターゲットが人事だからです。その他の課題という項目を入れているのは、必ずしも人事向けの開発ではないケースがあるためです（例えば内部のマーケ用の開発など）。

この方法はRICEよりも納得度はありました。そのため、しばらくはこれで運用していましたが、もやもやはしていました。

試しにECサイトを例にして計算してみます。ECサイトだと計算式の一部はこんな感じになるでしょうか。

開発価値 = ((売上貢献度 * 0.5) + (運営効率 * 0.2) + (顧客体験向上 * 0.2) + (その他 * 0.1)) / 工数(人月)

各項目は10点満点で評価します。

タスク	売上貢献度	運営効率	顧客体験向上	その他	工数	開発価値
A: 購入ボタンの色変更	2	0	1	0	0.1人月	12.0
B: お気に入り機能追加	5	0	4	0	1.5人月	2.2
C: 在庫管理の自動化	3	8	2	2	2人月	1.85

結果として、ボタン色変更(12.0) > お気に入り機能(2.2) > 在庫管理自動化(1.85)となり、RICEと同様に小さいタスクが高スコアになってしまいました。

RICEと同じなので、もやもやしながら結局はスコアは参考程度にして、感覚で決めるという運用を続けてしまいました。

5. CoDとWSJF

2024年〜2025年前半はこの方法を使っていました。独自スコアリングの問題点を踏まえて、次に検討したのがCoDです。WSJF（Weighted Shortest Job First）も同時に検討しました。

scaledagileframework.com

WSJFはSAFe（Scaled Agile Framework）由来の優先順位付け手法で、以下の計算式で算出します。

WSJF = Cost of Delay（遅延コスト） ÷ Job Size（作業サイズ）

ここで重要なのが Cost of Delay（CoD、遅延コスト） という考え方です。これは「ある機能のリリースが遅れることで失われるコスト」を意味します。例えば、月額20万円の利益が見込まれる機能のリリースが3ヶ月遅れると、遅延コストは60万円になります。

note.com

CoDは以下の3つの要素から構成されます。

User-Business Value（ユーザー・ビジネス価値） - ユーザーやビジネスへの直接的な価値
Time Criticality（時間的緊急性） - 時間とともに価値が変わるか、今すぐ必要か
Risk Reduction / Opportunity Enablement（リスク削減・機会創出） - 将来のリスク軽減や新しいビジネスチャンスを生む度合い

RICEの Impact が曖昧なのに対し、CoDは「遅らせると何を失うか」という経済的損失の視点で捉えるため、より具体的です。もちろんRICEの Impact を売上やARRで付けるという方法もありではあると思います。しかし、2番目のタスクの価値で触れたように金銭的価値を算出することはとても難しいので、結局同じ問題が発生してしまいます。

CoDの3つの点数を付けるのはそれほど難しくないようには感じました。ただ、RICEと違って不確実性( Confidence )が考慮されない点が少し気になっていました。時間的緊急性も少し気になっていました。私の点数の付け方が悪かったのかもしれませんが、営業やCSの方から聞く顕在化している問題は緊急性が高く、挑戦的、探索的なタスクは緊急性が低くなるなと感じていました。

これも今までと同じような理由でうまくいきませんでした。結局はまたもやもやした状態で、スコアを参考にするが、感覚によって決めるということを行っていました。

ちなみにWSJFも計算できるようにはしていましたが、そちらはあまり参考にしませんでした。どうしても不確実性が低く、簡単なタスクのスコアが高くなってしまいます。RICEの時と同じ問題が発生していました。

6. ICE + バジェットを分ける戦略

2025年後半からはまた方法を変えました。この記事を執筆している現在ではこのやり方を採用しています。まだ運用歴が短いので、また問題が発生するかもしれないため、ぜひ先人の方々はXで私まで教えて下さい！

前述のような悩みを持っていることを先ほどのMoriさんに相談したところ、以下のようなアドバイスを頂けました！

ICEは短期中期の目線での優先順位付けに向いているので、Moonshot と目の前の改善を対等に比較しようとすると、どうしてもEaseによってしまいますよね。それは定義上仕方がないものなのですが、3つほど考え方があるかなと思っています。 (中略) Moonshotと目の前の改善をICEで並列に評価をすることを諦めるというのも意思決定です。その場合はたとえば80:20などの意識/リソース配分を自薦に決めてしまい。改善とMoonshotはそれぞれ別々に優先順位を管理することになります。

目の前のイシューに直接関係ないのですが、Moonshotの優先順位付けにおけるとても良いメンタルモデルだと思ったので共有させてください Optimize for opportunity cost, not ROI: ROl thinking makes you chase low-hanging fruit. Ask "Is this the BEST use of our time?" not "Is this a GOOD use of our time?" High-leverage work means fewer, bigger bets.

これは良い考え方のように思えます。

なぜ機会費用で考えるべきなのでしょうか。

ROI（投資対効果）で考えると「このタスクはリターンがあるか？」という視点になります。すると、確実にリターンが見込める＝低リスク・低リターンのタスクを選びがちになります。

前述の引用では low-hanging fruit という言葉が出てきますが、これは英語の比喩で

〈比喩〉〔大きな努力をしなくても〕簡単に達成できる目標［目的・仕事］、容易に解決できる問題引用: 英辞郎 on the WEB - ALC https://eow.alc.co.jp/search?q=low-hanging%20fruit

という意味のようです。ROIで考えると低い位置にある果実（low-hanging fruit）ばかりを取りに行く状態になってしまうということですね。もしかすると、自分の組織でしきりにROIという言葉が出てくると危ないサインかもしれません。

一方、機会費用で考えると「今この時間を使って他にできる最も価値のあることは何か」という視点になります。「良い時間の使い方か？」ではなく「最良の時間の使い方か？」と問うことで、小さな改善を積み上げる誘惑から抜け出せます。

スタートアップにとって時間とリソースは限られています。その限られた時間で「確実だけど小さな成果」を積み上げるか、「不確実だけど大きな成果」に賭けるか。機会費用の視点は後者を選ぶ勇気を与えてくれる気がします。

当社のようなスタートアップ、それもまだ"これだ"という勝ちパターンが確立していないプロダクトでは正解や大ヒットを目指してひたすら探索すべきですが、探索系のタスクは Confidence が低く、 Effort が高い( Ease が低い)のでどうしても優先順位付けとしては低くなってしまいます。そこで、改善と挑戦をいっそのこと分けて考えてしまうのが良さそうです。

これは現実的にも良くあることのはずです。実際、大きな企業ほど新規事業開発専用の部署やチームを別に作っています。私はそれらの部署の設立背景を聞いたわけではありませんが、既存の仕事がある中ではその延長線上でしか考えられない問題が想像できますし、明確に挑戦するという役割や時間を作らなければなかなか人は挑戦できないと思います。

これについては例えば以下のような記事もあります。

www.layers.co.jp

両利きの経営という単語は稀に聞きますし、探索と深化を同時にやるというのは確かに重要に思えます。

お気に入りの飲食店に行き続けるか、新たに探すかの割合、みたいな問題も近い話ですね。学生の時以来触れていないですが、Multi-Armed Banditなども思い出します。

また、以下のようなイノベーション戦略の70:20:10の法則というような話もあります。

dhbr.diamond.jp

これらの記事を見るに、私の今までの直感やもやもやは悪いものではなかったように思えます。もし盲目にRICE等で優先順位付けした高スコアのタスクだけを信じて実施していたら、安定しているが少ない成長を続ける組織になっていたと思います。ある程度は感覚で挑戦的なタスクに時間をかけてきたことは無駄ではないように思います。

ただ、今までのやり方で問題なかったのでいいや、という考えになってしまうと何も変わらないような気がします。ある程度感覚で挑戦的なタスクを入れてきたつもりですが、今までの当社は安定側に寄せすぎていました。

よって80:20などではなく、ここは大胆に50:50のやり方を取ることにしました。理由は以下の通りです。

当社はまだ"これだ"という勝ちパターンが確立していないし、今までの状況を鑑みて、もっと挑戦、実験的なタスクを多くやって良い。近年は無難にまとまりすぎた
スプリントを2週間に設定しているので、改善と挑戦を交互にやりやすい。挑戦のスプリントが終わった後で改善のスプリントをやっている最中に挑戦のスプリントの計測・インタビューをやることで次の挑戦および準備をテンポ良くできる
- 80:20にして、挑戦スプリントは2ヶ月に1回、それが終わったら次の2ヶ月後まで計測、準備ということもできるとは思うが、それだとイノベーションと改善の速度が遅すぎる

50:50の内訳ですが、以下の通りです。

改善スプリントはICEスコアによってスコアが高いものから順に実施します。確実な改善を積み重ねます。
挑戦スプリントはICEスコアには従わず、経営戦略、事業戦略、Impactなどを総合的に検討・議論し、何から挑戦、実験するか決めます。

今のところ、この考え方や運用は満足しているのですが、次はその50%でどんな挑戦をするかについて迷っています。

例えばHR領域の中の別領域の新製品を作るというようなことはMoonshotを狙う挑戦だと思いますが、それよりも広く考えてバックオフィス、例えば経理領域に挑戦しよう、というようなことはさらに大きい挑戦だと思います。

どういった領域(Where)を攻めるかは経営レイヤー、BizDevレイヤーの話なので、今回したようなPdMレイヤーの優先順位の話と混ぜないほうが良いでしょうが。今後どういった挑戦をすべきなのかは考えていきたいです。今ある企画だけではなく、常に探索するマインドを持ちたいです。これは機会費用を意識したものです。

ちなみにRICEではなくICEにした理由は運用コストを下げるためであり、RICEを考えていた頃の経験からはReachは不要かなと思っただけなので、深くは考えきれてはいません。50:50は良いとしてもICE以外の手法を検討する余地はまだあるかもしれません。