© Omiai, Inc. 1 リアーキ「成功」までの道のり 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 
 Omiaiエンジニアチーム テックリード 渡邊 裕又 大学生時に、iOSアプリケーションを独学で開発・リリースまで に漕ぎ着ける 新卒として、ベンチャー広告代理店に入社後、サービス開発・ 運営に携わりフロントエンド ~ バックエンド ~ インフラのシステ ム全体の開発・保守に携わる その後、フリーランスとして、あらゆる規模のシステム開発に携 わり、フルスタックエンジニアとしての経験を5年ほど積み 2019年6月より株式会社Omiaiに入社、TL/EL就任。 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 
 今だから言える失敗を語る前に そもそも「失敗」とは何か？ ● 計画していたことが全てできなかったこと？ ● リリースしたシステムがバグってしまったこと？ ● 技術的な負債が全て解消できなかったこと？ 失敗とは「目的」を達成できなかったことします ● たとえ、計画が未達・技術的な負債を全て解消できていなくても、目的を 達成さえできれば、「成功」と言える 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 
 Omiaiにおけるリアーキテクチャの歴史 2012年 サービス開始 2019年 第1次リアーキ (失敗)2015年 言語リプレイス ● 目的未定義のため課題が 新たに発生 (成功)2024年 第2次リアーキ ● 目的の大部分を達成 今回の失敗は ここの話 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 
 2019年 第１次リアーキテクチャ 目的 目的 やりたかったこと システム寿命の延命 ● ドメイン定義を実施 ● テーブルの再設計 開発スピードの向上 ● マイクロサービス化の実施（影響範囲を特定を容易にするため） ● BFFの導入（マイクロサービスによるフロントエンドの複雑化に対応するため） 運用コストの削減 ● マネージドサービス主体のインフラ構成 セキュリティの向上 ● All in oneで権限の管理が曖昧な管理画面から、業務内容ごとに特化した管理画面にする ● 各種デプロイを管理できるようにする 結果 ● プロダクトレベルのトラブルの発生により、 PJT自体が途中停止 ● ただ、継続したとしても目的の達成は困難だったという評価 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 
 なぜ目的の達成は困難だと評価しているのか？ やっていることは常識的には間違っていないという評価 ● 影響範囲を絞るためのマイクロサービス・ BFFの導入 ● ドメイン定義・テーブルの再設計 ● 移行時にいらないデータを削除 そのまま実施していたとしても … ● 本当に目的達成したのかは判断することが不可能でもあった ● 時間・コストを目的達成のために使用できていたのかはものすごく微妙 本質的に必要だったもの： ● 目的が達成している状態 (ゴール)を決定 ● できていないこと(課題)を洗い出して対応していくこと 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 
 今だったらどうする 目的 ゴール 課題(当時) 対応 システム寿命の 延命 寿命を縮める原因である幾つかの テーブルのユーザが使用済の データの破棄 無駄が多いデータがない状態にす る 使用済みのデータでも分析・ユーザー対応のため削 除できない 1万ユーザー想定で構成され、大多数のユーザー想 定ができていないテーブルの存在 退会済でユーザーはすでに使用していないデータの削除、およ びに分析データとして分離 ドメイン設計を実施し、無駄が発生し、大量のデータを保持しや すいドメインのテーブルの再設計・データ移行 開発スピードの 向上 修正の際には影響範囲が特定が 容易になっていること 新規追加の際には他のモジュー ルに思うわぬ影響を出さないこと データとデータでの密結合しているテーブルの存在 密結合が発生しているAPI・ソフトウェアモジュール の存在 ドメイン設計を実施し、異なるドメインのデータとの結合をしない ようにテーブルの再設計・データ移行 機能的な凝集をさせるようにソフトウェアモジュールを再設計 運用コストの削 減 自前でのメンテナンスが必要にな るインフラ構成をマネージドサービ ス主体のインフラ構成にする メンテナンス頻度が高く、リスク・工数が大きいインフ ラリソースの存在 メンテナンス頻度が高く、リスク・工数が大きいインフラリソース を特定し、マネージドサービスに移行 セキュリティの向 上 外からの攻撃を防御できる仕組み が構築できていること 内からの流出を防御できる仕組み が構築できていること 外からの攻撃リスクが洗い出されていないこと 内からの流出経路が洗い出されていないこと セキュリティ診断の実施、その対応 内部で使用するシステムの権限の再設計・権限の再付与の実 施 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 
 目的を明確し、そこまで道筋を立てることが大事 目的に対しての手段はいくらでも存在する ● それは簡単なものから、難しいものまで ● 何が最善かを考えるためには目的のブレイクダウンが必須 ということで、 2024年のリアーキのお話し 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 
 2024年 第2次リアーキテクチャ 目的 目的 ゴール システムパフォーマンス の向上とランニングコス トの低減 無駄の少ないデータアクセスの実施し、ランニングコストを低減し、コア機能への投資に回す 機能修正の際の影響範囲特定を容易にする。機能追加の際には既存機能に影響を出しづらくする 保守・運用コストの低減 自前でのインフラ運用をさけ、そこで発生する工数を別のところへの投資に回す システム拡張性の向上 機能修正の際の影響範囲特定を容易にする。機能追加の際に既存機能への思わぬ影響がでないようなシステム構成にする 複数存在する言語の統一 プラットフォーム間の仕様の差分がでないような仕組みの構築 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 
 Omiaiの場合(2024リアーキ : 課題の洗い出し) それぞれのレイヤーでの課題の洗い出し Frontend Software Backend Software どこで 何が起きていたか その結果どうなっていたか PF間での仕様差が激しい 使用把握・影響範囲把握が困難 要件定義・検証工数が増加 PFごとに担当エンジニアを 採用する必要性がある 組織拡大が困難 APIの粒度が大きいため、 FEが不要な情報までAPIレスポンス データ効率性が悪化 データ操作コストを増大 巨大な共通クラス 影響把握の上での 実装・検証工数を著しく増大 異なるプログラミング言語で実装 組織拡大が困難 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 
 Omiaiの場合(2024リアーキ : 課題の洗い出し) それぞれのレイヤーでの課題の洗い出し Infrastucture Database どこで 何が起きていたか その結果どうなっていたか EC2中心のインフラ 領域が違うデータが 一つのテーブルにて管理 運用工数の増加 一つの領域に関わる開発をする際、 無関係な領域の開発・検証が必要 開発コスト・検証コストが著しく増大 初期のデータ設計の失敗により、 数億テーブルのコア機能の データ取得が効率できていなかった データベース運用コストの増大 お金で解決していた 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 
 Omiaiの場合(2024リアーキ : 対応の決定) 課題が多かったので、「最もゴールに寄与できる課題を解消する」を対応することに Backend Software 開発コスト・検証コストを増大させる状態を解消するため Infrastructure Database どこを なぜ 組織の拡大・組織文化の構築をより早めるため 定常的にかかるヒトを使う運用を解消するため 影響範囲が広いため、ヒトとカネを コア機能の追加・修正に集中できなくなるような状態を解消するため 札束で効率を上げるような状態を解消し、 カネをコア機能の追加・修正に集中させるため ヒト・カネを拡張期の実施する案件に集中させるため 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 
 どう解決したか - 依存関係の分解 Omiaiが提供している機能の概念において存在しなければいけない 5W1Hベースでモデリング・ドメイン分解を実施 機能とデータ・データとデータの相互依存の解消 仕様変更による影響範囲の拡大防止 一意性・再利用性のあるデータが保持　の達成 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 
 どう解決したか - データ退避・インフラの最適化 アクティブユーザーに必要ではないデータを退避 データサーバをIaaSからマネージドサービスに変更 12年間に及ぶ保有データ 激しいパフォーマンス劣化 データ量が 半減 データ移行 コストが低下 パフォーマンス 改善 運用コストが 実質0に 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 
 どう解決したか - 安全なデータ移行 Backend Software ● 並行稼働形式でのリプレースを採用 ● 切り替えModuleでリリースを実施 ○ 不具合が出た場合、不具合検知から 1時間以内には即時切り替えを実施 ○ 切り替え後にプログラム修正・データ不整合の解消し、再リリース (旧)Databa se Frontend Software (新)Databa se (旧)Module (新)Module 切り替え Module 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 
 結果(課題解決でできたのか？) 課題 結果 一つの領域に関わる開発をする際、 無関係な領域の開発・検証が必要 開発コスト・検証コストが著しく増大 データベース運用コストの増大 お金で解決していた 影響範囲がドメインで区切られるようになり、特定が 容易に 影響範囲がドメインで区切られるようになり、特定が 容易に テーブルの再設計により データの無駄が省かれ、 操作パフォーマンスが向上 データ周りのインフラコストが約半分程度に (年間5000万程度削減) 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 
 今後解決するべき課題とその対応 フロントエンド側でFlutterの導入 ● フロントエンドチーム構築のコストの低減 ● PF間の仕様差分による検証・開発コスト低減 複数プラットフォーム対応による 開発コスト増 優先度をつけた上でのインフラ構成の刷新 ● マネージドサービス ● PaaS ● SaaS レガシー(IaaS)インフラによる 運用コスト増 相次ぐ仕様の変更によるパフォーマンス低下が起きてい るAPIの改修 →開発コスト・リスク発生確率の低減 影響範囲が必要以上に拡大している API クイック且つ高品質なサービス提供 ● CI/CDの拡張 ● QA自動化 →リードタイム短縮、生産性向上、品質向上の実現 継続的な外部品質の担保ができていない 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 
 まとめ 目的に対しての手段はいくらでも存在する ただ、その手段が目的に対して、どれだけ有用であるかを評価せずに、手段を講じてしまうと、 達成したかった目的を達成できなくなる 当たり前のことだけど、人はそれをよく忘れて手段に固執してしまう Omiaiのリアーキテクチャは幾つかの失敗で、上記を学んで、最終的に目的のほとんどを達成 できたという話