Slide 1

Slide 1 text

パフォーマンス改善を支える アーキテクチャの役割とは?

Slide 2

Slide 2 text

©OPENLOGI Inc. 会社紹介 2

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

©OPENLOGI Inc. 荷主と物流パートナーを結ぶプラットフォーム 倉庫会社 マテハン 配送会社 資材会社 物流パートナー 5社 3社 荷主 5,300社 Eコマースを含む アパレル/雑貨/IPグッズ /インフルエンサー/マッ トレス/越境など様々 データ分析/活⽤ ‧需給予測 ‧リスク評価 ‧マッチング ‧最適化 ネットワーク化 提携70社 (※準提携130社) 12社 (国内‧海外) サービス提供 ソリューション 稼働率向上 庫内DX化 物流課題の解決 (コスト削減/効 率化‧⾃動化/最 適拠点配置等) 物流パートナーをネットワーク化することで、ノンアセット型のフルフィルメントサービスを提供 倉庫や配送といったフィジカルなリソースを AWSのようなインフラに変⾰し、サービスから得られる データを分析/活⽤することで、社会課題である物流業界の⾮効率を解消します 4

Slide 5

Slide 5 text

©OPENLOGI Inc. ビジョン実現のためのロードマップ 柔軟性の⾼い物流版AWSを実現し、将来的には配送やサプライチェーンを含めたコマース全体を最適化する “フィジカルインターネット”の世界観を⽬指して参ります 5 ECのグロース パートナー 倉庫 75社 従量課⾦ API連携 倉庫 1-2社 物流版AWS 倉庫 250社 フィジカル インターネット 倉庫 500社 倉庫NW拡⼤ 配送連携 倉庫 15社 • EC物流の原型 • メニュー化/標準化 • 多数荷主の⼀元管理 • 倉庫の空きスペースを 有効活⽤ • 在庫分散⇒コスト減 • 越境キャリアと連携 • EC事業の幅広いニーズ をカバー • ⾃動出荷率を向上 • マルチチャネル対応 • データ活⽤‧可視化 • ロボティクス化による オペレーション効率化 • ECの波動に対応 • モノの流れをデータで 捉え、究極に効率化 • 海外やSCM含めた コマース全体の最適化 フェーズ3 フェーズ4 フェーズ5 フェーズ1 フェーズ2

Slide 6

Slide 6 text

©OPENLOGI Inc. 37.5億円 シリーズD資⾦調達を実施 ー 累計調達額65億円 6 〜テクノロジーとデータを活⽤した物流プラットフォームの構築を加速〜 調達の⽬的と今後の展開 さらなる事業拡⼤を図り、この度の調達資⾦は、エンジニア職‧ ビジネス職を中⼼とした⼈材採⽤、及びプロダクト開発に充当する 予定です。物流業界内外から広く⼈材を募り組織基盤の強化に 取り組みます。 また、事業提携パートナーの強固なアセットを有効活⽤し、新規の 事業機会の追求を進め、物流の効率化、⾃動化、省⼈化を実現。 また倉庫ネットワークを活⽤した配送の効率化を⽬指します。 2024年問題という⽬下の社会課題の解消に貢献しつつ、 中⻑期的には企業の枠を超えた物流資産‧データを連携する 「フィジカルインターネット」を推進するために事業を 展開していきます。 オープンロジの採⽤について 事業拡⼤にともない、ビジネス職‧エンジニア職を中⼼に、 事業責任者、テックリード、プロダクトマネージャーなど様々な ポジションで採⽤を強化しております。 「テクノロジーを使い、サイロ化された物流をネットワーク化し データを起点にモノの流れを⾰新する」というオープンロジの ビジョンに共感し、実現を⼀緒に⽬指していける⽅のご応募を お待ちしております。 第三者割当増資 引受先 31VENTURES、Cygames Capital、東京海上ホールディングス、 HAKUHODO DY FUTURE DESIGN FUND、パーソルベンチャーパートナーズ、静岡キャピタル、あおぞら 企業投資、 Eight Roads Ventures Japan、Logistics Innovation Fund、SMBCベンチャーキャピタル 借入先 日本政策金融公庫、あおぞら企業投資、みずほ銀行、静岡銀行 ※2024年2月5日 プレスリリース ※2024年3月29日 プレスリリース

Slide 7

Slide 7 text

自己紹介 7

Slide 8

Slide 8 text

©OPENLOGI Inc. 自己紹介 deep-rain.com 2024年2月入社 CTO室所属 引当処理の改善に取り組んでいます。 どちらかといえば犬派です。 【経歴】 - 教育系事業会社 Software Engineer, 研究開発を経て、 Architectとしてアーキテクチャの価値に向き合う - 通信系事業会社 Architectとして、プロジェクト立ち上げの 0→1 のアーキテクチャを構築 - 個人事業 Sound Engineerとして 音楽のアーキテクチャに向き合う などなど、様々なアーキテクチャに向き合ってきた人生でした。

Slide 9

Slide 9 text

©OPENLOGI Inc. 自己紹介 9 CTO室とは? ● 全社的な課題に向き合い、生産性を最大化するチーム ● 重要機能や巨大機能のリファクタリング、リアーキテクチャなど、「機能開発」など のスコープからは外れる事柄を担当する ● 技術的負債や、横断的課題を含め、抽象度、不確実性が高いテーマに向き合うこ とが多い

Slide 10

Slide 10 text

©OPENLOGI Inc. 引当処理とは? 10

Slide 11

Slide 11 text

©OPENLOGI Inc. 引当処理とは? 11 倉庫に保管されている出庫可能な在庫を、実際の出庫指示に紐づけていく処理 荷主 倉庫 お届け先

Slide 12

Slide 12 text

©OPENLOGI Inc. 引当処理とは? 12 倉庫に保管されている出庫可能な在庫を、実際の出庫指示に紐づけていく処理 荷主 倉庫 お届け先 ここの話をします!

Slide 13

Slide 13 text

©OPENLOGI Inc. 引当処理とは? 入庫イメージ A-1 A-2 B-1 B-2 C-1 D-2 D-1 D-3 商品A 商品B 商品C

Slide 14

Slide 14 text

©OPENLOGI Inc. 引当処理とは? 入庫イメージ 商品C A-2 B-2 C-1 商品C 商品C 商品C 商品C 商品C 商品C 商品C 商品C 商品C 商品C A-1 B-1 D-2 D-1 D-3

Slide 15

Slide 15 text

©OPENLOGI Inc. 引当処理とは? 引当の例 商品Cが100個ほしい A-2 B-2 C-1 商品C 商品C 商品C 商品C 商品C 商品C 商品C 商品C 在庫20 在庫20 商品C 商品C 在庫20 在庫15 在庫20 在庫20 A-1から40個 B-1から35個 D-1から25個 持ってくれば 足りるはず… A-1 B-1 D-2 D-1 D-3

Slide 16

Slide 16 text

©OPENLOGI Inc. 引当処理とは? 16 倉庫に保管されている出庫可能な在庫を、実際の出庫指示に紐づけていく処理 入庫 ピッキング 出荷 出庫指示 openlogi 荷主 入庫処理 引当処理

Slide 17

Slide 17 text

©OPENLOGI Inc. 引当処理とは? 引当ができないと…? ● 出庫指示された商品に在庫があるのか? ● どこからピックすればいいのか? ● そもそも出庫可能なのか? わからない! 何もできない!

Slide 18

Slide 18 text

©OPENLOGI Inc. 引当処理とは? 引当ができないと…? 作業が進まない 経済的損失 信用の毀損 企業価値の毀損 配送遅延 機会損失

Slide 19

Slide 19 text

©OPENLOGI Inc. 引当処理とは? 引当ができないと…? 地球がヤバい! 物流という大動脈を止めてしまう。 つまり…

Slide 20

Slide 20 text

©OPENLOGI Inc. 引当処理の現状と課題 20

Slide 21

Slide 21 text

©OPENLOGI Inc. 引当処理の現状と課題 引当処理を紐解くと… DBに直接問い合わせて … トランザクション張って … データ取ってきて… あ…ロックもしないと… この引当情報は引当可能なんだっけ …? 引当可能だったらレコード作成して … コミットする… あ、エラーハンドリングもしないと … システムくん 引当リクエスト 引当処理くん

Slide 22

Slide 22 text

©OPENLOGI Inc. Confidential (社外秘) 何が課題なのか? 変更容易性 パフォーマンス 可読性 ● DBに直接依存しているので、処理を読み解くのに必要な知識が莫大になる ● トップレベルのエントリーポイントに詳細まで記述されており、全てを読み解かな いと意味のある知識を得られない ● 実装に直接依存しているため、影響範囲が計り知れず、テスト等 QAに多大な 時間が掛かる ● 依存の方向性が安定しておらず、安定させるべきモジュールとそうでないモ ジュールの区別がつかない ● パフォーマンスに関する事柄を隠蔽できていないので、パフォーマンスチューニ ングそのものが可読性、変更容易性の悪化に直結してしまう 22 引当処理の現状と課題

Slide 23

Slide 23 text

©OPENLOGI Inc. 引当処理の現状と課題 といった課題はあるものの、このアーキテクチャが悪い、というわけではありません。 どのようなコードやアーキテクチャでも、仕様に沿って動いているならそれは正しいですし、コードの良し悪しと いうものは目的に沿って語られるべきです。 ここまでの複雑性を持ったシステムで、振る舞いの価値を最大化し続けてきたのだから、 感謝と尊敬を忘れてはいけません。 先人は常に偉大です!

Slide 24

Slide 24 text

パフォーマンス改善とアーキテクチャ 24

Slide 25

Slide 25 text

©OPENLOGI Inc. パフォーマンス改善とアーキテクチャ パフォーマンス改善に向き合うために何が必要か? Don’t think, Profile… はもちろんのことですが、その先、コードに変更を加える場合には、 変更容易性 が必要不可欠ですよね!

Slide 26

Slide 26 text

©OPENLOGI Inc. (再掲)引当処理の現状と課題 引当処理を紐解くと… DBに直接問い合わせて … トランザクション張って … データ取ってきて… あ…ロックもしないと… この引当情報は引当可能なんだっけ …? 引当可能だったらレコード作成して … コミットする… あ、エラーハンドリングもしないと … システムくん 引当リクエスト 引当処理くん

Slide 27

Slide 27 text

©OPENLOGI Inc. パフォーマンス改善とアーキテクチャ パフォーマンス改善に耐えうるアーキテクチャ作り システムくん 引当 リクエスト 引当する 引当完了を 知らせる 引当処理くん 引当可能な在庫調べるくん 処理中の商品の 優先度を調べる 引当可能在庫を 取得する 優先度調べるくん … 引当するくん 引当情報を 保存する 引当可能な 在庫を調べる 在庫情報くん 引当情報くん 引当完了お知らせくん 引当完了イベント メールを送信する Slackに通知する 引当受付 システムくん専用受付窓口くん 理想 引当可能在庫計算くん 倉庫在庫を 取得 引当済在庫を 取得 引当情報Repoくん 在庫情報Repoくん モジュール インター フェース 上位モジュールへの依存 下位モジュールへの依存 凡例

Slide 28

Slide 28 text

©OPENLOGI Inc. パフォーマンス改善とアーキテクチャ パフォーマンス改善に耐えうるアーキテクチャ作り アーキテクチャは、ソフトウェア全体の文脈で捉えられがちですが、 巨大化したソフトウェア全体のアーキテクチャを切り替えることは非常に困難です。

Slide 29

Slide 29 text

©OPENLOGI Inc. パフォーマンス改善とアーキテクチャ パフォーマンス改善に耐えうるアーキテクチャ作り まずはモジュールを分離させ、小さい機能から少しずつ手を加えていくことで、少なくともそ の機能に関わる依存関係を整理していくことができます。 「大きな泥団子」に少し手を加えても「何か手が入った大きな泥団子」にしかなりませんが、 完全に分離させて別の役割を与えることで、それを「泥団子ではない何か」にすることができ ます。 ? ?

Slide 30

Slide 30 text

©OPENLOGI Inc. 引当する パフォーマンス改善とアーキテクチャ パフォーマンス改善に耐えうるアーキテクチャ作り システムくん 引当 リクエスト 引当完了 イベント 引当処理くん 処理中の商品の 優先度を調べる 引当可能在庫を 取得する 優先度調べるくん … 在庫情報くん 引当情報くん メールを送信 する Slackに通知 する 引当受付 現実 引当可能在庫計算くん 倉庫在庫を 取得 引当済在庫を 取得 引当情報を 保存する モジュール インター フェース 上位モジュールへの依存 下位モジュールへの依存 凡例

Slide 31

Slide 31 text

©OPENLOGI Inc. パフォーマンス改善とアーキテクチャ 目的ドリブンであること 今回の例で言えば、「パフォーマンス改善」という分かりやすい目的があり、そのために変更 容易性を確保する必要がある状態でした。 DDDなどはドメインの純粋性や完全性に寄与しますが、パフォーマンスを勘案したとき、そ れらが両立できないことはDDD Trilemmaとして提唱されています。 Domain model purity vs. domain model completeness (DDD Trilemma)  https://enterprisecraftsmanship.com/posts/domain-model-purity-completeness/ 引用:

Slide 32

Slide 32 text

©OPENLOGI Inc. パフォーマンス改善とアーキテクチャ 目的ドリブンであること バランスの取れた状態より 目的に沿った状態を目指す Software Performance Modifiability, Readability Domain Purity Domain Completeness

Slide 33

Slide 33 text

©OPENLOGI Inc. パフォーマンス改善とアーキテクチャ 目的ドリブンであること 例えば、ActiveRecordパターンはDDDとしては扱いづらいですが… ActiveRecordパターンに比べ、Repositoryパターンにおけるパフォーマンス上のメリッ トが薄いため、インターフェースを切ることによって影響範囲を抑えつつ、あえてそのま ま使います。 在庫情報くん 引当情報くん 引当可能在庫計算くん 倉庫在庫を 取得 引当済在庫を 取得 ドメインモデルではなくActiveRecordをそのまま取り回すのは、 DDD文脈ではデメリットが大きいですが …

Slide 34

Slide 34 text

©OPENLOGI Inc. パフォーマンス改善とアーキテクチャ パフォーマンス改善にとってアーキテクチャを整えることの何が嬉しいのか? ● インターフェースを切り、アプリケーションの上位方針を明確化することで、処理の流れ を追いやすくなる ● ストラングラーフィグパターンにより、比較的安全なリリースが可能になる ● 様々な実装を差し替えることが可能になり、実験がしやすくなる ● 依存の方向を揃えることにより、各モジュールの安定性と影響範囲が明確化される ● インターフェースに仕様を定義することで、テストが容易になる 全ては継続的なパフォーマンス改善のため!

Slide 35

Slide 35 text

©OPENLOGI Inc. パフォーマンス改善とアーキテクチャ パフォーマンス改善にとってアーキテクチャを整えることの何が嬉しいのか? 10年の道のりを経てきたソフトウェアにとって重要なことは、 DDDやClean Architectureなどのパターンを駆使して アーキテクチャを綺麗に整えることではありません。 いかにして変更を簡単に出来るようにするか? 将来に選択肢を残すことができるか? この先の10年を乗り越えるために必要なこと とは何かを考え続けることが重要だと考えています。

Slide 36

Slide 36 text

継続可能な構造価値 36

Slide 37

Slide 37 text

©OPENLOGI Inc. 継続可能な構造価値 As a team アーキテクチャはどんなにシンプルに見えても、 知らない人からすれば大変難解です。 インターフェースの使い方、依存の方向、抽象化…など。 現在は自然と意識できていることかもしれませんが、構造の価値に目を向けるまでは、その メリットすら分からなかった時代もあったはずです。 コードを扱い、維持していくのは我々ではなく、開発者組織全体であるということを忘れては なりません。 我々は、コードを書くだけでなく、 それを維持し、発展させていく責任があります。

Slide 38

Slide 38 text

©OPENLOGI Inc. 継続可能な構造価値 As a team パフォーマンス改善に伴う構造価値の創出は、そのきっかけでしかありません。 果てしなく、困難な道を、今、歩き始めたばかりなのです。

Slide 39

Slide 39 text

Are Hiring! We 39

Slide 40

Slide 40 text

©OPENLOGI Inc. 物流の未来を、動かす