Slide 1

Slide 1 text

決済システム内製化のその先に ~ クラウドネイティブな開発を ”スケール” させるために必要だったこと CloudNative Days 2023 #CNDT2023 Dec. 11 2023 Junya Suzuki (@suzukij), SB Payment Service 1

Slide 2

Slide 2 text

自己紹介 鈴木順也(@suzukij) 主な業務 ・新規サービスの開発 ・運用の効率化/改善 Java, Webシステムの開発に従事 元々は SIer のプログラマ フリーランスを経て現在の会社に転職 2

Slide 3

Slide 3 text

CloudNative Days Tokyo 2019登壇 3

Slide 4

Slide 4 text

アジェンダ ● 5年前に開始した内製開発 ○ プラットフォーム構築 ○ CloudNativeな決済システム開発 ○ 導入後の変化 ● 大規模プロジェクトの新たな挑戦 ○ プロジェクト概要と体制 ○ イネイブリングチームとしての取り組み ○ プラットフォームエンジニアリング ● まとめ 4

Slide 5

Slide 5 text

● 5年前に開始した内製開発 ○ プラットフォーム構築 ○ CloudNativeな決済システム開発 ○ 導入後の効果と広がり 5

Slide 6

Slide 6 text

2018年: 決済システムの内製へ 導入したもの Concourse Tanzu Application Service Tanzu Application Service(TAS)を中心とした クラウドネイティブなプラットフォーム 6

Slide 7

Slide 7 text

Tanzu Application Service(TAS) を選んだ理由 Tanzu Application Service 7

Slide 8

Slide 8 text


 
 
 やっぱりKubernetes?? エンジニアとして興味はあるけど… ・学習コスト、メンテナンスコストの高さ ・プラットフォーム構築と検証に必要な期間 ・数人のチームでは体制的にも厳しそう OR PaaS 8

Slide 9

Slide 9 text


 
 
 やっぱりKubernetes?? ウチはこっち 既に確立されたプラットフォームが欲しい ・業務コードの実装に集中したい ・コードをすぐに実行できる環境が欲しい OR PaaS 9

Slide 10

Slide 10 text

最終的に選んだのは… PaaS ● Java/Spring アプリケーションとの親和性 ● プラットフォームの導入/運用のサポート ● cf push コマンドによるアプリリリース Tanzu Application Service 10 (TAS)

Slide 11

Slide 11 text

開発プロジェクトのチーム体制と責任分界 11

Slide 12

Slide 12 text

開発プロジェクトのチーム体制と責任分界 Networking Storage Servers Virtualization O/S Middleware プラットフォーム運用者 Ops 2名 Runtime Tanzu Application Service 12

Slide 13

Slide 13 text

開発プロジェクトのチーム体制と責任分界 Data Application アプリケーション開発者 Dev 4名 プラットフォーム運用者 Ops 2名 Tanzu Application Service 13 Networking Storage Servers Virtualization O/S Middleware Runtime Spring Boot Spring Cloud

Slide 14

Slide 14 text

Spring Boot Spring Cloud 開発プロジェクトのチーム体制と責任分界 Data Application アプリケーション開発者 Dev 4名 プラットフォーム運用者 Ops 2名 Tanzu Application Service 14 Networking Storage Servers Virtualization O/S Middleware Runtime プラットフォームの 構築 / 管理 に専念

Slide 15

Slide 15 text

開発プロジェクトのチーム体制と責任分界 Networking Storage Servers Virtualization O/S Middleware Runtime Data Application 業務の設計 / 実装に集中 プラットフォーム運用者 Ops アプリケーション開発者 Dev 4名 Tanzu Application Service 15 Spring Boot Spring Cloud

Slide 16

Slide 16 text

開発プロジェクトのチーム体制と責任分界 プラットフォーム運用者 Ops 2名 アプリケーション開発者 Dev 4名 Tanzu Application Service Tanzu Application Service Spring Boot Spring Cloud 16 Data Application Networking Storage Servers Virtualization O/S Middleware Runtime

Slide 17

Slide 17 text

● 5年前に開始した内製開発 ○ プラットフォーム構築 ○ CloudNativeな決済システム開発 ○ 導入後の効果と広がり 17

Slide 18

Slide 18 text

全体のアーキテクチャ トレース監視 ログ分析/可視化 メトリクス監視 Logstash
 Elasticsearch
 Kibana
 デプロイ
 Concourse
 CI/CD
 Prometheus
 Tanzu
 Application Service 
 開発 運用/監視 システム稼働 DB・ミドルウェア
 パッケージ管理
 Zipkin
 ソースコード管理
 18

Slide 19

Slide 19 text

Container Apps / Microservices API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Tanzu Application Service 19

Slide 20

Slide 20 text

Async / Message Queue API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Tanzu Application Service 20

Slide 21

Slide 21 text

CI/CD 21 Concourse

Slide 22

Slide 22 text

Resilience - CircuitBreaker API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Tanzu Application Service CircuitBreaker CircuitBreaker よく聞かれるのですが接続先によっては 月に一度はCircuitOpenしたりします。 導入してよかった。 22

Slide 23

Slide 23 text

Observability ※Metrics, tracing, and logging  https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html Elastic Stack Elastic APM OTEL Collector 23

Slide 24

Slide 24 text

● 5年前に開始した内製開発 ○ プラットフォーム構築 ○ CloudNativeな決済システム開発 ○ 導入後の効果と広がり 24

Slide 25

Slide 25 text

プラットフォーム導入の効果 Before After Release リリース作業 手作業 ワンクリック リリース品質 人為的なミスの可能性あり 自動化によりミスなし リリース時間 45分 5分 Observability ログ調査 ログファイルから調査 Kibanaダッシュボード サーバメトリクス調査 ログファイルから調査 Grafanaダッシュボード トレース調査 なし Zipkinダッシュボード Resilience CircuitBreaker なし 外部障害の伝播を防止 スケールアウト 手作業 管理画面から数クリック 25

Slide 26

Slide 26 text

サービスの広がり サービス開始時 稼働から4年経った現在 システム数 1システム 4システム ⤴ App数 8アプリケーション 41アプリケーション ⤴ Appインスタンス数 20インスタンス 96インスタンス ⤴ プラットフォーム運用者数 2名 3名 ➝ アプリケーション開発者数 4名 最大 15名 ⤴ このシステムの障害件数 - 0件 26

Slide 27

Slide 27 text

● 大規模PJの新たな挑戦 ○ プロジェクト概要と体制 ○ イネイブリングチームとしての取り組み ○ プラットフォームエンジニアリング 27

Slide 28

Slide 28 text

新プロジェクトの概要 / 規模感 現在のPJ 5年前のPJ(参考) 領域 クレジットカード 発行管理システム 決済代行システム 目的 レガシーモダナイゼーション 新サービス開発 開発対象アプリ数 30アプリケーション 7アプリケーション 工数 1000人月超 60人月 体制 70人以上 4人 期間 3年間 1年間 ※アプリケーション開発領域のみ 28

Slide 29

Slide 29 text

新プロジェクトの概要 / 規模感 現在のPJ 5年前のPJ(参考) 領域 クレジットカード 発行管理システム 決済代行システム 目的 レガシーモダナイゼーション 新サービス開発 開発対象アプリ数 30アプリケーション 7アプリケーション 工数 1000人月超 60人月 体制 70人以上 4人 期間 3年間 1年間 ※アプリケーション開発領域のみ スケールさせる必要があった 29

Slide 30

Slide 30 text

スケジュール 2021 2022 2023 2024 PJ準備 12ヶ月 ● P J計画/予算策定 ● 開発ベンダ調整 ● プロトタイプ開発 ● 開発ガイドライン整備 PJ開始 - 開発 18ヶ月 ● プラットフォーム構築 ● 設計/開発/テスト 結合テスト システムテスト 9ヶ月 新システム 稼働予定 イマココ ● シナリオテスト/ユーザテスト ● 現新比較テスト ● データ移行 ● システム切替計画 30 今日の話

Slide 31

Slide 31 text

新たな挑戦 ①クラウドからオンプレミスへ ②内製から外注へ 31

Slide 32

Slide 32 text

新たな挑戦 ①クラウドからオンプレミスへ ● サービスレベルのさらなる向上を図りたい ● ランニングコストを削減したい  
 オンプレ環境 ● CloudNativeなアプリ開発/運用 で培った手法をオンプレ環境に持ち込みたい 32

Slide 33

Slide 33 text

新たな挑戦 ②内製から外注 ● 大規模プロジェクトとなるため 外部開発パートナーの支援が必須 外注 ● コア技術は社員が握る ● 内製開発で建て付けた開発サイクルを踏襲し 高い品質と生産性をキープしたい 33

Slide 34

Slide 34 text

34 レガシーモダナイゼーションパターン (再構築手法) レイヤー ハードウェア 更改 リホスト リライト リライト リビルド 業務要件 変更なし 変更なし 変更なし 変更なし 変更あり アーキテクチャ 変更なし 変更なし 変更なし 変更あり 変更あり 言語 変更なし 変更なし 変更あり 変更あり 変更あり OS/ミドルウェア 変更なし 変更あり 変更あり 変更あり 変更あり ハードウェア 変更あり 変更あり 変更あり 変更あり 変更あり 今回の 再構築パターン リスク/影響 低 高

Slide 35

Slide 35 text

仕様再定義 参考:大規模レガシーシステムのモダナイゼーション手法 https://www.ipsj.or.jp/dp/contents/publication/42/S1102-S04.html N字モデル 明確化できないシステム機能仕様を、リバースエンジニアリングで現行プログラム ソースから抽出し、V字モデルにつなげる。 従来のV字モデルの前段階に、現行ソースを解析する工程を追加 35

Slide 36

Slide 36 text

全体のアーキテクチャ 36 分散トレーシング ログ分析/可視化 メトリクス監視 Logstash
 Elasticsearch
 Kibana
 デプロイ
 Concourse
 CI/CD
 Prometheus
 Tanzu Application Service 開発 運用/監視 システム稼働 DB・ミドルウェア ソースコード管理
 パッケージ管理
 Kibana


Slide 37

Slide 37 text

全体のアーキテクチャ 分散トレーシング ログ分析/可視化 メトリクス監視 Logstash
 Elasticsearch
 Kibana
 デプロイ
 Concourse
 CI/CD
 Prometheus
 Tanzu Application Service 開発 運用/監視 システム稼働 DB・ミドルウェア ソースコード管理
 パッケージ管理
 Kibana
 37

Slide 38

Slide 38 text


 
 
 開発パートナー企業との契約 こちらを選択 決まった成果物だけが欲しかったのではなく、 内製開発のように動作するアプリを開発しながら 検討を繰り返し手段や品質の改善を重ねたい。 請負契約 OR 準委任契約 (SES契約) 38

Slide 39

Slide 39 text

システム構成と体制 プラットフォーム(TAS) インフラ - オンプレミス(HCI) インフラチーム プラットフォームチーム 39

Slide 40

Slide 40 text

システム構成と体制
 40 プラットフォーム(TAS) インフラ - オンプレミス(HCI) インフラチーム プラットフォームチーム 開発チーム A社 45名 開発チーム B社 15名 開発チーム C社 6名 40 基幹システム オペレータ向け システム 会員向け システム

Slide 41

Slide 41 text

システム構成と体制 基幹システム オペレータ向け システム 会員向け システム プラットフォーム(TAS) インフラ - オンプレミス(HCI) インフラチーム プラットフォームチーム 開発チーム A社 45名 開発チーム B社 15名 開発チーム C社 6名 アプリ基盤チーム 支援 41

Slide 42

Slide 42 text

Team Topologies - チームタイプ
 42 基幹システム オペレータ向け システム 会員向け システム 開発チーム A社 開発チーム B社 開発チーム C社 アプリ基盤チーム イネイブリングチーム ストリームアラインドチーム ファシリテーション 支援 課題解決

Slide 43

Slide 43 text

Team Topologies - チームタイプ
 基幹システム オペレータ向け システム 会員向け システム プラットフォーム 開発チーム A社 開発チーム B社 開発チーム C社 アプリ基盤チーム イネイブリングチーム ストリームアラインドチーム ファシリテーション 支援 課題解決 X as a Service プラットフォームをサービスとして提供 プラットフォームチーム 43

Slide 44

Slide 44 text

● 大規模PJの新たな挑戦 ○ プロジェクト概要と体制 ○ イネイブリングチームとしての取り組み ○ プラットフォームエンジニアリング 44

Slide 45

Slide 45 text

イネイブリングチームの役割 ● 適切なツール、プラクティス、アプリケーションスタックに関する調査、正しい情報に基づく提案 ● ソリューションの提供だけではなくガイダンスを提供する ● 開発チームの自律性を高めることを目的とする イネイブリング チーム (アプリ基盤チーム) 開発チーム 基幹システム 開発チーム オペレータ向け システム 開発チーム 会員向け システム 技術支援/フィードバック 開発チームに対して支援 45

Slide 46

Slide 46 text

プロトタイプ開発 当初 開発チーム(パートナー会社)がCloudNativeな環境での開発経験がなく、 開発コンセプトやプラットフォーム、設計書/コード等の成果物のイメージが持て ずこれまでのやり方を踏襲しようとしたためイネイブリングチームとの間で摩擦 が起きてしまった。 課題 46

Slide 47

Slide 47 text

イネイブリングチーム主導で各開発チームが1機能をプロトタイプ開発。 設計書作成、実装、ビルド、ユニットテスト、デプロイ全ての工程を対象とした。 対応 47 プロトタイプ開発 当初 開発チーム(パートナー会社)がCloudNativeな環境での開発経験がなく、 開発コンセプトやプラットフォーム、設計書/コード等の成果物のイメージが持て ずこれまでのやり方を踏襲しようとしたためイネイブリングチームとの間で摩擦 が起きてしまった。 課題

Slide 48

Slide 48 text

プロトタイプ開発 当初パートナー会社(開発チーム)がCloudNativeな環境での開発経験がなく、開発コン セプトやプラットフォーム、設計書/コード等の成果物のイメージが持てずこれまでのやり 方を踏襲しようとして摩擦が起きた。 イネイブリングチームと開発チームの双方で開発方式や成果物に対するギャップを感じ ていた。 課題 イネイブリングチーム主導で各領域において1機能をプロトタイプ開発した。 設計書作成、実装、ビルド、ユニットテスト、デプロイ全ての工程を対象とした。 対応 効果 開発チームが実際に手を動かして開発し、イネイブリング チームと意見交換することで開発コンセプトや手法、成果 物に対する認識を合わせることができた 48

Slide 49

Slide 49 text

開発ガイドラインの整備 プロトタイプ開発でギャップは埋まったが、PJ中盤で増えてくる数十名の開発 者に同様のことを伝える労力がかかってしまう。 アプリ開発が本格化した後に開発チームが混乱しないようにナレッジの共有を する必要があった。 懸念 49

Slide 50

Slide 50 text

イネイブリングチームがプロトタイプ開発で得られた知見を 開発ガイドラインに記載した。 テキストだけではなくデモや説明はアーカイブ動画を残した。 対応 50 開発ガイドラインの整備 プロトタイプ開発でギャップは埋まったが、PJ中盤で増えてくる数十名の開発 者に同様のことを伝える労力がかかってしまう。 アプリ開発が本格化した後に開発チームが混乱しないようにナレッジの共有を する必要があった。 懸念

Slide 51

Slide 51 text

開発ガイドラインの整備 プロトタイプ開発でギャップは埋まったが、PJ中盤で増えてくる数十名の開発者に同様の ことを伝える労力がかかってしまう 課題や質問に対して回答ができなくなってしまう不安があった 懸念 イネイブリングチームがプロトタイプ開発で得られた知見を 開発ガイドラインに記載した。 テキストだけではなくデモや説明はアーカイブ動画を残した。 対応 効果 開発メンバーに事前にガイドラインに目を通してもらう ことで開発手法や有用なプラクティスを浸透させた 51

Slide 52

Slide 52 text

大規模プロジェクトのウォーターフォール開発の問題点 フェーズが長い、フェーズ毎に担当者が入れ替わる、成果物が出てくるのが数カ月後 前工程の成果物に間違いがないことが前提 後続フェーズで気付いた設計や実装の不備はすべて手戻りとして扱われてしまう 内製開発時と同様の開発サイクル 全アプリ全機能の設計 全アプリ全機能の実装 全アプリ全機能のテスト よくあるウォーターフォール開発の流れ 設計チーム 実装チーム テストチーム リリース サービス稼働 52

Slide 53

Slide 53 text

今回採用した開発サイクル Aアプリ チーム テスト 実装 設計 機能a テスト 実装 設計 機能b テスト 実装 設計 機能c 従来のように長期間となる設計フェーズ/実装フェーズ/単体テストフェーズを設けない。 業務毎にチームを分割し、メンバーが担当するそれぞれの機能を設計/実装/テストの短いサ イクルを繰り返しながらアプリケーションを完成させる 内製開発時と同様の開発サイクル … 53

Slide 54

Slide 54 text

段階的な並列化でPJを推進 Aアプリ チーム テスト 実装 設計 機能a テスト 実装 設計 テスト 実装 設計 内製開発時と同様の開発サイクル … 機能b 機能c Bアプリ チーム テスト 実装 設計 機能c テスト 実装 設計 テスト 実装 設計 機能d 機能e Cアプリチー ム Cアプリ チーム Dアプリ チーム Eアプリ チーム … … … … システム テスト リリース サービス稼働 ・ ・ 54

Slide 55

Slide 55 text

効果 ● 各チームが業務に関する深い知識を得ることができシステム移行やシステム テストにつなげることができた ● フェーズを設けないことで設計ミスを早期に発見し、手戻りが小さくなった ● 開発中に気付いた設計改善を積極的に取り入れやすくなった この開発サイクルによって ● すべての開発メンバーが設計から実装、テスト計画まで全ての工程を担当 ● フェーズ間を埋めるために作成していた不完全で余分な設計書を廃止 (開発サイクルを回しながら着実に最適化) 内製開発時と同様の開発サイクル 55 テスト 実装 設計

Slide 56

Slide 56 text

56 発生した課題 ● チーム毎の成果物の品質に差が出やすい ● イネイブリングチームによる開発支援や開発ガイドラインで全体の品質を底上げ ● プラットフォームのおかげで認知負荷を低減、品質と生産性をカバー ○ CI/CDによるテストとデプロイの自動化 ○ ログ監視、メトリクス監視が自動的に適用される 内製開発時と同様の開発サイクル

Slide 57

Slide 57 text

発生した課題 ● チーム毎の成果物の品質に差が出やすい ● 各チームにテックリードエンジニアを配置 ● 長期PJのためメンバーが成長し後半に活躍 ● イネイブリングチームによる開発支援や開発ガイドラインで全体の品質を底上げ ● プラットフォームのおかげで認知負荷を低減、品質と生産性をカバー ○ CI/CDによるテストとデプロイの自動化 ○ ログ監視、メトリクス監視が自動的に適用される 内製開発時と同様の開発サイクル ● レベルの高いエンジニアが求められてしまう 57 開発 チーム 開発 チーム 開発 チーム

Slide 58

Slide 58 text

58 イネイブリングチームによるアプリ開発 イネイブリングチームが業務アプリ開発に直接関わっていなかったため、開発 チームにとって本当に有益な情報が何か見落としてしまう懸念があった。 開発の一連の流れを通して体験していないと当事者意識が薄れ開発チームへの情 報提供が不十分となってしまう。 懸念

Slide 59

Slide 59 text

イネイブリングチームによるアプリ開発 開発難易度が高く利用技術が多岐にわたるアプリをイネイブリングチームが開発か らリリースまで担当した。 対応 59 イネイブリングチームが業務アプリ開発に直接関わっていなかったため、開発 チームにとって本当に有益な情報が何か見落としてしまう懸念があった。 開発の一連の流れを通して体験していないと当事者意識が薄れ開発チームへの情 報提供が不十分となってしまう。 懸念

Slide 60

Slide 60 text

イネイブリングチームによるアプリ開発 イネイブリングチームが業務アプリケーション開発をしていなかったため開発チームに とって本当に有益な情報が何か見落としてしまうことが予想された。 プラットフォームの利用感覚は実際に開発の一連の流れを通して体験しないと理解でき ず開発チームへの情報提供が不充分となってしまう。 課題 開発難易度が高いアプリや利用技術が多岐にわたるアプリをイネイブリングチームが担 当として開発からリリースまで担当した。 対応 効果 イネイブリングチームがアプリ開発の当事者となることでガイドライン や各種テンプレート、支援内容の質が高まった。 イネイブリングチームがプラットフォームの最初の利用者となること で、プラットフォームチームに改善点をフィードバック。 60

Slide 61

Slide 61 text

横断的 / 継続的な開発支援 開発プロセスの標準化、ルール化に加えてガイダンスを提供 各チームが課題に直面して生産性が下がらないように Concourse Karate Elastic Stack 実行環境 テスト 負荷テスト ビルド Observability CI/CD 成果物管理 静的コード解析 61 イネイブリング チーム 開発 チーム 開発 チーム 開発 チーム

Slide 62

Slide 62 text

各種ツールや設定を提供し継続的に支援 CIビルドパイプライン設定テンプレートを提供 62 静的コード解析ツールのルールを作成/提供 アプリ一覧ダッシュボードを開発し提供 ライブラリのアップデートに追従できてる? ログを効率良く確認するためのダッシュボードを提供 怪しいログ出てないよね? その後Greenを維持できてる? 悪化してないよね?

Slide 63

Slide 63 text

● 大規模PJの新たな挑戦 ○ プロジェクト概要と体制 ○ イネイブリングチームとしての取り組み ○ プラットフォームエンジニアリング 63

Slide 64

Slide 64 text

64 プラットフォーム プラットフォームチームが開発チームへプラットフォームを提供 提供されたプラットフォームを利用することで開発チームの開発体験と生産性が向上 プラットフォーム チーム 開発チームへ 提供

Slide 65

Slide 65 text

開発チームの問題点 開発や運用をする上で必要なアレやコレや… 65

Slide 66

Slide 66 text

開発チームの問題点 開発や運用をする上で必要なアレやコレや… 66

Slide 67

Slide 67 text

開発チームの問題点 開発や運用をする上で必要なアレやコレや… 67

Slide 68

Slide 68 text

開発チームの問題点 開発チームの認知負荷が高すぎる 68

Slide 69

Slide 69 text

プラットフォーム プラットフォームチームが開発チームへプラットフォームを提供 提供されたプラットフォームを利用することで開発チームの開発体験と生産性が向上 69 プラットフォーム チーム 開発チームへ 提供

Slide 70

Slide 70 text

プラットフォームエンジニアリング ● 開発チームの認知負荷を低減 ● 開発体験と生産性を向上 ○ 開発中のアプリが継続的にテスト/デプロイされること ○ デプロイされたアプリは管理コンソールでスケールでき自動リカバリが備わっていること ○ デプロイされたアプリケーションのログやメトリクスが自動的に収集/可視化されること ● 開発中であっても “動くソフトウェア” が常に存在すること 70 プラットフォーム チーム 自動テスト 自動デプロイ 自動ログ収集、 可視化 スケーラブル 自動リカバリ

Slide 71

Slide 71 text

プラットフォームの存在 ● 開発チームの認知負荷を低減 ● 開発体験と生産性を向上 ○ 開発中のアプリが継続的にテスト/デプロイされること ○ デプロイされたアプリは管理コンソールでスケールでき自動リカバリが備わっていること ○ デプロイされたアプリケーションのログやメトリクスが自動的に収集/可視化されること ● 開発中であっても “動くソフトウェア” が常に存在すること プラットフォーム チーム 自動ログ収集、可 視化 開発メンバーの意識や気持ちに ポジティブな影響を与えた ● 認知負荷の低減 ● 自動テスト/デプロイのある安心感 ● 改善に対して前向きなマインド ● 自発的な品質向上の提案 71

Slide 72

Slide 72 text

本日のまとめ 決済システム内製化のその先に ~ クラウドネイティブな開発を ”スケール” させるために必要だったこと 72

Slide 73

Slide 73 text

73 5年前の内製開発でCloudNativeな 開発/運用ノウハウを蓄積 開発を “スケール” させるために イネイブリング チーム 開発チーム 有識者でイネイブリングチームを作り、 最初に1機能をプロトタイプ開発 そこで得られた知見をガイドライン化、 テンプレート化 その後イネイブリングチームは横断的な支 援活動を行い、CloudNativeな開発を実現 開発支援

Slide 74

Slide 74 text

74 5年前の内製開発でCloudNativeな 開発/運用ノウハウを蓄積 開発を “スケール” させるために イネイブリング チーム プラットフォーム チーム 開発チーム 有識者でイネイブリングチームを作り、 最初に1機能をプロトタイプ開発 そこで得られた知見をガイドライン化、 テンプレート化 その後イネイブリングチームは横断的な支 援活動を行い、CloudNativeな開発を実現 開発支援 開発チームの認知負荷を低減 開発体験と生産性を向上 プラットフォームの提供

Slide 75

Slide 75 text

5年前の内製開発でCloudNativeな 開発/運用ノウハウを蓄積 開発を “スケール” させるために 70人以上の開発体制にスケール 開発成功 75 イネイブリング チーム プラットフォーム チーム 開発チーム 有識者でイネイブリングチームを作り、 最初に1機能をプロトタイプ開発 そこで得られた知見をガイドライン化、 テンプレート化 その後イネイブリングチームは横断的な支 援活動を行い、CloudNativeな開発を実現 開発支援 開発チームの認知負荷を低減 開発体験と生産性を向上 プラットフォームの提供

Slide 76

Slide 76 text

クラウド / オンプレミス 内製 / 外注 クラウド環境、内製開発で培った CloudNativeな開発体験をオンプレ環境に持 ち込み生産性を向上させた。 また外部パートナー企業と共に協力すること で開発を ”スケール” できた。 このPJを通じて 76

Slide 77

Slide 77 text

このPJを通じて クラウド / オンプレミス 内製 / 外注 これらの手段は回帰や対立関係ではなく ビジネスや業務要件に応じて 最適なものが選択できることが大事 77

Slide 78

Slide 78 text

78