プロダクトを作るというのは、いったい何をやっている仕事なのだろう、と考えていた。 創造性やセンスが必要だと言われがちだが、実際に手を動かしているとしっくり来ない。 もっと地味で、調べ物と判断の繰り返しに近い、という感覚の方が実態に近い。
身も蓋もなく整理すると、プロダクト作りの 9 割は、既にどこかにある答えを今の条件に当てはめる作業だ。 そして、うまくいかないプロダクトは、たいてい何かの情報を持たないまま作ってしまっている。
プロダクトを作るのは、材料を集めて条件に合わせる仕事
プロダクトを作る仕事を、入力と出力のある一つの装置として書いてみる。 入力側に何が入るかというと、だいたいこういう情報だ。
- 顧客
- どういう場面で、何に困っているか
- 市場
- 既にどんなサービスがあり、それぞれ何で勝ち、何で負けているか
- 事業
- どこで儲けたいか、どこまでのリスクを取れるか
- チーム
- 何ができて、何ができないか
- 技術
- 何が可能で、何が地雷か
- 運用
- どれだけの人員とコストが割けるか
- 時間
- いつまでに、どのフェーズを終える必要があるか
出力側は、事業戦略、機能仕様、UI、システム設計、実装、テスト、運用の判断、といったものになる。 プロダクト作りとは、この入力を材料に、各レイヤで「今の世界に噛み合う出力」を返す仕事だ、と定義できる。
ポイントは、出力の評価軸が「論理的に正しい」ではなく「世界に噛み合っている」であることだ。 仕様として綺麗でも、顧客が実際にそう振る舞わなければ外れる。 技術的に洗練された設計でも、チームの手に余れば運用で崩壊する。
数学のように一意の正解が存在するわけではない。 常に「今の条件下で、いちばんフィットする形はどれか」を探し続けることになる。
9 割は前例を当てはめる作業
こう定義すると身も蓋もないのだが、プロダクトを作るというのは、実態としてはほとんど「創造」ではなく「探索と適用」だ。 既に世の中で誰かが解いた問題を見つけてきて、今の条件に合うよう調整する。 この繰り返しで、大半が済む。
日々やっていることを言語化すると、こういう順番になる。
- 目の前の問題を、既にある問題の型に分類する
- 似た状況で、誰がどう解いたかの前例を探す
- 今の条件と、その前例との差分を読む
- 差分を埋めるための調整を、最小限だけ入れる
- どうでもいい自由度は捨てる
- 既知の失敗パターンを避ける
新規性があるように見えるプロダクトも、よく見ると、別ドメインの既知パターンを今の制約に合わせて持ってきているだけ、というのが大半だ。
- 市場カテゴリ
- 既存カテゴリの組み合わせ
- UI / UX
- 既存の体験の再配置
- 技術構成
- 既知アーキテクチャの選択
- 事業モデル
- 既に勝ち筋のあるパターンの変形
本当にゼロから発明する場面は、ほぼない。
だから、いわゆる「センスがある人」の正体は独創性ではなく、前例を大量に知っていて、今の状況にあてはめる速度が速く、無駄な選択肢を素早く切り捨てられる人、と言った方が近い。 天才のひらめきではなく、蓄積と写像の話なので、学習と観察でかなり獲得できる。 逆に言えば、ショートカットもない。
例外があるとすれば、任意の性質を持つ化学分子を探すような、そもそも答えが存在するかも分からない問題領域くらいだ。 ただしそれは研究やサイエンスの領域で、プロダクトのエンジニアリングとは別枠になる。 エンジニアリングは、既にある部品と、既に分かっている条件の組み合わせで、実用に耐える解を組み立てる仕事、と定義した方がすっきりする。
いまいちなプロダクトは、情報不足で説明できる
こう見ると、失敗するプロダクトの共通点も、かなりクリアに整理できる。 失敗はセンスの欠如ではなく、必要だった情報を持たずに作ってしまった、という情報事故として説明できる。
おおまかには二種類ある。
一つ目は、そもそも基本的な情報が足りないタイプだ。
- 似たサービスの前例
- 顧客が普段どう行動しているか
- 業界のよくある地雷
- 技術上の常識
- 運用にかかる本当のコスト
こういったものを知らないまま作り始めているケース。 既存サービスがなぜ今の形に落ち着いているのかを理解していないので、表面だけ変わったものを作ってしまいがちになる。 プロダクトとしての強みが立ちにくく、出す前からある程度結末が見えてしまう、という状況に寄りやすい。
二つ目は、初期の仮説と実装力はあるが、現実からの跳ね返りを取り込む速度が足りないタイプだ。
- 市場のタイミング
- 実際の使われ方
- 価格に対する反応
- 流通経路
- 習慣として定着するかどうか
- 企業なら組織内で導入が進むかどうか
この手の「現実の抵抗」を早く観測して、次の一手に反映するループが遅いと、惜しいところで沈む。 手前の設計は正しくても、フィードバックが遅いという別の意味での情報不足だ。
つまり失敗は、大枠でこれらのどれかに落ちる。
- 前例を十分に知らなかった
- 顧客の実際を理解していなかった
- 市場の構造を読み違えた
- 制約条件を見落としていた
- 現実からの反応を取り込むのが遅かった
- 見るべき指標を間違えていた
いずれも情報の問題だ。 プロダクト作りは、創造性の勝負というより、世界から情報を取りこぼさない競技に近い、という言い方が実態に合う。
つまり、プロダクト作りは「情報を集める仕事」に近づいていく
以上を踏まえて、これからの仕事のシフトを描くと、かなり素直な形になる。
既にある答えを組み合わせる作業の相当部分は、道具（LLM 含む）が代わりに走らせてくれるようになる。 実装そのものの相対的な価値は、下がる。 代わりに価値が上がるのは、良い入力を用意できる能力だ。
ここで言う入力とは、顧客の観察結果、市場の構造、社内の制約、判断基準、そういった「本来なら頭の中や口頭に沈んでいる情報」を、読める形でまとめる能力を指す。 そのためには、書ける、読める、構造化できる、現実を観に行ける、というスキル群がこれまで以上に重要になる。
これらは特別な才能ではなく、地味な基礎練の集合だ。 プロダクト作りは、才能ゲームではなく、総合格闘技の基礎練不足で普通に負けるゲーム、というのが実態に近い。
単なる作業なのだが、扱わなければならない情報の範囲が広すぎるので、結果として難しく見える。 難しいのは、その情報を集めて構造化する体力と根気の話であって、天才が必要な話ではない。