PROJECT 002 — 社内ポータルサイトをWordPressで作る。
STEP 01 / REQUIREMENTS
社内ポータルを作ろうと決めても、最初から画面や機能を作り始めることはしませんでした。
先に整理したかったのは、誰が使い、どんな情報を扱い、何に困っているのかです。ここが曖昧なままだと、機能を増やしても日々の仕事では使いにくいサイトになってしまいます。
STEP 01では、実際に制作した社内ポータルの履歴を振り返り、今回のPROJECTで必要な機能と最初に作る範囲を整理します。
まず、解決したい困りごとを決める
出発点は、社内の情報が一か所にまとまっていないことでした。
- お知らせや引き継ぎ情報の置き場所が分かれている
- 過去の情報を探すのに時間がかかる
- 投稿した内容を誰が確認したか分からない
実制作では、複数の場所に分かれていた情報を一つの入口へまとめる必要がありました。大切なのは、単にページを集めることではありません。新しい情報を載せ、後から探し、必要に応じて補足し、確認状況まで把握できる流れが必要でした。
そこで、「情報を見る場所を一つにする」「探せるようにする」「確認したことを残す」の三つを、ポータルの中心に置きました。
使う人と役割を整理する
利用者は、不特定多数の読者ではなく、日常的に情報を確認する社内ユーザーです。ただし、全員が同じ操作をするわけではありません。
- 社内ユーザー：情報を読み、必要に応じてコメントする
- 投稿者：お知らせや引き継ぎ情報を追加する
- リーダー：担当する範囲の確認状況を扱う
- 管理者：ユーザーや情報分類、サイト全体を管理する
実制作でも、所属や役割に応じて表示対象や操作範囲を分けました。誰でも管理できる形にせず、「見る」「投稿する」「確認する」「管理する」を分けて考えたことで、必要な権限が見えやすくなりました。
扱う情報を先に分ける
ポータルで扱う情報は、大きく分けると全体へのお知らせと、担当やテーマごとの情報です。
全員に伝えたい内容はホームで目立つ位置に置き、それ以外はカテゴリーで整理します。実制作ではカテゴリーを階層化し、同じ目的の情報をまとめました。カテゴリー名を変えたときに、ホームやメニューにも反映できる構成も必要になりました。
投稿には文章だけでなく、写真やPDFなどの補足資料が必要になる場面もありました。そのため、情報の本文、コメント、添付ファイルを一つの流れで確認できることも要件に含めます。
必要な機能を七つに整理する
困りごと、利用者、扱う情報をつなげると、今回作る社内ポータルに必要な機能は七つに整理できました。
1. 情報の入口になるホーム
最初に見るホームでは、全体へのお知らせと、分類した情報への入口を分けます。実制作では、全体のお知らせを上部に置き、その下にカテゴリーごとのカードを並べました。
更新された情報が分かり、目的の場所へ短い動線で進めることを優先します。
2. 投稿とカテゴリー
お知らせや引き継ぎ情報は、WordPressの投稿として蓄積します。カテゴリーを使って内容を分ければ、同じ仕組みの中で複数の情報を整理できます。
固定ページを増やし続けるより、投稿を追加する日々の運用に合わせやすいと考えました。
3. コメントと添付
掲載した情報へ補足や返信が必要なときは、コメントを使います。実制作では、ログインしているユーザーがコメントでき、返信を階層で追える形にしました。
写真やPDFを添付できることも、文章だけでは伝えにくい情報を残すために必要でした。
4. 投稿とコメントを探す検索
情報をまとめても、増えたあとに探せなければ、別の場所へ散らばっていたときと同じ問題が残ります。
実制作では、投稿本文に加えてコメントも検索対象にしました。ホームでは全体、カテゴリーや投稿の画面では関連する範囲に絞るなど、いま見ている場所に合わせて探せることも要件にしました。
5. 迷わず移動できるナビゲーション
情報分類が増えると、カテゴリーを作るだけでは目的の場所へ進みにくくなります。ホーム、カテゴリー、投稿の位置関係が分かり、同じ分類の前後の記事にも移動できるナビゲーションが必要です。
6. ユーザーと権限
利用者ごとにアカウントを用意し、役割に応じて操作範囲を分けます。実制作では、所属情報とWordPressの権限を結び付け、一般ユーザー、リーダー、管理者の操作を整理しました。
これは制限を増やすためではなく、誤操作を避けながら、必要な人が必要な操作をできるようにするためです。
7. 確認状況を残す仕組み
「掲載した」で終わらず、誰が確認したかを記録します。実制作では、ユーザーごとの確認と、担当グループ単位の確認を扱える形へ発展しました。
確認する人の操作と、確認状況を把握する人の画面を分けることで、未確認の情報を見つけやすくします。
一般公開サイトとは優先順位が違う
MANIARUのような一般公開サイトでは、初めて訪れた人へ内容を伝え、読みたい記事へ案内することが大切です。
今回の社内ポータルは、使う人が比較的はっきりしています。見栄えを整えることに加えて、毎日迷わず使えること、情報を更新できること、過去の内容を探せること、誰が確認したか分かることを優先しました。
読むだけのサイトではなく、利用者が情報を追加し、補足し、確認する場所として設計する必要があります。
最初から全部は作らない
必要な機能を整理すると、作りたいものはいくらでも増やせます。しかし、最初から全部を作ると、どの機能が本当に使われるのかを確認しにくくなります。
今回のPROJECTでは、情報の入口、投稿と分類、コメント、検索、ユーザーと権限、確認状況という実制作で必要になった範囲を扱います。日々の情報共有という中心の問題から離れる機能は、最初の範囲へ加えません。
まず使える形を作り、実際の運用で不便が見つかったら改善する。この順番なら、機能の数ではなく、困りごとを解決できたかで判断できます。
作る前の確認リスト
同じように社内ポータルを考えるなら、制作前に次の項目を確認できます。
- 解決したい情報共有の問題は何か
- 誰が情報を読み、誰が投稿・管理するか
- どんな情報を、どの単位で分類するか
- 過去の情報をどう探すか
- 補足や返信をどこへ残すか
- 役割ごとに、どの操作を許可するか
- 確認状況を記録する必要があるか
- 最初の公開範囲から外すものは何か
この整理をしたことで、社内ポータルの完成形を一度に作るのではなく、必要な機能を順番に確かめながら進める方針が決まりました。
次はWordPressに土台を作る
困りごとから逆算し、誰が使うのか、どんな情報を扱うのか、どの機能が必要なのかを整理できました。
次は、この要件をWordPressの仕組みへ置き換えます。
STEP 02では、投稿、カテゴリー、ユーザーなど、WordPressが最初から持っている機能を確認し、社内ポータルの土台を作ります。