SRE NEXT 2026 何でも屋からの 脱却 SREとCTO室の役割を再定義し、 本来のSRE業務を取り戻すまでの道のり 

©OPENLOGI Inc. 

©OPENLOGI Inc. 問題を抱えているのは配送領域だけではありません。物流業界には私たちが直接触れている「配送事業者」 の他にも、⼤きく分けて消費者、荷主（EC事業者）、倉庫というステークホルダーで構成されており、 それぞれの領域が課題を抱えています 配送 倉庫 消費者 荷主 購⼊ （2022.9月末時点） 出荷 保管 配送 課題 課題 配送だけではない物流業界の問題 3 / 17 

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

物流版クラウドサービス 契約や調整を最⼩限に、⾃社のスケールに合わせて拡張性のあるフィジカルな物流リソースを利⽤できます。 エンジニアがクラウドインフラとしてAWSやGoogle Cloudを使うように、物流に関わる⼈がインフラとして オープンロジを使うことで、社会課題である物流業界の⾮効率を解消していきます 拡張性 倉庫のネットワーク化 による⾃社の成⻑に 応じた拡張性 コストダウン 継続的な値下げ 可⽤性 安⼼して継続し 利⽤できる品質改善 フルマネージド 倉庫/配送/資材/常温/ 冷蔵/冷凍などフル マネージドサービス オンデマンド 従量課⾦で すぐに利⽤できる 5 / 17 

問題提起 こんな経験ありませんか？ 誰が持つべきか わからない仕事がSREに 集まってくる 本来やりたい信頼性向上 が後回しになる 横断チームという理由で こぼれたタスクを 拾い続ける 6 / 17 

背景 オープンロジのSREが便利屋になった歴史的経緯 1 SREが唯⼀の横断 チームだった 2 受け⽫がない 技術課題がSREに 集まった 3 暫定対応が 積み重なった 4 困ったらSREに 相談が定着した 5 CTO室設⽴後も SREが持ち続けた 受け⽫のなさ × 相談定着 → 便利屋化が固定化 7 / 17 

現状 SREが抱えていたもの 運⽤系 社内システム / 権限付与 / データ連携 開発基盤系 CI/CD / リリーススクリ プト / GitHub / DXツール インフラ系 AWS / IaC / Security Hub アプリ寄りの相談 バージョンアップ / 性能調査 / データ移⾏ / バッチ実⾏ その他 相談先が不明な 技術課題の⼀次受け 8 / 17 

課題 何でも屋化で起きる問題 ⽇々の差し込みタスクへの対応 ■ 社内システム運⽤ ■ 権限付与 ■ 管轄外の相談 中⻑期の基盤改善が進まない ■ コンテナ化 ■ Aurora3 ■ IaC化 ■ Multi-AZ ■ インフラセキュリティ向上 差し込みが基盤改善を圧迫していた 9 / 17 

気づき 問題はタスク量ではなく境界の曖昧さ 量を減らす前に、境界を引き直す チームの役割が曖昧だった CTO室、SRE の担当が明確でない 歴史的経緯を継続し続けた 受け⽫がない仕事がSREに残り続けた 10 / 17 

⽅針 役割の再定義で⽬指したこと 歴史的経緯ではなく 原則で役割を分ける どの性質の仕事か、 で判断する SREが本来の 信頼性向上に 集中できる状態を作る 受け⽫のない仕事を SREに残し続けない 11 / 17 

定義 SREとCTO室の役割を再定義する SRE インフラ‧信頼性⽀援 ミッション 機能開発チームがビジネスロジックの開発に集中 できるよう、安全で信頼性の⾼いインフラを提供 し、開発速度を損なうことなくサービスの安定稼 働を実現 CTO室 技術牽引型⽀援 ミッション 各機能開発チームの改善活動における相談役となり、 そのハブとして機能することで、各チームの取り組み の連携を促進し、サービス全体の整合性を⾼め、中⻑ 期的なプロダクトの価値向上と技術的健全性を実現 ※ SREがタスクを多く抱えていたため、⼀旦はインフラ領域にフォーカスすることを決めた 12 / 17 

明⽂化 SREがやらないことも明⽂化した やらない アプリ固有のバグ修正 やらない アプリ固有のデバッグ やらない アプリ固有のデータ移⾏代⾏ やらない アプリ固有のバッチ実⾏代⾏ やらない アプリ固有のパフォーマンスチューニング 13 / 17 

実績 移管‧整理ができたもの 整理済 ライブラリアップデート 整理済 PHP、フレームワークの管理 整理済 GitHub Organization管理 整理済 DXツールのオーナー 整理済 CI/CDワークフローのオーナー 14 / 17 

現実 完璧にはできない 役割整理は完了した 注⼒できる状態は作れた しかし 移管先がないタスクは残り続けている 移管先チームの⽴ち上げ計画と ⼈員計画の策定 整理したら終わりではなく、 現実に合わせて更新し続ける 運⽤しながらチューニングし続ける 15 / 17 

学び 推進して⾒えてきたこと タスクを減らすことでは解決しない 量ではなく境界の問題 役割定義が必要 原則で切り分ける やらないことの明⽂化 適切なタスク判断ができる タスクを拾う受け⽫が必要 SRE以外の移管先を持つ 16 / 17 

まとめ まとめ 01 SREは便利屋ではない 02 SREは信頼性に向き合うチーム 03 SREの推進には組織側の設計が必要 04 役割を整理し、境界を決め、現実に合わせて更新し続ける SRE本来の仕事に、SREが集中できる組織へ 17 / 17