成功した機能1つのコストを下げるには、まず「何を成功と呼ぶか」を決めろ

Hatched by tttt

May 30, 2026

1 min read

3 views

86%

そのチームは本当に速いのか、それとも失敗を数えていないだけか

多くのプロダクトチームは、自分たちは速くなったと信じています。スプリントごとのベロシティは上がり、リリース回数も増え、デプロイも自動化されました。けれども、ある日ふと考えるべき問いが出てきます。その中で、本当に成功した機能は何個あったのか。

ここに、見落とされがちな真実があります。私たちはしばしば「たくさん作った」ことを「多くの価値を出した」ことと混同します。しかし、製品開発の本当の単位は、機能数でもリリース回数でもありません。成功した機能1つあたりの実効コストです。これを見失うと、チームは忙しくなるほど成果から遠ざかるという、奇妙な逆転が起こります。

この視点は、単なる会計の話ではありません。むしろ、プロダクト開発を回帰の問題として見るか、クラスタリングの問題として見るかという、思考の深い分岐点に関わっています。何を予測したいのか。そもそも何を成功と定義するのか。その問いを曖昧にしたまま、効率化だけを追うと、数字は良く見えても意思決定は悪化します。

速さとは、単に早く動くことではない。望ましい結果を、予測可能な形で、低コストに再現できることだ。

開発の本質は「作ること」ではなく「当てること」

プロダクトチームが直面する最大の誤解は、ソフトウェア開発を製造業のように扱ってしまうことです。作業量が増えれば価値も増える、という直線的な発想です。けれども、製品開発の現実はもっと厄介です。機能は作れば終わりではなく、ユーザーに届いて、期待に応え、行動を変え、継続的な価値を生まなければ意味がありません。

ここで重要になるのが、成功密度という考え方です。単に出した機能の数ではなく、その中にどれだけ成功が含まれていたか。10個出して1個当たるチームと、3個出して2個当たるチームでは、見た目の活動量は前者が上でも、実効コストでは後者が圧倒的に優れています。つまり、問うべきは「何個作ったか」ではなく、1つの成功を得るためにいくら払ったかです。

この発想は、機械学習でいう回帰と驚くほど似ています。回帰は、目的変数が分かっているときに使います。家の広さから価格を予測したいなら、価格というターゲットが明確です。何を当てたいのかが定まっているから、入力条件と結果の関係を学べます。

一方で、何を求めるべきか自体が曖昧な場合には、回帰ではなくクラスタリングのような考え方が必要になります。ユーザーをA、B、Cに分けたいのに、そもそも「成功したユーザー体験とは何か」が定義されていないなら、モデル以前に問いが壊れています。プロダクト開発でも同じです。成功が定義されていない状態で最適化を始めると、最適化対象そのものが滑っていくのです。

たとえば、あるチームが「新機能を毎週出す」ことをKPIにしたとします。見た目は素晴らしい。しかし、もしその半分が使われず、残りも軽微な満足しか生まないなら、彼らは高速に失敗を量産しているだけです。ここで必要なのは、リリース数の監視ではなく、成功という目的変数の定義です。

コストの式は、実は意思決定の地図である

成功した機能1つあたりのコストを考えるとき、多くの人は人件費だけを見ます。けれども、実効コストはもっと複雑です。チームコストに加えて、ツール、管理、調整、やり直し、失敗の廃棄コストが乗ってきます。さらに、チームがどれだけ機能を作れるかという効率もあれば、その中でどれだけが成功するかという成功率もある。そして最後に、成功したものが全体に占める意味の大きさ、つまり成功密度が効いてきます。

この構造を簡単に言い換えると、**「高いコストを払っても、成功の比率と濃度が高ければ、実効コストは下がる」**ということです。逆に、手元の数値が立派でも、失敗が多く、成功が薄く散らばっていれば、1つの当たりを得るための支払いは膨らみます。

ここで大事なのは、この式が単なる結果の記録ではなく、改善のレーダーだという点です。どこで無駄が生まれているのかを分解して見られるからです。

チームコストが高すぎるのか。
1スプリントあたりの機能産出が低いのか。
失敗率が高いのか。
成功しても、それが薄い価値しか持っていないのか。

この4つは似て見えて、対策がまったく違います。たとえば失敗率が高い場合は、QAを厚くするより、そもそもの探索を改善したほうが効くかもしれません。成功密度が低い場合は、機能の粒度が小さすぎるか、価値のある問題に十分踏み込めていないのかもしれません。機能数を増やしても、成功密度が低ければ意味は薄いのです。

効率化の罠とは、出力を増やすことに集中しすぎて、成功の定義を小さくしてしまうことだ。

たとえばレストランを想像してください。皿の数を増やすことは簡単です。前菜、スープ、メイン、デザートを毎週新しく出せば、メニューは豪華に見えます。しかし顧客が求めているのが「また来たいと思う体験」なら、皿数の増加は本質ではありません。むしろ、看板メニューが1つ強くなったほうが、全体の利益は伸びることが多い。プロダクトも同じで、成功した機能の密度が高いチームほど、少ない投資で大きな学習を得るのです。

失敗率を下げるだけでは足りない。成功の意味を濃くしろ

多くの改善活動は、失敗率を下げることに集中します。もちろん重要です。バグを減らし、手戻りを減らし、不要な開発を減らすことは大切です。しかし、ここにはもう一段深い論点があります。失敗率が下がっても、成功の価値が薄ければ、実効コストは期待ほど下がらないのです。

なぜなら、プロダクトで本当に難しいのは「動くものを作ること」ではなく、「ユーザーにとって意味のある変化を起こすこと」だからです。UIの洗練、APIの安定、デプロイ頻度の向上はどれも素晴らしい。しかし、それらは成功の必要条件であって十分条件ではありません。

ここで役立つのが、成功を3層で考える枠組みです。

機能成功: 仕様どおりに動くか。
利用成功: 実際に使われるか。
価値成功: 行動変容や成果につながるか。

多くのチームは1層目で満足し、2層目で安心し、3層目に到達する前に次の機能へ進みます。しかし、成功密度を本気で上げたいなら、3層目を測定可能な形に引き上げなければいけません。たとえば、登録機能を出しただけでは成功ではありません。登録後の定着率、紹介率、購入率まで見て初めて、成功の中身が見えてきます。

この視点は、回帰の話と深くつながります。回帰モデルは、目的変数が明確でなければ意味がありません。同様に、プロダクト開発でも「成功」のターゲットが曖昧だと、開発の最適化は空回りします。だから最初に必要なのは、機能を増やすことではなく、何を予測し、何を再現し、何を成功と呼ぶかを明文化することです。

たとえば、あるB2B SaaSのチームが「ダッシュボード機能」を作るとします。機能成功だけを見れば、グラフは表示されるし、フィルタも効くし、完成です。しかし利用成功はどうでしょうか。営業担当が毎週開いているか。会議で意思決定に使われているか。価値成功はどうでしょうか。商談化率や更新率に改善があるか。ここまで見て初めて、その機能は意味を持ちます。

組織が持つべきものは、速さではなく「成功の回路」である

本当に成熟したチームは、速いチームではありません。成功を再現可能にするチームです。これは小さな違いに見えて、実際には決定的です。

速さだけを追う組織では、たまたま当たった機能が英雄視されます。すると、偶然の成功が再現可能な能力のように誤認されます。逆に、成功の回路を持つ組織では、仮説、検証、学習、絞り込みが自然に循環します。どの入力がどの結果に効いたのかが見えるので、改善が戦術ではなく構造になります。

このとき、クラスタリングの発想が効いてきます。ユーザーや機能を似たもの同士に分けて見ると、何が効いたのかが見えやすくなります。たとえば「新規ユーザー向け」「既存ヘビーユーザー向け」「一度離脱しかけたユーザー向け」で成功条件は違います。全部を一つの成功指標で測ると、どの層にも刺さらない平均的な機能ばかりが増えます。クラスタごとに成功条件を見極めれば、成功密度は上がります。

つまり、回帰は予測の精度を高めるための道具であり、クラスタリングは成功条件の違いを見つけるための道具です。プロダクトに必要なのは、この両方です。何が結果を生むのかを予測しつつ、そもそも誰にとっての結果なのかを分ける。ここに、開発の成熟があります。

最高のチームは、たくさん作るチームではない。成功の条件を見つけ、その条件を狙って再現できるチームだ。

この視点に立つと、製品パイプラインの式は単なる計算ではなく、組織の鏡になります。チームコスト、効率、失敗率、成功密度。これらは数式の変数であると同時に、文化の変数でもあります。曖昧な成功、雑な検証、広すぎるターゲット、薄い価値提案。そうしたものは、必ず実効コストに跳ね返ります。

Key Takeaways

リリース数ではなく、成功した機能1つあたりのコストを見る。 速く出すことと、価値を出すことは別です。両者を混同すると、忙しさが成果に見えてしまいます。
成功を目的変数として定義する。 何を予測したいのか、何を達成したいのかが曖昧なままでは、改善は空転します。回帰の前に、ターゲットを決める必要があります。
失敗率だけでなく、成功密度を測る。 1つひとつの成功がどれだけ意味のある変化を生むかを見ないと、数値上の改善に騙されます。
機能成功、利用成功、価値成功を分けて考える。 動くことは出発点にすぎません。使われ、成果につながって初めて成功です。
ユーザーをクラスタで分けて、成功条件の違いを見つける。 全員に同じ成功指標を当てると、平均的で弱いプロダクトになります。