WordPressで社内ポータルを作り始めたとき、必要な画面をすべて独自に作る方法も考えられました。しかし、投稿、コメント、ユーザー、権限、カテゴリー、検索には、すでにWordPressの仕組みがあります。
今回の制作では、標準機能を社内の情報共有へ置き換えて使い、足りない業務ルールと画面だけを追加しました。この記事では、PROJECT 002のSTEP 01〜07を進める中で決めた「残す部分」と「作る部分」の境界を整理します。
最初から全部を作らない
社内ポータルに必要だったのは、情報を書く、分類する、補足する、探す、利用者ごとに操作を分ける、といった機能です。名前だけを見ると専用システムのようですが、WordPressの基本機能へ当てはめられる部分が多くありました。
| 社内ポータルで必要なこと | 土台にしたWordPress機能 |
|---|---|
| 日々の情報を残す | 投稿 |
| 担当やテーマで分ける | カテゴリー |
| 補足や返信を残す | コメント |
| 利用者を識別する | ユーザー |
| 操作できる範囲を分ける | roleとcapability |
| 過去の情報を探す | 検索 |
これらを別のデータ構造として作り直すと、登録、編集、公開状態、権限判定なども一から考える必要があります。そこで、WordPressが持つ単位をそのまま使えるかを先に確認しました。
情報の本体はWordPress標準へ残す
社内で共有する一件の情報には「投稿」を使いました。タイトル、本文、作成者、公開日時、カテゴリーを持ち、固有のURLで後から開けます。
投稿への補足や対応結果は「コメント」へ残します。返信先の関係、承認状態、投稿との結び付きもWordPress側で扱えます。利用者は「ユーザー」として登録し、サイト上で何ができるかはroleとcapabilityで分けました。
WordPress公式のUsers資料でも、ユーザーはroleを割り当てられ、roleはcapabilityのまとまりを持つと説明されています。社内の呼び方へ置き換えても、操作権限の土台はこの仕組みを使いました。
標準機能へ残したのは、WordPress管理画面から確認・修正でき、他の画面でも同じデータを使えるためです。独自画面を通さないと内容を確認できない状態を増やさないようにしました。
独自に作るのは、業務に固有の差分
標準機能だけでは、今回の使い方に合わない部分もありました。そこは、元のデータを置き換えるのではなく、入力方法、表示方法、追加情報として補いました。
| 標準の土台 | 追加した差分 | 理由 |
|---|---|---|
| 投稿 | HOMEのカテゴリー欄から投稿を始める入口 | 管理画面を毎回たどらずに共有を始める |
| 投稿タイトル | 日付と勤務帯からの自動生成 | 表記ゆれと日付境界の間違いを減らす |
| ユーザーとrole | 所属グループ、チーム、担当属性 | 操作権限と業務上の所属を分ける |
| コメント | 階層に応じた表示と操作の整理 | 会話の流れを追いやすくする |
| 標準検索 | コメント検索と検索範囲の表示 | 投稿本文以外に残った情報も探す |
| HOME | 新着、カテゴリー、固定リンクの配置 | 必要な情報への入口を一画面にまとめる |
この分け方なら、投稿は投稿のまま、コメントはコメントのまま残ります。独自機能は、利用者がどう入力し、どう見つけ、どう操作するかを調整する層になります。
独自データは既存の対象へ結び付ける
WordPressにない情報を持たせる場合も、別の仕組みへ切り離さず、関係する対象へ結び付けました。
- 所属グループやチームは、ユーザーに付く追加情報として扱う
- 業務上の状態は、関係する投稿へ付く追加情報として扱う
- コメントの返信先は、WordPress標準の親子関係を使う
WordPressのMetadata APIは、投稿、ユーザー、コメント、カテゴリーなどの対象へ、キーと値の形で追加情報を結び付ける仕組みです。公式のMetadata資料でも、投稿用のpostmeta、ユーザー用のusermeta、コメント用のcommentmetaが用意されていることを確認できます。
何でもメタデータへ入れるのではなく、「この値は誰に属するか」「どの投稿の状態か」を先に決めました。対象が明確なら、後から表示場所が変わっても同じ情報を参照できます。
画面とデータの役割を分ける
HOMEやカテゴリー一覧は、情報そのものを保存する場所ではありません。WordPressに保存された投稿やコメントへ進む入口です。
WordPress標準のデータ
投稿 / コメント / ユーザー / カテゴリー
↓
社内ポータル用の処理
所属判定 / タイトル生成 / 検索範囲
↓
利用者が見る画面
HOME / 一覧 / 投稿 / 検索
この順番にすると、HOMEの配置を変えても投稿データは変わりません。検索結果の見せ方を変えても、元の投稿とコメントは同じです。画面の改善と記録の保存を分けて考えられます。
境界を決めるときに使った判断基準
新しい機能を追加するときは、次の順番で考えました。
- WordPressに同じ役割の標準機能があるか確認する
- 標準データの意味を変えずに使えるか考える
- 足りない部分が入力、表示、業務ルールのどれかを分ける
- 追加情報は、投稿やユーザーなど関係する対象へ結び付ける
- 管理画面と公開側の両方から元データを確認できる状態を残す
- 標準機能と独自処理を分けて動作確認する
標準機能を使うこと自体が目的ではありません。標準で足りる部分を残し、社内の運用に必要な差分へ制作時間を使うための順番です。
標準と独自を分けて確認する
実装後は、独自画面が動くことだけでなく、WordPress側の記録も確認しました。
- HOMEから作った情報が、通常の投稿として保存されている
- カテゴリー、投稿者、コメント設定が意図どおりになっている
- 返信が元のコメントへ結び付いている
- roleと所属情報が別々に保存されている
- 検索結果から元の投稿やコメントへ移動できる
- 独自の入口を使わなくても、管理画面で元データを確認できる
入口だけが動いていて、保存先が想定と違えば、後の検索や管理で使えません。画面の成功と、WordPressへ正しく残ったことを分けて確かめました。
境界を決めて分かったこと
WordPressを社内ポータルへ使うとき、すべてをブログのまま使う必要はありません。一方で、専用画面が必要だからといって、投稿やユーザーまで作り直す必要もありませんでした。
- 情報の本体は、WordPress標準の単位へ残す
- 独自実装は、足りない入力・表示・業務ルールへ絞る
- 追加情報は、関係する投稿やユーザーへ結び付ける
- 画面と保存データを分けて確認する
この境界を決めたことで、WordPressの管理機能を残しながら、社内向けの使い方へ画面と操作を合わせられました。
構成を決めた時点の考え方は、PROJECT 002 STEP 02「社内ポータルのサイト構成を考える」で記録しています。標準検索へコメント検索と範囲表示を足した実例は、STEP 07「社内ポータルに検索を作る」でまとめました。