DX（デジタルトランスフォーメーション）への投資を続けているにもかかわらず、多くの企業は望ましい成果を上げられずにいます。
たとえば、マッキンゼー＆カンパニーの最近の調査によると、多くの企業がクラウドへの投資は、DXの目標達成に対して十分に貢献していないと回答しています。
少なくともこの問題の一端は、DXが単体の技術によって達成されるものではないことと関係しています。DXとは本質的に、より多くのモバイルアプリをリリースすることでも、クラウドへ移行することでも、あるいは、機械学習やその他のDXを連想させる限定的な技術を活用することでもありません。
そもそもDXは、これらすべてを包括しています。重要なことは、個々のプロジェクトの内容や、それらのプロジェクトをどう連携させるかということではありません。DXとはいわば、“ITアジリティ”の状態を達成して、顧客の嗜好や市場のダイナミクスの変化に企業が絶えず適応できるようにすることです。
誤解されやすい点ではありますが、ITアジリティの状態を達成すること自体が、ビジネスの成果を変えるわけではありません。しかし、ITアジリティは飛躍的なビジネス成果を得るためのレバレッジとなります。アジリティが向上すれば、企業の効率性を高めることも、パートナー、サプライヤー、顧客との関わり方を進化させることもできます。新しい方法で収益を上げることも期待できるのです。
このアジリティは、ITアーキテクチャが起点となります。クラウドにするかオンプレミスにするか、という意味ではありません。むしろ、企業が自社独自の能力を、別の目的のために、いかに簡単かつアジャイルに活用し、再構築できるかにかかっています。
DX達成のために必要なのは、継続的なアジリティと対応力である
すべての企業は、データであれ、機能であれ、貴重なデジタルアセットを持っています。しかし、これらは企業自身が活用あるいは併用でき、さらにはパートナーとも共有でき、なおかつ摩擦を最小にできて、はじめて戦略的な資産となるのです。
これは、サービスがどこに存在するか、が必ずしも重要ではないことを意味します。つまりクラウドでも、オンプレミスのサーバーでも、ハイブリッド構成によってその両方に存在していても、いずれでも構いません。より重要なのは、サービスを別の環境に移動した方が得策である場合に、それを実行できるかどうかなのです。
同様に、モバイルアプリケーションに特定の機能を組み込むことも必要不可欠ではありません。肝心なのは、その機能を将来の新しい目的のために、どれだけ簡単に再利用、または活用できるかです。その他の技術についても同じようなことが言えます。
これは多くの企業にとって大きな変化です。企業の多くは、アプリケーション内の機能が密結合したモノリシック（一枚岩的）なアーキテクチャ・スタイルに慣れています。このアプローチでは、アプリケーションを壊さずに更新することも、アプリケーション内の単一の機能部品を新しいプロジェクトに流用することも困難です。また、開発者が互いに影響を及ぼさずに仕事をするのも難しいため、全体的な開発スピードや自律性が制限され、新しいデジタル・エクスペリエンスを顧客に提供する能力も制限されてしまいます。
アジリティを高め、DXによるビジネス成果を生み出すための鍵は、こうした依存関係を断ち切ることです。
アジャイルなアーキテクチャとはどのようなものか
デジタルに精通した企業は、モノリシック・アプリケーションの代わりに、小規模で単機能のマイクロサービスをますます構築するようになっていて、多くのマイクロサービスを組み合わせてアプリケーションやデジタル・エクスペリエンスを生み出すケースが増えています。このようなマイクロサービスは、アプリケーションから機能を切り離します。また、マイクロサービスは独立してデプロイできるため、各サービスの開発者は互いの仕事を邪魔せずに開発を進められます。
結果として、動きの鈍い大人数の開発チームから、俊敏で独立性の高い少人数のチームに移行できます。少人数の開発チームが並行して作業すれば、新しい機能やエクスペリエンスの構築、リリースに要する時間が短縮されます。また、互いに学び合い、迅速なイテレーション（アジャイル開発プロセスにおけるサイクルの反復）も可能となるため、企業はイノベーションのペースを加速できるのです。
そして、開発者は個々のマイクロサービスにアクセスできる必要があり、ここでアプリケーション・プログラミング・インターフェース（API）の役割がクローズアップされることになります。
APIの役割
APIは、フロントエンドの開発からバックエンドの複雑さを切り離し、その複雑さを抽象化して、誰でも簡単に使えるインターフェースを提供します。基盤となる技術に詳しくない開発者でも、新しいアプリケーションやエクスペリエンスの開発にこのインターフェースを使用できるのです。
APIはチーム間や外部パートナーとのマイクロサービスの共有を促進するだけでなく、異なる時代の、異なるシステムや技術が混在した異種環境にアジリティをもたらします。
とはいえ企業が、すべてのモノリシック・アプリケーションをマイクロサービスに分解することはまずありえません。しかし、それでも古いアプリケーションを新しい技術に接続しなければならない可能性はあり、そのようなケースにおいて最適な方法はAPIの活用です。
コンテナ、API、マイクロサービスを中心とした疎結合アーキテクチャは、適切に管理されていれば、企業のデジタルアセットをより簡単に活用できるようになるのです。
マイクロサービスはしばしばコンテナと結び付けられており、この組み合わせはモダン・アーキテクチャからアジリティを生み出す別の機会を与えます。コンテナは、基盤ハードウェアとオペレーティングシステムの両方からアプリケーションを切り離すことができます。コンテナは、ハードウェアしか切り離せない仮想化技術よりも、一歩秀でているといえます。
コンテナの特性には、多くのメリットがあります。たとえば、開発者はコンテナ化されたマイクロサービスを記述する時、ポリシーに関するコードを含める必要はありません。これらは共有されたオペレーティングシステムのリソースに、コンテナレベルで一括して展開できます。
また、コンテナは、どのような種類のハードウェア・サービスが稼働しているかについて、ある程度の不可知論をもたらします。つまり、企業は複数のアプリケーションに対して複数のサーバーを配備しなくて済み、異なる環境の間、たとえばあるクラウドから別のクラウドへ、またはオンプレミスからクラウドへ、サービスをより簡単に移行できます。
アジャイルなアーキテクチャにおける管理ツールの重要性
モダンなITアーキテクチャでは、開発者はデジタルアセットをモジュール的に使用できるので、異なるシステム間の相互運用性とソフトウェアのポータビリティが向上します。しかし、複雑さが大幅に増すという側面もあります。この複雑さは、アジャイルな疎結合アプローチにおいて、コンテナ化されたマイクロサービスや、APIそのものよりさらに進んだ管理ツールが重要になることを意味します。
たとえば、顧客向けサービスを稼働し続けるため、企業は数千ものサービスをオーケストレート（統合化）しなければなりませんが、サービスの多くが異なる場所でホストされているような場合があります。管理ツールには、サービス間の通信を自動化する機能が求められます。これは複雑すぎて人間のオペレーターでは対処できません。また、すべての環境にわたる統一された、かつ一貫性のある包括的なビューによって、APIとマイクロサービスの使用状況を知らせる機能も必要です。
同様に、開発者にマイクロサービスとAPIを最大限に活用させたいならば、厳しいガバナンス・プロセスを開発者に課してはなりません。つまり、誰がそのアセットを使用しているかを管理し続けながらセルフサービスを提供する、アセットの使用状況の包括的な可視性を維持する、問題が発生した場合には運用チームとセキュリティチームに対して自動化されたレスポンスやアラートを生成する、といった手段が必要となります。
アジリティはどのようにしてビジネス成果を生み出す原動力となるか
もちろん、根深くはびこる技術的な「雑草」に対処する必要もあります。しかし、これまでの説明から、コンテナ、API、マイクロサービスを中心とする適切に管理された疎結合アーキテクチャがあれば、企業のデジタルアセットをより簡単に活用できるようになることがおわかりいただけるでしょう。
企業はどのようにしてITアジリティを、ビジネス成長の機会に変えることができるのか？ エコシステムへの参加は、最も刺激的で有益な例の一つだ。
これは最終的な問題、すなわち、このITアジリティを、ビジネスを成長させる機会に変えることにつながります。このアジリティはビジネス戦略にさまざまな形で現れますが、なかでもエコシステムへの参画は刺激的で有益な例のひとつです（参考記事）。
APIを利用すると、自社独自のAPIを再結合して新しいデジタル・エクスペリエンスを作り出すのが容易になるだけでなく、自社APIをパートナーのAPIと組み合わせるのも容易になります。
一例として、多くの企業はアプリケーションでマップやナビゲーションの機能を使用していますが、こうした機能を社内で開発する必要がなくなります。GoogleマップやGoogle DirectionsなどのサードパーティAPIを、自社の技術（たとえば店舗所在地APIなど）と組み合わせれば済むからです。
実際、今日のイマーシブなカスタマーエクスペリエンスの多くは、1つの企業によって作られたものではなく、多くの企業のサービスをAPIによって結び付けることによって、適切なコンテンツやオプションを適切なタイミングで提供することを実現しています（参考記事）。
つまり、物理的世界でよく見られるように、企業は顧客を引きつけるために必要なインフラの構築と維持にかかる費用を一から十まで自ら負担するのではなく、APIを使用して消費者とのインタラクションがすでに発生しているデジタルコンテキストに挿入したり、パートナーAPIを使用して内部機能を強化することもできます（Google Cloudによる参考記事）。
大手企業は API をどのように活用しているか
たとえば、米国のある大手チケット販売会社は、少し前まで電話セールスやリアル店舗のチケット売り場、自社アプリを主要な販売チャネルとしていました。このケースでは、顧客を集める責任を自社で負い、リーチ拡大のアクティビティのほとんどを自社で対応するアプローチです。しかし、最近では、この企業はイベント検索やチケット購入などの機能をAPIとして用意することで（参考記事）、自社の中核ビジネスをソーシャルメディア・プラットフォームなど、すでに潜在的顧客が集まっているデジタル・エクスペリエンスに挿入できるようになりました。
また、Pitney Bowesが、出荷・ロジスティクスAPI（既知の住所を検索するAPIや、最も安い送料を探すAPIなど）によって郵便と小包の発送業務を効率化させた事例もあります（Google Cloudによる参考記事）。こうしたAPIは幅広いパートナーのアプリケーションに実装され、それらのパートナーの顧客が利用できるようになるのです。
AccuWeatherは、さまざまなサブスクリプションモデルを通じてAPIへのアクセス権を販売している
また、AccuWeatherは、自社のAPIへのアクセスをさまざまなサブスクリプション・モデルを通じて販売することで、データを収益化し、多くの開発者が同社の知的財産を使用してイノベーションを果たせるようにしました（Google Cloudによる導入事例）。
事例を挙げていけばきりがないですが、DXによるビジネス運営方法の大きな進化は、限定的なモバイルアプリやクラウド移行だけに基づくものではなく、制御と管理性を維持しながら、継続的なアジリティを促進する分離アーキテクチャによって成し遂げられたということです。
DXは、完了すべき技術プロジェクトというよりは、継続的なアジリティの状態と考えてください。アジリティを高めることができれば、顧客が次に何を望んでも、いつでもすぐに適応し、正しい道を進むことができます（参考記事）。
インフラストラクチャ、サービス、チームを切り離す方法について興味をお持ちの場合は、優れたハイブリッドおよびマルチクラウド戦略を策定するためのベストプラクティスをまとめたGoogleの無料レポートをお読みください。
Amit Zavery ◎Google Cloud のバイスプレジデント兼ゼネラル マネージャー、およびプラットフォーム担当責任者を務める。DXの道を歩む企業のためにビジョンや戦略を立案し、Google Cloudのビジネス アプリケーションプラットフォームを提供する。Google入社以前は、Oracleでクラウドプラットフォームとミドルウェア製品担当のエグゼクティブ・バイスプレジデント兼ゼネラルマネージャーの職務に就く。業界のイベントでおなじみの基調講演者であり、エンタープライズ・ソフトウェアのオピニオンリーダーとして知られる。また、非上場企業や上場企業の選定、買収、統合における幅広い経験も持つ。米テキサス大学で電気およびコンピュータ エンジニアリングの理学士号を取得し、カーネギーメロン大学では情報ネットワーキングの修士号を取得した。
Google Cloud BrandVoice Paid program ー さあ、クラウドで解決しよう ー
https://forbesjapan.com/feat/googlecloud/
