はじめに

私は株式会社ログラスでエンジニアとしてBtoB SaaSの開発を行なっておりますが、経歴としてはBtoC事業に長く携わってきました。
これまで携わってきたサービスの事業形態によらず、ユーザーの価値に向き合って開発することを大切にしてきたので、BtoCとBtoBそれぞれで感じた価値との向き合い方を「事業・プロダクト・開発」の3つの視点からまとめてみたいと思います。

この記事では私の経験を元にスマホアプリのBtoC事業とマルチテナントSaaSのBtoB事業を前提に語るため、全てのBtoC,BtoB事業に当てはまるわけではございませんのでご容赦の程よろしくお願いいたします。

また、BtoBの事例として弊社の経営管理クラウドLoglassを題材にしておりますので、ご興味がある方はこちらのnoteをご覧いただくとどのようなサービスなのか知っていただけると思います。

事業の違い

取引相手は誰なのか

BtoCとBtoBで何よりも一番の違いは取引を行う対象でしょう。「Business to Consumer」と「Business to Business」と読んで字の如く、企業の取引先が個人なのか企業なのかが違います。

取引相手が個人になるBtoCでは、多くの場合決済者と利用者が同一の個人になります。一方でBtoBの場合は企業との取引なので、決済者となるコーポレートとサービスの利用者となる社員が別の人になることがあります。

この場合、現場の利用者だけで決済が進められないような高単価なサービスであればあるほど、決済者にもサービスの価値を理解してもらう必要が出てきます。

誰の何を解決するのか

結局のところ利用するのは一人の人間なのだから突き詰めるとBtoCもBtoBも同じなんじゃないか？そう思ったこともありましたが、
ざっくり区別すると、私生活の時間に個人的な課題やニーズを満たすための事業なのか、仕事の時間に業務課題を解決するための事業なのかが本質的に違うところなのだろうと思っています。

取引相手が誰なのか、どのような課題を解決しようとしているのかは、BtoCとBtoBのさまざまな違いの基点となっているためとても重要な話です。

収益モデル

ビジネスの取引相手が変わればもちろん収益モデルも変わるわけで、BtoCではユーザー課金や広告といった収益源が多くなっています。
多数のユーザーを抱えるため、全てのユーザーに課金してもらわなくても一部のユーザー課金で採算が取れる場合はサービス利用の間口を広げるためにフリーミアムやトライアルといった形態が採用される場合もあります。

フリーミアムの場合、無料で使わせる範囲や課金転換するポイントはどこなのかを考える必要がありプランごとの体験設計が常について回ります。事業としては無料ユーザーをいかに課金ユーザーに転換するかが重要KPIとして設定され、日々改善施策を回すことになるでしょう。

また1ユーザーあたりの単価は低く、大規模なユーザー数で収益をカバーすることが大半であると思います。いかにロイヤルカスタマーが育つ体験を作り上げられるかが、BtoCにおけるマネタイズの難しいポイントになると思います。

BtoBでは企業との契約で収益が発生します。比較的市場規模が大きく、1企業あたりの単価も高くなりやすいです。逆にいうと解約が起こった場合、失う収益も大きくなるため解約されないための機能開発が発生しやすい傾向にあると思います。

高単価な契約金額を上回るだけの価値を享受できない場合、投資対効果が見合わないとして解約が発生してしまうため、どれだけ価値のある業務課題を解決できるかがBtoBにおいては重要視されると考えています。

戦略

使ってみたいと選ばれるサービス

読者の皆さんは電車に乗っているときに、時間を潰すために使っているスマホアプリはどこで知ってインストールしましたか？
担当セールスの方に説明を受けてインストールしたわけではなく、さまざまな経路から自分で辿り着いて自然に使っていますよね？

BtoCのサービスは特性上多くのユーザーに使ってもらって収益を上げるため、ユーザーが自分でサービスをインストールして自分で使いこなし、価値を感じてお金を払ってもらう必要があります。
さらにユーザーが新規ユーザーにサービスを紹介し連れてきてくれたら自然とコミュニティが広がり万々歳です。

このように数ある競合サービスの中から「使ってみたい」と選ばれるサービスであることや、ユーザーが継続的に利用して満足し続けられることはBtoC事業を成長させていくためのキーポイントになっています。
競合との差別化やマーケットでのポジショニングなど、レッドオーシャンで勝ち抜くための戦略にコストをかける印象を持っています。

誰が価値を伝えるのか

一方でBtoB事業ではセールスチームによる受注を経てサービスを使い始め、カスタマーサクセスチームによりオンボーディングが行われユーザーがサクセスすることを支援します。

弊社の具体的なBtoB SaaSの営業モデルについてはこちらのnoteをご参照ください。

Loglassは経営管理という複雑なドメイン領域を取り扱うサービスであり、まだまだこれから市場を開拓していかなくてはいけない段階です。
高単価×エンタープライズセールスということもありセールスチームがいかにお客様に経営管理の課題を認識してもらい価値を伝えることができるのかが事業のトップラインを決める第一要因になります。

また、各社ごとに属人化した経営管理業務をシステム上で行うためにはカスタマーサクセスチームによる支援が必須であり、きめ細やかなサポートで伴走し価値を感じてもらう手助けをします。

このようにサービスとしてはセールス・カスタマーサクセスにとって価値が伝えやすいことが一定重要視される傾向にあり、契約の阻害要因を排除するための開発が優先されることが多いと感じています。

世界観を伝える

BtoB事業特有だと感じているのが世界観を伝えるという考え方です。スマホアプリを使っていてこのアプリの世界観は、、、と考えることはあまりないですが、弊社Loglassというサービスは明確に実現したい世界観を持って発信しています。

Loglassの機能を簡単にいうと「予算策定業務の効率化と柔軟な経営データのアウトプット」ですが、この機能によってサービス外の部分で経営管理業務に大きな影響を与えます。

経営企画担当者はより本質的な業務に集中できるようになり、経営者や事業責任者がよりスムーズに意思決定を行う土壌を整えることができます。
必要なデータはLoglassに全てあるという状態を作り上げることで、経営会議にかかるストレスは減少しより精緻な将来予測・投資を行えるようになり結果市場価値が向上します。

Loglassというサービスの機能の先にある世界観をお客様に伝えることができるのは、サービスとお客様の間にセールスチームが存在するBtoB事業ならではだと思います。

このように、その先にある世界観をお客様に伝えるビジョンセリングという難易度の高い挑戦をしてくれているセールスチームの記事がnoteにありますので是非ご覧ください。

プロダクトチームとしてはセールスチームが世界観を伝えやすく、かつカスタマーサポートチームがその世界観を実現できるようなサービスを作り上げることが使命だと考えており、ビジネスサイドに応えられるように日々走り続けています。

プロダクトにおける違い

本記事において「サービス」と「プロダクト」という言葉の違いを明確にしておきます。「プロダクト」は開発部が作るソフトウェア自体を指しており、「サービス」とはプロダクトと、セールス・カスタマーサクセスといった事業部を含めた全体の成果物を指しています。
特にBtoBではカスタマーサクセスチームによるサクセス支援までを含めてサービスとして提供しているためこのように定義しております。「プロダクト」は「サービスに包含されている」という考えのもと読み進めていただければと思います。

プロダクトで重要視されるもの

真っ直ぐに舗装された道路を作りたい

「使ってみたいと選ばれるサービス」で記述したようにBtoCサービスでは以下の3つが重要視されていると考えます。

• 数ある中から選ばれるためのUIやUXといった「使い心地の良さ」
• ユーザーが一人で使えるようになるための「システム的なオンボーディング」
• ゲーミフィケーションやパーソナライゼーション、プッシュ通知といった「継続して使い続けるための要素」

ユーザーが課題を解決するまでの道筋をプロダクトのメインストリートとした時に、いかに早く・自分で・何度もメインストリートを通れるのかがプロダクトの体験としてとても重要だと考えています。

特に無料アプリであれば、小さなニーズのためにインストールをしてくれますが使い続けることのハードルは相対的に高くなっていると思います。
そのためニーズをいかに早くわかりやすく満たすことができるかが重要であり、その成功体験がまた使いたいと思い使い続けてくれる大きな要因になると考えます。

ゴールまで迷わず進めるUI・UXの良さであったり、一人で走れるように舗装された親切なオンボーディング、何度も通りたくなるような風景・体験となる使い続けやすい要素をプロダクトで実現していくことが重要視されているのではないでしょうか。

曲がりくねった道でもいい

BtoBのドメイン知識は比較的複雑で課題が広く深いことが多くなっており、業務課題を解決するためのソリューションが企業内で既に組まれたオペレーションを大きく変えるようでは変更コストが高く、投資対効果に見合わないと判断されてしまうこともあります。

そのため業務課題を解決できるのかどうか、どうやって解決できるのかが重要視されると考えています。
少し複雑で長い道のりでも確実に課題解決のゴールにたどり着けるような道を作っていくことがプロダクトの中心になると思います。

また、近年BtoCの綺麗で舗装された道路を作る考え方が、BtoBにも波及していると感じます。これまで嫌々使っていた使いづらい業務システムから、近代的で圧倒的に使いやすいUXを提供しているSaaSが出てきており、これからも進展していくと考えられるためBtoCとBtoBの差はなくなっていくのかもしれません。

プロダクトの価値はなんなのか

そもそもプロダクトの価値とは何なのでしょうか。

私はプロダクトとはユーザーと企業の価値交換システムであるという考え方に非常に共感しています。ユーザーは課題解決やニーズを満たすためにプロダクトを利用し、企業はその対価として収益やデータを獲得するというものです。

プロダクトを価値交換システムとした時に、プロダクトの価値が高いというのはこの価値交換量が大きいことだと考えています。
多くの課題を解決しニーズを満たすことで、企業が持続的に成長できるプロダクトこそが価値があるのです。

広告収益のビジネスモデルは難しい

収益モデルでも言及しましたが、BtoCではユーザー課金や広告が収益のメインであることが多いです。
広告のみで収益を上げるビジネスモデルの場合、ユーザーの課題を解決するためにプロダクトが提供するユーザー価値とユーザーから得られるビジネス価値が一対一対応しないことがあります。

ユーザーにとって本当に使いやすいものを作ろうとすると、広告は出さないほうが良くなってしまいますが収益を上げるためにはできるだけ多くの広告を見てもらう必要があります。ユーザーの体験を損ねないようにしながらマネタイズを行うバランス設計は非常に難しいと言えるでしょう。

ユーザーに無料で利用できる価値を提供し続けながら更なる事業成長をしていくためには、日本国内向けのアプリだとユーザー数が限られてしまうため、いつか他の収益源を考えなければいけなくなるかもしれません。
このようにプロダクトの成長と事業の成長を両輪で回していく難しさにBtoC事業の面白さがあるのではないでしょうか。

ユーザー価値とビジネス価値の対応

一方でBtoBでは、ユーザーの課題を解決することができるシステムとしてプロダクトにお金を払っていただくため非常にシンプルな構造になります。
より深く広い課題を解決しユーザーに向き合い続けて価値を提供することが、ビジネス価値を得るための唯一の選択肢であり、プロダクト価値の向上に最も繋がるのです。

どのようにプロダクトを作るのか

リリース後が重要

ユーザー数が多いBtoCでは、リリース後のユーザー行動を定量的に分析しPDCAサイクルを回してプロダクトを作っていくことが多いと思います。
N1インタビューで一人のユーザーにフォーカスしたリサーチを行ったとしても、あくまでも方向性の示唆出しにとどまるため、一人のユーザーに向き合うよりも多くのユーザーから抽象化されたインサイトを得ることが重要だと考えています。

機能のリリース前に価値としての不確実性を下げることが難しいため、リリース後いかに高速にフィードバックを得て改善していくサイクルを早められるかがBtoCプロダクト作りにおいて重要になります。
そのためA/Bテストやデータ分析基盤、行動データ収集、データサイエンスといったリリース後のアジリティを向上させるための技術に投資を行う企業が多いのではないでしょうか。

リリース前が重要

BtoB事業では、解決したい業務領域の課題を語ってくれるユーザーとの関係値があるため、ヒアリングで価値の不確実性を低減させることができます。リリースしてユーザーの反応を見るまでもなく、ヒアリングとプロトタイピングでユーザーの抱える真の課題を炙り出すことができてしまうのです。

しかしながら欲しいと言われて作った機能が、いざリリースしてみると使われないということが往々にして起こってしまいます。
なぜこれが起こるのかというと、ユーザーは課題を語ってはくれますが答えを持っているわけではないからだと考えています。

「XXXができなくて困っているからXXXな機能が欲しいんだよね〜」という声を聞くと、ついついどういう仕様で作ろうかHowな話に進んでしまいがちだと思います。
深ぼって課題を整理していくと実は裏に別の課題があり、それを同時に解決したかったということが発見できるかもしれません。

ユーザーが本当に欲しいもの

ユーザーに直接ヒアリングする機会が多いBtoBでは本当に欲しいものは何かを探らなくてはいけません。ユーザーが欲しいと語ってくれているものとは実は違うものを必要としているのかもしれません。

これはいわゆるドリル穴理論というもので、ホームセンターにドリルを買いにくるお客様はドリルではなく穴が欲しくてドリルを買っているという話です。
ドリルが欲しいと言われたときに、どういうドリルがいいのか考えるのではなくなぜドリルが欲しいのかを解き明かしていくことが重要な視点になります。

また、ヒアリングで一人一人のユーザーに向き合うためそれぞれの課題を深く理解できるのですが、特殊なユースケースになっていないか一度引いて考えるマクロな視点も必要になります。
ありとあらゆるユースケースに対応できる十徳ナイフのようなプロダクトは、一見誰でも使えるように見えますが実際のところどれも中途半端で非常に使いづらくなってしまうことがあります。

チグハグなプロダクトにならないように、プロダクトビジョンと整合性をとりながら課題の本質をヒアリングから抽出し作り上げていくのがBtoBのプロダクト作りだと考えています。

開発の違い

大規模ユーザー

まず開発者が意識する違いとして挙げられるのがユーザー数の違いでしょう。BtoCの方が比較的ユーザー数が多く、高トラフィックを捌き続けるための設計が求められます。
CM放映やテレビ特集などトラフィックのスパイクが予測できることもありますが、思わぬタイミングでアクセスが集中しアラートに泣かされた開発者も多いのではないでしょうか。

ユーザー数が多いためプッシュ通知やメール配信といったユーザーごとに処理する必要がある部分は全てスケーラブルなアーキテクチャである必要がありますしデータベースのレコード数が億を超えることも多々あります。

アクセス数が多い時ほどサービスダウンは致命傷になり、ユーザーの体験を損ねる要因になってしまうため、いつでもサービスが使えるというのはユーザーにとって当たり前品質であり価値を提供する基礎にあたります。

しかしながらその当たり前品質の裏には技術的なチャレンジが必要で、主にインフラストラクチャーのレイヤーで大規模ユーザーに対応することがBtoCの技術的な面白さなのではないか思います。

マルチテナントのデータ分離

BtoBの場合は最も意識するのはテナントごとのデータ分離ではないでしょうか。一つのアプリケーションで複数のテナントに同一のソフトウェアを提供するため、他のテナントのデータが漏洩してしまうことは絶対に避けなければいけません。

一口にデータの分離と言ってもどのレイヤーで分離を行うのか、テナント間で共有可能なマスターデータの管理をどうするか、それらを保守運用していけるのかなど考えるべき複雑性がいくつもあります。

想像できないユースケース

BtoBではドメイン知識自体が非常に複雑であり、ユースケースを理解し切ることが難しい場合もあります。
私が携わっていたシステムでは、ユースケースとして数枚の画像をアップロードすることを想定し開発していましたが、実際にリリースした後になってから数千枚の画像をアップロードしたい要望が上がり泣きながら機能改修を行ったことがありました。

言われてみるとそういう使い方があるのか、、、となるのですが、開発前に想定するのは難しいと感じることが何度もあります。
プロトタイプの作成やヒアリングでユースケースを整理して、リリース前にどれだけ不確実性を減らせるかが開発チームとしての腕の見せ所だと思います。

複雑性の高さ

ユーザー数は少ないですが、ユーザー当たりのデータ量はBtoBの方が大規模になることが多いと感じています。数千枚の画像アップロード然りですが、一括操作でデータを投入したい・処理したいというユースケースが多々あるため、複雑なドメイン知識と組み合わせた時に難易度が急激に上昇します。

弊社の経営管理クラウドLoglassでは、年月・勘定科目・部署・明細といった複数のデータを多次元的に計算する必要があります。そして経営データという秘匿性の高い情報を扱いながら複雑なドメインを紐解いていくことが簡単なわけがありません。

このように主にアプリケーションレイヤーでの複雑性に技術で対応していくところにBtoBの面白さが詰まっているのではないでしょうか。

ステークホルダー

プロダクトはプロダクト組織で開発を行うだけではユーザーに届きません。社内のさまざまなステークホルダーとの協力によって初めてユーザーに届き価値になるのです。

BtoCであればBizDev、マーケティング、カスタマーサクセスなどのビジネス職と協力しつつプロダクト開発組織が中心になってプロダクトを作り上げていきます。ユーザーの反応や行動データを定量的に分析しプロダクトへ反映する作り方をするため、最もユーザーを理解し距離が近くなるのがプロダクトチームになると考えています。
この部分がBtoCは開発者とユーザーの距離が近いと言われる所以ではないかと思います。

BtoBではさらにセールス職が加わり、ユーザーを最も理解しているのがカスタマーサクセスチームになります。ユーザーの声を一番聞き、代弁者となって語るカスタマーサクセスチームといかに協力してプロダクトを作れるのかが重要になってくるのです。

そして価値を最初にユーザーに伝えるセールスにとって、いかに価値が伝えやすいプロダクトであるかも重要になるため、プロダクト開発組織とビジネス職が両輪となって事業を作っていくことが必要不可欠なのではないでしょうか。

弊社では開発組織がよりお客様の業務・課題を理解するためカスタマーサクセスの業務を体験するインターン制度を設けています。インターン制度についてはこちらのnoteに詳しく書かれているのでよろしければご覧ください。

ユーザーとの距離

BtoCはユーザーとの距離が近くBtoBは遠いというのが一般的に多く言われていることではないかと思います。
実際にBtoCではユーザーが友人や家族といった身近な人であったり、利用した喜びの声をSNSで見かけたりすることがあったりと使ってくれている人を私生活で実感することが非常に多いと思います。

一方でBtoBだと距離が遠いのかというとそうではないと考えています。業務課題を解決するという事業特性上、私生活でユーザーを感じることが少ないのは確かですが、ユーザーとの距離はBtoBの方が近いのではないかと思います。

サービス導入企業様にヒアリングさせていただくことも多いですし、使いづらくて困っていると要望をあげてくださる担当者様との接点もあります。機能開発する際には誰のどういう課題を解決するのか詳細化して取り組んでいくためBtoBの方が距離が近く、ユーザーの解像度を高くして向き合っていく必要のある事業だと考えています。

実際に弊社では開発者がお客様との定例ミーティングに同席し、一緒に業務フローの整理を行った上で課題の認識合わせを行なったこともありました。
仕様整理しているときには「この機能ってXXX社様の業務フローで誰がどういうユースケースで使うんでしたっけ？」といった会話がなされるほどに利用するお客様を意識した開発が行われています。

これほどまでにユーザーとの距離が近いBtoBは少ないのかもしれませんが、価値を提供できていることが実感できるため非常にやりがいと面白さを感じています。

おわりに

この記事では私が携わってきたBtoCアプリとBtoB SaaSそれぞれの視点からどのようにユーザーの価値に向き合うのかをまとめてきました。

BtoCとBtoBでプロセスや環境といったユーザー価値への向き合い方はもちろん違いますが、それぞれに合ったやり方を模索しユーザー価値・ビジネス価値を創出したいというゴールは同じです。その意味では本質は大きく変わらないと言えると思います。もちろんどちらの業界の方が優れているということはありません。

どちらの業界もそれぞれ面白いですし、どちらかの事業形態しかやりたくないというのはもったいないと思うので、機会があれば別の業界に飛び込んでみてください。少なからず環境は違いますが、新たな視点でこれまでとは違うユーザー価値への向き合い方ができると思います。

BtoCとBtoBのユーザー価値への向き合い方の違いについて、本記事で少しでもイメージができるようになれば幸いです。