前回の記事が思ったより反響があったので、今回もDXという文脈で感じたこと、学んだことを書いていきます。僕は過去にSI案件の業務システムの開発に携わってきた他、複数のB2B SaaSの新規事業、開発に携わってきて、主にB2Bのソフトウェア開発を主戦場としてきました。昨年からB2Cサービスを主にやってきたWEBエンジニアと一緒に働くことが多くなり、そこでこれまで前提としてきた視点の違い、B2Cで培われる能力、2Bで特に求められる視点について振り返る契機になりました。
DXという言葉の流行とともに、これからB2Cサービスに携わったエンジニアがB2Bサービスに携わることが増えてくるでしょう。B2C,B2Bなど様々なバックグラウンドのエンジニアチームが生まれると思いますが、視点の整理の一助になれば幸いです。
この記事では
について考えることを書きたいと思います。
- WEBエンジニアがB2Bのソフトウェア開発に関わる選択肢が増え始めた
- B2Cプロダクトの方がWEBの世界で技術実験しやすかった
- テックタッチ型のB2Bサービスの隆盛で実験しやすい環境に
- B2Bは「現実」を前提に設計する
- まとめ
WEBエンジニアがB2Bのソフトウェア開発に関わる選択肢が増え始めた
2010年代を振り返ると、WEBエンジニアの人気となっていた企業の生業はソーシャルゲーム・フリマアプリ・SNS・マッチングアプリ・メディア・動画サイト・ECサイト・検索エンジン・広告…こうして並べてみるとほぼtoCでした。この時期のフィクションで出てくる若い「IT社長」のイメージも「モバイルゲームアプリで一発当てた」等がステレオタイプだったように思います。
一方で、ここ数年はスタートアップからB2Bソフトウェアの会社が隆盛しています。2019年にIPOした名刺管理サービスのSansan、SMB向けの会計ソフト等のfreee、2013年に創業のSmartHR、財務情報提供のSPEEDAを運営するユーザベース、電子契約のクラウドサインの弁護士ドットコムなどWEBスタートアップから急成長している事例が多くあります。
ここ数年のB2B SaaSは動きが目立ってきて、これまでキャリアの選択肢に入れていなかったWEBエンジニア、特にスタートアップ界隈でコードを書いてきたエンジニアからの視線も増えたように思います。
売上規模でいえば、SMB（中堅・中小企業）向けの長年事業運営されている会計ソフトなどもありますが、昔はWEBというよりもインストール型のソフトウェアの文脈で見られていたように思います。（尤も、ほとんどの企業は数年前からクラウド製品に注力をしています）
B2Cプロダクトの方がWEBの世界で技術実験しやすかった
B2B型と比してB2C型サービスでは新しい技術の実験がしやすかったように思います。B2Bサービスで極端な例を出すと、僕は消費財メーカーで販売管理の受注に関わる基幹システムに携わっていました。ここではEDI（電子的な注文システム）から来るデータを元にデータベースに受注登録するという機能に関わっていたのですが、受注から数時間後に製造し、数時間したら出荷をするというオペレーションが組まれていました。この受注のシステムは24時間稼働で、1時間も落ちれば1日の業務に支障が出てしまう、ミッションクリティカル性の高いものでした。必然、枯れた技術で間違いがおきないように開発されるものになり、特に変化が多いものでもないので新規技術による実験よりも安定性が求められます。
B2C事例として、ソーシャルゲーム出身のエンジニアと話すと、素早く新しい機能であったりイベントであったりをリリースしてより良いユーザー体験を提供することが第一で、最悪「詫び石」を配って解消できるリスクなら飲んでスピードを重視する、という意思決定をしてきたという話をよく聞きます。もちろんサービスが停止するとその分売上にも直結しますし、ユーザー体験を大きく損うものでもあるので起こさないに越したことはないのですが、取り返しのつかない失敗でない以上、素早く良いユーザー体験を提供するリターンを取る意思決定が多くあるということでしょう。
新しい技術を実験しやすい環境の方が腕を磨きたいエンジニアには魅力的に映るでしょうし、B2Cプロダクトがキャリア選択肢として有望だったのではないかと思います。実験を繰り返すことでB2Cサービスで技術やWEBサービス方法論が磨かれてきました。 （ソーシャルゲームと一括りにしましたが、企業向けにゲームのAPIを提供しているB2Bのケースなどは非常に安定性を求められるというケースも聞いています）
テックタッチ型のB2Bサービスの隆盛で実験しやすい環境に
実はB2B,B2Cという分類も正確ではないと考えています。過去に少し書きましたが、SaaSにはハイタッチ・ミッドタッチ・テックタッチという分類があります。ハイタッチは1対1で手厚いサポートを行うサービス形態。テックタッチはユーザー自身にセルフケアしてもらう形で自由に使ってもらいます。B2Cサービスを当てはめると、ほとんどテックタッチ型といえます。ソーシャルゲーム・ECサイト・広告などは事細かに人がついて使い方を教えるモデルではありません。ゲームを例に取るとほとんどはチュートリアルをゲーム内で行うテックタッチモデルでしょう。
WEBという文脈で考えた場合、日本国内においては2Bサービスはハイタッチ型が多かったのではないかと思います。SIerの請負開発モデルはまさにハイタッチ型で、ユーザーから事細かにヒアリングして業務に適した形のシステムを綿密に設計開発します。（海外ではミッドタッチ・テックタッチとも言えるSaaSのSalesforceなどもありました）
2010年代後半で国内でもテックタッチ型のB2B SaaSが流行ってきました。2Bにおいても、失敗できない分野ばかりというわけではありません。受注や調達といった部分はなかなか失敗できませんが、間接費に関わる部分である会計（管理会計含む）、人事領域、分析システム、営業支援システムといった領域は24時間稼働の受注や調達などよりは相対的にミッションクリティカル性は落ちます。（締め日など落としてはいけないタイミングはありますが）そのような相対的にまだ「変化させやすい」システムである間接業務領域などについてはリリースによる改善サイクルをたくさん回し、技術的な挑戦をしやすい経験を作ってきたのではないかと推測します。
会計（管理会計含む）、人事領域、分析システム、営業支援システムなどを例に挙げましたが、freee、SmartHR、SPEEDA、Sansanのようなプロダクトを思い浮かべて見てもらうとイメージしやすいでしょうか。
特に、テックタッチであればユーザー数も多く、改善のためのフィードバックも多く取得できます。そのようにインターネットを通して多くのユーザーにアプリケーションを提供し、改善を繰り返す提供形態をとるビジネス形態、そして新規技術にも挑戦しやすい環境が整ってきたということではないでしょうか。
個人的には、無くなると社会に支障が出るようなソフトウェアを提供したいと思っていたので、業務システムにずっと軸足を置いてきましたが、一方でハイタッチ型の選択肢が主流の頃は新規技術をなかなか適用しづらいケースもあり、提供したい内容とエンジニアとしてのスキルアップというところに葛藤することもありました。ここに、一つの選択肢としてB2B SaaSの道が出てきたのは良いことではないかと思います。
そして、B2Cで多くのユーザーにサービスを提供する中で確立されてきたプロダクト方法論がB2Bにおいて活かされる時代になってきていると思います。
B2Bは「現実」を前提に設計する
さて、やっと本題です。B2CのエンジニアとB2B領域で仕事することが増えてきました。リリースサイクルの高速化、新機能の素早い実装などは培ったものがあるのですが、要件や設計においてはB2B独自の流儀に戸惑うことも多かったように思います。
B2Cは体験の設計の自由度が高いのに対し、B2Bは「現実」、「現状」を前提にしなければいけないのが大きな理由のようです。
業務コンサルティング等のプロジェクトでは「AsIs（現状）」、「ToBe（あるべき姿）」という言葉がよく使われます。あるべき姿を描いてから、現状分析を行なってギャップを埋めていく、というアプローチです。現状を把握しないであるべき業務を描いても、実現性のない絵に描いた餅になってしまいますから、「ToBe」を描きながら「AsIs」と調整していきます。
上の図は、「AsIs」、「ToBe」を「業務」、「システム」に分類した４象限です。B2B（業務・システム開発）、B2Cの開発についてそれぞれ枠で囲って視点を整理しています。
- B2Bで多い視点①は、業務ギャップを判断し、業務の現状(AsIs)を見ながらあるべき業務(ToBe)を考えます。業務コンサルなどが担ってきた役割です
B2Bということは、設立したての会社でない限り既存の業務がありますから、AsIsの分析を行います。またAsIs分析の中で様々な理由で業務を変えられないような制約が見つかればそこについてはToBeを調整し、描いたToBeを現実性のあるものとして業務にフィットさせていきます。
- B2Bで多い視点②は、システムギャップの視点で、システムの現状とのギャップを意識しながら、あるべき姿を設計・開発します。古くはSIなどが担っている役割です
業務システムの開発面においてもAsIsのシステムとあるべきToBeシステムについて、業務コンサルティングと同様のアプローチでギャップを明らかにしていきます。業務システムがない会社であれば考えることは減りますが、大なり小なりシステムは存在していますでしょうし、小さいもので言えば業務システムの代替品としてエクセルであったり、会計ソフトなどは大概の企業で保持しています。そこのシステムに加えて既存システムからのデータ移行可能かなどAsIsの分析は必須になります。
- B2Cで多い視点は、ToBeに絞って徹底的に素早く体験を作り込むこととしています。
これはToBeが定まれば、B2Cに限らない話ではありますが、あえて分けています。B2C向けのゲームアプリなどで、AsIsの制約というのは上2つで見てきた業務効率化と比べると制約条件は少ないはずです。AsIs、ToBeのフレームに当てはめると、ToBeは「あるべき体験」と考えられます。体験を磨き込んでいくこと、また新たな機能やイベントなどを実装してあるべき体験を増やしていくなどが優先されるかと思います。（あえてAsIsの制約に踏み込むとすると、想定ユーザーのスマホスペックなどの動作環境、ネット回線などはあると思いますが、今回の本論ではないので言及はしません）
B2Bでは既存業務/システムというAsIsがある以上、考慮事項が増えて視点が広がる節があるように思います。業務システムでは、業務ギャップ、システムギャップを追うための現状業務やシステムの解析において、BPMNやDFDといったツールを使いますが、B2Cのバックグラウンドのみのではこのあたりに馴染みがなく戸惑うこともあるようです。実際にB2Cのバックグラウンドで凄腕のエンジニアに、エンタープライズのシステム案件で「ゲーム等のアプリでは使わないのに、なぜ業務システムではDFDを使う必要があるのか」と問われたことがあり、「複雑な現状の業務やシステムを強く理解する必要があるから」と答えました。それより早く開発した方が良いのではという気持ちがあったようにも思い、重視する視点の違いを感じたシーンでした。
※大雑把に画像の色付けはしていますが、常にこれが正というわけではなくToBeの業務とシステムを見て作り込むことはB2Bシステムでもありますし、B2Cにおいてもユーザーの普段の行動様式をAsIsとして捉えた方が上手くいくこともシーンによってはあります。また、前回の記事で述べた通り、システムを意識しながら業務ToBeを描くのが必要であることも留意してください
まとめ
この記事では
について書きました。B2Bサービスにおいて、エンジニアが挑戦しやすい環境がととのってきたというのがここの数年大きな変化かと思います。そして、B2Cで確立されてきたプロダクト方法論がB2Bにおいても活かされる時代になってくるのでしょう。そこで「現実・現状」を意識しながら開発するというこれまでSIや業務コンサルなどが培ってきたスキルも求められてくるでしょう。
最後に「上流」という言葉は前回終焉と書いたので好きではないのですが、業務システム開発を学ぶときに役立った本を掲載しておきます。
- 作者:渡辺 幸三
- 発売日: 2003/10/17
- メディア: 単行本
関連記事
