「Loglass 経営管理」「Loglass IT投資管理」などを運営する株式会社ログラスは、成長著しいスタートアップ企業のひとつです。「Loglass 経営管理」は2023年7月に3周年を迎え、サービスの実績としてはARR前年比3.2倍を実現しました。

そんなログラスで2023年5月よりVP of Engineering（以下、VPoE）に就任したのが、シリーズCスタートアップ企業の元執行役員VPoEである伊藤博志さん。今回は伊藤さんに、過去に行った技術的意思決定のなかで印象に残るものを聞きました。

株式会社ログラス VPoE 伊藤博志

＜経歴＞

外資系証券会社のテクノロジー部に新卒入社後、同社の機関システム開発に従事。その後、VP/Senior Engineerとしてプラットフォーム開発に携わり、同社発のJavaのOSSのコミッター兼プロジェクトリードやOpenJDKへのコントリビュートを行うなど、OSS戦略を牽引。スタートアップ2社を経て、クラウドファンディング系スタートアップに入社し執行役員VPoEに就任。同社のエンジニア組織の10名から30名規模への成長、決済基盤の刷新や、技術的負債の返済、新規プロダクト開発を牽引。2022年10月に株式会社ログラスの開発部へエンジニアとして入社。エンジニアリングマネージャーを経て、VPoEに就任。

世界最大規模の外資系証券会社で経験した、複数の国にまたがる大規模リファクタリング

――伊藤さんがログラスでVPoEとしてどのような仕事をされているかを教えてください。

経営陣の議論に加わり「数年先のログラスはどのような状態であるべきか」について方針策定をしています。そのうえで、より短期的なスパンで「どのような事業目標やOKRを設定すべきか」を決め、採用や人の配置、育成、評価といった組織作りや開発プロジェクトの推進、技術課題の解決などを担っています。各プロダクトマネージャー陣と協力しながら、プロダクトの進むべき方向性にエンジニアリングが寄与できているか、組織や人の状態は良好かなどを確認しながら開発組織を運営しています。

――今回のインタビューでは、過去に取り組んだ技術的意思決定のなかで印象に残るものや、そこから得た学びを話していただきたいです。

これまで働いてきた会社のなかから、新卒で入った外資系証券会社とVPoEとして成長に寄与したスタートアップ企業、そしてログラスの事例をお話しします。最初の外資系証券会社では12年ほど働いており、最も長く携わっていたのがコントローラーズという職種の方々が使用する会計アプリの開発でした。

このアプリでは、損益の計算方法として最初に入ってきた買いと現在の売りをマッチさせるFirst in First out方式をとっています。たとえば、最初に10の買いがあって5の売りがあった場合に、マッチした5の部分をロットと呼びます。そしてロットに対して損益を計算した上で、残った数値に対しては未実現損益が1日の終値で計算されます。

ここまではシンプルなシナリオですが、実際には各種の金融商品ごとに計算の条件が異なり、計算エンジン全体のロジックはかなり複雑になります。かつて、この会計アプリでは計算エンジンのソースコードがかなり入り組んだ状態になっていました。

実は損益計算以外の別の箇所でも、ロットの計算と同様の処理を行っています。そのため、あるべき姿としてはロットの計算処理を共通コンポーネントとして切り出して、複数の箇所からこの処理を呼び出す形にすべきでした。ですが、ロットの計算と同様の処理がアプリ内のあちこちにコピーされていたんです。実装の重複が多く存在しており、技術的負債になっていました。

計算エンジンに変更を加える際の影響範囲が大きく、修正コストも高い状況に陥っていました。これらの重複コードを共通化することで、アプリの修正コストや障害発生のリスクなどを低減できるのではないか、という仮説を立てていました。

そこで、試しに自分の携わるプロジェクトで共通コンポーネントを利用してリファクタリングをやってみたところ、うまくいったんです。簡単に実装でき、かつ見通しも良くなって、もとのコードと比べると遥かにメンテナビリティが高い状況が作れました。小さな成功体験を積むことができたので、「このコンポーネントを他の箇所にも適用すれば、コードの品質を向上させられる」という確信を持ちました。

とはいえ、これを計算エンジン全体に反映させるのはかなり大変な作業です。なぜなら、その会社の開発チームは日本だけではなく世界各国に拠点が存在しました。そして、どこかの開発チームが常にこの計算エンジンを修正しているんです。リファクタリングを成功させるには、各国の開発チームとうまく連携をとる必要がありました。

重要なのは事前の情報連携。そして、コード修正の“動機付け”

――グローバルにまたがる各チームと連携をとるのは大変だと思います。どのようにリファクタリングのプロジェクトを進めたのでしょうか？

最初に取り組んだのは、グローバルの各チームへの情報共有でした。現状、計算エンジンの各所で重複するロジックがあり、メンテナビリティが悪いこと。そして、私たちのチームが作った共通コンポーネントを導入してもらうことで今後の保守・運用が楽になることなどを伝えました。

とはいえ「やったほうがいい」と「実際にやってもらう」には大きな隔たりがあります。各チームは他にもプロジェクトを抱えていますし、リファクタリングを行うにも人的コストがかかりますから、リファクタリングのプロジェクトを最優先で進めてもらうのは現実的には厳しいわけです。

そこで私たちは「各チームのプロジェクトの状況を適宜確認して、そのタイミングで計算エンジンを修正しているプロジェクトを見つける」「プロジェクトマネージャーと相談して、プロジェクトの機能開発と並行しつつ共通コンポーネントを導入してもらう」という手順を踏んで、段階的にリファクタリングを行うことにしました。

基本的にシステム開発のプロジェクトにおいては、特定の機能開発は何かのビジネス要件を実現するために行われるので、コード修正を行うための強い動機付けがあります。その“強い動機”があるタイミングで一緒にリファクタリングをやってもらうことで、共通コンポーネントの導入をなるべく円滑に進めてもらうようにしました。

――このプロジェクトを踏まえて、読者の方々に伝えたいことはありますか？

まず、予想以上にこうしたリファクタリングのプロジェクトは長い時間がかかると覚悟しておくことです。この事例では、トータルで5年ほどかかりました。80％くらいまではすぐ進むんですよ。でも、最後の20％を完遂するのが大変なので、そこを粘り強くやっていくことが重要でした。

当時の尊敬する上司が、プロジェクトやキャリアを成功させるには3つのPが大事であるといつも言っていました。PassionとPersistenceとPatience。情熱とやり続けることと忍耐です。まさにその通りだなと。そのリファクタリングに情熱を持ち、グローバルの各チームの人たちが計算エンジンに触れるタイミングで交渉し続けて、それを忍耐強く行ったからこそ成功できたんだろうと思っています。

ソフトウェアの資産は「技術的負債」と「技術的純資産」に分けられる

――2つ目のエピソードとしてスタートアップ企業での技術的意思決定についてお聞かせください。

この企業では入社時、エンジニアが10名ほどでした。入社の約半年前に資金調達をして、これからJカーブの成長曲線を目指そうとしていたフェーズです。この会社が他のスタートアップと異なっていたのは、資金調達の前に数年ほど自己資本でスモールビジネス的に経営を続けていたことです。そのため、事業の急成長を目指す前の段階で、数年分の技術的負債が蓄積している状態でした。

補足としてお伝えしておくと、この技術的負債が蓄積している状態というのは、あくまでそれまでのビジネスの成長過程で制約条件のもとサービスを成長させてきた先人たちの努力の副産物でもあるので、負債が存在すること自体に対してはなんらネガティブな感情を持ってはいけないと考えています。

そこからのプロダクト開発を加速させたいフェーズにおいて、負債が存在するという現実を受け止めつつどのように対処していくかが重要でした。

わかりやすい負債の例としては、「サービスで中心的な役割を担う概念」を扱うモデルの肥大化です。当該サービスでは、その概念に関連したさまざまなコンテキストが登場します。そうしたコンテキストの複数のロジックが単一のモデルにすべて詰め込まれている状態だったんです。

このままの状態では、開発効率を高めるのにも限界があります。そこで、私は経営陣を含めた全社に対して「企業が保持するソフトウェアの資産は『技術的負債』と『技術的純資産』に分けられる」という話をしました。

「技術的負債」に比べて「技術的純資産」が多い場合、最初に生み出すソフトウェアの価値は比較的小さくなりますが、時間が経つにつれて開発スピードの成長は大きくなります。一方、「技術的純資産」に比べて「技術的負債」が多い場合、初期に生み出す価値を大きくすることは可能ですが、時間が経つにつれて開発スピードの成長は逓減してしまいます。初期に蓄積した負債の利子を払い続けるような状態です。

そこで、我々が継続的に事業成長していくためにはリファクタリングが必要であるという話をしました。リファクタリングは「ソフトウェアの価値」を変化させることなく「技術的負債」を返済して「技術的純資産」に変換します。これによって、その後の開発スピードを加速させることができます。

ドメイン駆動設計を導入してリファクタリングを推進

――具体的には、どのような手段でリファクタリングを推進したのですか？

先ほど述べたように「さまざまなコンテキストの複数のロジックが特定のモデルに詰め込まれていること」が技術的負債の主要因だったため、コンテキストごとに適切な境界を設け、責務の分離が必要でした。そこで私たちは、ドメイン駆動設計（DDD）を取り入れることにしました。

とはいえ、当時在籍していたエンジニアはドメイン駆動設計には慣れ親しんでいない状態でした。そこで、まずは社内のエンジニアリングのベースラインを向上できるように、ドメイン駆動設計のスペシャリストに参画いただくための採用計画を立てました。

しかし、採用には時間がかかります。その間にまず取り組んだのは、フロントエンドとバックエンドの分離です。当該サービスはもともとRuby on Railsでモノリシックなアプリケーションとして構築されたものです。フロントエンドの技術としてReactを取り入れてはいたものの、あくまでRuby on RailsのViewファイルの中でReactを呼び出している状態で、バックエンドとフロントエンドが密結合になっていました。

そこで、特定の画面を機能変更するタイミングで、その機能に関連する箇所を「バックエンドはRuby on RailsのWeb API」「フロントエンドはReact+Next.js」によるSPA設計で構築しました。そこから、他の機能に関しても段階的にSPA化を進めました。

その過程でドメイン駆動設計に基づいたモデリングを行い、徐々にモデルの構造も洗練されていきました。そうしている間にドメイン駆動設計のスペシャリスト採用も進み、知識の共有やリファクタリングなどを一緒に推し進めていく体制を作ることができました。そして、事業価値を生みだすための機能開発だけではなく、リファクタリングやシステムの基盤作りなども推進できる組織モデルにしました。

余談ですが、ログラスにはドメイン駆動設計の第一人者である松岡幸一郎が所属しています。そして、CEOの布川友也は前職で経営企画を務めており、ドメインエキスパートなんです。これらのメンバーが中心となって創業当初からドメインモデリングを推進してきたため、ドメイン駆動設計が社内文化として根付いています。

人数が増えても揺るがない頑強な開発組織文化を築く

――ログラスでの今後の目標をお話しください。

ログラスにはドメインモデリングの土台があり、アプリケーションの設計も整備されています。システムのアーキテクチャも優れており、テストコードもしっかり書かれていて、開発生産性が高い状態です。私がこれまで所属した企業の中で最もエンジニアの開発スピードが速いくらいです。

「この機能を開発するにはこのくらいの期間が必要」と思った見積もりが、良い意味で当てになりません。想像をすごい勢いで超えてくるからです（笑）。そのぶん、「お客さまに価値を提供するには何をすべきか」という仕事の本質と純粋に向き合える環境です。

とはいえ、これは今のままで良いということではありません。ログラスのお客さまは膨大な量のデータを抱える企業が多く、それらを集計する計算処理が複雑です。そして、事業はいまT2D3と呼ばれるSaaSの成長曲線に乗っており、今後さらなる拡大が予測されています。よりデータが増えても処理の遅延や障害などが発生しないように、システムの基盤を改善し続ける必要があります。

また、ログラスは企業文化の面でも優れています。会社としての文化をミッション、バリュー、組織コンセプトとして言語化しており、全社員にこれらの考え方が浸透しています。数百人とか数千人の組織規模になっても良好な組織文化を維持していくのが、私がVPoEとして注力している業務のひとつです。

――どのような方法で、開発組織の文化を良好に保ちたいと考えていますか？

最近取り組んでいるのは、開発組織として大切にするTech Valueの明確化です。今後さらに開発組織の人数が増えても良い開発組織でいられるように、「自分たちが何を大切にしている組織なのかを言葉としてまとめよう」というメッセージをまずメンバーに伝えました。

そのうえで、開発組織全体をいくつかのグループに分けて、グループメンバー同士で「ログラスの開発組織が持っている良い要素は何か」「自分たちは今後どうなりたいか」について話し合い、情報をまとめてもらいました。これらの情報のグルーピングや共通化などを行ったうえで、ChatGPTに「これらの情報から、5つほどValueを抽出すると何になりますか？」と問いかけました。ChatGPTに質問したのも意図があって、私が選んでしまうと、私の考えによるバイアスがかかってしまうためです。

ChatGPTが抽出してくれた叩き台をベースに、もう1回みんなにValueの案を出してもらいました。そこからは数名ほどの有志を募って、アイデアの収束と発散をくり返したんです。このプロセスを経た結果、かなり納得感のあるTech Valueになってきました。

このTech Valueを言語化して、業務のいろいろな場面で用いることでメンバーの意識に浸透させたいと思っています。その「ログラスの開発組織の文化」を拠り所として、これから人が増えても崩れないような、強固な文化を作っていけると考えています。

――開発組織のさらなる拡大が楽しみです。最後に伺いたいのですが、「what we use」で掲載するインタビューやコラムは「技術的な意思決定」をテーマにしています。エンジニアがこういった事例を学ぶことには、どのような意義があると思われますか？

自身もWebの記事などを通じて、先人たちが行ってきたさまざまな意思決定を学びながら成長してきました。読者の方々にアドバイスしたいのは、そうした意思決定は必ず“コンテキスト”ありきなので、大抵の場合はそのまま流用できないと私は思っているんです。

意思決定の前提となったことと意思決定の内容をリンクさせることが大事です。だからこそ、記事などを通じて事例を学ぶ場合には、どのような背景があってその意思決定をしたかという繋ぎこみの情報を知っておく。そうすることで、自社に適用できる有益な知識になるはずです。

取材・執筆：中薗昴

撮影：山辺恵美子

提供：株式会社Haul

「組織開発」の記事一覧