ソフトウェア開発費の見積り、プロジェクトマネジメント、
発注者と受注者の間の合意形成等に参考となる情報を不定期に掲載していきます。
不確実性と向き合う見積り 第5回
「どれくらいかかるか」から「それだけの価値があるか」へ
2026.09.17
著者:
Scrum Inc. Japan 山本 尊人
限られた予算と時間の中で、何から作るべきでしょうか。
仕事の大きさを見積もることができても、それだけでは何を優先するかは決まりません。できそうなものをすべて作ることもできません。
そこで、どれくらいかかりそうかと、それによって何が得られるのかを一緒に考えます。見積りは、仕事の大きさを捉えるだけではなく、何に投資するかを選ぶための材料にもなります。
■コストだけでは、優先順位は決められない
たとえば、同じ8ポイントと見積もられた二つの機能があったとしても、それらを同じように扱う理由はありません。一方は多くの利用者が抱える問題を解決するかもしれませんし、もう一方は限られた場面でしか使われないかもしれません。
つまり、どれくらいかかるのかだけを見ても、優先順位は決められません。それによって何が得られるのかと組み合わせて考える必要があります。
■価値とコストを組み合わせて考える
ここで役立つのがROI(Return on Investment:投資対効果)の視点です。ROIは、投資に対してどれだけの効果が得られるかを見る指標です。ここでは厳密な財務指標としてではなく、期待する価値と必要なコストを組み合わせて、どこに投資するかを考えるために使います。
第3回で紹介した四半期計画では、その考え方を簡易的に取り入れ、一部の仕事について期待するBusiness Value(BV)もポイントで表しました。そして、BVをStory Point(SP)で割った値をROIと呼び、投資効率を比較する目安として使いました。
たとえば、BVが5、SPが3の仕事と、BVが9、SPが8の仕事がありました。ROIはそれぞれ約1.7、約1.1です。期待する価値だけを見れば後者が大きいのですが、投資効率で見ると前者が上回ります。
ここでいう得られるもの、すなわち価値は、必ずしも売上や利益だけではありません。利用者の利便性向上、業務時間の削減、リスクの低減、将来の選択肢を広げること、あるいは新しい仮説について学ぶことにも価値があります。

【図:価値とコストを組み合わせた優先順位付け】
候補となる仕事を、期待する価値と必要となるコストの二つの観点から捉えてみます。価値が高くコストが小さいものは、投資先として有力な候補になります。一方、価値が高くてもコストが非常に大きければ、もっと小さく実現できないか、まず一部だけ試せないか、といった問いが生まれます。
同じ価値が期待できるなら、より小さなコストで実現できるものの方が投資効率は高くなります。逆に、大きな価値が期待できても、そのために非常に大きなコストが必要なら、本当にその投資を行うべきかを考える必要があります。こうして価値とコストを並べてみることで、どこに投資するかを比較しやすくなります。ただし、ここで置いた価値やコストも、最初から確定したものではありません。
■価値も、最初から分かっているとは限らない
ここで注意したいのは、コストだけでなく、価値にも不確実性があるということです。この機能は顧客に喜ばれるはずだ、これを作れば業務時間を半分にできる、と考えていても、実際に提供してみなければ分からないことは多くあります。
価値についても最初の予測を正解として扱いません。価値もコストも、その時点での見通しにすぎません。小さく作って反応を見る、利用状況を観察する、顧客に確認するなどして、期待していた価値が本当に得られているのかを確かめます。
だからこそ、価値の高いものから順に届けます。すべてが完成するのを待ってから一度に提供するのではなく、優先順位の高いものを先にリリースすれば、その分だけ早く価値が生まれ、同時に、期待していた価値が本当に得られたのかを検証できます。
開発を進めて実績が増えれば、どれくらいかかるかという予測を更新できます。同じように、実際に作り、使ってもらい、結果を観察することで、どれくらいの価値が得られるのかについても分かることが増えていきます。
そして、新しく得られた情報をもとに、コストと価値の見通しを更新し、投資先を見直していきます。
■限られた投資の中で、何を選択するか
予算や期間に投資の枠を置き、その中でスコープに選択の余地を残す。その選択を支えるのが、ここまで見てきたコストと価値です。
限られた予算と時間の中で重要なのは、最初に決めたものをすべて作ることではありません。どれくらいかかりそうかと、どのような価値が期待できるかを照らし合わせ、どこに投資し、何から届けるのかを選択することです。
見積りは、単にどれくらいかかりそうかを考えるためのものではありません。期待する価値と照らし合わせ、限られた投資をどこに使うのかを考えるための材料でもあります。
では、開発が始まった後、こうした判断をどのように続けていけばよいのでしょうか。
次回は、進捗や残りの仕事を可視化しながら、開発の途中で見通しと判断を更新していく方法を取り上げます。
※このコラムは全6回を予定しています。
大手SIerにおけるシステム開発の経験を経て、現在はScrum Inc. Japanで、企業や組織のアジャイル開発・組織変革を支援。スクラムの導入・実践、プロダクト開発、組織づくりに関するコーチングや研修、人材育成に携わる。企業支援と大学教育の双方を通じて、複雑で変化の大きい環境におけるプロダクト開発とマネジメントのあり方を伝えている。関西学院大学、山梨大学非常勤講師。