SharePoint Listsで業務改善を始めるとき、多くの人が最初に考えるのが、
「どんな列を作ろうか？」
です。
例えば問い合わせ管理なら、受付日、担当者、問い合わせ内容、回答内容、ステータスといった列を作り始めます。
もちろん、これ自体が間違いというわけではありません。
問題は、列を作ることから設計を始めてしまうことです。
実際に企業の業務改善を支援していると、後から、
- 期限が近づいたら通知したい
- この状態になったら自動でメールを送りたい
- 担当者が異動したらどうするのか
- 過去の回答をナレッジとして再利用したい
といった要件が次々に出てきます。
すると、列を追加し、Power Automateを直し、さらに別の列を追加する……ということが起こります。
最初に考えるべきなのは列ではありません。
その業務が、どのように始まり、誰が何を判断し、どう終わるのか。
ここから設計を始める必要があります。
1．最初に「業務の入口から出口」を描く
SharePoint Listsで業務システムを作るとき、最初に考えたいのはリストの列ではなく、業務フローです。
例えば、締め切り管理のような業務であれば、
Formsで登録
↓
SharePoint Listsへ保存
↓
担当者へ通知
↓
担当者が対応
↓
完了
↓
必要に応じてアーカイブ
という流れが考えられます。
ここで重要なのは、Microsoft 365の機能名ではありません。
先に決めるべきなのは、
- 誰が入力するのか
- どこから入力するのか
- 誰が処理するのか
- 途中でどのような判断があるのか
- 何をもって完了とするのか
です。
この業務フローが決まってから、初めてSharePoint Listsにどのようなデータを持たせるかを考えます。
2．業務フローから「必要十分なデータ」を逆算する
業務フローが見えたら、次に必要な情報を整理します。
ここでありがちなのが、
「あると便利そうだから、この列も作っておこう」
という考え方です。
しかし、列が増えれば増えるほど入力負荷も管理負荷も増えていきます。
考えるべきなのは、
この業務を次の状態へ進めるために、この情報は本当に必要か？
です。
| 項目 | 必要な理由 |
|---|---|
| タイトル | 何の案件か識別する |
| 受付日 | いつ発生したか把握する |
| 担当者 | 誰が処理するか決める |
| 期限 | 優先順位や通知判定に使う |
| ステータス | 現在の業務状態を表す |
| 回答内容 | 最終成果を記録する |
つまり、列にはそれぞれ役割が必要です。
3．「人が見る列」と「システムが使う列」を分ける
SharePoint Listsで業務システムを作るとき、利用者が見る情報だけを設計すればいいわけではありません。
例えば、メールで届いた問い合わせに対して自動で返信する仕組みを考えます。
利用者が必要なのは、
- 問い合わせ内容
- 回答内容
- 担当者
といった情報です。
しかし、システム側では、
「どのメールに返信するのか」
を判定する情報が必要になります。
実際の業務改善事例でも、元のメールへ正しく返信するために、Message IDのような情報を保持する設計を行いました。
利用者はMessage IDを見る必要はありません。
しかし、自動化を正しく動かすためには必要です。
このように、データは大きく分けて、
業務データ
利用者が実際の業務で見る・入力する情報
制御データ
Power Automateなどの自動化やシステム処理のために利用する情報
として分けて考えることができます。
この視点を持つだけでも、後から自動化を追加するときの設計が大きく変わります。
4．ステータスは「色を付ける列」ではない
SharePoint Listsでは、よく「ステータス」という列を作ります。
未着手
対応中
完了
といった状態を管理するためです。
しかし、ステータスを作るだけでは設計として不十分です。
本当に決めるべきなのは、
- 誰が変更するのか
- どのタイミングで変更するのか
- 変更すると何が起きるのか
です。
例えば、ある問い合わせ回答業務では、
回答内容が入力されている
＋
ステータスが「要回答」
↓
元のメールへ自動返信
↓
ステータスを「回答済み」に変更
という設計にしました。
この設計なら、回答文を書いている途中ではメールは送信されません。
最後にステータスを変更したタイミングで送信できます。
ステータスとは業務の現在地であり、場合によっては次の処理を動かすスイッチでもあります。
5．「自動化できる」と「自動化すべき」は違う
Power Automateを使えば、さまざまな処理を自動化できます。
しかし、自動化できるからといって、すべてを自動化すればいいわけではありません。
複雑な条件分岐を大量に作ると、
- フローの内容が分からなくなる
- 修正できる人が限られる
- 業務変更のたびにフロー改修が必要になる
- エラーが起きたとき原因を追いにくい
という問題が起こります。
そのため、設計時には、
機械が確実に判断できるものは自動化する
人の判断が必要なものは人に残す
という線引きが重要です。
100％自動化することが優れた設計とは限りません。
運用や保守まで含めて、最もシンプルな仕組みを選ぶことが重要です。
ツールを作ること自体が目的になってしまう問題については、「Power Automateを導入しても業務改善が進まない理由」でも詳しく解説しています。
6．「誰がメンテナンスするか」まで設計する
システムは、作った瞬間に完成するわけではありません。
組織では、担当者の異動や役割変更が発生します。
例えばPower Automateの中に、個人のメールアドレスを直接大量に設定していたとします。
担当者が変わるたびに、Power Automateを開いて宛先を変更する必要があります。
数人なら問題ありません。
しかし、対象者が増えたり、異動が頻繁に起きたりすると、メンテナンス負荷は急激に上がります。
そこで、Teams側のグループやタグ、SharePoint側のマスタ情報など、運用担当者が変更しやすい場所で宛先を管理するという考え方が必要になります。
良いシステムとは、作った人しか直せないシステムではありません。
半年後、1年後に誰が運用するのか。
そこまで考えることも設計の一部です。
7．「処理するためのデータ」と「活用するためのデータ」を分ける
もう一つ、業務システムを作るときに重要なのが、
1つのリストですべてを解決しようとしない
という考え方です。
例えば問い合わせ管理では、処理のために、
- 受付日時
- 送信元
- Message ID
- ステータス
- 担当者
- 処理日時
- 回答内容
といった情報が必要になることがあります。
しかし、半年後に社員が過去の問い合わせを検索するとき、本当に必要なのは、
- カテゴリー
- 質問
- 回答
だけかもしれません。
その場合、
業務処理用リスト
↓
回答済みデータだけを抽出
↓
ナレッジ用リスト
という設計も考えられます。
処理用のリストにはシステム都合の情報を持たせる。
利用者が参照するナレッジには、必要な情報だけを持たせる。
こうすることで、それぞれの用途に合ったシンプルな構造にできます。
SharePoint Listsの設計で考えるべき7つのポイント
- 業務の入口から出口を描く
- 必要十分なデータを決める
- 業務データと制御データを分ける
- ステータスの意味を定義する
- 自動化しすぎない
- 誰がメンテナンスするか考える
- 処理用データと活用用データを分ける
ここまで整理してから、SharePoint Listsの列を作り始めます。
設計できるとListsは「一覧表」から業務システムになる
SharePoint Listsは、単なる一覧表として使うこともできます。
しかし、業務とデータをきちんと設計すると、
業務を整理する
↓
データを設計する
↓
SharePoint Listsで管理する
↓
JSONで分かりやすく見せる
↓
Power Automateで処理する
↓
Teamsなどへ届ける
という形まで発展させることができます。
実際に、SharePoint Listsでスキル評価データを管理し、JSONによる表示カスタマイズで見える化し、その結果からおすすめ研修をTeamsへ届けるPoCも行っています。
具体的な画面については、「スキルを『見える化』するだけでは意味がない ― SharePoint ListsとTeamsで育成までつなげたDX事例」で紹介しています。
また、そもそもExcel管理をSharePoint Listsへ移すべきか迷っている場合は、「Excel管理をSharePoint Listsへ移すべき業務・移さない方がいい業務」も参考にしてください。
まとめ ― 最初に作るべきものは「列」ではない
SharePoint Listsで業務システムを作るとき、最初に作るべきものは「列」ではありません。
最初に考えるべきなのは、
この業務では、誰が、いつ、何を判断しているのか。
です。
その判断を、一つずつデータとルールに置き換えていく。
そこから、
業務整理
↓
データ設計
↓
SharePoint Lists
↓
自動化
↓
見える化
という順番で作っていく。
システム設計とは、画面を作ることではありません。
業務上の判断を、データとルールに置き換えること。
ここを最初に整理することで、SharePoint Listsは単なる一覧表ではなく、実際の業務を動かす仕組みになります。
SharePoint Listsの設計から一緒に整理しませんか？
「とりあえずListsを作ったが、列がどんどん増えている」
「Power Automateを追加するたびに仕組みが複雑になっている」
「どのようなデータ構造にすればいいのか分からない」
「将来的にTeams通知やナレッジ化までつなげたい」
株式会社uniteでは、SharePoint Listsの操作方法だけではなく、現状業務の整理、データ設計、Power Automateによる自動化、JSONによる表示改善、運用設計まで含めて支援しています。
「まだ何を作るべきか整理できていない」という段階からでも構いません。
