最も重要なプロダクト判断は「何を作らないか」である

The most important product decision is what you don't build

最も重要なプロダクト判断は「何を作らないか」である

消費者向け金融アプリで「ドキュメントハブ」と「通知センター」をあえて作らない選択をした経験から、作らないことの重要性を説く。作るコストより維持コストを可視化して関係者を説得し、削除を称賛しない組織文化や人間の認知バイアスに触れ、Steve Jobsの1997年の製品マトリクスを引き合いに、一度に一つに集中することの価値を強調する。

作ってリリースする人が報われ、尊敬される。なぜなら私たちの文化は、何よりも物を生産することを評価し続けているからだ。レビューし、維持し、削除することは、すべて劣った仕事と見なされている。
  1. alentred

    私は、おそらく60年代に積極的に建設された小さな町をかなり訪れたことがあるのですが、そこではしばしば、ここに公園、あそこにコミュニティセンターといった、野心的、あるいは大げさなプロジェクトが放棄されているのを見かけます。完全に建てられたのに、今ではすっかり無人で、しばしば廃墟になっています。

    それらを見るたびに、いつも教訓も思い知らされます。維持費を計算に入れなさい、と。確かに素敵な人工水路ではあるけれど、その都市にそれを運営し、清掃し、水を供給するお金があるのでしょうか?

    もちろん、元の(不動産)開発者がコスト分析をしたことは知っています。しかし、そうした放棄された場所を見ると、非常に客観的に、彼らは誤りを犯したと結論づけられます。計算ミス、あるいは判断の誤りです。

    --

    ソフトウェアに戻ると、スコープクリープは多くの問題を引き起こすと思います。チームは集中力を失い、誰も必要としない機能を提供することでやる気を失うなど、すべて現実的で深刻な問題です。しかし、最終的にチームの能力をすべて壊滅させる可能性があるのは、しばしば見過ごされがちな、増え続ける維持費です。

    私たちが作るものはすべて維持する必要があり、すべてのプロジェクトはこれを予算に含めるべきです。品質は最高レベルであっても、外的要因のためにソフトウェアをアップグレードする必要があります。そして、増大する維持費は、上記で挙げた他の問題を悪化させるだけです。

    --

    そして、これがエンジニア、エンジニアリングマネージャー、あるいはCTOでさえあることの悲劇です。まさに投稿が言うように、やらないことを拒否したことで「昇進」することはありません。私は、プロダクトチームを説得することに何度も成功した経験があります […]

  2. stevoski

    私の本のある章では、この問題に「ボタンを追加し、ボタンを削除する」というマントラで取り組む会社を特集しています。

    新しいUI要素を追加する前に、まず削除できるものを探します。

    自己宣伝リンク: https://killthehippo.com/

  3. mmonaghan

    このような意見の投稿をよく見かけますが、私は二つの考えがあります:

    - LLMのおかげで、今では欲しいものをかなり迅速に構築できる、少なくともプロトタイプは作れる

    - しかし、これらの機能(または別の製品)を迅速に構築できることがまさに罠なのです

    > 適切な問題を選ぶときに私がいつも適用しているのと同じテストです — それはボートを速く進めますか?

    しかし、誰がこれを知っているのでしょうか?エンジニアであることは稀です。プロダクトはしばしば自分の領域内では良い感覚を持っています。リーダーシップは通常(良い会社では)ほとんど一致していますが、誰が話しているかによっていくつかのニュアンスがあります。

    良い意見ですが、単独の人の決定であることは稀です。

    私が言ったように、これらが現れるのを見ると、たいていイライラします。この時点で誰が新しい視点を提供できるというのでしょうか。でも毎回読んでしまいます :p

  4. djtriptych

    あるいは、私がよく言うように「ローンチする最善の方法は機能を削ることだ」。

    エンジニアリングリーダーとして、プロダクト/デザインに対して常にそれを主張しなければなりません。

  5. SophiaVela

    私にとって難しいのは、いつ止めるべきかを知ることです。準備ができたと感じる前に、常にもう一つ改善すべきことがあります。

この日のほかの記事

2026-09-17