【LayerX・バクラク事業部CTO/CPO】爆速開発を支えるバクラクチームとアーキテクチャのつくり方

スタートアップにおけるプロダクト開発でボトルネックとなりやすい組織づくり。組織に関して抱える課題は企業によって異なり、絶対的な正解は存在しない。それでも、他社事例を知ることで見えてくる解決策はあるはず。

本記事は、LayerX取締役で、バクラク事業部でCTO／CPOを務める榎本悠介氏から、バクラクの爆速開発を支えるチームとアーキテクチャのつくり方についてお話いただきました。
※本記事は、10月27日に開催されたイベント「SELECK LIVE! for Startup#2」のレポート記事になります。

• keyboard_arrow_down 成長に伴い、未分化の1チームから5チーム体制へ
• keyboard_arrow_down 体制変更の「4つの潮目」
• keyboard_arrow_down 立ち上がった「Layerone」プロジェクト

「LayerXといえば“爆速開発”というイメージを持っていただけていると思います」と語り始めた榎本氏。そんな世間のイメージに違わず、開発開始から約2年で、榎本氏はすでに5つのサービスリリースに関わってきたという。

「バクラク」では、「圧倒的に使いやすいプロダクトでわくわくする働き方を。」をビジョンに、コーポレート向けのSaaSを提供している。現在は、「経費精算」「請求書」「ビジネスカード」「申請」「電子帳簿保存」の5つのプロダクトを展開中とのこと。直近では「バクラクビジネスカード」をリリースしたが、（「あまり大きな声では言えないのですが……」とことわりを入れながらも）たった3ヶ月前後で開発してリリースしたことが明かされた。

そんな爆速開発を実現した背景から、発表は「チーム体制とアーキテクチャの関係」「チーム体制変更のきっかけ」という2つの観点で行われた。

まず、チーム体制について。バクラクにはプロダクトごとに縦軸のチームがあり、それとは別に、職能別の横軸のチームが5つある。これは、『チームトポロジー』(※)で言うところの「ストリームアラインドチーム」の形をとっているという。具体的には、各プロダクトにエンジニアとPdMが配置されており、機能にこだわり抜いて開発を進行しているそう。
※『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』マシュー・スケトン/マニュエル・パイス (著), 原田 騎郎/永瀬 美穂/吉羽 龍太郎 (翻訳)、日本能率協会マネジメントセンター

しかし、初めからこのようにスマートな組織だったわけではなく、当初は「バラクラ請求書」を開発する1つのチームしかなかった。しかも、チーム内には大まかな役割分担しかなく、職能の境界も曖昧だったとのことだ。

そんなバクラク開発チームの体制変更には、4つの潮目があった。

第1の潮目：新プロダクト「バクラク申請」の開発

第1の潮目は、「バクラク請求書」のリリース後、すぐに新プロダクトである「バクラク申請」をつくることになったこと。2つのプロダクトは密接にデータ連携を行う必要があり、マイクロサービスにするかモノリスにするか非常に悩んだそうだ。

「なるべくマイクロサービス化しよう！」というのが技術的なトレンドだが、榎本氏自身は過去、過度なマイクロサービス化で苦い思いをした経験があり、やみくもにトレンドを追いかける気にはならなかったという。

ただ結果的には、プロダクトごとに分割するマイクロサービスの道を選んだ。マイクロサービスにした理由について、単体でも成立するSaaSプロダクトのほうが、ドメイン境界として適切に見えたことや、同じタイミングで開発チームを担当機能ごとに小分けしたので、マイクロサービス化したほうがよりスケールしやすいことなどが挙げられる。さらに、プロダクトスケール後、モノリスからマイクロサービスに切り出すことに苦心している先人たちの姿も見ていたことから、バランスのよいマイクロサービス化を目指すことにした。

また、今後複数プロダクトを展開していくことを見越し、スケールしやすいように認証基盤や共通マスターなども、マイクロサービスとして切り出すことに。この選択は功を奏し、各チームが自立して動けるようになった結果、爆速で開発・運用を行うことに成功した。さらに、新しいプロダクトでは既存プロダクトにとらわれずに新しい開発手法を試すことができるので、チームに知見がどんどん溜まってきた。

一方、やはりマイクロサービス化による弊害もあるのだという。一番の問題は、データ同期がしづらいこと。また、循環参照を避けるために、将来のデータ構造を未来予知しながら考える必要があるのだという。
ご参考：絡み合うSaaSプロダクトのマイクロサービスアーキテクチャ

第2の潮目：各プロダクトにPdMを配置

エンジニアが貪欲に情報を取っていく文化が醸成されていたこともあり、ずっとチームの合議制で開発を進められていた。ただ、プロダクトが増えたことによって顧客やステークホルダーからの要望数が爆発的に増加。そこでPdMを置くようにしたところ、開発が上手く回るようになった。

第3の潮目：マネージャーを選任

榎本氏は開発の前線で立ち回るタイプで、マネジメント業の比率が高まっているのが苦しかったという。そこで各チームに新任マネージャーを計4名配置し、マネジメントする側・される側への研修を同時に行った。これにより、それぞれのマネージャーがアウトカムを出す意識を持てるようになったうえ、榎本氏も自身のリソースの9割を開発に集中させられるようになり、さらなる新規事業の立ち上げに成功したという。

第4の潮目は、まさに現在進行形のプロダクトで、メルカリやソウゾウでCTOを務めた名村卓氏がリードするEnabling Teamの発足だ。プロダクトの増加に伴って増加したデータ連携をスムーズにすることが目的だといい、マイクロサービスを管理しやすくするための基盤作りやモノレポ化など、攻めた技術構成を目指している。

このチームでは「Layerone」プロジェクトと呼ばれる取り組みを推進しており、「Blazing Fast – 爆速」「Fun to Build – 作る楽しみ」「No Struggle – 邪魔者がいない」「No Barriers − 全方位開発」という4つの注力項目を策定している。これにより、Developer Experience（DX／開発者体験）を向上させることがEnabling Teamの目的である。

榎本氏によると、「これまでのバクラクは、マイクロサービス毎の連携が密になっており、循環参照を避けられているのが奇跡と呼べるような構成となっていた」という。これを踏まえて「Layerone」プロジェクトでは、データ同期を極力なくす構成にしたり、循環参照を避けるためにマイクロサービスをプロダクト単位から、リソース単位に変更したりといった取り組みを行っているのだとか。

上図が示す通り、ユーザーからのAPI取得は全て同じGatewayを通るなど、アーキテクチャに秩序がもたらされているのだ。

ただ、「Layerone」プロジェクトによって、既存のチーム体制も影響を受けることが予想される。その点については「今後走りながら考えていきたい」とのこと。アーキテクチャに組織体制を合わせていく「逆コンウェイの法則」を体現している好例だと言えるでしょう。

マルチプロダクトを高速に展開する中で、組織もアーキテクチャも常に変化しているバクラク。「これからも柔軟に、先手を打って投資していき、お客様に良い体験を届けていきます」と榎本氏は今後への決意を語った。

整った環境で爆速開発を行っている印象のあるLayerXですが、常に理想と現実の落とし所に悩みながら進んでいるとのこと。

「LayerXにはまだまだ実現したいビジョンがあります。しかし、やりたいことに対してチームの拡大が追いついていない面もあります。ですから、もし興味のある方がいらっしゃいましたらぜひお声がけください」そんなメッセージでセッションを締めくくった。

文：伊藤 祥太