Why Great Products Need a Cutoff Point Before They Need More Features

いちばん重要なのは、機能ではなく「切片」を決めること

新しいサービスを作るとき、多くの人はまず機能を考えます。投稿、検索、通知、決済、分析、モデレーション。必要なものを積み上げていけば、きっと良いものになるはずだと信じたくなるからです。

でも本当に先に決めるべきなのは、機能ではありません。そのサービスが何もしなくても成立してしまう基準点です。数学でいう切片、回帰モデルでいう intercept のようなものです。入力がゼロでも残る値。そこに最初から乗っている定数。サービス設計に置き換えるなら、ユーザーがまだ何もしていない段階で、すでに成立している体験の核です。

これは単なる比喩ではありません。設計、開発、運用の多くの失敗は、切片を決めずに傾きだけを最適化しようとすることから起こります。つまり、何を増やすかは決めたのに、何を固定するかを決めていないのです。

優れたプロダクトは、足し算で生まれるのではない。まず「何が常にそこにあるべきか」を決め、それから初めて増分を設計する。

この視点を持つと、設計思想、MVP、パフォーマンス、セキュリティ、コミュニティ運営までが一本の線でつながります。

---

切片とは何か。プロダクトにおける「ゼロでも残る価値」

数学の切片は、xが0のときのyです。回帰モデルでは、説明変数がゼロでも残る予測値。ここで大事なのは、切片が「オマケ」ではなく、モデルの出発点だということです。式の中ではたった一項ですが、全体の位置を決めます。

プロダクトでも同じです。ユーザーがまだログインしていなくても、まだ投稿していなくても、まだ友達がいなくても、そのサービスに触れた瞬間に感じる価値があります。たとえば次のようなものです。

• 画面の読み込みが速く、待たされない
• 何をすればいいかが一目でわかる
• 余計な入力が少ない
• 雰囲気が心地よい
• 安心して使えると直感できる

これらは「機能」ではなく、切片的価値です。しかも、後からいくら機能を足しても、この基準点が低いと体験全体が安定しません。逆に切片が高いサービスは、機能が少なくても強い。なぜなら、ユーザーは機能の数ではなく、最初の接触で生まれる確信で残るからです。

ここで消費税の比喩は少し役立ちます。消費税は価格に比例して増える変数です。一方で切片は、価格に関係なく一定で存在する固定値です。プロダクトで言えば、画面ごとに増えるオプションや通知は税のようなものですが、最初にどんな体験が保証されるかは切片です。両者を混同すると、積み上げれば良くなると勘違いします。

本質はむしろ逆です。まず固定すべきなのは、体験の最小保証値です。そこが決まると、追加機能は「価値を増やす手段」になり、ノイズではなくなります。

---

15ステップの本質は、開発フローではなく「切片を守る装置」だ

一般的な開発手順は、思想、仮説、仕様、実装、テスト、運用と進みます。これは単なる工程表ではありません。深く見ると、切片を守るためのシステム設計です。

まず、思想とビジョンを固める段階で問うべきなのは、誰のどんな感情的課題を解くのかです。これはKPIより前に置かれるべき問いです。なぜなら、数字は傾きしか見せないことが多いからです。再訪率、滞在時間、投稿率は重要ですが、それだけでは「心地よさ」を保証できません。サービスの切片は、しばしば数字になる前の感覚に宿ります。

次に、ユーザー理解と仮説検証です。ヒアリングやペーパープロトタイプの目的は、アイデアを説明することではありません。ゼロの状態で価値が立ち上がるかを確かめることです。クリックダミーで十分伝わらないなら、そこにはまだ切片がない。機能を足す前に、基準点が見えているかを確認する必要があります。

仕様を固める段階で「やらないこと」を明記するのも同じ発想です。スコープを狭めるのは我慢ではなく、切片を守るためです。機能を増やすほど、何もしなくても成立していたシンプルな価値が埋もれるからです。

この観点はアーキテクチャにも直結します。12-Factor のような原則は、環境差分に壊されない基準点を作る思想です。Next.js や Vercel のチェックリスト、Supabase の宣言的スキーマ管理、Cloudflare Images の署名付き URL なども、結局は初期状態と運用状態のズレを最小化するための仕組みです。つまり、切片を守るための土台です。

良いアーキテクチャとは、機能を増やすための骨組みではなく、最初に定義した体験の高さを下げないための骨組みである。

テスト戦略も同じです。Unit, API, E2E, Perf の各層は、単にバグを見つけるためではなく、切片が壊れていないかを確認する装置です。とくに Perf テストは重要です。INP や LCP は「速いと嬉しい」という話ではなく、体験のゼロ地点がまだ成立しているかを測ります。遅いサービスは、機能が多くても切片が低い。ユーザーは価値に到達する前に離脱してしまうからです。

---

傾きだけを伸ばすと、サービスは重くなる

切片の発想が重要なのは、私たちがしばしば傾きだけを最適化してしまうからです。傾きとは、機能追加、成長率、通知量、KPIの伸び、売上の増分です。ビジネスの世界ではよく見える指標ですが、これだけを追うと、サービスはすぐに重くなります。

たとえば、いいね通知、フォロー通知、おすすめ通知、運営通知を足していくと、短期的には反応率が上がるかもしれません。しかし、ユーザーの最初の体験が煩雑になれば、そもそも残りません。ここで起こっているのは、傾きを上げるために切片を削っているという逆転です。

グロースでも同じです。K-factor のような拡散指標は魅力的ですが、最初に必要なのは、ユーザーがその場で「また来たい」と思える熱量です。これはLTVにもつながりますが、より本質的には、体験の基準温度です。熱量が低い状態で拡散だけを追うと、広がるのは不満です。

ここで Slow-Web の考え方が効いてきます。数字より心地よさを優先する設計は、成長を拒む思想ではありません。むしろ、短期の伸びに対して、長期的に壊れない切片を残すための選択です。速く増やすことより、長く残ることを優先する。これは感覚論ではなく、構造の問題です。

運用面でも同じです。SLO やアラート設計、オンコール、モデレーション、プライバシー対応は、後から付け足す雑務ではありません。これらは、プロダクトが社会的に存在し続けるための定数項です。ここが欠けると、どれだけ美しい機能も現実世界では成立しません。

たとえば、画像投稿サービスで NSFW 検知や通報フローが弱ければ、コミュニティは荒れます。荒れた場所では、どんな機能も魅力を失います。つまり安全性とガバナンスは、単なる追加機能ではなく、信頼という切片そのものです。

---

では、どうやって切片を設計するのか

切片を設計するとは、単にミニマルにすることではありません。削ることと守ることは違います。削りすぎると、ただ空っぽになります。重要なのは、何が常に存在していてほしいかを定義し、その上で増分を積むことです。

実践的には、次の3つを先に決めるとよいです。

1. 体験の切片

ユーザーが最初の10秒で得るべき感覚は何かを明文化します。たとえば、

• 迷わない
• 待たない
• 不安がない
• すぐ意味がわかる

このうち、どれを絶対条件にするかを決めます。これが曖昧だと、デザインも機能もぶれます。

2. 運用の切片

サービスが小さいうちから必ず維持する基準を定義します。たとえば、

• エラーはSentryで拾う
• デプロイは同一イメージで昇格する
• バックアップは自動化する
• セキュリティチェックを定期化する

これらは規模が大きくなってから必要になるのではありません。むしろ小さいうちに入れておかないと、後で取り戻せない初期傾きになります。

3. 判断の切片

意思決定のルールも固定します。たとえば、

• ユーザー価値に直結しない機能は入れない
• やらないことをPRDに書く
• 月次で技術負債を見直す
• 1つ触ったら1パーセント改善する

これは意識の問題ではなく、判断コストを下げるための設計です。判断の切片があると、毎回ゼロから迷わなくて済みます。

この3つが揃うと、サービスは単なる機能集合ではなく、一貫した体験を維持するシステムになります。

---

Key Takeaways

1. まず「切片」を決める。 ユーザーが何もしていない状態でも成立している価値を定義する。機能追加より先です。

2. KPIは傾き、体験は切片。両方必要だが役割が違う。 指標が伸びても、最初の接触が悪ければ残りません。

3. やらないことを決めることは、価値を削ることではない。 それは切片を守り、プロダクトを重くしないための設計です。

4. 安全性、速度、運用性は後付けではなく定数項。 これらが壊れると、サービス全体の基準点が下がります。

5. 小さく作るとは、貧しく作ることではない。 最小機能の裏側に、最小ではない信頼と安定を置くことです。

---

結論: いいプロダクトは、成長する前に「ゼロでも成立する」

多くのチームは、プロダクトを関数のように考えます。入力を増やせば、出力も増える。ユーザーを増やせば、売上も増える。機能を足せば、価値も増える。もちろんそれは間違いではありません。

ただし、もっと重要なのは、xが0でも残るyを設計できているかです。ユーザーがまだ行動していなくても、そこに安心があるか。まだ通知がなくても、また使いたいと思えるか。まだ成長していなくても、壊れないか。

切片を設計するとは、サービスの最初の高さを決めることです。そしてその高さは、あとからどれだけ傾きをつけても簡単には補えません。だから本当に問うべきなのは、「何を追加するか」ではなく、「何をゼロにしても残すか」です。

プロダクトの成熟とは、機能が増えることではありません。ゼロ地点の品質を、何があっても落とさないことです。そこに気づいたとき、設計は足し算から定数設計へ変わります。