事業貢献を加速させる新たなプラットフォーム戦略
一方、技術面での課題として、まずモノリスの問題がある。巨大な一枚岩のシステムでは、一部分の変更が全体に影響を及ぼし、影響調査やテストに多大な時間がかかる。これがアジャイルな開発を妨げる要因となっている。この問題を解決するためにマイクロサービスが提唱された。機能間の依存性を最小限に抑え、独立した変更を可能にする考え方だ。しかし、近年では全てをマイクロサービス化することは新たな問題を生むことが指摘されている。データの不整合、複雑な構成管理、高いメンテナンスコストなどが課題となる。
そこで現在は、モノリスとマイクロサービスの両極端を避け、適切な粒度を考える方向に進んでいる。システムの特性に応じて、モノリス、アプリケーション、サービス、マイクロサービスなど、さまざまな粒度を選択できる。また、これらの連携方法も、同期APIだけでなく、非同期API、DB共有、ファイル連携、イベントストリームなど、状況に応じて適切に選択する必要がある。鈴木氏は「銀の弾丸は存在せず、各システムやプロダクトの特性に合わせて適切なアーキテクチャを選択することが重要です」と話した。
鈴木氏は、技術的な問題の新しい解決策として、Internal Developer Platform（IDP）またはプラットフォームエンジニアリングと呼ばれる手法を紹介した。これは、複数のチームやシステムが個別にクラウド設定を行う代わりに、一元管理するためのプラットフォームやガイドラインを準備する考え方だ。
IDPは、DevOpsや運用管理基盤として機能し、コンテナ化を重視する。Kubernetesなどのコンテナオーケストレーションツールを使用し、Gitリポジトリ、CI/CD、オブザーバビリティ、チケット管理などを統合する。これにより、セキュリティ設定が完了したクラウド環境とテンプレート、ガイドラインを提供できる。
さらに、社内の基幹システムのデータやロジックも統合し、新サービス開発時の基幹システムとの調整を簡素化する。これは、1週間〜3か月といったサイクルで開発を行う際の大きな障壁を取り除くことにつながる。IDPの運営について鈴木氏は書籍「チームトポロジー」（日本能率協会マネジメントセンター刊）の概念を紹介した。直接的に事業貢献する「ストリームアラインドチーム」と、それを支える「プラットフォームチーム」によって運営していくというものだ。
最終的には、IDPをもとにして、システムを段階的にモダナイズし、新しいサービスを作成していく。モノリスな構造から、より分割された事業貢献しやすいシステムへと徐々に移行していく。
最後に鈴木氏は、「従来のシステムの一括再構築では、システムの中身は変わっても枠組みは変わらないことが多かったです。しかし、システムの枠組み自体を、事業や業務の範囲に合わせて柔軟に変更する必要があります。そのためにプラットフォームを構築し、そこから少しずつシステムを切り出していくアプローチが効果的です」とコメントした。
