決済システム内製化のその先に～クラウドネイティブな開発を"スケール"させるために必要だったこと / Beyond in-house production of payment systems

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

アジェンダ ● ５年前に開始した内製開発 ○ プラットフォーム構築 ○ 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な開発/運用ノウハウを蓄積開発を “スケール” させるためにイネイブリングチーム開発チーム有識者でイネイブリングチームを作り、最初に１機能をプロトタイプ開発そこで得られた知見をガイドライン化、テンプレート化その後イネイブリングチームは横断的な支援活動を行い、CloudNativeな開発を実現開発支援

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

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

Slide 76

Slide 76 text

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

Slide 77

Slide 77 text

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