こんにちは！エニトグループ（with／Omiai）の採用担当です。
このほどサービス開始から13周年を迎えた『Omiai』。第二創業期に差し掛かる今、サービス強化に向けたエンジニアの積極採用に取り組んでいます。
今回はOmiaiのリアーキテクチャプロジェクトを推進したテックリードを務める渡邉と、元Omiaiで元インフラ責任者をされていた久松様に、リアーキテクチャプロジェクトをテーマにディスカッションしていただきました。
リアーキテクチャプロジェクトの背景や難しかったポイント、今後のOmiaiの展望などについて語っていただきました。
株式会社エニトグループは20代を中心に価値観重視の出会いを提供しているマッチングアプリ『with（運営：株式会社with）』と恋愛結婚を叶えるマッチングアプリ『Omiai（運営：株式会社Omiai）』の二つのマッチングアプリ企業を運営統括しています。
プロフィール紹介
渡邊 裕又｜株式会社Omiaiテックリード
2012年にスマートフォンを専業とするベンチャーの広告代理店にエンジニア技術職として就職。その後、業務管理システムの受託開発を行う会社を経て、2014年にフリーランスとして独立し、さまざまなプロジェクトに参画。2019年7月に株式会社ネットマーケティングに入社し、2023年3月に株式会社Omiaiに転籍。現在はOmiaiの開発基盤チームに所属。
久松 剛｜合同会社エンジニアリングマネージメント
2000年より慶應義塾大学村井純教授に師事。動画転送、P2Pなどの基礎研究や個人受託開発に取り組みつつ大学教員を目指す。博士（政策・メディア）。
2012年に株式会社ネットマーケティング入社。6年間Omiaiのインフラ責任者として24時間365日体制で対応。
その後、レバレジーズにて開発部長、LIGにてオフショア開発のマネージメントを担当。
2022年より合同会社を設立。老舗製造業、日系コンサル、スタートアップ、SES企業、人材紹介会社、スカウト媒体などを中心に複数社の組織改善コンサル、採用、研修、評価制度・給与制度コンサル、セミナー、執筆などに関わる。
Omiai技術的負債の歴史と課題設定
久松： 本日はありがとうございます。この対談は、技術的負債という大きなテーマに立ち向かう方々へ、私たちのプロダクトが一つの具体例として参考になればという思いから企画しました。
私がいわゆる「Omiai」の0から1、そして10までを担当し、その後に様々な「課題」を残した後、渡邊さんが奮闘してくれた、という構図です。まずは率直に、渡邊さんがリアーキテクトプロジェクトを立ち上げた主な目的は何だったのでしょうか？
3つの大きな問題点
渡邊： 改めての狙いとしては、主に3つの大きな問題点を解消することでした。
1. システムの拡張性、保守性の確保： 単純にプロダクトとして「これ以上システムが拡張できません」という大問題になっていた状態をまず解消すること。
2. コストの削減： ユーザー規模に対してかかっているコストが大きすぎたこと。当時は1ユーザーあたり約50円のコストがかかっており、これを改善する必要がありました。
3. 保守運用コストの低減： システムがレガシーであったため、マネージドサービス（運用を自動化するクラウドサービス）が普及し運用コストが減少していく世の中の状況に対して、「Omiaiだけは減ってない」という状況を解消することです。元々2006〜2007年頃のシステム開発の常識が、2023年時点でもそのまま残ってしまっていました。
久松： 当時の課題設定を明確にしていただきありがとうございます。まさしく、最小限のリソースで高い生産性を出そうとするエンジニア組織の目標とは真逆の、コストも拡張性も失われた状態だったわけですね。
当時のシステムは、2012年2月のサービス開始当初、外注（受託開発会社）から始まっていて、社内にはプログラミングがわかる人間が数人しかいない中でスタートしました。試作を優先するフェーズが長く続き、ソースコードやデータがどんどん複雑になっていったという反省があります。
レガシーシステムの実態
渡邊： ええ、まさに「メンテナンスされていない状態」が顕著でした。特にデータ周りでは顕著でした。リファクタリングに着手する前は、百数十テーブルあったうち、多くは使われていませんでした。
また、当時のシステム拡張の課題を調査すると、2016年、あるいは2014年や2015年からアップデートがないまま残っているデータベースが多数ありました。それらが無駄にデータ結合され、書き込まれ続けている状況でした。
久松： 「どこからも参照されず、更新だけはずっとし続けてる」データがあったわけですね。特に思い当たるのが、過去に実施したキャンペーンの負債です。既存のテーブルに施策のロジックを組み込んでしまったために、後から取り外しが困難になっていましたよね。
そして、当時の検索速度は、異性検索に1分以上かかるという状態でした。
渡邊： はい、そのような技術的負債の解消と、これ以上システムが拡張できないという状態を解消し、プロダクトの価値を向上できる状態にすることがリアーキテクトプロジェクトの最重要ミッションでした。
2019年の第1次リアーキテクチャ：失敗から学んだこと
久松： Omiaiのリアーキテクチャは今回が初めてではありませんよね。2019年に第1次リアーキテクチャを試みたと伺っています。またこちらは残念ながら失敗に終わってしまったそうですね。この失敗から何を学んだのかをお聞きしたいです。
第1次リアーキの目的と取り組み
渡邊： 2019年のリアーキテクチャでは、以下のような目的を掲げていました。
- システム寿命の延命：ドメイン定義を実施し、テーブルの再設計を行う
- 開発スピードの向上：マイクロサービス化の実施（影響範囲の特定を容易にするため）、BFFの導入（マイクロサービスによるフロントエンドの複雑化に対応するため）
- 運用コストの削減：マネージドサービス主体のインフラ構成への移行
- セキュリティの向上：業務内容ごとに特化した管理画面への刷新
久松： やっていることは常識的には間違っていないという評価ですよね。影響範囲を絞るためのマイクロサービス・BFFの導入、ドメイン定義・テーブルの再設計、移行時にいらないデータを削除など。
失敗の本質：目的の未定義
渡邊： その通りです。しかし、プロダクトレベルのトラブルの発生により、プロジェクト自体が途中停止してしまいました。ただ、継続していたとしても目的の達成は困難だったと考えています。
久松： なぜ目的の達成は困難だと評価しているのでしょうか？
渡邊： そのまま実施していたとしても、以下の問題がありました。
- 本当に目的達成したのかは判断することが不可能でもあった
- 時間・コストを目的達成のために使用できていたのかが不確実であった
本質的に必要だったものは、下記であったと考えています。
- 目的が達成している状態（ゴール）を決定
- できていないこと（課題）を洗い出して対応していくこと
2024年リアーキでの改善アプローチ
久松： つまり、2024年のリアーキテクチャでは、まず「ゴール」を明確に定義し、そこに到達するための課題を洗い出してから対応を決めて進めていけたのですね。
渡邊： はい、その通りです。例えば「システム拡張性の向上」という目的に対して、
ゴール：
- 修正の際には影響範囲が特定が容易になっていること
- 新規追加の際には他のモジュールに思わぬ影響を出さないこと
課題（当時）：
- データとデータでの密結合しているテーブルの存在
- 密結合が発生しているAPI・ソフトウェアモジュールの存在
対応：
- ドメイン設計を実施し、異なるドメインのデータとの結合をしないようにテーブルの再設計・データ移行
- 機能的な凝集をさせるようにソフトウェアモジュールを再設計
このように、目的を明確にし、そこまでの道筋を立てることが大事だと学びました。
プロジェクト概要：規模と目標
久松： 目的の明確化の重要性がよくわかりました。では、2024年のリアーキテクチャプロジェクトの具体的な規模感を教えていただけますか？
プロジェクトの基本情報
渡邊： はい。プロジェクトの概要は以下の通りです。
久松： かなりの規模ですね。ROI（投資対効果）の目標はどのように設定されていたのでしょうか？
ROI目標と期待効果
渡邊： プロジェクト計画書では以下を目標としていました。
久松： 年間の削減効果だけでも相当な金額ですね。さらに開発スピードの向上による機会損失の回避なども考えると、投資対効果は十分に見込めると判断されたわけですね。
渡邊： その通りです。特にこれ以上システムが拡張できない状態が、ビジネス機会の損失に直結していましたので、金額以上に大きな価値があったと考えています。
システム拡張性の劇的な向上
久松： では、具体的な成果についてお聞きします。まず、主要な目的の一つであった「システム拡張性の向上」は、どのように実現されたのでしょうか？
検索アルゴリズムの抜本的な見直し
渡邊： システム拡張性の向上という点で、最も大きな成果の一つは検索アルゴリズムの変更です。
以前はMySQLとElasticsearchの混合で検索をかけていましたが、これをすべてElasticsearchのみで処理するように変更しました。この結果、Omiaiのシステムは検索アルゴリズムに依存しない形になり、Elasticsearchのクエリさえ理解できれば、アルゴリズムのチューニングをどんどんできるようになっています。
久松： それは本当に画期的ですね。私がインフラ担当だった時代は、当時のプロダクトオーナーが望む検索表示順を出すために、エンジニアが数営業日かけてひたすらSELECT文の並び替えなどを行い、理想のSQLを定期的に作るという、非常にコストがかかる作業が発生していました。それに比べると、相当ライトになったと感動しました。
バッチシステムの構成改善
渡邊： はい、とんでもなくライトになっています。拡張性という意味ではもう一点、バッチシステムの構成改善も大きな影響を及ぼしました。
久松： バッチシステムもレガシーなPHPベースで動いていたので大変でしたよね。
渡邊： はい。今までPHPベース（CakePHP1.2）で動いていたバッチを全部Javaベースに変えました。
この構成改善自体が直接的にプラスの影響を出したわけではないんですけれども、この変更のおかげで、その後のお知らせ回りの改善をあまりコストをかけずに実施できるようになったというメリットが生まれました。
具体的には、通常4〜5日かかる修正が1〜2日で対応可能になっています。
久松： なるほど。リアーキテクトが土台を作ったことで、低コストで今後のプロダクト要件に対応できるようになったと。
実際のビジネス要件への対応
渡邊： その通りです。特に2024年になった時に、プロダクト側から全ユーザーに大量配信したいという要件が出てきました。ちょうどそのタイミングでプロダクトの課題とシステムの課題がぴったり一致したため、低コストで対応が完了し、新たなプロダクト要件への拡張性を確保できた形になります。
久松： 拡張性の向上を示す具体的な数値はありますか？
渡邊： はい。KPIとして以下を設定していました。
パフォーマンス改善：検索速度76%削減の衝撃
久松： 次に、パフォーマンス改善についてお聞きします。冒頭で話があった異性検索に1分以上かかっていた状況から、どこまで改善したのでしょうか？
検索速度の劇的な改善
渡邊： パフォーマンス改善については、特に検索速度で非常に大きな成果が出ました。
MySQLとElasticsearchの混合検索からElasticsearch一本に絞った結果、新メンバー検索の平均レイテンシーが約0.5秒も削減されました。
これは驚異的な改善だと捉えていて、削減率にすると76.95% に達しています。つまり、以前の時間で5回普通に検索できるようになったということです。
久松： すごいですね！当時の私は、1分以上かかる検索を何とかごまかすために、くるくる回るローディングアニメーションを追加する施策を打っていましたからね。それが5回できるようになったというのは、ユーザー体験としても全く別物です。
このスピードアップは、ユーザーの「いいね数」の増加にも寄与した可能性があると推測されていますよね。
検索種別ごとの改善実績
渡邊： はい、その可能性は高いと考えています。検索種別ごとの改善実績は以下の通りです：
| API名 | リアーキ前（平均秒） | リアーキ後（平均秒） | 削減率 |
|---|---|---|---|
| 新メンバー検索 | 0.491 | 0.113 | 76.94% |
| キーワード検索 | 0.657 | 0.162 | 75.35% |
| いいね多い順検索 | 0.311 | 0.249 | 19.89% |
| ログイン順検索 | 0.211 | 0.141 | 33.31% |
| おすすめ検索 | 0.312 | 0.227 | 27.22% |
| ハイライト検索 | 0.135 | 0.100 | 26.45% |
検索周りのAPIで20〜75%のスピードアップを実現しました。
久松： データリファクタリング（いいね）でさらにスピードアップの余地もあるということですね。
API全体のパフォーマンス向上
渡邊： はい。また、パフォーマンス向上は検索だけに留まりません。データベースのリファクタリング、特に負荷が高かった「いいね」周りのデータ整理によって、ディスクリードの件数や量が激減しました。
その結果、全てのAPIの平均レイテンシーが、従来の約500msから約350msまで、150msの削減を達成しています。
KPIとしては、下記のような結果を出しています。
久松： API全体での底上げができたと。素晴らしい成果ですね。
コスト削減：月間1万ドル超の削減効果
久松： 次に、もう一つの大きな目的であったコスト削減については、具体的にどのような成果が出たのでしょうか？
サーバー費用の大幅削減
渡邊： パフォーマンスの改善は、そのままコスト削減に直結します。不要な処理が多かったシステムから高すぎる要求スペックが解消されたため、1日あたり300ドルのサーバー費用削減が実現しました。最終的には月間1万ドル程度の削減効果（年間約1,200万円）を超えています。
特に「いいね」のデータリファクタリングのリリース初速では、1日$300のコスト削減（月間で$9,300） を観測しました。リクエスト数が少し増大したにもかかわらず、DBインフラのコストが$300近く下がっているのが確認できました。
久松： 月間1万ドル超えですか。当時、1ユーザーあたり約50円という大きなコストがかかっていた状況から考えると、劇的な改善ですね。
運用コストの面でも、EC2だらけだったインフラを近代化できたことが大きかったと聞いていますが。
EC2費用の削減とDiskReadの改善
渡邊： その通りです。KPIとしては、
また、データリファクタリング（いいね）のリリース時はDiskReadが1/10になっています。
インフラの近代化による運用負荷の軽減
渡邊： データベースをRDSなどのマネージドサービスへ移行したおかげで、サーバーの面倒を見る工数が大幅に削減されました。以前は月1回確認が必要だったものが、ほとんどチェック不要となり、年1回程度の対応で済むようになりました。
さらに、EC2で動いていたAPIサーバーをECSへ、メモリキャッシュをRedis（ElastiCache）へ、メールサーバーもEC2からSESへ載せ替えるなど、インフラ全体がかなり近代化しました。
その結果、IaC（Infrastructure as Code）のソースコードも整理され、良い意味で適度に対応できる保守性の高い環境が整ったと言えます。
久松： 運用面での改善も素晴らしいですね。スケール調整やデータ移行の時間も大幅に短縮されたと聞いています。
渡邊： はい。移行前はスケール調整やデータ移行に8時間以上とサービス停止が必要だったのが、移行後は30分程度で無停止で実施可能となりました。
技術的負債解消の先にあるエンジニアの醍醐味と未来
久松： パフォーマンス改善やコスト削減といった目覚ましい実績が生まれましたが、レガシーシステムと格闘し、リアーキテクトをやり切った先にある、エンジニアとしての醍醐味やキャリア上の価値、そしてOmiaiの未来について教えていただけますか？
レガシーシステムと向き合うやりがい
渡邊： はい。やりがいという点でまず言えるのは、ユーザーが揃っているプロダクトにおいて、レガシーな部分と立ち向かい改善していくことで、効果が目に見えてすぐわかるという点です。
もちろん困難は多いのですが、0→1（ゼロイチ）フェーズにはなかったシステム課題やプロダクト課題に対して、どう技術的にトライしていくかが必要になります。
久松： そうですね。0→1の時期はビジネス課題やユーザー課題から直接システム構築ができましたが、今動いているシステムの中から課題を自ら見つけ出して改善していくのは、遠回り感があっても重要ですよね。
渡邊： まさにそうです。そして、Omiaiはユーザー数が多いため、少しコストを削るだけでも、月間1万ドル程度の削減効果が出るといった、自身が行ったことに対する効果がしっかりわかる世界観があります。
パフォーマンスを改善して数値が全体的に向上したりといった、難しい課題に対して得られるべき経験が非常に大きいと考えています。
キャリア形成における価値
久松： キャリア形成という意味では、レガシーシステムと向き合う経験は今後どのような価値になるでしょうか？
渡邊： 今あるシステムをちゃんと理解して課題設定できて直せる人というのは、世間一般のエンジニアの中ではそんなに多くありません。だからこそ、やる価値があるんです。
他人の書いた「良くないコード」や「イマイチな設計」を見ていく中で、「こういうことはやってはいけないよね」というアンチパターンを学び、エンジニアとして成長できるチャンスがたくさんあります。
久松： 昨今のAIブームを考えると、今後のエンジニアに求められるスキルは変わりそうですね。
AI時代におけるエンジニアの価値
渡邊： 0→1の新しい実装やプログラミングは、AIやAIエージェントで徐々に代替されていくと考えています。しかし、レガシーな部分を直すとなると、AIにコンテキスト情報をどのように与えていくか考えるのが非常に難しいと考えています。
今抱えている技術負債がどういう課題で、AIに対してどう直すかを命令する人が今まで以上に求められる世界観になるだろうと思っています。この「コンテキスト情報を作る人」として、いい経験ができるはずです。
今後のOmiaiのエンジニア組織
久松： 今後のOmiaiのエンジニア組織や、一緒に働きたい人材像についてはいかがでしょうか？
渡邊： まず、一緒に働きたい人というのは、プロダクト志向を持つ人ですね。自分のタスク本位やシステム本位ではなく、プロダクトを成り立たせるための手段としてシステムを使いこなせる方が重要だと考えています。
久松： 「開発の中心にプロダクトの価値追求をおいているエンジニア」であるプロダクトエンジニアの志向性が必要ということですね。
渡邊： はい。取り組みとしては、まず技術負債が残っているフロントエンドの解消、特にFlutterの導入によって、プロダクト的な課題を解決していきたいです。ここはプロダクト本位で動いていきたいと考えています。
あとは、新機能開発において、プロダクト本位で考え「こういうAPIが良いよね、こういうテーブルが良いよね」と設計・実装できる方を求めています。
ビジネスサイドとの連携
久松： プロダクトを伸ばすためには、ビジネスサイドとの連携も重要になってくるかと思いますが、そのあたりはいかがでしょうか？
渡邊： Omiaiでは、テックリードやユニットリーダーがビジネスサイドと密にコミュニケーションを取っています。単に「これをやってください」と渡されても要件が抜けていることもあるので、密にコミュニケーションを取って要件を固めにいくことが重要だと考えています。
久松： なるほど。単にコードを書くだけでなく、数値をしっかり分析し、ビジネスサイドとのコミュニケーションを取りながら、プロダクトを良くしていく姿勢も重要だと。
Omiaiの独自価値の追求
渡邊： その通りです。その上で、マッチングアプリとして 「これこそがOmiaiだ」という独自価値をプロダクトとして作っていきたいと考えています。例えば新機能のモジュールは新しく作り直さないといけないため、そこで新しいアーキテクチャや技術を入れるなど技術的チャレンジのチャンスもまだまだあります。
まとめ：目的志向のリアーキテクチャが成功の鍵
久松： 最後に、これからリアーキテクチャに取り組む方々へのメッセージをお願いします。
渡邊： 目的に対しての手段はいくらでも存在します。それは簡単なものから、難しいものまで。何が最善かを考えるためには目的のブレイクダウンが必須です。
2019年の第1次リアーキテクチャでは、手段は間違っていなかったのですが、目的が明確に定義されていなかったために、本当に達成できたのかを判断することができませんでした。
2024年の第2次リアーキテクチャでは、この反省を活かして、
1. 目的を明確に定義
2. ゴール（達成状態）を具体的に設定
3. 課題を洗い出し
4. 対応を決定
というプロセスを踏むことで、目的の大部分を達成することができました。
久松： 具体的な成果としては、
がありましたよね。
そして何より、「これ以上システムが拡張できません」という状態から脱却し、今後の施策を現実的に実現可能にしたことが最大の成果ですね。
渡邊： はい。そして、これらの成果は「目的を明確にし、そこまでの道筋を立てる」という当たり前のことを徹底したからこそ得られたものです。
人はそれをよく忘れて手段に固執してしまいますが、常に「なぜこれをやるのか」「これで本当に目的を達成できるのか」を問い続けることが、リアーキテクチャ成功の鍵だと学びました。
久松： Omiaiのリアーキテクチャは、幾つかの失敗を経て、最終的に目的のほとんどを達成できたという、まさに学びの多いプロジェクトでしたね。本日は貴重なお話をありがとうございました。
渡邊： ありがとうございました。この経験が、技術的負債と向き合う多くのエンジニアの方々の参考になれば幸いです。
Discussion