プロダクトはコードではなく、学習ループでできている

Hatched by tttt

Apr 20, 2026

1 min read

3 views

87%

いちばん高くつくのは、作ることではない

多くの組織は、プロダクトのコストを「開発工数」で見積もる。だが、実際に高くつくのはそこではない。もっと厄介なのは、間違ったものを作り、使われないものを維持し、使い方を説明するために人を増やし続けることだ。

ここに、プロダクトづくりの本当の逆説がある。開発チームの速度を上げたいなら、まずコードを書く前の時間と、リリース後の支援を見直さなければならない。なぜなら、プロダクトの価値は「完成した瞬間」ではなく、ユーザーが実際に成功するまでの一連の体験で決まるからだ。

つまり、プロダクトとは機能の集合ではない。学習が流れ込んで、学習が返ってくるシステムである。サポート、コンサルティング、UI、要件定義、開発チームは別々の部署に見えて、実はひとつの循環の別々の地点にすぎない。

速いチームとは、たくさん作れるチームではない。間違いを早く見つけ、早く修正できるチームだ。

「作る前」と「作った後」は、同じ仕事の続きである

プロダクトマネジメントで見落とされがちなのは、ユーザー体験が画面の内側で終わらないことだ。導入支援が必要なら、その支援は体験の一部になる。サポートに電話しなければ使えないなら、その電話の先にいる人は単なる付属品ではなく、プロダクトの一部として機能している。

たとえば、家具を買った顧客が、自分で組み立てられず、毎回サポートに連絡し、さらにコンサルタントが個別に手順を説明しているとする。このとき顧客が感じている価値は、家具そのものだけではない。説明書、動画、チャット対応、設置支援、FAQ、そして必要なら誰かが家に来ることまで含めた総合体験だ。

エンタープライズソフトも同じだ。製品の成否は、ログイン画面や機能数ではなく、導入初日から業務で使える状態になるまでの摩擦の少なさで決まる。もしそこに支援チームが必要なら、そのチームは「製品の外」にいるのではない。製品の価値を最後まで届けるためのインターフェースなのだ。

ここで重要なのは、支援を厚くすればよいという話ではないことだ。むしろ逆で、支援が多すぎると、それはプロダクトの失敗を覆い隠すクッションになる。問い合わせが減らないのにサポートを増員し続ける組織は、問題を解決しているのではなく、問題を配給している。

サポートが多忙になる理由はたいてい一つではない。UIがわかりにくい、期待値の設定が不十分、オンボーディングが曖昧、機能が過剰に複雑、あるいはそもそも市場の理解が浅い。だから、問い合わせは厄介なノイズではなく、どこで学習が止まっているかを示す診断データだ。

速さを生むのは、開発チームではなく「入力の質」である

開発チームの生産性は、しばしば出力で測られる。何機能リリースしたか。何ポイント消化したか。何件のチケットを閉じたか。しかし、本当に効いているレバーはそこではない。開発パイプラインに入る入力の質だ。

ここで役に立つのが、工場ではなく編集部の比喩だ。優秀な編集部は、原稿を大量に受け取ってから頑張るのではない。そもそも、良い企画だけが入ってくるように、取材、企画会議、編集基準、読者理解を磨く。開発も同じで、コードを書く前に「何を作るべきか」を鋭くするほうが、後工程のコストは劇的に下がる。

そのとき中心になるのが、継続的デザインと呼べる考え方だ。これは、仕様を一度決めて終わりにする発想ではない。ユーザーが何を達成したいのかという仮説を、実装可能な形にしつつ、検証可能な粒度で保つことだ。要するに、設計は絵ではなく、学習の容器である。

たとえば「ユーザーはダッシュボードを見たい」という要求は曖昧すぎる。一方で、「初回利用から5分以内に、自分の次の行動が一目でわかる状態になる」という記述なら、設計も分析も可能になる。ここでは、成功が何かを具体的に言語化することが、実装の自由度を奪うのではなく、むしろ増やしている。

なぜなら、開発チームが本当に苦しむのは、技術的に難しいことよりも、目的が曖昧なことだからだ。目的が曖昧だと、変更はすべて正当化できてしまい、結果として技術的負債だけでなく、意味の負債まで積み上がる。どの機能も少しずつ正しく見え、全体としては誰にも刺さらない製品ができあがる。

仕様が細かいことと、成功条件が明確なことは違う。前者は開発を縛り、後者は開発を解放する。

ここでプロダクトマネージャーの仕事は、「要件を集める人」ではない。入力を編集する人だ。市場の大きな輪郭、ユーザーのジョブ、行動の障壁、支援現場からの学びを統合し、開発チームが判断できる形に翻訳する。良いPMは、要求をそのまま渡さない。意味のある仮説として渡す。

サポートはコストセンターではなく、プロダクトの観測装置である

もしサポートをコストとしてしか見ていないなら、その組織は自分の目を閉じている。サポートの現場には、ユーザーがどこで迷い、何に怒り、何を期待していたかが、加工されていない形で現れる。これはアンケートよりも、営業報告よりも、はるかに正直だ。

重要なのは、問い合わせ件数そのものではない。問い合わせの意味である。何が繰り返されているのか。どの画面で止まるのか。どの説明が誤解されるのか。誰が、いつ、なぜ助けを求めたのか。これらを追うことで、製品の摩擦地帯が見えてくる。

この視点で見ると、サポートは「火消し」ではなく「計器」になる。温度計を見て熱を下げるかどうかを考えるように、問い合わせを見て製品のどこに熱がこもっているかを考える。もし毎週同じ質問が来るなら、それは顧客が学んでいないのではない。製品が教えることに失敗しているのだ。

コンサルティングにも同じことが言える。短期的には、コンサルが顧客の成功を助けることは価値がある。しかし長期的には、コンサルがいないと使えない状態を維持してしまうと、製品は自己改善を止める。ここには危険な甘さがある。支援が売上を生み、支援の複雑さが次の支援を必要にする。すると組織は、顧客の成功よりも支援の持続可能性に最適化されてしまう。

だから、良い支援の役割は、顧客を守ることだけではない。プロダクトが本来担うべき学習責任を、プロダクト側へ返すことだ。サポートから得た情報をFAQやUI改善に戻し、問い合わせが本当に減るかを検証する。この循環が回り始めて初めて、支援は消耗戦ではなく改善装置になる。

本当に設計すべきなのは、機能ではなく「学習の流れ」だ

ここまでをつなぐと、プロダクトの成熟度を測るための別の地図が見えてくる。多くのチームは、機能の数で成熟を考える。だが本当に見るべきなのは、学習がどのくらい滑らかに流れているかだ。

私はこれを「学習ループ設計」と呼びたい。ループは大きく4つの点でできている。

ユーザーのつまずきが観測される
その意味が解釈される
製品や説明が修正される
つまずきが減ったかが確かめられる

このループが短く、正確で、責任の所在が明確なほど、組織は強い。逆に、ループが長く、部門間で断絶し、誰も観測の所有権を持たないと、製品はどんどん複雑になる。複雑になるほど支援が増え、支援が増えるほど製品改善の緊張感が薄れる。

この構造は、単なる運用の話ではない。組織が何を価値とみなしているかの問題だ。リリース数を称賛する組織は、出力を神格化する。問い合わせ削減と自己解決率を称賛する組織は、理解のしやすさを神格化する。前者は忙しさを生み、後者は余白を生む。

そして、余白こそが開発チームの創造性を支える。入力の質が高く、サポートからの学びが整理され、ユーザー成功の定義が明確であれば、エンジニアはただ修理する人ではなく、問題を構造化して解く人になれる。これは速度の問題であると同時に、尊厳の問題でもある。よい入力があるとき、開発はようやく本来の仕事に集中できる。