売れる事業と伸びる事業は何が違うのか

以前、法人向けのデータ解析サービスに関わっていたとき、顧客先に処理用のサーバーを設置し、お客さんの環境に合わせてシステムを構築したことがある。

技術的には問題なく動いていたし、顧客固有の環境にも対応できていた。
当時、開発に関わっていた僕としては、それなりに良いシステムを作れたと思っていたし、実際に顧客へ価値を届けられたという意味では今でも間違っていなかったと思う。
ただ、その後に新規事業や経営企画の仕事を経験する中で少し違う見方をするようになった。

この仕組みを次の顧客にも、その次の顧客にも、同じ品質と採算で提供できるのだろうか。
顧客が10社、100社と増えたとき、売上と一緒に必要な人員や工数まで増えてしまわないだろうか。

技術が完成したからといって、事業やビジネスモデルまで完成するわけではない。

1社に届けられることと100社に届けられることは違う

顧客先にサーバーを置くこと自体が悪いわけではない。
データを外部に出せなかったり、既存設備との接続が必要だったりと業界や用途によってはクラウドよりオンプレミスの方が合理的な場合もある。

重要なのは技術構成そのものよりも顧客が一社増えたときに自社の仕事がどれだけ増える構造になっているかだと思う。

例えば、顧客が増えるたびに現地調査を行って設計や設定を変更し、データ形式を合わせる必要があるとする。
障害が発生すれば、その顧客固有の環境を理解しているエンジニアが対応しなければならない。こうした仕事が顧客数に比例して増えるのであれば、売上が伸びてもコストや運用の複雑性も増えてしまう。

しかも、個別対応を頑張るほど顧客には喜んでもらえるし、営業としても受注につながるので、なかなかやめられない。
次の商談で「前のお客様には対応したと聞いています」と言われれば、断る理由よりも対応方法を考えてしまうこともある。

こうして個別対応が積み重なると案件ごとに異なるシステムを維持することになり、事業の成長とともに負担も大きくなっていく。

最初の顧客に価値を届けられたことは大きな前進だが、それによって確認できたのは「その顧客には価値があった」ということまでであり、「同じ仕組みで事業を大きくできる」ということまで証明されたわけではない。

ソフトウェアだから限界費用が低い、とは限らない

この問題を考えるうえで参考になるのが、経済学の限界費用という考え方である。商品やサービスをもう一単位増やすために追加で必要になる費用のことで一般にソフトウェアは物理的な製品と比べて限界費用が低いと言われている。
例えば、自動車をもう一台生産するには新たな材料や部品が必要になるが、完成したソフトウェアをコピーするだけなら追加費用はほとんどかからない。

ただし、ソフトウェアの複製コストが低いこととソフトウェアを使った事業の限界費用が低いことは、必ずしも同じではない。

導入のたびに顧客ごとの調整や個別開発が必要で運用や保守にも専門のエンジニアが対応しているのであれば、ソフトウェア自体はいくらでもコピーできても顧客に届けるまでには相応の工数がかかる。

特にIoTのようにセンサーやネットワーク、現場設備と解析ソフトウェアが組み合わさる事業では、ソフトウェア単体ではなくて営業から導入、運用、保守まで含めた提供プロセス全体を見る必要がある。

「売れた」が証明することは、意外と少ない

新規事業において、最初の受注には大きな意味がある。誰かが実際にお金を払ったという事実は企画書に書かれた需要予測とは重みが違う。
一方で、一件売れたことから言えることを広げすぎるのも危ない。

その顧客が、その条件で、その提案に対してお金を払ったことは確認できても、別の顧客にも同じように売れるかは分からない。
営業担当者が変わっても売れるのか、値引きや個別開発を減らしても選ばれるのか、導入後も継続して使ってもらえるのかは、それぞれ別に検証する必要がある。

技術が動いたこと、顧客が喜んだこと、受注できたこと、利益が出たこと、そして繰り返し売れることは、一連の成功に見えても、それぞれ意味が違う。

ところが組織の中では、一つの成功をきっかけにこうした違いが曖昧になりやすい。技術が動けば事業化できそうだと考え、一件売れれば市場性が確認できたと捉え、顧客に褒められれば横展開できると期待する。

期待を持つことは必要だが、検証していない仮説まで確認済みの前提にしてしまうと、事業の実態を見誤る可能性がある。

個別対応は悪なのか

では、最初から標準化を徹底し、顧客ごとの個別対応をすべて断ればいいのかというと、もちろんそんなに簡単ではない。

新規事業の初期には、顧客が何に価値を感じるのかも十分に分かっていない。個別の要望に向き合うからこそ、想定していなかった課題や、複数の顧客に共通するニーズが見えてくることもある。

だから、僕は個別対応そのものが問題だとは思っていない。
重要なのは、個別対応を通じて得られた知識や経験を次の顧客への提供に生かせているかどうかだと思う。

例えば、同じ要望が繰り返し出てくるのであれば標準機能として取り込み、顧客ごとの違いは設定変更で吸収できるようにする。導入作業を手順化すれば、次の案件では同じ苦労を繰り返さずに済む。

逆に顧客ごとに要望が大きく異なり、そのたびに新たな開発が必要になるのであれば、対象とする顧客層を絞った方がいいかもしれない。

毎回「今回のお客様は特殊なので」と言いながら個別対応を続け、その経験が案件の中だけにとどまってしまうと、顧客が増えるほど事業は複雑になっていく。

売上は今期に計上されても個別対応によって生まれた負担は翌期以降も残り続ける。
残念ながら、決算書に「個別対応しすぎた代」という勘定科目はない。

「システムをつくる」から「仕組みをつくる」へ

当時の経験から僕が学んだのは、オンプレミスが良いとか悪いとか、そういうことではなかった。

技術者は目の前の技術課題を解決しようとするし、営業は顧客の要望にできる限り応えようとする。どちらも必要な仕事だが、事業として成長させるためには、もう一つ考えなければならないことがある。

同じ価値を次の顧客にはもっと少ない追加負担で届けられる仕組みをつくることだ。

そのためには、完成させる対象を一つのシステムから、事業全体へと広げる必要がある。営業担当者が変わっても提案できるようにすることや、導入のたびに専門のエンジニアが対応しなくても済むようにすることなど、顧客に価値を届けるまでの仕組みを整えていくことが重要になる。

この視点を持つと開発ロードマップの見え方も変わってくる。

AIを搭載した、分析精度が上がった、新しいダッシュボードを開発したといった成果は分かりやすく、社内でも注目されやすい。
一方で、設定の共通化や遠隔保守、アップデートの一括配信といった改善は、あまり目立たない。

ただ、顧客が10社、100社と増えたときに事業の収益性を大きく左右するのは案外こうした地道な改善だったりする。

顧客がもう一社増えたとき、何が増えるのか

あのとき作ったシステムが技術的に間違っていたとは、今でも思っていない。顧客の環境に合わせて価値を届けられたことには意味があったし、最初の顧客に向き合ったからこそ得られた経験もあった。

ただ、新規事業や経営企画の仕事を経験したことで僕自身が「完成」を判断する視点は変わった。

以前であれば、システムが要求どおりに動くか、顧客の課題を解決できるかを中心に考えていた。今はそれに加えて、顧客がもう一社増えたときに、自社の仕事がどのように変わるのかを考えるようになった。

僕は、継続的に成長できる事業とは、単に需要が大きい事業ではなく、顧客が増えるほど、自社の提供能力も高まっていく事業なのだと思っている。

もちろん、新規事業の初期からすべてを標準化する必要はない。ただ、何を個別対応するのか、そこから何を学ぶのか、いつ標準化するのかを判断しないまま案件を積み重ねても、なかなか再現性のある事業にはならない。

PoCの次に必要なのは、さらに豪華なPoCではなく、顧客への価値提供を繰り返せる事業の仕組みをつくることだ。

だから、新しい事業を見るとき、僕自身も一つの問いを大切にしている。

「顧客がもう一社増えたとき、僕たちの仕事の何が同じ割合で増えてしまうだろうか」

この問いを持つことで、その事業が単に売れているだけなのか、それとも成長できる仕組みを持っているのかが、少し違って見えてくる。