共有前の確認点
社内ポータルのモックには従業員の氏名・部署・連絡先などのサンプルデータが使われていることが多い。実際の個人情報をダミーデータに差し替えたか確認し、「田中太郎」「03-xxxx-xxxx」のような架空データや「xxxxxxxx」のマスク表記に統一してからアップロードする。
ナビゲーションのリンク先が存在しないページを指している場合、クリック時に404になることをあらかじめレビュワーに伝えておく。「このモックはUIのデザインと主要フローの確認が目的で、全リンクは動作しません」とURL送付メールに一文加えるだけで問い合わせが大幅に減る。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
向いている認証方式
社内のみで確認する場合は会社ドメイン認証が最も管理コストが低い。URLを社内Slackの専用チャンネルに貼るだけで対象者全員がアクセスでき、個別のパスワード配布作業が不要になる。情報システム部門や経営層が同じドメインであれば追加設定なしに参加できる。
役員や外部コンサルタントなど社外の関係者を含む場合は、パスワード認証とメール認証の組み合わせが適している。パスワードは会議招待メールに、メール認証は個別送付にするなど、情報の重要度に合わせてチャネルを分けることでリスクを分散できる。
- 誰でも見てよい: URL共有のみでもよいが、検索除外は確認する
- 特定の相手だけ: パスワードまたはメール認証を使う
- 会社内だけ: 会社ドメイン認証を検討する
- 短期レビュー: 期限を設定して古いURLを残さない
相手への送り方
試作モックの共有メールには「このURLはデザインレビュー専用で、入力内容は保存されません」という一文を必ず入れる。本番ポータルと見た目が似ているため、一部のユーザーが実際にログイン情報を入力しようとするケースがあるためだ。フォーム要素には`disabled`属性を付与するか、送信ボタンを削除しておくのも有効だ。
モックのURLとともに「確認してほしいページ一覧」をリスト形式で送ると、レビュワーが全ページを網羅的に見やすくなる。特に「ダッシュボード → レポートページ → 設定画面の順に確認してください」のように動線を示すと、レビューの質が上がる。
更新・期限管理
デザインのフィードバックを受けてHTMLを修正したら、同じURLに上書きアップロードしてから「修正しました」と返信するだけでよい。メールにファイルを再添付して再確認を依頼する従来のフローと比べ、全員が常に最新版を見ている状態を維持できる。
開発フェーズに移行してステージング環境が立ち上がったら、モックのURLを無効化し「本番確認はこちら」と新しいURLに誘導するページに差し替える。モックと開発版が並存すると「どちらが正しいか」という混乱を招くため、切り替えのタイミングを関係者に周知してから無効化する。
よくある質問
モックに動的なデータを表示したいのですが、JavaScriptで外部APIを呼び出すことはできますか？
HTMLに記述したJavaScriptはそのまま動作するため、外部APIの呼び出しも可能です。ただし本番APIを直接呼び出す場合はCORSの設定が必要になることがあります。モック用途ではローカルのJSONデータをハードコードする方法が確実です。
複数のモックバリアント（案A・案B）を同時にレビューしてもらう場合はどうすればよいですか？
案ごとに別スラグでURLを発行し、レビュー依頼メールに両URLを並べて記載します。レビュワーがURLを行き来できるよう、各モックのページ内にもう一方へのリンクを設置しておくと比較がしやすくなります。
社内ポータルのモックに社内ロゴや画像を使用している場合、著作権や機密性の問題はありますか？
自社のロゴは通常問題ありませんが、社外秘の資料の画像スキャンや外部の著作物が含まれる場合は除去または差し替えてからアップロードしてください。アクセスが限定されていても、権利の観点では公開に準じる扱いが安全です。