PRDには書けないけれど、プロダクトの「愛着」を求めたい

公開日:2026.05.01


※この記事は『2025年12月12日』に公開した内容をもとに掲載しています。


落ち着いて過去の仕事を振り返る

この約二年、振り返ってみれば0→1のフェーズばかりを4回ほど駆け抜けてきた。
とにかく「動くデモ」を必死で作り続けてうまくいけば本番提供に動き出すし、うまくいかなければ次のプロダクトに駆け出す日々だった。特にBtoBのSaaSにおいては、まず最初のお客さんを獲得することが最優先事項であり、生命線になる。だから実装もデザインもなんでもやるし、スピードが命だ。

汎用的な機能やUIは、既に世にある優れたサービスの良いところをどんどん真似させてもらう。その代わり、自分たちが提供する独自の価値、コアとなる部分だけは汗をかいて独自に考える。とにかく「このプロダクトで何ができるのか」を伝えることに全比重を置いて、意匠の美しさや細部の作り込みは二の次にして走ってきた。 けれど、そうやって機能のパズルを最短距離で埋めていく中で、ふと立ち止まって考えることがある。課題を解決し、数字を合わせるパズルの、その先について。この記事はそんな、短距離走を走り続けてきた作り手の、独り言ポエムになる。

0→1を繰り返す中で思うこと

Webサービスのデザインについて考えると、どうしても「ユーザーの課題解決」という言葉が最初に浮かんでくるし、実際そこから議論をスタートさせることが多い。
けれど、最近はどうもそれだけじゃ足りないというか、少し窮屈さを感じることがある。

ユーザーが今抱えている課題から出発して、その解決策を提示しようとすると、必然的に「現在のユーザーの作業フロー」の中にどう綺麗にピースをはめるか、というパズルゲームになりがちだ。
でも、それって結局のところ、既存のフローに「当てはまるか、当てはまらないか」の二択勝負になってしまう。当てはまれば便利だけど、当てはまらなければ不要、で終わってしまう。

本当に良いプロダクトって、実はもっと図々しいものなんじゃないかと思う。既存のフローに合わせるんじゃなくて、あえて少しズラす。むしろ、そのプロダクトを使うことで元の作業フロー自体が変わってしまうような、そういう引力を持っている。
サービスを使っているうちに、ユーザーの行動そのものが変容していく感覚。私の中のわかりやすい例で言えばNotionで、最初はただのメモ帳やToDoリストの代替、つまり既存のツールの置き換えとして使い始めたはずなのに、気づけばNotionを中心に情報設計を考え始めている自分がいる。
今や「MCP(Model Context Protocol)で繋がれるか」「APIで連携できるか」という基準で他のツールを選定し始めている。
これは完全に主客転倒だ。でも、これこそが本質なんだと思う。

本当に良い道具に出会うと、人はその道具を最大限に活かすために、自分の環境や習慣の方を変えようとする。道具に合わせようと、ユーザー自身が変化するのだ。
だからこそ、リリース当初に想定したペルソナが、一年後も三年後も一切変わらないようなプロダクトでは、いつでも置換可能なモジュールになってしまう。
プロダクトがアップデートされるのは当然だけど、それを使うユーザーもまた、プロダクトによって視座が高まったり、使い方が深まったりしてアップデートされていく良い道具を使いたいがゆえに、「もっとこうしたい」という新たな課題がユーザーの中に生まれる。そうやって生まれた新しい渇望に、プロダクトがまた応えていく。
そういうサイクルを作れるかどうかが、愛されるWebサービスの分かれ目になるんじゃないだろうか。

「パズルピースを綺麗にはめる」という感覚、特にBtoBのSaaS領域では顕著な気がする。企業側からすれば、導入における摩擦が少なく、既存のフローを乱さないというのは大きなメリットだ。単純に業務時間が減り、空いた時間を他のことに使える。その費用対効果さえ基準を満たしていれば、それ以上の変化を求めるのは、ある種「お節介」なのかもしれない。今の業務フローを維持したいと考えるのが自然だし、システムは静かに黒子に徹している方が好まれることも多い。
しかし、いち作り手としての本音を言えば、やっぱり簡単に切り替え可能な部品ではなく、「離れがたい」プロダクトであってほしいと願ってしまう。

たとえば社内に凄腕のエクセル職人がいて、マクロを駆使した神がかった管理シートを作り上げたとしても、「いや、それでもこのプロダクトを使いたいんだ」と言わせるような何かが欲しい。それは単なる効率化の数値勝負を超えた部分にあるはず。

なぜそのプロダクトを選ぶのか。

そこには計算式には表れない「愛着」のようなものや、もはや思考の一部になってしまったような「便利さ」、あるいは「このサービスを使っていれば、将来的な技術の拡張や変化にも追従できるはずだ」という未来への期待値が含まれている気がする。単に今の業務が回るからだけじゃなく、「時代の流れに乗っている」という感覚や、自分たちの仕事の質が道具によって引き上げられるような感覚。
そういった、機能以上の何かが評価されて選ばれ続ける、そんな存在を目指したい。

結局走り続けるしかない

正直なところ、どうやってそれを実装に落とし込むかという答えは、まだない。ユーザーの行動が数年後にどう変容しているかなんて、最初から完全に見通すことは不可能に近いし、それを完璧に予測しようとするのは少し傲慢かもしれない。
結局のところ、ユーザーと一緒に泥臭く走りながら、その時々の「Great」な形を模索し、創り続けていくしかないのだと思う。
ただ、だからといって羅針盤なしで漂流するわけにはいかない。

「自分たちはどういうプロダクトでありたいか」という確固たる意志、あるいは美学のようなものを、作り手が常に懐に忍ばせておくことは絶対に必要だ。それさえあれば、例えばユーザーヒアリングの現場一つとっても、風景が変わってくるはずだから。
単に要望を聞いて「わかりました、修正します」と頷くだけの御用聞きで終わらなくなる。「今の課題はそうかもしれないけれど、私たちが目指すこのプロダクトの在り方からすると、こういうアプローチの方が本質的ではないですか?」といった、さらなる別の提案や、そこから生まれる深い議論。
その「あと一歩先」へ踏み込むための気概は、作り手の意志から生まれる気がする。

そうやって摩擦を恐れずに提案していくことが、結果としてユーザーを新しい場所へ連れて行くことにつながるんじゃないだろうか。

Hidetoshi Asao のプロフィール画像

WRITER

Hidetoshi Asao

Acompany / エンジニア

-

入力された情報は学習には使われませんが、念のため個人情報の入力はお控えください。

読書の進捗

0%