物流システムにおけるリファクタリングとアーキテクチャの再構築 〜依存関係とモジュール分割の重要性〜

本発表では、10年の歴史を持つ物流システムにおけるリファクタリングとアーキテクチャ構築の戦略について紹介します。システムのパフォーマンス向上を目的に、変更容易性と拡張性を重視したシンプルなアーキテクチャを構築。従来の複雑な依存関係を整理し、モジュールの分離と役割分担を明確化することで、システムの柔軟性を高め、効率的なリファクタリングを実現しました。適切なモジュール化と、依存関係の整理がアーキテクチャ設計においていかに重要かを、実例を通じて詳述します。

Transcript

1. 物流システムにおける リファクタリングと アーキテクチャの再構築 〜依存関係とモジュール分割の重要性〜
2. ©OPENLOGI Inc. 会社紹介 2
4. EC事業者は… • 注⽂を受けた商品を迅速に配達する必要が あるが、すべての商品を⾃社で保管した り、配送などを⾏うことは稀 • 発送業務、保管、管理を外部委託すること で、コア業務に集中している これって何かに似ていませんか？ 「物流版クラウドサービス」とは？
5. クラウドサービスの恩恵 ITエンジニアも、クラウドの恩恵を受けてきた • サーバー管理の負担を軽減 • 物理サーバーの設置が不要 • ⾃社のリソースをコア業務に集中 • クラウドの柔軟性で効率的な運営 物理サーバーの設置や管理をクラウドサービスに 委託し、コア業務に専念できるように 「物流版クラウドサービス」とは？
6. サーバー配置 サービス開始 サーバー購入 オンプレミスの課題 オンプレミスでサービスを公開する場合 「物流版クラウドサービス」とは？
7. サーバー不⾜のリスク アクセスが急増すると… 「物流版クラウドサービス」とは？ サーバー不足 大規模障害 機会損失
8. 倉庫の選定 条件を交渉し契約 荷物の配送 「物流版クラウドサービス」とは？ 倉庫業務の外部委託の課題 倉庫の選定、契約、発送までのプロセスには多⼤な労⼒と時間がかかる
9. 「物流版クラウドサービス」とは？ 倉庫容量の制限とそのリスク 倉庫の容量や配送にも限界があり、商品が売れすぎると許容量を上回る。 新しい倉庫を契約するにも時間がかかり、需要の急増に間に合わない。
10. 「物流版クラウドサービス」とは？ 固定されたコストのリスク • サーバーの購⼊や倉庫の契約は、すぐに売却したり解約できない • 不要になった時も、コストがかかり続ける • つまり、過剰な⽀出が続く
11. 「物流版クラウドサービス」とは？ ITエンジニアにとって、クラウド技術は夢のようなサービス • 必要なときにすぐに拡⼤‧縮⼩ • いつでもすぐに使える • 無駄なリソースを持たない
12. 倉庫リソースもスケーラブルに • 必要なときに倉庫の契約をすぐに拡⼤‧縮⼩ • いつでもすぐに使える • 無駄なスペースを保持しない 「物流版クラウドサービス」とは？
13. サービスコンセプト：「物流版クラウドサービス」 契約や調整を最⼩限に、⾃社のスケールに合わせて拡張性のあるフィジカルな物流リソースを利⽤できます。 クラウドのような物流サービスを提供することで、EC事業の成⻑を加速して参ります 13 拡張性 倉庫のネットワーク化 による⾃社の成⻑に 応じた拡張性 コストダウン 継続的な値下げ 可⽤性 安⼼して継続し 利⽤できる品質改善 フルマネージド 倉庫/配送/資材/常温/ 冷蔵/冷凍など、多種多 様なフル マネージドサービス オンデマンド 従量課⾦で すぐに利⽤できる
14. 物流における様々な社会課題 • 倉庫の⼈⼿不⾜ • 配送の⼩⼝化 • 2024年問題 • ⾮効率な業務 「物流版クラウドサービス」とは？
15. ©OPENLOGI Inc. ビジョン実現のためのロードマップ 柔軟性の⾼い物流版クラウドサービスを実現し、将来的には配送やサプライチェーンを含めたコマース全体を 最適化する“フィジカルインターネット”の世界観を⽬指して参ります 15 ECのグロース パートナー 倉庫 75社 従量課⾦ API連携 倉庫 1-2社 物流版クラウド サービス 倉庫 250社 フィジカル インターネット 倉庫 500社 倉庫NW拡⼤ 配送連携 倉庫 15社 • EC物流の原型 • メニュー化/標準化 • 多数荷主の⼀元管理 • 倉庫の空きスペースを 有効活⽤ • 在庫分散⇒コスト減 • 越境キャリアと連携 • EC事業の幅広いニーズ をカバー • ⾃動出荷率を向上 • マルチチャネル対応 • データ活⽤‧可視化 • ロボティクス化による オペレーション効率化 • ECの波動に対応 • モノの流れをデータで 捉え、究極に効率化 • 海外やSCM含めた コマース全体の最適化 フェーズ３ フェーズ４ フェーズ５ フェーズ１ フェーズ２
16. 自己紹介 16
17. ©OPENLOGI Inc. 自己紹介 辻井 福嗣 2024年2⽉⼊社 CTO室所属 引当処理の改善に取り組んでいます。 どちらかといえば⽝派です。 【経歴】 - 教育系事業会社 Software Engineer, 研究開発を経て、 Architectとしてアーキテクチャの価値に向き合う - 通信系事業会社 Architectとして、プロジェクト⽴ち上げの0→1 のアーキテクチャを構築 - 個⼈事業 Sound Engineerとして ⾳楽のアーキテクチャに向き合う など、様々なアーキテクチャに向き合ってきた⼈⽣でした。
18. ©OPENLOGI Inc. 自己紹介 18 CTO室とは？ • 全社的な課題に向き合い、⽣産性を最⼤化するチーム • 重要機能や巨⼤機能のリファクタリング、リアーキテクチャなど、「機能開 発」などのスコープからは外れる事柄を担当する • 技術的負債や、横断的課題を含め、抽象度、不確実性が⾼いテーマに向き 合うことが多い
19. ©OPENLOGI Inc. 組織とプロジェクトの背景 19
20. ©OPENLOGI Inc. 資 ⾦ 調 達 15年3⽉ 16年5⽉ 17年7⽉ 20年10⽉ 24年3⽉ 0.6億円 シード 2.1億円 シリーズA 7.3億円 シリーズB 17.5億円 シリーズC 37.5億円 シリーズD 2014年10⽉ サービス ローンチ 導⼊アカウント数の推移 13,000+ 14/10 15/3 15/9 16/3 16/9 17/3 17/9 18/3 18/9 19/3 19/9 20/3 20/9 21/3 21/9 22/3 22/9 23/3 23/9 24/3 24/9 成⻑とともに抱える課題 オープンロジは、これまで10年の歴史を経て、着実に成⻑してきました。 しかし、これからの成⻑を⽀えるには、技術的負債が⼤きな障害となっています。 組織とプロジェクトの背景 20 従業員数 194 エンジニア 組織の人数 58
21. ©OPENLOGI Inc. 組織とプロジェクトの背景 21 巨⼤なコードベース ⻑い歴史を積み重ねてきたコードは、160万⾏にも達しています。 ファイル数 14,125 コードの総行数 1,616,326 erikbern/git-of-theseus
22. ©OPENLOGI Inc. 組織とプロジェクトの背景 22 技術的負債 オープンロジの根幹を⽀える、超重要なクラスの⾏数は… 超重要クラスの行数 3,308
23. ©OPENLOGI Inc. 組織とプロジェクトの背景 23 変更容易性の⽋如 わずか⼗数⾏の変更のリリースに3ヶ⽉かかったものが ある • 複雑な依存関係により、些細な変更がシステム全体 に影響 • テストやデプロイにかかる⼿間が増加 • 予期せぬバグの修正により、開発が遅延 変更容易性の向上が必須！
24. ©OPENLOGI Inc. パフォーマンス課題とアーキテクチャ 24
25. ©OPENLOGI Inc. パフォーマンス課題とアーキテクチャ 25 パフォーマンス課題の表出 重要機能である「引当処理」のパフォーマンスが 課題 • 構造はパフォーマンスに直接的な関係はない が… • ⼤きくパフォーマンスを改善するためには、 抜本的な変更が必要 • 現状の構造では、少しの変更に⻑い時間が掛 かってしまい、改善が進まない
26. ©OPENLOGI Inc. パフォーマンス課題とアーキテクチャ 26 引当処理とは？ 引当処理とは、商品やリソースを在庫や注⽂データと照合し、必要な数量を確 保するプロセスで、システム全体の運⽤において重要な役割を果たしている • 注⽂された商品の在庫をチェックして確保する • この処理が遅れると、配送遅延に直結する 注文 引当 ピッキング 出荷
27. ©OPENLOGI Inc. パフォーマンス課題とアーキテクチャ 27 パフォーマンス改善のための⼤規模な構造改⾰ • 数百倍のパフォーマンス向上が必要 • 従来の構造では、その変更に対応できない • 構造の⾒直しと変更容易性の確保が必須 そのために必要なことは… • 依存関係の整理 • テストやリリース効率の向上
28. ©OPENLOGI Inc. リファクタリング戦略とアーキテクチャの設計 28
29. ©OPENLOGI Inc. リファクタリング戦略とアーキテクチャの設計 29 従来のMVCアーキテクチャとその限界 オープンロジでは、主にMVCアーキテクチャを採⽤していたが、 ⻑い年⽉を経て以下のような問題が顕在化 • 重要なサービスクラスが 3000行を超える状態 と なり、変更や拡張が困難に • 適切なモジュール化ができず、ロジックが一極集 中 • サービスクラスやモデル間の依存関係が複雑化 し、変更が難しくなった • 変更容易性の欠如により、廃止したコードが 放置 されている
30. ©OPENLOGI Inc. リファクタリング戦略とアーキテクチャの設計 30 シンプルなアーキテクチャの設計 • 変更の影響を最⼩限に抑え、安定性を向上させる • 理解と保守を簡単にし、⻑期的な開発効率を向上させる • テストの容易さを確保し、迅速かつ安全なリリースを実現する そのために… • モジュール間の依存を明確にし、インターフェースで分離 • 各機能が明確な責務を持つようにし、再利⽤可能なコンポーネントを設計 • モジュールを⼩さな単位に分割し、各機能が独⽴して変更可能にする
31. ©OPENLOGI Inc. リファクタリング戦略とアーキテクチャの設計 31 ⽬的の明確化 アーキテクチャに良し悪しは無く、「⽬的を達成できるかどうか」が重要 • 変更の影響を最⼩限に抑え、安定性を向上させる • 理解と保守を簡単にし、⻑期的な開発効率を向上させる • テストの容易さを確保し、迅速かつ安全なリリースを実現する 明確な⽬的を定義し、そこにフォーカスすることで 迷いのないシンプルな構造を⽬指す
32. ©OPENLOGI Inc. リファクタリング戦略とアーキテクチャの設計 32 依存の⽅向 依存の⽅向を揃えることで、安定性と柔軟性を明確化 • 軽々しく変更してはいけないもの • 柔軟性を保たなければいけないもの に切り分けることができる 依存する側 依存される側 安定性 低 ⾼ 柔軟性 ⾼ 低
33. ©OPENLOGI Inc. リファクタリング戦略とアーキテクチャの設計 33 MVCからモジュールを重視した構造へ Model View Controller 引当 在庫 入庫 出庫
34. ©OPENLOGI Inc. リファクタリング戦略とアーキテクチャの設計 34 フレームワークとは仲良くする • フレームワークは再利⽤可能な機能を提供し、開発をスピードアップする 頼もしいパートナー • フレームワークの強みを最⼤限に活かしつつ、⽬的を達成することを重視
35. ©OPENLOGI Inc. リファクタリング戦略とアーキテクチャの設計 35 フレームワークとの共存 Model （ORMapper） Controller 引当 フレームワークに依存したアプリケーション コアな仕様を含むモジュール 依存
36. ©OPENLOGI Inc. リファクタリング戦略とアーキテクチャの設計 36 フレームワークとの共存 Model （ORMapper） Controller 引当 フレームワークに依存したアプリケーション コアな仕様を含むモジュール ？ 依存
37. ©OPENLOGI Inc. リファクタリング戦略とアーキテクチャの設計 37 処理の整理 引当処理の流れは… 引当 優先度判定 結果の永続化
38. ©OPENLOGI Inc. リファクタリング戦略とアーキテクチャの設計 38 処理の整理 抽象化と細分化 引当 在庫情報取得 優先度判定 引当可否判定 結果の永続化 割当アルゴリズム 処理を分割
39. ©OPENLOGI Inc. リファクタリング戦略とアーキテクチャの設計 39 処理の整理 抽象化と細分化 在庫情報取得 引当可否判定 結果の永続化 割当アルゴリズム
40. ©OPENLOGI Inc. リファクタリング戦略とアーキテクチャの設計 40 インターフェースの重要性 依存の⽅向を変化させられる魔法 実装 実装 実装 実装 インターフェース 依存
41. ©OPENLOGI Inc. xxの商品をyy個 zzの場所から予約 xxの商品がyy個 zzの場所にある xxの商品が yy個ほしい リファクタリング戦略とアーキテクチャの設計 41 処理の整理 依存関係の整理 在庫情報取得 引当可否判定 結果の永続化 割当アルゴリズム 注文 在庫情報 引当結果 依存 input output input input output input input
42. ©OPENLOGI Inc. リファクタリング戦略とアーキテクチャの設計 42 フレームワークとの共存 Model （ORMapper） Controller フレームワークに依存したアプリケーション 注文 引当結果 在庫情報 在庫情報取得 割当アルゴリズム 結果の永続化 コアな仕様を含むモジュール 依存 引当可否判定
43. ©OPENLOGI Inc. リファクタリング戦略とアーキテクチャの設計 43 なぜDDDではないのか？ DDDは強⼒なパターン集だが… • DDDの代表的な書籍である、「エリック‧エ ヴァンスのドメイン駆動設計」は538ページにも およぶ内容で、学習にはかなりの時間がかかる • DDDの複雑な概念やパターンを理解し、実装に 適⽤するには、⾼度な理解と設計スキルが必要 • ⼤規模なチームでは、全メンバーが同じレベル に到達するのが難しい
44. ©OPENLOGI Inc. リファクタリング戦略とアーキテクチャの設計 44 可能な限りシンプルに • 構造化すればするほどコード量も増え、複雑に ⾒える • 設計思想を知らなければ、構造をキャッチアッ プすることが困難 • 複雑な仕様や要件を、シンプルでわかりやすい 構造に落とし込むことが課題
45. ©OPENLOGI Inc. リファクタリング戦略とアーキテクチャの設計 45 シンプルな設計を⽬指すために • ⾔葉をむやみに増やさない • 不要なパターンや概念を取り⼊れない • 明確な⽬的を定義する
46. ©OPENLOGI Inc. リファクタリング戦略とアーキテクチャの設計 46 ⽬的に合致するシンプルさを追い求める • モジュールを独⽴した機能に分割 • インターフェースの明⽰ • 依存の⽅向を揃える
47. ©OPENLOGI Inc. リファクタリングの進め方 47
48. ©OPENLOGI Inc. リファクタリングの進め方 48 インクリメンタルに進める 千⾥の道も⼀歩から • 巨⼤な変更を⼀度に加えようとしても上 ⼿く⾏かない • スコープを⼩さく区切って、少しずつ⼿ を加えていくことが重要 • ⼩さな成功の積み重ねが、最終的に⼤き な成功に繋がる
49. ©OPENLOGI Inc. リファクタリングの進め方 49 インクリメンタルに進める ⾊々やりたいことはあるが… 引当 在庫 入庫 出庫 請求 連携
50. ©OPENLOGI Inc. リファクタリングの進め方 50 インクリメンタルに進める ⼩さく始める 引当 在庫 入庫 出庫 請求 連携
51. ©OPENLOGI Inc. リファクタリングの進め方 51 テストを追加する 重要機能のリファクタリングにおいて、安全に進めるのは⾮常に重要な観点 • 異常が起きると、即事業存続に関わる 超重要処理 • データを活⽤し、単体テストのパターン を拡充 • 更に、包括的なテストとして、既存の データを機械的に分析し、あらゆる パターンを網羅
52. ©OPENLOGI Inc. リファクタリングの進め方 52 抽象と具象 • 構造設計は抽象的な話になりがち • しかし最終的な成果物は具体のコードである • 抽象と具象のレイヤー間でギャップが⽣まれる class InventoryAllocator : def __init__ (self): self.inventory = {} def add_item (self, item_name , quantity ): if item_name in self.inventory: self.inventory[item_name] += quantity else: self.inventory[item_name] = quantity def allocate_item (self, item_name , request_quantity ): if item_name not in self.inventory: raise ValueError ("Item not found" ) if self.inventory[item_name] < request_quantity: raise ValueError ("Insufficient stock" ) self.inventory[item_name] -= request_quantity return f"{request_quantity } units of {item_name } allocated"
53. ©OPENLOGI Inc. リファクタリングの進め方 53 抽象と具象の溝を埋めるには？ • ホワイトボードに図を書く？ • 設計書を起こす？ • プロトタイピング？
54. ©OPENLOGI Inc. リファクタリングの進め方 54 この図をコードに表現する 在庫情報取得 引当可否判定 結果の永続化 割当アルゴリズム 注文 在庫情報 引当結果
55. ©OPENLOGI Inc. リファクタリングの進め方 55 ⽅針のみをコードに表現し、PR上でやり取り interface AllocationAlgorithm { allocate(order: Order, availableStock: Inventory): AllocationResult; } 割当アルゴリズム interface InventoryInformation { getInventory(itemId: string): Inventory; } 在庫情報取得 class AllocationService { private inventoryInfo : InventoryInformation ; private allocationAlgo : AllocationAlgorithm ; processAllocation (order: Order): boolean { const availableStock = this.inventoryInfo .getInventory (order.itemId ); if (availableStock.quantity < order.quantity ) { console.log(`Not enough stock for item ${order.itemId }`); return false; } return this.allocationAlgo .allocate (order, availableStock ); } } 呼び出し元 ※実際のコードとは異なります
56. ©OPENLOGI Inc. リファクタリングの進め方 56 構造に関するレビューを終えてから詳細を実装 ⼤きな⼿戻りを防⽌しつつ、着実な⼀歩を積み重ね ていく • 最後まで実装してしまってからのレビューで は、構造に関する認識齟齬があった場合に⼤き な⼿戻りが発⽣するリスクがある • 最初に構造とインターフェースの仕様について の合意さえできていれば、詳細やテストの実装 はタスクを分割でき、並列化も可能 • インターフェースの明確な定義が鍵
57. ©OPENLOGI Inc. リファクタリングの進め方 57 抽象に戻って考え直すこともある 実装の都合でインターフェースや構造を考え直さなければならないことも… • ⼤筋で合意が取れていれば、⼤幅な⼿戻りになることは少ない • チーム全体で⼤きな⽅針について認識を揃えることが⼤事 • 明確な設計思想と、適切なコミュニケーションが必須
58. ©OPENLOGI Inc. リファクタリングの進め方 58 使われていない機能の削除も⼤切 廃⽌された機能のコードが残っていると、効率に⼤きく影響を与える • リファクタリングは、振る舞いを変更しない ことが前提 • 廃⽌された機能があると、使われていないに もかかわらず、新しいアーキテクチャに移⾏ するコストが掛かる • リファクタリングの際の認知負荷も増⼤し、 効率的な変更が難しくなる • 並⾏して、使われていない機能のコードや、 モデルの削除も進める
59. ©OPENLOGI Inc. 取り組みの結果 59
60. ©OPENLOGI Inc. 取り組みの結果 60 モジュール化と依存関係の整理により、変更容易性を確保 • ⼿続き的にひとつの関数に書かれていた、数百 ⾏のコードを4つの処理に分割し、モジュール 化 • インターフェースを定義し、モジュール毎の仕 様を確定させることで、実装を差し替え可能に • モジュール毎にテストを⾏うことが出来るよう になり、安全性が向上 • カナリアリリースや、ストラングラーフィグパ ターンなどの強⼒な置き換え⼿法を適⽤可能に
61. ©OPENLOGI Inc. 今後の展望と継続的な改善 61
62. ©OPENLOGI Inc. 今後の展望と継続的な改善 62 継続的なアーキテクチャ改善 システムの成⻑に伴い、アーキテクチャも進化し続ける必要がある • 今回のテーマである引当処理以外についても、モジュール化と依存の整理 を引き続き進める • 疎結合な構造により安全かつ迅速なリリースを可能に • 技術者組織全体が構造を維持し続けられる仕組みを構築 持続可能なシステムへ！
63. 結論 63
64. ©OPENLOGI Inc. 結論 64 依存関係の整理とモジュール分割が鍵 ⽐較的⼤規模な組織におけるレガシーシステムのリアーキテクチャでは、機能 の依存を整理し、疎結合なモジュールに分割することが鍵となる • 疎結合なモジュール設計 • 依存を意識した設計 • インクリメンタルな改善戦略 • 効率的なコミュニケーション これらを意識することで、効果的なリアーキテクチャを推進！
65. Are Hiring! We 現在急成⻑期で今がチャンス！ 全職種募集しています！ 65
66. ©OPENLOGI Inc. 物流の未来を、動かす