PROJECT 002 — 社内ポータルサイトをWordPressで作る。
STEP 10 / FINALIZE
STEP 09では、文書の発行、確認、完了を一つの業務フローとしてつなげました。これで、PROJECT 002で考えてきた主要な機能は揃いました。
最後に必要だったのは、新しい機能を増やすことではありません。利用者が迷わず操作できるか、役割ごとに必要な画面が見えるか、問題が起きたときに戻せるか。実際に使い続けられる状態かを確認し、どこまでを完成とするか決める作業でした。
STEP 10では、社内ポータルを仕上げたときの確認内容と、完成後に残した課題を記録します。
新機能を増やす段階から、使い続けられるかを確認する段階へ
ここまでに、HOME、ナビゲーション、利用者と権限、投稿とコメント、検索、自動化、確認フローを作ってきました。それぞれが動いていても、機能の間で利用者が止まれば、日常の道具としては使えません。
そこで最後は、管理画面の項目を順番に点検するのではなく、実際の利用に近い流れで確認しました。情報を出し、対象者が見つけ、確認し、完了後も記録へ戻れることを一続きで見ます。
代表的な利用の流れを最後まで確認する
確認した中心の流れは、次の形です。
ログインする ↓ HOMEから必要な情報へ進む ↓ 権限のある人が文書を発行する ↓ 対象者が記事を開いて確認する ↓ 必要な確認が揃うと完了になる ↓ HOMEから外れ、記録は一覧と検索に残る
HOMEは今対応する情報の入口にし、完了した投稿はカテゴリー一覧や検索から参照します。表示場所を状態に応じて分けたことで、現在の作業と過去の記録を同じWordPressの中で扱えるようになりました。
権限ごとの見え方と操作を確認する
社内ポータルでは、管理する人、情報を発行する人、確認する人で必要な操作が異なります。最後の確認でも、すべての利用者へ同じ画面を見せるのではなく、役割に応じて必要な入口と操作だけが表示される状態を見直しました。
- 発行用のフォームは、権限のある利用者だけに表示される
- 確認操作は、対象となる利用者や担当班が行える
- 管理を担当する利用者は、必要な確認と修正を行える
- 一般の利用者には、WordPressの管理を意識させない
権限は機能を隠すためだけの設定ではありません。利用者が誤った操作をしにくくし、自分に必要な作業を見つけやすくするための設計でもありました。
共有PCで利用者を取り違えないようにする
共有PCで使う場面では、前の利用者がログインしたまま席を離れると、次の人がそのアカウントで操作してしまう可能性があります。そこで、操作がない状態が10分続いたときに自動でログアウトする仕組みを加えました。
ログアウトの1分前には案内を表示し、作業中なら利用を続けられるようにしています。一定時間ログインを保つ設定を明示的に選んだ場合は、自動ログアウトの対象から外しました。
判定は利用者のログイン単位で持ち、画面操作と定期的な通信で最終操作時刻を更新します。バックグラウンド処理まで通常の画面操作として扱わないようにし、共有PCでの取り違えを減らしながら、普段の利用を妨げない形にしました。
PCとスマートフォンで日常の操作を見直す
PCだけでなく、スマートフォンでもHOME、ナビゲーション、検索、記事、コメント、確認操作を見直しました。画面幅が変わっても、今いる場所と次に押す場所が分かることを重視しました。
この確認では、見た目を豪華にする調整よりも、文字が読み切れるか、ボタンを押せるか、横方向にはみ出さないか、必要な情報へ戻れるかを優先しました。日常的に繰り返す操作ほど、細かな迷いが積み重なるためです。
バックアップは戻せて初めて意味がある
運用を始める前に、手動でバックアップを実行し、データベースと必要なファイルが保存されることを確認しました。保存物には整合性を確認するための情報も含め、途中で失敗した出力を完成したバックアップとして扱わないようにしています。
さらに、本番とは別の環境へバックアップを戻す復元練習を行いました。復元したサイトで、閲覧、管理画面へのログイン、投稿、コメント、アップロードしたファイルを確認できました。
復元中にはファイルの属性に関する警告が出ましたが、復元後の主要な機能を確認し、サイトを使ううえで致命的な問題ではないと判断しました。バックアップファイルが存在するだけでなく、実際に戻して動くところまで確認したことで、障害時の対応を具体的に考えられるようになりました。
自動バックアップには未確認が残った
一方で、毎日午前2時に実行する予定だった自動バックアップは、確認した時点では動いていませんでした。ログには手動実行の記録だけがあり、定時に処理が始まった記録はありませんでした。
定期実行の設定を読み込み直し、ジョブが登録されているところまでは確認しました。ただし、その後の翌日実行が成功した記録は残っていません。そのため、自動バックアップが正常に動作しているとは書かず、運用開始後も確認する課題として残しました。
手動バックアップと復元は確認できています。定時実行は未確認です。同じ「バックアップ」でも、確認できた範囲を分けて記録することにしました。
PROJECT 002を完成と判断した基準
未確認の項目が残っていても、PROJECT 002を完成としました。完成の基準を、問題が一つもない状態ではなく、実際の利用を始められ、問題が起きたときに確認と改善を続けられる状態に置いたためです。
- 利用者がHOMEから必要な情報へ進める
- 役割に応じて投稿、確認、管理ができる
- 一覧と検索から過去の記録へ戻れる
- 繰り返す操作をWordPressへ任せられる
- 発行から完了までを一つの流れとして扱える
- 手動バックアップと別環境での復元を確認できた
記事制作のために社内ポータルへ新しい投稿や確認データは作らず、実装履歴、当時の確認記録、現在のソースを照合しました。
完成は、改善を終えることではなかった
PROJECT 002を通して分かったのは、ページを作るだけでは社内ポータルは完成しないということでした。実際に使うと、利用者の役割、情報の探し方、確認後の状態、共有PCでの扱い、復元できる備えまでがつながって初めて、日常の仕組みになります。
最初からすべてを設計できたわけではありません。小さく作って使い、必要になった機能を加え、問題が見つかれば判断の記録を残す。その繰り返しで、WordPressは情報を掲載する場所から、社内の仕事を支える道具へ変わりました。
完成は、改善を終える宣言ではありません。実際の運用を始められる地点まで来た、という区切りです。自動バックアップの定時実行を含め、残った課題は運用の中で確認し、必要に応じて直していきます。
PROJECT 002 — COMPLETE
STEP 00で計画を立て、サイト構成、HOME、ナビゲーション、利用者と権限、投稿とコメント、検索、自動化、業務フローを順番に作ってきました。そしてSTEP 10で、使い続けるための確認と備えまでを一つにつなげました。
PROJECT 002「社内ポータルサイトをWordPressで作る。」は、ここでひとつの完成です。これからは実際の運用を通して、使う人と一緒に育てていきます。
← STEP 09「社内ポータルに業務フローを作る｜WordPress実制作記録」
PROJECT 002の記事一覧を見る