開発者のためのB2Bサービスづくり徹底入門
こんにちは、普段はプロダクトマネージャをしつつエンジニア界隈にも首を突っ込んでいるku-sukeです。最近では個人や少人数チームでアプリやサービスを使ってリリースする人も増えましたね！その中でも「いままでは個人向けにサービスを作ってきたけど、法人のひとから問い合わせが来た」とか「B2Bって取引金額が大きそうだから興味がある」あとは自分で運営していなくても「B2BのSaaS企業に転職したけどB2Bわからん」という声をちらほら目にしたので、自分が知っている範囲でまとめようと思います。
🔰はじめに。B2Bってなんなん
個人開発者の人からするとこの時点で違和感があるかもですが、Business to Businessつまり事業者間取引のことです。個人の方もビジネスをしている以上は個人事業主ですので立派な事業者です。
これと対比して、個人消費者向けにビジネスする、あるいは広告など個人が使用することに伴い収益を得るビジネスをざっくりB2C、Business to Consumer(Customer)といいます。事業者ではない、個人同士のフリマ取引などはC2Cと呼ばれますが、話すと長くなるのでここでは触れません。
この記事の対象読者はこんな人
- モバイルアプリ作れます
- Webサービス作れます
- アプリorクレカの課金機能作ったことあります
- 広告も張ったことあります
という、エンジニア属性の中ではアプリやサービスでお金稼いだことあるぞ！というレベルの人をターゲットとしています。ちなみにまだ稼いだことがない人は、nabettuさんの個人開発マネタイズ大全をご覧ください。
あるいはB2B SaaSとかの会社に転職したので様式を知りたい人にもいいかもしれないです。
※日本市場の話に特化しています。
🏢B2Bといってもだいたい３層に分かれる
法人あいてのビジネスといってもそこは大きな違いがあります。おおよそ3層に分かれ、ひとりor零細企業、SMB、エンタープライズです。企業規模によって「求める機能」や「購買の流れ」がかわります。
ひとりor零細企業
だいたい５名以下の会社とか個人事業主が法人成りしたパターンです。この場合は比較的B2Cの頃と同じようなパターンで進めることができます。
- ほとんどの場合カード決済ができる、むしろカード決済希望
- 使う人＝意思決定者＝導入推進者＝購買担当者
- 一般的にセキュリティとかもそんなに気にしない
- リテラシーはやや高め（な人しか契約しない）
SMB（Small and Mid Business）中小・中堅企業
おおよそ300名以下の企業です、このあたりの境目はあいまいなのですが、次のような特徴があります。
- 業種によってリテラシーの差異が大きい。カード決済OKのところもあればNGもある。
- その場合月末締め翌月末払いでの課金が必要
- 情シスが１人とか最低限しかいないので、セキュリティは多少気にするが厳密ではない
- 購買担当者＝使う人＝導入推進者だけど、その人のほかに使うことになる数名は「いわれたから使ってみる」みたいな消極的であるパターンがある
- 意思決定者は別（社内稟議が必要）なのでトライアルから利用開始までラグがある
※稟議（りんぎ）とは、会社の中でこれ買っていいですか？とワークフローをまわして決済権者にOKをもらって証拠に残すこと。
ここからが本当の意味でB2Bでの入口ですね。場合によっては契約までに1回程度打ち合わせが必要になります。細かい対応は以下の章で書いていきますので、先にエンプラを見ていきましょう。
エンタープライズ
おおよそ300名以上の大きな企業です。上場している企業も多くあり、コンプライアンスとかいろいろなルールの中でビジネスをやってきているので、面倒ごとが多いです。
- 取引先チェックがあるし、なんなら基本契約書を交わさないといけない
- セキュリティのチェックが厳しい
- 業種によってはサーバーが日本にあるかどうかとか聞かれる
- 他社とデータの保管場所が論理的に分かれているかとか聞かれる
- いきなり買ったりしない。資料請求して比較検討する（しないといけない）
- 導入推進者が必ずしも主に使う人とは限らない
- 情シス担当が営業向けCRMツールの導入をすることもある
- 買いますって決まってからの手続きが多いし謎の購買様式が求められることがある
ここまでくると、かなり導入してもらうまでに人間の工数がかかります。打ち合わせ回数も3回とか5回とかが必要になったり、トライアル期間を1か月とか2か月とか長くほしいといわれることもあります。
🙇♂️B2Bに対応する-1 売り方を考える
いままでアプリストアやB2C向けでやっていたひとは、宣伝→勝手に会員登録してもらう→勝手にクレカ決済してもらうという「セルフサービス型」の作りをする場合がほとんどだったと思います。ところがB2Bの場合は、個人や零細規模のお客様を除き、社内の手続きのために人間の手を求める割合が増えます。
導入推進者は、社内外に「説明責任」を果たす必要がある
企業が大きくなると、不正防止の観点から、なにかをしましょうと決めるときには「なんでそうするの？」を説明し証拠に残す責任があります。もちろん「一定金額以下＆個人情報や営業秘密を扱わなければ担当者裁量でOK」とする場合も多いですが、年間100万円を超えたり、ファイルアップロード機能がついているとだいたい引っ掛かります。
- なんでこのサービスにしたの？他も比較した？
- イケてないサービスを契約する＝会社のコストを無駄遣いする
- この取引先安全なの？つぶれたりしない？反社会的勢力じゃない？
- このサービス安全なの？情報漏洩しない？うちのデータのぞき見したりしない？
ダウンロード可能な資料を用意しましょう
導入したい担当者が社内に説明しやすいように、以下のようなポイントを書いた資料を用意しましょう。
- このサービスの特徴、アピールポイント
- このサービスは特にこういう風に活用されています
- 類似サービスと比べた優位性
- 運営者の安全性
- サービスの安全性
逆に言うと、説明できるほどちゃんとしてないんだよな・・というときは完ぺきじゃなくてもいいので徐々に整備しつつ、それまでは「個人またはそれに準ずるライトな法人のみ」と意思決定するのも立派な戦略です。
そして、資料がダウンロードされたら、初回のお打ち合わせを打診しつつ見積書を12か月分で用意しましょう。法人ビジネスは手間がかかる代わりにお互いの事務処理を軽減するため長期契約が魅力です。
セキュリティチェックシートに記入しよう
大企業はだいたいセキュリティチェックシートへの記載を求めてきます。そのため記入する必要があります。また、一歩進んでISO27001の取得を検討するのもいいでしょう。最終的に取得にいたらなくても、セキュリティチェックシートで聞かれる項目はだいたいおなじなので勉強になります。
図解即戦力 ISO27001:2022の規格と審査がこれ1冊でしっかりわかる教科書 Kindle版
なお、ここで聞かれる「セキュリティ」とは、たんにシステムの脆弱性がないかだけではなく、会社として情報が守れるように、社内ルールを整備したり、日々の業務がルール通りに行われているかチェック・見直しする体制がありますか？といったところのウェイトがかなり大きいです。
もし個人事業主として、適当に人目があるカフェで本番データのメンテしてますとか、Slackにパスワードを張り付けちゃったりしてるザルな運用をしている場合はこの機会に見直していきましょう。
詳しくは（詳しくない。ただの読み物）拙著技術同人誌「セキュリティチェックシートの薄い本」もご覧ください。
あと本稿では詳しく書きませんが、利用規約がテンプレをちょっといじったような雑な状態であれば、いちど法律家にみてもらって増強しておきましょう。
月末締め翌月末払い銀行振込に対応しよう
さて、いよいよ会社としてのチェック、サービスとしてのチェックに合格したら、つぎはお金の払い方です。クレカで決済してくれる企業は半分くらいで、残りの企業は「請求書払いいけますか？」と聞かれます。請求書払いとは、月末締め翌月末払いのことを指します。
では月末締め翌月末払いとは何か、普通クレカのサブスクだと、10/15に契約したらその日に1回目の課金が発生し、だいたい翌15日にもカードに自動で決済が走りますよね。
これをおおよそ手動でやることになります。まず、月半ばで規約するときのルールを定めます。おすすめは「月中で契約しても日割りやってません」で突っぱねましょう。10/15に契約しても10/31までで1か月分いただきますよ、ということです。
次に「月末締め」がやってきます。1か月間のお取引を月末に集計しますよ、という意味ですがサブスクで基本料しかない場合は締めるも何も1件しかないですね。しかしそういう商習慣、既存の事務処理フローに載せないとイレギュラー対応コストがかかるので買いません。ということです。
そして、締めた結果を「請求書」として発行します。どこどこの口座に、いつまでに振り込んでくださいね。と。そこで登場するのが「翌月末払い」です。10/15に契約したら10/31に締めて、11/30までに銀行振り込みをするという最もフィジカルで最もプリミテi（略）な支払い手段です。
これをStripeでやると大変だったので、Stripeでやる方はこちらの記事をご覧ください。
商談ができる人（営業マン）を用意しよう
さて、もうおなかいっぱいだよという声も聞こえてきそうですが、ここまでのやり取りをお客様とコミュニケーションする担当が必要ですね。そう、営業マンです。とくに資料請求レベルだと「まだ使うかどうかわかってない」「他社と比べたいだけ」みたいな温度感の低いお客様が大半なので、そのなかで具体的にヒアリングしたり3か月間かけて機をうかがって契約にもっていく、みたいな活動が必要なのです。
開発者のあなたがやってもいいですし、得意なことは得意な人にやらせてもいいでしょう。営業の世界は開発者とプロトコルが違いますので、Zoomに1分遅刻するだけで怒る人や、打ち合わせ日程の候補をどちらから出すべきかみたいなマナー講師みたいな世界も一部あります。
開発者のみなさんとしては「いやな客、あわない客とは商売しない」「ない袖は振れない」「今回はミスマッチでしたねハハハさようなら」というスタンスがおすすめです。企業なんて400万社以上あるわけですから。ただし悪評が立つようなひどいことを言ってはいけませんよ。敬意をもってうちでは対応できませんと答えましょう。
💪B2Bに対応する-2 プロダクトの作り方
さて、売り方編が終わりました、つぎはプロダクト編です。最終的にエンタープライズのお客様にも買っていただくようなプロダクトは、以下のようなポイントを抑える必要があります。それ以外にもマニュアルをスクショ入りで整備しようとかもありますが、開発者が携わる場所を選んで書いていきます。
複数人が参加できる「組織」という概念を作ろう
一般的に普通の個人向けサービスは、1アカウントだけで利用しますね。法人の場合は「Aさんがつくった資料をBさんが閲覧する、ただし外部公開はしない」みたいな使い方をしたいことが往々にしてあります。
そこで、「組織」「ワークスペース」みたいな概念を実装する必要があり、さらには権限管理を作る必要が出てきます。とくに「10人契約するけど、決済システムと連動するのは1人で10人分払う」とかだと大変ですよね。いわゆる「支払いアカウント」「オーナー権限」みたいなものの実装が必要です。
組織という概念を作ると、招待機能やユーザー管理などもふくめ付随機能の実装がたくさん生まれます。がんばりましょう。
データの保管場所名前空間で分けよう（マルチテナンシー）
これはまぁ、理論的にはアプリケーションサーバが乗っ取られたら結局漏洩するんですが、それ以外にアプリのバグやうっかりミスで漏洩しないよう、データの保管が企業ごとにちゃんとわかれていますか？というのがポイントです。
PostgreSQLのRowLevelSecurityや、firestoreでアカウントごとのコレクション配下にデータを入れるなど、簡単には横断取得できないような仕組みを構築しましょう。これは先ほどの「組織」という単位でデータをフォルダ分けして、手当を行うわけです。
ほかにも、アクセスするURLを組織ごとにサブドメインを分けたりすると、企業のファイアーウォールのルールで穴をあけやすくなるのでセキュリティの厳しい企業も導入しやすくなります。
シングルサインオン（SSO/SAML）に対応しよう
シングルサインオンとは、めちゃくちゃ雑に言えば企業のMicrosoftIDとかGoogleIDでログインさせよう、その際に通常のSNSログインとちがってその企業のドメインしか入れないようにしよう、という機能です。SAMLはさらに雑に言えばユーザーアカウントの有効無効も同期しようみたいなかんじです。
これを実装しておくとメリットが2つあって、１つはリテラシーの低いユーザーさんが無理やり利用を開始することに伴う「ログインできません」「パスワード忘れました」みたいな問合せから解放されます。２つめは2段階認証とかIP制限とか、そっちの（MSとかGoogleとか）ほうでやってるからうちで実装してないけどいいよね？と言えます。
なお、いろいろな方式がありますが、最低限だとMS Entra IDとGoogle WorkspaceとOpenID ConnectでOktaに対応できるのでこれ３つで90％以上はカバーできます。SNSログインの実装とほぼ同じなので試行錯誤とテストは大変ですが終わってみると短いコードで実現できます。
ただし前述した組織の絡みとかで、社員なら誰でもログインできる&&ログインしたユーザ単位で課金されるみたいにすると問題になるので管理者承認機能は必要になります。
インフラのセキュリティや監査を気にしよう
セキュリティチェックシートにも絡みますが、大企業の場合日本にデータを保管していることを要件にしている会社がありますので、Vercelとか海外のSaaS、PaaSにデータが保管されるものはNGだったりします。「保管」ではなく「通過」だとOKな場合もありますが取り扱うデータによります。あとCDNとかキャッシュはだいたい目をつぶってくれて、とにかく主要なデータの保管先が国内リージョンのクラウドであるってのが大事です。
また、よくあるのがIP制限要望です、これは顧客ごとに異なるIPレンジを制御しないといけなくなるので、アプリケーションレイヤーでログインを中心とした主要エンドポイントのみに実装するでもOKになる場合が多いです。また、年に1回くらいしかいじらないので管理画面を作らずエンジニアがDBや設定ファイルに顧客ごとのIPレンジを直書きすればOKです。
WAFなどの設置も聞かれますので、CloudflareのWAFやAWS WAF、Cloud ArmorなどロードバランサーやCDNレイヤーのWAFをオンにしましょう。そしてこれらは誤検知もしますのでチューニングしていいバランスでフィルタリングしましょう。
あと監査の観点からログをとっているかも聞かれますので、ログをとって保管しましょう。特にログインログと、重要情報を扱う場合はその操作のログですね。うちのログを確認できますか？みたいに言われる項目がありますが、インシデント時は実費負担いただければ5営業日程度で手動提供します。みたいに答えておけば専用ログビューワを作る必要はありません。
🏃♂️➡️最後に。B2Bのほうが「届ける」努力がめっちゃいる気がする
これはあくまで雑感ですが、B2CプロダクトはアプリストアやSNSなど、自分が経験したことあるフィールドで何となく集客して広げやすい、あるいは便利だったら一定口コミで広がるみたいな世界だと思います。(それで飯が食えるほどかは置いといて)
それに比べB2Bは、使いたい人と買う権限がある人がちがう、使うならうちのメンバー全員で活用できてコスト以上の効果出るよね？みたいな圧もあるため、いろんな人を納得させて初めて購入いただくみたいな違いがあります。
プロダクトの「価値」を作るといっても誰のためなのか？導入推進者、情シス、購買、上から言われていきなり使うことになった人、そのさらに先にいる顧客。
B2Bプロダクトは一点突破型の機能だけで戦えるようなものではなく、だからこそ丁寧にいろんな役割の人とコミュニケーションする必要がありますし、みんながみんな欲しい製品を探しているわけじゃないので、ガンガンお知らせしてガンガン営業する必要もあるわけです。そういった届ける努力も必要になります。
なぜUXで劣る（といわれがちな）初期のTeamsがSlackを一気に抜き去ってシェアを獲得できたのか。それも上記のような視点から見ると何となく理解できたりしそうですね。
さて、ここまで大変そうなことを書きましたがB2Bビジネスは、やることをやっていけば飯が食える程度の稼ぎは稼ぎやすいと個人的に考えています。
契約までに手間がかかるということは、一度契約すればほかのプロダクトに乗り換えしづらいということになりますし、面倒だから一気に人数分×長期で買っておくかという判断にもなりやすいのです。それに業界シェア第20位とか30位でも適切な営業があればそれなりに売り上げがたつのも特徴です。
B2Cよりも人気に左右されにくく、きちんとやることをやれば売り上げが上がるので、ぜひ本稿がみなさまのビジネスの第一歩となれば幸いです。
あるいは、そんなダルいことはしたくない、開発だけやっていたいというあなたの高額な時給を生み出すビジネスについて理解が深まればとおもいます。
あわせてよみたい（10年近く前の個人ブログで似たようなこと書いてた）：
Discussion