toB か toC かはエンジニアにとってどんな違いがあるか

「toB と toC で言えばどちらのサービスに携わりたい？」

割とよく聞かれる質問です。
「toB はカッチリしていて toC は華やかなイメージあるなぁ」ぐらいで考えてもいいかもしれないですが、実はこの区分、ターゲットとするユーザ層や文脈がガラリと変わるので技術的な側面でも結構な違いが発生します。

なのでこの記事では具体的にどんな違いがあるのかを考えていこうと思います。

1.ユーザ数

基本的に toB は契約数百から数千社に対して toC は数万、数十万のオーダーをターゲットにすることが多いです。なので toC の方がユーザ数は多く、パフォーマンスに関しては難易度が上がりやすい傾向にあるのではないかと思います。

2.対応する画面幅やブラウザ

toB ではスマホを対応する必要があることがほとんどありません。なので、PCだけのデザイン対応で済んだりします。これは結構考えること減って楽ちんです。
対して toC では両方対応する必要がありますが、最近ではPCユーザの比率はどのサイトでも 1-2 割なので、PCは手抜きで作る事例も最近は増えてきているように思います。

ちなみにこちらは、スマホのレイアウトを保ちつつも右にハンバーガーメニューの中身を表示し、PCのレイアウトも整って見える賢いレイアウトの例です。

https://takaone.jp/

また、 toB はPCだけで楽ちんとは言いましたが、IE11 などのレガシーブラウザを使っているユーザの比率が高くなりがちなので、その点で不毛な体験をすることはあるでしょう。
ただ、これに関してもいい加減 IE がサポート切れされるのと、 IE11 非対応を宣言する企業が増えてきていることから潮目は変わってきているのかなという印象です。

3.初期表示のパフォーマンス

昨今のフロントの SPA 開発では初期表示のパフォーマンスを良くするためにサーバー側で事前に HTML を生成しておく工夫がとられています。
離脱に関してシビアな toC では採用するメリットは高いと思うのですが、個人的には toB では微妙かなとも思っています。SPA あまり工夫せずにそのまま配信したら初期表示に 2-5 秒くらいかかってしまうのかなという肌感ですが、それが原因で解約に至ることはほぼほぼないと思うからです。
SSG or SSR はやり方にもよりますが追加工数が大なり小なりかかるものなので、toB の方はここに工数を割かなくする判断は十分納得感あるものだと思います。

4.ユーザとの距離感

toB では規模感にもよりますが基本的には営業やカスタマーサクセスなどの接点があるため、ユーザからのフィードバックが得やすいと思います。
toC でももちろん工夫すればインタビューなどはバリバリできるしユーザコミュニティなども作れると思うのですが、より近い距離で関わりやすいのは toB なので、ここが一個魅力にはなり得るんじゃないかなと思います。

5.toB は UI をガラリと変えてはいけない(とよく言われる)

toB の開発に携わってるとよく聞く(自分の周りだけ？)のが「B向けのサービスは UI の大幅な変更はしづらい」という話です。真偽のほどは定かではないですが、確かに日々の業務で使うものなのでガラリと変えたら反発くらいそうというのは想像できます。

そもそもそんな反発もらうリスクがあるレベルで UI をガラッと変える機会はあまりないと思いますが、もしかしたら焦ったく感じる瞬間はあるかもしれません。

6.アニメーション

何となく toC の方が激しめのものを要求されることが多い気がします。ただ、 toB は toB でグラフとかデータビジュアライゼーション系で激しめのものを要求されることがある気もするのでどっこいどっこいかもしれません。
言い出しておいてアレですが、ここは toC とか toB とかあまり関係なくプロダクト依存な気がしますね。

まとめ

ざっくりまとめると toC の方が技術的な難易度が高い傾向にあり、技術的な挑戦を求める方にはハマりやすいのではないかと思います。対して toB はユーザとの距離が近くプロダクトの改善自体を楽しみやすい傾向にあるのではないかと思います。

結局は個々のプロダクトによりけりではありますが、ぼんやりしたイメージとしては上記のようなものを持っておくといいかもしれません。