巨大インフラ産業で戦うSRE / SRE working in the large infrastructure industry

SRE NEXT2024で発表した資料です。
https://sre-next.dev/2024/
#srenext

Transcript

1. 巨大インフラ産業で戦うSRE 株式会社オープンロジ 林 正紀 SRE NEXT 2024 2024.08.03
2. ©OPENLOGI Inc. 自己紹介 • 林 正紀 (Hayashi Masanori) • X(Twitter)： @m_norii • (株)オープンロジ 技術開発部 SRE • 2020年1月入社 • 埼玉県川越市在住 • 嫁とMr.Childrenと麻雀を愛するエンジニア
3. ©OPENLOGI Inc.
4. ©OPENLOGI Inc. 本日のAgenda • 会社紹介 • OPENLOGIとサービス信頼性 • OPENLOGIのSRE ◦ SREチームの取り組み① ◦ SREチームの取り組み② ◦ OPENLOGIのSREを振り返る • SREチームの現在とこれから • まとめ
5. ©OPENLOGI Inc. おことわり 本日の発表は、弊社でのSRE取り組み事例と SREにまつわる個人的な気づきを共有するものです。 SREとはこれだ！という唯一的なものを断言するものでもなければ 他の会社の状況にフィットすることを保証するものでもありません。 あくまで、いち企業いちエンジニアが、自身のコンテキストの中で SREを解釈し、取り組んだ事例としてお聞きいただければさいわいです。
6. ©OPENLOGI Inc. 本日のAgenda • 会社紹介 • OPENLOGIとサービス信頼性 • OPENLOGIのSRE ◦ SREチームの取り組み① ◦ SREチームの取り組み② ◦ OPENLOGIのSREを振り返る • SREチームの現在とこれから • まとめ
7. ©OPENLOGI Inc. 会社概要・沿革 会社名 株式会社オープンロジ 設立 2013年12月25日 代表者 代表取締役社長 CEO　伊藤 秀嗣 資本金 1億円 住所 東京都豊島区東池袋1-34-5 いちご東池袋ビル9階 事業内容 物流フルフィルメント・プラットフォーム 「OPENLOGI」の開発、提供 取引銀行 みずほ銀行、りそな銀行、 日本政策金融公庫、商工中金、 あおぞら企業投資等 社員数 192名（2024年7月時点）
8. ©OPENLOGI Inc. 物流の未来を、動かす Mission テクノロジーを使い、 サイロ化された物流をネットワーク化し データを起点にモノの流れを革新する Vision １．悩まない物流 荷主や倉庫が物流について 悩まなくても良い状態を作る ２．無駄のない物流 荷主-倉庫-配送が連携しムダの 少ない効率的な物流網を構築する ３．物流から商流へ 物流データを起点とした 新しい商流網を構築する 物流はこれから、テクノロジーがより浸透し ダイナミックに変化する これまでアナログだった物の流れがデジタルになり 高効率化された未来が到達する 物をつくる人とそれを欲しい人 その間の物流や配送が全てネットワーク化され 需要と供給が最適化される 物流の進化から、経済が新たに活性化する 次世代のインフラを作り、この時代の変革を 物流に関わる多くの情熱たちと共に成し遂げる
9. ©OPENLOGI Inc. オープンロジが目指す「遠くて高い山」 「物流」という巨大な業界と「EC」という急成長・ハイポテンシャルな市場に切り込み、 イノベーションを通じて、大きな社会的インパクトを実現したいと考えています    物流業界 24兆円 　　EC市場 14兆円 （出典）EC化率。経済産業省資料/2022年時点 日本 9.13% 中国 45.3% 米国 15.0% 世界 19.3% EC市場は長期で成長トレンド コロナ禍でも強い成長 日本のEC市場は 拡大余地が大きい 巨大 急成長 ハイポテンシャル
10. ©OPENLOGI Inc. サイロ化された物流課題 物流業界では各社が連携できておらず、それぞれ部分最適を目指した結果、”サイロ化”が起きており、 全体で見た場合には効率が悪いオペレーションが至るところで発生しています 荷主 › 物流ノウハウがなく、やり方がわからない › 委託先の倉庫の良し悪しが分からない › 小ロットは敬遠され、固定費が掛かる › 倉庫間の連携がなく、波動対応が受けき れない › 現場がアナログで、データによる 分析や生産性の改善が不在 › EC市場は成長するがドライバーが不足 →2024年問題（残業規制）が追い打ち › 積載効率が悪い（平均40％） 倉庫 配送 デジタル化（DX化）とネットワーク化により、物流業界は大幅に合理化・効率化が可能
11. ©OPENLOGI Inc. Whole Productの実現 受発注、入出庫在庫、配送など一連のオペレーションと物流ネットワークが一体となったWhole Productとして データを中心に、物流をAWSのようなインフラに変革、荷主や物流パートナー双方の課題を解決します 物流 ネットワーク 荷主 オペレーション 販売 チャネル 物流 オペレーション データ蓄積/分析
12. ©OPENLOGI Inc. 荷主と物流パートナーを結ぶプラットフォーム 倉庫会社 マテハン 配送会社 資材会社 物流パートナー 5社 3社 荷主 5,300社 Eコマースを含む アパレル/雑貨/IPグッズ /インフルエンサー/マッ トレス/越境など様々 データ分析/活用 ‧需給予測 ・リスク評価 ・マッチング ・最適化 ネットワーク化 提携70社 （※準提携130社） 12社 （国内・海外） サービス提供 ソリューション 稼働率向上 庫内DX化 物流課題の解決 （コスト削減/効率 化・自動化/最適 拠点配置等） 物流パートナーをネットワーク化することで、ノンアセット型のフルフィルメントサービスを提供 倉庫や配送といったフィジカルなリソースを AWSのようなインフラに変革し、サービスから得られる データを分析/活用することで、社会課題である物流業界の非効率を解消します
13. ©OPENLOGI Inc. オープンロジプラットフォーム 「物流版AWS」をコンセプトとしたオープンロジプラットフォームには以下のような機能があり、 物流の始まりから終わりまで、サプライチェーン全体を最適化するソリューションを提供します 荷主向け システム 倉庫向け システム 受注連携 システム 請求清算 システム 分析 ツール 荷主が操作する 入出庫管理システム ・商品登録 ・入庫処理 ・出庫処理 他 倉庫作業者が 操作する 倉庫管理システム ・入庫検品 ・出庫検品 ・ロケーション登録 他 Shopifyなどの ECモールと連携 商品の受注と連動し シームレスな 商品管理を可能に 荷主・倉庫 双方の請求情報を 管理するシステム ・各種料金管理 ・集計処理 ・決済処理 他 荷主向けの 分析ツール 特定期間における 様々なデータを 把握することが可能 経営的な判断を サポート オープンロジプラットフォーム
14. ©OPENLOGI Inc. 技術開発体制 技術開発 WMS 倉庫システム Billing 請求管理システム    SRE インフラ/DevOps 基盤開発 Product Management Order Sync 受注連携システム Portal 荷主システム HHT ハンディターミナル   Design QA Engineering Management 組織横断 チーム    CTO室 負債解消  CRE データ基盤
15. ©OPENLOGI Inc. アーキテクチャ ※使用しているスタックの一部を図示。 実際のアーキテクチャとは多少異なります。
16. ©OPENLOGI Inc. 技術スタック 特定の技術に固執せず、課題を解決するために最適な技術を選定しています フロントエンド バックエンド データストア インフラ/モニタリング CI/CD IaC
17. ©OPENLOGI Inc. 本日のAgenda • 会社紹介 • OPENLOGIとサービス信頼性 • OPENLOGIのSRE ◦ SREチームの取り組み① ◦ SREチームの取り組み② ◦ OPENLOGIのSREを振り返る • SREチームの現在とこれから • まとめ
18. ©OPENLOGI Inc. EC事業者の業務〜物流の流れ 楽天 Amazon Yahoo! Japan 工場/メーカー
 フォワーダー
 卸し会社
 倉庫会社 
 入出庫業務
 EC事業者 
 発注
 生産
 引き渡し
 納品
 通関業務
 納品
 配送会社 
 入庫の連絡 
 出荷依頼
 出荷
 配送
 物 流 業 務
 顧 客 対 応
 仕 入 れ 業 務
 問い合わせ対応（未着、返品、商品について） 
 販 売 業 務
 出店
 自社
 BASE
19. ©OPENLOGI Inc. 倉庫内業務の流れ 工場/メーカー 
 フォワーダー 
 卸し会社 
 倉庫会社 
 通関業務 
 出 庫 業 務
 保 管 業 務
 入 庫 業 務
 ①
 ②
 ③
 ④
 ⑤
 ⑥
 ⑦
 ⑧
 ①
 ②
 ③
 ④
 ⑤
 ⑥
 ⑦
 倉庫着 
 デバンニング 
 着荷登録 
 作業台へ 
 入庫IDを読取る 
 開梱
 入庫内容確認 
 外装＆数量検品 
 棚入れ 
 ⑨
 ⑩
 ハウスコード貼り 
 ①棚保管 
 ②パレット保管 
 ③ハンガーラック保管 
 棚卸し
 ピッキングリスト出力 
 リストをとる 
 ピッキング 
 検品台へ 
 バーコード検品 
 ⑨
 ⑧
 梱包作業 
 送り状貼付 
 パレット積み 
 引き渡し 
 納品

20. ©OPENLOGI Inc. OPENLOGIのシステムに障害が発生すると… 工場/メーカー 
 フォワーダー 
 卸し会社 
 倉庫会社 
 通関業務 
 出 庫 業 務
 保 管 業 務
 入 庫 業 務
 ①
 ②
 ③
 ④
 ⑤
 ⑥
 ⑦
 ⑧
 ①
 ②
 ③
 ④
 ⑤
 ⑥
 ⑦
 倉庫着 
 デバンニング 
 着荷登録 
 作業台へ 
 入庫IDを読取る 
 開梱
 入庫内容確認 
 外装＆数量検品 
 棚入れ 
 ⑨
 ⑩
 ハウスコード貼り 
 ①棚保管 
 ②パレット保管 
 ③ハンガーラック保管 
 棚卸し
 ピッキングリスト出力 
 リストをとる 
 ピッキング 
 検品台へ 
 バーコード検品 
 ⑨
 ⑧
 梱包作業 
 送り状貼付 
 パレット積み 
 引き渡し 
 納品

21. ©OPENLOGI Inc. OPENLOGIサービスと信頼性 • EC事業者 ◦ 入庫・出庫依頼ができない ◦ 機会損失、エンドユーザへの信頼低下 • 倉庫 ◦ 入庫・出庫作業ができない ◦ 商品をエンドユーザに配送できない ◦ 倉庫作業員の手が止まってしまう • 物流は経済の血液循環 • リアルが絡むシステムは、障害発生時のインパクトが大きい • 高い信頼性が求められる
22. ©OPENLOGI Inc. 本日のAgenda • 会社紹介 • OPENLOGIとサービス信頼性 • OPENLOGIのSRE ◦ SREチームの取り組み① ◦ SREチームの取り組み② ◦ OPENLOGIのSREを振り返る • SREチームの現在とこれから • まとめ
23. ©OPENLOGI Inc. SREチーム発足以前 • (m_noriiが入社した2020年1月当時)エンジニアは18人 ◦ うち、インフラ担当は3名 • インフラチームは存在したが、言葉通りインフラ運用がメイン • SRE的な活動も一部ではあったが 当時はボーイスカウト的に気づいた人・得意な人が進めることが多かった （組織的に動けているわけではなかった）
24. ©OPENLOGI Inc. 2022年4月：SREチーム発足 • インフラチーム から SREチーム に名称変更する形で発足 • 発足当時の社内資料：
25. ©OPENLOGI Inc. SREチーム発足当時の個人的な想い • よりサービスに向き合おう、というのはそれはそう • とはいえ、この資料見る限り、今までとそんなにやること変わってない・・・？ • SRE本※ で言ってるSREよりも範囲広い感じ？ • SREって流行りだしな • インフラ、よりもSREって言ったほうが採用や技術広報的にもいいのかな？ ※ O'Reilly Japan 「SRE サイトリライアビリティエンジニアリング」のこと
26. ©OPENLOGI Inc. 本日のAgenda • 会社紹介 • OPENLOGIとサービス信頼性 • OPENLOGIのSRE ◦ SREチームの取り組み① ◦ SREチームの取り組み② ◦ OPENLOGIのSREを振り返る • SREチームの現在とこれから • まとめ
27. ©OPENLOGI Inc. SREチームの取り組み：オブザーバビリティの強化 • Datadogは導入していた • 十分に活用できていなかった • 一部、別システムも利用して いた ◦ CloudWatch ◦ PaperTrail
28. ©OPENLOGI Inc. SREチームの取り組み：オブザーバビリティの強化 スロークエリの可視化 →致命的な問題になる前に発見、対処ができるように
29. ©OPENLOGI Inc. SREチームの取り組み：オブザーバビリティの強化 SLOの導入 →非同期処理の「なんとなく重い」が可視化 　 明確な基準で対処できるように
30. ©OPENLOGI Inc. SREチームの取り組み：オブザーバビリティの強化 Profiler の導入 →PHP実行関数単位での 　 処理時間の可視化 →ボトルネックになっていた 　 重いバッチ処理の改善に繋がる
31. ©OPENLOGI Inc. SREチームの取り組み：オブザーバビリティの強化 • Datadogは導入していた • 十分に活用できていなかった • 一部、別システムも利用して いた ◦ CloudWatch ◦ PaperTrail • 監視基盤をDatadogに集約 • ダッシュボード整備 • SLI/SLO整備 • Profiler導入
32. ©OPENLOGI Inc. SREチームの取り組み：パフォーマンス改善 • 問題が発生したベースで アドホックに対応 • パフォーマンス劣化が ビジネスにも影響
33. ©OPENLOGI Inc. SREチームの取り組み：パフォーマンス改善 レイテンシーの改善 →特に処理時間がかかっていた 　 特定エンドポイントに対する処理が大幅に改善
34. ©OPENLOGI Inc. SREチームの取り組み：パフォーマンス改善 スロークエリの解消で、DBのレイテンシーも大幅改善 CPU使用率も安定するように
35. ©OPENLOGI Inc. SREチームの取り組み：パフォーマンス改善 • 問題が発生したベースで アドホックに対応 • パフォーマンス劣化が ビジネスにも影響 • Datadog整備により 潜在的なパフォーマンスリスクを 事前に検知 • レスポンスタイムの改善 • DB負荷の改善
36. ©OPENLOGI Inc. SREチームの取り組み：IaC化 • AWS、Datadog等 SaaSの設定は Webコンソールから • 履歴が残っておらず 後日、なんのために 設定されたものかわからず 困ることも • Terraformを採用 ◦ Datadog Monitor/SLO ◦ GitHub ◦ AWS
37. ©OPENLOGI Inc. 本日のAgenda • 会社紹介 • OPENLOGIとサービス信頼性 • OPENLOGIのSRE ◦ SREチームの取り組み① ◦ SREチームの取り組み② ◦ OPENLOGIのSREを振り返る • SREチームの現在とこれから • まとめ
38. ©OPENLOGI Inc. SREチームの取り組み：GitHub Actionsによる自動化 • 一部便利ツール的なものは あったが、体系立てて管理さ れていなかった • インフラ/SREチームへ依頼 ベースでの作業も多かった • リリース手順が煩雑で、ミス も多かった
39. ©OPENLOGI Inc. SREチームの取り組み：GitHub Actionsによる自動化 QA用DB立ち上げ Before: エンジニアがチケット起票してSREに依頼 After: エンジニア自身でActionを実行
40. ©OPENLOGI Inc. SREチームの取り組み：GitHub Actionsによる自動化 Before: リリース担当がコマンドを逐次実行 (ミスも多かった) After: メンテ開始Action、デプロイAction、 メンテ終了Actionを実行するだけ デプロイ・リリースの自動化
41. ©OPENLOGI Inc. SREチームの取り組み：GitHub Actionsによる自動化 • 一部便利ツール的なものは あったが、体系立てて管理さ れていなかった • インフラ/SREチームへ依頼 ベースでの作業も多かった • リリース手順が煩雑で、ミス も多かった • GitHub Actionsを活用し 開発エンジニアで完結するように （セルフサービス化、認知負荷軽減） ◦ QA環境立ち上げ ◦ QA用DB立ち上げ ◦ デプロイ・リリースの実行
42. ©OPENLOGI Inc. SREチームの取り組み：コード品質強化および可視化 • lint等の実行は 開発者個々人任せだった • UnitTestがある機能と 無い機能が混在 ◦ どのくらいテストが 網羅しているのかも わかっていなかった
43. ©OPENLOGI Inc. SREチームの取り組み：コード品質強化および可視化 各種LinterをCIに導入
44. ©OPENLOGI Inc. SREチームの取り組み：コード品質強化および可視化 Code Climateの導入 カバレッジ率の可視化 PR上でカバレッジの変化率を表示 PR上でCode Smellを指摘
45. ©OPENLOGI Inc. SREチームの取り組み：コード品質強化および可視化 • lint等の実行は 開発者個々人任せだった • UnitTestがある機能と 無い機能が混在 ◦ どのくらいテストが 網羅しているのかも わかっていなかった • 各種Linter等をCIに導入 ◦ PHPStan ◦ PHP CS Fixer ◦ ESLint ◦ Shellcheck ◦ Secretlint • CodeClimateを導入 ◦ テストカバレッジを可視化 ◦ 問題あるコード自動指摘 • →開発生産性向上
46. ©OPENLOGI Inc. SREチームの取り組み：他チームとのコラボレーション • 課題が発生すると その都度会議を招集 • チームごとに課題を抱えが ちだった
47. ©OPENLOGI Inc. SREチームの取り組み：他チームとのコラボレーション • SREチームと関わりの深いチームと定期的にMtgを実施 ◦ 開催頻度は関わり度合いにより異なる（週1〜月1） • 各チームの課題をヒアリング 課題の早期発見・早期解決を目指す • SREチームとしての要望、導入して欲しい事の共有も実施 • 取り扱う課題は「SREプラクティス」にこだわらない 困っていることがあれば基本的に何でも聞く Sync Mtgの導入
48. ©OPENLOGI Inc. SREチームの取り組み：他チームとのコラボレーション Collaboration: 頻繁に交流をし、課題把握・課題解決を密接に行って いる Facilitation: 業務を推進するためのサポート、もしくは実作業を代 わりに実施している X-as-a-Service: 一般的なチーム 問い合わせ・依頼など、決まった手順を介してのやり 取り 他チームとの関係性
49. ©OPENLOGI Inc. SREチームの取り組み：他チームとのコラボレーション • 課題が発生すると その都度会議を招集 • チームごとに課題を抱えが ちだった • 開発チームとSync Mtgを定期的に実施 • 各チームと目線をあわせて「課題」に取り組 めるようになった • SREチームの取り組みが「組織・会社に貢 献できている」という確信が得られた • 他のチームも「孤独」だったことに気づいた ◦ 誰に相談してよいか分からない悩み を抱えていた ◦ オープンスタンスで話をする場の大 事さを感じた
50. ©OPENLOGI Inc. 本日のAgenda • 会社紹介 • OPENLOGIとサービス信頼性 • OPENLOGIのSRE ◦ SREチームの取り組み① ◦ SREチームの取り組み② ◦ OPENLOGIのSREを振り返る • SREチームの現在とこれから • まとめ
51. ©OPENLOGI Inc. SREチームの取り組みを振り返ると… • オブザーバビリティの強化 • パフォーマンス改善 • IaC化 • GitHub Actionsによる自動化 • コード品質強化および可視化 • 他チームとのコラボレーション
52. ©OPENLOGI Inc. Platform Enginnering Kaigi 2024より 「Platform Engineering とSREの⾨」@nwiizo https://speakerdeck.com/nwiizo/platform-engineering-to-sre-nomen?slide=28 SREチームの取り組みを振り返ると…
53. ©OPENLOGI Inc. SREチームの取り組みを振り返ると… • オブザーバビリティの強化 • パフォーマンス改善 • IaC化 • GitHub Actionsによる自動化 • コード品質強化および可視化 • 他チームとのコラボレーション Site Reliability Engineering Platform Engineering
54. ©OPENLOGI Inc. OPENLOGIのSREチームの活動範囲 Site Reliablity Engineering Security Platform Engineering ※ Securityの取り組みについては当登壇では割愛しています
55. ©OPENLOGI Inc. SREチーム発足当時の個人的な想い → 現在は • よりサービスに向き合おう、というのはそれはそう • とはいえ、この資料見る限り、今までとそんなにやること変わってない・・・？ • SRE本 で言ってるSREよりも範囲広い感じ？ • SREって流行りだしな • インフラチーム、よりもSREって言ったほうが採用や技術広報的にもいいのかな？ • チーム名は大事 ◦ 「運用だけのチーム」から「サービス信頼性に責任を持つチーム」に意識が変わる ◦ 事業貢献への意識に繋がる • SREといっても、取り組むべきプラクティスは各社の事情やフェーズで異なる ◦ 思想や原則は大事 ◦ プラクティスは参考にはすべきだが、各現場にフィットさせるのが重要 方針に一定理解しつつも、斜に構えていた部分もあった
56. ©OPENLOGI Inc. 本日のAgenda • 会社紹介 • OPENLOGIとサービス信頼性 • OPENLOGIのSRE ◦ SREチームの取り組み① ◦ SREチームの取り組み② ◦ OPENLOGIのSREを振り返る • SREチームの現在とこれから • まとめ
57. ©OPENLOGI Inc. SREチームの基本方針 • 横断的技術課題の解決によるビジネスへの貢献 ◦ SRE チームなりのやり方でビジネスに貢献する ◦ 以下の観点での貢献が可能と考えている 
 
 プラットフォーム 機能向上 処理能力が向上したり、使える機能が増える。結果サービスのUIUXや開発生産性向 上に寄与する 安定性向上 よりシステムが安定的に動作することで、人手を介さずに自律的に長期的にシステム が運営できるようになる（費用削減も含む） セキュリティ向上 セキュリティリスクが低減することで、サービス継続性に関わるリスクを減らすことが できる 開発生産性向上 開発チームや組織全体の開発効率が向上し、よりビジネス価値を創造しやすくなる
58. ©OPENLOGI Inc. SREチームの今後の課題 • Deployment Pipeline の改善 ◦ よりデプロイ回数を増やし、多様なリリースを行える環境の構築 • コンテナをベースにしたアーキテクチャへの移行 ◦ Container orchestration tool (ECS等) を用いたアプリケーション環境への移行 ◦ 柔軟なコンピュートリソースの確保、デプロイ戦略の改善のため • インフラのコードカバレッジの向上 ◦ IaC, CaD (Configuration as Data) 関連のツールを組み合わせ できる限りすべてのインフラ構成をコード化 • セキュリティの堅牢化 ◦ 日々刻々と変わる社会情勢、法関連の状況に即したインフラの改善 • ミドルウェア・ソフトウェアの適切なバージョンアップ ◦ 地味だがとても大事
59. ©OPENLOGI Inc. より将来の成長に向けて (Beyond NEXT) • 現状のOPENLOGIシステムのほとんどは、まだモノリスなアーキテクチャ • 拙速なマイクロサービス化には舵を切らない決断を以前している • しかし、将来のサービス成長を支えるためには、いずれ向き合わなければいけない課題 • そのときにSREチームがボトルネックになってはいけない ◦ SREはすぐにスケールできない ▪ 採用の難しさ • なので、OPENLOGIにもいずれ なんらかの形の Embedded SRE的なロールが必要になるのでは • 今はその将来を見越して、Platformをしっかり整備し、開発チームにSREの思想を啓蒙していくフェーズ
60. ©OPENLOGI Inc. より将来の成長に向けて (Beyond NEXT) • 「SLOはエンジニアのためだけのもの？」 ◦ SLOは本来、経営・ビジネス層も活用できるポテンシャルがあるはず ◦ 現在OPENLOGIのSLOは、システム寄りな指標のみ ◦ Critical User Journeyに基づいたSLOの策定には踏み込めてない ◦ Error Budgetも活用できていない ◦ とはいえ、一足飛びに導入は難しい ▪ 先にも述べたとおり、プラクティスありきではダメ ◦ 組織の成長にあわせ、適切なタイミングで検討したい
61. ©OPENLOGI Inc. 本日のAgenda • 会社紹介 • OPENLOGIとサービス信頼性 • OPENLOGIのSRE ◦ SREチームの取り組み① ◦ SREチームの取り組み② ◦ OPENLOGIのSREを振り返る • SREチームの現在とこれから • まとめ
62. ©OPENLOGI Inc. まとめ • OPENLOGIは、巨大な物流産業と急成長のEC市場をつなぐ プラットフォームを開発・運用 • リアルな「モノ」が動くシステムなので、サービスの信頼性が重要 • OPENLOGIのSREチームは、以下の領域で活動し、事業に貢献している ◦ サービス信頼性の向上 ◦ Platform Engineering ◦ セキュリティ • 将来のさらなる事業成長に向けて、OPENLOGIのSREとして よりあるべき姿を模索している
63. Are Hiring! We 現在急成長期で今がチャンス！ 全職種募集しています！ 63
64. ©OPENLOGI Inc. OPENLOGI note 公開中！ https://note.openlogi.com/ 毎月1回、もくもく会を開催しています！ https://openlogi.connpass.com/ 告知
65. ©OPENLOGI Inc. 物流の未来を、動かす