PdMとエンジニアだけでUIを作り始めるのは合理的だ。だが、ある時点で限界が来る。「いつ来るか」はフェーズ理論より現場の症状で判断する方が頼りになる。
- 「なんか違う」が増えたが直し方がわからない
- PRDと実装の間で仕様が確定しない
- 機能は揃ったのに定着しない
- UIの判断を誰もできない
- 競合と同じ機能なのに選ばれない
ここでは、なぜPdMとエンジニアだけだとこうなるのか、構造的な理由を整理する。
PdMが見ているもの、エンジニアが見ているもの
PdMは「誰のために、何を、なぜ作るのか」を見ている。ユーザーの課題、市場の機会、ビジネスとしての成立性。仕事の対象は言語で定義できるものだ。PRDを書き、要件を固め、優先順位をつける。
エンジニアは「どう実装するか」を見ている。技術的に成立するか、パフォーマンスは出るか、保守できる設計か。仕事の対象はコードとシステムだ。
両者の視野を合わせると、「何を作るか」と「どう作るか」はカバーされている。だが、「触ったときにどう感じるか」はどちらも見ていない。ボタンを押したときの手応え、画面を開いたときの第一印象、操作していて気持ちいいか。この領域はPdMの仕事でもエンジニアの仕事でもないから、誰の責務にもなっていない。
プロダクト開発組織における役割分担の構造と重要性で述べた通り、役割分担は「誰が何を見るか」を決めるものだ。デザイナーがいないチームでは、UIの感覚的な品質を見る人がいない。見ていない領域は改善されない。
空白の領域はロジックの外にある
この空白が厄介なのは、ロジカルに考えても埋まらないことだ。
PdMもエンジニアもロジックで仕事をしている。言語化して、分析して、判断する。PRDの前にデザインを作ることで要件の解像度が格段に上がるで論じたように、PRDは文章で表現できる粒度でしか要件を定義できない。「ユーザーが直感的に操作できるUI」と書いても、書いた本人以外には何も伝わらない。
ところが、UIが要求する判断の多くは言語化の手前にある。言語化可能な世界の限界：人間の認知における非言語的知識の圧倒的優位性で述べられているように、人間が言語化できるのは認知の10%程度だ。色の組み合わせが心地いいかどうか、余白の量が適切かどうか、画面遷移のテンポが気持ちいいかどうか。これらは見た瞬間に判断されるもので、ロジカルに導出できるものではない。
デザイナーはこの非言語領域で日常的に仕事をしている。デザイナーの核心スキルは直感の論理化にあるで整理した通り、デザイナーの訓練とは、まず非言語的な直感で「これだ」を掴み、次にそれを言語で説明できるようにすることだ。直感が先、論理化が後。この順序は逆にできない。
PdMとエンジニアがいくらロジカルに考えても、非言語的な判断力は育たない。使う認知の型が違うからだ。解釈無限な物に対してのアプローチを常日頃行ってるからこそ、デザイナーは想像力が高いにある通り、正解が一つに定まらない問題に日常的に向き合い続けることで育つ感覚であって、片手間に身につくものではない。
なぜ最初は問題にならないのか
事業の0-1探索段階においてデザインは必須ではなく、問題発見と仮説検証こそが最優先されるで整理した通り、プロダクトの初期段階ではPdMとエンジニアの視野で十分足りる。この段階で求められるのは「正しい問題を見つけること」と「解決策が機能するか検証すること」であって、UIの感覚的な品質ではない。
0→1プロダクト開発では観察駆動の試行錯誤による発見が再現可能な設計より優先されるように、検証速度が全てのフェーズでは、標準コンポーネントで組んだ「ロジカルに正しいUI」で事足りる。むしろ作り込んだUIは捨てにくくなり、ピボットを遅らせる。
この段階では、カバレッジの空白は存在するが顕在化していない。ユーザーがプロダクトを使う理由は「課題が解決されるから」であって、「触っていて気持ちいいから」ではない。だからPdMとエンジニアの二人三脚で十分に成立する。
なぜある段階で限界が来るのか
問題は、プロダクトが成長するにつれて、ユーザーがプロダクトに求めるものが変わることだ。
初期は「正しい」で十分だった。課題を解決してくれるなら、UIが粗くても使う。だが、競合が出てきて機能差がなくなると、選ばれる理由は「正しい」から「好き」に移行する。課題解決系と価値提案系の違いは創造的ジャンプの度合いと制約下での選択肢に表れるで整理した分類では、課題解決から価値提案への移行だ。
デジタルプロダクトにデザイナーが必要なのは直感で問いを立てられる人間がチームにいないとプロダクトが心を動かせないからであるで述べた通り、ロジカルに正しいUIは使って不快ではないが、心も動かない。毎日触るプロダクトで「好き」を生み出すのは、非言語的な判断の蓄積だ。初めて開いたときの小さな驚き、操作のフィードバックの気持ちよさ、画面遷移のテンポ感。仕様書に「ユーザーを驚かせること」と書いても生まれない類のものだ。
見た目が美しいものは使いやすいと錯覚されるで論じたaesthetic-usability effectの裏を返せば、ユーザーは感覚的な心地よさをプロダクトの品質として知覚している。デザインの価値は初期露出の後の定着率と最大風速を決めるところにあるが指摘する通り、この差は定着率として数字に出る。
つまり、限界が来る理由は単純だ。PdMとエンジニアの認知がカバーしていない領域が、プロダクトの成長とともに勝負を決める領域になるからだ。初期は「正しい」が勝ち、後期は「好き」が勝つ。「好き」を作る能力がチームにないと、プロダクトの天井が見えてくる。
カバレッジの空白が現れる兆候
この空白がチームに現れるとき、いくつかの典型的な兆候がある。
チームの誰かが「なんか違う」と言い始めるが、何がどう違うのか言語化できない。PdMは「もっと使いやすく」と言い、エンジニアは「具体的に何を変えればいいのか」と返す。会話が噛み合わない。非言語的な判断力がチームに不在だから、違和感を改善行動に変換できない。
PRDと実装の間で仕様が何往復しても確定しない。文章では画面の振る舞いやエッジケースを表現しきれないからだ。AI時代のプロダクト開発は高速な言語化・可視化・反復プロセスによって競争優位を実現するにある通り、可視化は言語化を補完する。画面を先に作れば仕様の穴は自然に埋まるが、それをやる人がいない。
UIの細かい判断（マージン、色、モーダルの閉じ方、エラー表示）を求められたとき、誰も答えを持っていない。各エンジニアがそれぞれの感覚で決めた結果、画面ごとにUIの一貫性がなくなる。デザインプロセスは明確なアウトプット単位と役割分担によって効果的に進行するように、判断権者の不在が一貫性を壊す。
これらの兆候はフェーズ理論（0→1、PMF前後）より頼りになる判断材料だ。事業フェーズ別のデザイナーおよびデザイン組織の在り方のような整理はあるが、「今うちはどのフェーズか」は当事者には分かりにくい。対して、兆候は現場で毎日観察できる。
兆候を先行指標にする
デザイナー採用の難しさを考えれば、兆候が出てから動いたのでは遅いという反論もある。だから兆候は「今すぐデザイナーを入れるべきか」の判断だけでなく、「採用活動を始めるべきか」の早めの信号として使える。兆しが一つでも見えたら動き出す。実際にジョインする頃には兆候が顕在化しているから、タイミングとしてちょうどいい。
もう一つの手として、構築とデザインの関係性は逆転し、反復的構築とジャッジを通したデザイン昇華プロセスが重要性を増しているで述べた「構築しながらジャッジする」アプローチがある。常勤のデザイナーを採用する前に、外部デザイナーにスポットでジャッジを依頼する。プロトタイプを見せて「ここが引っかかる」「ここはこう変えた方がいい」というフィードバックをもらうだけでも、カバレッジの空白はかなり埋まる。
PdMとエンジニアだけでUIを作り始めることは間違っていない。だが、彼らの認知がカバーしていない領域は確実に存在していて、プロダクトの成長とともにその領域が勝負を決めるようになる。自分たちのチームに空白の兆候が出ているかどうか。それを見ることが、デザイナー参画のタイミングを判断する一番確実な方法だ。