Art-Break .log : Taichi Nakamura
Microsoft 365 ( Office 365 ) ・ Power Platform ・その他の情報発信ブログ
※自己責任でお願いします。
これまで僕は3回ほど Microsoft Teams のデスクトップアプリの調子が悪くなったことがあります。1・2回目はどういう症状だったか忘れました…。3回目はつい数日前から設定画面のタブを切り替えたりデバイス設定でデバイスを変更しようとするとアプリが固まって落ちて再起動する挙動が頻発しました。オンライン会議前にこうなると会議に遅刻してしまう恐れがあるので解決に向けて色々試しましたが、この3回のトラブルとも僕の場合はデスクトップアプリを再インストールする事でトラブル解消されました。で、特にPC初心者の方は、デスクトップアプリのアンインストールや再インストールの方法がわからない人もいると思うので、備忘録も兼ねて僕の方法を紹介します。
“Microsoft Teams ：デスクトップアプリが不調な場合は再インストールしてみると良いかも？” の続きを読む※長文の文章のみとなります…。
「部門ポータルの掲示板（リスト）に掲載したアノ情報だけど、全従業員にも見てもらいたいから社内ポータルの掲示板にも掲載しておいて！」
上司からそう命じられて、部門ポータルのリストに投稿したアイテムと全く同じ情報を、コピペで社内ポータルのリストにも投稿しました。
よくある話だと思いますが、実際にトラブルにつながる可能性があります。
「掲示板に掲載されていた自社製品情報をお客様にお伝えしたところ、後日、それが古い情報で損害が出たとのクレームを受けた。」
信頼に関わるトラブルですね。調べてみると、部門ポータルと社内ポータルに両方に同一タイトルのアイテムが投稿され、その後情報が変更された際に、部門ポータルのアイテムは更新されていたが、社内ポータルは更新されていなかった。投稿者に話を聞くと、両方に掲載した事を失念しており、部門ポータルのみを更新したとの話。
十分ありえる話ですよね。
ここでの問題は社内ポータルの更新を失念した更新者…もありますが、投稿を多数行っている人にその問題を押し付けるのはかわいそうですね。運営面から考えると、同一情報を複数個所に掲載しているという点です。これはメンテナンスが大変だし、トラブル事例のようにヒューマンエラーの可能性が上がります。特に、投稿者が退職などすると余計ありえますね。
※以下は、あくまでも解決のための一例です。
ここでタイトルの通り、情報の一元管理が大事です。ただし、部門ポータルに掲示した情報を社内ポータルにも掲示するな！という事は言いません。
まず考えるべきはその情報をどこに保管するのが一番ふさわしいか？です。
今回はまず部門ポータルに掲載されたことからも、またその部門発信という事からも、またその部門がサイトを所有しているということからも、部門ポータル内に情報を掲載する事で良いと思います。
次に一元管理しつつ全従業員にも見てもらうには？
社内ポータルの掲示板を利用しても良いと思いますが、大事なのは掲載方法です。ここでコピペで同じ情報を掲載すると二重になってしまいます。ただ、Webの醍醐味は「リンク」なので有意義に使いましょう。つまり、社内ポータルに掲示する本文には詳細内容を記載せず、概要のみと部門ポータルに掲示したアイテムのURLのリンクを起きましょう。そうすれば、リンク先の部門ポータルの掲示したアイテムのみをメンテナンスすればOKなので、更新し忘れはなくなります。
例で考えると、社内ポータルの掲示板のアイテムにアクセスしたユーザーには、更にワンクリックを強要してしまう事になります。Webサイトの場合、ユーザーアクションをいかに減らす事を考慮しますが、ただし SharePoint に関してはWebサイトの考えがそのまま当てはまるわけではありません。つまりユーザーにとって本当に重要な情報であれば、離脱せずにワンクリックするからです。クリックされないならそのユーザーにとってはその程度の情報なのです。そういう意味でも大きなデメリットとは思えません。
次に、情報源であるリンク先のアイテムを移動したり削除されたら？
たしかにリンク元からはデッドリンクになり情報にたどり着きません。ただ、しつこいようですが本当に必要な情報であれば、リンク元アイテムの投稿者に連絡するなりします。更新し忘れて誤情報を元にトラブルになるリスクを考えれば、デッドリンクになった方がまだリスクは低いと考えます。もちろん、ユーザーからデッドリンクになっている連絡が来たら、投稿者がリンク先を更新すれば良いだけですし。
ユーザー目線で考えてみましょう。社内ポータルの掲示板を従業員が読んだとして、その情報が自分にとって必要と判断すれば読むでしょう。そこにリンクがついていればリンク先に行きます。例えばそこで「こんな部門ポータルもあったんだ！」と気づく場合もあります。自分に関連する情報であれば他の情報も気になる可能性もあります。そうすると初めて訪れたその部門ポータルの別のコンテンツも見る可能性もあります。つまり、利用者が増える可能性があがるわけです。
情報の一元管理が適切にでき、本来保管すべき場所に情報が鮮度を保たれて保管され、更に自分のサイトのPRにもなれる。
このような運営方針を投稿者レベルまで落とし込んで啓蒙しクセをつけてもらう事により、より安全な運営ができるのではないでしょうか。投稿者が多ければ多いほど、徹底させるのはなかなか難しいですけどね。
SharePoint は多機能なので使いこなせば便利ですが、その場合、IT部門やサイト管理者がSharePoint に詳しいだけではダメで、このブログ内では何度も書いていますが、利用者の中でも大半を占める投稿者・閲覧者に対しても、最低限の教育をしなければいけないと思っています。
その中で投稿者が機能を把握していないがために起きたトラブルを紹介します。実際に様々な場面で見かけていますが、投稿者が悪いわけではありません。
■トラブル
「ライブラリにファイルをアップロードしているが、本人以外は表示されない！」
という問い合わせがありました。実際確認したところ、知らずに1年以上合計数十ファイルをアップロードしたが共有できていない事が判明しました。
これは必須の設定をしている列のあるライブラリに起きやすいトラブルです。
実際に検証してみましょう。
▼ライブラリに「コメント」という列があり、必須に設定しています。
▼エクスプローラーからファイルを選択する方法の場合は
▼アップロードする前に必ずプロパティを埋めるよう促されるので問題ありません。※1
▼この場合はファイルはアップロードされ、投稿者以外にもファイルが表示されています。
▼ファイルをビューに直接ドラッグをした場合
▼必須列に入力を促す警告もなく、アップロードが完了いたしました。ただし、本人以外のユーザーがアクセスしても該当ファイルは表示されません。
※画像が小さくて申し訳ないですが、投稿者以外のビューには１つしか表示されていません。
▼このままアップロードし続けるも、結果的に本人以外には共有されていない状態です。
これは、必須列が未入力だとチェックインができない仕様で、チェックインされないと本人以外には表示されない事が原因です。
ビューに直接ファイルをドラッグするとアップロードさせる仕組みはたしか SharePoint 2013 から実装された機能かと思いますが、Windowsのエクスプローラーのように複数ファイルを1度にアップロードできたりして便利なので、この方法でアップロードするユーザーは多いと思います。
リストを作成したサイト管理者が、ファイルをアップロードしたら必ず入力して欲しい意図があり必須と設定した列があったが、直接ドラッグしてファイルをアップロードするとこのような挙動になることまでは把握せず、特に投稿者に意図を説明しませんでした。
チェックアウト状態であるとドキュメントのアイコンの右下に矢印の付くアイコンになりますが、SharePoint をよく知らないユーザーがこれだけでこのトラブルに気がつくとは思えません。
困った事に、チェックアウト状態はサイトコレクションの管理者であっても、本人でなければ表示されないので、この違和感を本人以外が気がつきにくいこともあります。
※たとえサイトコレクションの管理者であっても、アップロードした本人でない場合は、ビューの表示は右側です。
さて、どうしたらトラブルを避けられるか？
■リスト作成時
■投稿者への教育
■サイト管理者の日常
などなど、複合的にトラブルを避けられる方法がありますが、それぞれの環境に合わせて出来る範囲で回避策を実行すれば良いと思います。
しかし、日本企業にありがちですが、やはりIT部門やサイト管理者などが色々苦労して社員（投稿者・閲覧者）を楽にさせようとするのは、最終的には社員のIT（SharePoint）リテラシーの鈍化につながるので、個人的には好ましくないです。
IT部門やサイト管理者などが開発や管理などで対応する苦労の工数（費用）をかけるなら、その工数を社員の教育に使った方が、将来を考えるとよほど建設的な工数のかけ方かと思いますが、いかがでしょうか。
※1
この状態で「キャンセル」をクリックしたら、チェックインされない状態でアップロードされます。
以下、サイト管理者（Q）と SharePoint 運用部門（A)のやりとりです。
知っている人にとっては SharePoint あるあるなのかもしれませんが、選択肢列の値を変更しても、投稿済アイテムの値が連動して変更されません。つまり、選択肢列の設定の値はマスターデータではなく、選択して投稿した際に、その値がそのままアイテムのデータとしてスタンプされるわけです。
実際に検証してみます。
▼「選択肢」列に「AAAA」「BBBB」「CCCC」という値を設定しました。
▼実際に投稿します。
▼投稿後に「選択肢」列の「AAAA」を「ああああ」に変更します。
▼投稿済アイテムは「AAAA」のままです。
これを「クソ仕様」だと言う人もいたけど、選択した時の値を保持したいニーズもあるので、クソではないと思います。
▼想定される選択肢の仕様で後々トラブルになりやすい条件
例えば、そのようなニーズがあるリストを作成する場合は、選択肢列を利用する前に投稿済アイテムの値については確認を取った方が良いですね。
では、値を変更した際に投稿済アイテムの値と連動させるような方法があるか？ありますよね。参照列を利用し、マスターデータを別リストで管理すれば可能ですね。また、管理されたメタデータでも要件は満たされると思います。ただし、参照列も管理されたメタデータもそれはそれで特色や仕様があるので、そちらにも注意して利用しないと、別のトラブルになりかねないです。
そういう意味でも、選択肢を実現させるには複数の列の種類がありますが、全ての特徴を表にしたりすると良いかもしれません。っていうか僕はそういう表を作っていました。忘れがちなので。
サイト管理者の SharePoint のスキルや経験次第なのですが、仕様を把握せずに作成して運営を開始すると、後々になってトラブルになる事もあります。
とはいえ、運用・運営部門でも SharePoint の細かな仕様はなかなか全ては把握できず、ましてやサイト管理者となれば仕方のない事かなと思うので、やはり経験を積んでトラブルなどはしっかり記録してナレッジとして蓄積させないとですね。
↑実際起きたらおそろしい…
SharePoint のアンケートリストは簡易的にアンケートを実施するには手頃なので、アプリの中では割と利用頻度の高い部類かと思います。ただし、色々注意すべきポイントがあるので過去に記事にしてきました。
今回も（仮想の）トラブル事例を元に注意すべきポイントを書いていきたいと思います。
アンケート用のサイトがあったとします。詳細には以下のような設定です。
このような方法で運営をスタートし、アンケートリストの細かい不満は聞くものの、結構重宝され、運営する事数年経過…。最近とあるウワサを耳にしました。
「アンケートサイトは、回答内容が見放題らしいぞ！」
「○○さんの趣味は意外にもクラッシックバレエらしいぞ！アンケートサイトの回答に書いてあった。」
などなど。
このようなウワサが耳に入ってきたので、運営部門は徹底的に調べたところ、以下の事が判明しました。
こんな感じです。
つまり、ひとたびアンケート作成者になりサイトに対してデザイン権限を付与されれば、読み取りアクセス権を適切に設定したところで、全ての回答が閲覧できてしまうんです。また、恐ろしい事に、アンケートリストの設定では、デフォルトで回答が検索対象なので、検索から他人の回答にたどり着いてしまう場合もあります。
上述のウワサについては、回答内容が見放題なのはアンケート作成者だし、○○さんの趣味がクラッシックバレエなのを見てウワサを流したのもアンケート作成者の誰かという事です。
人としてのモラルの問題でもありますが、秘密は垣間見たくなるのもこれまた人なので、やはりシステム的に制御しないとダメそうですよね。
これ、実はリストの詳細設定のアイテムごとの権限のところに、注意事項として記載されているんですよね。非常に見落としがちですが。
こうやって穴が存在している事に気がつかずに何年も運営されているなんて事は、ありえ…なくはないですよね。特にサイト管理者は往々にして自身にフルコントロール権限が付与されている事からも、各権限の挙動を検証しないで実装しがちで、気がつかない場合が多いです。
さて、今回の場合は、どのような対策をすれば解決されるでしょうか。これまた解答ではなく、考察とさせていただきます。
チェックアウトの取り消し権限というのはつまり…アクセス許可レベルの中でも「リストの動作を無視」という項目に該当すると思います。「デザイン」アクセス許可レベルではここがチェックされていました。
この項目をチェックから外したらどうでしょうか？これがダメなんですよね。
このチェックを外してしまうと、アンケート作成者は自分の管理するアンケートすら全回答が閲覧できなくなるので、スプレッドシートに保存をしても権限不足で集計ができません。
▼チェックを外した状態で自分のアンケートリストを見ると、本当は回答があるのに表示されません。
▼この状態でスプレッドシートに保存をしても、集計はされません。
こうなるとアクセス権限をサイト単位ではなくアンケートリスト単位で設定するしかなさそうです。そうなると結局サイト管理者の手間が増えます。
なぜかというと、アンケートリスト単位でアクセス権限を設定する場合、その設定はアンケート作成者では行えず、サイト管理者が行うしかないからです。
そもそも機微な情報を取得する目的でアンケートを開催する際には、たとえ社内であっても気軽にやれるものではない意識付けにもなるのかなとは思います。ポジティブに考えれば。
ただ、中には機微な情報ではないフランクな目的のアンケートもあるので、それも同じセキュリティレベル（手間）で運営しなくても良いかもしれません。そういう意味では、セキュリティレベルで運営方法を分岐させる方法もアリかもしれません。つまり、機微情報を含まないアンケートは今まで通りアンケート作成者が自由に作成・集計できるものとし、機微情報を含むアンケートの場合は、サイト管理者が個別の権限設定を施したアンケートリストを提供する。これなら機微情報を含むアンケートのみサイト管理者の手間が増えるだけなので、まだマシなのかなと思います。機微情報の有無を判断するのが難しい時もあるし、面倒だから機微情報が含まれているのに含まれていない方で実施されてしまう可能性もありますが、こうなるとさすがにモラルの問題かと思います。
このようにあくまでも一例ですが、このようなトラブルにつながりかねないという事と、解決方法も一つではなく様々な角度から検討し、最適解を探し出す必要があります。
アンケートはアンケートサイトではなく、各部門サイトやチームサイトの管理人に任せている場合も、その中のアンケートリストは、属しているサイトでデザイン権限以上のユーザーであれば、やはり他人の回答を見る事が可能だし。
とはいえ、Office 365 も色々なアプリやサービスが増え、ユーザーにとって色々な選択肢が増えたはいいけど、中には管理者が管理しきれないところもあり、アクセス権限を厳密・厳格に行う事は難しく、やはり利用者のITリテラシーやモラルにかかってくるのかなぁ？なんてスッキリしない感じで今回も〆させていただきます。
SharePoint のアンケートリストは気軽にアンケートをとれるので意外と利用されると思います。反面、運営方法次第だと色々トラブルの元にもなりかねません。当ブログでも過去にアンケートに関しては記事を書いてきました。
今回記事にするのは集計の際の注意点です。
実際に何度かあったトラブルなのですが、トラブル内容は、「集計したスプレッドシートが集計直後には表示されたが、今開いたらエラーで開けない。」というトラブルです。
実際にトラブルを再現してみます。
▼こんなアンケートを作りました。（低レベルの質問で恐縮です）
▼4件の回答があります。
▼スプレッドシートにエクスポートします。
▼エクスポート直後にowssvr.iqyを開きます。（見慣れない拡張子ですよね）
▼しっかり4件集計されたデータが表示されました。
ここまでは問題ありません。ここから数日経過したあと、あらためて集計しようとしたところ…
▼同じowssvr.iqyを開くとエラーで開けませんでした。
こういう流れです。
原因は「該当アンケートリストを削除」したことです。
通常、アンケートを運営していて、その性質上、長くデータは保管したくないので、集計が終わったらアンケートリスト自体を削除する事は普通のことかと思います。
では、なぜアンケートリストを削除した後にowssvr.iqyを開くとエラーになるのか？それはowssvr.iqyの中に回答データがないからです。つまりowssvr.iqyはアンケートリスト内のデータをその都度表示させているだけなんです。だからアンケートリストを削除すると、表示させるべきデータが削除されているのでエラーが出るわけです。試しにowssvr.iqyをテキストエディタで開いてみましょう。
▼回答データは一つもなく、接続する際の情報が記載されているだけです。
原因がわかれば対処法もわかります。
アンケートリストを削除する前に、owssvr.iqyを開いてxlsx形式などで別名保存すればOKです。もしくは回答データをコピーして、新規ファイルにペーストするなど。つまり、実データとして保存すればOKです。
SharePoint に精通している方はこれらを把握しているかもしれないので、アンケートの作成から集計といった管理を SharePoint の運用・運営部門が一括して行っている場合は良いですが、SharePoint に精通していないユーザーに相応の権限を付与して作成から集計まで行ってもらっている運営をしている場合は、事前にマニュアルに記載しておくなどで教えておいたほうが良い内容かもしれません。トラブルが起きた際にアンケートリストがごみ箱に残っていれば良いですが、ごみ箱からも消えていたら、折角のアンケートがパァになりますからね。
SharePointのアンケートリストでアンケートを実施していると、よくある問い合わせがあります。
【前提】
【問い合わせ内容】
回答途中で中断したアンケートの回答を再開しようとしたら「このアンケートに再度回答することはできません。」とエラーが出ます。
アンケートリストでは、分岐させてアンケートの入力ページが複数ページに渡る場合、「保存して閉じる」ボタンが表示され、アンケートを中断できます。この機能自体は長いアンケートの場合は良い機能だと思うのですが、アンケートを再開させる場合の操作が直感的ではないんですよね。なので…、たしかSharePoint2007にはなかったと記憶していますが、この「保存して閉じる」ボタンをクリックすると、再開の方法を記載してあるダイアログボックスが表示されるんですよね。
ただ…回答者はよく読まずに（理解せずに）閉じてしまいます。
で、再度アンケートリストを開いて、ユーザーは「このアンケートに回答する」をクリックすれば再開すると思ってしまうが、
実際は新規で回答をするリンクなので、複数回答を無効にしてあるからエラーが出るという感じです。
アンケートリストについての回答者からの問い合わせの多くはこのパターンでした。なので、問い合わせが来た場合は、以下の操作方法を教えれば解決です。
▼「すべての回答を表示する」をクリック
▼自分が登録者の回答の「…」→「回答の編集」をクリック
これで解決です。
と、ここまではなんてことのない記事なのですが、この問い合わせで、ちょっとした経緯から若干ハマり、結果としてアンケートリストの特別仕様を知ったという事があったので、それを以下に記載します。
まず、問い合わせを受けて、上述の通りアンケート再開の操作方法を教えれば即解決でした。ところが、問い合わせを受けた別の担当者が、ユーザーとのやりとりの中で、「とりあえず途中になっている回答をそちら（管理者）の方で探して削除して欲しい」という要求に答えようとしたところからスタートしました。
担当者としてはフルコントロール権限で該当アンケートリストにアクセスし、そのアイテムを削除すれば良いと思ったが、アイテムが見つからないとの事で僕に相談が。結果的にはアイテムは確実に存在するのにサイトコレクションの管理者であっても表示されませんでした。
ライブラリではチェックインバージョンが存在しないファイルがある場合、アップロードしたユーザーしかビュー上に表示されないアイテムで、これはサイトコレクションの管理者でもビュー上では確認できません。ライブラリの設定の「チェックイン バージョンが存在しないファイルの管理」からしか確認できません。
しかし、リストの場合は、様々な設定をしてもチェックインバージョンが存在しないアイテムという状態にはならず、投稿したユーザーしか表示されないという現象は起きません。
しかし、結果としてアンケートリストについては例外だったようです。つまり回答を中断したアイテムに関しては、チェックインバージョンが存在しないアイテムのような状態になり、サイトコレクションの管理者でもビュー上では確認できません。しかも、リストの設定にはライブラリのように「チェックイン バージョンが存在しないファイルの管理」メニューは存在しないので、結果的に回答者本人以外がアイテムを表示させる手段はないようです。
↓念のため検証した際のスクショを。
▼回答中断した状態で中断したユーザーで「すべての回答」ビューを表示（アイテムは表示される）
▼サイトコレクションの管理者で「すべての回答」ビューを表示（アイテムは表示されない）
やはりこの問い合わせを受けた際には、ユーザーに再開の操作を教えるのがベストのようですね。
SharePointでは、通常、リストもライブラリもアイテムの登録者や更新者は自動でログインユーザー名がスタンプされ変更する事はできませんが、アンケートリストは、設定でカンタンに匿名アンケートにできます。
設定の全般設定セクションの「リスト名、説明、ナビゲーションの列挙」からアンケートのオプションの「アンケートの結果にユーザー名を表示する」を「いいえ」にすると、
回答者（表示上では「登録者」または「作成者」）は「***」と表示され、匿名となります。
これで実名では回答しづらいアンケートも安心して回答でき…ないんですよね。
というのも、この設定を「いいえ」にすると、回答者の名前がデータとして登録されないわけではなくて、単に非表示になるだけの機能なんです。つまり、回答が出揃ったところで再度この設定を「はい」に戻すと、全回答において回答者が表示されてしまいます。
↑このように匿名だというから安心して回答した恥ずかしい質問が、実名で晒されてしまう事に…。
該当アンケートリストの設定を変更できるアクセス権限のあるユーザーであれば、誰でもいつでも匿名を解除する事が可能なんです。ちょっと怖いですね。
【前提】
社内共用の匿名アンケート用のサイトを作成。匿名の設定をしたアンケートリストをリストテンプレート化しておく。社内で匿名アンケートをとりたいという希望者がいたら、サイトに対してリストが作成できる権限を付与し、アンケート作成者が匿名アンケート用のリストテンプレートからアンケートを作成し、アンケートを実施。
【事故】
サイトに対してリストが作成できる権限を付与したので、アンケート作成希望者が増えるほど、その権限を所持するユーザーが増える。アンケート作成者は自分のアンケート以外のアンケートリストの設定も変更できてしまうので、匿名を解除し、データをエクスポートができてしまい、様々な匿名アンケートを実名込みで盗み見てしまった。
【防止策】
アクセス権限の粒度をサイトではなくアンケートリスト単位にする。
【前提】
サイトコレクション内にサイト管理者が匿名アンケートを作成し実施。アンケート終了後も該当アンケートリストをそのまま保管。
【事故】
時を経て、当時のサイト管理者は退職や異動などでいなくなる。新たなサイト管理者が興味本位で該当アンケートリストの匿名設定を解除し、匿名アンケートを実名込みで盗み見てしまった。
【防止策】
匿名アンケートはアンケート終了したら必ず即削除する。
など…。また、操作ミスで匿名が解除される事も100%ないとは言えません。そういう意味では、SharePoint のアンケートリストは機微情報を含むようなアンケートには厳密には不向きなのかもしれません。機微情報でなくても、回答者にとっては匿名だからこそ回答した問いもあるかと思います。防止策も軽く書きましたが、事故を回避する策は徹底的にした方が良いです。
以前、お知らせリストの有効期限列について以下の記事を書きました。
SharePointの「お知らせ」リストの「有効期限」列の利用および非表示方法
この記事で、利用方法の一例として、ビューのフィルターを活用して有効期限切れのアイテムをビュー上に表示させない方法も紹介しました。この方法は参考書などにも紹介されている方法なのでメジャーな使い方かと思います。ただし、この活用方法には落とし穴があり、実際にSharePoint運営に携わっていた頃にもトラブルがありました。以下、架空の設定ですが実際起きうるトラブルとして紹介いたします。
閲覧ユーザーが、お知らせリストに掲載されていた情報を元にお客様用に資料を作成し提出したが、その情報が古かったらしく怒られてしまった。その掲載物の投稿者に問い合わせてみたところ、古い情報は有効期限が切れており、新しい情報は別途掲載して表示した、とのこと。
ビューのフィルターをかけるだけでは有効期限切れのアイテムはビュー上から非表示になるだけで、実際に削除されたわけではありません。すべてのアイテムを表示させるビューがなかったとしても、検索すれば検索結果に表示されてしまいます。このトラブルも検索結果から古いアイテムを表示した事が原因でした。
お知らせリストの利用用途として検索対象外にする事はあまり好ましくありません。この方法を継続していれば同じトラブルは起きる可能性は高いです。このようなリスクを考慮して有効期限にどの機能を加えて活用するかを検討しないといけないです。
あくまでも参考としてください。
まずトラブルを避けるには有効期限切れのアイテムは表示されないように配慮する必要があります。やはり情報管理ポリシーの保持を利用し、有効期限が切れたらアイテムを削除するのも一つの手です。ただし、この方法はこのトラブルが解決できても別のトラブルが出る場合があります。これも運営に携わっていた頃によくあった問い合わせなのですが、「過去に投稿したアイテムを再利用したいけど有効期限が切れたらしく見当たらないので復活してほしい。」という問い合わせ。運営側からすると「いやいやあなた…自分で設定した有効期限が切れたならあきらめなさいよ…」と思うでしょうが、実際この手の問い合わせは結構多かったんです。で、ごみ箱から復元できる場合は復元してあげるのですが、ごみ箱からも削除されていたらもうあきらめてもらうわけです。この場合は、運営上そういうものだとユーザーに啓蒙していくしかありませんが、別の方法としては、有効期限が切れたら別のリストに移動するように設定し、移動先のリストのアクセス権限をサイト管理者以外閲覧できないように設定すれば、検索でも古い情報がひっかからず、復元の依頼があっても対応できるのかなと思います。また、SharePoint Designerなどのワークフローを利用して、有効期限の直前に投稿者にメールで通知してから有効期限で移動や削除なんて事も可能かと思います。
そこまでしてフロー情報をストックしておく必要があるかどうかは別として。
そうなんです。そもそも運営の仕方（サイト作成の仕方）がユーザーのニーズと乖離しているところも検討するところです。色々な角度から検討する必要がありますが、例えば、そこで発信する情報の種類が最低限フロー情報なのかストック情報なのかを考えて、サイト作成をしていく必要があります。
極端に言えば、例えば規程集のようなストック情報に有効期限を付ける必要はありませんよね。例えば鮮度が命の情報のようなフロー情報を半永久的に保存しておく必要はありませんよね。これらフロー情報とストック情報は性質が全く異なるので、それを同じ管理方法で運営している事自体を再検討しないといけない、などです。
運営部門の会議などで「有効期限列を活用する方法があります。」と言って説明をすると、すぐに「じゃ、全てに実装しよう！」なんて考えも出てきます。気をつけたいところですね。