急速に進化する今日のデジタル環境において、組織は変化するビジネスニーズに対応するためにレガシー アプリケーションをモダナイズするという絶え間ない課題に直面しています。 アプリケーションのモダナイゼーションは、運用効率の向上、カスタマーエクスペリエンスの向上、競合他社の一歩先を行くためには不可欠です。 Microsoft Power Platformは、企業がアプリケーションを迅速かつ効果的に変換および最新化できるようにする、包括的なツールとテクノロジのスイートを提供します。
この記事では、Microsoft Power Platformを使用してアプリケーションを最新化する利点、戦略、ベスト プラクティスについて説明します。 この資料では、組織のデジタル変革の一環として、Microsoft のローコード プラットフォームがアプリケーションのモダナイゼーションの取り組みを成功に導くためにどのように役立つかについての分析情報とガイダンスを提供しています。
概要
レガシーアプリケーションは、組織に多くの課題をもたらします。 これらのアプリケーションは、時代遅れのテクノロジー スタックやフレームワーク上に構築されていることが多く、最新のシステムやツールとの統合が困難です。 多くの場合、スケーラビリティとパフォーマンスの制限があり、組織が増加するワークロードと顧客の要求を処理する能力を妨げます。 レガシー アプリケーションは柔軟性と俊敏性に欠けており、変化するビジネスニーズや市場動向に迅速に適応する能力を制限しています。 セキュリティの脆弱性、高いメンテナンス コスト、限られた統合機能、ベンダー依存のリスクが、レガシーアプリケーションの課題をさらに悪化させています。 これらを克服するために、組織はアプリケーションのインフラストラクチャをモダナイズして新しいテクノロジーを活用する必要があります。
Microsoft Power Platformの低コード開発機能により、最新のアプリケーションをこれまで以上に迅速かつコスト効率の高い方法で構築およびデプロイできます。 既存のシステムやデータソースを簡単に統合して、シームレスなデータ交換とコラボレーションを実現します。 人工知能を追加することで、ユーザー エクスペリエンスの向上、プロセスの自動化、データからの貴重な分岐情報の取得が可能になります。 さまざまな作業に追われている市民開発者でも、複雑なカスタマイズに取り組んでいるプロ開発者でも、従来のアプローチよりも直感的、迅速、低コストでデジタル トランスフォーメーションを推進できます。
なぜ Power Platform なのか？
Power Platform を構成する包括的なツールやテクノロジーは、モダナイゼーションやデジタル トランスフォーメーション プロジェクトの期間、コスト、開発要件を劇的に削減します。 そのローコード アプローチは、高価なコーディング、データサイエンス、AI エンジニアリング リソースの必要性を減らし、さらには排除することができます。 市民開発者もプロ開発者も同様の恩恵を受けます。 市民開発者は、その専門知識に基づいて直接アプリケーションを構築し、ITチームへの依存度を低減することで、モダナイズのプロセスに積極的に関与することができます。 プロの開発者は、複雑なソリューションでもはるかに短い時間で提供できるため、次のプロジェクトにすぐに進むことができます。
Power Platform 製品とコンセプト
Power Platform ファミリーの各製品には、独自の重点分野があります。 組織は、特定の要件を満たすために、製品を個別に、または組み合わせて実装できます。 製品は相互に関連しており、シームレスな全体を形成しています。
次の表は、各 Power Platform 製品の概要を示したものです。
| 製品 | 説明 |
|---|---|
| Power Apps | 直感的なドラッグ アンド ドロップのキャンバスでカスタム アプリケーションを作成します。 1,000 を超えるコネクタがあるため、内部/外部のデータ ソースとサービスに数回クリックするだけでアクセスできます。 アプリはブラウザ、デスクトップ、モバイル デバイスで実行できます。 |
| Power Automate | ワークフローを構築して、複雑なプロセスも自動化します。 組み込みコネクタとカスタム コネクタを使用して、内部/外部のデータ ソースとサービスを組み込みます。 アプリケーションにアプリケーション プログラミング インターフェイス (API) がある場合は、デジタル プロセス オートメーション (DPA) を使用します。 ロボティック プロセス オートメーション (RPA) を使用して、ブラウザーまたはデスクトップ アプリで実行される反復的なタスクを自動化します。 他のシステムやサービスでイベントが発生した際にワークフローをトリガーして実行したり、特定の時間に実行するようにスケジュールしたりできます。 |
| Copilot Studio | ノーコードのグラフィカル インターフェースを使用した会話エージェントの作成。 エージェントは、Web サイト、モバイル アプリ、Microsoft Teams などのメッセージング プラットフォームなど、複数のチャネルにデプロイできます。 AI 支援による作成により、トピックの作成を高速化できます。 生成型の回答では、トピックを作成しなくても、複数のソースから情報を検索して提示できます。 |
| Power BI | グラフ、表、その他のビジュアルをキャンバスにドラッグするだけで、データ内に隠れている分析情報を明らかにする洗練されたレポートを簡単に作成できます。 予測モデリングのための自動機械学習と、詳細な根本原因分析ドリルダウンのための分解ツリーによる AI の視覚化が含まれます。 簡単な Q&A 形式で自然言語の質問をして、データを探索します。 |
| Power Pages | 安全なエンタープライズグレードのローコード SaaS (サービスとしてのソフトウェア) プラットフォーム上で、魅力的なデータ駆動型の Web サイトをすばやく構築します。 豊富でカスタマイズ可能なテンプレートと流動的なビジュアル エクスペリエンスにより、最新の外部向けビジネス Web サイトの作成、ホスティング、管理が簡単になります。 |
Power Platform の製品ファミリは、いくつかのサポート機能とコンセプトに依存しています。 次の表では、理解しておくべき最も重要なものについて説明します。
| 概念 | 説明 |
|---|---|
| Power Fx | Power Fx は Excel の数式にインスパイアされたオープンソースのローコード言語です。 厳密な型指定、宣言型、関数型、命令型ロジックと状態管理、そのすべてが人間にやさしいテキストで表現されているため、Power Fx は市民開発者にもプロ開発者にも、一般的なプログラミング作業を簡単にします。 プログラミングをしたことがないユーザーに向けたノーコードから、熟練したプロフェッショナルのための「プロコード」まで、開発の全領域をサポートし、多様なチームが協力して時間と費用を節約できるようにします。 |
| コネクタ | コネクタは、ローコードと従来のコーディングを連携させて最新のアプリを提供するために不可欠です。 コネクタは、Power AppsとPower Automateが内部および外部のデータ ソースとサービスを使用できるようにする API のラッパーです。 1,000 を超える構築済みコネクタが使用可能であり、任意の RESTful API 用に独自のコネクタを作成できます。 コネクタ定義には、ローコード アプリで API を簡単に使用できるようにするために必要なメタデータが含まれています。 |
| Dataverse | Dataverse は、Azureデータ管理サービスに基づいて構築されたクラウド規模のハイブリッド データ ストアですが、データベースを超えています。 これは、Dynamics 365と Power Platform の両方の基になるデータ プラットフォームであり、ワークフローとプラグインの形式のサーバー側ロジック、ビジネス ルールとプロセス フロー、高度に洗練されたセキュリティ モデル、および多言語アプリと複数通貨アプリの組み込みサポートを備えた拡張可能な開発プラットフォームを備えています。 アプリケーションはデータ モデルから素早く構築できるため、フォーム オーバー データ ソリューションを展開する最速の方法のひとつです。 |
| AI Builder | AI Builderを使用すると、Power AppsとPower Automateで人工知能を簡単に使用して、データ内の分析情報を見つけ、プロセスを自動化し、アプリの生産性を高めることができます。 AI Builderでは、AI の力にアクセスするためにコーディングやデータ サイエンスのスキルは必要ありません。 事前構築済みの構築されたカスタマイズ可能なモデルは、多くの一般的なビジネス シナリオに対応しており、すぐに利用できます。また、特定のビジネスニーズを満たす独自のモデルを構築することも可能です。 |
| Copilot | Copilot AI の支援により、Power Platform のユーザーと開発者、市民、またはプロの生産性が向上し、ジョブの最適な部分に多くの時間を費やしたり、日常的なタスクにかかる時間を短縮したりできます。 Power AutomateのCopilotにビジネスシナリオを説明すると、その説明が自動化されたワークフローに変換されます。 Copilot Power Appsで、何を行うか、表示する情報を伝え、アプリを構築できます。 Copilot接続の設定、テーブルの作成と設定、画面の生成、フローやアプリの改善に関する提案も提供します。 アプリには最初の画面から Copilot を活用した体験が組み込まれているため、ユーザーは会話を通じて分析情報を発見できます。 |
| 環境とソリューション | 環境とは、Power Platform リソースの管理と保護を容易にする境界を意味します。 また、運用環境に展開する前にソリューションを別々の環境で開発/テストする、アプリケーション ライフサイクル管理 (ALM) でも使用されます。 ソリューションは、Power Platform のカスタマイズや拡張機能としてパッケージ化されています。 ソリューションには、アプリ、フロー、テーブル、グラフ、ダッシュボード、コネクタ、およびカスタマイズや拡張機能に必要なその他のコンポーネントを含めることができます。 ソリューションは、組織の ALM ポリシーの一部として、開発、テスト、運用環境への個別の環境への展開を行うことができます。 ソリューションをエクスポートして他のユーザーや組織と共有したり、他のユーザーからソリューションをインポートしたりできます。 ソリューションにはマネージド型とアンマネージド型があります。 アンマネージド ソリューションは、開発とテストに使用されます。 マネージド ソリューションは、運用環境の展開と配布に使用されます。 |
アプリのモダナイゼーションにおける Power Platform の主な利点
Microsoft Power Platformを使用してアプリケーションを最新化する利点は、最新のテクノロジを使用するソリューションを持つことの初期ビジネス価値を超えています。
コストの削減。 組織は、アプリの開発とメンテナンスにかかるコストを節約できます。 Forrester Consulting 社の委託調査によると、Power Platform を使用する組織は、アプリケーション開発コストを 45％ 削減し、140％ の投資収益率を実現できることがわかりました。
リソース プールを拡張し、ボトルネックを解消します。 プロの開発者、データ サイエンティスト、AI エンジニアは高給で、高い需要があります。 中小規模の組織では、社内にコーディングの専門知識を持つ人材を確保する余裕がないことが多く、また、アウトソーシングも高額です。 ローコード Power Platform は、より多くの人々にとって利用しやすくなっています。 業務プロセスに精通した専門家や従業員は、たとえコードを一行も書いたことがない場合でも、モダナイゼーションの取り組みを加速させることができます。
車輪を作るのではなく、台車を作ります。 従来のソフトウェア開発は、毎回最初からやり直し、新しいプロジェクトごとに車輪の再発明を行います。 ローコードで直感的な、メーカー フレンドリーな Power Platform 製品を車輪として使用することで、より優れたカートの構築、つまりビジネスプロセスの改善に集中することができ、モダナイゼーション努力のメリットをより早く享受することができます。
技術的負債を削減します。 手間をかけないなソフトウェア ソリューションのアップグレードやレガシーなインフラストラクチャの維持には、財政的にも機会損失としても大きなコストがかかります。 Power Platform は、ソリューションの構築を簡単かつ低コストで実現し、共通のデータモデルとコネクターによってデータ統合とガバナンスを簡素化し、ソリューションを管理するための一元化されたプラットフォームを提供し、アナリティクスと AI によって継続的な改善をサポートすることで、このような技術的負債を軽減します。
セキュリティの強化とコンプライアンスを徹底します。 すべての Power Platform 製品には、エンタープライズグレードのセキュリティ、コンプライアンス、ガバナンスが完全に統合されており、既成の環境から実行できます。 マネージド環境は、管理者がよりコントロールしやすく、より少ない労力で Power Platform を大規模に管理することを可能にする一連のツールです。 特に、どのフローやアプリを誰と共有できるユーザーを制限したり、ポリシーを使用して作成者が使用できるコネクタを制限したりできます。 ネイティブで柔軟なデータセキュリティ モデルにより、各アプリケーションが独自に構築する必要がありません。
進行しながらモダナイズする。 最新化するアプリの重要性が高いほど、それらをすべて一度に置き換える可能性は低くなります。 ローコード アプローチは、管理しやすい増分でソリューションを構築する場合に適しています。
レガシーアプリと統合します。 古いアプリケーションには、多くの場合 API がありません。 Power Platform の RPA 機能は、古典的なアプリケーションを自動化し、新しいモダンなビジネス プロセスに組み込むことができます。 RPA は、大規模で複雑なアプリを段階的に最新化するのにも役立ちます。
コストをかけずに革新を実現しましょう。 Power Platform の機能は向上し続けています。 プラットフォーム上に構築されたアプリは、コストをかけずに Microsoft イノベーションの恩恵を受けることができます。
現代の職場で従業員の生産性を向上させます。 Power Platform はマイクロソフトのモダン ワークプレイスの一部です。 プラットフォームで最新化されたアプリケーションでは、魅力的なモバイル エクスペリエンスや簡単で直感的なコラボレーションなど、Microsoft 365の機能を活用できます。 Copilot、AI Builder、機能などの最先端の AI は、すぐに発表される予定です。これにより、ユーザーと開発者の生産性が向上し、ストレスが軽減され、学習曲線が浅くなります。
現場労働者のためのイノベーション
現場担当者は、どこで働いていても、どのデバイスでも使用できる最新のアプリケーションを必要としています。 より良い意思決定をより迅速に行うために、リアルタイムで分析情報にアクセスする必要があります。 彼らは、すべてを円滑に機能させるために、同僚や経営陣と協力する必要があります。 アメリカン航空が運航の一部を近代化することを決定した際、彼らはそれ以上のものを得ました。
マイクロソフトと提携して、アメリカン航空はConnectMe、Power AppsとAzure上に構築されたMicrosoft Teamsアプリを作成しました。 モバイル端末でアプリを使用することで、現場チームは到着、搭乗、手荷物、ゲートに関する重要な情報をリアルタイムで入手でき、地上業務を効率化し、航空機の回転時間を短縮し、お客様の旅をより快適なものとすることができます。 航空会社の変革についての詳細をご覧ください。
ナレッジ ワーカーのための AI エンパワーメント
ナレッジ ワーカーはデータの海を泳いでおり、溺れているように感じることが多すぎます。 ほとんどすべてのアプリケーションがデータを収集します。 ユーザーが収集したデータを理解するのに役立つものはほとんどなく、ましてや労働者の仕事の改善に役立つ可能性のある洞察を引き出すことはほとんどありません。 最新化の一環として AI 機能をアプリに追加することで、データの収集と分析を自動化するだけでなく、ナレッジ ワーカーがパターンや傾向を見つけやすくすることができます。 予測分析では、AI モデルを使用して、履歴データに基づいて将来の結果を高精度で予測できるため、リーダーは自信を持って計画を立てることができます。 モダナイズされたアプリには コパイロット AI が含まれており、インタビューの要約、ターゲットを絞ったマーケティングおよび販売メッセージの作成、さらには顧客サービス担当者や営業担当者が顧客との電話中にリアルタイムで役立つ情報を提供するなど、コンテキストに沿ったコンテンツを生成するパートナーとして機能します。
レガシ アプリをモダナイズするための段階的な取り組み
ほとんどの組織がそうであるように、モダナイゼーションの恩恵を受ける古いアプリケーションのバックログが増えています。 レガシ アプリケーションは通常、時代遅れのテクノロジーを使用しており、サポートされなくなったインフラストラクチャ (ハードウェアとソフトウェア) 上に構築されています。 多くの場合、その仕組みを知っているのは数人の従業員、たいていは定年間近の従業員だけです。 新しいスタッフは、自身が慣れ親しんだ、あるいは使いたがっている最新のツールを使えないので、関わりたくないのです。 更新はおろか、維持するには技術的負債の山を登る必要があり、登れば登るほど高くなります。 何年、何十年にもわたるパッチワークのメンテナンスの結果、特にビジネスの大部分がそれに依存している場合、誰もあえて触れないコード ベースができあがります。
多くの場合、組織はこれらのアプリケーションをすべて一度に簡単に置き換えることはできません。 代わりに、段階的なモダナイゼーションの旅に乗り出します。 漸進的なアプローチにより、最新化の利点を最大化すると同時に、一回限りの最新化作業によるリスクを軽減することができます。
アプリを最新化するためのオプション
モダナイゼーションとは、必ずしもレガシー アプリをゼロから再構築することを意味するわけではありません。 その他のオプションとしては、廃止、置換、再ホスト、リファクタリング、再設計があります。
次の表では、各オプション、最適な場合の ALM ステージ、その選択に影響を与える可能性のあるドライバーについて説明します。
製品寿命終了
移行
最新化
Retire
取り替える
Rehost
Refactor
Rearchitect
Rebuild
説明
アプリの削除
アプリを SaaS または別のアプリに置き換える
そのままクラウドに再展開する
既存のコードを最適化する
コードを新しいアプリケーション アーキテクチャに移行するか、マイクロサービスに分割します
元のスコープと仕様でアプリをゼロから書き直す
ドライバー
不要になりました
経費の削減
資本経費の削減
新しいテクノロジーを活用する
資本経費の削減
データ ストレージの回復
迅速なクラウド ROI
より速く、より短い更新
よりポータブルなコード
リソース、スピード、コストにおけるクラウド効率の向上
パフォーマンスの向上
技術的負債を削減する
スケーラビリティ、信頼性、保守性の向上
新しいクラウド機能の導入の容易化
ミックス テクノロジー スタック
イノベーションの加速
開発の迅速化
営業費用の削減
Microsoft のテクノロジー
Power Apps
Dynamics 365
Azure IaaS
AZURE VMWare
Power Platform
Containers
Azure PaaS
Power Platform
Azure PaaS
サーバーレス マイクロサービス
Power Platform
Azure PaaS
サーバーレス マイクロサービス
次の表は、ローコード アプローチを各アプリの最新化オプションに適用する方法を示しています。
| オプション | 説明 |
|---|---|
| Rehost | リホストでは、アプリを古い環境から新しい環境にそのまま移動します。 ローコード アプローチは直接適用されませんが、リホスティングは、ローコード ソリューションを含む他の戦略を適用する前の最初のステップとなる可能性があります。 |
| リファクタリングまたはアーキテクチャの再設計 | リファクタリングでは、アプリがクラウドファースト環境から最大限のメリットを得られるようにコードを微調整します。 再設計では、コードが大幅に変更されます。 これには、コネクタを介してローコード ソリューションに公開できる API に移動することで、既存のロジックをカプセル化することが含まれる場合があります。 |
| 交換または再構築 | 置き換えると、アプリが別のアプリと入れ替わります。 リビルドでは、アプリをゼロから再作成します。 このオプションは、ローコード アプローチが最高のビジネス成果を達成する場合によく使われます。 Dynamics 365または Microsoft Marketplace からアプリケーションを開始すると、ユース ケースが事前構築済みの機能と一致する場合に、最新化をすぐに開始できます。 組織は、Power Platform のコンポーネントを使用して、独自のニーズに合わせてアプリをカスタマイズすることができます。 |
Power Platform のローコード アプローチは、単なる開発ツール以上のものを提供する可能性を秘めています。 ロー コードを最新のアプリ戦略の一部にすることで、対象分野の専門家など、開発者以外の人がモダナイゼーションの取り組みに参加するための基盤を確立することもできます。 組織は、Power Platform に関するセンター オブ エクセレンス (CoE) を確立し、ガイドラインとガバナンスを作成する CoE スターターキットのようなツールを使用することで、ユーザーがローコード アプリやオートメーションを成功裏に構築し、API やコンポーネントのような資産を再利用できることに気付きました。 ロー コードは、アプリケーション開発を加速し、データがどこにあるかに関係なく、組織がデータからより迅速に価値を引き出すのに役立ちます。 実際、多くの組織は、ロー コードの考え方を企業文化に統合することを決定しています。
モダナイゼーション ジャーニーのガイド
レガシー アプリのモダナイゼーションについて考え始めると、圧倒されてしまいがちです。 ガイドがあれば、体験の計画を立てやすくなり、正しい道を歩むことができます。 まず、これら 3 つのステップから始めて、それぞれをローコードの考え方で検討することをお勧めします。
プランニング。 レガシ アプリケーションをモダナイズする目標を慎重に検討し、それを達成するための戦略を定義します。 モダナイゼーションで解決したい問題を明確に記述します。 今こそ、何が機能していないのか、何が機能しているが改善の余地があるのか、そして最も重要なこととして、変更によってビジネスやユーザーにとってどのような価値があるのかに目を向けて、アプリと環境を評価していきます。 各モダナイゼーションの機会を評価して、ローコード アプローチを活用する可能性を確認します。 ローコード ソリューションを組み込んだ機会に優先順位を付けます。 クラウド導入戦略評価ツールを使用して、アプリケーション最新化のビジネス用途を構築します。
実装。 アプリを段階的にだけでなく、反復的に最新化します。 反復的なアプローチにより、組織は必要に応じてプロジェクトの範囲や戦略を柔軟に変更できます。 Power Platform のローコード ソリューションは、従来開発されたアプリよりも迅速に開発およびテストすることができ、マネージド環境での展開はわずか数ステップで済みます。 ローコードは従来のコーディングよりもスキルアップの必要性が低いとはいえ、ロー コードと従来のリソースを組み合わせた融合チームとして働く方法について、従業員が適切にトレーニングを受けていることを確認してください。
操作。 アプリのモダナイゼーションは実装にとどまりません。 ロー コードのクラウド ファーストのアプローチでは、クラウド プラットフォームのサービスとツールを使用して、アプリを保護、ガバナンス、管理、最適化できます。
ローコード ソリューションの機会を評価する
組織は、非公式なレビューから詳細な決定木に至るまで、さまざまな方法を用いて、レガシー アプリケーションを近代化するのにロー コード アプローチが正しい方法であるかどうかを判断します。 考慮すべき最も重要なことは、ロー コードはオール オア ナッシングの決定ではないということです。 アプリケーションの一部を Power Platform コンポーネントで構築し、一部を従来のコーディング技法で開発されたコンポーネントで構築することは一般的です。
アプリケーションを評価するには、まず、そのアプリケーションがまだ必要で有用であるか、廃止する必要があるかどうかを判断することをお勧めします。 それでも必要だと判断した場合は、ローコード ソリューションでアプリ全体を置き換えることができるかどうかを評価します。 アプリ全体がローコードでの置き換えに適していない場合は、アプリのワークロードやコンポーネントの 1 つ以上が適しているかどうかを評価します。 従来の方法で開発されたコードで拡張されたローコード ソリューションは、両方の長所を提供することがわかります。
たとえば、Power Appsに必要なコントロールがないためにアプリケーションが適していないと判断した場合は、Power Apps コンポーネント フレームワーク (PCF) と従来のコードを使用してカスタム コントロールを構築できます。 もう 1 つの例は、複雑なロジックを持つアプリです。 カスタムコネクタを使用して、Power Apps がアクセスできる API にロジックを一元化することができます。 これらの両方の例では、Power Platform の拡張性により、アプリのほとんどがローコード コンポーネントで構築され、従来開発されてきたコードとのギャップを埋めることができました。
独自のオンライン保険ショッピングプラットフォームである NSure.com は、実際の例を示しています。 同社の最初の立ち上げは、従来開発された Angular、Xamarin、Azure サービスに依存していました。 Power Platform と Dynamics 365 を追加 NSure.com、次の図に示すように、ロー コードと従来のコーディング手法の両方を使用して次世代ソリューションを作成しました。 会社の歩みについて詳しくはこちらをご覧ください。
ロー コードの機会を特定するのと同じくらい重要なのは、ローコード アプローチが適切でない場合を認識することです。 次の表は、一般的にローコード ソリューションに適さないユース ケースを示しています。 組織はフロント エンドとバックエンドで異なる課題に直面しているため、それらを別々に検討しましょう。
ローコード アプローチに適さないフロントエンドのシナリオ
| シナリオ | 課題 |
|---|---|
| ユーザー デバイスに互換性がありません | Power Platform はモバイル機器やバーコード スキャナのような特殊なデバイスを認識します。 特定の API またはドライバーに依存するデバイスはサポートされていない可能性があるため、より従来のアプローチが必要になります。 |
| 大量のクライアント側データ | 一部のアプリケーションのユーザー エクスペリエンスには大量のデータが必要であり、ローコードに限らず、あらゆるテクノロジーにとっての課題となっています。 大量のデータをダウンロードして処理すると、バックエンド システムに負荷がかかり、アプリとアプリが実行されているデバイスの両方のパフォーマンスが低下する可能性があります。 大量のデータをナビゲートすることを余儀なくされているユーザーは、生産性が低下します。 負荷を処理するために従来のコーディング方法に目を向ける前に、適切なフィルター処理とナビゲーションによってユーザー エクスペリエンスが向上するかどうかを調べてください。 |
| 複雑なオフライン要件 | 接続性が低い場所や存在しない場所で動作する必要があるアプリケーションは、ローコードと従来のコードのどちらを使用していても、実装とサポートが困難な場合があります。 Power Appsは、単純なオフライン シナリオに対する基本的な機能を提供します。 たとえば、イベント中にリードをキャプチャし、イベント後にマーケティング データベースにアップロードするアプリは正常に機能します。 ファイルや画像、非 Dataverse のコネクタ、複雑な競合の解決を必要とするアプリケーションでは、従来のコード テクニックを利用する必要があります。 |
ローコード アプローチに適合しないバックエンド シナリオ
| シナリオ | 課題 |
|---|---|
| 高速データ | 移行や同様のイベントの一部としての数百万行のデータのインポートは、一般的にサポートされています。 ただし、毎時または毎日数百万行のデータを処理するワークロードは、より多くの評価を受ける必要があります。 たとえば、大量のモノのインターネット (IoT) のテレメトリを Dataverse にコレクションしても意味がありません。 代わりに、Azureクラウド サービスを使用して、Dataverse に追加されたデータと関連シグナルを収集して分析し、アプリケーション内のアクションをトリガーできます。 Dataverse のデータを定期的に大量に更新するようなアプリケーションでは、更新を拡張するために従来のコードの支援が必要になる場合があります。 |
| 複雑なロジックを持つバックグラウンド ワークロード | 複雑なロジックや大量の API 呼び出しを伴うバック グラウンド ワークロードは、ローコード ソリューションに適していない可能性があります。 代わりに、ローコード ソリューションが呼び出すことができる API にロジックを一元化できます。 |
| 非 RESTful のプロトコルを使用する API | Power Platform コネクタは REST API のみをサポートします。 SOAP や gRPC などの別のスタイルの API に接続する必要がある場合は、互換性のない API と通信する独自の REST API を提供します。 |
Power Platform のリリース サイクルは、ローコード ソリューションでできることのギャップを埋め続けているため、このサイクルをフォローすることを推奨します。 ローコードの概念実証を作成することは、シナリオが適切かどうかを判断するための優れた方法です。
ローコードのビジネスチャンスを優先する
アプリケーション ポートフォリオを評価する際には、ローコード変換の適切な候補を特定するだけでは不十分です。 チームは、モダナイゼーションの取り組みの成功を最大化するために、それらに優先順位を付ける必要があります。
優先順位付けは、以下の要素を考慮する必要があります:
- お客様の組織のローコード成熟度
- 機会の複雑性
- 組織、ユーザー、IT 部門の ROI
- 価値実現までの時間
組織のローコード機能を現実的に把握することで、チームの成長に課題を与えながらも、失敗に追い込まれることのない機会を選択することができます。 何の課題もなく、最も簡単なアプリケーションを選択する必要はありません。 理想的なのは、従来のコードとローコード ソリューションを組み合わせる方法を模索する機会を提供することです。
他のシステムと複雑に統合されているアプリケーションは、多くの場合、最適なスタート地点ではありません。 大きすぎたり複雑すぎたりするアプリケーションに取り組もうとすると、フラストレーションや失敗につながる可能性があります。 疑わしいローコードの候補は避けてください。 チームがいくつかの最新化を成功させた後のために保存しておいてください。
大規模なモノリシック アプリを最新化する場合は、その小さな部分を段階的に最新化できるかどうかを検討してください。 モノリシックなアプリケーションは、かつては一般的でした。 現在では、役割やタスクに重点を置いた小規模なアプリが一般的になっています。 これにより、インクリメンタルな開発と、それらを構築するチームの拡張とスケーリングが可能になります。
最初の数回の最新化は、組織がローコード ソリューションの影響を確認できるようにするために重要です。 機会に優先順位を付ける際には、アプリの関係者にとっての利点とリスクを評価することが重要です。 誰も気にしないアプリケーションや、組織への影響が少ないアプリケーションを選択することは、ローコード ソリューションの利点を最もよく示すことはできません。
最新化されたアプリケーションをユーザーが受け入れることは重要です。 ユーザーは、新しいローコード アプリケーションが、使用する他のアプリケーションと調和していると感じる必要があります。 導入におけるもう一つのリスクは、彼らが慣れているカスタマイズの度合いです。 高度にカスタム構築されたエクスペリエンスを期待している場合、個人的ではないと感じられるローコード ソリューションを採用する傾向は低いかもしれません。
チームの編成とスキルアップ
レガシー アプリのモダナイゼーションに成功している組織は、従来のコード開発者のチームにモダナイゼーション プロジェクトを割り当てて、その成功を願うだけではありません。 最新化の取り組みを成功させるために必要なローコード開発のナレッジと自信をチームに与えることが重要です。
従来のコード リソースと並行して作業するローコード リソースのチームは、フュージョン チームと呼ばれます。 フュージョン チームは、ローコード ソリューションと従来のコードの統合について両方の種類のリソースをトレーニングすることで、コラボレーションを促進するように設計されています。 ソリューション アーキテクトは、ローコードと従来のコードの間でソリューションを設計する方法を確立します。
既定では、すべての作業を従来の開発者に割り当てるのは簡単ですが、ローコードのモダナイゼーションの取り組みは、プロジェクト チームを拡大する良い機会です。 多くのビジネス ユーザーは、優れたローコード リソースとなります。 ビジネス上の問題を既に理解しているため、チームの作業を加速できます。 チームが引き受けるローコード作業の種類を完了する方法を学び、テストと ALM の手順に精通しているだけで済みます。 これは、Power AutomateのPower Appsまたはワークフローでアプリを構築する方法を学ぶことを意味する場合があります。 また、従来のコーダーがローコード作業を容易にするために何を開発できるかを理解する必要があります。 だからといって、従来のコードの書き方を知っておく必要はありません。
従来のコード リソースは、ローコード アプローチと、これらが通常記述するコードとどのように異なるかについての基本的な知識を持っている必要があります。 最も重要なのは、ローコード ソリューションの拡張性オプションを学ぶ必要があることです。 作成したコードを使用するテスト アプリまたはフローの作成に問題がなく、それが動作することを確認し、機能拡張資産を使用する際にローコード リソースをサポートする準備を整える必要があります。
ローコードと従来のコードの両方のリソースは、ローコードと従来のコード ソリューションの開始と終了、それらが交差する場所を理解する必要があります。
要件の収集
10 年以上前のアプリがあり、文書化されていない場合があります。 再現するには、リバース エンジニアリングやビジネス ユーザーの知識が必要な場合があります。 ローコード アプローチは効率的ですが、要件やビジネス プロセスに関する知識の収集を高速化したり、複雑な要件の複雑さを軽減したりするわけではないことを覚えておくことが重要です。 多くの場合、アプリをモダナイズするチームが、ロー コードで新しいアプリを構築するチームと同じくらい多くのことを達成できるという非現実的な期待があります。 これらの課題を念頭に置いて、組織の期待を確立します。
2 つのアプローチにより、レガシー アプリに関する知識を得る作業を加速できます。 まず、チームを拡張して、ドメイン知識を持つビジネスユーザーを含めます。 次に、レガシー システムでどのように実装されているかをドキュメント化するのではなく、ビジネス プロセスとその望ましい結果を理解することに焦点を当てます。 ただし、レガシ アプリケーションが、従う必要のあるビジネス ルールを実行する特殊なロジックを必要とする場合は例外です。
ローコードアプローチに反対しないようにする
ローコード ソリューションを使用したアプリケーションのモダナイゼーションに不慣れな組織は、従来のコードを開発するのと同じ方法でローコードを開発するという間違いを犯すことがよくあります。 たとえば、組織では、Angular アプリ用に記述された UX 標準を最初のPower Apps実装に適用する場合があります。 プロジェクト チームは、ビジネス ニーズではなく Angular フレームワークの機能のために設計された標準を満たすために不必要な時間を費やすことになります。
従来のコードでの作業に慣れているチームは、ローコードを最小限に抑えようとするかもしれません。 たとえば、Power Apps コントロールを使用する代わりに、チームは、できるだけ低いコードを使用しないように、Power Appsコンポーネント フレームワーク コントロールからアプリケーションを構築できます。 チームは、回避できない障壁にぶつかるまで、ローコードでできる限り進めるのが最善です。 プラットフォームの機能を活用する方法を学んだチームは、ローコードのメリットを最大限に引き出すことに成功します。 ローコードは、従来のコードでしか実現できなかったことを実現できるようになってきています。 これまでの一般的な課題は、ローコードでは必要な機能を複製できないために行き詰まることでした。 Power Platform は、主にローコード アプリケーションが、必要に応じて従来のコードで書かれた特殊なコンポーネントを組み込めるようにする拡張性オプションによって、この課題に対処しています。
ローコード アプローチは、モダナイゼーション戦略において重要な役割を果たします。 最良の結果を得るには、モダナイゼーションの取り組みが解決しようとしている問題、計画、既定の役割を超えた人員配置、トレーニング、優先順位付けの明確な説明が必要です。 また、必要に応じて標準やプロセスを適切に調整することで、組織はローコードの可能性を最大限に引き出すことができます。 モダナイゼーションを適切に行うと、モダナイズされたアプリケーションの全体的なビジネス価値が向上します。
ローコード プラットフォームは、ここ数年で急速に進化しています。 これまでも個人の生産性シナリオのサポートに長けていましたが、最近では企業の機能に重点が置かれています。 組織は、ハイブリッド ワーク (リモートおよびオンサイト) や、それに伴うコラボレーションを促進する方法の必要性など、現代の職場環境をサポートするローコード アプリケーションを構築しています。 Power Platform のようなローコード プラットフォームは、組織内のすべてのユーザーが信頼でき、企業のセキュリティモデルに統合できるアプリケーションを扱うために拡張できるようになりました。 ローコード機能をエンタープライズのインフラストラクチャに接続することで、ローコード手法を従来の方法と並行して使用できます。 ローコードは複雑性の多くを抽象化し、より多くの人々がソリューションの構築に参加できるようにします。
ローコード アプローチのコスト構造を理解する
組織がモダナイゼーションの取り組みを検討する際によく聞かれる質問は、どれくらいの費用がかかるかということです。 ライセンスとコスト分析の完全な説明は、このホワイト ペーパーの範囲を超えていますが、これらのトピックを大まかに調べることができます。
Power Platform 製品はライセンス製品です。 要件に合わせて個別にライセンスを取得できます。 従量課金制のAzure課金を構成できます。これにより、事前のライセンス コミットメントや購入なしで使用でき、アプリ内のPower Automate使用量が含まれます。 Power Automateには、スタンドアロン作業用のユーザーごとのライセンスとフローごとのライセンスもあります。 フローごとのライセンスは、組織全体に利益をもたらす自動化がある場合に適しています。 Power Appsライセンスは、ユーザーごとまたはアプリごとに指定できます。 Power Pages サイトは、ユーザー、サイト、または月ごとにライセンスが付与されます。 認証されたサイトには、追加のライセンスが必要です。 すべてのライセンスにはコネクタと Dataverse の使用が含まれ、大容量シナリオ用にストレージと API リクエストのライセンスを増やすオプションもあります。
すべての Power Platform 製品には、アプリケーションの最新化作業に一般的に適用されるボリューム価格が設定されており、各組織独自の戦略に合わせて評価する必要があります。
ローコードのコストを従来のコードと比較する際には、同じ条件での比較ではないことを理解することが重要です。 ローコードでは、ローコード製品に独自のビジネスプロセスを実装するための人件費と、使用するための製品ライセンス料を支払うことになります。 一般に、ライセンスには複数のアプリと自動化が含まれており、それぞれに追加のコストは必要ありません。
従来のコーディングのアプローチでは、独自のビジネス プロセスをコードに実装する作業、アプリのインフラを構築する作業、そしてアプリをサポートするために必要なクラウド サービスに費用がかかります。
ローコードであろうと従来のコードであろうと、すべてのソリューションには継続的なメンテナンスと維持が必要です。 ただし、ローコード ソリューションでは、それを実行するために必要なリソースが少なくて済みます。 また、アプリのインフラストラクチャがプラットフォームによって提供されるため、技術的負債も少なくなります。
ローコード プラットフォーム上に構築されていない完全なカスタム アプリケーションと比較して、ローコード ソリューションのコストはより予測可能です。 ローコード ライセンスと従来のコード展開の初期コストを比較するという罠に陥らないようにします。
Power Platform の内部を見る
Power Platform コンポーネントは、従来のコーディング方法を使用する場合に使用できるのと同じMicrosoft Azureクラウド サービス上に構築されます。 これらのコンポーネントを相互に統合し、セキュリティ、スケーラビリティ、ディザスター リカバリー機能を提供します。
Dataverse の内側
Dataverse は、Functions、Load Balancer、Cognitive Services、Synapse、DevOps、Active Directory、Microsoft Purviewなど、25 を超えるフル マネージド Azure サービスを利用しています。 組み込みの機能には、包括的なセキュリティ、強力な分析、AI、高度なビジネス ロジックとイベント処理、データ モデリング、Dynamics 365、Microsoft 365、Azureなどの統合が含まれます。 これらすべての機能は、Azure SQL DB (リレーショナル データの場合)、Azure Cosmos DB (NoSQL)、Azure Blob Storage (ファイル用)、およびAzure Data Lake Storageに基づく polyglot Dataverse ストレージ レイヤー上に構築されていますGen 2 (大規模な分析と長期的なデータ保持用)。 これらは Power Platform のローコード コンポーネントや Dataverse の REST API で透過的に使用できます。
ビジネス クリティカルなアプリケーションにとって、高可用性と事業継続性、ディザスター リカバリー (BCDR) は重要です。 Dataverse は、Azure信頼性サービスを使用して可用性を最大化します。 プライマリ サーバとセカンダリ サーバのレプリケーションは同期的であり、その下にファブリックがあり、不具合を検出し、正確性プロトコルに従って新しいプライマリ サーバを選択できます。 Azure リージョン内で発生する高可用性のフェールオーバーはシームレスであり、ユーザーが気付くことはほとんどなく、通常は数秒で発生します。 停止が計画的か計画外かに関係なく、データ損失がゼロであることが保証されています。
ディザスターリカバリーフェールオーバーは、2つのAzureリージョンにまたがって発生します。 データ損失を最小限に抑えてフェールオーバーを高速化するために、ディザスター リカバリーの連続コピーは非同期レプリケーションを使用して維持されます。 計画的なフェールオーバーではデータ損失は発生せず、運用環境では通常、数秒または数分で完了できます。
高可用性と BCDR の技術的な実装に加えて、運用チームは、さまざまな種類のイベントに応答する準備ができているかどうかを定期的にテストします。
Power Automate の内部
Power Automateクラウド フローは、Azure Logic Apps上に構築されます。 Power Automateは、抽象化と、Power Appsなどの他のローコード コンポーネントとの統合を提供し、Logic Apps ランタイム エンジンを使用します。 Logic Apps に慣れている開発者は、式言語を含む同様の概念を Power Automate でも使用していることがわかります。
Power Apps の内部
Power Apps ランタイム エンジンは、React フレームワーク上に構築されています。 アプリケーションは、ドラッグ アンド ドロップ インターフェイスを使用して画面を構築するPower Apps デザイナーでビルドされます。 Power Fx 式はロジックを実装します。 コネクタは、再利用可能なビジュアル拡張機能を可能にする他のサービス、ロジック、コンポーネントへのアプリのアクセスを拡張します。 開発者は、Power Apps コンポーネント フレームワーク (PCF) を使用してカスタム コントロールを作成できます。 多くの UI フレームワークを PCF と共に使用できますが、Power Apps React の組み込みサポートが機能します。
コネクタの内部
コネクタでは、Azure API Managementを使用して、各ユーザーからの資格情報と接続を管理します。
独自の API 用に作成したカスタム コネクタを含め、すべてのコネクタに同じアーキテクチャが使用されます。 Azure API Managementを使用することで、すべてのコネクタとのPower AppsやPower Automateなどの Power Platform 製品の一貫したインターフェイスが保証されます。
例外は Dataverse コネクタです。 アプリとフローのコネクタの一覧に表示されますが、実装方法が異なります。 アプリやフローが Dataverse のデータやアクションを使用する場合、Dataverse の OData API を介して直接やり取りされます。
Power Platform 拡張オプション
拡張性は、Microsoft Power Platformを他のローコード プラットフォームと区別する重要な機能です。 このプラットフォームの基本原則は「障壁がない」ことであり、従来のコードを必要とする場合でも、ローコードを使用して何かを達成することを妨げられるべきではありません。 必要に応じて、従来のコードを使用して、大規模なアプリの一部としてワークロード全体を構築できます。 ただし、このプラットフォームには、ローコードと従来のコードを同じワークロードで一緒に使用できる多くの拡張機能オプションが用意されています。
次の表に、いくつかの一般的な拡張機能オプションの概要を示します。 そのうちのいくつかは、モダナイゼーションへのアプローチ方法と適用できるパターンについて後で説明するときに、再び参照します。
| オプション | 説明 |
|---|---|
| API とカスタム コネクタ | REST API 用のカスタム コネクタは、アプリ ロジックを一元化し、安全で管理された方法でローコード コンポーネントに公開できるようにします。 このアプローチは、アプリケーションの最新化のための API ファースト戦略で使用できます。 カスタムコネクタは OpenAPI ドキュメントを使用して、ローコード コンポーネントが REST API とどのように相互作用できるかを定義します。 たとえば、Azure Functionsを使用して API を作成し、Azure API Managementに発行できます。 Azure API Management OpenAPI 定義をエクスポートして、ローコード ソリューションで使用するカスタム コネクタを自動的に作成できます。 このアプローチでは、クライアント アプリケーションを API から切り離し、独立して進化させます。 API は一元管理されており、API を直接公開せず、サブスクリプション キー、トークン、クライアント証明書、カスタム ヘッダーなどの認証技術を使用することで、セキュリティのレイヤーを追加しています。 |
| Power Apps コンポーネント フレームワーク | Power Apps コンポーネント フレームワークは、Power AppsおよびPower Pages用のカスタム ビジュアルを作成するための拡張フレームワークです。 コード コンポーネントは、HTML、JavaScript、またはTypeScript を使用して作成されます。 コード コンポーネントは、1 つ以上のアプリを構築するために再利用できる UI 構成要素と考えてください。 コンポーネントには、ローコード コンポーネントがコード コンポーネントと対話する方法を定義するマニフェストが含まれています。 コンポーネント インターフェイスを使用すると、ホスティング ランタイム エンジンはホスティング コンテナーのライフサイクル イベントを通信できます。 これにより、コード コンポーネントは、ホスティング コンテナーによって提供されるコンテキスト情報を使用してビジュアルをレンダリングできます。 アイデアについては、コミュニティ ギャラリー ( https://pcf.gallery) を参照してください。 |
| 仮想テーブル | 仮想テーブルを使用すると、外部システムに存在するデータを簡単に統合できます。 外部データは、データをレプリケートすることなく、多くの場合、カスタム コーディングを必要とせずに、Microsoft Dataverseのテーブルとしてシームレスに表されます。 Dataverse には、OData v4 および Azure Cosmos DB 用のデータ プロバイダーが付属しています。 現在プレビュー段階にある仮想コネクタ プロバイダーは、使用可能なデータ プロバイダーを拡張して、SharePointやSQL Serverなど、Power Platform コネクタのサブセットを含めます。 より高度なシナリオでは、開発者はカスタム データ プロバイダーを作成できます。 カスタム データ プロバイダを作成するには、外部データと Dataverse の両方に関する深い知識が必要です。 ロジックに Power Fx を使用して Dataverse のプラグインを作成する機能はプレビュー中です。 |
| Dataverse プラグイン | Dataverse プラグインは、特定のイベントに反応して実行されるカスタム イベント ハンドラーです。 データベース エンジンではストアド プロシージャのようなプラグインを考えますが、.NETで記述されています。 たとえば、イベントは、Microsoft Dataverseデータ操作の処理中、またはカスタム API イベントのオンデマンドで発生します。 このプラグインは、アップロードして Dataverse に登録できる.NET フレームワーク アセンブリにコンパイルされたカスタム クラスとして実装されます。 プラグインは、定義されたインターフェイスを使用して、処理中のイベントに関するコンテキスト情報を取得できます。 プラグインは Dataverse トランザクションの一部として実行でき、現在のトランザクションの一部である他のデータ操作を実行できます。 プラグインは、小さな作業単位を対象としています。 プラグインのパフォーマンスを最適化する必要があり、全体的なパフォーマンスに悪影響を与えないようにしなければなりません。 プラグインは、ユーザー インターフェイスや API からの操作に関係なく常に実行されるため、ビジネス ロジックを一貫して適用するための強力な手段となります。 |
ローコード モダナイゼーション アーキテクチャ シナリオの調査
ほとんどのプラットフォームと同様に、Power Platform コンポーネントやその他の Microsoft クラウド サービスを使用して、無限のアーキテクチャ シナリオを構成することができます。 ホワイト ペーパーのこのセクションでは、より一般的なシナリオをいくつか検討し、それらを使用する際に留意する必要がある、いくつかの考慮事項について説明します。
アプリケーションのエクスペリエンス
ユーザー エクスペリエンスを最新化することで、ユーザーに大きな違いをもたらすことができます。 Power Appsは、Power Platform を使用して内部アプリケーション エクスペリエンスを構築する主要な方法です。 Power Pagesは内部 Web アプリケーションに使用できますが、外部向けアプリケーションの方が一般的です。
Power Apps
ワークロードは、ユーザーがアプリを切り替えることなく作業の多くを完了できるように設計する必要があります。 大規模なモノリシック アプリケーションを最新化する場合、その機能を複数のアプリに分割する場合があります。 逆に、ユーザーが複数のアプリで作業する必要がある場合は、それらを 1 つのアプリに統合して、複数のデータ ソースの統合ビューを表示することができます。
次の表では、Power Apps、キャンバス アプリ、モデル駆動型アプリで構築できる 2 種類のアプリについて説明します。
| AP の種類 | 説明 |
|---|---|
| キャンバス アプリ | キャンバス アプリは、高いカスタマイズ性を備えている。 これらは、ユーザーが操作する 1 つ以上の画面で構成されます。 各画面のレイアウトと画面間のナビゲーションを制御します。 キャンバス アプリはコネクタを使用してデータを操作します。 1 つのアプリで複数のコネクタを操作できるため、複合アプリとして複数のデータ ソースを統合するのに適しています。 |
| モデル駆動型アプリ | モデル駆動型アプリは、プライマリ データ ソースとして Dataverse を使用します。 これらは 1 つ以上のページで構成され、Dataverse テーブルまたはカスタム ページにすることができます。 Dataverse テーブルのページは、詳細ページまでドリルダウンして表示、編集することができます。 カスタム ページには、キャンバス アプリの画面とコネクタからのデータを組み込むことができます。 モデル駆動型アプリには、カスタマイズ可能なナビゲーション構造が組み込まれています。 これはすべてのモデル駆動型アプリで一貫しており、ユーザーによる導入に役立ちます。 |
次の図は、アプリがデータ ソースに直接接続するキャンバス アプリまたは モデル駆動型アプリ の基本的なアーキテクチャを示しています。
データ ソースへの直接接続を最小限に抑えるには、API へのカスタム コネクタをアプリで使用して、データ ソースで必要な作業を行います。 このアプローチにより、ローコード コンポーネントに公開される操作を制御し、基になるロジックの複雑さを抽象化できます。 次の図は、この API 優先のアプローチを示しています。
Power Appsは、結果をアプリケーションに返したり、非同期的に実行したりできるクラウド フロー Power Automate直接実行することもできます。
データ リポジトリまたは API でPower Appsを使用すると、従来のソリューションの他の部分の中断を最小限に抑えながら、ユーザー エクスペリエンスを最新化できます。 このアプローチでは、複数のレガシ システムを 1 つのアプリケーションに接続して、ユーザーが 1 か所で作業を完了することもできます。
Power Pages
Power Pagesのプライマリ データ ソースは Dataverse です。 Web サイトにページを追加する場合、ページ定義は Dataverse に保存されます。 ページは Dataverse のデータを提示することも、ユーザーからデータを収集して Dataverse テーブルに保存することもできます。
外部ユーザーの内部ユーザーまたは ID プロバイダーのMicrosoft Entra IDを使用して、匿名アクセスまたは認証済みアクセス用にページを構成できます。 認証されたユーザーがデータにアクセスすると、アクセス権限のあるデータのみが使用可能になります。
Power Pages サイトの一般的なアプリケーションは、組織のビジネス プロセスへのセルフサービス アクセスを外部ユーザーに提供することです。 内部ユーザーは、Power Apps アプリケーションを使用できます。 次の図は、このようなアーキテクチャを示しています。
外部向けのPower Pagesサイトを介してDataverseデータにアクセスする外部ユーザーと、Power Appsアプリを介してDataverseデータにアクセスする内部ユーザーを示す図。
データ管理
アプリケーションの最新化では、ソリューション全体で使用されるデータを評価する必要があります。 最新化されたアプリケーションには、データを処理するための複数のオプションがあります。 多くの場合、複数のアプリケーションが同じデータリポジトリを使用します。 アプリケーションの 1 つをモダナイズする一環として、新しいリポジトリにデータを移行することが困難になります。 Power Platform の中核となるコンセプトは、データを今ある場所で利用することも、Dataverse またはデータレイクでプラットフォームに取り込むこともできるということです。
最新化されたアプリケーションのデータ アーキテクチャには、次のオプションがあります。
データをそのまま残す: コネクタまたは API とカスタム コネクタを使用して、データが存在する場所にあるデータにアクセスします。 データがオンプレミスにある場合、データ ゲートウェイはセキュリティで保護された接続を容易にすることができます。 仮想テーブルを使用して、互換性のある外部データを Dataverse テーブルとして統合します。
Dataverse への移行 Dataverse は、トランザクション データや、複数のソースを 1 つのレコード システムに統合する場合に適したオプションです。 データは、Power Queryおよび自動化されたフローを使用して、多くのソースからマップおよび移行できます。 Dataverse は、非構造化形式または半構造化形式で格納されている大量のデータを取り込むために設計されたエラスティック テーブルもサポートしています。
データ レイクへの移行: 履歴データ、分析データ、またはテレメトリ データの場合は、データ レイクを使用します。 レイク内のデータを使用して、Power BI分析を生成したり、AI を利用した分析情報を生成するために処理したりできます。
最新化されたアプリケーションのデータ アーキテクチャのオプションを評価するときは、次の考慮事項に留意してください。
他のアプリケーションへの影響: より効率的なデータ ストアへの移行は、1 つのアプリケーションにとって理想的かもしれませんが、データを使用する他のアプリケーションへの最初の影響が大きすぎる可能性があります。 組織によっては、古いデータ ストアにデータを残して Dataverse に新しいデータを作成し、より多くのアプリケーションを最新化する際に古いストアから移行することを検討しています。
新しいアプリケーションへの影響: 古いデータ ストアにデータを残しておくことは簡単ですが、モダナイズされたアプリケーションがそのデータを扱いやすくすることに悪影響を及ぼす可能性があります。 古いデータ ストアは、他のクラウド サービスと適切に統合されていない可能性があり、新しい全体的なアーキテクチャにデータを組み込むことが難しくなります。
データ統合: アプリケーションのモダナイゼーションの一環として、適切な使用を確保するための明確な所有権や責任がないデータを特定するのが一般的です。 Dataverse にデータを統合することで、組織はデータのガバナンスを向上させ、適切な利用をより確実にすることができます。
データのプライバシーとセキュリティ: プライバシーとセキュリティは、レガシー アプリケーションがどのように処理していたかだけでなく、現在のニーズと目標とする近代化アーキテクチャに基づいて評価する必要があります。 クラウド ソリューションには、プライバシーとセキュリティの制御を実装するためのより多くのオプションがあります。 多くの場合、1 つのデータ ストアで単純化できます。 また、複数のリポジトリにデータを分割するハイブリッド アプリケーションに統合データセキュリティを実装する方法も検討する必要があります。
統合の問題 古いデータ ストアには、データを移行したり、アプリケーションがカスタム コネクタで使用できる API を作成したりせずに、アクセスを許可するために必要な API が不足している可能性があります。 古いデータ ストアからそれを使用するアプリケーションへの接続を評価して、パフォーマンスが許容できるかどうかを判断する必要があります。
最新化するアプリケーションごとにデータ アーキテクチャを決定する必要があります。 最初のステップは、データ アーキテクチャにどのように Dataverse を組み込むかという全体的なビジョンを確立することです。 ローコードの価値を最大化することが目的なら、可能な限り Dataverse を使用する必要があります。 最初にビジョンを持つことで、データのサイロ化を回避できます。
「外部データ」とDataverse
レガシー アプリケーションは、多くの場合、組織の外部に存在し、Dataverse 以前から存在していたデータに依存しています。 これらのアプリケーションを最新化する場合、Dataverse のデータを複製する必要はありません。 その代わりに、データを仮想 Dataverse テーブルとして表現することができます。 仮想テーブルは、他の仮想テーブルやローカル テーブルとのリレーションシップに参加できます。 最新化されたアプリケーションでは、完全に Dataverse に存在するように見える統一されたテーブル セットが表示されます。
仮想テーブルは、データ プロバイダー アーキテクチャを使用して実装されます。 Dataverse には、OData V4 Web サービスで使用できる OData プロバイダが含まれています。 現在プレビュー中の仮想コネクタ データ プロバイダーでは、表形式の Power Platform コネクタを仮想テーブルとして使用できます。
次の図は、仮想コネクタの使用方法を示しています。
開発者は、他の外部データ ソースのカスタム プロバイダーを作成することもできます。 しかし、すべての Dataverse マッピングと操作サポートを理解し、実装する必要があります。
次の考慮事項は、最新化プロジェクトでの仮想テーブルの使用を評価する際に役立ちます。
- すべての外部データ ソースは主キーを持たなければならず、データ プロバイダはそれを GUID として Dataverse に提示する必要があります。 パディングされた値が安定していて一意である場合、パディング付きの非 GUID キーに対応できます。
- データ セキュリティは、仮想テーブル レベルで構成されます。 行レベルおよび列レベルのセキュリティは使用できません。
- 仮想テーブルのパフォーマンスは、データ プロバイダー、外部データ ソース API、データ ソースへの接続によって異なります。 ほとんどの場合、仮想テーブルへのアクセスはローカルの Dataverseテーブルよりも遅くなります。
- 検索、監査、グラフやダッシュボード、オフラインアクセスなどの一部の Dataverse 機能は、仮想テーブルでは利用できません。
- 参照データに仮想テーブルを使用すると、同期が低下する可能性があります。
ファイルと画像
ファイルやイメージを使用するアプリケーションを最新化するときは、新しいソリューションがそれらを格納する場所を検討することが重要です。 Dataverse には、ファイルや画像を保存する特殊な機能があります。 どちらも列としてテーブルに追加でき、Dataverse によって管理されるAzure Blob Storageに格納されます。 アプリは Dataverse コネクタを使用して連携できるため、個別の認証や API は必要ありません。
ファイルや画像に Dataverse を使用するのは、データと直接関係があり、複数のユーザーが共同作業する必要がない場合に適しています (製品や場所の写真、法的契約の最終コピーなど)。 ただし、複数のユーザーが法的契約を同時に変更する必要がある場合は、SharePointを使用すると、より大きなコラボレーション機能が提供されます。 Dataverse とは別にセキュリティを管理する必要がある場合、または特定のファイル固有の機能を使用する必要がある場合は、Azure Blob Storageを直接使用することを検討してください。
統合
アプリケーションのモダナイゼーションには、多くの場合、内部または外部システムとの統合が含まれます。 統合は、データ、アプリケーション、またはプロセスに大別できます。
データ統合では、異なるソースからのデータを組み合わせ、ユーザーに統一されたビューを提供します。 分離されたアプローチを提供しますが、ロジックやプロセスをリアルタイムで構築することはできません。 すべてのデータがローカルであるため、パフォーマンスが向上する可能性があります。
アプリケーションの統合は、アプリケーション層で接続され、通常は API またはローコード ソリューションではコネクタを介して行われます。 アプリケーション レベルの統合では、2 つのソリューション間に明確な境界が提供されますが、多くの場合、リアルタイムの依存関係も作成されます。 このタイプの統合では、API を提供しているシステムによってアクセスを制御できるセキュリティ境界も作成されます。
プロセス統合での各システムは、全体的なビジネス プロセスの一部です。 このタイプの統合は最も分離されているため、参加するシステムがビジネス プロセスの各部分を処理できます。 最新化のシナリオでは、最新化のプロセスの一部をローコードで分割し、レガシー システムによって処理されている他の部分と統合すると役立つ場合があります。
統合の実装方法を評価するときは、古いアプローチがモダナイズするアプリケーションに最適なアプローチであると思い込まないことが重要です。 たとえば、プロセスがリアルタイムかつ同期的な場合は、非同期的に実行できるかどうかを検討します。 クラウド ソリューションでは、同期統合がさらなる脆弱をもたらす可能性があります。 たとえば、適切なエラー処理を伴う低コードのPower Automate フローによって、統合が調整される可能性があります。 このアプローチでは、信頼性が向上するだけでなく、統合の完了を待つ必要がなくなるため、ユーザーの生産性も向上します。
次の検討事項は、既存の統合を前進させる方法を評価する際に役立ちます:
統合はまだ必要ですか？ 統合の結果を誰も使用しなくなり、廃止される可能性があることがわかることは珍しくありません。
最新化されたアプリケーションがクラウドにある場合、接続の課題はありますか? 課題としては、待機時間や、オンプレミスの API やデータ ストアへのアクセスなどが考えられます。 場合によっては、オンプレミス データ ゲートウェイが、クラウドからのサービスまたはデータへのアクセスに役立ちます。 データやサービスへのアクセスが遅すぎる場合は、最新化されたアプリに対してデータをローカルにするか、バックグラウンドで統合を実行できるかを検討してください。
統合は、モダナイズされたアプリケーションの適切なサイズ設定にも役立ちます。 レガシー アプリケーションの 1 つ以上の部分を分割し、そのまま残したり、別のアプリケーションとして実装したりすることができます。 このアプローチは、異なるロールのユーザーがレガシー アプリケーションの異なる部分を使用する場合に適しています。 ローコードを使用して 1 つ以上のロールを実装し、プロセス統合を使用して、プロセスの残りの部分を既存のアプリケーションで処理させることができます。 このアプローチを使用すると、時間の経過とともに残りの部分を段階的に最新化できます。 また、プロセスの独立した部分を個別に実装することで、プロセスの他の部分とは独立して機能強化をロールアウトする、より機敏な方法も容易になります。
カスタム統合を進める前に、Power Appsに組み込まれている統合機能を評価する必要があります。
Microsoft Teams: Power Apps キャンバス アプリと Copilot Studio エージェントを Teams チャネルに埋め込むことができます。 Teams コネクタを使用すると、アプリとフローは Teams メッセージを簡単に投稿および使用できます。 Power Appsカードは、マイクロアプリのように使用して、Teams チャネルで実用的な情報を共有できます。
SharePoint: Power Apps モデル駆動型アプリは、dataverse 行で使用できるように、SharePoint ライブラリに格納されているドキュメントに接続するように構成できます。 Microsoft Lists または SharePoint リストを使用すると、ユーザーはリスト アイテムのコンテキストでPower Automateフローを実行できます。
Power BI: Power BI分析情報は、Power Appsキャンバス アプリのコンテキストで表示できます。 モデル駆動型アプリをPower BI レポートに埋め込んで、ユーザーがPower BIを離れることなく分析情報に基づいて行動できるようにすることができます。
最新化されたアプリケーションの主要なデータ リポジトリとして Dataverse を使用すると、統合に役立ついくつかの組み込み機能が提供されます。
Dataverse のカスタム API は、インバウンド アプリケーション レベルの統合に使用できます。 カスタム API は、少量のカスタム コード ロジックに関連付けられた一意の操作を提供します。 たとえば、送信システムは
RequestNewProjectのカスタム API を使用することができ、関連するロジックは受信したデータを適切な Dataverse テーブルに配置する方法を把握しています。 送信システムは Dataverse テーブル構造から抽象化されます。アウトバウンドの統合は、Dataverse のイベント公開機能を使って行うことができます。 Dataverse は、Azure Service Bus、Azure Event Hubs、または任意の Webhook レシーバーに発行するように構成できます。 たとえば、新しい Dataverse プロジェクト テーブル行を作成すると、Azure Service Bus キューにパブリッシュできます。 また、ビジネス プロセス イベントに一致する、より概念的なイベントを発行することもできます。 たとえば、プロジェクトの完了時にイベントを定義して公開できます。
次の図は、Dataverse 環境におけるインバウンド イベントとアウトバウンド イベントの例を示しています。
組織では、Microsoft Marketplace でサード パーティから利用できる事前構築済みの統合オプションも検討する必要があります。 たとえば、マイクロソフトは、SAP と Power Platform を統合する必要がある企業向けに、あらかじめソリューションを用意しています。 この構築済みソリューションは、アプリとフローを組み込み、組織の SAP システムと Power Platform との間のコミュニケーションを促進する新しい機能を追加します。
たとえば、Ernst & Young は、事前構築済みの SAP 統合を使用して、頻度の高いグローバル財務プロセスを最適化するソリューションを迅速に開発しました。 次の図は、会社の PowerPost ソリューションの図で、財務ユーザーが Power Platform を使用して一般会計 SAP ERP システムにドキュメントをポストする方法を示しています。
統合接続オプション
ソリューションがクラウドに移行すると、オンプレミスのリソースへの接続が、最新化されたアプリケーションとの統合を引き続き機能させるために不可欠になる場合があります。 これらのアプリケーションは、異なるネットワーク環境に存在する可能性のある他の従来のクラウドリソースとも統合できる必要があります。 Power Platform は、データ ゲートウェイ、仮想ネットワーク データ ゲートウェイ、プライベート リンク、ExpressRoute という 4 つの主要なセキュア接続オプションをサポートしています。
Data ゲートウェイを使用すると、Power Apps、Power Automate、Power BIのローコード コンポーネントをオンプレミスのリソースに戻してハイブリッド統合シナリオをサポートできます。 ゲートウェイは、最新化されたローコード アプリケーションが、まだオンプレミスにあるデータ ソースにすばやくアクセスする方法を提供します。 ゲートウェイを使用すると、ローカル ファイル システム、DB2、Oracle、SAP ERP、SQL Server、SharePointなどのソースからオンプレミスのデータに接続できます。 1 つのゲートウェイで、複数のユーザーと複数のソースへのアクセスをサポートできます。 また、データ ゲートウェイをクラスターとして構成して、高可用性を実現することもできます。
ゲートウェイのサポートはコネクタの接続プロセスに統合されており、ゲートウェイが必要なタイミングを示し、構成済みのゲートウェイを選択できます。 接続が構成されると、アプリとフローはゲートウェイがない場合と同じようにコネクタを使用できます。
仮想ネットワーク データ ゲートウェイではPower BIと Power Platform のデータフローを使用して、仮想ネットワーク内の仮想マシン上のオンプレミス データ ゲートウェイを必要とせずに、Azure仮想ネットワーク内のデータ サービスに接続できます。
Azure Private LinkおよびAzureネットワーク プライベート エンドポイントを使用すると、アプリとフローはPower BIに安全にアクセスできます。 プライベート エンドポイントは、インターネットを経由するのではなく、Microsoft のバックボーン ネットワーク インフラストラクチャを使用してデータ トラフィックをプライベートに送信するために使用されます。 プライベート エンドポイントにより、レポートやワークスペースなどの組織のPower BI リソースに送信されるトラフィックは、常に組織の構成済みのプライベート リンク ネットワーク パスに従います。
Azure ExpressRoute は、プライベート接続を使用してオンプレミス ネットワークを Microsoft クラウド サービスに接続する高度な方法を提供します。 1 つの ExpressRoute 接続は、パブリック インターネットを通過することなく、Power Platform、Dynamics 365、Microsoft 365、Azure クラウド サービスなどの複数のonline servicesにアクセスできます。 ExpressRoute には大規模な計画と構成が必要であり、ExpressRoute サービスと接続プロバイダーのコストが増加します。
統合接続に使用するアプローチに関係なく、接続を評価して、統合と最新化されたアプリケーションの両方をサポートするために十分な待機時間と十分な帯域幅があることを確認する必要があります。
ビジネス ロジック
最新のアプリケーションを構築する場合、ビジネス ロジックを実装する対象と、それをアプリケーション アーキテクチャのどこに実装するかを選択できます。 ガイダンスがなければ、ほとんどの組織はビジネス ロジックの混乱に陥るでしょう。 実装の一貫性を保証する再利用可能なロジックを使用すると、モダナイゼーションの取り組みを迅速化できます。
ここでは、ビジネス ロジックをユーザー エクスペリエンスのロジックとは異なるものとして定義します。 たとえば、検査データの値に基づいて画面間を移動するロジックは、ユーザー エクスペリエンス ロジックです。 検査が完了したかどうかを判断するために実装するロジックには、いくつかの条件評価が含まれる場合があり、ビジネス ロジックと見なされます。
ローコードを含むソリューションを設計する場合、次の考慮事項は、ビジネス ロジックを配置する場所を決定する際に役立ちます。
Power Apps application: 低コード アプリケーションにビジネス ロジックを配置するのが最も簡単なアプローチですが、再利用したり、アプリと自動化間で一貫性を適用したりするためのオプションは限られています。 このアプローチは、一般に他のアプリケーションや自動化で使用する必要のない、ミッション クリティカルではない単純なロジックに限定する必要があります。 ローコード ツールでは、行ごとのデバッグ エクスペリエンスは提供されません。 ロジックが複数の画面にまたがっていたり、読みにくい場合は、より保守しやすい他の方法を検討する必要があります。 一部のビジネス ロジックが、アプリケーションとクラウドでローカルに複製されることは珍しくありません。 たとえば、ユーザーがホテルの予約を入力する場合、ビジネス ルールでは、チェックアウト日をチェックイン日より前にすることはできません。 アプリケーションがこれを検証しなかった場合、ユーザーは最後までたどり着き、予約を送信しても、カスタムコネクターがそれを拒否したことに気づくでしょう。 アプリケーションとクラウドでローカルに検証を処理することで、はるかに優れたユーザー エクスペリエンスが実現します。Power Automateクラウド フロー内: フロー内のアクションでビジネス ロジックを表現できます。フローは、イベントや他のアプリやフローからのオンデマンド要求に応答してトリガーできます。 このフローは、ロジックを一元化するためのローコード アプローチを提供できます。 フロー内のステップは独立しており、トランザクションの一部ではありません。ただし、フローはエラーが発生した場合にロールバックを処理するための補正を実装できます。 フローは、アプリ ユーザーが実行できる以上のアクセス許可を持つ接続を使用してステップを実行できるため、アクセス許可を昇格する方法が提供されます。 このアプローチでは、アプリ ユーザーが必要とする可能性のあるアクセス許可を最小限に抑えることもできます。
Dataverse プラグイン: プラグインは、作成、更新、削除などのデータ行イベントに応答して実行されます。 このロジックは、どのアプリやフローがアクションを実行したか、または Dataverse API から直接実行されたかに関係なく、イベントが発生するといつでも実行されます。 この動作の利点は、すべての用途で一貫性が確保されることです。 さらに、プラグイン ロジックによる Dataverse データの変更はすべてトランザクションで、すべて完了するか、すべてロールバックされます。 プラグインのロジックは、短くて効率的である必要があるため、実行時間の長い作業を実装しようとしないでください。 Close Inspection のような 1 つのビジネス イベントを完了するために複数のテーブルのイベントをリッスンする必要がある場合、イベントのプラグインは最適なアプローチではないことがあります。 たとえば、複数のテーブルにプラグインを持つ代わりに、Dataverse カスタム API を検討することもできます。 プラグインは、ユーザーが通常は持っていない可能性のある昇格されたアクセス許可でロジックを実行できます。 このアプローチでは、アプリ ユーザーが必要とする可能性のあるアクセス許可を最小限に抑えることもできます。 プラグインは、アプリやフローと一緒に Dataverse ソリューションで展開できます。
Dataverse カスタム API: Dataverse カスタム API を使用すると、ロジックを実行できる独自のカスタム API メッセージを実装できます。 たとえば、検査の確認と終了のすべての作業を行う際に呼び出される「Close Inspection」のカスタム API を作成することができます。 イベント ドリブンではありませんが、それを必要とするアプリやフローがオンデマンドで使用します。 イベント駆動型プラグインと同様に、カスタム API プラグインで行われるデータ変更はトランザクションです。 カスタム API は、使用するサービスが他のデータ作業用の Dataverse API のみである場合に最適です。 カスタム API 用のプラグインは、アプリやフローとともに Dataverse ソリューションで展開できます。
コード API を実装する
AZURE FUNCTIONS、Azure Container Apps、REST API をホストできる任意のサービスなど、お気に入りの API ホスティング ランタイムに API を実装できます。 これらのカスタム API は任意のロジックを実装でき、ローコード アプリケーションと従来のコード アプリケーションの両方で使用できます。 カスタム API は、使用する API によって提供されるもの以外のトランザクション サポートを提供しません。 たとえば、カスタム API では、SQL Serverを使用する場合、SQL Serverトランザクション コンストラクトを使用できます。 コード API の展開は、それを使用する可能性のあるローコード リソースとは無関係です。 Azure API Managementを使用して、これらの API の使用を管理し、検出しやすくすることができます。
セキュリティ
認証や承認などのセキュリティは、最新化されたアプリケーションのアーキテクチャに不可欠な要素です。 最新のアプリケーションは、多くの場合、従来のアプリケーションよりもセキュリティ保護が困難です。 これには複数のクラウド サービスが含まれており、ユーザーはより多様な場所からそれらを操作します。 概念的には、プラットフォームにおけるセキュリティは、データとサービスを保護しつつ、ユーザーが最小限の摩擦で必要な作業を行えるようにするためにあります。
Power Platform は、セキュリティ アーキテクチャを構築するために使用できる、セキュリティに対する多層的なアプローチを採用しています。 これらの機能の中核となる考え方は、ローコード ソリューションを既存のセキュリティ装置と統合して、導入による影響を最小限に抑えることです。
Power Platform セキュリティ モデルを構成する複数のセキュリティ レイヤーの概要をご案内します。
- ユーザーはMicrosoft Entra IDによって認証され、条件付きアクセス ポリシーを使用して使用を制限できます。
- ライセンスは、Power Platform コンポーネントへのアクセスを許可する最初のコントロール ゲートです。
- アプリケーションとワークフローを作成する機能は、環境のコンテキストでのセキュリティ ロールによって制御されます。
- ユーザーが Power Platform リソースを表示および使用できるかどうかは、アプリケーションをユーザーと共有することで制御されます。 リソースは、ユーザーまたは Entra ID グループと直接共有されます。
- 環境はセキュリティ境界として機能するため、各環境に異なるセキュリティのニーズを実装できます。
- Power Automate フローとキャンバス アプリではコネクタが使用されます。 特定の接続資格情報と、関連するサービスの権利によって、アプリがコネクタを使用する際のアクセス許可が決まります。
- Dataverse のインスタンスを持つ環境は、その Dataverse インスタンス内のデータとサービスへのアクセスを制御するより高度なセキュリティ モデルをサポートします。
- コネクタの使用は、データ ポリシーを使用してさらに制限できます。 クロステナント型の受信および送信の制限はコネクタにも適用できます。
コネクタを使用してデータ ソースにアクセスする場合、データ ソースが提供する基盤となるセキュリティすべては、上記で説明したセキュリティの層に追加されることに注意してください。 Power AppsとPower Automateは、既定では、まだ持っていないコネクタ データ ソースへのアクセス権をユーザーに提供しません。 ユーザーは実際にアクセスを必要とするデータへのアクセスのみが必要です。
Dataverse をソリューションの一部として使用する場合、多くのビジネス シナリオに適応できるロールベースのセキュリティ モデルが含まれます。 データは、データ行の個々の列に至るまでセキュリティで保護できます。 ユーザーには 1 つ以上のセキュリティ ロールが割り当てられ、これらによって全体的な特権が決定されます。 Dataverse は部署やチームなどのセキュリティ モデリングの構成要素を提供します。 たとえば、部署を使用してセキュリティ境界を定義し、組織のユーザーの 2 つの異なるグループ間でデータを分離できます。 チームを使用して、データへの同様のアクセスを必要とするユーザーをグループ化できます。 データ行のグループ所有権を割り当てることもできます。 次の図は、部署を使用して組織の部門のデータを分離する方法を示しています。
セキュリティ モデルの設計
最新化されたアプリケーションのセキュリティ モデルを、アプリケーションのアーキテクチャ全体に合わせて調整します。 単一のデータ リポジトリを使用し、コネクタを使用しないアプリケーションでは、最小限のセキュリティ設計作業で済みます。 アプリケーションがより多くのコネクタとデータ リポジトリを使用するようになると、セキュリティ モデリングに他の考慮事項を含める必要があります。
User identity: ユーザーはどのように認証を行うのか、またオンプレミスからのシナリオでそれがすでにMicrosoft Entra IDにマップされているのか？ これには、Dataverse のようなクラウド データストアでアプリケーション グループやチームの割り当てをサポートするために必要なグループのマッピングが含まれます。
コネクタ接続 ID: アプリケーションが 1 つ以上のコネクターを使用する場合、接続に対してどのようなタイプの認証が行われ、 必要なセキュリティ管理を実施するために必要なレベルの管理が行われていますか？ たとえば、サービス プリンシパルを使用して接続するアプリケーションでは、アプリケーションのユーザーがコネクタに直接アクセスする必要がないため、シナリオによってはこれが有益な場合があります。 個々のユーザー接続は、どのユーザーが操作を実行したかを把握する必要があるアプリケーションや、特定のユーザーに応答のスコープを設定する必要があるアプリケーションに適しています。
セキュリティ構造の移植性: アプリケーションがより多くのコネクターやデータ リポジトリを使用するようになると、あるコネクタのセキュ リティ構成がすべてそのまま別のコネクタに対応するわけではないことを覚えておくことが重要です。 たとえば Dataverse では、ユーザーがデータ行にアクセスする方法は複数あり、ユーザーとデータ行を共有することもできます。 アプリケーションがSharePointドキュメント ライブラリを行に関連付ける場合、ドキュメント ライブラリへのアクセスを許可するセキュリティは、Dataverse アクセスを制御するセキュリティとは別です。 これらは直接マッピングされません。 モダナイズされたアプリケーションは、使用するコネクタとデータ リポジトリ全体でこれらの種類の不一致に対応する必要があります。
人工知能
ここ数年、AI はアプリケーションのモダナイゼーションの取り組みに導入されるようになってきました。 アプリケーションをモダナイズする際には、ユーザーの生産性を向上させ、より適切な意思決定ができるよう支援する人工知能の活用を検討する必要があります。 AI を導入した結果は、より良い顧客体験にもつながり、それがビジネス成果に好影響を与えることもあります。
AI を含めるには、以前はアプリケーション ロジックの統合とカスタム トレーニングモデルの構築に手間のかかる作業が必要でした。 大規模言語モデルの可用性と能力により、アプリケーションはユーザーが答えを見つけたり、タスクを実行したりするのを助ける新しい AI の使い方を導入できるようになりました。 ユーザーは自然言語プロンプトを使用して、幅広い支援ビジネス シナリオで AI 機能を操作できます。
Microsoft は、高度な AI 技術へのアクセスを容易にするために、コア製品とサービスにコパイロットを導入しました。 Copilotは、最新の AI 手法と大規模な言語モデルを使用し、Microsoft 365、Windows、Dynamics 365、Power Platform など、毎日使用するアプリケーションのユーザーが操作できます。
プラグインで拡張する
Copilotを利用するアプリケーションのユーザーは、アプリケーション内の一般的なタスクに関するヘルプをCopilotに求めることができます。 コパイロットを拡張して、ユーザーがまだ知らないデータやタスクや、ユーザーが操作しているアプリの範囲を超えているデータやタスクを含めることができます。 Microsoft 365 Copilotは、Dataverse に格納されている Power Platform データを組み込むことができるため、ユーザーはアプリケーション間で切り替える必要がありません。 たとえば、Outlookから、ユーザーは、今日完了したすべての失敗した検査の状態更新を生成するようにCopilotに依頼できます。 Microsoft 365 Copilotは、Dataverse のネイティブセキュリティとガバナンスフレームワークを自動的に継承し、実行時にユーザーのセキュリティとアクセス許可を適用します。
プラグインとしてのコネクタ
Power Platform コネクタは、Copilotエクスペリエンスにも重要です。 コネクタはプラグインとして接続して、Copilotの機能を拡張できます。 たとえば、Microsoft 365 Copilot と Power Platform コネクタ for Jira Software を使用すると、プロジェクトマネージャーは Jira サポートチケットの状態を問い合わせ、その応答に基づいて承認の行程を進めたり、新しいハードウェアの発注処理を開始したりすることができます。 プラグインを使用すると、ビジネス プロセスとデータをCopilotと統合して、ユーザーが使用するあらゆるアプリから対話できるようにします。
自分用のコパイロットを構築する
ユーザーがアプリに Copilot AI の支援があることに慣れていくにつれ、すべてのアプリケーションに Copilot AI の支援があることを期待するようになります。 ai 開発フレームワークである Copilot スタックを使用して作成した副操縦士を含めることで、最新のアプリケーションをより魅力的にすることができます。
Power Appsで事前構築済みのCopilot コントロールを使用して、キャンバス アプリとモデル駆動型アプリに副操縦を追加できます。 データソースのビューといくつかの基本的なプロンプト情報を設定することで、独自のアプリ内コパイロットのエクスペリエンスをすばやく提供できます。
アプリケーション ライフサイクル管理
モダナイゼーション作業の重要な部分は、適切なアプリケーション ライフサイクル管理プロセスを確立することです。 多くの場合、組織はローコードの取り組みを、従来のコード ALM での作業方法に適合させたいと考えます。 Power Platform には ALM ツールが用意されているため、通常使用するプロセス内またはプロセスと並行してローコードの成果物を含めることができます。
Power Platform における ALM は、ローコード リソースの構築から始まります。 構築するリソースは、Power Platform 環境のコンテキストにあります。 環境は 1 つの Dataverse データ ストアを持つことができます。 複数の環境 (通常は開発、テスト、運用) を使用して、ローコードを含む ALM プロセスにランディング ゾーンを実装できます。 環境の数と目的は柔軟であり、組織は個々のプロジェクトのニーズに合わせて環境を調整できます。 Dataverse のソリューションは、関連するローコード リソースのコンテナであり、バージョン管理やある環境から別の環境への移行を容易にします。
Power Platform パイプラインは、展開を自動化し、継続的インテグレーションと継続的デリバリー (CI/CD) を実装するローコードのアプローチを提供します。 Power Platform はパイプライン構成時のプロセスを管理します。 管理者は、パイプラインを一元的に管理および統制できます。
組織は、選択した CI/CD ツールを使用することもできます。 Power Platform CLI は、ほとんどの CI/CD 自動化ツールで使用できるコマンドライン ツールです。 Power Platform Build Tools は、GitHub のアクションおよび Azure DevOps のタスクに対して必要なアクションを提供し、コードの少ないアーティファクトを含む CI/CD オートメーションを構築するために必要なすべての一般的なアクションを提供します。
次の図は、調査アプリを構築するチームの例を示しています。 内側のループでは、開発環境で作業し、作業内容を Git リポジトリに保存します。 外側のループは、テスト環境と運用環境で構成されます。 ビルド パイプラインは、バージョン管理されたソリューションを取得し、必要なチェックを実行し、検査ソリューション成果物を生成します。 その後、リリース パイプラインによってソリューションがテスト対象に展開され、テスターは運用環境の準備ができていることを確認できます。 承認されると、リリース パイプラインによってソリューションが運用環境に展開されます。
Dataverse からソリューションをエクスポートすると、1 つの圧縮ファイルとしてエクスポートされます。 ローコード リソースをバージョン管理に格納するには、ビルド ツールを使用して、ソリューション ファイルを個々のコンポーネント ファイルにアンパックします。 ビルドの自動化中に、ビルド ツールはバージョン管理の個々のファイルを 1 つの圧縮ファイルに結合します。
以前のバージョンのソリューションを含む環境へのソリューションの展開では、変更のみを適用するインテリジェントなアップグレード プロセスが使用されます。 このアップグレード プロセスにより、差分スクリプトやその他の方法で展開する必要があるものを決定する必要がなくなります。
モダナイズされたアプリケーションにローコードと従来のコード リソースが含まれている場合、それらを 1 つの CI/CD プロセスに組み合わせたり、個別に管理したりできます。 独立した管理により、リソースを個別に展開でき、プロジェクトチームは機敏性を高めることができます。 たとえば、ローコード アプリケーションが使用する API は、チームが破壊的変更を導入しなければ、個別に展開できます。
監視と分析情報
モダナイズされたアプリケーションは、開発から運用まで、さまざまな環境にわたる問題を診断する機能を提供する運用環境へと統合する必要があります。
Power Apps アプリケーションは開発中ですが、開発者はカスタム イベントをログに記録するロジックを含めることができます。 展開されたアプリケーションを Application Insights に接続した後、拡張機能は、ユーザーがアプリケーションを操作する際に、ログに記録されたイベントからより多くのコンテキストを含む基本的な遠隔測定を自動的に収集します。
管理者は Dataverse 環境が Application Insights にテレメトリをエクスポートするように構成することもできます。 ログに記録されるデータには、Dataverse API の呼び出し、プラグインの実行、SDK 操作、例外などが含まれます。 カスタム プラグインのロジックを作成する開発者は、より多くのカスタム遠隔測定データを直接 Application Insights に記録できます。
アプリケーション全体で Application Insights を使用することで、複数のリソースの問題を簡単に関連付けることができます。 運用スタッフは、多数の例外が検出されたときにトリガーするアラートをAzure Monitorで作成できます。 モダナイズされたアプリケーションを定期的に分析することで、さらに調査が必要な傾向を特定できます。
結論
この記事では、Microsoft Power Platformを使用してレガシ アプリケーションを最新化する利点、戦略、ベスト プラクティスについて説明しました。 組織のデジタル トランスフォーメーションの一環として、最新化の取り組みを成功させるために Power Platform のローコード機能を採用する分析情報とガイダンスを得ることができました。
レガシーアプリケーションは、組織に多くの課題をもたらします。 それらを克服するために、組織はアプリケーションのモダナイゼーションのイニシアチブに着手して、インフラストラクチャを活性化し、最新のテクノロジーを活用する必要があります。 この記事では、モダン化の取り組みにローコードアプローチを採用する方法について説明しました。具体的には、Microsoft Power Platformの低コード開発機能を使用して、最新のアプリケーションを迅速にビルドしてデプロイする方法について説明しました。
ローコードは、従来のコーダーよりも幅広い層の人々への扉を開きます。 ローコード アプローチで成功する組織の重要な要素は、アプリケーションのモダナイゼーションに関わる人々が、プロの開発者であれビジネスユーザーであれ、ローコード開発のトレーニングを受けていることを徹底することです。 ビジネスユーザーは、解決しようとしているビジネス上の問題に近づき、時間を節約する専門知識を提供することができます。 従来のコード開発者は、拡張機能を構築するためにすでに持っている手法とスキルを適用して、ローコードのギャップを埋めることができます。 私たちが「フュージョン チーム」と呼ぶものにビジネスと技術のリソースを組み合わせることで、組織は最も効果的に機能します。
この記事では、あなたのための基礎を確立します。 次のステップはあなた次第です。 いくつかの推奨事項を次に示します:
- 若干の時間を取って、あなたの組織がすでにローコードで何を行っているかを確認してください。 びっくりするかもしれません。
- アプリケーションのモダナイゼーションの機会を評価します。
- 最初の候補として適切なものを特定し、優先順位を付けます。
- アプリケーションを最新化するチームを配置します。 最良の結果を得るには、必ずフュージョン チームを使用してください。
- チームが成功するために必要なトレーニングを受けていることを確認してください。
- チームがアプリケーションを最新化できるようにしてください。
- 最新化の取り組みを振り返ってください。 それを改良し、他のレガシー アプリケーションに拡張してください。
アプリケーションのモダナイゼーションへの道のりは、組織ごとに異なります。 マイクロソフトのアカウントチームまたは Power Platform パートナーは、皆さんの体験を計画し、正しい道を歩むお手伝いをします。
リソース
- Microsoft Power Platform Premium 機能の経済的影響™の合計
- アメリカン航空の ConnectMe アプリは、お客様によりスムーズな旅行体験を、チームメンバーにはより優れたテクノロジーツールを提供しています
Power Fx のオープン ソース リポジトリが GitHub - CoE スターター キット
- Power Platform 導入の評価
- デジタル保険代理店は、Power Platform を利用して複雑な購買プロセスを自動化しています
- PCF ギャラリー
EYはグローバル金融プロセスをMicrosoft Power Platform - Azure Private Link
- Microsoft Azure ExpressRoute
- Power Platform リリース プランナー
- Microsoft Power Platform ライセンス ガイド
- Microsoft は、AI アプリと Copilot を構築するフレームワークの概要を発表し、AI プラグインのエコシステムを拡大しました