PROJECT 002 — 社内ポータルサイトをWordPressで作る。
STEP 09 / WORKFLOW
STEP 08では、投稿のたびに繰り返していた日付や時間帯の判断、タイトル生成、重複確認をWordPressへ任せました。操作を短くできた一方で、社内ポータルを実際の仕事に使うには、個別の機能を作るだけでは足りませんでした。
情報を出したあと、誰が確認するのか。どこまで進めば完了なのか。確認が終わった情報をどう扱うのか。人と状態をつなげなければ、投稿は増えても仕事の流れにはなりません。
そこでSTEP 09では、確認が必要な文書を例に、発行から完了までを一つの業務フローとして整えた過程を記録します。
投稿できるだけでは仕事がつながらなかった
初期の社内ポータルでは、WordPressの投稿とコメントを使って情報を共有できました。カテゴリーから必要な情報を探し、検索で過去の内容へ戻ることもできます。
しかし、確認が必要な情報では、記事を公開しただけでは次の状態が分かりません。対象者が読んだのか、まだ誰かの確認が残っているのか、確認が揃った文書をHOMEへ表示し続けるのかを、人が別に判断する必要がありました。
BEFORE 文書を投稿する ↓ 対象者へ確認を依頼する ↓ 誰が確認したかを別に把握する ↓ 完了したかを人が判断する
STEP 05で利用者と権限を分け、STEP 06で情報共有の基本を作っても、それだけでは「次に誰が何をするか」まで表せません。必要になったのは、投稿、利用者、確認状態を一つの流れとして扱う仕組みでした。
専用の発行画面から流れを始める
最初から完成したワークフローを設計していたわけではありません。はじめは通常の投稿機能へ確認欄を加え、その後、実際の使い方に合わせてHOMEに専用の発行フォームを作りました。
発行する人は、HOMEで対象となる種類を選び、文書番号やタイトル、必要に応じて参照URLやPDFを指定します。入力内容を確認して発行すると、WordPressが決められたカテゴリーへ投稿を作ります。
通常の投稿画面を開き、カテゴリーや形式を毎回選び直すのではなく、業務ごとの入口を用意した形です。STEP 08で作った小さな自動化が、専用の発行処理へ発展しました。
発行フォームは、管理を担当する利用者だけに表示します。記事を見る人と発行する人を分けることで、操作を簡単にしても、誰でも文書を発行できる状態にはしませんでした。
発行から完了までを一本につなげる
今回整えた代表的な流れは次の形です。
AFTER 権限のある人がHOMEから発行する ↓ 発行時点の確認対象をWordPressへ保存する ↓ 対象者が記事を開いて確認する ↓ WordPressが確認状況を記録する ↓ 必要な確認が揃うと完了になる ↓ HOMEから外れ、投稿は記録として残る
この流れでは、発行する操作が次の確認作業の入口になります。確認結果は記事に結び付いているため、別の一覧へ転記しなくても、記事画面で現在の状態を確認できます。
操作する場所を役割ごとに分けた
利用者が操作する場所は、主に三つです。
- HOME：権限のある人が文書を発行し、未完了の確認対象を見つける
- 記事画面：文書の内容と確認状況を見て、自分または担当班の確認を記録する
- カテゴリー一覧：HOMEから外れた完了済みの投稿を含め、過去の記録を探す
実装では、HOMEの発行フォームと未完了一覧をfront-page.php、確認画面をconfirmations.php、対象決定や状態保存などの処理をfunctions.phpに置きました。画面と処理を分けながら、同じ投稿IDを中心に情報をつないでいます。
発行者と確認者の役割を分ける
発行UIは管理を担当する利用者に限定しました。確認は文書の種類によって、対象となる利用者が一人ずつ行う方式と、各班の代表が班単位で行う方式を使い分けています。
班単位の確認では、リーダーは自分が所属する班を確認できます。管理担当者は必要に応じて各班を確認し、取り消して未確認へ戻すこともできます。個人単位の確認では、対象者が自分の確認を記録し、管理担当者は代理確認ができます。
権限の詳細を増やすことが目的ではありません。誰の操作として記録するか、誰が次の状態へ進められるかを、実際の役割に合わせるための区分です。
確認の状態を投稿に保存する
確認状態は、WordPressの「投稿メタ」に保存します。投稿メタは、記事本文とは別に、その投稿へ追加情報を結び付ける保存場所です。
個人単位では、誰が、いつ確認したかを対象者ごとに記録します。代理確認の場合は、対象者に加えて実際に操作した利用者も残します。班単位では、どの班を、誰が、いつ確認したかを保存します。
必要な人数、または必要な班の確認数と、保存済みの確認数を比べます。すべて揃ったときだけ「完了」と判断し、途中なら「何名中何名」「何班中何班」のように進み具合を表示します。
後から増えた利用者が過去文書の対象になった
実際に使って見つかった問題が、確認対象の決め方でした。
最初は確認画面を開くたびに、現在の利用者一覧と所属グループから対象者を計算していました。この方法では、新しい利用者を登録すると、その人が発行前には在籍していなかった過去文書の確認対象にも加わります。
変更前 確認画面を開く ↓ 現在の利用者から対象者を計算する ↓ 利用者が増えると過去文書の対象も変わる 変更後 文書を発行する ↓ その時点の対象ユーザーIDを投稿メタへ保存する ↓ 以後は保存済みの対象者を使う
そこで、文書を発行した時点の対象ユーザーIDを投稿へ保存する形に変えました。ユーザーIDは、WordPressが利用者を区別するために持つ番号です。表示名ではなくIDを保存することで、同名の人がいても対象を区別できます。
過去の投稿で対象情報がまだ保存されていない場合は、初めて参照した時点で対象を確定する処理も用意しました。完成形を最初から作ったのではなく、利用者が増える運用を通して「発行時点の状態を固定する」必要性が分かりました。
完了した投稿は消さずにHOMEから外す
次に見直したのが、完了後の扱いです。
はじめはHOMEへ新しい投稿を一定件数表示していました。しかし件数で区切ると、古い未確認の投稿が新しい投稿に押し出され、確認が終わっていないのに見えなくなる可能性があります。一方、完了済みの投稿をHOMEへ残し続けると、今やるべきものを探しにくくなります。
そこでHOMEには、未完了の確認対象を件数制限なしで表示する形へ変更しました。必要な確認が揃った投稿はHOMEのカードから外しますが、投稿自体は削除しません。カテゴリー一覧や検索から、完了後も記録として参照できます。
HOMEは「今、確認が必要なものを見る場所」、カテゴリーと検索は「過去を含む記録へ戻る場所」と役割を分けました。
発行から完了までを確認する
実装後は、既存の文書と確認データを使って、次の流れを確認しました。
- 発行権限のある利用者にだけ専用フォームが表示される
- 発行すると、指定したカテゴリーへ文書が作成される
- 発行時点の確認対象が投稿へ保存される
- 対象者または担当班だけが確認操作を行える
- 確認後に人数・班数と表示状態が更新される
- 必要な確認が揃うと完了になり、HOMEから外れる
- 完了後も投稿はカテゴリー一覧と検索から参照できる
記事制作のために社内ポータルへ新しい文書や確認データは作らず、既存の実装履歴、実データで行った確認記録、現在のソースを照合しました。
機能の間に受け渡しを作る
今回分かったのは、業務フローの中心は機能の数ではなく、次の人への受け渡しにあることです。
発行すると対象が決まり、確認すると状態が進み、確認が揃うと入口から片付く。このつながりができたことで、投稿、利用者、権限、自動化、検索が、実際の仕事の流れとして動くようになりました。
また、対象者のように後から変わる情報は、毎回現在の状態から計算すればよいとは限りません。「その文書を出した時点ではどうだったか」を残すことも、記録を正しく扱うために必要でした。
完了した情報を削除せず、今見る必要がある場所からだけ外す考え方も、ポータルを日常的に使ううえで重要でした。
次はPROJECT 002を使える状態へ整える
個別の機能を作り、投稿と確認を一つの流れへつなげたことで、社内ポータルは情報を置く場所から、仕事の進行を支える場所へ変わりました。
STEP 10では、ここまで作った機能と導線を見直し、PROJECT 002を実際に使える状態へ整えて完成までをまとめます。
← STEP 08「社内ポータルの作業を自動化する。繰り返す操作をWordPressに任せてみる。」
PROJECT 002の記事一覧を見る
NEXT → STEP 10「社内ポータルを仕上げる。実際に使える状態まで確認してPROJECTを完成させる。」