開発現場におけるtoB/toCとは？

最初に

エンジニア歴1年の若手エンジニアが自分なりに気づいた点をまとめさせていただきます。

経験が浅い分、当たり前の事を言っていたり偏った内容になっている可能性がございます。
そういった記述が散見された場合はご容赦いただけますと幸いです。

SESエンジニア、フリーランスエンジニアの方で、
これから案件を「toB⇨toC」のように切り替える際に、私のようにギャップを感じる人が少なくなれば、という思いで記事を書かせていただきます。

※あくまで体験した事に基づいて記述させていただきますので、必ずしも記述通りではない事はご了承ください。

背景

私は準委任契約にて現在の案件を含め3つの案件に携わらせていただいております。

• 1つ目の案件(管理者向け 自社ツール)：顧客・契約情報管理システム開発
• 2つ目の案件(管理者向け toB向けツール)：倉庫管理システム開発
• 現在の案件(一般ユーザー向け toCサービス)：一般ユーザー向けコンテンツ配信サービス開発

以上のような経歴となっており、10ヶ月程、toB向けないしは自社向け管理システムの開発に従事しておりました。
今回、初めてtoC向けサービスに携わるにあたって設計段階から開発内容、サービス運用にあたって違いを感じる場面が多々ございました。
拙いですがそんな経験を元に、これからtoBもしくはtoCの案件で切り替える方に向けて少しでも足しにしていただければと存じます。

※toB向けサービスと自社ツール(管理者向けツール)を一緒にすると厳密的には違うのは承知しておりますが、今回はtoC向けサービスか否かで記述させていただきます。

障害発生時の影響範囲の違い

• toBの場合(管理者向けツールの場合)

  • 管理者向けサービス(自社ツール)の場合、障害発生時に影響を受ける対象はコールセンターのオペレーターや営業担当等。

  • 具体例で言うと、CRMを使用するコールセンターのオペレーター等が架電/受電する際に大きく影響を受けるかと思います。

  • 言い換えると、業務全体がストップ(お客様からの架電に際して情報照会が出来ない,契約情報の登録ができない等)してしまう為、直接的に売上に響かないにせよ業務運用する方々の人件費や作業ができない事による残業代などのコスト面(原価)にも影響を及ぼす事となります。
    特に業務運用の要員(コールセンター)として登録型派遣の一般派遣を利用している企業などではサービスの停止時間がそのまま余分な人権費となる可能性もあり、開発者の考慮漏れ一つで様々な悪影響を引き起こす事が考えられます。

• toCの場合(一般ユーザー向けサービスの場合)

  • toC向けサービスの場合は、サービスの利用者がそのまま影響範囲になりえると思います。
    サービスの規模感にもよりますが、影響範囲は自社向けツール(CRM),toB向けの管理者向けサービスに比べて大きくなる場合が多いかと思います。
    (社員の数が多かったり、利用企業が多くエンドユーザーの規模が大きいパターン等を考えると簡単に比較できるものでもないとは思いますが。)

  • 一番重要なポイントで言うと障害発生した場合、エンドユーザー様がサービスを利用できなくなってしまう事です。
    対象が無料会員の場合はそこまで大きな被害になりえないかもしれません。
    (語弊が生じそうですが、もちろん全てのエンドユーザー様が気持ちよくサービスを利用できる事は前提です。)
    ただ、有料会員向けのサービスの場合、少し話が変わってくるはずです。
    エンドユーザー様視点でお金を払っているにも関わらずサービスを利用できる事ができない状態が生まれてしまいます。

  • toB向けサービスでは、サービスが停止してしまった場合もなんとか運用でカバーできる部分もあるかと思いますが、toC向けサービスでは中々そうも行きません。
    障害発生事になんとか対応(運用でカバー)しやすいtoB向け(管理者サービス)に比べて、toC向けサービスでは一度障害発生してしまうと根本を解決しない限り中々対処しきれない部分が存在し大きく違う点でもあるかと思います。
    開発者はそういった観点を常に意識して業務に従事していく必要があると思っています。

ユーザー数や層の違い

サービスを利用いただくにあたっての考慮

• toBの場合(管理者向けツールの場合)

  • 「ユーザー数 = (業務運用者 || 登録している企業数)」
    toB向けのサービスを利用する層は、上述の通り。
    利用目的も各企業の業務を行う為のものになります。

• toCの場合(一般ユーザー向けサービスの場合)

  • 「ユーザー数 = サービス利用者」
    toBにも存在するとは思いますが、toC向けサービスはより色濃く会員種別(無料 or 有料)を設けたりするイメージがあります。

  • 特に私の経験した自社向けツール開発では存在しなかった「有料会員」or「無料会員」の考慮点は、設計、開発時において大きく違う印象を受けました。
    ※自社向けツール(管理者向けサービス)にも権限レベルの切り分け、代理店の操作権限等存在するかと思いますが、有料会員or無料会員の操作制限に関しては通ずるものがあるかと思います。
    (大きく違うのは、お金を払う事で利用できる機能か否か。)

UI/UXの考慮点の違い

• toBの場合(管理者向けツールの場合)

  • 基本的に利用者の環境は社内で支給されているPC、指定のブラウザ等の為、
    考慮すべき点は派手な装飾や見た目の綺麗さよりも機能の使い易さかと思っております。
    (toCがこの考慮点を無視していいという話ではない。)
    UXには十分注意する必要があるかと思います。

  • 例えば顧客情報や契約情報、契約の支払い方法を登録するフォーム操作は項目が多くなり複雑になっていきます。
    その為、「文字列や整数値を受け付ける」等の単純なバリデーションに留まらず、
    ドメイン面を深く考慮したバリデーションが必要になるかと思います。

  • 例で言うと既存の情報登録フォームがかなり複雑で、「予期しない値(親子テーブルで整合性が図れない)がDBに登録されてしまう」という事がありました。
    こちらの例の場合、何を対策しておけばよかったのかというとバリデーションによって弾く事ももちろん大前提ですが、「情報登録」という操作を行う上で利用者が極力脳死で入力しても迷わないUX設計が大事になるのではないかと感じました。

• toCの場合(一般ユーザー向けサービスの場合)

  • toCで考慮すべきポイントは下記の通りです。
    (正直なところ管理者向けツールを開発する際、私の場合は下記を気にする必要がほとんど無かった為、ギャップを感じたポイントの一つになりました。)

    • 端末依存の考慮
      利用者は不特定多数のため、スマートフォンを利用するのかPCを利用しているのか考慮する必要がある。

    • OS依存の考慮
      代表的なOSはiOS,iPadOS,Android,Windows,MacOS。
      また各OSのverによってJavaScriptのメソッド対応可否が存在する為、注意が必要。
      ※実際にDOM操作を行うにあたってverによる差異が生じた事があります。

    • ブラウザ依存の考慮
      Chrome,FireFox,Edge,Safariの有名どころを各ブラウザにて検証。

    ※ブラウザのサポート状況等は下記を参考にすると良いかと思います。
    　・JavaScript リファレンス
    　　https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference
    　・ブラウザサポート一覧
    　　https://mobilehtml5.org/

その他、個人的に面白いと感じた点

私が開発業務に従事して特に面白いと感じた機能は、ログ記録についてでした。
ただ同じ「ログを記録する」という動作でも、記録したログの利用目的が違う事にギャップを感じる場面がございました。

　- toB向けサービス(管理者サイト)：セキュリティの観点上、「誰が」「どの画面(URI)で」「どんな操作をしたか」記録する。

　- toC向けサービス：機能の使用頻度からサービス発展の為に次の施策を練る為に使用する。

以上のような違いがあり、ログ一つでも違いを感じる事ができました。
toC向けサービスでは管理者サイトと比べてマーケティングの色も出てくる気がします。
(要件定義、設計段階においてもプロダクト開発を行う上で何が求められているのかを意識する事が重要だと感じます。)

最後に

文字だらけの記事となってしまいましたが、ここまで閲覧いただきありがとうございました。
まだまだ経験が浅い分、おかしな部分もあるかとは思いますが、これから業態が大きく違う案件に参画する方にとって少しでも活かしていただける部分があればこの上なく幸いです。