本記事は、Rich Mironov 氏の The Slippery Slope of Sales-Led Development（2018-11-02）の日本語訳です。直訳ではなく、論点と口調が残るようにAIで意訳しています。公式訳ではありません。誤訳・ニュアンスのずれがあれば訳者の責任です。著者からAIで意訳すること含めて許可もいただいています。
www.mironov.com
著者について
Rich Mironov は、シリコンバレーで長年プロダクトマネジメントに携わってきたコンサルタント、著述家、講演者です。スタートアップ 6 社で「プロダクト側の人」を務め、CEO や CPO / VP Product も経験しています。15 社では暫定の VP Products / CPO として入り、220 社以上のテック企業と Head of Product を支援してきました。
専門は、プロダクト組織の作り方、スケール時のポートフォリオ、そして 「作れるもの」と「市場が金を払うもの」 を揃えることです。ブログ Product Bytes は 2000 年代初頭から続いており、プロダクトマネージャ向けのコミュニティ Product Camp の創設者でもあります。著書に The Art of Product Management と Money Stories があります。Yale で物理学の学士、Stanford で MBA を取得しています。
訳者まえがき
開発の優先度が営業の個別案件に飲まれていく話を聞いたことがあります。日本のB2B/エンタープライズ寄りのプロダクトでも、「この機能があれば受注できる」から作り始める話は珍しくないと思います。その1回は善意でも、積み重なるとプロダクトが少しづつ歪んでいきます。
この記事は2018年の記事になりますが、普遍的なB2Bのプロダクト経済を見事に表現しており、とても価値のある内容だと考えています。
本文
プロダクト企業のロードマップには、たいてい「特定の1社のためだけ」の項目がいくつか入っている。私はこれを 個別開発 と呼んでいる。
ただし B2B／エンタープライズ企業では、いつの間にか 仕事の大半が個別顧客向け になる「セールス主導開発」に落ち込みやすい。その結果、コアプロダクトからイノベーション、新機能、品質改善、技術的な耐性が奪われる。
どうやってここに来たのか自分でもわからない会社、まだ問題だと気づいていない会社を、私は何十社も見てきた。この記事では、最初は善意だった選択が、段階を踏んで「既存プロダクトを良くする余裕も、新規顧客を取る余裕もない」まで滑り落ちる過程を追う。
行き着く先は、フラストレーション、魅力のないプロダクト、利益率の低下、事業を伸ばせない状態だ。直すには、プロダクトマネジメントが経営層に「一つひとつの判断の累積効果」を見せて、組織として手を打てるようにする必要がある。では中身に入ろう。
まず、私が大事にしている区別がある。プロダクト企業と受託（プロフェッショナルサービス）企業 だ。
プロダクト企業 は、パッケージ化された標準プロダクトを作り、ほとんどカスタムなしで何度も多くの顧客に売る。だから、1件あたりの売価を「作るコスト」よりかなり安くできる。焦点は損益分岐の件数を超えること。それを超えたあとの追加販売は、粗利 90% 超になる。（たとえば、年 5 万ドルのエンタープライズライセンスを提供するのに年 800 万ドルかけても、損益分岐の 160 社を超えれば成り立つ。）手間のかかるオンボーディングやカスタムは、設計で消そうとする。古いバージョンを何本も抱えたりしない。
受託企業 は、顧客ごとのプロジェクトを請け、案件単位で利益が出るように値付けする。原価プラス 50%、70%、100% といった具合だ。成功の鍵は、見積もり精度と、技術チームが暇にならないこと。顧客が「特別なこと」「違うこと」を欲しがるほど 儲かる。工数で請求し、追加変更で伸びるからだ。顧客ごとに固有のソフトが渡り、その固有部分の保守コストも顧客が払う。受託企業は再利用可能なプロダクトを作り始めはするが、完成までいくことは少ない。目先の利益が出るカスタム案件に、プロダクトチームを何度も引き抜くからだ。
つまり私の見立てでは、プロダクト企業は標準プロダクトを出荷し、同じものを何度も売ることで勝つ。受託企業はカスタム案件を取り、開発者の時間にマージンを乗せて勝つ。ところが営業主導のエンタープライズ・ソフトウェア企業は、よく中途半端な混合モデルに踏み外す。半カスタムの仕事に、プロダクトとしては安すぎる値段をつけ、開発チームをどんどん食いつぶし、ついには新規顧客を支えられなくなる。個別開発の工数はライセンス売上から出しているので、損益分岐にも届かない。
これは少しずつ、気づかれないまま起きる。一見小さな個別開発の約束が、ロードマップとエンジニアリング優先度に積み重なる。もっときつい言い方をすれば、営業のための個別開発はコカインだ。気持ちよく、習慣になり、しかも「これが特別対応の最後だ」という、かろうじてそれっぽい言い訳を毎回生み出す。
根っこにあるのはプロダクトの経済学であり、セールス主導のプロダクト企業がスケールできないことだ。表面的には「プロダクト対営業」の争いのように語られがちだが。
大きな話なので、段階に分ける。
- プロダクト／エンジニアリングが、ロードマップのトレードオフをどう決めるか
- 「ほんの小さなものが必要な、特別なエンタープライズ案件」の一回分
- 顧客横断・四半期横断で積み上がる影響
- では何をするか
[1] プロダクト主導のロードマップと、投資ポートフォリオの配分
良いプロダクトマネージャは知っている。貴重な開発チームを、新機能だけ、品質だけ、見た目のデザインだけ、技術的負債の返済だけ、に全振りしてはいけない。プロダクトを健康に保つには、カテゴリごとの混ぜ方が要る。
プロダクト／マーケットフィットが見えたあとの、技術投資ポートフォリオはだいたいこうなる。
- 半分は、顧客から見える新機能、使いやすさ、競合対応など、ユーザー／顧客が直接求めるもの
- 四分の一は、コアの基盤といわゆる「〜リティ」。可用性、拡張性、セキュリティ、規制対応。顧客はできていて当然と思い、失敗したときだけ聞く（ブラックフライデーにカートが落ちる、など）
- 残り四分の一弱は、バグ修正、テスト自動化、DevOps、技術的負債の返済など、開発プロセスを回し続ける支え
- さらに 10% 以上は、顧客インタビュー、プロダクト／市場検証、Jobs To Be Done、プロトタイプ、ユーザー課題と解の深い理解に使う。このスライスの中にイノベーションが隠れている。それっぽいアイデアをたくさん考え、試し、捨てる時間を取らなければいけない。勝者を決めていきなり本開発に入る、では足りない
これ全部を 100% に収めるだけでも、すでにきつい。（円グラフの良いところは、あるスライスを大きくしたら別のスライスが小さくなることだ。都合のいい妄想 を減らせる。）
しかもどのスライスにも、もっとよこせと言う利害関係者がいる。
- マーケと営業は、継続と新規を稼ぐキラキラ機能が欲しい。今四半期は見える改善に 100% 使って、来四半期にバランスを戻せばいい、と言う。（戻らない。）
- エンジニアリングは技術リスクと基盤の不足を現場で見ているので、アーキテクチャ、ツール、リファクタにもっと投資しろと押す。
- サポートは、バグをもっと直せ、オンボーディングと使いやすさを上げろ、テスト自動化で手前で捕まえろ、とロビーする。
- 経営層はもっとイノベーティブであれと言う。ただし「曖昧な思いつきを、検証済みで開発する価値のある設計にする地味な仕事」と結びつけて考えていないことが多い。イノベーションを、実験と市場に根ざした継続プロセスへの投資ではなく、態度やイベントとして語りがちだ。
だから どの利害関係者も満足させられない。やる価値のある改善バックログは、無限に深いからだ。
私たちは善悪を仕分けているというより、「今四半期の改善トップ5に入ったほど良いもの」と「顧客向けとして筋はいいが、トップ5を押し出せなかった他の16個」を分けている。サポートには、P1 と印をつけた 37 件から 6〜8 件を選んでもらう。アーキテクトとは、前回レトロで何十個も出た基盤投資のうち、価値の高い数件を交渉する。そして種類の違う仕事を、一本の優先バックログに編み込む。機会はあり余っている。資源はいつも足りない。
だからプロダクトマネージャはつらい選択をし、お気に入りの大半をぼんやりした未来に残す。そのうえで、直近の計画を経営層に「売り込む」。（これを 90 日ロードマップと呼んでもいい。）エンジニアリング容量については、たいてい少し楽観する。最後の1件を落とすのが忍びないからだ。全部終わる確率は 70% くらいかもしれない。エンジニアリングと組んで、不確実性と変更に備えた余裕は入れる。ただし、経営からの飛び込み依頼のための空きではない。
整理すると:
- 健全な開発計画は、見える改善、基盤、開発自動化、技術的負債の返済、誠実な検証、が混ざる。新機能だけに投資するのは、砂糖たっぷりのジャンク食だ。プロダクトはすぐ不安定になり、アーキテクチャは虫歯になる。
- 空き枠も、未割り当ての工数もない。「もう1件」を滑り込ませる隙間はない。魅力的な候補の長いリストから少数の勝者を選び、お気に入りの多くは後回し（あるいは永遠に後回し）にした。市場／設計／技術の検証には今投資して、後の価値ある仕事を並べている。
- 選ぶ対象は、だいたい広い顧客層向けだ。売上総量を伸ばし、解約を下げ、平均的なユーザーの喜びを増やす機能・UX・基盤。1社だけの要望が通ることはめったにない。
四半期のバランスの取れた計画を並べて、達成感はあるかもしれない。だが実際は、こうは進まない。エンタープライズの優先度ゲームは、ここから始まるからだ。経営合意の数日後、エンタープライズ営業の誰かが一件を上げてくる。
[2] エンタープライズ案件のエスカレーションを1件追う
ソフトウェアの顧客はたいてい、「足してほしい／変えてほしい／作り直してほしい」リストを持っている。コンシューマや中小向けなら顧客は数千〜数百万で、ロードマップ変更を要求できるほど払っている顧客はいない。広く効く改善を探し、対象顧客全体の採用・アップセル・解約低下を狙う。子どもの頃のヒーローの言葉を借りれば、「多数のニーズは、少数のニーズに勝る。あるいは『一人』のニーズに勝る。」
エンタープライズ顧客は大きく、数が少なく、経営層は名前を知っている。売上の 1%、2%、4% を占める先もある。そして エンタープライズ顧客は、ロードマップを交渉の起点と見る。計画どおりの大半は出る前提で、自分たちの買い物リストのうち、こちらが意図して外したものも拾いに来る。よくあるのは、自社レガシーとのデータ連携、業務固有のワークフロー変更、サードパーティ帳票、マイナーなテスト基盤対応。
そして何より、大口顧客にはエンタープライズ営業を付けている。彼らが採用され、訓練され、報酬を受け、昇進する理由は、次のような必須スキルだ。
- 粘り、楽観、人間関係を作る力
- 狭い アカウント焦点: 1社（またはごく少数）を満足させ、買い続け、更新させ続けることで報酬を得る
- 説得力のあるポジショニング: 自社の方が競合や代替より顧客ニーズに合う、と語れる。RFP の土俵を自社有利に組み替える、など
- 顧客組織の中にチャンピオンを見つけ、味方・支持者へ判断を上げ替え、経路を変える
- 成功基準が極端に明確: 「クローズした」チームはハワイのプレジデンツクラブへ。できなかったチームは切られる。
（正直に言うと、私は売るのが下手だ。自分にできないことをやる営業を、深く尊敬している。顧客を丁寧に扱い、不完全なプロダクトを創意で売り、売上を持ち帰り、それで称賛される。）
だから大口顧客が計画にないものを求めると、営業は真面目にプロダクトマネジメントへ「作ってくれ」と来る。返ってくるのはほぼ必ず「No」か「何四半期か先かも。バックログに入れておく」であって、彼らが欲しかった「もちろん、いいね、すぐやる」ではない。多くのプロダクトマネージャは、ここで話が終わったと思う。
だが私たちは、粘り強く、説得力があり、組織の中に味方を見つける人を、高い報酬で雇っている。その同じスキルが社内に向いたとき、なぜか驚く。営業はキー顧客の要望を、営業幹部経由で CEO や経営委員会まで巧みに上げる。経営層が聞く話は、決まってこうなる。
- この顧客は最大級、あるいは戦略的だ。この機能がないと案件が閉まらず、売上目標に届かない。
- 今回の要望は簡単だ。たぶん コード10行。
- 顧客は必要なものを正確に分かっていて、仕様も正しい。
- エンジニアリングはアジャイルだから、来週のスプリントに滑り込める。
- これは1社の要望ではなく市場の需要だ。彼らが話す相手はみんな同じものを求めている。本来もうやっていないとおかしい。
どれももっともらしく、私たちは 本当であってほしい と思う。そして 巨大顧客1社に全時間を使っている エンタープライズ営業の視点では、社内を動かすのに十分な「真実」でもある。
その下に通っている前提は、エンジニアリングに余剰がある、というものだ。この改修が必要だから、資源と枠があるはずだ。戦略顧客なのだから、なんとかしろ。アカウント単位の売上計画が、市場単位のプロダクト計画に勝つ。（言い換えると、私たちはエンタープライズ営業に、プロダクト計画を内側から崩すことを報酬として払っている。）
エスカレーションでは営業の方が、プロダクトマネージャの応答より上手くて速い。経営会議室の議論は一方的になりやすい。降りてくるのは「なんとかしてやれ」かもしれない。プロダクト側は反論の機会を逃す。しかもその反論は、泣き言や防御に聞こえがちだ。
- 本当に、空き資源も余り枠も余剰能力もない
- すでに並んでいる X か Y を延期するか、落とすしかない
- 顧客は私たちのアーキテクチャを理解していない（あるいは悪い解を出している）。技術ミーティングとニーズ分析からやり直す必要がある。第一感では大きな仕事だ
- 顧客基盤全体の市場ニーズなら、私たちは知っている。リストの上位に置いていたはずだ（経営もレビュー済み）。この件は他ではほとんど使えないので、すでに落としている
- この顧客の要望は以前も押し返してきた。短命な要求を何度も出してきたが、契約は結ばれた。プロダクト側から見ると、本当に勝負を分ける項目なのか、忠誠心の試しなのか、はっきりしない
ただ、たまにしか起きないことなので、ぶつぶつ言いながら、なんとかねじ込む。心のどこかでは、今の計画への影響は小さいと思いたい。
たいてい、要望は人手を渡りすぎていて、問題の記述ではなく部分解として届く。（「この帳票を足せ、この画面を変えろ、エクスポート API を伸ばせ、DB に列を2つ足せ。」）それで顧客の問題が解けるのか分からず、却下された代替案の文脈もない。すでに設計・実装・テストに入っている人を引き剥がしたくもない。
だから代わりに、先を見ているシニアのデザイン・開発・プロダクトを中断させる。顧客の技術チームと直接話して状況を確認し、選択肢を探す。予定していた市場検証とデザイン思考の時間を削って、最小工数で実装する。
技術投資ポートフォリオは、少しずれる。うまくいけば、1回なら大惨事ではない。ただし予定していた検証・設計・アーキテクチャから、時間を借りている（盗んでいる）。
うまくいくこともある。（プロダクトもシニア開発者も、営業と同じくらい楽観できる。）だが普通は、つまずき、驚き、深刻な問題が出る。新しいワークフローには新しいデータ項目と入力経路が要る。サードパーティ帳票にはサポートされた API がない。顧客のレガシーにはセキュリティ穴や性能のボトルネックがある。小さな UI 変更が、丹念に作った UX を濁す。約束の日までに出すため、技術的負債の多い回避策に大きく工数を使う。
実際の影響は、こうなる。
一番手の人（あるいは、予定作業へのコミットが一番弱い人）をここに載せた結果、進行中の検証と先を見る設計は一時的に全部押しのけられる。だが大口顧客への約束は守り、今四半期の売上は支えられた。経営は喜び、営業はハワイの夕日を Instagram に載せる。惨事は回避された。プロダクト、デザイン、エンジニアリングは短いドラマのヒーローになり、予定の仕事に戻る。
ただし——
[3] セールス主導の振る舞いが定着する
この小さな火事場対応は、良い結果になった。経営も、その1チームのエンタープライズ営業も報われた。実際、リーダーシップはこう学ぶかもしれない。「エンジニアリングとプロダクトは、あれだけ反対しても個別開発をねじ込める」（ひどいことにはならなかった）。他の、賢くて粘り強くて社内に太い線を持つ営業は、すぐ気づく。大口を閉じるための、とても良い道具だ、と。
新しい振る舞いが定着した。 1アカウントのエスカレーションに報酬を出した。
大型案件の要件は、組織図を高速で上がる。約束 は営業組織の中で増え、納期まで含む。経営は、事前承認済みプロジェクトのリストをプロダクトマネージャに渡す。既成事実だ。市場起点の検証と分析から、アカウント起点 の意思決定へ移る。大型案件には、どれも「特別な1つ」が付くのが常態になる。
制御不能になるか？ なる。私は、個別顧客プロジェクトが開発予算全体の 30% 超を食っているエンタープライズ企業を、20社は見てきた。
これは少しずつ、広い顧客向けの見える機能、「〜リティ」、支えの基盤を押し出す。
兆候:
- プロダクトマネージャは挫折し、沈む。プロダクト計画が減り、プロジェクト管理が増える。入ってくる約束は特定の戦略にもアーキテクチャにも乗らないので、プロダクトの一貫性はだんだん失われる。対象顧客と Jobs To Be Done は、狭い機能のリストに取って代わられる。
- 開発チームは挫折し、引きこもる。問題／解を考えるのではなく、顧客が設計したプロジェクトを実装させられる。ポジティブなユーザーフィードバックは少なく、自分たちのプロダクトを愛せなくなる。
- デザイナーは静かに「良いデザイン」を諦め、特定顧客を喜ばせるために画面を少しずつ変え、全体 UX の主導権を失う。使いやすさは落ちる。
- 営業も（再び）イライラする。顧客の個別開発への食欲は底なしだと気づくからだ。開発キューは指名顧客の約束で埋まり、次の要望を入れる枠が（また）ない。新規顧客の立ち上げは遅れ、自分専用プロジェクト待ちになる。
- CFO は利益率の低下を見る。半カスタムをプロダクト価格で売っているので、個別開発のコストを回収できていない。新規アカウント（それぞれ特別要望つき）は、いまの約束の後ろに並び、売上成長は鈍る。
- 経営は、新規アカウントの売上が落ちることに苛立つ。ワクワクする改善が押し出され、競合が追いつく。イノベーションとカルチャーの話は増える。
愉快な状況ではない。しかも「個人の失敗」「やる気不足」として読み替えられ、部門間の非難が起きやすい。（「プロダクトがもっと聞けば…」「開発が週末を使って追いつければ…」「営業が今あるものを売れば…」）
違う。これは組織のシステム問題だ。個別顧客の要望に先に投資することで、広い市場向けにプロダクトを計画し、設計する能力を手放している。 カスタム案件をライセンスモデルの中に隠している。成功を内側から崩すことに給料を払っている。本当の価値に、市場価格を取れていない。
では何をするか
これは難しい問題で、プロダクトマネージャ個人（開発、デザイン、営業も同じ）では解けない。経営チームの仕事であり、まずい薬も含む。
1. パターンを認め、これが問題かどうかを決める。
- 直近の勝ち案件だけでなく、全体を経営として正直に見る。利益を出して伸ばせるか。営業をどうインセンティブしているか。新規顧客を立ち上げて本番に乗せるのに何が要るか。会社のボトルネックはどこか。
- データを取る。プロダクトマネジメントに、直近数四半期を振り返らせ、最近の開発のうち個別開発がどれだけかを表にする。（確認質問: 出荷したもののうち、四半期初の計画になかったものは？ 一般に使われると予測したのに、1〜2社しか使っていないものは？ 「いつもやる」と言っている検証ステップを飛ばしたプロジェクトは？ そのために取ろうとした案件は、実際に取れたか？）
2. 自社は受託企業なのか、プロダクト企業なのかを決める。
- 半々、どっちつかず、「うちの市場は違う」は通らない。やるかやらないか。Yes か No。黒か白。プロダクトか受託か。私の観察では、プロダクト企業はセールス主導 15% ならうまく両立でき、20% でかなり苦しく、30% で路肩を外れる。
3. 受託企業なら、受託企業として振る舞え。そして値を上げろ。
- 個別顧客に優先度を決めさせるなら、案件ごとにフルの価値を取れ。（「戦略アカウント」はない。あるのは儲かる顧客だけ。タダ働きは、次のタダ働きを教える。） 競合の受託と比べ、チームの時間に相応のマージンを乗せる。
- パッケージを補完したいプロダクト企業と組め。
- 必要なら、案件の質を上げる基盤とツールを作る少人数の常設チームを置く（案件に引き抜かない）。
4. ソフトウェアのプロダクト企業なら、対立を「説明して消す」のではなく、管理する。
- プロダクト企業の利益と成功は、ユーザー基盤を伸ばし、年々更新してもらうことから来る と認める。ライセンス売上は、追加料金なしで出す改善の定常流を賄い、買い手をキラキラした競合へ逃がさないためのものだ。個別案件だけでなく、事業全体のパターンを見る。
- 営業のための個別開発全体に、エンジニアリング工数の 絶対予算（10% 未満）を決め、経営レベルで守る。営業 VP に、四半期あたり小さな案件を1〜2件選ぶ権限を渡す。たとえば開発 2 人週まで。サイズと成立性はプロダクト／エンジニアリングが確認する。営業 VP は全社売上を最大化したいので、会社とアカウントのインセンティブが揃う。そのうえで、エスカレーションはプロダクトから営業へ戻して裁定させる。
- 報酬制度を、望ましい振る舞いに合わせる。標準プロダクトはノルマ算入 100%。個別開発は実コストに対して 20%（あるいは マイナス 50% でもいい）。私たちは営業が好きだ。だが彼らは、私たちが 望む ことではなく、払う ことに応じて動く。
- 開発は本当に有限だと認める。新しいものを押せば、計画から何が落ちるかを聞く。エンジニアリングとプロダクトのリーダーは、プロダクトの長期健康を心配している。トレードオフの一部は、何四半期、何年も経ってから見える。
- 受託の仕事（人と予算も）を、コアプロダクトの仕事から分ける。カスタム案件はコストの 3 倍を返せ、と強制する。「現場で作ったソフト」と、保守できるプロダクトを混同しない。
- さらに良いのは、社外の受託パートナーを入れる こと。ライセンス売上は社内に残し、カスタムは市場価格を取る会社へ渡す。パートナーが個別開発をもっと吸収できるよう、コアプロダクト側を改善する。
- エンジニアリングとプロダクトに、カスタムが要らなくなるアーキテクチャ改善を任せる。文書化された帳票インタフェース、意図して設計したホワイトラベル、セキュリティ標準との統合、商用 DevOps ツールへのフック。カスタムを外に出す道を作る。
- 「みんな欲しい」という経営・営業の議論に、プロダクトマネージャが広く押し返せるようにする。代わりに、需要（これから出す機能）と採用（出した機能）の市場指標を求める。議論を出荷日ではなく利用へ移す。重要でないものを予定どおり大量に出す機能工場チームには、健全な懐疑を持つ。
- いまの顧客を、いまのプロダクトバージョンへ移す方法を探す。本人（や営業）がどれだけ抵抗しても。3本（あるいは 6 本）の旧バージョンを支えていたら、明らかな改善もイノベーションも残らない。1世代前はサポート料金を倍、2世代前は4倍にする。
- 進行中の個別開発、顧客への未履行約束、その代わりに 具体的に 何を先送りしたかを、毎月経営に報告する。計画内の改善を待っている顧客の名と、その更新売上を出す。特別対応の見え方を上げ、中断のコストと頻度を目立たせる。
高い注文で、気の弱い人向きではない。だがアカウント単位の機能要求が、エンタープライズ／B2B 企業を何社も不自由にするのを、私は見てきた。仕事に取りかかろう。
一言で
どのエンタープライズ企業も、個別顧客の要望はいくらか叶える。だが個別開発が「振りかけ」を超えると高くつき、腐食し、成長と利益を削る。リーダーは広いパターンを見て、累積の影響に、システムとして手を打つ必要がある。
