SharePointで社内ポータルを作ったものの、社員にほとんど使われていない。
ニュース、マニュアル、資料、リンク集などをきれいに整理したはずなのに、現場では今も、
- 「○○の資料ってどこですか？」
- 「この申請の締切いつでしたっけ？」
- 「この件は誰に問い合わせればいいですか？」
- 「Teamsにリンク送ってもらえますか？」
といったやり取りが繰り返されている。
こうした状態は、SharePointの機能不足が原因とは限りません。
社内ポータルを「情報を置く場所」として設計していること自体が、使われない原因になっている可能性があります。
社員が毎朝ポータルを開いた瞬間に、
- 今日何をすべきか
- 必要な資料はどこにあるか
- よく使うシステムはどこから開くか
- 分からないときは誰に聞けばいいか
が分かる。
つまり、社内ポータルは「情報を見る場所」ではなく「仕事を始める場所」として設計することが重要です。
今回は、SharePointで社内ポータルを構築する際に、毎日の業務で自然と使われるようにするための7つの設計ポイントをご紹介します。
SharePointで社内ポータルを作った。でも誰も見ていない
SharePointで社内ポータルを構築するとき、多くの企業ではまず「どんな情報を載せるか」を考えます。
例えば、
- お知らせ
- マニュアル
- 営業資料
- リンク集
- FAQ
- 社内イベント
などです。
もちろん、これらの情報を整理すること自体は重要です。
しかし、情報を載せただけでは、利用者側に「今日このポータルを開く理由」がありません。
すると社員は、必要な情報があるときだけポータルを探しに行きます。
そして一度でも「どこにあるか分からない」「検索しても見つからない」と感じれば、次からは人に聞く方が早いと判断します。
この状態では、SharePointを導入していても、情報探索の負担はほとんど変わりません。
なぜ社内ポータルは使われなくなるのか
情報を「載せること」が目的になっている
社内ポータルを運用していると、情報は少しずつ増えていきます。
「この資料も必要」
「このリンクもトップに置いてほしい」
「このお知らせも目立たせたい」
こうした要望をすべて受け入れていくと、トップページは情報で埋まります。
しかし、利用者が欲しいのは情報量ではありません。
「今、自分が必要としている情報へすぐたどり着けること」
です。
組織構造で整理してしまう
もう一つよくあるのが、情報を提供する側の組織構造で分類することです。
例えば、
- 営業企画部
- 人事部
- 総務部
- 商品部
- 情報システム部
といった部門ごとの入口を作る。
管理者側には分かりやすい構造ですが、利用者は必ずしも組織名から情報を探しているわけではありません。
利用者が考えているのは、
- 経費精算したい
- 営業資料を探したい
- 商品のことを確認したい
- システムについて質問したい
といった「目的」です。
情報を提供する側の分類と、情報を探す側の行動にはズレがあります。
「情報を見る場所」から「仕事を始める場所」へ
使われないポータルと、日常的に使われるポータルの違いを整理すると、次のようになります。
Beforeでは、ニュース、資料、リンク、マニュアル、FAQなどの情報が並んでいます。
しかし、社員は「必要なら見に行く」必要があります。
Afterでは、トップページを開いた時点で、
- 今日やること
- 締切
- よく使うリンク
- 必要な資料
- 問い合わせ先
- FAQ
- 今後の予定
が分かります。
ポータルを見るために仕事を止めるのではなく、ポータルを開くことで仕事が始まる。
この状態を目指します。
毎朝開かれるSharePointポータルにする7つの設計ポイント
ポイント1．トップに「今日やること」を置く
社内ポータルの一番上に「お知らせ」を配置しているケースは多くあります。
しかし、社員が仕事を始めるときに最も知りたいのは、
「今日、自分は何をしなければならないのか」
です。
例えば、
- 本日締切
- 今週締切
- 提出が必要な報告
- 申請期限
- 今後の会議・予定
などをトップページで確認できるようにします。
ポータルを開くことで「今日やることが分かる」という実利があれば、社員が毎日開く理由が生まれます。
ポイント2．よく使う情報ほどクリック数を減らす
毎日利用する業務システムへアクセスするために、何度もページを移動させてはいけません。
例えば、
- 勤怠システム
- 経費精算
- 申請ポータル
- 社内メール
- Teams
- 共有ドライブ
など、頻繁に利用する入口はトップページに配置します。
利用頻度が高いものほど、情報階層を浅くする。
この考え方が重要です。
ポイント3．資料を「保存場所」ではなく「目的」から探せるようにする
SharePointのドキュメントライブラリを、そのままファイルサーバーのように使ってしまうケースがあります。
例えば、
2026年度
↓
営業部
↓
商品
↓
営業資料
というフォルダ構造です。
保存する側には分かりやすくても、利用者は「どのフォルダに保存されているか」を知っていなければなりません。
そこで入口では、
- 提案するとき
- 商品を調べるとき
- お客様へ説明するとき
- 研修で使う資料
など、利用目的から資料へアクセスできるようにします。
「保存場所」と「利用者の入口」は別物として設計する。
ポイント4．問い合わせ先を「人」ではなく「何を聞けるか」で整理する
社員名簿だけを掲載しても、「誰に問い合わせればいいか」という問題は解決しません。
利用者が知りたいのは、人の名前ではなく、
「この内容について、誰に聞けばいいのか」
です。
| 聞きたいこと | 担当 | 連絡方法 |
|---|---|---|
| 商品について | 商品担当 | Teams／メール |
| システム操作 | IT担当 | 問い合わせフォーム |
| 契約・手続き | 業務担当 | メール |
というように、利用者の疑問から逆引きできる形にします。
FAQや問い合わせ業務の改善については、「FAQを作ったのに問い合わせが減らない理由」でも詳しく解説しています。
ポイント5．締切や重要情報は「探させない」
重要な締切が「詳しくはこちら」の先にしか書かれていない状態では、見落としが発生します。
トップページの時点で、
- 8月28日まで：月次報告
- 9月3日まで：経費精算申請
- 9月10日まで：キャンペーン申請
など、最低限必要な情報を確認できるようにします。
情報が存在しているだけでは足りません。必要なタイミングで利用者の視界に入ることまで設計する必要があります。
ポイント6．「何を置くか」より「何を置かないか」を決める
社内ポータルは、運用を続けるほど情報が増えていきます。
各部署から「この情報もトップに載せてほしい」という要望が出てきます。
すべてトップページに載せると、重要な情報が埋もれます。
そこで、トップページへ掲載する基準をあらかじめ決めます。
- 毎日または毎週使う
- 締切がある
- 多くの社員に関係する
- 問い合わせが多い
こうした条件に当てはまらない情報は、一覧ページや詳細ページへ配置します。
ポータル設計では、載せる情報を決めること以上に、載せない情報を決めることが重要です。
ポイント7．「作れる仕組み」ではなく「更新できる仕組み」にする
最後は運用です。
どれだけ見栄えの良いポータルを作っても、更新できなくなれば古い情報が残ります。
例えば、
- お知らせ → SharePointニュース
- 締切 → SharePoint Lists
- 資料 → ドキュメントライブラリ
- 問い合わせ先 → SharePoint Lists
- FAQ → SharePoint Lists
- よく使うリンク → クイックリンク
など、通常の担当者でも更新できる仕組みを中心にします。
必要に応じてPower Automateなどで通知・登録を自動化しますが、複雑な仕組みにしすぎないことも重要です。
高度なポータルを作ることより、半年後も現場が更新できることの方が重要です。
7つの考え方を実際のSharePoint画面にするとこうなる
ここまでの考え方をトップページへ落とし込むと、例えば次のような構成になります。
例えばトップページには、
- 今日やること・締切
- よく使うリンク
- 問い合わせ先
- 新着お知らせ
- 営業資料
- FAQ
- AI活用・業務効率化
- 今後の予定
などを配置します。
すべての情報をトップに掲載するのではありません。
毎日の仕事に必要な「入口」だけをトップページへ置き、詳細な情報はその先に配置します。
SharePoint標準機能だけでもかなり作れる
社内ポータルというと、大規模なシステム開発を想像するかもしれません。
しかし、多くのケースではMicrosoft 365の標準機能を組み合わせることで、業務の入口を作ることができます。
- SharePointサイトページ
- ニュース
- クイックリンク
- SharePoint Lists
- ドキュメントライブラリ
- イベント
- Power Automate
重要なのは、最初から高機能なポータルを作ることではありません。
まず標準機能で業務動線を作り、本当に不足する部分だけを後から拡張する。
この進め方の方が、導入後の運用もシンプルになります。
ポータルのKPIを「ページビュー」だけにしない
社内ポータルの利用状況を評価するとき、ページビュー数を見ることがあります。
もちろん利用状況を把握する指標の一つにはなります。
しかし、本当に知りたいのは、ポータルによって業務が改善されたかどうかです。
例えば、
- 資料を探す時間が減ったか
- 「○○はどこですか？」という問い合わせが減ったか
- 締切漏れが減ったか
- FAQによる自己解決が増えたか
- 特定担当者への問い合わせ集中が減ったか
- 日常的に使うシステムへ早くアクセスできるようになったか
といった変化です。
「何人が見たか」ではなく、「仕事がどれだけ楽になったか」を評価する。
この視点が重要です。
AIを載せる前に、まずポータルを整理する
最近では、Copilotなどを活用し、社内情報をAIから探せるようにしたいという企業も増えています。
しかし、AIを入れる前に確認すべきことがあります。
- 資料が複数の場所に散らばっている
- 古い情報が残っている
- 分類ルールが統一されていない
- どれが正しい情報なのか分からない
こうした状態では、AI以前に情報構造そのものを見直す必要があります。
AIに探させる前に、人間が見ても分かる情報構造を作る。
まず情報と業務動線を整理し、その先にAI活用を考える方が現実的です。
こんな社内ポータルなら、一度見直した方がいい
現在のSharePointポータルについて、次のような状態になっていないでしょうか。
- ポータルはあるが、社員がほとんど開かない
- 「資料はどこ？」という質問が多い
- トップページがお知らせだらけになっている
- リンクが増えすぎている
- ファイルサーバーと同じ階層構造になっている
- 担当者しか更新方法を分からない
- 古い情報が残っている
- Teams・メール・SharePointに情報が散在している
複数当てはまる場合、さらに情報を追加する前に、ポータルの役割と情報設計そのものを見直す余地があります。
「毎朝開かれる理由」を設計する
社内ポータルを使ってもらうために、社員へ「毎日見てください」とお願いしなければならない状態なら、ポータル側の設計を見直す必要があります。
理想は、
今日やることが分かる。
必要な資料がすぐ見つかる。
困ったときの解決方法が分かる。
だから、社員が仕事を始めるときに自然とポータルを開く。
この状態です。
株式会社uniteでは、SharePointの画面を作るところからではなく、社員がどんな情報を探し、どこで困り、どんな順番で仕事をしているのかという業務整理から社内ポータルを設計しています。
「SharePointはあるが使われていない」
「情報が増えすぎて整理できない」
「毎朝開かれる社内ポータルを作りたい」
といった段階からでも構いません。
まずは現在、社員がどこから情報を探しているのかを整理するところから始めましょう。
