担当されていたセッションを視聴させていただきました。とても勉強になりました。後半に部門という区切りでサイト構築することを推奨しない旨言及をされていた点が印象に残っているのですが、「部門”内”での情報共有」の媒体として、コミュニケーションサイトを部門ごとに構築することは有効といえますか？
Teamsに紐づくチームサイトとの棲み分けが難しい気がしています。

kotatsu さん、ご視聴をありがとうございます!

部門内での情報共有についてですが、先に考えたいのが「一緒に仕事をする業務単位でのコミュニケーション」で、組織の大きさには依存するのですが必ずしも「部」単位での情報共有がそれほど重要ではないことも少なくないようです。

たとえば、組織改編で組織が分かれたけれど実は仕事としてはいつも通り一緒に仕事をしているということもあります。私がポータルサイトの設計をさせていただくときに総務、経理といった管理業務に関しては割とそのまま組織通りに作ることはあるものの、部門サイトは極力作らないように提案しています。

コミュニケ―ション重視ならSharePointではなく、 Teams 内に業務単位のグループを作って運営していき、全社的なアナウンスやプロジェクトなどはコミュニケーションサイトでブロードに告知するというスタンスをとります。

大抵の組織では入れ物から先に作りますが(その方が手っ取り早いので)、要するに業務をしっかりと分析して、関わっている人や物を洗い出してから「入れ物となる」サイトなりチームなりを作ることが重要だと思っています。もちろん、十分に吟味したうえで部単位での情報共有が必要になれば、サイトを作成します。

そもそもそうしないと、管理側は常に組織改編対応に追われてしまうし、一緒に仕事をしていない人が利用する「サイト」というのはアクセス権限も複雑になりがちです。どうしても特定の人に「見せてはいけない」情報も出てくるためです。アクセス権限設定もシンプルかつ確実に設定していきたいですし。また、利用する側にとってもサイトがコロコロと変わってしまうと、利用しにくくなる可能性もあるため、組織改編に振り回されないサイト設計が重要ですね。

平野愛様
ご回答くださり、ありがとうございます。「部」といった目に見えやすい型にとらわれてしまいましたが、あくまで「業務が行われる単位」での構築を検討するべきという点、まさにその通りで、その着眼点が抜け落ちていました。先日投稿されていた「SharePointワークフロー2010→PowerAutomateへの移行」も然りですが、既存の型にとらわれず、今一度、まず業務の分析・見直しを行うことが重要であると解釈致しました（IT部門の立場から全社を対象にこれを行うことは中々骨が折れそうですね…）
コミュニケーション→Teams、ブロードなアナウンス→コミュニケーションサイト、という考え方も大変参考になりました。この点意識して運用に取り組みたいと思います。
技術的な内容ではなく、こちらのブログの趣旨とは逸れた質問をしてしまったかもしれません。それにも関わらず丁寧に対応いただきありがとうございました。ちなみに「合わせ技で 3 倍便利に使いこなす! Microsoft Teams & SharePoint」も（こちらはリアルタイムで）視聴させていただきました。これからも色々と参考にさせていただきます!

kotatsu さん、お返事をありがとうございました!
少しでもお役に立てれば幸いです。
今後とも引き続きよろしくお願いいたします。