こんにちは、株式会社ログラス プロダクト基盤部の小林です。
この記事は、先日開催された「アーキテクチャConference 2025」におけるログラスブースの企画報告です。ブースにお立ち寄りいただいた皆様、セッションにご参加いただいた皆様に、改めて御礼申し上げます（ブース運営の皆さんもお疲れ様でした）。本稿では、ブースで実施した企画の結果と、そこから浮かび上がった現代のエンジニアが直面する共通の課題について整理してみます。
ボードを埋め尽くした「98の葛藤」
今回のブースでは、開発現場が抱えるリアルな課題を共有する場を設けたいと考え、次のようなボードを用意しました。
「プロダクト開発における『両立』これが悩ましい」
「スケーラビリティ」と「柔軟性」、「開発スピード」と「品質」——アーキテクチャの設計・運用は、常にトレードオフとの向き合いです。参加者の皆様が日々どのような「両立」に悩んでいるのか、付箋に書いて貼っていただきました。
結果は、ご覧の通りです。
もしかしたら書きにくいお題かもな、という懸念もありましたが、2日間でボードは隙間なく埋まり、集まった付箋は98枚に上りました（重ねて貼られたものを含めると、実際にはさらに多い可能性があります）。
一枚一枚の付箋には、教科書的な理論ではなく、現場のリアルな葛藤が記されていました。ブースでは「それ、よくわかります」「うちも同じ状況です」といった共感の声が多く聞かれ、参加者同士が課題を共有し合う場となっていました。
すべての付箋を読み込み、カテゴリ別に分類したところ、明確な傾向が見えてきました。
最も多かったテーマは「質とスピード」
最も多くの方（計13枚以上）が挙げたのが、このテーマでした。
- 質とスピード（13枚以上）
- 統制と速度
- QCD
- 新機能開発とコード品質
- 属人化と品質
- 大規模開発とリリースサイクル
- 安定性と速いリリース
- クオリティとデリバリー
「質とスピード」 —— やはり、これが突出して多い結果となりました。t_wada（和田卓人）さんの講演『質とスピード』がエンジニアの共通言語として浸透していることの表れとも言えます。「質を犠牲にしてもスピードは上がらない」という原則は広く理解されている一方で、現実の納期やプレッシャーの中でどうバランスを取るかは、多くの現場で継続的な課題となっていそうです。
また、「安定性と速いリリース」 や 「大規模開発とリリースサイクル」 といった付箋も目立ちました。これはFour Keys（デプロイ頻度、リードタイム、変更障害率、復旧時間）の観点とも重なります。デプロイ頻度を上げればリードタイムは短縮できる一方で、変更障害率が上昇するリスクがある —— この相関をどう制御するかはやはり重要なテーマですね。
次に「質とスピード」という大きなテーマの周辺を詳しく見ると、より具体的で、アーキテクトやリードエンジニアが抱える 構造的な板挟み が浮かび上がってきます。
アーキテクトが直面する「3つの構造的ジレンマ」
付箋を分類してみますと、参加者の属性（アーキテクト、テックリード、マネージャーなど、ややシニアより）を反映した3つの軸が浮かび上がりました。
1. 時間軸の葛藤：【未来への投資】vs【現在の価値提供】
一つ目は、システムの長期的な健全性を守りたい技術的視点と、今すぐ価値を届けたいビジネス的視点の衝突です。
- 短期の価値とLTV
- 新機能とリファクタ
- 新規開発と技術的負債
- 安定と挑戦
- 安定さとチャレンジ
- 機能追加とレガシー
- サービスグロースとリアーキテクチャ
- 新規プロダクトと既存プロダクト
- やりたいこととやらなきゃいけないこと
- ビジョンとゴール（足元の）
- 変化と信頼性
特に 「新規開発と技術的負債」 や 「機能追加とレガシー」 というキーワードが目立ちました。
カンファレンスのテーマが「スケールするアーキテクチャ」だったこともあり、システムを長期的に健全に保つことへの意識が高い参加者が多かったと推察されます。「今は多少粗くてもリリースを優先する」という判断と、「ここで改善しておかなければ将来的に大きな問題になる」という認識 --- この狭間で判断を迫られているテックリードの姿が、付箋から読み取れます。
2. 組織の葛藤：【人・組織の成長】vs【事業の成果】
二つ目は、技術とは切り離すことのできない組織の課題です。
- 育成と成果
- 組織と開発
- 作りたいもの VS 人員採用
- 価値と教育
- 人数とカルチャー
- 一体感とダイバーシティ
- 多様性と一体感
- 現場と経営層のギャップ
- スピードと育成
- プロダクトの成果とエンジニアの教育
- スキルと納期
- 足回りの整備と開発スピード
「育成と成果」、「人数とカルチャー」 --- これらの言葉が持つ重みは、組織の拡大を経験した方であれば容易に想像できるでしょう。メンバーの育成に時間をかければ短期的な成果は遅れ、成果を優先すれば育成が後回しになる。組織が拡大すれば多様性は増すものの、一体感の維持が難しくなる。技術力だけでなく組織構築も求められるフェーズにいる方々の葛藤が、これらの付箋に表れていました。
3. 理想と現実の葛藤：【ビジネス要求】vs【システム制約】
三つ目は、ビジネスサイドとエンジニアリングサイドの「翻訳者」として板挟みになるアーキテクトの課題です。
- エンジニアが作りたいもの vs ユーザーが欲しいもの
- 営業の要望とCSの要望
- 信頼と開発
- やりたいことと予算
- やりたいことは無限にリソースは足りない
- 技術的挑戦とビジネスの安定
- プロジェクト思考とプロダクト思考
「エンジニアが作りたいもの vs ユーザーが欲しいもの」 --- この付箋は、多くの方にとって示唆に富む内容ではないでしょうか。技術的に優れた解法が、必ずしもユーザーにとって最適とは限りません。また、 「営業の要望（売るための機能）」と「CSの要望（守るための改善）」 の対立も、プロダクトが成長する過程で必ず直面する課題です。
これらの要求を受け止めながら、限られたリソースとシステム制約の中で最適解を導く、会場にいた皆様は、まさにこの高度な課題に日々取り組んでいる方々でした。
そして「境界の設計」という永遠の問い
上記3つのジレンマに加え、アーキテクチャ設計の核心を突く 「境界と分業」 に関する課題も見られました。
- ドメイン分割と共通化・再利用性
- モデルの分離と共通化
- AIの向上と物理
- 機能開発しつつAI活用を推し進めること
システムをどこで分割するか——共通化しすぎれば密結合になり、分割しすぎれば複雑性が増す。これは後述するログラスの課題とも深く関連しています。
また、 「機能開発しつつAI活用を推し進めること」 という付箋も印象的でした。2023年以降、生成AIの活用が急速に広がる中で、既存の機能開発ロードマップを進めながら、AI機能の検証・導入をどう両立させるかは、多くの組織で新たな課題となっています。従来のアーキテクチャにAIコンポーネントをどう組み込むか、という境界設計の問題とも言えます。
ちなみに、98枚の付箋の中に 「規律と遊び心」 と書かれたものがありました。本稿では紹介しきれませんでしたが、この一枚にはアーキテクチャに向き合う姿勢の本質が凝縮されているように感じます。
ログラスが直面する同様の課題
ブースで今回このようなお題を設定したのは、 ログラスもまた、皆様と同様に、あるいはそれ以上に複雑な「両立」の課題を抱えているからです。 現在、単一プロダクトを磨き込むフェーズから、複数のプロダクトが連携して価値を創出する「マルチプロダクト」フェーズへの移行期にあり、付箋に記されていたような課題が複合的に発生しています。
ブースのボードでは、ログラスが現在取り組んでいる「3つの両立」を紹介しました。
① 多様なユースケースに対応できる「柔軟性」× エンタープライズ規模の「大規模対応」
ログラスは経営管理クラウドですが、経営管理の手法は企業によって異なります。Excelのような自由なモデリング（柔軟性）を提供しながら、エンタープライズ企業が扱う規模のデータを高速に処理する（大規模対応・スケーラビリティ）必要があります。
- 柔軟性： メタデータ駆動により、ユーザーが自由にデータモデルを定義可能
- 大規模対応： 高いクエリパフォーマンスを維持する技術選定
「何でもできる」ことと「速くて堅牢」であることは、本来相反する要求です。この両立を技術でいかに実現するかが、設計上の重要な課題となっています。
② 事業を牽引する「開発速度」× 確実に稼働する「安定性」
これは、付箋で最も多かった「質とスピード」に対するログラスのアプローチです。
- 戦略の個別化： 後述のマルチドライブアーキテクチャにあるようにシステムを分割し、それぞれに最適な戦略を適用
- 境界の設計： スピード重視の領域と安定重視の領域の間に、適切な「緩衝材」を設ける
高速な開発を維持しながら、システムの基盤を堅固に保つ——そのためのアーキテクチャ設計を進めています。
③ ビジネス要求を実装する「業務システム（OLTP）」× 大量データを処理する「分析システム（OLAP）」
経営管理特有の技術的課題かもしれませんが、ログラスは「予算を入力する（業務システム）」側面と、「予実を分析する（分析システム）」側面の両方を持ちます。
- OLTP的な要求： データの整合性を担保し、複雑なワークフローを処理する
- OLAP的な要求： 入力された大量のデータを即座に集計・分析して可視化する
通常、この二つはシステムを分離して構築することが多いですが、 入力して即座に分析したい というユーザー体験を実現するために、いかにシームレスに連携させるかが問われます。 統一したユーザー体験を維持しながら、裏側ではシステムを明確に分離する という、難易度の高い設計に取り組んでいます。
異なる駆動力を束ねる「マルチドライブアーキテクチャ」
これらのトレードオフに対し、ログラスが現在どのようなアプローチをとっているか——その解の一つとして、今回のカンファレンスで登壇したテーマが マルチドライブアーキテクチャ です。
従来のモノリシックな設計や、単一の設計思想によるマイクロサービス化では、前述した「OLTP（確実性）」と「OLAP（分析性能）」のような相反する特性（駆動力）を共存させることは困難です。車に例えるなら、オフロードを走破するためのギアと、サーキットを高速で走るためのギアを、一つのエンジンで無理に両立させようとするようなものです。
そこで私たちは、システム全体を単一のエンジンで動かすことを断念しました。代わりに、 「異なる駆動力（ドライブ）を持つコンポーネントを定義し、それらを適切な境界（クラッチ）で接続する」 というアーキテクチャスタイルへの大きな変更を進めています。
※ 詳細は、SpeakerDeckの資料をご参照ください。
さいごに
今回、ブースのボードを埋め尽くした98枚の付箋。そこには、組織やプロダクトが成長する過程で多くのチームが直面する、普遍的な課題が並んでいました。守るべき価値が増え、関わる人が増え、システムが複雑化するからこそ生まれるこれらの課題は、エンジニアやプロダクト、組織が次のステージへ進むための入口でもあります。
ログラスは現在、経営管理プロダクトを引き続き中核としながら、「マルチプロダクトを支える共通基盤」 を構築するフェーズです。難易度は高く、付箋にあったような「質とスピード」の課題も、「技術的負債」への対処も、日常的に発生しています。
しかし、それに向き合うための体制は整っています。難しい状況をくぐり抜けてきたシニアなエンジニアが在籍しており、複雑な課題にチームで取り組むカルチャーが根付いてます。そして、この規模のリアーキテクチャや共通基盤構築に、大きな裁量を持って携われる機会は、エンジニアのキャリアにおいてそう多くはありません。
もし、ブースの付箋を見て共感しながらも、 「こうした複雑な課題を解くことに面白さを感じる」 という方がいらっしゃれば、ログラスとの相性は良いと考えています。
もしよろしければ、弊社公式Xをウォッチしてください。
ぜひ、イベントでもお会いしましょう。
最後になりましたが、ブースにお越しいただいた皆様、付箋を通じて課題を共有してくださった皆様に、改めて御礼申し上げます。
Discussion