IT基盤をモダナイズするための3つのステップ
この記事は Google Cloud Japan Customer Engineer Advent Calendar 2019 の 最後の記事になります。ここでは、プロダクトに関する話ではなくて、少し視点を変えて、IT基盤をモダナイズするための道筋について考えてみたいと思います。
DXとは
最近筆者の周りでは、DX（デジタルトランスフォーメーション）という言葉をよく聞くようになりました。IT業界特有の流行り言葉の側面もありますが、その本質はデジタル化が進展していく中で、新しい技術を活かして新たな価値を創出しなければ競争力が失われてしまう、ということだと思います。
経産省が２０１９年３月にまとめた、いわゆる「DXレポート」の中では、DXという言葉が以下のように定義されています。
企業が外部エコシステム（顧客、市場）の破壊的な変化に対応しつつ、内部エコシステム（組織、文化、従業員）の変革を索引しながら、第三のプラットフォーム（クラウド、モビリティ、ビッグデータ/アナリティクス、ソーシャル技術）を利用して、新しい製品やサービス、新しいビジネス・モデルを通して、ネットとリアルの両面での顧客エクスペリエンスの変革を図ることで価値を創出し、競争上の優位性を確立すること。
分かったような、分からないような。自分なりに理解すると、
Why？なんのためにやるのか。”外部エコシステムの破壊的な変化に対応しつつ、、、競争上の優位性を確立すること”
What？何をするのか。”新しい製品やサービス、顧客エクスペリエンスの変革を図ることで価値を創出”
How？どうやってやるのか。”第三のプラットフォームを利用”
この「第三のプラットフォーム」の中に「クラウド」が位置づけられています。基盤の観点から言えば「クラウドネイティブテクノロジー」と言い換えてもいいかもしれません。つまり、クラウドネイティブテクノロジーがDXを実現するための一つの重要な要素になっていると理解することができます。
DXを実現するためにはIT基盤のモダナイゼーションが必要
ところが、DXを実現しようにも
約７割の企業がレガシーシステムがDXの足枷と感じている
ここが我々ITに携わるものが解決すべき課題です。例えば、新しく顧客向けのモバイルアプリケーションを作ろうにも、数ヶ月の開発期間、数千万円を超えるコストが普通に請求されてしまう、といったことが起こります。
時間がかかる、お金がかかる理由は、そもそも自社開発せずに外注することが原因でもあります。請負ベンダーによるリスクヘッジやコミュニケーションコストが上乗せされるのです。「ソフトウェアファースト」の時代には、ソフトウェア開発を内製化すべしとの議論がありますが、ここでは深入りせずにIT基盤の問題に目を向けます。
そこには、複雑なそしてブラックボックス化されたバックエンドのシステムが横たわります。フロントのアプリケーションからつなぎこもうとしても、 技術的に難しい（CORBA、MQ、Tuxedoといった昔ながらの技術が使われている）、 仕様的に難しい（インタフェース仕様やシステムの動作がわからなくなっている）といったことが上げられます。
では、どうやって改善していけば良いのでしょうか？
システムの仕分けが重要。SoEは差別化し、SoRは標準化する
みずほ銀行のシステム統合では、35万人月、4000億円以上が費やされたと聞きます（日経XTECH記事）。すべての会社がこのようなビッグバン的なアプローチでシステムをモダナイズできるわけではありません。変わるところと変わりにくいところを分けて、それぞれ別のアプローチで取り組むことが重要だと思います。
エンタープライズシステム全体を見渡してみると、変わりやすいところと変わりにくいところがあります。
例えば、筆者が関わったことのある通信会社のシステムの例でいうと、顧客システムやビリング、設備といったいわゆる基幹系のシステムは、ビジネスを遂行する上で根源的なデータを扱うところであり、基本的には大きく変わらないところです。
一方、商品やサービス、あるいは顧客対応のアプリケーション、コールセンター向けのアプリケーションといったフロントエンドのシステムは、ビジネスニーズや市場環境によって大きく変わるところです。
前者をSoR（System of Records）、後者をSoE（System of Engagement)と言い換えると、SoEは変わりやすく、SoRは変わりにくい。
これらを疎結合にし分離して考えることがモダナイゼーションの第一歩です。これは米ガートナーが提唱している「バイモーダルIT」の考え方に繋がります。
モダナイゼーションへの道筋としては、SoEとSoRを分離し、SoEは積極的に差別化をしていくところと位置づける、そしてSoRは多様性を許容しながら最終的には標準技術に移行していく。これが基本的な考え方になります。
ステップ１．APIレイヤでSoRを抽象化する
最初のステップとしてやるべきことは複雑なSoRを抽象化することです。SoRとSoEの間にAPIレイヤを挿入することで、SoRの複雑性を隠し、上位のSoE（アプリケーション）に対してわかりやすいインタフェース（API）を提供することができます。
API レイヤの実装として、GCP では API 管理基盤 Apigee を提供しています。Apigee には API プロキシの機能が備わっており、予め組み込まれている各種ポリシーを組み合わせることで、バックエンドのサービスプロバイダーとコンシューマーであるアプリケーションの間のミスマッチを解消することができます。
このような仲介レイヤを持つことで、フロントエンドの要件変更に対しても、バックエンドに影響を与えることなく簡単に対応することができます。また、バックエンド側の変更もフロントのアプリケーションに影響を与えないように対応できます。
Apigee で特筆すべきは、プロダクトとしての実績と業界の中での認知でしょう。ガートナーのマジッククアドランドによると、API 管理分野において4年連続でリーダーの評価を獲得しており、今年のレポートではさらに実行能力において最高点を上げています。
Apigee に関しては、以下のブログ記事がおすすめです。
ステップ ２．SoE はサーバレスでアジャイルに
次に取り組むべきことは顧客接点となるSoEの改善です。顧客に対してどのようなエクスペリエンスを提供できるのか、そのために素晴らしいアプリケーションをいかに早く提供できるのか。DXの文脈でいうとここが最も重要になるわけです。
SoE の改善は基盤だけで達成できるわけではありません。プロセス（アジャイルや DevOps、SRE の考え方）やアプリケーションの構造（マイクロサービスアーキテクチャ、12 Factor App）も関係してくるところではあります。ここはアプリケーションセントリックに考えるべきです。より良いアプリケーションを作るために集中する。基盤としては、
- すばやく
- 繰り返し
- スケール
といったSoEの特性に合わせたものが必要です。ここには、サーバレス基盤を積極的に活用することを提案します。
多くのサーバレスサービスを抱えているのが GCP の特徴です。GAE は2008年にリリースして以来10年以上の歴史がありますし、最新のアプリケーションサーバレス基盤 Cloud Run は、GAE の制約であった対応言語の問題をコンテナに対応することで解決し、さらには GCP 上だけでなくて、オンプレミスでも同じアプリケーションを動作させることができます。
Cloud Run に関しては、以下のブログ記事がおすすめです。
ステップ３．SoRは標準技術で緩やかに移行する
最後にSoRの部分。あくまでもSoE、顧客にむけた「攻めのIT」を実現するために、SoRをどう変えていくのかという視点が必要になると思います。
SoR は将来のレガシーとならないように標準技術で構築することが重要です。クラウドネイティブ時代の新しい技術を活用していくことを考えた場合、CNCF (Cloud Native Computing Foundation)の動向にも目を払うと良いと思います。モダンアプリケーションに必要なツールキットをオープンソースとして取りまとめているのが、CNCF の役割です。
Open Source Cloud Computing for Applications （アプリケーションのためのオープンソースクラウドコンピューティング）
We curate & promote a trusted tool kit for modern architecture （CNCFはモダンアーキテクチャのための信頼できるツールキットを集め促進する）
CNCF の中でも中心的な位置づけとなる Kubernetes は2014年にオープンソース化され、2015年にはそのマネージド・サービスであるGKEがリリースされました。Kubernetes の役割は、コンテナ化されたアプリケーションに対して、その下のインフラを抽象化することです。オンプレミスでDellやHPのサーバが動いていようが、GCPであろうが、その他のクラウドであろうがアプリケーションから見ると同じKubernetesのインタフェースと話をすればよく、運用者のオペレーションを統一することができます。
GCPでは、GKE、GKE On-Prem、を提供、さらに将来的にはAWS のような他のクラウドで動作するGKEを提供します。
長い移行期間を考えると、すべての基幹システムを単一の技術で統一するのは難しいかもしれません。またできたとしても、技術革新のスピードを考えると、今最適な技術が10年後にもふさわしいかどうかは誰にもわかりません。そう考えると、SoR の部分はある程度技術の多様性を許容できるようになっていないといけないのかもしれません。
多様性を許容する
そのためにも抽象レイヤとしてのAPI基盤が重要になるわけです。
まとめ
最後に超ハイレベルなリファレンスアーキテクチャなるものを作るとしたら以下のような絵になるのではないかと思います。
DXの文脈では、顧客に対して素晴らしいアプリケーションを提供することが重要だと思います。図の一番上にある赤いアプリケーションが重要です。
既存ITの複雑性が足枷になるというのが課題でした。なので、まずは、API 基盤で SoR を抽象化します。
SoE はアプリケーションのために定義されたAPIを使って、アプリケーションを構築します。アプリケーションの実行基盤としては、サーバレス基盤を使います。これにより、アジャイルにスケールするアプリケーションの提供が可能になります。
SoR は標準技術を使って緩やかに移行しましょう。Kubernetes を中心とした新たな技術スタックを活用していきます。
さて、Google Cloud CE による Adventカレンダー楽しんでいただけたでしょうか？来年も皆さんにとって良い年になりますように！
