プロダクトは機能ではなく、調整のための装置である

Hatched by tttt

Jun 27, 2026

1 min read

4 views

87%

その問い合わせ、本当に「サポート」の仕事ですか？

顧客がサポートに連絡するたびに、私たちはついこう考えます。設定が難しかったのだろうか。FAQが足りないのだろうか。UIがわかりにくいのだろうか。もちろん、それらはすべて正しい問いです。けれど、もっと根本的な問いがあります。なぜその問題は、わざわざ人間の会話を必要とする形で現れたのか。

この問いを突き詰めると、プロダクトの見え方が変わります。プロダクトは画面や機能の集合ではありません。ユーザーが価値に到達するまでの途中にある、社内外の調整、説明、契約、導入、支援、例外処理まで含めた、ひとつの運用システムです。つまり、プロダクトの競争力は「何ができるか」だけでなく、「周辺の人たちをどれだけ滑らかに動かせるか」で決まります。

この視点に立つと、外部ステークホルダーとの調整や、コンサルティング、サポートは単なる補助業務ではなくなります。むしろそれらは、顧客体験を完成させるためのインターフェースです。製品そのものが優れていても、財務、法務、営業、マーケティング、導入支援、サポートが噛み合わなければ、顧客には「使える製品」ではなく「使いにくい事業」に見えてしまうのです。

プロダクトが壊れるのは、機能不足ではなく、接続不足である

多くのチームは、プロダクトの改善を機能追加やUI修正の問題として扱います。もちろんそれも大切です。ただ、実際には多くの失敗が、機能の欠陥よりも境界面の設計不足から起きます。顧客は製品だけを触っているのではなく、その前後にある営業資料、契約プロセス、オンボーディング、導入支援、問い合わせ窓口、成功事例、社内承認フローまでまとめて体験しています。

たとえば、ある企業向けSaaSが高性能だとします。機能は強い、速度も速い、価格も妥当です。それでも導入が進まないことがあります。理由は、法務が契約条件に難色を示し、営業が期待値を上げすぎ、導入担当が顧客の業務に合わせた説明を用意できず、サポートが同じ質問を何度も受けるからです。このとき問題になっているのは、製品の品質だけではありません。組織間の摩擦係数です。

ここで重要なのは、摩擦をなくすことが目的ではない、という点です。摩擦は完全には消せません。むしろ優れたチームは、摩擦を隠すのではなく、摩擦が発生する場所を特定して、そこに名前を付け、改善の対象にするのです。サポートへの問い合わせはその最前線です。問い合わせは迷惑な雑音ではなく、プロダクトがユーザーの現実と接触した瞬間に発生する、最も純度の高い観測データです。

問い合わせはコストではない。設計の欠陥が、言葉として現れたものだ。

この見方を持つと、サポートの役割は劇的に変わります。単に問題をさばく機能ではなく、ユーザーがどこで詰まるのかを可視化するセンサーになるのです。

コンサルティングとサポートは、製品の外側にあるのではない

よくある誤解は、コンサルティングやサポートを「製品を使うための周辺サービス」とみなすことです。けれど実際には、これらは製品体験そのものを構成しています。高級家具の組み立てを例に取るとわかりやすいでしょう。家に置かれた完成品だけが商品ではありません。説明書のわかりやすさ、配送の丁寧さ、必要なら組み立てを支援する人の存在まで含めて、顧客は価値を感じます。

エンタープライズソフトも同じです。機能が存在していても、導入支援がなければ組織に定着しない。逆に言えば、導入支援がうまく機能するなら、製品の価値は何倍にも増幅されます。ここでのコンサルティングは、単に「人手を足すこと」ではありません。顧客が成功するための前提条件を整えることです。

ただし、ここには危険な罠があります。サポートやコンサルティングが、製品の未完成さを埋めるための恒常的な補修作業になってしまうことです。こうなると、支援部門は成果を出しているように見えます。問い合わせは処理され、導入は進み、顧客は一応使える。しかし、製品改善の圧力は弱まります。なぜなら、問題は人間の努力で吸収されてしまうからです。

この状態は一見すると健全です。実際には、かなり危険です。なぜなら、サポートがうまくいきすぎると、製品の根本課題が見えなくなるからです。顧客は本来サポートに連絡したくありません。連絡する時点で、製品体験はすでにどこかで失敗しているのです。

したがって、良いサポートとは、問題を抱え込むことではなく、問題を製品へ返送することです。サポート担当が顧客の怒りをなだめるだけでなく、「何が伝わらなかったのか」「どこで期待が崩れたのか」「どの説明が不十分だったのか」を記録し、再発防止へつなぐ必要があります。

優れたPMは、機能ではなく「学習ループ」を設計する

ここでプロダクトマネージャーの役割が明確になります。優れたPMは、すべての問題を直接解決する人ではありません。むしろ、組織が学習し続けるための接続面を設計する人です。サポート、コンサルティング、営業、法務、財務、マーケティング、開発が、それぞれ独立した最適化をするのではなく、ひとつの顧客体験を共有できるようにする。そのための構造を作るのがPMの仕事です。

ここで役立つ考え方が、プロダクトを三層で見るフレームです。

コア体験: ユーザーが直接触る機能やUI
実装体験: 導入、契約、設定、運用、サポート
学習体験: 問い合わせ、失注理由、利用ログ、顧客の文脈から学ぶ仕組み

多くのチームは、第一層に集中しすぎます。しかし競争力を決めるのは、第三層です。なぜなら、プロダクトが成熟するほど、差は機能そのものよりも、学習の速度に現れるからです。誰がどの理由でつまずいたのかを早く知り、それを製品、文書、オペレーションへ反映できる組織は強い。

この意味で、ビジネスモデルキャンバス、OKR、チーム憲章、製品パイプラインのようなツールは単なる管理帳票ではありません。これらは、組織に「私たちは今、何を良しとしているのか」を共有させるための言語です。とくに外部ステークホルダーが多い環境では、同じ言葉を持たない組織同士をつなぐ翻訳機として機能します。

たとえば、営業は売上を見ます。法務はリスクを見ます。サポートは詰まりを見ます。開発は実装コストを見ます。PMの仕事は、これらの視点を消すことではなく、ひとつの顧客成果に向けて整列させることです。各部門が異なる指標を見ていてもよい。ただし、最終的に同じ顧客価値へ向かっている必要があります。

プロダクトマネジメントとは、意思決定の仕事である前に、意味を整列させる仕事である。

「問い合わせを減らす」より大事なのは、問い合わせが不要になること

ここには、よくある目標設定の落とし穴があります。サポート問い合わせを減らそう、という目標は一見正しい。しかし、そのままだと、ただ件数を抑えるゲームになりかねません。大切なのは、問い合わせを減らすことではなく、問い合わせしなくても済む体験へ変えることです。

たとえば、ある機能について問い合わせが多いとします。表面的には、FAQを増やせばよいように見えます。しかし本質的な問題は、機能の概念モデルがユーザーの心的モデルとずれていることかもしれません。あるいは、初回設定の順序が現場の業務フローと合っていないのかもしれません。あるいは、営業が「すぐ使える」と言ったのに、実際には準備が必要だったのかもしれません。

このとき必要なのは、応急処置ではなく、原因の階層を見極めることです。私はこれを症状層、説明層、構造層の三層で考えると理解しやすいと思います。

症状層: 顧客が困っている事象そのもの。ログインできない、設定できない、使い方がわからない
説明層: その困りごとが生まれた説明の不一致。案内不足、用語の曖昧さ、期待値のズレ
構造層: そもそもの製品設計、業務設計、導入設計の問題

多くの組織は症状層で止まります。優れた組織は説明層まで行きます。強い組織は構造層に触れます。ここに到達すると、サポートのインシデントは単なる問題報告ではなく、製品ロードマップの入力になります。

この考え方は、外部ステークホルダーとの調整にもそのまま使えます。財務や法務とのやり取りが面倒なのは、相手が厄介だからではありません。顧客価値、収益、リスク、運用負荷という異なる構造層の論理が、ひとつの意思決定に同居しているからです。だからこそ、チーム憲章やOKRのような共通フレームが必要になります。バラバラの会話を、ひとつの整列された議論に変えるためです。

Key Takeaways

サポートは後処理ではなく、観測装置である
問い合わせは面倒なノイズではなく、プロダクトのどこで意味が壊れたかを示す信号です。
顧客体験は製品画面の外まで続いている
導入支援、契約、説明、運用、問い合わせ対応まで含めて、ひとつの体験として設計する必要があります。
PMの重要な仕事は、部門間の意味を整列させること
営業、法務、財務、サポート、開発が別の指標を見ていても、同じ顧客成果へ向かう構造を作ることが重要です。
問い合わせ削減の本当の目的は、問い合わせ不要の体験を作ること
FAQの追加で終わらせず、症状層、説明層、構造層のどこに原因があるかを見極めて改善しましょう。
外部ステークホルダーとの調整は、スピードを落とすためではなく、学習を速くするためにある
調整の質が高いほど、組織は早く正確に学び、製品改善の精度が上がります。

プロダクトは「作るもの」ではなく「整えるもの」

私たちはしばしば、プロダクトを何かを生み出す装置として捉えます。新機能を出す、売上を伸ばす、ユーザーを増やす。もちろんそれは間違っていません。けれど、より本質的には、プロダクトとは価値が人間の組織を通って顧客に届くまでの流れを整える装置です。

この視点に立つと、良いプロダクトマネジメントとは、機能を積み上げることではなく、接点を設計し、摩擦を見つけ、学習を循環させることだとわかります。サポートは顧客の不満処理ではなく、設計の鏡です。コンサルティングは外注ではなく、成功の補助線です。外部ステークホルダーとの調整は雑務ではなく、価値が失われずに流れるための配管工事です。

だから次に、誰かが「サポートが増えて大変だ」と言ったとき、少しだけ問いを変えてみてください。大変なのは本当にサポートでしょうか。それとも、製品がまだ組織全体を通して滑らかに流れるようにはできていないのでしょうか。

この問いを持ち続ける限り、プロダクトは単なる機能の集まりでは終わりません。顧客が成功するために、組織が何を学び、何を揃え、何を手放すべきかを教えてくれる、最も鋭い知的装置になります。