こんにちは。BASE株式会社の開発担当役員、かつ、子会社でPAY.JPを提供するPAY株式会社の取締役をしている藤川です。
JTC（Japanese Traditional Company）などと呼ばれたりする主に日本の歴史ある大企業のDX化の文脈において、バイモーダルITという考え方があります。JTCたる既存の大企業は、SIerが構築した基幹システムをITの根幹として事業を運営していましたが、昨今叫ばれるDXの取り組みにおいて、本業における顧客接点以外にITシステムでも顧客接点を実現していくための組織を整理する手段としてバイモーダルITという考え方を使うことができます。
考え方として、SoR（System of Record）と呼ばれるデータを記録することに重きを置く既存の基幹システムと、SoE（System of Engagement）と呼ばれるエンドユーザとの結びつきを実現するためのシステムに分類し、前者がミッションクリティカル性を最優先に、後者をアジャイルプロセスなどを使ってスピード重視にするという分類です。
この２つのシステム分類を見極めた上で、それぞれに見合った開発手法や組織を考えるべきというのがバイモーダルITで語られている部分で、DXを通じてSoEのシステムを実現するために内製化組織を作ることを目指す場合は、このことへの深い理解が不可欠です。
すでにインターネットに対する深い知見を持っている人たちは活躍されていて、例えばクレディセゾンでCTOをやられている小野さん、またイオングループにおいても本体のCTOである山崎さんや、イオンネクストの樽石さんが活躍されている代表的な事例として挙げられると考えています。
更に、最近はSoI（System of Insight）という言葉もあり、主にデータ分析によるアプローチのことを示すようですが、生成AIも活用も含めてAIネイティブなシステム分類があってもいいかもしれませんね。
BASE社におけるSoE,SoRの考え方
さて我々、BASEグループは成り立ちがBASEという簡単にネットショップを作れるというサービスから始まりました。シンプルかつスマートフォンネイティブ、登録すればすぐに決済が使えるというサービス構成で、開始時点から好評をいただきスムーズなサービス成長を開始しました。
代表の鶴岡は起業当時、休学していた大学生でした。こういった若きスタートアップにおける勝ち筋は、基本的にSoEのプロフェッショナルにならないと成立しません。BASEも若い組織、若い開発メンバーのチームで多くのショップオーナーさんにお店を作っていただくことで、サービスのプレゼンスが上がっていき、JTCである大手企業のパートナーシップの実現やボリュームメリットによるコスト競争力などに繋がっていくことになります。
そして、最近、BASEの流通総額を超えて伸び盛りになっている当社グループPAY社が提供するPAY.JPですが、こちらはクレジットカードの決済サービスとなります。クレジットカード番号を取り扱うためのセキュリティ認証規格であるPCIDSS ver4.0にフル準拠する形で、サービス提供をしています。PAY社の代表の高野も起業当時は大学生で、BASE社に一度ジョインしてPAY.JPを立ち上げた後に分社化する形で子会社として独立しています。
共にスタートアップとして起業して、クラウドをネイティブに使い、ベンチャー企業としてスピーディな開発を進める２社ですが、改めて考えてみると、組織構成だったりサービスの構造が違います。
現在は、BASE社で開発を進めている購入者向けショッピングサービスのPay IDも、最初はPAY社が提供するID決済サービスでしたが、2021年にリブランドして以降は、BASE社にてPay IDアプリのバックエンド構造を作り直しています。こうなった経緯を当社における歴史的な流れとして考える時に、実は言語化しきれていない何かが理由としてあるんじゃないかと考えてみて、それがSoEとSoRという分類で考えるべきなのではないかと気が付きました。
BASEやPay IDアプリと言った、エンドユーザのフロントの接点を持つプロダクトがSoEというシステム、これはどちらかというとBASE社が得意とする領域です。一方で、クレジットカード決済APIを軸にサービス展開するPAY.JPは、なによりもシステムの安定性が求められることや、クレジットカード番号の繊細な取り扱いこそがファーストプライオリティだと考えると、SoRのシステム分類に整理した方がしっくりいきます。
BASEとPAY.JPは、クレジットカード決済におけるマイクロサービスの関係性であり、PAY.JPから見たBASEは、PAY.JP APIを使う一加盟店という位置付けになることからも、明確にレイヤーが違うことは認識していたのですが、SoEとSoRという分類で整理することが可能です。
Pay IDチームで開発している「あと払い（Pay ID）」というBNPLサービスもSoRのシステムなのだろうし、YELL BANKというサービスで、BASEの利用者に資金提供をさせていただいてるBASE BANKチームもSoRのサービスと言えるのかもしれません。
BASEグループは「Payment to the people, Power to the people.」というミッションでビジネスを考えていますが、システムという面からもSoEとして立ち上がったBASEというサービスに対して、より事業に深みを出していくというのがPAY.JP以降に始めたSoRのサービスが新規事業だと考えると、JTCとはまるで逆のベクトルで、バイモーダルITという考え方にアプローチしているとも考えられます。
しかも、JTCにおけるバイモーダルITは、ウォーターフォール開発等の既存開発プロセスに気を使わざるを得ない分類であるのに対して、我々は、クラウドネイティブ、オブザーバビリティ、継続的デプロイメント、アジャイル開発など、ネット系ベンチャーとしての標準的な開発環境や開発プロセスを取りながら、スピーディかつミッションクリティカルにサービス提供をしていることが特徴と言えます。BASEもPAY.JPも大体、同じような環境で仕事をしているので、あまりこの整理ができていませんでした。
今後もこの構造は際立っていく
これが具体的に開発組織に対してどう影響するかというと、おそらく....SoRとSoEを適切に意識していくことで、何を重視するかというプライオリティが変わることと組織構造に影響してくるんじゃないかと思います。
事業という区切りで組織が分かれるだけでなく、開発や運用スピードにも影響するエンジニアが重視するメンタリティで組織を分けることになる可能性は十分にあると思っています。そこには、開発を引っ張る開発組織とリーダーが必要で、それに向けて誰がどう活躍して個々の事業ドメインのトップエンジニアになっていくのか、ということになると思います。
みんなのお給料を上げるためには、事業を通じて会社を成長させるための組織構造をいくつ増やせるかというのがとても重要で、この整理をすることで、それに向けて頑張っていく構造を作れると思います。
また、全然違う話として、例えば転職ドラフトなどをやっていると「金融系には行きたくない」と書かれていることがあるのですが、ここで言う金融系とは、おそらくJTCにおける基幹システムを作ってるSIerで行われているレガシーなSoRシステムには携わりたくないということなのだと思います。
我々は、スタートアップ、ベンチャーとして、SoEと変わらぬ開発環境やプロセスで、ミッションクリティカルなSoRのフィンテックスシステムを作っていると考えると、この「金融系には行きたくない」という既存の価値観を覆していかないと、採用に苦労し続けるということになりますから、いかに我々は夜、ちゃんと眠れる会社であるか？ということをもっともっとアピールしていかねばなりません。
ちなみに実際のところBASEは、SoEとSoRの両方の要素を持っていて、大量のトランザクションを処理する決済システム、ショップの売上管理、顧客管理システムなどのSoR的な側面と、ストアフロントとしてユーザビリティ重視のSoE視点の両方を担っているのが現実なので、BASEはBASEで考えるべき幅が広くて大変なんですけどね。
それこそIT内部統制で求められているミッションクリティカル性と、ユーザビリティ重視のスピード型で双方に求められる部分が、開発者としてのお気持ち的にコンフリクトするのは、SoEとSoRの両方を抱えているシステムだからだと今気が付きました。それ故に、サービスの安定運用には技術力が求められ、面白みもあるというシステムでもあったりします。
当社で活躍するエンジニアも、金融やEC出身の人もいれば、ソーシャルゲーム出身の人もいるというのは、この両面があるからなんだと思います。そんな幅広いポートフォリオを持つBASEグループですが、もしご興味を持っていただいた方がいらっしゃったら是非、お話しましょう。
