SaaSにおけるマルチプロダクト戦略を考える上では、各プロダクトにおける整合性担保や、スケールするアーキテクチャの維持、チーム間の連携など、開発組織を横断した取り組みが重要になる。

特にエンタープライズ攻略を進めるにあたっては、多様な機能やプロダクトの統一性が求められ、それらを実現するエンジニア組織のパフォーマンス向上も不可欠だ。

経営管理クラウド「Loglass」シリーズを開発する株式会社ログラスは、創業間もない頃から顧客の本質的な課題を発見し解決していく「DDD（ドメイン駆動設計）」を実践してきた。

直近では、プロダクトの中長期的な成長を見据えた「Enabling & Platform部」の立ち上げや、まだ日本では導入事例の少ない先進的なアジャイルフレームワークである「FAST」の導入など、新たな取り組みも積極的に行っている。

今回は執行役員CTOを務める伊藤 博志さんと、Enabling & Platform部の部長を務める鈴木 健一さんに、同社の開発組織戦略や、チームの目指す未来について話を聞いた。

創業当初からCEOがドメインエキスパートとして開発を推進

伊藤　私は新卒でゴールドマン・サックスに入り、10年ほど働いたのちにスタートアップの世界に入りました。いくつかFinTech系のスタートアップでEMやVPoEを務め、2022年10月にログラスへ入社しています。

当初はエンジニアとしてプロダクト開発に携わった後、2023年の初めにEMに昇格し、同年5月にはVPoEとして開発組織全体のマネジメントをするようになりました。そして、2024年11月に執行役員CTOに就任し、経営と現場のエンジニアリングをつなげる役割を担っています。

鈴木　私は新卒でSIerのNTTデータに入り、ミッションクリティカルなシステムやアーキテクチャ周りの設計を手がけていました。

その後、プログラミングのバックグラウンドになっている言語理論の数学的な研究に携わり、それをもっと現場で実践したいという思いからスタートアップ企業に転職し、プロダクトマネジメントやVPoDを担当してきました。

ログラスには2023年7月に入社し、同年の10月からは開発の横断的な領域を見るEnabling & Platform部で部長を務めています。

▼【左】伊藤さん、【右】鈴木さん

伊藤　ログラスはCEOの布川と初代CTOの坂本（※2024年11月に退任し、伊藤さんにバトンタッチ）が共同創業した会社です。

布川はもともと投資銀行でのM&A、アドバイザリー業務やベンチャー企業での経営企画などの経験を通じて、経営管理の領域を深く理解していました。ですので、CEO自らドメインエキスパートとしてプロダクト開発に関わりながら、「経営管理の領域のペインを解消すること」に尽力してきました。

スタートアップの創業期で大事なのは、「お客様のバーニングニーズ」をいかに捉えるかということです。「今すぐ使いたい」「喉から手が出るほど欲しい」というプロダクトを作ることが、非常に重要になるわけですね。

そこを布川がしっかりと捉えながら開発を進めていき、2020年に初期バージョンのLoglassをリリースしました。

またログラスでは、創業当初からスクラムやDDD（ドメイン駆動設計）に取り組んできました。これは坂本が、「プロダクトの成長を考える上で、最初はスピードを意識して価値あるものを市場に出し、そこから中長期的に品質の高いものを作っていく」という強い意思を持っていたからです。

そのため、初期の段階からデータのモデリングやコードの品質を高めていくための仲間集めに注力していました。そして最初の転機になったのが、ドメイン駆動設計の「伝道師」と呼ばれるエンジニアの松岡を業務委託として招いたときです。

その後、松岡が正社員としてジョインしたことで、弊社の中でも「DDDを当たり前にやっていく文化」が醸成されていきました。また、現在のVPoEを務める飯田がアジャイル開発やスクラムの知見をかなり持っていたことで、開発体制も強化されていきました。

このような背景もあり、私がログラスへ入社した頃には、開発の中でドメイン駆動設計が自然に行われていて、「DDDを当たり前にやっていく基準値が本当に高い」と感じましたね。

今まで私が働いてきた会社の中でも、ログラスは特に開発の課題を現場主導で解決していける力があり、それが組織の強みだと考えています。

「要望の最大公約数」ではなく「本当に求められるもの」を作る

伊藤　開発体制については、2019年から2021年の始めまでは1つのチームでしたが、その後2チーム体制へと変わり、2022年初頭に3チームになったタイミングで、フィーチャーチーム（※）を導入しました。

※顧客への提供価値を中心に、特定の成果物を生み出すことを目的として編成された職種横断型のチーム。1つの機能を完成させるために複数のチームをまたぐ必要がなくなることが特徴。

「誰がどこを担当するか」がより具体的になったことで、各領域へのオーナーシップが非常に高まったと感じています。

▼ログラス社のプロダクト開発チームの進化（引用元はこちら）

伊藤　1チームだった頃から、CEOの布川がドメインエキスパートとしてスクラムチームの中に入り込み、開発とビジネスを繋げる役割を担っていましたが、1人目のCS（カスタマーサクセス）がジョインしたタイミングで、その役割を引き継ぎました。

また、チーム数の増加と共に、CSを含めたビジネスサイドのメンバーも徐々に増えていきましたが、スプリントレビューでは成果物を一緒に見てフィードバックをするなど、細かな粒度で開発に入り込んでお客様に本質的な価値を届けることにコミットしてきました。

このように、当初からビジネスサイドとプロダクトサイドが共創してプロダクトを作り、お客様に価値を届けることを当たり前にやってきたんですね。これが、現在においても、1人ひとりがオーナーシップを持ってサービスの信頼性向上に取り組めている大きな要因になっていると感じています。

もうひとつプロダクト開発において意識してきたこととして、「最大公約数的にお客様が欲しいものを無作為に作る」のではなく、「本当にお客様が使いたいと思うプロダクトを作る」というマインドセットがあります。

プロダクトが成長してくると、お客様の要望が多様化・複雑化してきますが、「どのセグメントのお客様をターゲットにするか」をビジネスのフェーズごとにしっかりと見直すようにしてきました。

具体的には、CSや経営戦略を担う部署が、顧客の事例を深掘りしていくなかで解像度を上げていき、ターゲットを選定してピン止めする。その上で、その方々にとって最高のプロダクトを作ることを目指して、開発に取り組むようにしています。

本質的課題に付随する「偶有的な複雑性」の解消が肝に

鈴木　このように、ログラスのプロダクト開発チームではフィーチャーチームを導入し、それぞれがお客様の本質的な課題解決につながる機能を開発しています。

その一方で、私が所属しているEnabling & Platform部は組織横断型で、「開発の出力を最大化する」ことを目的に置いています。このチームは、プロダクト開発に付随する「偶有的な複雑性」に注力していく組織が必要だと判断し、2023年に新しく立ち上げたものです。

▼ログラス社の開発組織の全体像

鈴木　「偶有的な複雑性」とは、例えばソフトウェア開発におけるプログラミング言語やデータベースの選定、アーキテクチャの設計のような、「本質的に解決したい課題に付随するもの」を指します。

より具体的にいうと、「膨大なデータを適切に処理すること」が本質的な課題だとすると、そのデータ量の増加によって起こるパフォーマンスやキャパシティの問題が、偶有的な複雑性に該当する部分です。

▼ソフトウェア開発における「本質的な作業」と「偶有的な作業」（引用元はこちら）

鈴木　この言葉自体はフレデリック・ブルックス氏の論文『銀の弾などない— ソフトウェアエンジニアリングの本質と偶有的事項』に出てくる「偶有的な複雑性は、本質的な課題に付随するもの」という内容を参考にしています。

現在のEnabling & Platform部は、クラウド基盤とアプリケーション基盤の2チームに分かれ、今後マルチプロダクト化を進めていく上で横断的に解決すべき課題に対してのツールやソリューションを検証しています。

伊藤　これからの2年で新規事業を10個立ち上げていく構想を描いているのですが、その過程で何もせずに手をこまねいていると、新しいプロダクト同士の統制や調和が取れなくなってしまいます。なので、「これから問題になるかもしれない」ことを見据えて、今の段階から具体的な対策に取り組んでいるという状況です。

鈴木　一般論としては、スケーラビリティ、パフォーマンス、セキュリティ、保守性といった非機能要件への対応が後手に回ってしまうことが、スケールの障害になると言われています。

ログラスの場合も、導入企業の増加に伴いデータ量が今の10倍、100倍、1,000倍と増えていくと考えると、「現状の仕組みでパフォーマンスを担保できるのか」という問題とどうしても向き合う必要があります。そのため、数年先を見越してデータ量や規模感の予測を立て、最適なアーキテクチャを検討しています。

伊藤　とはいえ、スタートアップのエンジニア組織にとって、将来のことを予測するのは難しく、会社の成長に伴って発生する課題を先回りして手を打つのは容易ではありません。

例えばSIerとスタートアップを比較すると、SIerはもともと潤沢なリソースを持っているので、機能要件と非機能要件の両方を最初から鑑みて開発しますが、一般的にスタートアップはお客様への価値提供を優先し、プロダクト作りにフォーカスします。

一方で、ログラスは成長速度が極めて速いため、非機能的な課題にぶつかった時に解決策を考えるのでは遅いんです。従って、組織として課題を乗り越えていける体制を前もって作っておくことが不可欠であり、その流れで立ち上げたのがEnabling & Platform部になっています。

プロダクト全体の提供価値を高めるため「FAST」を採用

伊藤　そのほか、プロダクト開発チームが本質的な価値に向き合っていくための取り組みとして、「FAST （※）」というアジャイルフレームワークを導入しています。

※Fluid（流動性）、 Adaptive（適応性）、 Scaling（拡張性）、 Technology（技術）の頭文字を取って名付けられたアジャイル開発の新しいフレームワーク

プロダクトに機能が十分に揃いきっていないフェーズでは、機能を拡充していくだけで価値を創出できるため、スクラム開発でそれぞれの機能群に注力し、最大生産性で作っていくことがお客様の価値に直結していました。

しかし、機能がひと通り揃った今では、「経営管理プロダクトとしての一連のユースケース全体で、お客様により大きな価値を提供するにはどうしたらいいか」を考えるべきフェーズに差し掛かってきています。

そうなった場合に、スクラムでチームを組む既存のやり方では、価値の最大化が難しい。各機能の依存関係による動きづらさが生じてきますし、組織面でも、1つのスクラムチームに参加する人数が増えることでフォーカスを決めるのが難しくなります。

このようなイシューを解決するやり方として、LeSSやNexusといったスクラム開発のフレームワークがありますが、 基本的にスクラムがベースになっている以上、「スクラムチームの肥大化」のイシューは解決できないんですよ。

そこで試行錯誤を重ねるなかで、一気に規模を拡大させるダイナミズムと、組織全体が一丸となって共通の目標に向かうことを両立できる手法として、FASTというアプローチに行き着きました。

FASTは海外で生まれたフレームワークで、 チームを「コレクティブ」という最小単位で考え、より自由な自己組織化を促進することが特徴です。

鈴木　FASTの難しい点は、いわゆる従来のスクラムのアプローチに比べて自律性が高いフレームワークゆえに、「開発がすごく流動的になる」ことです。アーキテクチャや機能面など、横断的な課題に対して整合性を取るのが難しいので、コミュニケーションをクリアにしていく必要があるんですね。

その解決のため、ログラスではバーチャルオフィスツールの「Gather」を使っていますが、日々のコミュニケーションにおいても、 直接Enabling & Platform部のメンバーがヒアリングを行い、横断MTGで議論していく形態をとっています。

何か決まった形で解決していくというよりも、見えてきた課題に対して色々なアプローチを使いながら、課題に応じて動くという形ですね。

FAST自体も世の中的にあまり導入事例がなく、先進的なモデルケースもありません。そのなかで、いかにFASTの良さを生かして開発をしていけるかが、チャレンジだと考えています。

ミッション実現のため、開発のケイパビリティをグローバルに

鈴木　私はもともとSIer出身ですが、 新卒の頃にその基幹システムに携わっていた際に感じていた課題が、今まさに「2025年の崖」という形で顕在化しています。

日本特有のレガシーシステムが大きな経済損失をもたらすとされているなかで、ログラスとしては「未来の基幹システム」を作っていくことで、お客様に価値提供できる幅を広げていきたいという思いがあります。

今よりも組織をさらに拡張していき、日本のレガシーシステムを置き換えていくことで、健全な状態を作っていきたいですね。

伊藤　ログラスは「良い景気を作ろう。」というミッションを掲げています。その第一段階として、日本のマーケットの中で経営をより良くしていくことで、多くの企業が元気になり、お金の循環を増やしていくことを目指しています。

さらに、これからスピード感を持ってサービスを広げていくためには、プロダクトが日本向けだったとしても、開発のケイパビリティとしては海外のエンジニアを採用していく必要性を強く感じています。

そのため、海外にも開発拠点を設け、現地でエンジニアを採用しながら、開発のケイパビリティをグローバルレベルに引き上げていきたいと考えています。そうして、いずれは海外にも市場を広げていきたいですね。

とはいえ、日本のエンジニアは世界と比べても相当優秀だと感じていますし、彼らがグローバルでも活躍できる状況を、ログラスが切り拓いていけたらと思っています。（了）

取材・ライター：古田島 大介
企画・編集：舟迫 鈴（SELECK編集部）

【読者特典・無料ダウンロード】UPSIDER/10X/ゆめみが語る
「エンジニア・デザイナー・PMの連携を強める方法」

Webメディア「SELECK」が実施するオンラインイベント「SELECK LIVE!」より、【エンジニア・デザイナー・PMの連携を強めるには？】をテーマにしたイベントレポートをお届けします。

異職種メンバーの連携を強めるために、UPSIDER、10X、ゆめみの3社がどのような取り組みをしているのか、リアルな経験談をお聞きしています。

▼登壇企業一覧
株式会社UPSIDER / 株式会社10X / 株式会社ゆめみ

無料ダウンロードはこちら！