スマートバンク社は、シリーズBの資金調達を実施いたしました。これからB/43事業をさらに拡大させていきつつ、組織も急拡大させていかなければならないフェーズに突入していきます。今回はこれまでエンジニア組織がどのように拡大、組織編成を辿ってきたかの軌跡を振り返ると共に、これからどのようなギアチェンジが必要かを綴っていこうと思います。

創業 ~ シリーズAまでのエンジニア組織

B/43というプロダクトは昨今のスタートアップがプロトタイプをシュッと立ち上げて、すばやくPMFを検証していくスタイルではなく、そのプロダクトの特性から立ち上げに多くの時間と労力が掛かりました。プロダクトのコンセプトを決めて、実際にローンチするまでに約1.5年程度は掛かっているかと思います。

ここからは創業からシリーズAの資金調達を行なっていく上で、CTOがどのようなことを考えて、エンジニア組織を見ていたかを解説していきます。

チーム立ち上げ時の組織コンセプト

立ち上げ時から、強く意識していたことがあります。それは技術的にスペシャリティを持ったチームを立ち上げることです。B/43は Fintech というサービスの特性上、どの領域をとっても複雑さに向き合う必要があり、それぞれの領域でキチンとした技術選択、実装を行なっていけるエンジニアが必要でした。

[例]

バックエンドのシステムはお金を1円のずれもないように管理したり、決済を高速で捌いたりといった堅牢性が求められる
インフラはPCI DSSへの準拠やVisa、印刷工場といった複数のベンダーと通信制御する必要がある。ユーザーが24時間/265日お買い物できるように稼働させ続けないといけない
モバイルアプリは、お金管理やカード発行、決済、eKYC、入出金と非常に多くの機能をシンプルで分かりやすく提供する必要がある

そのため、創業初期から何でもできるフルスタック的な人材ではなく、バックエンド、SRE、モバイルアプリといった各専門領域でエンジニアを採用しながら、サービスインから2年ぐらいはワンチームの構成で開発を進めてきました。

当時の開発案件の進め方

サービスを立ち上げたものの、リリースしてからの2年はまだ、B/43のサービスの中でユーザー課題を解決しマネタイズするための一連の機能が揃ってはおらず、どうすればそこに最短でたどり着けるかというのが課題でした。

開発組織は足りない機能をガンガン作っていくために、3~4名のプロジェクトチームを都度組成し、リリースした端から、また違うチームを組成し、といった形で、プロジェクトごとにその時々で臨機応変に対応しながら開発を進めてきました。その時はこれが、一番スピードが出る組織構造でした。

これがなぜ可能だったのか？

こういった体制で開発を進めるのが一番早く、また体制的に可能だったのは以下のような要因があったからと認識しています。

ユーザー課題のXXを解決する、マネタイズのためにXXを開発するといった、不確実性の少ない開発プロジェクト
シニアな開発メンバーが多く、自律的に開発を進められるメンバー個人のスキルの高さ

ある程度開発要件が明示的であり、メンバー個人のスキルも高かったことから数ヶ月 ~ 半年に及ぶ開発プロジェクトを次々と片付けて、人によっては兼務もしながらアウトプットしていくことが可能でした。

2023 ~ 2024年での開発組織の課題

しかし、事業が成長し所属するエンジニアが20名を超えてくる中で、2023年頃から下記のような課題が潜在的、顕在的に発生し、開発チームの組織化を行なっていく決断を行いました。

組織構造の問題

前述の通り、チームを立ち上げてリリース後解散し、また違うチームを組成するというコンセプトは、スピードと引き換えに下記のような課題が顕在化していきました。

エンジニアが断続的に複数のプロジェクトを担うことで、保守効率性が悪くなってしまう
チーム内のメンバー同士の良い関係性や、ナレッジの蓄積ができていた部分が、チームの解散時に失われて、結果属人化してしまう

当たり前ですが、機能はリリースして終わりではなく、追加開発や保守といった観点でも開発が必要になります。サービスが大きくなりユーザーが増えるたび、そういった仕事も増え、過去にこの開発していたのはAさんだけど、今は別の案件をやっているしな…といった問題や、チームとしてバディを組んで上手くやれていた開発方法やチームでのナレッジが都度リセットされてしまい、チームビルディングのコストが高くなってしまっていました。

マネジメントへの対処

前回の起業時の反省から、組織が拡大していく中で、権限移譲のタイミングを見誤らずに素早くチームを拡大していくことを意識していました。エンジニアが20名目前になるまで、私自身が1on1 や評価などを行なってきましたが、CTOとしての諸業務を行った上で、10数名のエンジニアに対してキチンとマネジメントができているかでいうと、否という状態が続いており、とりわけピープルマネジメント領域での仕事を移譲する必要がでてきました。

開発不確実性への対処

2023年に入ると、目の前の開発しないといけないタスクは落ち着き、開発した機能をフックにKPIをどう伸ばしていくか？これからユーザーに価値を提供していくにあたって、どのようなサービスコンセプト、ドメインを掘っていくか？といった、より抽象度が高く、企画にも一定の時間をかけないといけない開発案件が多くなってきました。

開発チームもそういった事業の作り方の変化に合わせるべく、中長期的な目標やフォーカスする事業領域に対して寄り添いながら開発をしていく必要が生まれてきました。

現在の組織構成について

上記のような問題をクリアにするべく、2023年の後半から下記のポイントを押さえた組織変更への移行を行い、EMといったロールも整備しながら体制変更を行なっています。

短期的に解散しない、中長期的に固定されたメンバーで開発チームを作る
CTOと連携してピープルマネジメントや組織課題の解決を担うロールとしてEMを配備し、チームに必ず1人存在するようにする
特定の事業を伸ばすコンセプトに沿ったチームを組成し、チーム間での兼務はしない

具体的には達成したい事業領域に合わせて、エンジニアが2 ~ 5名程度所属するチーム（EMもチーム内に必ず存在し、近い距離でマネジメントを行う）を複数組成して、開発を行なっています。

EMも現段階では専任ではなく、プレイングEMとして開発しながらマネジメントを行なってもらっています。開発とマネジメント両方の仕事を進めることは非常に困難で、どっちつかずになる状況を避けるために、1チームのメンバー数を3 ~ 4名程度に抑えることでマネジメントコストを下げる体制にしています。

現時点での課題

現行体制に落ち着いてから約1年ほど経ち、組織の構造としては安定していく兆しが見えています。各チームでの開発の進め方や、マネジメントの主務をEMが担いつつ、各チームが達成したいミッションにフォーカスした開発が軌道に乗ってきていると言えるでしょう。

しかし、シリーズBの資金調達を経て、今後さらに開発を加速していく上で下記のような課題感も持っています。

チームとシステムドメインが完全に一致していない箇所において、担当するチームがいないタスクが溢れる
課題解決のためのソリューションに不確実性が伴う部分が多く企画フェーズが長くなりがち
1チームあたりの開発メンバーの増加によるマネジメント人材の不足
マネージャとメンバーのセットでチームを組成するため、新しいチーム組成時のコストが高い

さらにいうと、それぞれのチームが直面している機能開発においても技術的にも難しい課題が多く、それだけに取り組み甲斐もあるのですが、圧倒的に開発メンバーが不足している状態でもあります。

これからの組織について

これまで約5年間で多くの機能をリリースしてきましたが、これからは特定の領域にフォーカスしながら、より抽象度の高い課題に向けて開発生産性を高めていく必要があると思っています。

開発生産性について議論する前に知っておきたいこと #開発生産性 - Qiita

生産性にも1~3のレベルがあり、イメージとしてはレベル3生産性につながる、レベル2生産性を意識した、チーム運営や施策を早く実行できるかが課題になってくると言えるでしょう。そのためには下記のような Try を組織的に行っていく必要があると考えています。

ミッションに対して十分なエンジニアが配属されるように、採用活動を加速させていくこと
チームをさらにスケールさせるために、EMロールを担える人材を抜擢していくこと
フットワーク軽くプロトタイプを開発し、素早くリリース、検証結果から改善しながら、レベル2 → 3に寄与する施策を数多く行なっていくこと

シリーズB以降の開発における技術的な面白さ

今後のB/43は、下記のような開発を行なっていく予定です。

ユーザーのキャッシュフローだけでなく、資産の管理を家計単位で実現していくこと
お金の使いすぎや、貯蓄といった人間がコントロールしにくいお金の管理をAIがサポートしていくこと
短期的な資金需要だけでなく、より長期的なライフプランに沿ったローンなどの資金需要に応えていくこと

その過程で銀行と連携し、資産データを保存していきながら、家計単位で資産管理できる基盤の構築やユーザーの決済データとAI技術を活用した家計改善のサポート機能の開発、ローン事業のための信用情報を元にした、与信 / 督促基盤の構築といった開発を行なっていく予定です。

b43.jp

Fintech は規制や法律などに準拠しながらシステムを作る必要性があり、設計の難易度が高い部分があると感じています。だからこそエンジニアとして、それらを踏まえた上でシステム仕様をどう作っていくか、保守性や拡張性をどう維持していくかという、アーキテクチャや設計力などのスキルを伸ばしていく機会が多いと思っています。

また、AI技術の利活用や、非接触決済（ApplePay / GooglePay）、機械学習を用いた与信基盤の構築など、技術的に面白いテーマを今後も扱っていきますので、エンジニアとして関わると非常にやりがいのあるフェーズかと思います。