SharePointリストとMicrosoft Lists。市民開発ならSharePointリストがおすすめ

Power AppsやPower Automateのデータソースとして使う、SharePointリストとMicrosoft Listsの違いを整理します。

どちらを使うか迷った場合は、個人的にはSharePointリストがおすすめです。その理由をこの記事で解説します。

機能に根本的な違いはない

SharePointリストとMicrosoft Listsに、機能的な大きな違いはありません。どちらもデータソースとして使えますし、見た目の違いもほとんどありません。

では何が違いなのかといえば、アクセス権の管理の方法です。

アクセス権の違い

まずSharePointリストは、特定のSharePointサイトの中に作成されます。サイトにアクセス権のあるメンバーであれば、基本的に誰でも編集権限を持っています。

一方のMicrosoft Listsは、作成者のOneDrive (for Business)の中に作成されます。アクセス権は基本的に作成者にしかなく、明示的に共有しない限り他人がアクセスすることはできず、URLを知られる心配もありません。

SharePointリストを使って開発する人の多くは、この誰でも編集権限がある状態を嫌います。これはSharePointサイトとリストの構造上、そういうものだと割り切るしかありません。（もし組織のポリシー上でサイトのアクセス権限を自由に変更できるのであれば対応策は存在します）

ですので、アクセス権を自由に設定できるMicrosoft Listsをデータベースとすれば、Listsごとにアクセス権を設定し、データの改変を防ぐことができるわけです。

しかしMicrosoft Listsは、後々ユーザー管理の煩雑さがネックになってくると思われます。

Microsoft Listsは数が増えると管理が大変

市民開発が進み、アプリもユーザーも増えてくると、ユーザー増減時のMicrosoft Listsのアクセス権管理が大変です。

Microsoft Listsが1つ2つならまだいいですが、アプリが増えていくにつれてListsも増えていきます。新しいメンバーが増えるたびに、すべてのListsにアクセス権を付与しなければならず、メンバーが抜けるたびに全部のListsから権限を削除する必要があります。

個人的には、このユーザー管理の手間を考えるとSharePointリストのほうが長期的な運用に向いていると感じています。SharePointサイトのメンバー管理だけで一括管理できるからです。

リストのアクセス権を変更するには

どうしてもSharePointリストのアクセス権を変更したい場合、以下の手順で対応できます。

1. STEP

   アクセス許可の管理を開く

   

2. STEP

   ユーザー、またはグループどちらかでアクセス権を変更する

3. STEP

   アクセス権の変更完了

この順番でやればリストごとのアクセス権を変更できます。

このやり方のデメリットは大きく2つあります。

1. アプリからも編集できなくなってしまう

編集権限を制限すれば、当然アプリやPower Automateのデータソースとして使うことができなくなります。閲覧のみ可能とすれば、ツールの用途によってはそれで事足りるかもしれません。

しかし閲覧するにしても、リストの保存場所を知られていると直接リストにアクセスされ、中身全部を閲覧されてしまいます（編集はできませんが）。

2. アクセス権の管理が大変

サイト内のリストが増えると、アクセス権の管理が煩雑になってしまいます。Microsoft Listsの管理よりかは幾分ラクかもしれませんが、人が変われば面倒に感じてくるかもしれません。

以上の2つの理由から、リストのアクセス権を変更するのは個人的にあまりおすすめしません。企業によっては、リストのアクセス権を変更してはならないと決められている可能性もあります（私が所属する会社はそうです）。

開発専用のSharePointサイトを使う

アクセス権の問題を解消するおすすめの方法は、開発専用SharePointサイトを使うことです。アプリ開発に使うリストを専用サイトに集約し、そのサイトへのアクセス権を持つメンバーのみがデータを扱える環境を作ります。

この方法であれば、サイトメンバーの増減管理だけで対応できます。委任問題や5,000件の上限については別途考慮が必要ですが、アクセス権管理の煩雑さからは解放されます。

ただし1つ注意点があります。Teamsを使うと、チャネル-ファイル-三点リーダーから辿ることでSharePointサイトにアクセスできてしまいます。

このTeamsの問題を解消するには、もう1つ別にSharePointサイトを作成し、そちらにも開発サイトと同じメンバーを登録し、そこでTeamsを使います。メンバー増減時の手間は増えますが、こうすれば開発サイトとコミュニケーションサイトを分離し、データソースへのアクセスを限りなく隠したまま進められるでしょう。

SharePoint ListsとPower Appsを使ったデータの読み書き（追加・更新・削除）の具体的な実装方法については、Power AppsでSharePointリストのデータを読み書きする記事で詳しく解説しています。あわせて参考にしてください。

また、フォームコントロールを使ったデータ入力・編集については、Power AppsのEditForm・NewForm・DisplayFormの記事も参考になります。

Dataverseを使う

Dataverseであればデータソースへのアクセス管理を細かく設定できます。SharePointリストのように頭を悩ませる必要はありませんし、Dataverseを利用できる環境であれば迷わず使用することをおすすめします。

ただし、Dataverseはプレミアムライセンスが必要で追加費用がかかります。また委任問題がないなどの利点はある一方、使いこなすための学習コストも高いです。まずはSharePoint Listsから始め、要件に応じてDataverseへの移行を検討するというのが現実的なステップだと思っています。

Power Apps全体のデータソース選びや開発の全体マップについては、Power Apps開発の全体マップ記事でまとめて解説しています。あわせて参考にしてください。