何が共有しづらいのか
社内ツールのプロトタイプは「受注管理」「在庫照会」「勤怠申請」など実業務に近いUIを含むため、ダミーとはいえ従業員番号や取引先コードのような形式のデータが入ることがある。社外に漏れると情報管理規定に抵触する可能性があり、共有経路の選択に慎重にならざるを得ない。
プロトタイプを実機で触れてもらいたい相手が全国の営業所にいる場合、ローカルサーバーでのデモは現実的でない。リモートから誰でも開けるURLがあれば、テレビ会議中に「今見ていただけますか？」と促して同じ画面を見ながら議論できる。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
URL化する前の確認点
社内ツールのプロトタイプには、業務フローの設計書から転記した「社外秘」レベルの用語や数値が混入しやすい。HTMLをテキストエディタで開いてコメントアウトされた部分も確認し、`<!-- TODO: 実際のDB値 -->`のような記述がないかチェックしよう。コメントはブラウザの開発者ツールで誰でも見られる。
社内ツールのUIはしばしばiframeで別システムの画面を埋め込んでいる。公開URLからiframeで社内システムを参照しようとすると、X-Frame-Optionsの設定によって表示がブロックされる。公開前にiframeの参照先をダミー画像に差し替えるか、iframe部分だけスクリーンショットに置き換えた静的版を作ると確認がスムーズだ。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
認証と期限の決め方
社内限定のプロトタイプには会社ドメイン認証が最も合理的だ。`@company.co.jp`のアドレスを持つ社員だけが自動的にアクセスでき、人事異動で部署が変わっても同じURLが使い回せる。外部ベンダーにも確認してもらう場合はメール認証でベンダーアドレスを個別追加すればよい。
プロトタイプの確認フェーズは通常「初回レビュー → 修正 → 最終確認」の2〜3ラウンドで完了する。期限をラウンドごとに設定し、「初回レビュー期限: 6月30日、最終確認期限: 7月14日」のように段階的に管理すると、プロジェクト計画と連動しやすい。
- 誰でも見てよい: URL共有のみでもよいが、検索除外は確認する
- 特定の相手だけ: パスワードまたはメール認証を使う
- 会社内だけ: 会社ドメイン認証を検討する
- 短期レビュー: 期限を設定して古いURLを残さない
共有後のフィードバック回収
業務担当者からのフィードバックは「この操作は毎日何十回もするのに手順が多すぎる」「エラーメッセージが英語で意味がわからない」など、実務目線の具体的な指摘が多い。こうした声を拾うために、フィードバックフォームに「1日に何回この操作をしますか？」という頻度の質問を加えると優先度付けに役立つ。
プロトタイプのレビューでは「この機能は最終的に実装されるのか？」という質問が出やすい。依頼メールに「今回確認いただくのはUIとフローのみで、バックエンドとの連携は別途実装します」と明記しておくと、機能の有無に関する問い合わせを減らせる。
- 確認してほしい観点を3つ以内に絞る
- 期限と返信先を明記する
- 修正後も同じURLで見られるか伝える
- 最終版と途中版が混ざらないようタイトルを付ける
よくある質問
社外のベンダーにも確認してもらいたいのですが、社内ドメイン認証だと弾かれますか？
会社ドメイン認証は指定したドメイン外のメールアドレスでは認証できません。ベンダーのメールアドレスをメール認証で個別に追加するか、パスワード認証に切り替えてパスワードをベンダーにのみ共有する方法が現実的です。
プロトタイプのコメントアウト部分は公開後も見えますか？
はい、HTMLコメント（<!-- -->）はブラウザの開発者ツールのソースビューで誰でも確認できます。機密情報を含むコメントは公開前に必ず削除し、代わりにコメントなし版を別途保管する運用にしましょう。
全国の支社にいるメンバーに同時にレビューしてもらう際の注意点はありますか？
同時に大人数がアクセスするとホスティング側の転送量制限に引っかかる場合があります。事前にサービスの同時接続制限を確認し、段階的に（例えば支社ごとに時間をずらして）案内するとアクセス集中を避けられます。