はじめに
今回は、よく聞かれる、SharePoint リストと比較した際の Microsoft Dataverse (以降 Dataverse) のメリットについて、私の考えを整理してみます。
データ件数の観点
まず、市民開発者の中には、SharePointリストについて、5000 件問題という言葉を聞いたことがある人もいると思います。
こちらについて、沢山の人が有益な情報を書いてくださっており、インデックス列を設定するなど、少なからず回避策があります。
個人的に以下の情報がとても参考になると思います。
また、問題が発生するかどうかについて、上述の回避策を講じるかどうかはもちろん、Power Apps のアプリの作りにもよるところもあり、SharePoint リストのデータが 5000 件を超えたら直ちに問題が発生するというわけではございません。
例えば、アプリからはデータの登録をするだけの場合、SharePoint リストのデータの件数が 5000 件を超えてもアプリの動作上は特に問題はないです。
また、委任についても考慮が必要です。委任について、別記事でも書きましたが、以下のようなイメージです。
上記画像は、SharePoint リストと Excel の比較ですが、委任できる処理 (関数) かどうかについては、データソースにより異なります。
例えば、SharePoint リストに対して委任できる処理は以下に記載がございます。
全てを覚える必要はないですが、Dataverse と比較すると委任できない処理が多いです。
その中でも特に問題になりやすいと個人的に思うのは、Search 関数です。Search 関数は名前の通り、データソースの文字列を検索します。
そして、残念ながら現状 SharePoint リストに対して Search の処理を委任することができません。
委任できない際の問題点について、データの件数が多い場合、正しい結果が得られないという点があります。具体的な件数については、以下の設定に依存しますが、現状、既定値 500、最大値 2000 です。
そのため、例えば、既定値の状態で、委任できない Search 関数を使用したものの、データの件数が 5000 件あった場合、500 件しか処理されず、本来あるはずのデータがヒットしない結果となります。
Search 関数の代わりに、StartsWith という処理は委任可能ですが、こちらは、先頭の文字が一致する場合ヒットするため、本文を検索するときなど、検索としては不十分と思います。
こちらについても、厳密には、裏技的な回避策が全くないわけではなく、また、アプリの要件次第 (例：アプリ起動時に期間などでデータを Filter して 2000 件未満にして一旦コレクションに格納した上で Search する) では回避できることもあると思いますが、難易度が高くなると思います。
上記を踏まえると、Power PlatformのデータソースとしてSharePointリストを用いる場合、データ件数が数千件を超えると取り扱いが複雑化すると思います。そして、この点を十分理解して開発するのは、市民開発者、特に、入門者の方にとって難易度が高いと感じます。
また、後述するパフォーマンスの観点含め、個人的には、SharePoint リストを Power Platform のデータソースにする際は、基本的には、データ件数の目安としては数千件程度に留めておくのが良いと考えます。
パフォーマンスの観点
以下の記事にも記載がある通り、Power Platform からの接続という観点で、SharePoint リストと比較すると、Dataverse の方がパフォーマンスが良いです。
端的に言うと、例えば、Power Apps から Dataverse に接続する場合、同じ Power Platform のサービスのため、API management を介さずに接続するためです。
SharePoint リスト等に接続する際は、内部的に、API management 等を介して接続しております
どのくらい違うの？という点について、例えば、アプリの作りにもよりますし、サービスとしてどの程度差が出るという点について保証はしていないため一概には言えませんが、以下記事の検証結果が少なからず参考になると思います。
ソリューションに追加できる
まず、Power Platformを使用して何らかの業務を改善・効率化したい場合、その目的を達成するために必要なものがアプリとテーブル一つだけとは限りません。
例えば、こちらは、先日社内で実施した Power Platform のアプリコンテスト用のソリューションですが、アプリ 3 つ、フロー 3 つ、テーブル 5 つほどの構成となっています。
Dataverse の場合、こちらのソリューションに含めることができます。
ソリューションに含めることができるということは、エクスポートして、異なる環境やテナントに対してインポートすることが可能です。
例えば、以下のような要件や依頼があった際、Dataverse をデータソースとして利用している際は、データソースごとソリューションをエクスポートしてインポートすればよく、非常に楽です。
- 何らかの理由で社内でアプリを別の環境に引っ越ししないといけない。その際、データソースも別にする必要がある
- 本番リリース前にテスト用から本番用にデータソースを変更する必要がある
- 別部門の方から似たようなアプリを作成したいのでアプリの雛形がほしいと依頼された
- プロジェクトで作成するアプリについて、開発環境と本番環境を分ける必要がある
しかし、SharePoint リストの場合、データソースの作り直しが必要になります。この際、基本的にテーブル名や列名などは同じにする必要があり、また、Power Apps や Power Automate から再接続する必要があるなど、正直非常に面倒です。
リレーションシップ
アプリを作成する際、必ずしも、テーブルは一つとは限りません。
例えば、上述のコンテスト用のアプリでは、テーブルが 5 つでしたが、このような際に、テーブル間で関係性を持たせ矛盾が発生しないようにする必要があります。
例えば、こちらのアプリコンテスト用のアプリの場合、誰がどのアプリに良いねしたか、矛盾が生じないようにする必要があります。
そのため、投票テーブルには、エントリーアプリテーブルのアプリの一意な情報を格納する列が必要になります。
こちらを容易に実現する手段として、リレーションシップという仕組みがあり、Dataverse では、もちろん、リレーションシップの設定をすることが可能です。
SharePoint リストの場合、以下のような参照列という仕組みがありますが、厳密には、リレーションシップではなく、あくまで個人的な見解ですが、ちょっと使いにくいです。
そのため、テーブル数が多い場合、参照列を沢山使って SharePoint リストで構築するよりは、Dataverse を利用した方が良いと思います。
オートナンバー
例えば、新しい注文データが追加されたら自動で、番号が重複しないよう、決められたフォーマットで番号を割り当てたいといった要望をいただくことがあります。
こちらの要望について、Dataverse の場合は、オートナンバーという種類の列を利用することで満たすことができると思います。
しかし、SharePoint リストにはオートナンバーという種類の列はございません。そのため、例えば、既定で存在する ID 列を利用して、Power Automate で強引に作成するなどの工夫が必要になりますが、個人的にはあまり現実的ではないと思います。
モデル駆動型アプリ
Excel ライクなアプリを作りたい、様々な列で、検索、フィルターをしたいといった相談をいただくことがあります。
テーブルの数が多い場合、キャンバスアプリで作成しようとすると、ものすごく面倒くさいです。
以下は、モデル駆動型アプリの例ですが、このようなアプリについて、テーブルおよびテーブルのビューやフォームを作成すれば、あっという間に作成することができます。
こちらの記事で紹介したアプリの管理用アプリです
モデル駆動型アプリについて、以下のような手順で作成できます。もちろんノーコードで数クリックレベルで作成できます。最初少しとっつきにくいかもしれませんが、慣れたら本当に楽です。
また、モデル駆動アプリにビジネスプロセスフローを追加し、業務プロセスを標準化することも可能です。
個人的に、管理向けのアプリとしてよく利用していますが、このようなアプリが簡単に作れるのも Dataverse のメリットと考えます。
また、以下のように、モデル駆動型アプリから直接 Excel を開き編集できる点も魅力です。使い慣れた Excel のインターフェイスで一括でデータの更新が出来ます。
インターフェイスは Excel ですが、データの反映には多少時間を要します。当たり前ですが、Excel ファイルのセルへの反映ではなく、データベースにデータを反映させているためです。
データ移行の観点
既存の業務で利用しているデータを移行したい、しばらくの間データを同期したいという要件もあると思います。
例えば、行数の多い Excel をマスターとしている業務があり、そちらを Power Platform で活用したいという要件もあると思います。元々別システムにデータがあり、そちらには直接接続できず、定期的にエクスポートしたデータを Exce で管理している場合もあると思います。そのような際、以下で紹介しているデータフローが便利です。
SharePoint リストの場合は、現状、Power Automate でインポートする方法が考えられますが、以下のような要件がある場合、大変になってくると思います。
- テーブルが複数あり、テーブル間でリレーションシップ（関係）がある
- しばらくの間データを同期する。その際、データの変更や削除も発生する
また、インポートしたいデータが csv ファイルで、定期的にファイルが生成されるような場合においても、データフローの場合、以下のような方法で実現できます。
データフローを作成し、自動更新するようにして、上述のモデル駆動型アプリを作成すれば、ノーコードベースでデータの一元管理が可能になり、Power Automate や Power BI を活用することで、その他データとの連携や可視化も可能になります。
テーブル作成の作業工数の観点
Dataverse では、以下のように Excel ファイルをアップロードするだけで Dataverse のテーブルを作成し、そのままアプリを作成することができます。
更に、以下のように自然言語ベースでテーブルを作成することもできます。
そのため、列を一つ一つ作成する必要がなく、SharePoint リストと比較すると、テーブルの作成、初期データの投入等の作業工数を大幅に削減できます。
以前は簡単と思っていましたが、個人的に、これらの機能が出てきてから、SharePoint リストで列を一つ一つ作成するのが凄く面倒に感じるようになり、ちょっとしたサンプルアプリやデモ用のアプリを作成する際含め、基本的に Dataverse でテーブルを作成するようになりました。
SharePoint リストの場合、基本、一つ一つ列を作成する必要があり、また、列名は英語名にする必要があり、英語に慣れていない方だと、列名を一旦英語で考え、作成後日本語に戻すなど、個人的に結構面倒くさいと思います。
※テンプレートのリストを使う場合やスクリプトや API 等を利用する場合は除く
アクセス権制御の観点
アプリで利用するデータが重要な場合、アクセス権制御について色々要件が出てくると思います。例えば、作成したアプリ以外からは SharePoint リストにアクセスされてデータを操作されたくないという要望をいただくことがあります。
以下の記事で対策を書いていますが、こちらの記事にも記載している通り、SharePoint は情報共有基盤です。そのため、アクセス権がある場合、情報を見つけやすく、アクセスしやすくなるよう、様々な導線が引かれているため、その点については念頭に置いておく必要があると思います。
また、組織の全ての市民開発者の方が、SharePoint の動作や設定変更方法を十分に理解し、徹底することは簡単ではないことも念頭に置いておく必要があると思います。
Dataverse の場合、例えば、個別の環境内で作成したアプリの利用は可能ですが、その環境でアプリを作成したりテーブルを作成したりすることは出来ないようにすることで、作成したアプリ以外からテーブルを直接操作されることを制御できます。
こちらについて、以下の記事でも触れているため、参考にしていただければと思います。
それ以外にも、SharePoint リストと比較すると、部署を利用したアクセス制御や列レベルのセキュリティ、アクセスチームなど、Dataverse はアクセス権の制御の観点で多くのメリットを持っていると考えます。
まとめ
今回は、SharePoint リストと比較した際の Dataverse のメリットについて整理してみました。
もちろん、SharePoint リストを利用する場合においても、様々なアプリやフローと連携し業務改善・効率化可能です。
しかし、要件次第では、Dataverse を利用する方がメリットがあるという場合もあるため、利用するデータソースを見極める際の参考にしていただけると幸いです。