こんにちは、ログラスでテックリードをしている南部です。
2025年1月終わりから9月中旬のβリリースまで、約9ヶ月かけて、ログラスの中の1つの大きな機能の全面リプレイス要件策定から実装まで行いました。
このプロジェクトは、ログラスの技術的投資を奨励する環境と、頼れるビジネスサイドがなければ実現できなかったものだと思っています。詳しくは後半で紹介しますが、適切なアーキテクチャへの移行という技術的投資が実現でき、中長期的な価値提供の速さを向上できました。ビジネスサイドからは大胆な決断を一緒に背負ってもらえる環境がありました。
ログラスのエンジニアを取り巻く環境がよくわかるいい機会だったので、紹介させていただこうと思います。ログラスのエンジニアの雰囲気や働き方に興味がある方の参考になれば幸いです。
機能リプレイスを提案するに至った背景
機能の概要
詳細は控えるのですが、この機能はユーザーが設定を複数のステップに分けて作成し、その設定をもとにステップを順番に実行していくような機能です。各ステップは独立した設定として管理され、実行時には設定された順序で処理が進みます。
リプレイスを検討するきっかけ
きっかけは、あるお客様の設定作業でした。
このお客様は、複数の条件を組み合わせた複雑な処理を行いたいというニーズがありました。しかし、既存機能では設定が煩雑で、メンテナンスが困難という課題がありました。
50ステップに満たない設定なお客様が半数以上の中、1,000ステップ以上もの設定を作成していただいていて、このままだと日々の運用が立ち行かなくなってしまう状態でした。
具体的な課題：
- 似たような処理ステップを何度も手動で作成する必要がある
- 処理の一部を変更したい時、多数のステップを修正する必要がある
- 設定が複雑で、後から見ても意図が分かりづらい
- ステップ数が増えるほど、管理コストが増加する
「改修」か「リプレイス」か
当初はこの機能を改修する方向も検討しました。しかし、以下の理由から全面リプレイスを決断しました：
-
抽象化レベルの問題
- 既存のデータモデルでは、処理の「共通パターン」を表現できない
- 個別具体的なステップ設定しか持てず、設定数が爆発的に増加する構造
-
技術的負債の蓄積
- 他機能との密結合により、改修時の影響範囲が大きい
- パフォーマンスのボトルネックが構造的に解消不可能
-
UXの限界
- 設定の手順が実際の業務の思考フローと乖離している
- 段階的改善では抜本的な使いやすさの向上が不可能
リプレイスのメリット：
- クリーンなアーキテクチャで開発速度向上
- 将来的な機能拡張の余地を確保
- 技術的負債のリセット
リプレイスのリスク：
- 既存ユーザーへの影響
- 品質保証の難易度
結果として、長期的なプロダクト価値を優先し、リプレイスを選択しました。
このリプレイスの提案は、エンジニアサイドから起案したものです。当時のPdMに掛け合い、「改修ではなくリプレイスが必要」という技術的判断を説明したところ、提案が通りました。
「リプレイスしたい」というエンジニアの提案が通る。当たり前のようで、実現にあたっては壁がある選択肢だと思います。
この提案が通ったのは、ログラスの長期的な価値を優先する文化が影響していると感じます。
技術的投資ができる環境
リプレイスにあたって、ログラスで初めてとなる新しいアーキテクチャへの技術的投資も実現できました。
ログラス初のモジュラーモノリス設計への移行
今回のリプレイスでは、これまでモノリスだったログラスのアプリケーションをモジュラーモノリスに再設計しました。機能間の結合度を下げ、保守性を向上させるための技術的意思決定です。
今後機能を拡張していくにあたって、モジュール分割をしていかないと保守性が下がり続けて開発速度の低下を招くという課題があったためこの意思決定をしました。
こういったプロダクト全体に影響のある意思決定ができて、それを実現できるのはエンジニアにとって魅力的な環境だと感じました。
具体的にどういった意思決定だったかをお伝えするため、どのようなプロセスで、何を決定して実現したのかを記載していきます。
ADRによるアーキテクチャ決定
まず、ADR（Architecture Decision Record）を書いて、この機能をモジュラーモノリスの1モジュールとして切り出すことを提案しました。組織内で広く意見を募り、議論を重ねることで現時点で最適な設計を見出しました。
決定したこと：
- モジュラーモノリスアーキテクチャを採用
- リプレイス対象機能を独立したモジュールとして分離
検討した対案と却下理由：
-
完全なモノリスのまま改修
- 却下理由：既存の密結合構造では、改修時の影響範囲が大きく、技術的負債が解消できない
-
マイクロサービス化
- 却下理由：DBを共用しているため、完全にアプリケーションを分離すると、同一のDBを参照するアプリケーションが増えてしまう。その結果、DBスキーマの変更が複数のアプリケーションに影響し、障害につながりうるリスクが高まる
-
完全な疎結合を目指すアプローチ
- イベント駆動アーキテクチャなど、より疎結合な設計を目指すことも検討しましたが、現時点でのROIを考慮すると、段階的なアプローチが適切だと判断
モジュラーモノリスを選んだ理由：
- 現時点ではDB共有が前提
- モノリス内モジュール化で十分な分離を実現できる
- 同一アプリケーション内でスキーマ変更の影響範囲を把握しやすく、安全にリファクタリングを進められる
- 将来のマイクロサービス化への移行も可能な設計
モジュール境界の分離方法
モジュラーモノリス設計において、重要なのはモジュールの境界をどこで切るかです。
今回は、**ドメイン駆動設計（DDD）の境界づけられたコンテキスト（Bounded Context）**の概念に基づいて、モジュールを分割しました。リプレイスする機能を、独立した境界づけられたコンテキストとして分離することで、この機能は他の機能と独立して開発・テストできるようになりました。
DB設計の詳細
モジュール間の依存をどう管理するかも重要なポイントです。今回は、DBスキーマの分離と依存関係の明確化を実現しました。
採用した設計：
- DBスキーマの分離: リプレイス対象機能のスキーマを独立
- マスタデータの共有: マスタ系は共有スキーマを使用するが、リードオンリーのみ許可
- リポジトリの独自実装: リプレイス先の機能で独自のリポジトリを実装し、参照先が同一であっても実装の結合は切る
- 出力テーブルの共有: この機能がアウトプットするテーブルは共用スキーマに出力して既存機能がこれまで通り参照可能にする
技術的投資ができる環境によって得られたメリット
このような技術的投資ができる環境があったことで、将来の機能拡張の余地を確保でき、保守性と開発速度の向上が実現できました。この意思決定をしていなかったら、この期間で開発を終えることはできなかったと思います。このように、ログラスではプロダクト全体に関わる技術的意思決定ができ、それを実装できる環境があります。長期的な価値を優先する文化により、適切なタイミングで技術的投資を行えるのです。
ビジネスサイドが頼れる環境
技術的投資ができる環境に加えて、このプロジェクトを成功に導いた要因がもう一つあります。
ビジネスサイドと、本当の意味でチームになれるということです。
ドメインエキスパートであり、お客様への窓口でもあるCSが要件検討段階から入ってくれたことで、リスクを共に背負いお互いの専門性を尊重し合う対等なパートナーシップを築けました。
お客様にリプレイス後の機能に設定を移行してもらう決断
既存のお客様の設定データを載せたまま機能を改修していくのではなく、完全に新しく機能を作り、お客様にはリプレイス後の機能に設定を移行していただくという決断を、ビジネスサイドを含めてできました。
お客様に手間をかけることになり、一時的に顧客満足度が下がるリスクや、移行期間中のサポートコストの増加も伴います。しかし、デメリットをさしおいても、お客様の既存設定データを壊さないか気にせず開発できることで、より早くお客様に価値提供できることをビジネスサイドとしても選んでくれました。
この決断を、ビジネスサイドが一緒に背負ってくれました。お客様へのご案内と移行サポート、そして移行プロジェクトの推進を担ってくれました。
移行プロジェクトにおいては、社内で実行委員を立ち上げ、全お客様が設定移行できるよう日々問い合わせの対応や勉強会を開いていただいたりしています。社内外問わずで尋常ではなく大変なサポートを請け負っていただいていると感じています。
全お客様を移行してリプレイス前の機能のコードを消したい、というプロダクトサイドの気持ちも汲み取って動いていただけてとても感謝しています。
ドメインエキスパートとの協働による設計の深化
CSとPdMといったドメインエキスパートがチームに入り、機能の仕様設計から協働してくれたことで、ドメイン理解がより深まりました。
ドメインを深く理解することで、1つのステップで表現できるが、内部では複数のステップとして扱い並列実行できるケースがあることがわかりました。従来のデータモデルは、具体的な処理を一つ一つ個別に定義する必要があり、設定が爆発的に増加する構造でした。しかし、ドメインを深く理解することで、共通パターンを抽象化して定義できるデータモデルを設計でき、並列実行も可能になりました。
技術的にはKotlin Coroutinesを使った並列処理の実装自体は難しくありませんが、そういったステップがユースケースとして頻発することはドメインエキスパートなしには気づけませんでした。
その結果、あるお客様の設定では、旧機能では1000以上のステップが必要だったのが、新機能では100以下のステップで同じ処理を実現可能となり、約100分の1に設定ステップ数を削減できました。また、旧機能の設定で15分かかっていた処理が、新機能では1分未満で完了するようになりました（15倍以上の高速化）。メンテナンス性と理解しやすさが飛躍的に向上しました。
これらの改善は、技術的な難しさというより、ドメインエキスパートとの協働によってドメイン理解が深まったからこそ実現できたものです。
短いスパンでのフィードバックサイクル
ビジネスサイドに開発した機能を触ってレビューしてもらう機会を毎週設けていました。短いスパンでフィードバックをもらえることで、検討が不足している部分はすぐに検討に回せました。この繰り返しにより、要件の見落としを早期に発見し、開発の方向性を適切に調整できました。
ビジネスサイドが頼れる環境によって得られたメリット
このようにビジネスサイドとチームとして開発できたことで、お客様への大胆な決断を共に背負ってもらえ、ドメイン理解を深めることで技術だけでは気づけない課題解決が実現できました。また、お客様へのご案内の調整やリリース日の相談などもシームレスにでき、開発の進捗とビジネスの都合を両立させながらプロジェクトを進められました。結果として、設定ステップ数を約100分の1に削減し、処理時間を15倍以上高速化することができました。ビジネスサイドが真のパートナーとして機能することで、プロダクトの品質向上と顧客価値の最大化が実現できたのです。
プロジェクトの成果
達成した成果
このプロジェクトを通じて、以下の成果を達成できました：
プロダクト面：
- 処理時間：あるお客様の設定では15分 → 1分未満（15倍高速化）
- 設定の複雑さ：あるお客様の設定では約100分の1に削減
- 業務フローに沿った自然なUI/UX
お客様の初期設定や運用のコストを低減することができました。
技術面：
- ログラス初のモジュラーモノリス設計
- クリーンなアーキテクチャによる保守性向上
- 将来の機能拡張の余地を確保
中長期的なプロダクトのアウトカムを担保できる地盤を作れました。
余談ですが、直近で社内にだんだんリプレイス後の機能が浸透しており、リプレイス前と比べて「革命だ！」というような声もいただけています。
こういった声をいただけることも成果であり、やりがいになるなと思っています。
ログラスで働くことを検討している方へ
もしあなたが：
- 技術的なあるべきを模索し、それを実現したい
- ビジネスサイドと協働してにプロダクトを作りたい
そんな想いをお持ちなら、ログラスは良い環境だと思います。
このプロジェクトは、私にとってキャリアの中でも特に印象深いものになりました。
- 技術的にチャレンジングで
- チームとして成長できて
- そして何よりお客様に価値を届けられた
技術的投資を奨励する文化と、頼れるビジネスサイドがいる。
エンジニアとして「やりたいこと」ができる環境が、ログラスにはあるなと感じました。
このような環境を求めているエンジニアの方に、この記事が届けば嬉しいです。
採用情報
ログラスでは、一緒にプロダクトを作るエンジニアを募集しています。
このような環境に興味がある方は、ぜひカジュアル面談でお話ししましょう！
Discussion