何が共有しづらいのか
社内ツールのプロトタイプには「田中部長」「予算：500万円」のようなそれらしい架空のデータが含まれることが多い。外部の開発会社にレビューを依頼する際にこういったデータが入ったHTMLを無防備に共有すると、守秘義務の観点で問題になる場合がある。共有前にダミーデータを完全に架空の英語名や匿名化した値に置き換えておくと安全だ。
社内ツールのモックは「誰がどの操作をできるか」という権限設計を見せることが目的になることが多い。このためクリック可能なナビゲーションや権限ごとの表示切り替えなど、インタラクションを含むHTMLであるケースが多い。こういった動的UI はファイルで添付するより、ブラウザでURLを開いてもらった方が確認してもらいやすい。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
URL化する前の確認点
Canva Codeが生成したコードにAnalyticsタグやヒートマップツールのスクリプトが含まれている場合、レビュアーの操作データが外部サービスに送信される可能性がある。HTMLを公開する前にすべての `<script>` タグをリストアップし、会社のポリシーに照らして不要なものは削除する。
社内ツールモックには `localStorage` や `sessionStorage` を使った疑似的な状態管理が含まれることがある。レビュアーのブラウザにデータが残ると、次のレビュアーが同じ端末で開いた際に前の人の操作結果が残る。共有するHTMLにはページリロード時にストレージをクリアする処理を入れておくか、「シークレットモードで開いてください」と案内を添える。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
認証と期限の決め方
社内ツールのプロトタイプを情報システム部門や経営陣に確認してもらう場合、全員が同じ会社ドメインのメールアドレスを持っているはずなので、ドメイン認証が最も運用コストが低い。パスワードの配布や変更管理が不要で、社員の入退社に合わせたアクセス制御もメールドメインで代替できる。
プロトタイプのレビューフェーズが終わり正式開発に移行したら、レビュー用URLは速やかに失効させる。失効させずに放置すると、完成後の本番ツールと混同した関係者が「あのURLに書いてあった通り動かない」とサポート問い合わせを寄越すケースがある。期限を設定してフェーズ終了と同時に自動失効させるのが理想だ。
- 誰でも見てよい: URL共有のみでもよいが、検索除外は確認する
- 特定の相手だけ: パスワードまたはメール認証を使う
- 会社内だけ: 会社ドメイン認証を検討する
- 短期レビュー: 期限を設定して古いURLを残さない
共有後のフィードバック回収
社内ツールのレビューでは「このボタンは一般社員も押せるのか」「承認フローのステップが多すぎる」といった権限設計・業務フローへの意見が集まりやすい。こういった意見は「UIの改善」ではなく「仕様変更」として別管理するためにも、フィードバック収集フォームに「操作性」「権限設計」「業務フロー」の分類ラベルを設けると整理しやすい。
ステークホルダーが複数部門にまたがる場合、誰がどの画面を確認したかをトラッキングしておくと、承認エビデンスとして活用できる。アクセスログを取得できるサービスを選ぶか、確認済みの証としてレビュアーに返信メッセージを送るよう依頼するルールを作るとよい。
- 確認してほしい観点を3つ以内に絞る
- 期限と返信先を明記する
- 修正後も同じURLで見られるか伝える
- 最終版と途中版が混ざらないようタイトルを付ける
よくある質問
社内ツールのプロトタイプに仮の従業員名を入れたまま共有しても問題ないか？
架空の名前であれば法的リスクは低いが、実在の社員名と誤解される文字列は避けるべきだ。「山田太郎」のような典型名でも、実在の社員と一致した場合にトラブルになることがあるため、明らかに架空とわかるアルファベット名や記号的な識別子を使うのが安全だ。
会社ドメイン認証を設定すれば、退職者の旧メールアドレスでもアクセスできてしまうか？
退職後に会社がメールアカウントを無効化していれば、メール認証のワンタイムリンクがそのアドレスに届かないためアクセスできない。ただし認証済みセッションが有効な場合は別途URLを失効させる必要がある。
権限ごとに表示が変わる画面を複数レビュアーに同時確認してもらいたい場合、URLはどう分けるか？
権限パターンごとに別HTMLを用意して別URLを発行するのがシンプルだ。「管理者ビュー用URL」「一般ユーザービュー用URL」のように命名したURLを、それぞれ対応するレビュアーに渡すと確認漏れが起きにくい。