開発観点からプロダクト価値を最大化する〜バクラク新CTOのミッション〜

こんにちは！ 2024年1月より現 CPO の榎本（mosa）から引き継ぎ、バクラク事業部 CTO に就任した中川佳希です。 今回の記事では、CTO としてそのミッションを定めた背景とこれからのバクラクの開発について書いていきます。 あわせて引き継ぎや今後の開発について、Podcast も収録しています。こちらもぜひ！

open.spotify.com

自己紹介

大学在学中に複数企業でインターンを経験し、2013年に株式会社エウレカに入社しました。その後フリーランスを経て、2020年6月に LayerX にジョインしました。

入社前の LayerX はブロックチェーンのイメージが強く、技術課題も Solidity でのアプリケーションの開発でした。選考の期間は、会社としてブロックチェーン事業からのピボットタイミングでもありました。入社までの面談でブロックチェーン事業の経験からうまれた DX への課題とそこに対しアプローチしていく構想を初めて聞きました。それが DX事業部というバクラクの前身となる事業部で、はじめは社内の契約管理や手続きをデジタル上でシームレスに行うには？というところから、LayerX でのキャリアがスタートしました。その後、プロダクトのテックリードや開発チーム横断組織である Enabling Team に所属し、複数製品の開発に携わってきました。

DX事業部当時の社内業務整理とシステム的なシーケンス図

バクラクへの想い

2021年1月に最初のプロダクトである LayerX インボイス（現在のバクラク請求書受取）を一般公開しました。いちからつくり始め、最初のユーザーは社内のコーポレートチームということもあり、個人的にも思い入れのあるプロダクトの1つです。（全ての経理の方に使われるプロダクトになってほしい！）

開発を通して感じたのは、これまで社会人をしていながら、経理業務や稟議システムを無自覚に使っていたことでした。プロダクトマネージャーやコーポレートチームからインプットをしてもらい、現実の業務をシステム上に再現する作業を経験したことは、自分の思考をスイッチするきっかけの1つでした。どのようなことがシステム上では可能になるか、人がミスしやすい部分をシステムはいかにサポートできるか。例えば、受け取った請求書をOCRで読み取り、文字列をコピー&ペースト出来ると業務がどのように変わるのか。今も業務への観察とそれがどうすればスムーズに楽になるかという思考は、全てのチームに共通して根底にあると感じています。

3年経過した今ではプロダクトは5つに増え、単に数を増やしていくではなく、共通化された業務データと機能のインテグレーションを強みの1つにして成長してきました。2023年からは、特にコンパウンドスタートアップを掲げるようになりました。

comemo.nikkei.com

バクラク事業部 CTO としてのミッション

バクラク事業部 CPO/CTO を兼務していた mosa さんと、バクラクの開発組織にあう CTO の役割や技術的な意志決定について話をする機会がありました。プロダクト数の増加とともに技術領域を広くあまねくみて判断することは、1人の人間だけでは難しいフェーズだと感じていました。また組織拡大もあり、これまでの開発スタイルで局所最適に陥ってしまわないかも個人的に課題に思っていました。例えば、エンジニア組織で実装のみが優先された状態は個別最適です。仕様の検討や QA、リリース後のユーザーサクセスまでの全プロセスがプロダクトにとっての全体最適の要素1つ1つであるということです。エンジニアチームがどのように開発をするかで、その後の組織やプロダクトに大きな影響を与える、またエンジニアリングでプロダクトに貢献出来る余地はとても大きいと考えたてたミッションが下記です。

「開発観点からプロダクト価値を最大化する」

バクラク事業部 CTO をやりたいと自分の意志として伝えてから、mosa さん、VPoE である小賀さん、Platform Engineering マネージャーの名村さんを交え、改めて体制とやること・やらないことについて話をする機会をいただきました。最大限に理解を示してもらい、自分としても役割の整理が出来たのは非常に大きなことでした。

その際に話したミッションをより具体にした「やること」は大きく3つあります。

1. 開発チーム横断でのテクノロジーマネジメント
   • プロダクト間の接続やアーキテクチャ設計
   • プロダクトチームと Platform engineering チームの接続
2. 開発から顧客へのデリバリまでオペレーションマネジメント
   • プロセスの全体最適
3. コードを書く
   • プロダクトの機能開発、共通的なシステム開発

また以下の2つは「やらないこと」として定義して、これまで通りCPOやVPoE、エンジニアリングマネージャーが担う整理としました。

1. プロダクトへの意思決定
2. 組織、ピープルマネジメント

「やらないこと」に対して補足すると、協力することが前提にあり、そのうえで意思決定者を明確にして、情報やリソースを集約するために設けたものです。それぞれが持つミッション達成のために、集中できる状態、ゾーンをお互いにどうつくっていくかが目標にあります。

Greg Brockman のブログ記事 #define CTO OpenAI に、創業期に運用上タスクをだれが引き受けるか（だれに持たせるべきではないか）という話が登場しています。当初 Greg（CTO）が受け持ち、Ilya（MLのトップ）に研究以外の仕事を取り除くために必要なことは何でもしようと決心していました。ところが突然エンジニアリング部分が研究のボトルネックになると、Greg と Ilya は役割をスイッチして、運用上のタスクを Ilya が全て受け持った時期について紹介していました。 エンジニアが集中、没頭する時間を確保することの重要性とそれは工夫なしに簡単には実現出来ないことを改めて感じました。ブログの最後は上のような CTO でもコーディングに集中することが出来る組織への感謝で締められています。（二人ともスーパーな技術者、研究者でありながら、そのうえで献身性や信頼が感じれるエピソードでした。）

今後のバクラク開発

「やること」として据えたのは、今もエンジニア組織にある機動力やプロダクト開発への取り組み方を持続しながら、今後のビジネスドメイン領域を拡大するために重きをおいたことです。

1. 開発チーム横断でのテクノロジーマネジメント

コンパウンドスタートアップとして、共通化したデータを用いて業務を繋ぐことを今後のバクラク製品ラインナップでも実現する。スケールした先でも標準化されたバクラク体験を全てのプロダクトに提供出来るシステム開発を目指す。全体最適を追求すること。

2. 開発から顧客へのデリバリまでオペレーションマネジメント

バクラクのような業務 SaaS を提供する上で、ドメインへの理解がほぼ全ての職種において求められる。使われないものを作らないことと開発された製品機能を速く正確に実際の現場まで届けきるための開発スタイルやエンジニアリングを行う。

3. コードを書く（直接的な経験を元にリーダーシップを取る）

エンジニア（ロールやグレード関係なく）が実際の業務解像度をもって作っていく事が当たり前になっているのが今のバクラク。 これまで私がみてきた人への憧れもあるが、様々なことが起きながらでもコードを書くことから見通しを持って、いちエンジニアとして前に進めていく。（プロダクトと距離をおいた場所から価値を出すことにモチベーションや正しく解を導く自信が今の私には持てていないこともある。） LayerX の羅針盤にある、実行と戦略をわけずにソフトウェアを作る直接的なプロセスを通して、意思決定をしていく。

さいごに

社員数が200名を超える現在ですが変わらないのは、プロダクトや会社に対して真面目な方、情熱を傾ける方が多いという点だと思います。周りからの刺激、どのフェーズにおいても大きな目標を掲げる組織の中で今後も精進していきます！

すべての経済活動を、デジタル化する。一緒に挑戦してくれる仲間を募集しています！

jobs.layerx.co.jp

jobs.layerx.co.jp

event.shoeisha.jp