ログラスが挑むマルチプロダクトプラットフォーム構想

2026年1月28日 20:00

はじめに

「良い景気を作ろう。」

これがログラスのミッションです。大きな言葉に聞こえるかもしれませんが、私たちは本気でこの実現を目指しています。企業の収益力を高め、それが給与拡大、消費拡大、そして景気向上へとつながる。そのトリガーとなるのが、私たちが取り組む「経営管理」の領域です。

ログラスは現在、単一プロダクトからマルチプロダクトプラットフォームへの進化を進めています。経営管理の課題を解決するには、財務だけでなく、人事・IT投資管理・販売管理など様々な業務領域のデータと計画を統合する必要があるからです。

この記事では、ログラスがどのような課題に向き合い、マルチプロダクト戦略でどう解決しようとしているのか、そしてそれを支える技術的チャレンジについて、プロダクト基盤部の部長である私の立場からお伝えします。

経営管理領域の課題

なぜ経営管理が難しいのか

どの企業にも経営企画や管理会計を担う部門があります。予算を策定し、実績を追い、差分を分析して意思決定につなげるこのPDCAサイクルは経営の根幹です。

しかし、多くの日本企業が経営管理の課題に直面しています。

世界と比較して2倍以上のリードタイムがかかっている
経営層の7割以上が適切な指標を見れていないと感じている
結果として、経験と勘に頼った意思決定が行われている

なぜこのような状況が生まれるのでしょうか。

データはあるのに、つながっていない

昨今、DXが進み企業内のデータの量は確実に増えています。しかし問題は「つながっていない」ことです。

売上データはCRM/SFAに、費用データは会計システムにあり、経営の判断にはそれらのデータを組み合わせて分析することが求められます。
しかし、例えばマスタデータの定義が各システムで異なっていたり、データの粒度が異なっていたり、システムから抽出する方法がなかったり…などの理由で、あちこちにあるデータをうまく繋ぎ合わせられないという課題が存在します。

結果としてExcelでの手作業による集計・分析が選択されます。

Excelは柔軟で便利ですが、組織が大きくなるほど「バケツリレー」が発生します。どれが最新版かわからない、関数が複雑になりすぎて誰も理解できない、計算の透明性が失われるなどの問題が起こり、その運用に膨大な工数・コストが発生しています。これが多くの企業で起きている現実です。

大企業ではコンサルティング会社やSIerが入り、大規模なデータパイプラインやDWH（データウェアハウス）を構築することもあります。しかし、コストが高い上に、変更に弱いというデメリットも存在します。

Loglassのアプローチ

3つの役割

Loglassは、これらの課題を解決するために3つの役割を担います。

1. データの集約
散らばったデータを一箇所に集めます。Excelファイルのアップロード、APIによる外部システム連携、GUI上での直接入力など、多様な方法でデータを取り込みやすくしています。

2. データの加工・多次元分析
集約したデータを、様々な切り口で分析できるよう加工・保持します。
経営の意思決定では、単一の視点だけでなく、複数の軸でデータを見る必要があります。普段は製品別の利益率を見ているが、今度は取引先別で見たい、さらにエリア別で切ると、実は〇〇地方の利益率が低いことがわかった…といったような多次元での分析をリアルタイムで実現するために、データを適切な形で加工し保持しておくことが求められます。

3. 意思決定の支援
ダッシュボードなどの機能を通じて、必要なデータを簡単に即座に取得できるような体験を提供し、適切な意思決定を支援します。

マルチプロダクト戦略

ログラスは現在、3つの領域でマルチプロダクト展開を進めています。これは単にプロダクト数を増やしたいわけではなく、企業価値を高めるという目的に対して、複数のアプローチで支援するための戦略です。

1. xP&A領域 - 業務単位での意思決定支援

私たちの中核となる事業領域は「xP&A（Extended Planning & Analysis）」です。従来のFP&A（Financial Planning & Analysis＝経営管理）を、様々な業務領域に拡張したものを指します。

なぜ拡張が必要なのか
先ほどの「3つの役割」のうち、特に入り口となるデータの質が最終的な意思決定の質を左右します。

例えば人件費の予算を考えてみます。100人の社員がいて、一人ひとり給与が違う。昇給もあれば、採用・退職・育休もある。福利厚生費は条件によって変わる。これを正確にシミュレーションするのは、単純な関数では表現できない複雑さがあります。

IT投資管理も同様です。様々なビジネスモデルのSaaSを導入することでシミュレーションが複雑化し、どのサービスにいくらコストがかかるのか、予測が難しくなっています。

この複雑な計画業務を、現場の担当者の方の努力と工夫に依存してしまうと、繁忙期などの理由でデータの質が悪くなってしまうリスクがあります。それはそのまま経営管理や意思決定の質に直結します。

これらの業務ごとの複雑さに対応するため、「人員計画」「IT投資管理」など、特定業務に特化したプロダクトを開発しています。各業務で質の高いデータを作成できれば、最終的な経営の意思決定の質も向上します。

業務単位での計画業務を支援し、現場の正確なデータが集まる仕組みを提供することで、企業全体の意思決定の質を上げキャッシュフローの増加に貢献すること。これがxP&A領域の目的です。

2. IR領域 - 資金調達の支援

企業価値を高めるには、キャッシュフローの増加だけでなく、効果的な資金調達も重要です。この観点から、IR（Investor Relations）領域にも進出しています。

IR領域の課題
投資家との対話、開示資料の作成、株主総会の準備など、IR業務には多くの工数がかかります。また、投資家が求める情報と、企業が伝えたい情報のギャップを埋めることも課題です。

AI IRプロダクト
先日ローンチした「AI IR」プロダクトは、この領域を支援します。xP&A領域とは異なるアプローチですが、「企業価値を高める」という目的は共通しています。

3. AIエージェント - 領域を横断した高度な意思決定支援

xP&A領域とIR領域を横断して、AIエージェントの開発にも取り組んでいます。

なぜAIエージェントなのか
経営の意思決定は数字だけでは完結しません。

CFOや経営陣の考え方
会社の価値観や戦略
景気動向や世界情勢
業界のトレンド

定量データ（財務データ）と定性情報（オープンデータ、議事録など）を組み合わせることで、より高度な分析と予測が可能になるのではないか。この仮説のもと、実証実験を進めています。

現在、パートナー企業様と共同で実証プロジェクトを行っています。将来的にはxP&AとIRの両領域を横断した、高度な意思決定支援を実現したいと考えています。

このように、３つの領域でそれぞれでマルチプロダクト化が加速しています。それと共に、アーキテクチャも大きく進化していく必要があります。

アーキテクチャの進化

サービスローンチから約5年。私たちは今、複数の技術的な壁に直面しています。

データベースの限界
通常のリレーショナルデータベースでは、多次元分析の柔軟性とパフォーマンスに限界を感じ始めています。正規化しすぎると、JOINが増えてパフォーマンスが低下する。一方で非正規化しすぎれば、整合性担保の課題が発生する。これはある程度のスケールに達した多くのプロダクトが経験する課題です。

共通機能のマルチプロダクト対応不足
現状、認証やセキュリティ機能（IPアドレス制限、SSO、MFA等）が一部各プロダクトに分散して実装されており、一貫性・保守性に課題があります。また、エンタープライズ顧客からのセキュリティ要件も高度化しています。

これらの課題に対して、様々な取り組みを開始しています。

1. リアーキテクチャへの取り組み

データ分析基盤の刷新
キーワードは「ディメンショナルモデリング」です。OLAP（Online Analytical Processing）に近い、分析に特化したデータの持ち方を採用します。事前に分析軸を定義し、様々な切り口で迅速に分析できる構造です。

2. マルチプロダクト共通基盤の整備

マルチプロダクト展開を加速するために、共通基盤の整備も進めています。プロダクトが増えるたびに認証やユーザー管理を個別実装していては、開発速度も保守性も低下します。

共通基盤で実現すること

認証基盤の統合: 全プロダクト共通の認証フロー。一度ログインすれば、複数のプロダクトをシームレスに利用できる
マルチテナント管理: グループ企業での利用を想定した階層構造。親会社・子会社それぞれが独立したセキュリティポリシーを持ちつつ、データ連携も可能に
エンタープライズセキュリティ: IPアドレス制限、SSO連携、MFA対応を共通基盤として横断で管理し提供

新規プロダクトの立ち上げを最速化しつつ、将来のスケールにも耐えうる基盤を構築することが求められます。

どう実現するか

ここまでアーキテクチャの課題と取り組みをお伝えしてきました。では、これらをどのように実現していくのか。私たちが大切にしている考え方と文化を紹介します。

組織体制

基本的にはプロダクトごとにチームがあり、各チームのエンジニアは2〜5名程度です。プロダクトのフェーズによって規模は様々で、立ち上げ期は少人数、成長期は増員といった形で変化します。
最も大規模な経営管理プロダクトは、プロダクト内の領域（予算管理、レポーティングなど）ごとにチームが分かれています。

これらのプロダクトチームとは別に、プロダクト基盤部が横断的に位置しています。基盤は開発の都合だけでなく、マルチプロダクト戦略という事業戦略とも深く関わります。そのため、プロダクト基盤部はプロダクトチームだけでなく、経営層や事業責任者ともコミュニケーションを取りながら進めています。

基盤とプロダクトの関係性

ここまでお伝えしてきた共通基盤やxP&A基盤は、マルチプロダクト戦略における「武器」にもなりますが、一歩間違えれば「制約」にもなりえます。
基盤チームがプロダクトの未来を想像して先行して構築した結果、それがプロダクトの足かせになってしまっては本末転倒です。

基盤はプロダクトの進化や変化に伴走し、共に進化して価値を提供し続ける必要がありますので、以下のような考え方を大事にしています。

基盤が「武器」であり続けるために

プロダクトの現在のニーズを理解し、適切な抽象度で機能を提供する
プロダクトの進化・変化を継続的にキャッチアップし、基盤も共に進化する
過度な先行投資や過剰な汎用化を避け、実際のユースケースに基づいて構築する

基盤が「制約」にならないために

プロダクトの意思決定を阻害しない柔軟性を持つ
基盤の都合でプロダクトの選択肢を狭めない
プロダクトからのフィードバックを積極的に取り入れる

この考え方は、基盤チームだけでなく、プロダクトチームとの協業の中で常に意識しています。

顧客理解を開発に活かす

エンジニアが顧客や業務を理解する機会を多く設けています。商談動画の共有会、顧客インタビューへの参加など。
前述の通り、管理会計はユースケースをパターン化しづらい領域です。だからこそ、顧客理解が開発の質に直結します。「このお客様はなぜこの管理をしているのか」を理解することで、適切な抽象度の設計が可能になります。

技術選定の柔軟性

メインプロダクトではKotlin（Spring Boot）を使用していますが、これはDDDの思想を徹底しやすいことと、パフォーマンスを考慮した結果です。
一方、新規事業ではGoを採用するなど、目的に応じて柔軟に選択しています。AI駆動開発が進む中で、どの言語・技術スタックが最適かは日々議論しています。全エンジニアがClaude CodeやCursorなどのAIツールを活用しており、AI時代の新しいエンジニアリングの形も模索し続けています。

こんな人に来てほしい

複雑な課題に挑みたい方

経営管理という複雑なドメインを、技術で解決していく。簡単ではありませんが、だからこそ面白い。技術的にも事業的にもチャレンジングな環境を求める方には、最適な環境だと思います。

自律的に動ける方

300名規模になりましたが、まだまだスタートアップのカオスな部分があります。マネジメント体制も発展途上です。だからこそ、自ら課題を発見し、アクションを起こせる方が活躍できます。

おわりに

私たちは「良い景気を作ろう。」というミッションのもと、企業の経営管理を変革しようとしています。
効率化ツールを作っているわけではありません。各企業の経営を高度化し、より適切な意思決定ができるようになることが、私たちの目指すゴールです。

技術的には、多次元データのリアルタイム分析、マルチプロダクトの共通基盤設計、AIによる意思決定支援など、難易度の高い課題が山積みです。

一緒にこの挑戦に取り組んでくれる方を、私たちは待っています。
この記事に興味を持っていただけたら、ぜひカジュアル面談でお話しましょう。

【採用情報】

【募集ポジション】