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

SBペイメントサービスは内製開発の立ち上げから既に5年以上が経過し、新たな開発プロジェクトが2年前に始まりました。
このプロジェクトは当社の中でも最大規模のシステムリプレイスのため開発パートナー企業にも協力いただき、またクラウド環境ではなくオンプレミスで構築されています。

このセッションでは開発体制をスケーリングする際に直面した課題や解決するためにしたことをお伝えします。
またクラウドネイティブな開発体験をどのようにオンプレミスで実現したのか、効率と品質を向上させるためのアーキテクチャや事例について紹介する予定です。

Transcript

1. 決済システム内製化のその先に ～ クラウドネイティブな開発を ”スケール” させるために必要だったこと CloudNative Days 2023 #CNDT2023 Dec. 11 2023 Junya Suzuki (@suzukij), SB Payment Service 1
2. 自己紹介 鈴木順也(@suzukij) 主な業務 ・新規サービスの開発 ・運用の効率化/改善 Java, Webシステムの開発に従事 元々は SIer のプログラマ フリーランスを経て現在の会社に転職 2
3. CloudNative Days Tokyo 2019登壇 3
4. アジェンダ • ５年前に開始した内製開発 ◦ プラットフォーム構築 ◦ CloudNativeな決済システム開発 ◦ 導入後の変化 • 大規模プロジェクトの新たな挑戦 ◦ プロジェクト概要と体制 ◦ イネイブリングチームとしての取り組み ◦ プラットフォームエンジニアリング • まとめ 4
5. • 5年前に開始した内製開発 ◦ プラットフォーム構築 ◦ CloudNativeな決済システム開発 ◦ 導入後の効果と広がり 5
6. 2018年: 決済システムの内製へ 導入したもの Concourse Tanzu Application Service Tanzu Application Service（TAS）を中心とした クラウドネイティブなプラットフォーム 6
7. Tanzu Application Service(TAS) を選んだ理由 Tanzu Application Service 7
8. 
 
 
 やっぱりKubernetes？？ エンジニアとして興味はあるけど… ・学習コスト、メンテナンスコストの高さ ・プラットフォーム構築と検証に必要な期間 ・数人のチームでは体制的にも厳しそう OR PaaS 8
9. 
 
 
 やっぱりKubernetes？？ ウチはこっち 既に確立されたプラットフォームが欲しい ・業務コードの実装に集中したい ・コードをすぐに実行できる環境が欲しい OR PaaS 9
10. 最終的に選んだのは… PaaS • Java/Spring アプリケーションとの親和性 • プラットフォームの導入/運用のサポート • cf push コマンドによるアプリリリース Tanzu Application Service 10 （TAS）
11. 開発プロジェクトのチーム体制と責任分界 11
12. 開発プロジェクトのチーム体制と責任分界 Networking Storage Servers Virtualization O/S Middleware プラットフォーム運用者 Ops 2名 Runtime Tanzu Application Service 12
13. 開発プロジェクトのチーム体制と責任分界 Data Application アプリケーション開発者 Dev 4名 プラットフォーム運用者 Ops 2名 Tanzu Application Service 13 Networking Storage Servers Virtualization O/S Middleware Runtime Spring Boot Spring Cloud
14. Spring Boot Spring Cloud 開発プロジェクトのチーム体制と責任分界 Data Application アプリケーション開発者 Dev 4名 プラットフォーム運用者 Ops 2名 Tanzu Application Service 14 Networking Storage Servers Virtualization O/S Middleware Runtime プラットフォームの 構築 / 管理 に専念
15. 開発プロジェクトのチーム体制と責任分界 Networking Storage Servers Virtualization O/S Middleware Runtime Data Application 業務の設計 / 実装に集中 プラットフォーム運用者 Ops アプリケーション開発者 Dev 4名 Tanzu Application Service 15 Spring Boot Spring Cloud
16. 開発プロジェクトのチーム体制と責任分界 プラットフォーム運用者 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
17. • 5年前に開始した内製開発 ◦ プラットフォーム構築 ◦ CloudNativeな決済システム開発 ◦ 導入後の効果と広がり 17
18. 全体のアーキテクチャ トレース監視 ログ分析/可視化 メトリクス監視 Logstash
 Elasticsearch
 Kibana
 デプロイ
 Concourse
 CI/CD
 Prometheus
 Tanzu
 Application Service 
 開発 運用/監視 システム稼働 DB・ミドルウェア
 パッケージ管理
 Zipkin
 ソースコード管理
 18
19. Container Apps / Microservices API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Tanzu Application Service 19
20. Async / Message Queue API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Tanzu Application Service 20
21. CI/CD 21 Concourse
22. Resilience - CircuitBreaker API Gateway Service A Service B Service C 加盟店 X 加盟店 Y 加盟店 Z 決済機関 A 決済機関 B 決済機関 C Tanzu Application Service CircuitBreaker CircuitBreaker よく聞かれるのですが接続先によっては 月に一度はCircuitOpenしたりします。 導入してよかった。 22
23. 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
24. • 5年前に開始した内製開発 ◦ プラットフォーム構築 ◦ CloudNativeな決済システム開発 ◦ 導入後の効果と広がり 24
25. プラットフォーム導入の効果 Before After Release リリース作業 手作業 ワンクリック リリース品質 人為的なミスの可能性あり 自動化によりミスなし リリース時間 45分 5分 Observability ログ調査 ログファイルから調査 Kibanaダッシュボード サーバメトリクス調査 ログファイルから調査 Grafanaダッシュボード トレース調査 なし Zipkinダッシュボード Resilience CircuitBreaker なし 外部障害の伝播を防止 スケールアウト 手作業 管理画面から数クリック 25
26. サービスの広がり サービス開始時 稼働から4年経った現在 システム数 1システム 4システム ⤴ App数 8アプリケーション 41アプリケーション ⤴ Appインスタンス数 20インスタンス 96インスタンス ⤴ プラットフォーム運用者数 2名 3名 ➝ アプリケーション開発者数 4名 最大 15名 ⤴ このシステムの障害件数 - 0件 26
27. • 大規模PJの新たな挑戦 ◦ プロジェクト概要と体制 ◦ イネイブリングチームとしての取り組み ◦ プラットフォームエンジニアリング 27
28. 新プロジェクトの概要 / 規模感 現在のPJ 5年前のPJ（参考） 領域 クレジットカード 発行管理システム 決済代行システム 目的 レガシーモダナイゼーション 新サービス開発 開発対象アプリ数 30アプリケーション 7アプリケーション 工数 1000人月超 60人月 体制 70人以上 4人 期間 3年間 1年間 ※アプリケーション開発領域のみ 28
29. 新プロジェクトの概要 / 規模感 現在のPJ 5年前のPJ（参考） 領域 クレジットカード 発行管理システム 決済代行システム 目的 レガシーモダナイゼーション 新サービス開発 開発対象アプリ数 30アプリケーション 7アプリケーション 工数 1000人月超 60人月 体制 70人以上 4人 期間 3年間 1年間 ※アプリケーション開発領域のみ スケールさせる必要があった 29
30. スケジュール 2021 2022 2023 2024 PJ準備 12ヶ月 • P J計画/予算策定 • 開発ベンダ調整 • プロトタイプ開発 • 開発ガイドライン整備 PJ開始 - 開発 18ヶ月 • プラットフォーム構築 • 設計/開発/テスト 結合テスト システムテスト 9ヶ月 新システム 稼働予定 イマココ • シナリオテスト/ユーザテスト • 現新比較テスト • データ移行 • システム切替計画 30 今日の話
31. 新たな挑戦 ①クラウドからオンプレミスへ ②内製から外注へ 31
32. 新たな挑戦 ①クラウドからオンプレミスへ • サービスレベルのさらなる向上を図りたい • ランニングコストを削減したい 　
 オンプレ環境 • CloudNativeなアプリ開発/運用 で培った手法をオンプレ環境に持ち込みたい 32
33. 新たな挑戦 ②内製から外注 • 大規模プロジェクトとなるため 外部開発パートナーの支援が必須 外注 • コア技術は社員が握る • 内製開発で建て付けた開発サイクルを踏襲し 高い品質と生産性をキープしたい 33
34. 34 レガシーモダナイゼーションパターン （再構築手法） レイヤー ハードウェア 更改 リホスト リライト リライト リビルド 業務要件 変更なし 変更なし 変更なし 変更なし 変更あり アーキテクチャ 変更なし 変更なし 変更なし 変更あり 変更あり 言語 変更なし 変更なし 変更あり 変更あり 変更あり OS/ミドルウェア 変更なし 変更あり 変更あり 変更あり 変更あり ハードウェア 変更あり 変更あり 変更あり 変更あり 変更あり 今回の 再構築パターン リスク/影響 低 高
35. 仕様再定義 参考：大規模レガシーシステムのモダナイゼーション手法 https://www.ipsj.or.jp/dp/contents/publication/42/S1102-S04.html N字モデル 明確化できないシステム機能仕様を、リバースエンジニアリングで現行プログラム ソースから抽出し、V字モデルにつなげる。 従来のV字モデルの前段階に、現行ソースを解析する工程を追加 35
36. 全体のアーキテクチャ 36 分散トレーシング ログ分析/可視化 メトリクス監視 Logstash
 Elasticsearch
 Kibana
 デプロイ
 Concourse
 CI/CD
 Prometheus
 Tanzu Application Service 開発 運用/監視 システム稼働 DB・ミドルウェア ソースコード管理
 パッケージ管理
 Kibana

37. 全体のアーキテクチャ 分散トレーシング ログ分析/可視化 メトリクス監視 Logstash
 Elasticsearch
 Kibana
 デプロイ
 Concourse
 CI/CD
 Prometheus
 Tanzu Application Service 開発 運用/監視 システム稼働 DB・ミドルウェア ソースコード管理
 パッケージ管理
 Kibana
 37
38. 
 
 
 開発パートナー企業との契約 こちらを選択 決まった成果物だけが欲しかったのではなく、 内製開発のように動作するアプリを開発しながら 検討を繰り返し手段や品質の改善を重ねたい。 請負契約 OR 準委任契約 （SES契約） 38
39. システム構成と体制 プラットフォーム（TAS） インフラ - オンプレミス（HCI） インフラチーム プラットフォームチーム 39
40. システム構成と体制
 40 プラットフォーム（TAS） インフラ - オンプレミス（HCI） インフラチーム プラットフォームチーム 開発チーム A社 45名 開発チーム B社 15名 開発チーム C社 6名 40 基幹システム オペレータ向け システム 会員向け システム
41. システム構成と体制 基幹システム オペレータ向け システム 会員向け システム プラットフォーム（TAS） インフラ - オンプレミス（HCI） インフラチーム プラットフォームチーム 開発チーム A社 45名 開発チーム B社 15名 開発チーム C社 6名 アプリ基盤チーム 支援 41
42. Team Topologies - チームタイプ
 42 基幹システム オペレータ向け システム 会員向け システム 開発チーム A社 開発チーム B社 開発チーム C社 アプリ基盤チーム イネイブリングチーム ストリームアラインドチーム ファシリテーション 支援 課題解決
43. Team Topologies - チームタイプ
 基幹システム オペレータ向け システム 会員向け システム プラットフォーム 開発チーム A社 開発チーム B社 開発チーム C社 アプリ基盤チーム イネイブリングチーム ストリームアラインドチーム ファシリテーション 支援 課題解決 X as a Service プラットフォームをサービスとして提供 プラットフォームチーム 43
44. • 大規模PJの新たな挑戦 ◦ プロジェクト概要と体制 ◦ イネイブリングチームとしての取り組み ◦ プラットフォームエンジニアリング 44
45. イネイブリングチームの役割 • 適切なツール、プラクティス、アプリケーションスタックに関する調査、正しい情報に基づく提案 • ソリューションの提供だけではなくガイダンスを提供する • 開発チームの自律性を高めることを目的とする イネイブリング チーム （アプリ基盤チーム） 開発チーム 基幹システム 開発チーム オペレータ向け システム 開発チーム 会員向け システム 技術支援/フィードバック 開発チームに対して支援 45
46. プロトタイプ開発 当初 開発チーム（パートナー会社）がCloudNativeな環境での開発経験がなく、 開発コンセプトやプラットフォーム、設計書/コード等の成果物のイメージが持て ずこれまでのやり方を踏襲しようとしたためイネイブリングチームとの間で摩擦 が起きてしまった。 課題 46
47. イネイブリングチーム主導で各開発チームが1機能をプロトタイプ開発。 設計書作成、実装、ビルド、ユニットテスト、デプロイ全ての工程を対象とした。 対応 47 プロトタイプ開発 当初 開発チーム（パートナー会社）がCloudNativeな環境での開発経験がなく、 開発コンセプトやプラットフォーム、設計書/コード等の成果物のイメージが持て ずこれまでのやり方を踏襲しようとしたためイネイブリングチームとの間で摩擦 が起きてしまった。 課題
48. プロトタイプ開発 当初パートナー会社（開発チーム）がCloudNativeな環境での開発経験がなく、開発コン セプトやプラットフォーム、設計書/コード等の成果物のイメージが持てずこれまでのやり 方を踏襲しようとして摩擦が起きた。 イネイブリングチームと開発チームの双方で開発方式や成果物に対するギャップを感じ ていた。 課題 イネイブリングチーム主導で各領域において1機能をプロトタイプ開発した。 設計書作成、実装、ビルド、ユニットテスト、デプロイ全ての工程を対象とした。 対応 効果 開発チームが実際に手を動かして開発し、イネイブリング チームと意見交換することで開発コンセプトや手法、成果 物に対する認識を合わせることができた 48
49. 開発ガイドラインの整備 プロトタイプ開発でギャップは埋まったが、PJ中盤で増えてくる数十名の開発 者に同様のことを伝える労力がかかってしまう。 アプリ開発が本格化した後に開発チームが混乱しないようにナレッジの共有を する必要があった。 懸念 49
50. イネイブリングチームがプロトタイプ開発で得られた知見を 開発ガイドラインに記載した。 テキストだけではなくデモや説明はアーカイブ動画を残した。 対応 50 開発ガイドラインの整備 プロトタイプ開発でギャップは埋まったが、PJ中盤で増えてくる数十名の開発 者に同様のことを伝える労力がかかってしまう。 アプリ開発が本格化した後に開発チームが混乱しないようにナレッジの共有を する必要があった。 懸念
51. 開発ガイドラインの整備 プロトタイプ開発でギャップは埋まったが、PJ中盤で増えてくる数十名の開発者に同様の ことを伝える労力がかかってしまう 課題や質問に対して回答ができなくなってしまう不安があった 懸念 イネイブリングチームがプロトタイプ開発で得られた知見を 開発ガイドラインに記載した。 テキストだけではなくデモや説明はアーカイブ動画を残した。 対応 効果 開発メンバーに事前にガイドラインに目を通してもらう ことで開発手法や有用なプラクティスを浸透させた 51
52. 大規模プロジェクトのウォーターフォール開発の問題点 フェーズが長い、フェーズ毎に担当者が入れ替わる、成果物が出てくるのが数カ月後 前工程の成果物に間違いがないことが前提 後続フェーズで気付いた設計や実装の不備はすべて手戻りとして扱われてしまう 内製開発時と同様の開発サイクル 全アプリ全機能の設計 全アプリ全機能の実装 全アプリ全機能のテスト よくあるウォーターフォール開発の流れ 設計チーム 実装チーム テストチーム リリース サービス稼働 52
53. 今回採用した開発サイクル Aアプリ チーム テスト 実装 設計 機能a テスト 実装 設計 機能b テスト 実装 設計 機能c 従来のように長期間となる設計フェーズ/実装フェーズ/単体テストフェーズを設けない。 業務毎にチームを分割し、メンバーが担当するそれぞれの機能を設計/実装/テストの短いサ イクルを繰り返しながらアプリケーションを完成させる 内製開発時と同様の開発サイクル … 53
54. 段階的な並列化でPJを推進 Aアプリ チーム テスト 実装 設計 機能a テスト 実装 設計 テスト 実装 設計 内製開発時と同様の開発サイクル … 機能b 機能c Bアプリ チーム テスト 実装 設計 機能c テスト 実装 設計 テスト 実装 設計 機能d 機能e Cアプリチー ム Cアプリ チーム Dアプリ チーム Eアプリ チーム … … … … システム テスト リリース サービス稼働 ・ ・ 54
55. 効果 • 各チームが業務に関する深い知識を得ることができシステム移行やシステム テストにつなげることができた • フェーズを設けないことで設計ミスを早期に発見し、手戻りが小さくなった • 開発中に気付いた設計改善を積極的に取り入れやすくなった この開発サイクルによって • すべての開発メンバーが設計から実装、テスト計画まで全ての工程を担当 • フェーズ間を埋めるために作成していた不完全で余分な設計書を廃止 （開発サイクルを回しながら着実に最適化） 内製開発時と同様の開発サイクル 55 テスト 実装 設計
56. 56 発生した課題 • チーム毎の成果物の品質に差が出やすい • イネイブリングチームによる開発支援や開発ガイドラインで全体の品質を底上げ • プラットフォームのおかげで認知負荷を低減、品質と生産性をカバー ◦ CI/CDによるテストとデプロイの自動化 ◦ ログ監視、メトリクス監視が自動的に適用される 内製開発時と同様の開発サイクル
57. 発生した課題 • チーム毎の成果物の品質に差が出やすい • 各チームにテックリードエンジニアを配置 • 長期PJのためメンバーが成長し後半に活躍 • イネイブリングチームによる開発支援や開発ガイドラインで全体の品質を底上げ • プラットフォームのおかげで認知負荷を低減、品質と生産性をカバー ◦ CI/CDによるテストとデプロイの自動化 ◦ ログ監視、メトリクス監視が自動的に適用される 内製開発時と同様の開発サイクル • レベルの高いエンジニアが求められてしまう 57 開発 チーム 開発 チーム 開発 チーム
58. 58 イネイブリングチームによるアプリ開発 イネイブリングチームが業務アプリ開発に直接関わっていなかったため、開発 チームにとって本当に有益な情報が何か見落としてしまう懸念があった。 開発の一連の流れを通して体験していないと当事者意識が薄れ開発チームへの情 報提供が不十分となってしまう。 懸念
59. イネイブリングチームによるアプリ開発 開発難易度が高く利用技術が多岐にわたるアプリをイネイブリングチームが開発か らリリースまで担当した。 対応 59 イネイブリングチームが業務アプリ開発に直接関わっていなかったため、開発 チームにとって本当に有益な情報が何か見落としてしまう懸念があった。 開発の一連の流れを通して体験していないと当事者意識が薄れ開発チームへの情 報提供が不十分となってしまう。 懸念
60. イネイブリングチームによるアプリ開発 イネイブリングチームが業務アプリケーション開発をしていなかったため開発チームに とって本当に有益な情報が何か見落としてしまうことが予想された。 プラットフォームの利用感覚は実際に開発の一連の流れを通して体験しないと理解でき ず開発チームへの情報提供が不充分となってしまう。 課題 開発難易度が高いアプリや利用技術が多岐にわたるアプリをイネイブリングチームが担 当として開発からリリースまで担当した。 対応 効果 イネイブリングチームがアプリ開発の当事者となることでガイドライン や各種テンプレート、支援内容の質が高まった。 イネイブリングチームがプラットフォームの最初の利用者となること で、プラットフォームチームに改善点をフィードバック。 60
61. 横断的 / 継続的な開発支援 開発プロセスの標準化、ルール化に加えてガイダンスを提供 各チームが課題に直面して生産性が下がらないように Concourse Karate Elastic Stack 実行環境 テスト 負荷テスト ビルド Observability CI/CD 成果物管理 静的コード解析 61 イネイブリング チーム 開発 チーム 開発 チーム 開発 チーム
62. 各種ツールや設定を提供し継続的に支援 CIビルドパイプライン設定テンプレートを提供 62 静的コード解析ツールのルールを作成/提供 アプリ一覧ダッシュボードを開発し提供 ライブラリのアップデートに追従できてる？ ログを効率良く確認するためのダッシュボードを提供 怪しいログ出てないよね？ その後Greenを維持できてる？ 悪化してないよね？
63. • 大規模PJの新たな挑戦 ◦ プロジェクト概要と体制 ◦ イネイブリングチームとしての取り組み ◦ プラットフォームエンジニアリング 63
64. 64 プラットフォーム プラットフォームチームが開発チームへプラットフォームを提供 提供されたプラットフォームを利用することで開発チームの開発体験と生産性が向上 プラットフォーム チーム 開発チームへ 提供
65. 開発チームの問題点 開発や運用をする上で必要なアレやコレや… 65
66. 開発チームの問題点 開発や運用をする上で必要なアレやコレや… 66
67. 開発チームの問題点 開発や運用をする上で必要なアレやコレや… 67
68. 開発チームの問題点 開発チームの認知負荷が高すぎる 68
69. プラットフォーム プラットフォームチームが開発チームへプラットフォームを提供 提供されたプラットフォームを利用することで開発チームの開発体験と生産性が向上 69 プラットフォーム チーム 開発チームへ 提供
70. プラットフォームエンジニアリング • 開発チームの認知負荷を低減 • 開発体験と生産性を向上 ◦ 開発中のアプリが継続的にテスト/デプロイされること ◦ デプロイされたアプリは管理コンソールでスケールでき自動リカバリが備わっていること ◦ デプロイされたアプリケーションのログやメトリクスが自動的に収集/可視化されること • 開発中であっても “動くソフトウェア” が常に存在すること 70 プラットフォーム チーム 自動テスト 自動デプロイ 自動ログ収集、 可視化 スケーラブル 自動リカバリ
71. プラットフォームの存在 • 開発チームの認知負荷を低減 • 開発体験と生産性を向上 ◦ 開発中のアプリが継続的にテスト/デプロイされること ◦ デプロイされたアプリは管理コンソールでスケールでき自動リカバリが備わっていること ◦ デプロイされたアプリケーションのログやメトリクスが自動的に収集/可視化されること • 開発中であっても “動くソフトウェア” が常に存在すること プラットフォーム チーム 自動ログ収集、可 視化 開発メンバーの意識や気持ちに ポジティブな影響を与えた • 認知負荷の低減 • 自動テスト/デプロイのある安心感 • 改善に対して前向きなマインド • 自発的な品質向上の提案 71
72. 本日のまとめ 決済システム内製化のその先に ～ クラウドネイティブな開発を ”スケール” させるために必要だったこと 72
73. 73 5年前の内製開発でCloudNativeな 開発/運用ノウハウを蓄積 開発を “スケール” させるために イネイブリング チーム 開発チーム 有識者でイネイブリングチームを作り、 最初に１機能をプロトタイプ開発 そこで得られた知見をガイドライン化、 テンプレート化 その後イネイブリングチームは横断的な支 援活動を行い、CloudNativeな開発を実現 開発支援
74. 74 5年前の内製開発でCloudNativeな 開発/運用ノウハウを蓄積 開発を “スケール” させるために イネイブリング チーム プラットフォーム チーム 開発チーム 有識者でイネイブリングチームを作り、 最初に１機能をプロトタイプ開発 そこで得られた知見をガイドライン化、 テンプレート化 その後イネイブリングチームは横断的な支 援活動を行い、CloudNativeな開発を実現 開発支援 開発チームの認知負荷を低減 開発体験と生産性を向上 プラットフォームの提供
75. 5年前の内製開発でCloudNativeな 開発/運用ノウハウを蓄積 開発を “スケール” させるために 70人以上の開発体制にスケール 開発成功 75 イネイブリング チーム プラットフォーム チーム 開発チーム 有識者でイネイブリングチームを作り、 最初に１機能をプロトタイプ開発 そこで得られた知見をガイドライン化、 テンプレート化 その後イネイブリングチームは横断的な支 援活動を行い、CloudNativeな開発を実現 開発支援 開発チームの認知負荷を低減 開発体験と生産性を向上 プラットフォームの提供
76. クラウド / オンプレミス 内製 / 外注 クラウド環境、内製開発で培った CloudNativeな開発体験をオンプレ環境に持 ち込み生産性を向上させた。 また外部パートナー企業と共に協力すること で開発を ”スケール” できた。 このPJを通じて 76
77. このPJを通じて クラウド / オンプレミス 内製 / 外注 これらの手段は回帰や対立関係ではなく ビジネスや業務要件に応じて 最適なものが選択できることが大事 77