かつて受託開発の SI をやっていた頃、「ユーザー」は特定少数でした。その後、パッケージ製品ベンダーに移ってみると、「ユーザー」は特定多数でした。そして、販売前の製品の開発をやっている現在、「ユーザー」は不特定未知数だったりします。

でもいつでも、「ユーザー」に満足して貰いたいと思ってきたわけです。
実装する機能セット(コード量)と開発コストの関係は、ざっくり考えれば、直線的な比例関係でしょう。現実には規模に応じて複雑度も増大して、単純な比例では済まないのかもしれませんが、まあ、コード量に応じて開発コストは確実に増大するというイメージは間違いないはずです。
一方、製品の機能セットとユーザーの満足度は、単純な比例関係ではないとように思います。
この機能実装量に対して、開発コストとユーザー満足度が異なる関数であることが、開発の妙味だったり苦しみだったりの要因となりがちなのではないかと思うのです。

まずは、満足度の最低レベルはクリアしなければなりません。そこに至るまでの状態を、仮に「サワー・スポット」と呼んでみます。
次に、最低レベルを超えると、開発すればする程にグングン満足度が上がる状態が訪れます。その状態は、「スウィート・スポット」と呼べるでしょう。
最後に、既に一定の満足度を達成して以降、開発しても開発しても、それまでとは違って満足度の向上は緩慢になる時期が訪れるはずです。なぜならば、それまでに多くのユーザの最大公約数的なニーズはほぼ満たされており、そこから先のニーズは千差万別な世界となるはずだからです。
この状態は、「ビター・スポット」と呼びたいところです。それは、酸いも甘いも噛み分けた大人の味覚です。

市場における競争という観点では、ビター・スポットに突入した体力勝負のような競合製品との差別化は避けたいところです。できるだけ、未開のフロンティアを開拓して、スウィート・スポットを享受できるに越したことはありません。
そもそも製品開発における製品の機能的な訴求力や完成度という観点でも、何しろサワー・スポットを超えてスウィート・スポットに到達すべきですし、そうすべく努力することでしょう。

でも、現実の製品開発においては、こんな便利な「ユーザー」の満足度についての道しるべはないのです。
「ユーザー」とは誰のことでしょうか？ どこにその「ユーザー」はいるのでしょうか？
もちろん、そんな「ユーザー」はどこにもいません。皆のニーズを過不足なく代表するような「ユーザー」なんてファンタジーです。
おまけに機能セットとユーザーの満足度は連続的な関数ではなく、離散的な関数です。つまりコードを1行増やせば、その分、満足度が高まるということはなく、あるコードのまとまりである機能セットを提供して初めて、満足度へ影響があるからです。
さらに、機能セットに対する満足度も個々のユーザーによって異なる可能性もありますし、そもそも実装の順序も本当は固定されている訳ではありません。

ファンタジーを追い求めて現実から乖離することは避けたいところです。また、たまたま聴こえる特定の声が正解である保障はありません。
では、どうするべきなのか。
多分、ここで、開発者のヴィジョンが問われるのだと思います。
そう言えば、しばらく前に、「ユーザー指向のもの作りに関する一考察」 というCNETのブログ記事にも、そんなようなことが書かれていました。

ヴィジョナリーは挫けちゃ駄目です。頑張るのです。