お金では買えない競争優位性：MongoDBのApplication Data Platformでデジタルトランスフォーメーションを加速する #MongoDB #デジタルトランスフォーメーション #Application Data Platform
この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。
本ブログは「MongoDB」社のブログで2021年6月22日に公開された「Competitive Advantage Cannot Be Bought: Accelerating Digital Transformation With MongoDB's Application Data Platform」の日本語翻訳です。
ビジネスにおいて劇的な変革が起きるのは今に始まったことではありません。しかし、そのスピードは加速し、これまで以上に激しさを強めています。そしてその加速に拍車をかけているのが、グローバルレベルのパンデミックや政情の変化、気候変動など、現代の私たちを取り巻くさまざまな力です。
このような破壊的な力によって、企業の行動や消費者の期待に大きな変化が生じています。適応によるものであれ、イノベーションによるものであれ、ビジネスにおける変化について考える場合、その変化が結局は前の状況に戻ってしまうような一過性のものでないかどうかを問うてみることは価値があります。「おそらくその考えは正しくない」というのがほとんどのケースでの答えです。劇的な変革は今後も続いていくのです。
そのような状況は大手の企業にとっては脅威となる可能性があります。しかし、劇的な変革は停滞の対極に位置するものであると、MongoDBは確信しています。変化し、適応し、行動するための絶好の機会が訪れているのです。2020年には、多くの企業が、ビジネスの目標を達成するための方法を完全に見直さねばならなくなり、新たな戦略を早急に取り入れることに追われました。数年分のデジタルトランスフォーメーションを数か月で成し遂げねばならなくなったのです。
さまざまな企業が、新たな構造や柔軟性の高いモデルを開発しました。これらは人間のインナーマッスルのように、将来にわたって企業を支える存在となるでしょう。そして、デジタルトランスフォーメーションのペースは加速するばかりです。経済のデジタル化が進展するのに伴い、以下のような変化が生じています。
参入障壁の消滅：実際のところ、デジタルエコノミーでは、参入障壁は消滅しています。たとえば、フィンテックによる変革を検討している銀行の場合、地域間レベルで他行と競合するだけでは済みません。今や、世界各国に存在するモバイルファーストの新規参入銀行すべてが競争相手になるのです。競争におけるリスクはこれまで以上に大きくなっています。
継続的なイノベーションの実現が必須：競争力のきわめて高い企業は、自社のチームが拡張性と持続性に優れた手法で俊敏に行動できるよう、あらゆる障害の排除に血眼になって取り組んでいます。
重視されるデータのセキュリティ：クラウドに移行するIT環境が増え、グローバルに事業を展開する企業の数が増加するのに伴い、データのセキュリティとデータのプライバシーを最優先で考えることが必要になっています。現在も将来も顧客のデータをしっかり管理できる企業であると顧客に信頼してもらうことが不可欠になっているのです。
一方で、どの企業においてもデジタルトランスフォーメーションが成功しているとは限りません。多くの企業が新しい競合相手に太刀打ちできず、突然の市場の変化に追従できずにいるのです。
自社固有の競争優位性を確保する
今や企業が競争優位性を維持できるかどうかは、自社の最も重要な資産であるデータを中心としていかにソフトウェアの開発を上手く進められるか否かにかかっています。
1970年代初頭より企業は市販のソフトウェアを使用してきました。しかし今やこれまでとは事情が異なります。現在では、企業としての差別化と、社内開発のソフトウェアとが深く結び付いているのです。たとえば、既成のCRM製品を使っているような企業は業界では勝ち残ることはできません。つまり、競争優位性とは、お金を支払って外部から調達できるものではありません。開発を通じ、生み出す必要があるのです。
これは新しい考え方ではありません。最も基本的なソフトウェアでさえ、データを適切に保管、抽出、利用しないと、機能させることはできません。データをこのように扱えなければ、どんなソフトウェアも、見かけ倒しでまったく機能しないソフトウェアになってしまいます。最新のアプリケーション開発で本当に求められるのは、データをうまく取り出し、巧みに利用して真のイノベーションを生み出す技術やスキルです。
カスタマーエクスペリエンスと顧客の期待
スマートフォンとスマートデバイスの時代になってから約15年が経過しました。コンシューマー市場とB2B市場がデジタルインタラクションとデジタルエクスペリエンスに寄せる期待はきわめて高く、要求はひときわ厳しさを増しています。顧客はデジタルエクスペリエンスに次のような事柄を求めています。
高い応答性：デジタルエクスペリエンスにおいては、イベントやアクション、顧客の行動にすばやく応答することが求められます。
関連性の高い情報を提供できる：最新のデジタルエクスペリエンスでは、最も関連性の高い情報がインテリジェントに提示されます。消費者の考えがまとまる前に消費者が探そうとしている情報を予測することさえあります。
モバイルファースト：顧客が企業とやり取りする主要なルートはモバイルになります。デスクトップ環境なら可能なあらゆる事柄をモバイルデバイスでも実現できるようにしたいと顧客は望んでいます。
データのプライバシーを維持できる：顧客はデータのプライバシーが完全に確保されることを望んでおり、必要に応じてデータの管理を顧客自身に許可するよう、企業に求めています。
リアルタイムアナリティクスを利用できる：顧客が求めているのは、スマートなアプリケーションです。上記のすべての内容に加え、消費者が求めているのは、アナリティクスをベースとしてリアルタイムに提供されるリッチなエクスペリエンスを通じて、アプリがガイドとなり、安心を約束し、満足度を高めてくれることです。
継続的なエクスペリエンスの向上：顧客は、従来よりもスピード感のあるエクスペリエンスの向上を望んでいます。
デジタルトランスフォーメーションで課題となるレガシーのインフラストラクチャ
企業が顧客の期待に応えられるかどうかは、ほぼ完全に企業の基盤データインフラストラクチャに依存します。このインフラストラクチャは、企業のテクノロジースタック全体を支える土台の役割を果たします。最新のデジタルエクスペリエンスを実現するには、データの保存、処理、利用の用途に対応する最新のデータインフラストラクチャが必要です。
企業が最善の努力を尽くし、大がかりな投資を行っても、70%以上の企業はデジタルトランスフォーメーションの取り組みに失敗するとの意見があります。このような憂慮すべき数字を見ると、デジタル化による改善はギャンブルで実施する価値はないと思われるかもしれませんが、絶対にそんなことはありません。
実際に何が起こっているのかと言えば、データを利用して最新のアプリケーションを開発する方法が変わっているというのに、標準のデータインフラストラクチャがさまざまな要求に応えられず、アプリケーションの開発や機能強化において、データを使った作業がきわめて困難になっているのです。
主な要因の1つは、標準のデータインフラストラクチャがまだレガシーのリレーショナルデータベースを中心に構築されていることにあります。このような次代遅れのインフラストラクチャは次のような影響をもたらします。
硬直性：リレーショナルデータベースを定義する列と行の硬直性のために、アプリケーションのテストやイテレーションが難しくなります。また、アプリケーションの機能を強化したり、アプリケーションに新しいタイプのデータを取り込んだりするときには必ずデータモデルやスキーマの変更が必要になるため、開発者はデータレイヤーの依存関係を考慮しなければならず、さらには、リレーショナルデータベースの脆性がそのような変更作業を困難にしています。
データ構造の対立：テーブル形式のリレーショナルデータ構造はほとんどの開発者の思考やコーディング手法と相容れません。開発者が使用しているのはオブジェクト指向のプログラミング言語なのです。簡単に言えば、開発者の頭の中には、列や行といった概念は存在しないのです。それは、開発者が扱っている最新のデータやオブジェクトと対立する概念です。
自動フェイルオーバーや水平スケーリングがネイティブでサポートされない：自動フェイルオーバーや需要に応じた大規模なスケーリング機能をはじめとする、最新のアプリケーションに必須の要素がレガシーのリレーショナルデータベースにはネイティブで組み込まれていません。この問題は前の課題以上にさらに克服が困難な障害となっています。
リレーショナルデータインフラストラクチャを何年も使用している組織には通常、数十万に上るテーブルが蓄積されています。リレーショナルデータインフラストラクチャでのアプリケーションの開発やイテレーションでは、そのようなテーブルを更新したり、解読したりしなければならないため、イノベーションの取り組みは遅々として進まず、場合によっては完全に停止してしまいます。
たとえば、米国を拠点にするFortune 500企業の保険会社、Travelersは最近、アンダーライティングアプリケーションの刷新を試みました。同社で最も利益を上げている事業保険部門では、もっと迅速なソフトウェアの展開とより応答性に優れたシステムを必要としていました。同社は標準のソリューションでこの問題を解決しようとしました。アジャイル開発の導入や、マイクロサービスによるモノリスの細分化、継続的デリバリーの展開などを実施したのです。しかし奮闘むなしく、レガシーのリレーショナルデータベースが原因で、プロジェクトは失敗しました。
当時、Travelersでアーキテクチャ担当シニアディレクターを務めていたJeff Needham氏はこのトランスフォーメーションの試みについて次のように述べています。「最終的には、レガシーのデータベースが残ることになりました。作業をすべて完了したというのに、データベースの更新作業が実施されるのを何日も待たねばなりませんでした」。Travelersはプロジェクトに失敗し、その後もフラストレーションを募らせることになりましたが、自身のデータインフラストラクチャの罠にはまった多くの組織が、Travelersとまったく同じ経験をしているのです。
NoSQLとは何か
最新のアプリケーション環境の実現やよりスピード感のある運用を必要としているチームにとって、リレーショナルシステムの欠陥を補う対策として道筋のはっきりした対処法は、NoSQLデータストアの導入のように思われますが、これを実現するにはETL（あるソースからデータを抽出して別のソースへ転送し、別のソースでロードすること）が必要であり、データ管理もより複雑になります。非リレーショナルデータベースであるNoSQLデータベースが限られた特定の目的だけにしか有効でないことはすぐにわかります。また、NoSQLデータベースには、それ以外にも、クエリ機能が制限されたり、データの一貫性が保証されなかったりするなどの機能制限があります。
実は、NoSQLデータベースが適切なユースケースはニッチなものに限られるため、NoSQLデータベースでリレーショナルデータベースを完全に置き換えることはできません。そして、最終的には、データベースに加え、管理機能も必要になります。しかも、グラフデータとトラバーサル用に1つ、時系列の管理に1つ、キーバリューに1つなどといったように、複数の管理機能が必要です。多様化するデータワークロードに対応することがますます求められるようになっており、データの分断が進んでいます。つまり、どのタイプのデータにも対応できるマネージド型の新しいデータベースが必要になっているのです。
リレーショナルデータベースの欠陥を補うためにNoSQLデータベースを追加すると、データ環境はこれまで以上に複雑になります。この点が重要です。
オペレーションデータベースの限界
今日の組織におけるアプリケーションデータインフラストラクチャは、複数のオペレーションデータベースから構成されています。
検索機能を充実させるために、多くの組織では、別の検索エンジンテクノロジーを環境に追加していますが、この結果、組織のチームには、システム間を移動するデータの管理の負荷が生じています。
また、モバイルデバイスにおいて低遅延とオフラインファーストのアプリケーション環境を実現するために、個別のローカルデータストレージテクノロジーを導入していることも少なくありません。デバイスのデータをバックエンドと同期するのも、開発者にとっては厄介なタスクになります。ネットワーク処理のコードを記述したり、競合を解決したりするなどの複雑な作業があるからです。
さらには、豊富なアナリティクス機能に対応するアプリケーション環境を構築するために、多くの組織がETLを使用しており、まったく別のアナリティクスデータベースを用意する過程でデータを再フォーマットしています。
データインフラストラクチャでは今、ある問題が深刻になる一方です。無秩序にインフラストラクチャの複雑さが増しているのです。あらゆる段階において、この問題に対処するために多くの時間や人員、費用が費やされており、製品のイノベーションに使えたはずの開発サイクルを浸食しています。
イノベーションの足かせとなるスパゲッティアーキテクチャ
新しいコンポーネントやサービス、テクノロジーを追加してデータの問題を解決しようとする中で、多くの企業は自らが「スパゲッティアーキテクチャ」の罠にはまっていることに気付きます。すでに鈍重になっているインフラストラクチャの上に過剰に複雑で相互に連携しない複数のアーキテクチャを積み重ねているのです。
どんな断片的なテクノロジーでも、運用、セキュリティ、パフォーマンスの観点から見て思いもよらないことが起こる可能性があります。そのため、その扱いでは専門的な知識が必要になり、注意を払う必要があり、データの統合が難しくなるのです。システム間でデータを移動するときには、専任の担当者やチームを割り当て、費用を個別に用意しなければなりません。また、膨大な量のデータを複製する場合は、大がかりなリソースが必要です。データを分散させるときに対象のシステムの種類が多岐にわたる場合には、単にコストがかかるだけでなく、複数の運用モデルやセキュリティモデルを扱うための開発リソースも準備しなければなりません。
こうなると、高い拡張性や持続性を維持しながらイノベーションを実現するのはきわめて困難になります。実際のところ、このような要因が影響して多くのデジタルトランスフォーメーションが失敗しています。不完全なデータインフラストラクチャが生まれ、リソースが枯渇し、「ソリューション」のせいでさらに複雑さが増してしまうのです。そしてその間はずっと、競合他者に後れを取ることになります。
MongoDBでは、これらすべてを、データインフラストラクチャの問題が拡大することに紐付いて繰り返し発生する、イノベーションに課された一種の税と捉えており、DIRT（Data and Innovation Recurring Tax、データとイノベーションに関する経常税）と呼んでいます。DIRTは自然に消滅することがないため、繰り返し発生します。そのままでは、現在も、将来も、今から5年が経過しても、大きな重荷であり続けます。正面から対峙して問題の解決を図らない限り、DIRTは重荷となり続けます。
DIRTを解消する
DIRTが問題となるのは間違いありません。同時にこれを解決する現実的な対策があるのも確かです。大きな成果を上げている先進の組織は、以下に示す4つの重要な指針を重視してデータインフラストラクチャを構築し、あらゆる複雑な要素を排除しています。
- 開発者の生産性を倍増する：自社の開発者が業界トップレベルのアプリケーションを開発できるかどうかに、企業の成功は左右されます。そのため、成功を収めている企業は、硬直的なデータ構造、断片化した開発環境、バックエンドのメンテナンス作業といった、生産性を損なうあらゆる要素を排除することに、優先して取り組んでいます。
- シンプルで繰り返し利用できるアーキテクチャの構築を優先する：データの整合性を維持できる組織は、運用環境を複雑するだけの前に述べたようなデータインフラストラクチャやテクノロジーがもたらすコストを理解しています。このような企業は本当に必要なときにだけニッチなテクノロジーを使用しています。
- セキュリティとデータのプライバシーの確保を意識する：成功を収めている企業は、データのセキュリティやプライバシーを個別の巨大なプロジェクトで扱うようなことはしていません。このような組織は、簡潔さを損なわず、開発環境を犠牲にすることもなく、緻密な要件を満足しています。
- マルチクラウドを活用する：マルチクラウドを活用している企業は、環境の柔軟性で妥協をしていません。このような企業はデータグラビティの影響を受けることがなく、コードを書き換えたり、計画に何か月もの期間を費やしたりしなくても、複数のリージョンや複数のクラウドへグローバルに単一のアプリケーションを展開できます。
MongoDBのメリット
MongoDBが提供するアプリケーションデータプラットフォームでは、データを使ってさまざまな用途の開発を行う際に、作業のスピードを速め、作業を簡素化します。MongoDBを利用すれば、労力をかけずにデータインフラストラクチャを最適化できるので、イノベーションの取り組みに資源を集約することが可能になり、独自の差別化機能の開発や、DIRTの解消も実現できます。
MongoDBのドキュメントモデルは柔軟性が高く、開発者の思考やコーディング手法にマッチ：柔軟性に優れたドキュメントデータモデルでは、アプリケーションの要件の変更に合わせてデータのモデル化や再モデル化が容易に可能です。列や行の概念に悩まされることがないので、開発の生産性が向上します。ドキュメントは、開発者がコーディングで使用するオブジェクトの概念と正確にマッチします。これは、MongoDBの創設者が10年以上前から考えていたコアとなるインサイトです。本質的にデータシステムには、最新の環境に適合できるデータモデルが個々に必要なのです。この点を考えると、開発者がMongoDBを高く評価し、7,500万以上もMongoDBがダウンロードされていることも納得できます。
他のあらゆるデータモデルとの上位互換性を確保：MongoDBのドキュメントモデルはレガシーの機能と上位互換性があるため、ユーザーはさまざまなタイプや形状のデータを保存および操作することが可能です。ニッチなデータベースとは対照的に、MongoDBのドキュメントモデルでは、レリレーショナルデータやオブジェクト、キャッシュフォーマットのニーズに加え、GISデータタイプや時系列データなどの特殊データのニーズにも対応しています。ドキュメントデータベースは、現在利用されている数多くある他のデータベースとは一線を画しています。時代の最先端を走る組織は、ドキュメントモデルが広範なユースケースを支える役目を果たすものであることに気付いています。
たとえば、最もシンプルなドキュメントは、キーと値のペアのように機能します。ドキュメントはグラフのノードやエッジとしてモデル化することが可能です。ドキュメントを利用すれば、埋め込み構造やネスト構造をサポートする関係性を直感的にモデル化できます。また、ドキュメントデータモデルは、さまざまな種類のデータを扱う場合に最適であり、具体的には、MongoDBが開発基盤になります。
機能豊富で表現豊かな統合インターフェイスを提供：開発者は、ワークロードごとにデータの扱い方法を調査したり、学習したり、その最新情報を入手したりする必要がないので、生産性が向上します。プログラミング言語の拡張機能のように利用できるため、SQLよりもずっと自然な開発環境が実現します。
個々のプログラミング言語やパラダイムに合わせた固有の環境が提供され、開発者はネイティブのフォーマットでMongoDBドキュメントを確認することができ、データを直接操作できます。オブジェクト関係マッパー（ORM）やデータベース抽象化レイヤー（DAL）などの抽象化レイヤーは必要ありません。データは簡単に削除や取り消しが可能です。さらには、C#やJava、C++などの別々のプログラミング環境で別々に作業を進めている複数のチームが個々の都合に合わせて共通のデータを利用できるので、データドメインの簡素化と統合が可能になります。
アプリケーションデータプラットフォームとしてのMongoDB
MongoDBは単なるデータベースではありません。MongoDBは、多目的の用途に対応する多面的なアプリケーションデータプラットフォームです。つまり、さまざまな形式のデータや、さまざまな方法での処理、保存、トレーニングなどが必要なデータを、あるいは、同じくさまざまな方法で規制、監査、暗号化、保護が必要なデータを、MongoDBは認識できるのです。
データは、企業が保有する、きわめて価値の高い、きわめて複雑な資産の1つです。MongoDBでは、数多くのさまざまユースケースを簡素化し、インテリジェントで洗練された手法を通じてこの重要な資産を活用します。最新のアプリケーションが生成するデータを操作可能な統合インターフェイスもその手法の1つです。
MongoDBには、ドキュメントモデルと統合クエリAPIという、基盤となる2つの概念があり、これらをオペレーションデータベースとトランザクションデータベースの形態に統合しています。MongoDBのアプリケーションデータプラットフォームの機能や特長には、以下のようなものがあります。
トラザクションデータベース：MongoDBには、リレーショナルデータベースを補完するだけでなく、リレーショナルデータベースを置き換えるために必要なトランザクションの保証機能とデータガバナンスの機能が搭載されています。分散型のマルチドキュメントトランザクションは、ACIDに完全に準拠しており、コアのミッションクリティカルなアプリケーションを背後で支えるトランザクションデータベースを構築できます。
検索機能：完全統合型のフルテキストサーチで、個別の検索エンジンを不要にします。MongoDBプラットフォームには、拡張クエリAPIなどの、統合型の検索機能が搭載されているため、アプリケーションの検索機能を有効にするのに、開発者は専用の検索エンジンを構築する必要がありません。データの移動を含むすべてのオペレーションは、MongoDBプラットフォーム内でネイティブに処理されます。
モバイル対応：MongoDB Realmの柔軟性の高いローカルデータストアには、エッジとクラウドをシームレスに同期する機能が実装されているため、モバイルとエッジのコンピューティングを同期できます。MongoDB Realmの開発環境は、最低限のコードを記述するだけでバックエンドとフロントエンドでデータを同期でき、自然な感覚で利用できるので、モバイル用アプリの開発スピードを加速できます。競合を解決したり、ネットワーク処理のコードを記述したり、機能を連結したりする作業はすべて自動的に処理されます。
リアルタイムアナリティクス：MongoDBでは、ワークロードの分離とネイティブでのデータの可視化が可能なリアルタイムアナリティクス機能を提供します。MongoDBでよりスマートなアプリケーションを開発する組織が増えるのに伴い、機械学習の機能やダイレクトアプリケーション環境と連携するリアルタイムアナリティクスの機能が求められるようになっています。
データレイク：MongoDBでは、フェデレーションクエリを実行できるため、オペレーションデータベース、トランザクションデータベース、クラウドオブジェクトストレージにまたがる照会が可能です。複数のクラスターを対象とした照会やMongoDBの外部にあるデータの照会もできます。MongoDBのアーキテクチャでは、必要に応じ、分析のためにデータのフェデレーションや集約が可能です。
持続性のあるプラットフォーム：現実の世界では、プラットフォームにセキュリティやレジリエンス、拡張性の問題があると、アプリケーションの機能は意味をなさなくなってしまいます。市場の変化や製品需要の変化に対応して進化できるのは、持続性の高いフレームワークだけです。
拡張性とコンプライアンス：MongoDBではすべてが分散型のシステムアーキテクチャをベースに構築されており、すぐに利用できるグローバル対応のデータ分散機能が提供されます。この機能を利用すれば、データ主権を確保でき、データへの高速なアクセスが可能です。この機能は、ワークロードの拡大に対応する水平スケーリングやリニアのコスト経済性を実現するほか、グローバル対応のアプリケーションのためにデータを分散し、関連性の高いデータをユーザーの近くに配置する場合にも役立ちます。必要に応じて地理的に異なる複数の場所にデータを分散して遅延を抑制するなどの対応が可能です。また、MongoDBでは、国別にデータを分離することも可能です。この機能は、データ主権の要件に対応するうえで有用です。
セキュリティ：MongoDBには、業界トップクラスのデータプライバシー管理機能が搭載されており、クライアント側やフィールドレベルで暗号化を実施するほか、データベースの中枢にセキュリティ機能を組み込んでおり、ストレージの暗号化や、ロールベースのアクセス管理、エンタープライズグレードの監査機能を利用できます。サードパーティのプロバイダーが関係することの多い環境では、これらのセキュリティ機能でエンドユーザーの管理を厳格に行えば、サードパーティプロバイダーが機密性の高いデータにアクセスするのを確実に防ぐことができ、セキュリティ侵害の発生を完全に抑えられます。
マルチクラウド：MongoDBは、クラウドの約80のリージョンに柔軟に展開できます。データベースを複数のクラウドにわたって展開すれば、特定のプロバイダー固有の革新なサービスを利用することや、複数のクラウドにまたがりレジリエンスを確保することが可能になります。また、リージョンごとに別々のデータベースを構築しなくてもサービスの利用地域を拡大できます。さらには、複数のデータワークロードで開発環境を統一したり、運用モデルやセキュリティモデルを簡素化したり、サービス間のデータの移動を自動化したり、移動の透明性を確保したりできるほか、データが複製される懸念を減らすことも可能です。
