この記事はAIによって機能開発のスピードは速くなっているにもかかわらず、収益が伸び悩んでいるプロダクトチームに向けて、収益が伸び悩む構造を解説します。

生成AIが登場するまでエンジニアは手作業でコードを書いていた。手作業でコードを書くのは時間がかかっていた。生成AIによって早くなった。ところがプロダクトチームで機能開発による収益は伸びていない。これはなぜか?

もともと手作業でコードを書く速度よりも、解決したらお金を払ってもいい顧客を特定することのほうが遅いからだ。

AIで機能開発は早くなっても収益への貢献は期待ほど伸びない。機能追加されても顧客は無関心なままだ。

※世の中には様々なプロダクトがあるが、この記事では収益が停滞する構造を分かりやすくするために、BtoB向けの顧客の問題を解決するソフトウェアプロダクトで解説する。他のケースでも該当する。

この記事では以下を解説する
・「解決したらお金を払ってもいい顧客」とは何か
・「解決したらお金を払ってもいい顧客を特定する」とは何か
・ソフトウェア開発はますます改善され続けている
・顧客の特定の質は停滞している
・なぜ顧客の特定ではなく、機能開発に関心が集まるのか
・顧客が解決してもらいたくない問題に取り組みすぎる
・企業に価値があっても担当者には価値がない

｢解決したらお金を払ってもいい顧客｣とは何か

収益は成立された取引からもたらされる。良好な取引が増えるほど収益は伸びる。では、どのような状況だと取引が成立しやすいのだろうか。

チームは顧客にとって重要な問題を見つけ出そうと努力しているだろう。ところが問題は大切だが、それだけでは足りない。その問題を持つ人にどれくらい接触できるかが収益を左右する。

取引を成立するという状況を成立するためには、下記の5つの条件を高水準で満たせる顧客に接触する必要がある。

1.困っている
2.解決するために使える予算を持っている
3.現在の方法や他社のプロダクトに強い不満がある
4.新しいプロダクトを探している
5.今買う必要がある/購入に締め切りがある

これら5つの条件をすべて満たす顧客は、プロダクトチームが想像するよりも限られている。並んでいるPRD、バックログアイテムは5条件をどれくらいの水準で満たしているだろうか。顧客課題やユーザーニーズと呼ばれるものは、このうち1～2しか満たせていない。それにも関わらず、開発を始めてしまう。

「私たちはどのような問題を解くべきか?私たちはどれくらいその問題をうまく解けるか?」これがうまくいっても、取引を持ちかけられる顧客がいなければ収益に結びつかない。顧客にニーズがあるかどうかだけでなく、買う顧客と出会える確率を高める活動をしなければならない。

「解決したらお金を払ってもいい顧客を特定する」とは何か

5つの条件を満たす顧客を特定するために、市場において顧客を開拓するという活動を行う。顧客を特定し、ユーザーインタビューなどを通して仮説を構築し、プロダクト開発をする。

ところが少なくないプロダクトチームは顧客を特定するという最初の時点で、そこそこで満足してしまう。顧客を特定すること…言い換えると、顧客の絞り込みである。顧客の絞り込みは恐怖である。絞るほど顧客総量は減るように見え、もたらされる収益も消えていくように感じるからだ。

しかし、絞り込んでいない顧客リストは皮算用である。ほとんどのチームは絞り込みが足りない。

インタビュー前の顧客の特定の時点で、下記条件を満たす必要がある。これらの条件は顧客との距離から事業の経済性を検証するものである。顧客獲得コストをより具体的に表現したものと理解してもらってもかまわない。

1.顧客として特定できる
　1.1.顧客が困っていることは何か
　1.2.顧客が困っているときに何をしているか
　1.3.顧客が困っていることに顧客はいくら支払っているか
　1.4.顧客はどれくらいの頻度で困っているのか

2.顧客とコンタクトが容易にできる
　2.1.コンタクトチャネルの特定が容易
　2.2.コンタクト頻度が高い
　2.3.コンタクトコストが安い

3.顧客との取引可能性の高さ
　3.1.解決行動の発生頻度が多い
　3.2.解決行動の総ボリュームが多い
　3.3.解決行動のタイミングで顧客に接触するためのチャネルの特定が容易
　3.4.解決行動のタイミングで顧客に接触するためのコストが安い
　3.5.解決行動のタイミングで顧客に接触できる頻度が高い

これらの条件に合致しない顧客に、ユーザーインタビューをしたりプロダクトを開発したとしても、1顧客当たりとの取引成立のための経済条件が悪く、収益が伸びない。顧客が高い価格を払っても良いという条件を軽視して、開発の着手を急ぎすぎると、生成AIを利用しても収益性の伸びの悪さに苦労することになる。

顧客リストは思い切り絞り込むことから始めよう。絞り込みに合わせてPRDもバックログもシャープにしよう。

しかし、これらよりもより深刻な問題がある。質的な問題である。

ソフトウェア開発の質は改善され続けている

ソフトウェア開発は常に改善され続けている。仕事の仕方と環境の質は高まり続けている。

日本では2009年からスクラムが普及し始め、チームで仕事をするスキルが急速に普及した。たとえばペアプロ、モブワークといったコミュニケーション頻度が著しく増え、フィードバックサイクルが大きく縮み、学習が進むようになった。

チームでの仕事の影響を実際に理解している人は少ない。チームでの仕事とは分担や分業ではない。以前は「仕事ができなくてもその人のせい」「不得意なことは無理せず、得意なことすればいい」だったが、チームでの仕事を高水準に実現していると、仕事ができない人が急速にスキルを身につけることが当たり前になる。

一週間の中で計画、開発、リリース可能にする、改善を行えるようになった。CI/CD、Git、slackなど開発を支える技術や環境の改善も著しい。エンジニアの学習速度が異常に早くなっている。

しかし、個々で考えたいことがある。もし「機能開発が早ければ収益が伸びる」というなら、2010年代から2026年までに起きてきたソフトウェア開発の仕事環境の改善と共に自社の収益は伸び続けるはずだ。

顧客の特定の質は停滞している

ソフトウェア開発に比べて、顧客とのコミュニケーションは未だにコミュニケーション頻度も少なく、フィードバックサイクルが遅いままである。顧客リストを作り、アポイントメントを取り、数週間後に会い、なんとなくの会話を行い、顧客は持ち帰って検討をし始める…。この10年間で、開発の環境ほどには改善していない。

解決したらお金を払ってもいい顧客を特定することのフィードバックサイクルは高まっていない。「100社の現場に訪問して顧客の現場の課題を特定するということをやった」というと、いまだに「おおー!それはすごい!」となる。

こうした状況を変えるために、たとえばドメインエキスパートを雇うケースが増えている。顧客との距離を間接的に縮める試みといえる。しかしこれも簡単ではない。多くのドメインエキスパートはプロダクト開発の初心者なので、ここで軋轢が生じるケースが多々ある。

高給を支払って雇用したため、ドメインエキスパートとしての情報提供やコンテキストの提供だけでなく、プロダクト開発に貢献してもらいたいと考えてしまうが、ワークしないことが多い。ドメインエキスパートは業務の固有情報を持っており、それだけで権力に繋がりやすい。「20年やってきた人がいうのだから」となってしまう。

なぜ顧客の特定ではなく、機能開発に関心が集まるのか

そもそも、解決したらお金を払ってもいい顧客を特定することのほうが、機能開発よりも遅く、収益の向上を左右するのならば、なぜ問題視されたり解決しないのだろうか。

機能開発は分かりやすいアウトプットであり、改善しやすく、責任を取りやすく、制御しやすい。一方で、解決したらお金を払ってもいい顧客を特定することに失敗したことを容易には扱えない。

1.失敗と認めたとして、機能開発に費やしたコストは想像以上に大きい

5人が1ヶ月かけて開発し、関係部署の人にも新機能をレクチャーしたり、顧客にもアピールしたりするとしよう。人件費だけで1000万円はかかっている。この失敗を認めることは容易ではない。

2.リリースした機能の削除にも多大なコストがかかる

少数であってもユーザーがいるのであれば、何かしらの説明や補填が必要となる。また機能の削除は顧客から見て「開発がうまくいっていないのでは」という不信シグナルとなる。

「失敗から学習しよう」というスローガンは10年前から繰り返されている。では実際にどれくらいできているだろう?「1000万円かかったことを失敗と認めて学習しよう」といえる人はどれだけいるだろう?それが1億だったら?10億だったら?もし資本調達しているなら、出資者を前に言えるだろうか?リリースした機能の取りやめを出資者はどう評価するだろうか?

寝た子を起こしたくない。不都合なフィードバックサイクルは壊したいという動機がある。

3.失敗ではない正当化する方向性はたくさん思いつく

これから売れるかもしれない(希望的な予測)。少数のユーザーが使っているから価値がある(成功を程度の大きさではなく、ゼロイチにすり替える)。この機能からさらにユーザーのより深い課題を特定に役立つ(都合のよいナラティブはいくらでも作れる)。

失敗を認められない、失敗を取り下げることができない、正当化は容易にできる。これらのため、顧客の特定に従事する関係者は失敗を表にしないという共犯関係を結ぶことになる。表だって議論が難しくなる、改善することが難しくなる。

この状況下では、あたかも厚顔無恥をスキルとして身に付けなければならないプレッシャーを抱く。自分が詐欺師なのではないかというインポスター症候群に悩むことになる。

インテグリティ(一貫した誠実さ)の問題

心の中で思っていることと、会議で話していることと、実際に自分がとっている行動はどれくらい一致しているだろうか。この一致性が高いほどインテグリティ性が高いといえる。

インテグリティの高さはディスカッションの質に大きく影響する。心で思っていることと、会話や行動との間に違いがあれば、物事をよりよくしていくことは難しい。ソフトウェア開発という仕事環境は、心の中で思っていることを話しやすく、より良くするための議論がしやすい。インテグリティを発揮できる程度が職能によって大きく異なる。

そしてこれは顧客企業の担当者にも起きている。ここまでは自社内の問題だった。同じ状況が顧客企業側にもある。顧客の担当者も、心の中で思っていることと、会議で話していること、実際の行動は不一致になることがある。そしてこの不一致を明かすことは難しい。

顧客の担当者が解決してもらいたくない問題に取り組みすぎる

業務効率化プロダクトを開発しているとする。見込み顧客の該当部署は業務の煩雑さに手を焼いていて、解決すれば該当部署の収益性が大きく改善できるとしよう。ところが結局、その見込み顧客はプロダクトを購入しなかった。なぜだろうか?

1.仕事の効率化は困るし、利益が出るのも困る

そつなく今の仕事を続けたいという担当者がいる。業務改善プロダクトは、顧客担当者のこの要望に応えるどころかダメージを与える。また利益が出ると社内で目立ってしまい、期待され、面倒なことになる。そつなくやっていければいいという部署の責任者もいる。

また組織の人員数の多さは、権力に結びつく。業務改善が進みも、人員が少なくなると予算が減り、社内的立場も弱くなる。仕事が非効率であっても、人員の量を維持したいというニーズがある。

なんならプロダクト開発企業を呼び寄せて、様々な要望を出し、開発させ、トライアルをするものの、消極的にしか使わず、結果として失敗させ、「DXはうまくいかない」という失敗事例を作ることで今の仕事を守るケースもある。あるいはマイルドに少額導入してやっているふりをするケースもある。

2.利益を生み出せるとしても組織構造的に動機が弱い

いくら導入し、利益が出ても、担当者の給与には関係がないことはよくある。プロダクトを採用することで部署に利益がでても、給与テーブルや評価はガチガチなので自分の給与は変わらない。やったもの負けになっている。

たとえば1万人の企業で100人が所属部署で利益が三倍になったとしても、全体からすると大した貢献にはなっていない。一部の部署が大きく成果を伸ばしたからといって、組織統制上、その部署のメンバーに多額の給与が支払われるわけではない。

その企業の人事評価システムがダメかというとそういうわけでもない。利益を基準にしすぎると組織運営に不整合が生じる。たとえば利益をコントロールしやすい部署に配属された人が得をし、コントロールしにくい部署は損をするようになると、部署間で不和が生じる。また部署間で権力関係の差があると、立場の弱い部署に不経済を押しつけるようなことが横行してしまう。

3.担当者への保証不足

顧客担当者の「弊社のためになにをしてくれるのか?」という表だって話されやすい言葉と、言われない言葉「私のために何をしてくれるのか」がある。

自分がステークホルダーが関心を寄せる新プロダクトの広告を打ち出すとしよう。小さいながら気鋭の広告代理店と、電通や博報堂のどちらに依頼するだろうか?

多くの場合は電通や博報堂といった著名なところである。なぜなら失敗しても、「電通でもダメだったら仕方がない」と担当者責任をある程度免れるからだ。保険の役割を果たす。気鋭の広告代理店に出して失敗したら自分の責任になる。また気鋭の代理店に依頼する正当性をステークホルダーに説明し続けることになるため、膨大な説明コストがかかる。本当は気鋭の代理店のほうがいいと思いつつも、定番に依頼することになる。担当者は保険も一緒に買っている。

企業と、企業の担当者では異なる意思決定環境にいる

このように企業と、企業の担当者では異なる意思決定環境にいる。これらも問題特定の失敗と同様に、顧客の担当者は心の内を明かすことはしない。業務改善プロダクトをいくらAIで機能開発しても、顧客担当者の心の中で「改善されたら困るんだよ」となっていたら取引成立にはならない。顧客特定が難しいのはプロセスの難しさもあるが、顧客担当者側にも本音を明かさない理由がある。隠されているものにはコストがかかる。

プロダクトは、企業にとって価値はあっても、担当者にとっては価値があるとは限らない。自己犠牲をしてでも導入するかのような担当者を想定していないだろうか?英雄のような人を担当者として想定していないだろうか?

よりよいプロダクト開発には、どの顧客からフィードバックを取りいれればよりよい事業になるかという観点も必要である。自分たちのプロダクトに不適切な顧客を選び、フィードバックを真に受けてしまうとプロダクトはダメージを受けることになる。

企業に価値があっても担当者には価値がない

この数年で生産性という語はより正確に用いられるようになってきた。たとえばryuzeeさんによる『価値創造と開発生産性』では、生産性を物的生産性と付加価値生産性に分けて明確にした。

https://slide.meguro.ryuzee.com/slides/121

一方で、付加価値生産性への取り組みそのものはあまりうまくいっていないように思える。とくに今回の記事の後半の、担当者価値は薄い。これは担当者の心の内に疑いを挟むという行為であり表だって検討するテーマが難しいからだ。

インテグリティ(心の中で思っていることと、話していることと、実際に自分がとっている行動の一致)と、距離の近さとフィードバックの頻度があれば仕事の質はよくなっていく。インテグリティにギャップがあり、距離が遠くフィードバック頻度が少ないほど改善は進まない。

ソフトウェア開発は、失敗を認め、本音で話すことで質を大きく改善できるようになった。ところが、自社の中ではステークホルダーの視線を気にして本音を隠し、失敗にならないように正当化する動機がある。顧客側も、顧客企業と担当者では利害が異なり、本音を隠す。

次のアクション

ではこの状況をどのように対処するか。顧客担当者のインテグリティを検証し、その過程で自社のインテグリティを改善する方法を紹介する。顧客と高い頻度で話すことができるプロダクトチームならできるだろう。

最初の下記5条件に対して具体的なエピソードをヒアリングしていくというものである。
1.困っている
2.解決するために使える予算を持っている
3.現在の方法や他社のプロダクトに強い不満がある
4.新しいプロダクトを探している
5.今買う必要がある/購入に締め切りがある

ないものを隠すことは難しい。各要素について、何をしてきたのかの具体的なエピソードをヒアリングする。そして顧客企業全体ではなく、相対している担当者自身にとっての個人的動機を確認する。

たとえば次の趣旨の具体的なエピソードをヒアリングする。
担当者の労力「この問題のためにどのような苦労をしてきましたか?」
責任「過去に導入が失敗した時、誰が何を責められましたか?」
担当者への報酬「この問題を解決したら、あなた個人のキャリアにどう影響しますか?」
稟議「小さく成功したという証拠を、誰にどう見せると効果的ですか?」
※腹を探る質問にもなるため、聴き方には注意すること。ヒアリングの前に、安心して話せるという保険を買ってもらわなければならない。

英雄的動機が話されたのであれば注意が必要となる。話を盛っているならば取引の成立は難しいだろう。本当に英雄的な人ならば、その取引は成立しやすくはなるが、見込み顧客の標準像にはできない。

英雄的な人を見込み客の前提にしていては事業はなりたたない。これはテクノロジーライフサイクルのキャズムと類似する。英雄やイノベーターはマジョリティではない。顧客の特定やセールスのプロセスは、マジョリティと気持ちよく仕事を進められるようにしなければならない。

このヒアリングの質的なフィードバック観点は次である。
・社内、社外ともにインテグリティのギャップを評価すること
・顧客特定のフィードバックサイクル数を増やせること
・ステークホルダーから見ても、失敗から効果的に収益に繋がる学習をしていることが認められポジティブに評価されること
・顧客の担当者にとっての価値を検証できること

顧客と話すときのチートシート

ポイント

せっかくの機能開発の速度向上も、下記状況では収益向上は律速される
1.アポイントメントを取るなどを含めた商談期間が短くなっていないなら収益は伸びない
2.隠された本音に対応するには社内も社外でも時間やコストがかかる。ここも対処しないと収益が伸びない

この記事をより理解するためのスライド

顧客の特定を詳細に解説したスライド

また、今回の話はRSGT2026のSIDE Bの土台にある話である