イントラは声が集まる仕組みこそがゴール
社内ポータルやイントラサイトのリニューアルを検討するとき、多くの現場ではまず「情報設計」や「デザイン」に議論が集中します。しかし、公開後半年、一年と経つうちに「使われていない」「必要な情報にたどり着けない」という声が上がってくるケースは少なくありません。
本記事では、イントラサイトの本質は初期構築の完成度ではなく、ユーザーの声を継続的に反映する運用改善サイクルにあるという考え方を提示します。広報・人事・情シスなど、社内ポータルの企画・運用に関わる方に向けて、UI/UXを決めるのは「作った瞬間」ではなく「その後の運用設計」であるという視点をまとめます。
目次
初期設計だけでは、イントラの使いやすさは決まらない
社内ポータルの構築プロジェクトでは、要件定義、情報設計、デザイン、開発というフェーズを経て、公開日をゴールに設定するのが一般的です。関係部門へのヒアリング、ペルソナ設計、サイトマップ作成といった上流工程に多くの工数が割かれます。
ただし、公開直後の完成度と、半年後の使われ方の間には必ずギャップが発生します。理由はシンプルで、社内組織は絶えず変化するためです。組織改編、新規事業の立ち上げ、制度改定、リモートワーク比率の変動など、ポータルが扱う情報の重み付けは日々変わります。初期設計で完璧に想定することは現実的ではなく、公開後にどう調整していくかという設計項目が増えていきます。
つまり、イントラサイトのUI/UXは、初期構築の品質そのものよりも、公開後にユーザーの声をどう拾い、どう反映するかという運用改善サイクルによって決まるのです。
「声が集まる仕組み」が、なぜイントラのゴールなのか
社外向けのWebサイトであれば、アクセス解析やヒートマップ、問い合わせフォームなど、ユーザーの反応を得る手段が確立されています。一方、イントラサイトでは、社員が不便を感じても「わざわざ申告するほどではない」と我慢して使い続けるケースが多く見られます。
その結果、運用担当者のもとには「大きな不満」は届いても、「小さな使いにくさ」は届きません。この小さな声こそが、UI/UX改善のヒントになる情報です。
したがって、イントラサイトの運用フェーズで最初に整えるべきは、以下のような「声が集まる仕組み」です。
- ポータル内に常設されたフィードバック導線（意見箱、簡易フォーム）
- 部門ごとの運用担当者から定期的に情報を吸い上げる会議体
- アクセスログや検索ログの定期レビュー
- 新入社員・異動者へのオンボーディング時のヒアリング
これらを個別に運用するのではなく、集めた声を分類・優先順位付けし、改善タスクに落とし込む一連のフローとして設計することが重要です。
改善サイクルを回すための責任範囲の整理
運用改善サイクルを継続させるうえで、避けて通れないのが責任範囲の明確化です。イントラサイトは、広報、人事、情シス、経営企画など複数部門が関わるため、「誰が何を判断するか」が曖昧なまま運用が始まると、改善提案が上がっても意思決定が滞り、調整が増えていきます。
整理すべき観点は主に次の三つです。
第一に、コンテンツ責任。どの部門がどのカテゴリの情報を管理し、更新するのかを定義します。
第二に、UI/UX判断責任。ナビゲーションやトップページのレイアウト変更など、全社に影響する変更を誰が最上位管理者として承認するのかを決めます。
第三に、システム責任。CMSの設定変更、権限管理、性能面の監視など、情シス側で担う範囲を明確にします。
この三層を切り分けたうえで、月次または四半期単位の改善レビュー会議に接続することで、声を集める仕組みと、意思決定する仕組みが連動します。
標準化しておくと運用負荷が下がる領域
改善サイクルを回すたびに毎回ゼロから議論していると、運用負荷が高まります。あらかじめ標準化しておくと工数削減につながる領域を挙げます。
- ページテンプレート（お知らせ、制度案内、マニュアル等の型）
- 用語の表記ルール（部署名、制度名、略称）
- 更新フローと承認フロー
- アクセス権限のパターン
- 改善要望の受付フォーマットと優先度基準
これらを標準化しておけば、改善提案が上がった際に「どのテンプレートを使うか」「誰が承認するか」といった判断が自動化され、実装までの時間が短縮されます。
改善サイクルの回し方：小さく始めて広げる
いきなり全社的な改善プロセスを設計しようとすると、関係者調整だけで数か月が経過してしまいます。現実的な進め方としては、次の順序が有効です。
- アクセスログの上位ページを洗い出す
- 検索されているが結果が出ていないキーワードを特定する
- それらを対象に月次で小さな改善を実施する
- ビフォーアフターを社内に共有する
- 他部門からのフィードバックが集まり始めたら、部門横断レビューや大規模なコンテンツ再編に着手する
改善の効果が可視化されると、他部門からもフィードバックが集まりやすくなり、声が集まる仕組みが自然と機能し始めます。この段階を経てから部門横断の取り組みに拡張していく流れが、無理のない進め方です。
リニューアルを検討している段階だからこそ、運用設計を先に描く
現在、社内ポータルのリニューアルを検討している段階であれば、デザインや機能要件を固める前に、公開後の運用体制と改善サイクルを先にスケッチしておくことをおすすめします。運用側の体制が描けていないと、どれだけ精緻な初期設計をしても、公開後の変化に追従できません。
逆に、運用改善のフローと責任範囲を先に定義しておけば、初期構築のスコープは必要最小限に抑えられ、公開後の学習で調整していく前提の設計が可能になります。結果として、初期コストの最適化にもつながります。
よくある質問
Q. イントラサイトの改善サイクルは、どのくらいの頻度で回すのが適切ですか。
小さな改善は月次、レイアウトやナビゲーションなど全社に影響する変更は四半期単位が目安です。組織規模や更新頻度によって調整しますが、まずは月次レビューを定着させ、そこから拡張する進め方が現実的です。
Q. ユーザーの声を集める仕組みは、具体的に何から始めればよいですか。
ポータル内に常設のフィードバックフォームを設置し、あわせてアクセスログと検索ログの定期レビューを開始するのが着手しやすい方法です。声の量が少ない段階では、部門の運用担当者へのヒアリングを組み合わせると、傾向をつかみやすくなります。
Q. 運用体制が整っていない段階でも、リニューアルの相談は可能ですか。
可能です。むしろ体制設計の段階からご相談いただくことで、公開後の運用負荷を抑えたスコープ設定がしやすくなります。現状の棚卸しからご一緒することもできますので、検討初期の段階でお声がけください。
LYZONが提供するWebサービス
Webに関するお悩みは、まずLYZONへ
構築・運用・AIまで、Webに関わる課題をワンストップで対応。まず何ができるかをご覧ください。
2015年入社。
サポートデスクとして下積み期間を経てディレクターに転身。主に運用案件を担当。
家に帰れば、息子2人の胃袋を満たすべく食事作りに追われている。
