三越伊勢丹におけるDX向けプラットフォーム構築への挑戦 - E-JAWSカンファレンス2021

by アイムデジタルラボ

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Copyright© IM Digital Lab, Inc. All rights reserved. 講演者鈴⽊雄介 • (株)アイムデジタルラボ • 取締役 • Graat（グラーツ） • グロース・アーキテクチャ＆チームス(株) • 代表取締役社⻑ • ⽇本Javaユーザーグループ • サブリーダー/CCC運営委員⻑ • その他 • @yusuke_arclamp • http://arclamp.hatenablog.com/

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Copyright© IM Digital Lab, Inc. All rights reserved. 状況 DXの推進 • コロナ禍により取り組みが加速 • 三越伊勢丹リモートショッピング • 2020/4 アイデア • 2020/5 ワークショップ（コンセプト） • 2020/6 開発チーム編成 • モバイルアプリ、サーバなど20名規模 • 2020/7 開発スタート • 2020/10 内部リリース • 2020/11 プレスリリース • 毎週リリース継続中

Slide 9

Slide 9 text

Copyright© IM Digital Lab, Inc. All rights reserved. 状況 2025年の崖 • 三越伊勢丹も例外ではない • 2022年度中を⽬指してモダナイズを推進中 • 主に⾃動化による運⾏費削減、開発アジリティの向上 • その中で「DX向けプラットフォーム」の整備を推進 • 名称：ビジネスプラットフォーム（略称：BPF） • 三越伊勢丹リモートショッピングも利⽤既存システムが、事業部⾨ごとに構築されて、全社横断的なデータ活⽤ができなかったり、過剰なカスタマイズがなされているなどにより、複雑化・ブラックボックス化経済産業省 DXレポート〜ITシステム「2025年の崖」の克服とDXの本格的な展開〜

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Copyright© IM Digital Lab, Inc. All rights reserved. 何を作るのか？ DX＝お客様視点でサービスを構築する • ユーザー体験はシステムを横断する • フロントサービスは横断的に基幹システムを利⽤したい • 個別に調整するのは⼿間なので⼀元的に提供したい商品情報価格情報展開情報会員情報決済/ 配送⼀元的に提供する基盤お客様情報⾜の情報⾜に合う靴の⼀覧⾜に合う靴の詳細購⼊会員商品在庫/販売価格決済

Slide 13

Slide 13 text

Copyright© IM Digital Lab, Inc. All rights reserved. 何を作るのか？ビジネスプラットフォーム • 基幹のデータや機能をフロントから使いやすく • 単なるAPIゲートウェイでは機能が⾜らない • データのキャッシュ、加⼯も⾏う • 基幹のデータ更新をイベント配信商品情報価格情報展開情報会員情報決済/ 配送会員情報参照⾜形情報参照商品情報取得展開情報取得購⼊連携会員商品在庫/販売価格決済フロントサービスビジネスプラットフォーム

Slide 14

Slide 14 text

Copyright© IM Digital Lab, Inc. All rights reserved. API 何を作るのか？さまざまな連携をパターン化して整理 • 処理をゾーニングすることで再利⽤性を⾼める • ストレージゾーン：基幹からのI/Fを受け取る場所 • デリバリーゾーン：フロントへ配信する場所 RDB ストレージゾーンデリバリーゾーンロジックゾーン基幹システムﾌｧｲﾙ RDB 基幹システム収集 Topic RDB 配信 Topic ⾮同期ストリーミングキャッシュとAPI配信リアルイベント配信フロントサービスフロントサービス基幹システムフロントサービス APIルーティング変換 API 変換 API ｹﾞｰﾄｳｪｲビジネスプラットフォーム

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Copyright© IM Digital Lab, Inc. All rights reserved. どう作るのか？（技術編） DevOpsの実現 • 開発チームがインフラ構築/サービス運⽤も実施すればスピードアップと効率化が実現できる • でも、それが開発チームの負担にならないようにするこれまでこれからインフラ構築アプリ開発運⽤監視インフラチーム開発チーム運⽤監視チーム既存環境利⽤整備監視開発チーム運⽤監視チーム DevOps 環境利⽤利⽤通知インフラ DevOps ⽀援チームコア監視全体整備⽀援

Slide 17

Slide 17 text

Copyright© IM Digital Lab, Inc. All rights reserved. どう作るのか？（技術編） DevOps＝あれこれが⾃動になる • 障害からの⾃動復旧 • クラウドサービスのPaaSの採⽤ • 平⽇⽇中でリリース作業を⾏う • CI/CDツールによるビルド/デプロイパイプライン整備 • インフラ構築作業の⾃動化 • IaC(Infrastructure as code)ツールによるインフラ整備

Slide 18

Slide 18 text

Copyright© IM Digital Lab, Inc. All rights reserved. どう作るのか？（技術編）新たに環境を構築し、ガイドラインを策定 • 各種ガイドラインを策定 • AWS利⽤ガイドライン • CI/CDガイドライン • 運⽤ガイドライン • 既存のAWS環境とは切り離して策定 • 既存：リフト先としてIaaS前提で設計 • 新規：シフト先としてPaaS前提で設計

Slide 19

Slide 19 text

Copyright© IM Digital Lab, Inc. All rights reserved. どう作るのか？（技術編） AWSガイドライン • AWSのベストプラクティスを中⼼に設計 • EC2禁⽌（サーバレス/マネージドのみ） • アプリ:Fargate、Lambda • データベース:Aurora/DynamoDB • セキュリティ関連の構成は新規に定義 • 既存環境のガバナンスを参考に再定義を⾏い、再審査 • BPF⾃⾝だけではなく、フロントサービスも同様のガイドラインを利⽤

Slide 20

Slide 20 text

Copyright© IM Digital Lab, Inc. All rights reserved. どう作るのか？（技術編） AWSガイドライン • 例：サーバレスなバッチ機構 • 要素 • スケジューラー → Step Functions • Javaバッチプロセス → Fargate • 起動シェル → Lambda • ファイル加⼯処理 → Athena • 特徴 • バッチサーバ不要 • バッチプロセス単位で性能設計 ECR Step Functions Lambda Fargate Athena Java 1.ファイルコピー 2.ファイル加⼯ 3.処理

Slide 21

Slide 21 text

Copyright© IM Digital Lab, Inc. All rights reserved. どう作るのか？（技術編）プレスリリースを出しました • 今後、ノウハウの共有も進めていきたい • ⽇本全体でDX推進をやらなくちゃいけない • ご興味がある企業の⽅、ぜひ情報交換させてください • https://note.com/imd_lab/n/nb544bbdfc9c2 三越伊勢丹システム・ソリューションズ、IM Digital Lab 、サーバーワークスの3社が、クラウドネイティブな開発⼿法である、モード2開発基盤のガイドラインを策定 2021年1⽉20⽇

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Copyright© IM Digital Lab, Inc. All rights reserved. 基幹モダナイズ基幹機能の段階的置き換えにむけて • 基幹システム機能をBPFに移管し、再配置 • Step1:基幹の仕組みをクラウドネイティブに構築 • 基幹データを利⽤し、同じ結果がでるように • Step2:基幹と新システムを並⾏稼働し検証 • 既存システムは基幹のデータを利⽤ • 新規フロントシステムはBPFのデータを利⽤ • Step3:既存システムも段階的に新システムに移⾏ • Step4:利⽤されなくなった基幹を廃棄 • いわゆるストラングラーパターン

Slide 24

Slide 24 text

Copyright© IM Digital Lab, Inc. All rights reserved. 基幹モダナイズ基幹系機能をクラウドネイティブにシフト • 同じ処理を性能向上＋コスト削減 • POS情報API • オンラインAPIは数msのターンアラウンドを実現 • バッチでのファイル加⼯処理コストは⽉間数百円 • 在庫計算処理 • オンラインのピークも問題なく処理が可能 • 棚卸のような特殊なピークは平準化して処理 • 売上確定処理 • 基幹と同レベルの障害対応処理を実現

Slide 25

Slide 25 text

Copyright© IM Digital Lab, Inc. All rights reserved. 基幹モダナイズ POS情報API VPC 商品差分情報売上属性情報 POS情報API フロントサービス SFn 価格情報⽣成キャッシュデータ作成商品情報（含む価格）売上属性情報 SFn 商品情報（全件）商品情報ｴｸｽﾎﾟｰﾄ商品情報差分反映データコピー属性情報⽣成前⽇差分情報⽣成前⽇差分情報⽣成キャッシュデータ作成 SFn ⽇次再起動

Slide 26

Slide 26 text

Copyright© IM Digital Lab, Inc. All rights reserved. 基幹モダナイズ在庫計算処理 VPC 売上情報（リアル）伝票情報（数分毎）売上確定情報（毎⽇夜間）棚卸情報（特定⽇）売上情報伝票情報売上仕分け伝票仕分け在庫更新情報（リアル）在庫更新情報（バルク）更新（リアル）更新（バルク） SFn 伝票取込売上受信在庫参照API フロントサービス在庫DB ⽇中差分仕分け差分⽣成棚卸⽇在庫数棚卸差分取込 SFn 棚卸⽇在庫数退避

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Copyright© IM Digital Lab, Inc. All rights reserved. どう作るのか？（組織編） 2020年春、BPF構築スタート • BPF担当部署を設⽴し、構築を開始 • 内製メンバーを中⼼にしながら、各種の技術要素については⽀援体制を準備テクノロジー推進部ビジネスプラットフォームグループ <全体⽀援> アイムデジタルラボ C社 D社 <内製化⽀援> A社 B社 AWSJ

Slide 30

Slide 30 text

Copyright© IM Digital Lab, Inc. All rights reserved. どう作るのか？（組織編）ニーズに合わせて段階的に構築 • フロントサービスのニーズに合わせて構築 • 具体的な要求に対応することで無駄なものを作らない • ダメになったら作り直せばいいという割り切り • 現在、5機能の⼀部が稼働中。ビジョンの数％程度 • 逆に基幹I/Fは⼀度決めたら変えられない • なるべく基幹システム側に改修を発⽣させない • 基幹システムの現状や制約を最⼤限優先

Slide 31

Slide 31 text

Copyright© IM Digital Lab, Inc. All rights reserved. どう作るのか？（組織編）スクラムでマネジメント • 週次でスプリントを回しながらマネジメント • 週次で優先順位をリソースを調整 • 四半期で⼤きなリリース、⽉次で⼩さなリリース • 既存保守作業も含めて優先順位をつける • BPF担当部署は既存システムの保守も実施 • 緊急対応などの差込作業があることを前提に対応

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Copyright© IM Digital Lab, Inc. All rights reserved. ⽴ち上げの苦労カルチャーショックと挫折からのスタート • 部署はできたものの何をするかイメージできず • アイムデジタルラボで全体設計はしていたが、どうやって作っていくのかわからない • 利⽤する技術が既存の概念と違いすぎて判断しきれない • サーバレスって何がうれしいの？ • Fargateのサービスとタスクってなに？ECRと連携？ • バッチサーバがないってメリットは？ • Athenaってなに？ • オブザーバビリティってなに？

Slide 34

Slide 34 text

Copyright© IM Digital Lab, Inc. All rights reserved. ⽴ち上げの苦労まずは先⽣の真似をするところから • とりあえず動かしてみてから考えることにした • 概念だけ聞いていても理解しきれないので、想定要件をベースに先⽣たちとプロトして考えることにした • AWSのPrototyping Programも利⽤ • プロト実施時に無償でSAが集中サポートしてくれる設計:0.5⽇ ×2回実装:連続3⽇間 ×2チーム

Slide 35

Slide 35 text

Copyright© IM Digital Lab, Inc. All rights reserved. ⽴ち上げの苦労変化：質からスピードへ • 丁寧に設計するより、試⾏錯誤のほうが効率的 • 既存：丁寧に設計することで⼿戻りをなくす • BPF：早く試して、早く失敗して正解に近づける • 試⾏錯誤の⽅が学びが深い • 「なぜ失敗した？どうすればいい？」という思考が⼤事 • ただし、闇雲に試⾏錯誤してはダメ • 設計をパターン化して整理し、ポイントを明確にする

Slide 36

Slide 36 text

Copyright© IM Digital Lab, Inc. All rights reserved. ⽴ち上げの苦労変化：なるべく楽をする • あるものを使って「なくす/やらなくする」 • サーバレス:サーバもミドルウェアも管理しなくていい • Fargate:⾃動リリースができれば⼿順書が不要 • バッチサーバレス:プロセスごと性能調整で遅延回避 • Athena:⼤量データの加⼯が早く、安く • オブザーバビリティ:障害を予測して未然に防ぐ • 世の中にある便利なものを使い倒すほうが効率的

Slide 37

Slide 37 text

Copyright© IM Digital Lab, Inc. All rights reserved. ⽴ち上げの苦労専任化と⽬標設定でメンバーの成⻑をうながす • メンバーは専任にさせる • 既存保守兼任にすると⼿が動かず、学びが⼩さくなる • 少しずつだが確実に専任できるメンバーを増やす • 取り組むメンバーには具体的な⽬標を持たせる • 学ぶことが多いのでスキル獲得ステップを明⽰する • スキルマップは継続的に改善中

Slide 38

Slide 38 text

Copyright© IM Digital Lab, Inc. All rights reserved. ⽴ち上げの苦労悔しさが覚悟につながった • 最初の3ヶ⽉は何もできなかったという挫折 • いまから考えれば最初の試⾏錯誤だから失敗だらけなのは当然だけど... • 悔しさをバネに覚悟を決められた • 「ともかく先⽣の真似をしよう」という割り切り • 「失敗してもいいからやりきろう」という覚悟 • まだまだ⾃信はないけどできることは増えてきた • もっと早く！もっと楽に！

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Copyright© IM Digital Lab, Inc. All rights reserved. 何を作るのか？ビジネスプラットフォーム • ユーザーはシステムを横断して利⽤する • フロントシステムから基幹のデータや機能を使いやすくするためのプラットフォーム • フロントが欲しい形に基幹のデータや機能を再編集 • さまざまな連携をパターン化して整理 • 基幹I/F⼿法、フロント提供⼿法をパターン化

Slide 41

Slide 41 text

Copyright© IM Digital Lab, Inc. All rights reserved. どう作るのか？（技術編） PaaSを活⽤しながらDevOpsを実現する • DevOpsの実現 • インフラに関わる開発チームの効率化 • ⾃動復旧、平⽇⽇中リリース、インフラ作業の⾃動化 • 新たにガイドラインと環境を整備 • AWSガイドライン • EC2禁⽌。すべてサーバレス/マネージドにする • 基幹モダナイズに向けた取り組みも実施 • 基幹の仕組みをすり替えていく

Slide 42

Slide 42 text

Copyright© IM Digital Lab, Inc. All rights reserved. どう作るのか？（組織編）挫折をへて、メンバーが成⻑中 • 内製での構築を前提に組織と体制と準備 • フロントサービスのニーズに合わせた段階整備 • スクラムで週次マネジメント • ⽴ち上げの挫折があったから覚悟ができた • 最初はいままでの常識と違いすぎてついていけない • まずは先⽣の真似からやってみる • 「スピード」と「楽をする」ことを優先に • メンバーは専任させ、⽬標設定を通じて成⻑をうながす

Slide 43

Slide 43 text

Copyright© IM Digital Lab, Inc. All rights reserved. さいごに BPFの世界観をひろめていきたい • ⾃分たちでやれることが多くなる世界 • ⾃分たちで開発もインフラもやる/やれる • PaaSやツールを使って「保守を楽」にすればいい • 体験でしか学べない • 既存とのギャップが⼤きすぎてイメージがつかない • 当初の⾃分たちがそうだったように • もっと多くの⼈に体験してもらって、会社全体として成⻑していきたい