はじめに
SharePointのドキュメント ライブラリ、こちらはメタデータとして様々な情報を、ファイルに追加できる利便性の高い機能です。
この機能によって、ファイルの検索性が向上するなど、ファイルサーバーとは一線を画した機能ものとなります。
ファイルサーバーをそのまま踏襲せず、メタデータ機能を活用しましょう。
これがなければ、SharePointベースでファイル管理をするにも、その恩恵を受けることができません。
メタデータをどこまで入力するか
メタデータの利便性を述べましたが、
どこまでメタデータを入力するか
ここは悩みどころでしょう。
一定の内容にかかわる情報を列挙したときに、
その案件を特定するIDや件名、種別といった情報が必要になりますし、複数のファイルに同じ情報を入力することも手間です。
ケーススタディで考えてみます。
ケーススタディ：裁判沙汰・折衝履歴
例えば、裁判沙汰の折衝を挙げてみましょう。
※一回もであったことのない事案です、完全に想像です。
架空の事案です。
内容証明やら手紙が飛び交う世界です。
PDFがひたすら蓄積されていくことでしょう。
このファイル管理を方法を考えていこうと思います。
まずは「架空のシナリオ」を作ります。
ChatGPTに以下を入力。
架空の裁判に通じた労働紛争のストーリーを検討してください。
上司Ａによる管理不足により、部下Ｂの心身への負担・日時につながったことから、部下Bから上司Ａとの労働紛争につながったケースです。
内容証明で情報のやりとりをすることを想定します。
ストーリーを作成してください。
さすがGPT・・・
作成されたストーリー
ストーリーの背景
- 登場人物: 上司A（管理職）、部下B（従業員）
- 場所: 中規模の企業
- 時期: 現代
紛争の発端
- 上司Aの管理不足: 上司Aは、部下Bの仕事量と期限に対するリアルな評価を怠っていました。これにより、部下Bは過度のストレスと過労を経験し、心身の健康に悪影響が出始めます。
紛争の激化
- 部下Bの反応: 疲弊し始めた部下Bは、上司Aに何度も労働条件の改善を求めますが、その要求は無視されたり、不十分な対応がされたりしていました。
- 健康問題の発生: その結果、部下Bはストレスによる健康問題を抱え、仕事を休むことになります。
法的措置
- 内容証明の使用: 部下Bは、労働環境の改善が見られないため、法的措置に訴えることを決意します。部下Bは弁護士と相談し、上司A及び会社に対して内容証明を送ることにします。
- 内容証明の内容: 内容証明には、不適切な管理、労働条件の改善要求の無視、心身への影響などが詳細に記載されます。
紛争の解決
- 会社の反応: 会社は内容証明を受け取り、部下Bの主張を真剣に受け止めることにします。上司Aの管理方法を見直し、部下Bの労働環境を改善するための措置を講じます。
- 和解: 最終的に、部下Bと会社は和解に至り、部下Bの労働条件は改善されます。上司Aには追加の管理研修が行われ、今後このような事態を避けるための策が講じられます。
結論
このストーリーは、職場での適切な管理とコミュニケーションの重要性を浮き彫りにします。また、労働者が直面する問題に対処する際の法的手段の有効性も示しています。
さて上記のストーリーをまずはファイル化します。
この概要をPDFファイルに変換してください。
日本語だと失敗したので、英語に翻訳してトライしてみます。
できました。
すごいですよね、本当に。
この要領で
- ストーリーの中の内容証明
- 会社の返信
- 和解の証拠資料
- 顛末書
を作成します。
本当にできたよ。おそろしいわ。
GPT先生は2023.12.23段階で日本語が苦手です
ケーススタディに対応する仕組みづくり
ドキュメントライブラリを設計
ここで新しくドキュメント ライブラリを作成します。名前はCaseFilesDocsとしました。
メタデータ・列を追加する場合、そのドキュメントライブラリ全体に追加されます。
メタデータが不要な場合、必要最小限に追加して管理する方法が私はいいと思っています。
格納する情報の属性に合わせたドキュメントライブラリの設計ですね。
ということで、下記のようなドキュメント ライブラリを新規で追加します。
| 項目 | 名前 | 属性 | コメント |
|---|---|---|---|
| 名前 | 名前 | 1行テキスト | 固定列（ファイル名） |
| 種別 | Category | 選択肢 | ファイルの種類を選択 |
| 備考 | Comment | 複数行テキスト | ファイルにつけたいメモ |
| 参照列 | case | 種別 | 後述 |
さて、今回事件に携わる管理としました。
となると、発生日時や事件名、事件IDが必要になりますね。
しかしファイルを複数格納するとなると、ファイルの数だけ同じ情報である発生日時などを入力するのは嫌です。
そこでリストを組み合わせてみます。
目録としてのリスト
ここでSharePointリストを活用します。
ドキュメントライブラリに格納する情報の目録して利用します。
リスト名はCaseFilesとでもしておきましょう。
やりづらさはありますが、やっぱり英語で管理した方がラクです
こちらで下記の項目を管理します。
ファイルに付帯する固定情報ですね。
| 項目 | 属性 | コメント |
|---|---|---|
| 事件名 | 1行テキスト | タイトル列をリネーム |
| 事件ID | 1行テキスト | 固定IDとして表記 |
| 担当者 | ユーザー列 | やっぱり便利 |
| 発生日時 | 日付と時刻 | 一応 |
| 区分 | 選択肢 | ケースの区分に使います |
| 概要 | 複数行テキスト | メモは何か残したくなるもの |
| Hyperlink | ハイパーリンク | Power AppsのPower upに利用 |
目録があるのであれば、その情報に紐づくフォルダへのアクセスも目録から
参照したいものです。
ここで業務手順を考えてみましょう。
業務の流れ
- SharePointリストで案件を登録する
- フォルダが自動でできる
- ドキュメントライブラリへのハイパーリンクができる
- ドキュメントライブラリでファイルを管理する
- メタデータの付与
こんな流れを想定します。情報が分散することが残念ですし、
紐づけというイメージが湧きにくい。
少しずつまともなものに変えていきます。
ドキュメントライブラリにルックアップ列（参照）を追加する
ドキュメントライブラリにSharePointリストをソースにしたルックアップを追加します。
この機能大好きなんですよね。
ソース元から情報をルックアップ、ExcelでいうXLOOKUPができます。
ここでリストの情報を持ってきましょう。
間違いなく一意の値になるSharePointリストのIDをキーにします。
※ フォルダの作成の際に、このIdでPower Automateに仕込みます。
ドキュメントライブラリでも、案件の情報がわかるようになりました。
子アイテムへの情報継承
ドキュメントライブラリの子アイテムにもルックアップの情報が自動で入ってほしいものです。
こちらもPower Automateでルックアップ用のIDを、親であるフォルダから継承します。
※2 フォルダの作成の際に、このIdでPower Automateに仕込みます。
ファイルが追加されるたびに自動で更新されるので、重複した入力が省けました
このような管理体制になりました。
しかし毎回、ドキュメントライブラリに、その固定的な情報を入力するのも手間。
Power Appsによる情報の統合
SharePointをだいぶカスタマイズしてきましたが、
追い打ちでPower Appsのビューを作ります。
なんだかんだ縦長でまとめて見れたら嬉しいですからね！
データソースを解説すると
SharePoint Listsとドキュメントライブラリの実質的なデータの紐づけですね。
同じIDを共有することにより、リレーショナルなデータ管理となっています。
簡易的なクエリです。
呼び出すだけで、SharePoint Listsおよびドキュメントライブラリ、
またその中のファイルのアイテムのリンクも取得できることから
Launch(ThisItem.アイテムへのリンク)
こちらでListsもファイルも簡単に開くことができます。
これをどうやって呼び出す？？
さてAppsでビューを作っても、これどうやって呼び出すのやって話ですね。
ここから
- SharePoint Listsのカスタマイズ
- Power Appsの関数活用
に展開していきたいところですが・・・今日は力つきました。
次回のお楽しみとさせてください。
良いPower Lifeを！