レビュー相手の決め方
オンボーディングチェックリストのレビュワーは、人事担当・配属先のマネージャー・情報システム担当の3者を基本構成にすると網羅性が高い。人事は手順の抜け漏れを、マネージャーは業務フロー上の正確性を、情報システムはツールやアカウント周りの記述を確認する。
レビュワーが10名を超えると意見が集約しにくくなるため、最終承認者を1名決めておく。他のレビュワーはコメントを出す担当と位置付け、意思決定ラインを明確にすることで修正ループが短くなる。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
認証方式の選び方
社内レビューには会社ドメイン認証が最も適している。設定後はURLを社内Slackで展開するだけでよく、パスワードを別途管理する手間がない。ドメイン認証では誰がアクセスしたかの記録も残るため、「レビューしたかどうか」の確認にも使える。
業務委託のHRコンサルタントなど社外のレビュワーが参加する場合は、メール個別認証でアクセスを付与する。期間が終わったら個別にアクセスを失効させられるため、退職や契約終了後に情報へのアクセスが継続するリスクを防げる。
- 誰でも見てよい: URL共有のみでもよいが、検索除外は確認する
- 特定の相手だけ: パスワードまたはメール認証を使う
- 会社内だけ: 会社ドメイン認証を検討する
- 短期レビュー: 期限を設定して古いURLを残さない
フィードバック回収
チェックリストのレビューで特に確認してほしいポイントを「手順の順番は実態と合っているか」「担当者名・連絡先は最新か」「スマートフォンで読めるか」の3点に絞り、URLと合わせてチェックシートを送付する。観点なしに渡すと「雰囲気はよさそう」で終わりがちだ。
フィードバックの回収期限は2営業日以内に設定すると、レビューが長引いてオンボーディング本番に間に合わないリスクを減らせる。リマインダーを期限前日の午前中に自動送信するだけでも回答率が上がる。
- 確認してほしい観点を3つ以内に絞る
- 期限と返信先を明記する
- 修正後も同じURLで見られるか伝える
- 最終版と途中版が混ざらないようタイトルを付ける
公開終了の処理
レビューが完了して最終版が確定したら、レビュー用URLを無効化し、本番配布用の別URLを新規発行する。同じURLをそのまま本番利用することもできるが、レビュー期間中の閲覧ログと本番配布後のログが混在するため、可能なら分けて管理することを推奨する。
年1回以上の定期レビューを予定している場合は、次回レビュー予定をカレンダーに登録しておく。オンボーディング手順の陳腐化は入社体験の品質低下に直結するため、年度の変わり目に必ず確認サイクルを組み込む体制をつくる。
よくある質問
チェックリストの内容が部署によって少しずつ異なる場合、毎回別々のHTMLを用意する必要がありますか？
共通部分はベースHTMLとして1本管理し、部署固有のセクションのみ差し込むテンプレート構成にすると更新コストを抑えられます。それぞれ別URLで発行すれば閲覧権限も個別に管理できます。
レビュー中に誰かが内容を変更してしまわないか心配です。
ギガサイト便で配信するHTMLは読み取り専用の閲覧URLであるため、レビュワーがブラウザ上で内容を書き換えることはできません。変更は管理者側がファイルを差し替えた場合のみ反映されます。
レビューが複数ラウンドになる場合、各ラウンドの版を区別して管理するよい方法はありますか？
ラウンドごとにスラグにv1・v2のサフィックスを付けたURLを発行します。前ラウンドのURLは無効化せずに残しておくと、変更前後の比較用としてレビュワーが参照できて便利です。