ロードマップは機能表ではない: 未来を名詞で設計し、動詞は後で試す

いちばん危険なのは、「何を作るか」を先に決めてしまうこと

多くのプロダクト組織では、未来を語るはずのロードマップが、いつの間にか機能の配列表になってしまいます。そこでは、次に作るものが並び、優先順位がつき、見積もりが入り、安心感だけが増えていく。けれど、その瞬間に失われるものがあります。ユーザーが何と向き合うのか、そしてその体験をどんな操作の論理で支えるべきかという、もっと根本的な問いです。

これはUIの話にも、経営の話にも見えますが、実は同じ問題を別の角度から見ています。UIでは、ユーザーは「やること」から入るのではなく、関心の対象であるオブジェクトから入るほうが自然です。プロダクト戦略でも、未来は「作る機能」から入るのではなく、どの数字を、どんな状態に変えるのかから入るほうが強い。つまり、良い設計とは、名詞を先に立て、動詞は後から学ぶことです。

優れたプロダクトは、機能を積み上げてできるのではない。まず「何が主役か」を明確にし、その主役に対してだけ操作を許すことで、体験と戦略を同じ地平に置く。

この視点に立つと、UIのオブジェクトベース設計と、ロードマップから機能を追放する発想は、ただ似ているだけではありません。どちらも、人間の認知を「タスク中心」から「対象中心」へ戻す試みなのです。

---

名詞から始めると、世界は見える。動詞から始めると、世界は狭くなる

人は本来、対象物を見て考えます。机の上にある書類、編集したい写真、支払い先の口座、確認したい注文。私たちはまず「それ」を見つけ、それから「どうするか」を決める。にもかかわらず、多くのシステムはユーザーに「まずやることを選べ」と迫ります。これは、まるで暗いトンネルに入ってから、出口を探せと言われるようなものです。

この差は、単なる使いやすさの違いではありません。認知負荷の配分が違います。オブジェクトベースのUIでは、対象が先に見えるので、ユーザーは状況を理解しやすい。何が存在し、何が選べ、何が変わるのかが一目でわかる。逆にタスクベースの設計では、操作の前に手続きを選ばされるため、ユーザーは目的と対象を頭の中で結びつけ続けなければならない。

たとえば、写真管理アプリを考えてみてください。タスクベースなら「編集」「共有」「整理」をまず選び、その後で写真を指定します。オブジェクトベースなら、写真の一覧や単体のビューが先にあり、その写真に対して共有や編集を行う。後者のほうが自然なのは、ユーザーが欲しいのが「編集という行為」ではなく、あの写真の状態を変えることだからです。

この考え方は、プロダクト戦略にもそのまま写ります。ロードマップで「検索機能を作る」「通知機能を改善する」と並べると、チームは安心します。しかし、数字が見えない。何のための検索なのか、どの行動を増やしたいのか、どのボトルネックを解消したいのかがぼやける。すると、ロードマップは未来の地図ではなく、作業リストの上位互換になってしまいます。

本当に必要なのは、名詞の設計です。ユーザーにとっての主役は何か。プロダクトにおいて、追うべき対象は何か。購入、予約、投稿、保存、再訪、完了、継続。これらの対象を明確にしないまま動詞だけを並べても、体験は薄まり、戦略は散らばります。

---

機能は「答え」ではなく、「仮説」にすぎない

ここで重要なのは、機能そのものを否定することではありません。機能は必要です。ただし、機能は未来そのものではなく、未来に近づくための仮説です。この順序を間違えると、組織は手段を目的化します。

たとえば、売上向上を目指すロードマップを考えます。ここで「新しい決済機能を入れる」「クーポンを追加する」「UIを刷新する」と書いてしまうと、見た目は具体的ですが、実際には何も決まっていません。どの数字を、どの時期に、どんな状態へ持っていくのかが不明だからです。これでは、機能を実装しても、成果への接続が弱いままです。

逆に、ロードマップが「この四半期は継続率を5ポイント改善する」「次の半年で新規ユーザーの初回完了率を20パーセント上げる」といったアウトカム中心で書かれていれば、機能は固定されません。仮説を試し、学び、必要なら捨てることができる。ここでは、機能は答えではなく、検証のための道具になります。

この発想は、オブジェクトベースのUIと驚くほど似ています。UIでも、先に「編集フォーム」を決めるのではなく、ユーザーが扱うべきオブジェクトを先に定義します。単体表示にするか、コレクション表示にするか。どの属性を目立たせるか。何を一覧で見せ、何を詳細で扱うか。こうして初めて、動詞としての編集、共有、削除、保存が意味を持ちます。

つまり、オブジェクトは構造の単位であり、機能は変化の単位です。構造を定めずに変化だけを語ると、システムは迷子になります。

機能は地図の目的地ではない。オブジェクトの輪郭を描いたあとに、そこへ到達するための一時的な道として現れる。

この視点を持つと、ロードマップを「何を作るかの一覧」から「どの対象を、どんな状態に変えるかの計画」へ変換できます。すると、議論の質が一段上がります。例えば、「通知機能を作るべきか」ではなく、「ユーザーが見逃している重要なオブジェクトは何か」「その状態変化を知らせるべきか」と問えるようになるのです。

---

シングルとコレクションは、戦略にもそのまま当てはまる

UIには、単体を深く見せるシングルと、複数を俯瞰するコレクションがあります。これは画面設計の話であると同時に、思考様式の話でもあります。

シングルは、一つの対象を詳しく見るための場です。たとえば、一人の顧客、一件の注文、一つのプロジェクト。ここでは属性を多く見せてもよい。状態、履歴、関連データ、アクションの候補など、対象に関する厚みを出せます。ユーザーは「この対象をどう扱うか」を考える。

コレクションは、複数の対象を比較し、選び、優先順位をつけるための場です。ここでは情報を絞ります。全部を見せるのではなく、選択に必要な差分を見せる。これは戦略でも同じです。プロダクト全体を一枚のロードマップに載せるとき、すべての機能を同じ粒度で並べると、重要な差が見えません。

そこで必要なのが、ロードマップをコレクションとして設計する視点です。並べるのは機能ではなく、事業や体験の状態変化です。たとえば、

• 新規登録後の初回体験を短縮する
• 既存顧客の再訪を増やす
• 主要ユーザーの意思決定を高速化する
• サポート依頼の前に自己解決できるようにする

これらは機能ではありません。しかし、プロダクトの進む方向を示すには十分に具体的です。そして必要なら、それぞれの状態変化に対して複数の機能仮説をぶら下げればよい。

この設計が強いのは、チームが「何を作るか」ではなく、「何を見せるべきか」「何を隠すべきか」を考えるようになるからです。UIで重要な属性だけを一覧に出すのと同じように、ロードマップでも重要なアウトカムだけを表に出す。細部は後で検証すればよい。最初から全部を固定すると、変化に弱くなります。

---

良い設計は、自由を与えるのではなく、自由の輪郭を定める

ここで一つ誤解を解いておきたいのは、オブジェクトベースが常に自由で、タスクベースが常に悪いわけではない、ということです。ATMや定型的な申請フローのように、対象が限定され、選択の余地が少なく、手続きを迷わせないほうがよい場面はあります。むしろそこで自由を増やすと、混乱が増えるだけです。

この事実は、ロードマップにも重要な示唆を与えます。すべてをアウトカム中心にしろと言っても、現場が何をすべきか分からなければ機能開発は進みません。逆に、すべてを機能で書いてしまえば、組織は短期の実行に閉じ込められます。必要なのは、自由と制約の適切な切り分けです。

私はこれを、二層モデルとして捉えるのがよいと思います。

1. 上の層はオブジェクトとアウトカム
   何を主役にするか、どの数字を動かすか、どんな状態を目指すかを定義する。

2. 下の層は仮説としての機能
   その状態を実現するために、どの操作や実装を試すかを複数並べる。

この二層が分かれていれば、上の層は安定し、下の層は変えやすくなります。UIでも同じです。ユーザーが見ている対象は安定していてよいが、その対象に対するアクションは、状況に応じて差し替え可能であるべきです。たとえば「注文」という対象は変わらなくても、配送変更、キャンセル、再注文、問い合わせ導線は時期や条件で変えられる。

自由とは、何でもできることではない。主役がはっきりしていて、その主役に対する操作が状況に応じて調整できることだ。

この意味で、ロードマップに機能を書くべからず、という主張は単なる表現の問題ではありません。機能は必要だが、それを未来の単位として扱うと、組織の視界がタスクへ縮む。未来の単位は、対象の状態変化と、その変化を測る数字であるべきです。

---

Key Takeaways

• まず名詞を定義する。 何を主役にするのかを決めてから、何をするかを考える。
• 機能は仮説として扱う。 ロードマップに載せるのは、実装案ではなく、達成したい状態と数字にする。
• 一覧には差分だけを出す。 UIでも戦略でも、コレクションは重要な属性だけを見せるほうが判断しやすい。
• 単体で深く見る場を作る。 重要なオブジェクトは、詳細を見られるシングルの文脈を用意する。
• 自由と制約を分ける。 上位では目的を固定し、下位では手段を試す。そうすると変化に強くなる。

---

未来を設計するとは、操作を増やすことではない

私たちはしばしば、より多くの機能があるほど優れたプロダクトだと思いがちです。けれど、優れたプロダクトが本当に増やしているのは機能ではありません。対象の見えやすさです。ユーザーが何を見て、何を選び、何に対して行動できるか。その輪郭が明確であるほど、人は迷わず、創造的になれます。

そして、優れたロードマップも同じです。未来を機能の列で語るのではなく、何を良くするのか、誰のどんな状態を変えるのか、どの数字を動かすのかを先に置く。機能はその後でいい。むしろそのほうが、組織は学べます。なぜなら、未来を固定しないからです。

結局のところ、設計とは操作の設計ではなく、関心の設計です。何を見せるか、何を主役にするか、何を後回しにするか。その選択が、UIをつくり、戦略をつくり、そしてプロダクトの未来をつくります。

ロードマップから機能を書き消すことは、現実逃避ではありません。むしろ逆です。未来を、まだ確定していない手段ではなく、確実に変えたい対象として捉え直す、最も現実的な方法なのです。