これは Microsoft の SharePoint コンサルタント (MCS) の話です。
SharePoint のリストに未読既読の機能をつける。しかし、その設計、ヘンじゃない？
Microsoft のコンサルタントが間違え、大手 Sier が鵜呑みにした実話です。
お知らせリストに既読機能を付けたい
私が技術支援で要件定義と基本設計で参加した、大企業への SharePoint 導入のお話です。
SharePoint のお知らせリストに、ユーザーごとの既読の機能をつけたいという話がありました。
SharePoint の標準機能にはその機能は無いので、開発する方向で検討する、という話になりました。
既読ユーザーを別途管理する形になりますが、Microsoft の MCS の方が来て、わざわざ実装サンプルを作っていただきました。
内容にびっくり
MCS 「別途データベースにテーブルを作って既読ユーザーを記録する方式だと非常に負荷がかかるので、リスト アイテムの中に列を作り、既読ユーザーを格納することにしました。アイテムが表示されると、このリストの列の中にそのユーザーが追加されます。」
私はここで非常に違和感を抱きました。
この実装方式のほうが格段に時間がかかるのではないか？
今回のプロジェクトチームは、女性のプロジェクト マネージャーと若い 1 人の SE、若い 1 の開発者という、SharePoint 専門家の3人組が主体となるチームでした。
当然、疑問に思ったと思いきや、・・・その開発者も PM も納得の表情です。
私は超絶違和感があったため、その後すぐに検証したところ、ユーザーが一人二人の時は、さして時間はかかりませんでした。しかし、100 件のアイテムにそれぞれ 2000 人のユーザーを既読済み登録すると、案の定1 アクセスで表示に 15 秒かかりました！！
表示確認は特に負荷をかけたわけでもなく、単にブラウザを開いただけです。
一方、別途未読既読を記録するテーブルを使った場合は、ものの数秒しかかかりません。その差は歴然でした。
結局、この私の検証でこの話はお流れになり、無事惨劇を逃れたわけです。
この事件では困ったことが 2 つあります。1 つは、これを提案したのが Microsoft の MCS であったことと、今回の大手 Sier で専門家を掲げる集団が開発者含め一切それを疑わなかったことです。
イメージで判断しない
技術的な話に移りましょう。
SharePoint のリストは、見た目は相関データベースのテーブルですが、列はリストごとに可変です。そして、リストごとに専用のテーブルができているわけではありません。
つまり、内部的には列を型情報とともに建持ちするような、非常に複雑な構成を取っています。
さらには、SharePoint の [ユーザー型] にフィルタをするというのは複雑で、対象ユーザーや権限制御とは仕組みが異なります。
困ったことに、大手ベンダーの SharePoint 技術者も、これに対して疑問を持たなかったのです！
設計士、アーキテクトはしっかりした感覚を
SharePoint に会議った話ではありません。複雑なフレームワークとアーキテクチャを噛ませたアプリケーションでは、このセンスが非常に重要になります。Microsoft 自身は大手の Sier に比べればシステム導入にかかわることは少ないので、今回の件がわからなくて当然です。MCS のかたも頑張って作っていただいたのでしょう。しかし、大手 Sier 側は、SharePoint でも有名な大手企業であったにもかかわらず、技術者の基本的なアプリケーションに関するセンスが鈍感であったわけです。そもそも検証を検討するべきです。
IT の基礎が欠けた感覚に違和感を持ちました。技術者の審美眼をぜひ鍛えておきたいところです。