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

2021年1月25日に開催された「E-JAWS カンファレンス 2021 TOKYO」での講演「三越伊勢丹におけるDX向けプラットフォーム構築への挑戦」の資料です。
https://aws.amazon.com/jp/about-aws/events/2021/ejawsconf2021125/

概要：
三越伊勢丹では「DX 推進に向けたアジリティの確保」と「2025 年の崖問題を見据えた基幹系のモダナイズ」が並行するなか、両者を一緒に解決することを目指してDX向けプラットフォームの構築をはじめました。講演では「DX サービスに合わせて少しづつ整備する」「基幹系の機能をすり替えていく」「運用作業を極限まで削減する」といったコンセプトを紹介しながら、実際、どのように取り組んでいるのかについて説明します。この中では、システムのサイロ化、ベンダー依存、既存ルールとのギャップなど、さまざまな出来事に挑戦をしていっています。

Transcript

1. Copyright© IM Digital Lab, Inc. All rights reserved. 三越伊勢丹における DX向けプラットフォーム構築への挑戦 （株）三越伊勢丹システムソリューションズ ⽵前千草 （株）アイムデジタルラボ 鈴⽊雄介
2. Copyright© IM Digital Lab, Inc. All rights reserved. IMSとは (株)三越伊勢丹システムソ リューションズ • 三越伊勢丹グループにおける情報 システム⼦会社 • 1968年設⽴ • http://www.ims-sol.co.jp/ • 三越伊勢丹グループの基幹システ ム、デジタルサービスの開発、保 守、運⽤を実施
3. Copyright© IM Digital Lab, Inc. All rights reserved. 講演者 ⽵前千草 • （株）三越伊勢丹システムソリューションズ • テクノロジー推進部 ビジネスプラットフォーム第⼀グループ グループ⻑
4. Copyright© IM Digital Lab, Inc. All rights reserved. IMDLとは （株）アイムデジタルラボ • 三越伊勢丹グループにおけるDX推進 機能⼦会社 • 2019年11⽉設⽴ • https://www.imd-lab.co.jp/ • https://note.com/imd_lab ミッション 仕組みを変えて お買い物を楽しくする
5. Copyright© IM Digital Lab, Inc. All rights reserved. 講演者 鈴⽊雄介 • (株)アイムデジタルラボ • 取締役 • Graat（グラーツ） • グロース・アーキテクチャ＆チームス(株) • 代表取締役社⻑ • ⽇本Javaユーザーグループ • サブリーダー/CCC運営委員⻑ • その他 • @yusuke_arclamp • http://arclamp.hatenablog.com/
6. Copyright© IM Digital Lab, Inc. All rights reserved. アジェンダ 状況 何を作るのか？ どう作るのか？（技術編） どう作るのか？（組織編） まとめ
7. Copyright© IM Digital Lab, Inc. All rights reserved. 状況
8. Copyright© IM Digital Lab, Inc. All rights reserved. 状況 DXの推進 • コロナ禍により取り組みが加速 • 三越伊勢丹リモートショッピング • 2020/4 アイデア • 2020/5 ワークショップ（コンセプト） • 2020/6 開発チーム編成 • モバイルアプリ、サーバなど20名規模 • 2020/7 開発スタート • 2020/10 内部リリース • 2020/11 プレスリリース • 毎週リリース継続中
9. Copyright© IM Digital Lab, Inc. All rights reserved. 状況 2025年の崖 • 三越伊勢丹も例外ではない • 2022年度中を⽬指してモダナイズを推進中 • 主に⾃動化による運⾏費削減、開発アジリティの向上 • その中で「DX向けプラットフォーム」の整備を推進 • 名称：ビジネスプラットフォーム（略称：BPF） • 三越伊勢丹リモートショッピングも利⽤ 既存システムが、事業部⾨ごとに構築されて、全社横断的なデータ活 ⽤ができなかったり、過剰なカスタマイズがなされているなどにより、 複雑化・ブラックボックス化 経済産業省 DXレポート 〜ITシステム「2025年の崖」の克服とDXの本格的な展開〜
10. Copyright© IM Digital Lab, Inc. All rights reserved. 今⽇の話 ビジネスプラットフォームの話 • ビジネスプラットフォームとは何か？ • 略称：BPF（Business PlatForm） • それをどのように作ったのか？ • 技術的な話 • 組織的な話
11. Copyright© IM Digital Lab, Inc. All rights reserved. 何を作るのか？
12. Copyright© IM Digital Lab, Inc. All rights reserved. 何を作るのか？ DX＝お客様視点でサービスを構築する • ユーザー体験はシステムを横断する • フロントサービスは横断的に基幹システムを利⽤したい • 個別に調整するのは⼿間なので⼀元的に提供したい 商品 情報 価格 情報 展開 情報 会員 情報 決済/ 配送 ⼀元的に提供する基盤 お客様 情報 ⾜の情報 ⾜に合う 靴の⼀覧 ⾜に合う 靴の詳細 購⼊ 会員 商品 在庫/販売 価格 決済
13. Copyright© IM Digital Lab, Inc. All rights reserved. 何を作るのか？ ビジネスプラットフォーム • 基幹のデータや機能をフロントから使いやすく • 単なるAPIゲートウェイでは機能が⾜らない • データのキャッシュ、加⼯も⾏う • 基幹のデータ更新をイベント配信 商品 情報 価格 情報 展開 情報 会員 情報 決済/ 配送 会員情報 参照 ⾜形情報 参照 商品情報 取得 展開情報 取得 購⼊連携 会員 商品 在庫/販売 価格 決済 フロントサービス ビジネスプラットフォーム
14. Copyright© IM Digital Lab, Inc. All rights reserved. API 何を作るのか？ さまざまな連携をパターン化して整理 • 処理をゾーニングすることで再利⽤性を⾼める • ストレージゾーン：基幹からのI/Fを受け取る場所 • デリバリーゾーン：フロントへ配信する場所 RDB ストレージ ゾーン デリバリー ゾーン ロジック ゾーン 基幹 システム ﾌｧｲﾙ RDB 基幹 システム 収集 Topic RDB 配信 Topic ⾮同期ストリーミング キャッシュとAPI配信 リアルイベント配信 フロント サービス フロント サービス 基幹 システム フロント サービス APIルーティング 変換 API 変換 API ｹﾞｰﾄｳｪｲ ビジネスプラットフォーム
15. Copyright© IM Digital Lab, Inc. All rights reserved. どう作るのか？（技術編）
16. Copyright© IM Digital Lab, Inc. All rights reserved. どう作るのか？（技術編） DevOpsの実現 • 開発チームがインフラ構築/サービス運⽤も実施す ればスピードアップと効率化が実現できる • でも、それが開発チームの負担にならないようにする これまで これから インフラ 構築 アプリ 開発 運⽤監視 インフラ チーム 開発 チーム 運⽤監視 チーム 既存 環境 利⽤ 整備 監視 開発 チーム 運⽤監視 チーム DevOps 環境 利⽤ 利⽤ 通知 インフラ DevOps ⽀援チーム コア 監視 全体 整備 ⽀援
17. Copyright© IM Digital Lab, Inc. All rights reserved. どう作るのか？（技術編） DevOps＝あれこれが⾃動になる • 障害からの⾃動復旧 • クラウドサービスのPaaSの採⽤ • 平⽇⽇中でリリース作業を⾏う • CI/CDツールによるビルド/デプロイパイプライン整備 • インフラ構築作業の⾃動化 • IaC(Infrastructure as code)ツールによるインフラ整備
18. Copyright© IM Digital Lab, Inc. All rights reserved. どう作るのか？（技術編） 新たに環境を構築し、ガイドラインを策定 • 各種ガイドラインを策定 • AWS利⽤ガイドライン • CI/CDガイドライン • 運⽤ガイドライン • 既存のAWS環境とは切り離して策定 • 既存：リフト先としてIaaS前提で設計 • 新規：シフト先としてPaaS前提で設計
19. Copyright© IM Digital Lab, Inc. All rights reserved. どう作るのか？（技術編） AWSガイドライン • AWSのベストプラクティスを中⼼に設計 • EC2禁⽌（サーバレス/マネージドのみ） • アプリ:Fargate、Lambda • データベース:Aurora/DynamoDB • セキュリティ関連の構成は新規に定義 • 既存環境のガバナンスを参考に再定義を⾏い、再審査 • BPF⾃⾝だけではなく、フロントサービスも同様のガイ ドラインを利⽤
20. 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.処理
21. Copyright© IM Digital Lab, Inc. All rights reserved. どう作るのか？（技術編） プレスリリースを出しました • 今後、ノウハウの共有も進めていきたい • ⽇本全体でDX推進をやらなくちゃいけない • ご興味がある企業の⽅、ぜひ情報交換させてください • https://note.com/imd_lab/n/nb544bbdfc9c2 三越伊勢丹システム・ソリューションズ、IM Digital Lab 、 サーバーワークスの3社が、クラウドネイティブな開発⼿ 法である、モード2開発基盤のガイドラインを策定 2021年1⽉20⽇
22. Copyright© IM Digital Lab, Inc. All rights reserved. 基幹モダナイズ どう作るのか？（技術編）
23. Copyright© IM Digital Lab, Inc. All rights reserved. 基幹モダナイズ 基幹機能の段階的置き換えにむけて • 基幹システム機能をBPFに移管し、再配置 • Step1:基幹の仕組みをクラウドネイティブに構築 • 基幹データを利⽤し、同じ結果がでるように • Step2:基幹と新システムを並⾏稼働し検証 • 既存システムは基幹のデータを利⽤ • 新規フロントシステムはBPFのデータを利⽤ • Step3:既存システムも段階的に新システムに移⾏ • Step4:利⽤されなくなった基幹を廃棄 • いわゆるストラングラーパターン
24. Copyright© IM Digital Lab, Inc. All rights reserved. 基幹モダナイズ 基幹系機能をクラウドネイティブにシフト • 同じ処理を性能向上＋コスト削減 • POS情報API • オンラインAPIは数msのターンアラウンドを実現 • バッチでのファイル加⼯処理コストは⽉間数百円 • 在庫計算処理 • オンラインのピークも問題なく処理が可能 • 棚卸のような特殊なピークは平準化して処理 • 売上確定処理 • 基幹と同レベルの障害対応処理を実現
25. Copyright© IM Digital Lab, Inc. All rights reserved. 基幹モダナイズ POS情報API VPC 商品差分情報 売上属性情報 POS情報API フロント サービス SFn 価格情報 ⽣成 キャッシュ データ作成 商品情報 （含む価格） 売上属性情報 SFn 商品情報 （全件） 商品情報 ｴｸｽﾎﾟｰﾄ 商品情報 差分反映 データ コピー 属性情報 ⽣成 前⽇差分 情報⽣成 前⽇差分 情報⽣成 キャッシュ データ作成 SFn ⽇次 再起動
26. Copyright© IM Digital Lab, Inc. All rights reserved. 基幹モダナイズ 在庫計算処理 VPC 売上情報 （リアル） 伝票情報 （数分毎） 売上確定情報 （毎⽇夜間） 棚卸情報 （特定⽇） 売上情報 伝票情報 売上仕分け 伝票仕分け 在庫更新情報 （リアル） 在庫更新情報 （バルク） 更新 （リアル） 更新 （バルク） SFn 伝票取込 売上受信 在庫参照API フロント サービス 在庫DB ⽇中差分仕分け 差分⽣成 棚卸⽇ 在庫数 棚卸差分取込 SFn 棚卸⽇ 在庫数 退避
27. Copyright© IM Digital Lab, Inc. All rights reserved. 基幹モダナイズ 売上確定処理 POS 取引確定依頼 未確定 取引情報 サーバ 未確定 取引情報 取引情報 売上 サーバ 未確定 取引情報 取得 取引確定 確定受信 取引確定 VPC
28. Copyright© IM Digital Lab, Inc. All rights reserved. どう作るのか？（組織編）
29. Copyright© IM Digital Lab, Inc. All rights reserved. どう作るのか？（組織編） 2020年春、BPF構築スタート • BPF担当部署を設⽴し、構築を開始 • 内製メンバーを中⼼にしながら、各種の技術要素につい ては⽀援体制を準備 テクノロジー推進部 ビジネスプラットフォームグループ <全体⽀援> アイムデジタルラボ <DevOps⽀援> C社 <Java/Kafka⽀援> D社 <内製化⽀援> A社 <AWS⽀援> B社 <AWS⽀援> AWSJ
30. Copyright© IM Digital Lab, Inc. All rights reserved. どう作るのか？（組織編） ニーズに合わせて段階的に構築 • フロントサービスのニーズに合わせて構築 • 具体的な要求に対応することで無駄なものを作らない • ダメになったら作り直せばいいという割り切り • 現在、5機能の⼀部が稼働中。ビジョンの数％程度 • 逆に基幹I/Fは⼀度決めたら変えられない • なるべく基幹システム側に改修を発⽣させない • 基幹システムの現状や制約を最⼤限優先
31. Copyright© IM Digital Lab, Inc. All rights reserved. どう作るのか？（組織編） スクラムでマネジメント • 週次でスプリントを回しながらマネジメント • 週次で優先順位をリソースを調整 • 四半期で⼤きなリリース、⽉次で⼩さなリリース • 既存保守作業も含めて優先順位をつける • BPF担当部署は既存システムの保守も実施 • 緊急対応などの差込作業があることを前提に対応
32. Copyright© IM Digital Lab, Inc. All rights reserved. ⽴ち上げの苦労 どう作るのか？（組織編）
33. Copyright© IM Digital Lab, Inc. All rights reserved. ⽴ち上げの苦労 カルチャーショックと挫折からのスタート • 部署はできたものの何をするかイメージできず • アイムデジタルラボで全体設計はしていたが、どうやっ て作っていくのかわからない • 利⽤する技術が既存の概念と違いすぎて判断しきれない • サーバレスって何がうれしいの？ • Fargateのサービスとタスクってなに？ECRと連携？ • バッチサーバがないってメリットは？ • Athenaってなに？ • オブザーバビリティってなに？
34. Copyright© IM Digital Lab, Inc. All rights reserved. ⽴ち上げの苦労 まずは先⽣の真似をするところから • とりあえず動かしてみてから考えることにした • 概念だけ聞いていても理解しきれないので、想定要件を ベースに先⽣たちとプロトして考えることにした • AWSのPrototyping Programも利⽤ • プロト実施時に無償でSAが集中サポートしてくれる 設計:0.5⽇ ×2回 実装:連続3⽇間 ×2チーム
35. Copyright© IM Digital Lab, Inc. All rights reserved. ⽴ち上げの苦労 変化：質からスピードへ • 丁寧に設計するより、試⾏錯誤のほうが効率的 • 既存：丁寧に設計することで⼿戻りをなくす • BPF：早く試して、早く失敗して正解に近づける • 試⾏錯誤の⽅が学びが深い • 「なぜ失敗した？どうすればいい？」という思考が⼤事 • ただし、闇雲に試⾏錯誤してはダメ • 設計をパターン化して整理し、ポイントを明確にする
36. Copyright© IM Digital Lab, Inc. All rights reserved. ⽴ち上げの苦労 変化：なるべく楽をする • あるものを使って「なくす/やらなくする」 • サーバレス:サーバもミドルウェアも管理しなくていい • Fargate:⾃動リリースができれば⼿順書が不要 • バッチサーバレス:プロセスごと性能調整で遅延回避 • Athena:⼤量データの加⼯が早く、安く • オブザーバビリティ:障害を予測して未然に防ぐ • 世の中にある便利なものを使い倒すほうが効率的
37. Copyright© IM Digital Lab, Inc. All rights reserved. ⽴ち上げの苦労 専任化と⽬標設定でメンバーの成⻑をうながす • メンバーは専任にさせる • 既存保守兼任にすると⼿が動かず、学びが⼩さくなる • 少しずつだが確実に専任できるメンバーを増やす • 取り組むメンバーには具体的な⽬標を持たせる • 学ぶことが多いのでスキル獲得ステップを明⽰する • スキルマップは継続的に改善中
38. Copyright© IM Digital Lab, Inc. All rights reserved. ⽴ち上げの苦労 悔しさが覚悟につながった • 最初の3ヶ⽉は何もできなかったという挫折 • いまから考えれば最初の試⾏錯誤だから失敗だらけなの は当然だけど... • 悔しさをバネに覚悟を決められた • 「ともかく先⽣の真似をしよう」という割り切り • 「失敗してもいいからやりきろう」という覚悟 • まだまだ⾃信はないけどできることは増えてきた • もっと早く！もっと楽に！
39. Copyright© IM Digital Lab, Inc. All rights reserved. まとめ
40. Copyright© IM Digital Lab, Inc. All rights reserved. 何を作るのか？ ビジネスプラットフォーム • ユーザーはシステムを横断して利⽤する • フロントシステムから基幹のデータや機能を使い やすくするためのプラットフォーム • フロントが欲しい形に基幹のデータや機能を再編集 • さまざまな連携をパターン化して整理 • 基幹I/F⼿法、フロント提供⼿法をパターン化
41. Copyright© IM Digital Lab, Inc. All rights reserved. どう作るのか？（技術編） PaaSを活⽤しながらDevOpsを実現する • DevOpsの実現 • インフラに関わる開発チームの効率化 • ⾃動復旧、平⽇⽇中リリース、インフラ作業の⾃動化 • 新たにガイドラインと環境を整備 • AWSガイドライン • EC2禁⽌。すべてサーバレス/マネージドにする • 基幹モダナイズに向けた取り組みも実施 • 基幹の仕組みをすり替えていく
42. Copyright© IM Digital Lab, Inc. All rights reserved. どう作るのか？（組織編） 挫折をへて、メンバーが成⻑中 • 内製での構築を前提に組織と体制と準備 • フロントサービスのニーズに合わせた段階整備 • スクラムで週次マネジメント • ⽴ち上げの挫折があったから覚悟ができた • 最初はいままでの常識と違いすぎてついていけない • まずは先⽣の真似からやってみる • 「スピード」と「楽をする」ことを優先に • メンバーは専任させ、⽬標設定を通じて成⻑をうながす
43. Copyright© IM Digital Lab, Inc. All rights reserved. さいごに BPFの世界観をひろめていきたい • ⾃分たちでやれることが多くなる世界 • ⾃分たちで開発もインフラもやる/やれる • PaaSやツールを使って「保守を楽」にすればいい • 体験でしか学べない • 既存とのギャップが⼤きすぎてイメージがつかない • 当初の⾃分たちがそうだったように • もっと多くの⼈に体験してもらって、会社全体として成 ⻑していきたい