機能を追加するのは、簡単だ。でも、機能を削るのは難しい。
結果、使われない機能が積み上がっていく。
それは、資産ではない。負債だ。
機能は増え続ける
プロダクトは、時間とともに機能が増えていく。
新しいユーザーの要望に応える。競合に追いつく。新しいアイデアを試す。
気づけば、機能が100個を超えている。でも、そのうち使われているのは10個だけ。
残りの90個は、何のためにあるのか？
使われない機能のコスト
使われない機能は、コストを生む。
開発コスト。 作るのに、時間とお金がかかった。
メンテナンスコスト。 作った後も、バグ修正、アップデート、互換性維持が必要だ。
複雑さのコスト。 機能が多いほど、プロダクトは複雑になる。複雑になると、新しい機能を追加するのが難しくなる。
ユーザー体験のコスト。 機能が多すぎると、ユーザーは迷う。何をすればいいか分からなくなる。
使われない機能は、百害あって一利なしだ。
37signalsの決断
プロジェクト管理ツールのBasecampは、定期的に機能を削除する。
使用率が低い機能。複雑さを生む機能。メンテナンスコストが高い機能。
容赦なく削る。
「でも、この機能を使っている人がいるかもしれない」
確かにいる。でも、全体の1%だ。99%のユーザーのために、その機能を削る。
削る勇気
機能を削るのは、勇気がいる。
「せっかく作ったのに」「誰かが使っているかもしれない」「削ったら文句を言われるかもしれない」
でも、削らないと、負債が積み上がっていく。
定期的に、機能の棚卸しをしろ。使われていない機能を見つけたら、削れ。
80/20の法則
パレートの法則は、プロダクトにも当てはまる。
20%の機能が、80%の価値を生む。残りの80%の機能は、20%の価値しか生まない。
その80%の機能を削ったら、どうなるか？
価値は20%しか減らない。でも、複雑さは80%減る。メンテナンスコストも80%減る。
どちらが良いか？明白だ。
機能を追加する前に
新しい機能を追加する前に、こう問え。
「この機能は、本当に必要か？」
「この機能は、多くの人が使うか？」
「この機能は、複雑さを増すか？」
「この機能の代わりに、削れる機能はないか？」
追加する前に、削ることを考えろ。
使われない機能は、負債だ。定期的に棚卸しをして、削れ。
シンプルさを保つことが、最も重要だ。