事前準備
役員承認用URLを発行する前に、法務確認が完了しているかを確認します。効果保証表現（「必ず〜できる」「日本一の〜」など）や他社を誹謗する表現は、役員から指摘される前に法務でクリアしておかないと、修正と再承認という二重工数が発生します。法務確認済みであることを依頼メールに一言添えると、役員の安心感が高まります。
役員が使うデバイスを事前に確認しておきます。iPadのSafariやWindowsのEdgeなど、役員が実際に使うブラウザで表示テストを行います。特に大画面iPadではデスクトップとモバイルの中間サイズになるため、レスポンシブのブレークポイント付近での崩れが出やすくなります。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
確認観点
HTMLに含まれる数値・ランキング・実績値は全件、根拠の一次資料と照合します。「導入実績○○社以上」「満足度99%」などのクレームは、算出方法や調査対象が明確でなければ役員から「これは外に出せる数字か？」という質問が来ます。根拠資料とセットで事前確認できる状態にしておくと承認がスムーズです。
競合他社の製品名やサービス名が比較表に含まれている場合、商標の使い方が適切かを確認します。競合の製品名に®マークが付いている場合、比較表での使用が商標権侵害と見なされないよう、法務の見解を得てから掲載します。このチェックを怠ると役員承認後にリーガルチェックでNGになり、リリーススケジュールが大きく後ろ倒しになることがあります。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
NG例
役員承認フローで最もよくあるNGは、まだ社内合意が得られていない情報（未発表の機能・価格・提携先）をHTMLに含めたまま役員に送ることです。役員承認は「このHTMLを公開してよいか」の判断を求めるものですが、内容に社内未合意の情報が混在していると承認の範囲が曖昧になります。
もうひとつのNGは、スマホ縦持ちで確認した際に重要なCTAボタンがファーストビューの外にある状態です。役員がスマホで開いて「何をするページかわからない」と感じると、内容以前の問題として指摘を受けます。スクロールしなくても価値提案とCTAが見える構成にしてから共有します。
修正後の再共有
役員からの指摘を受けた修正は「指摘内容」「対応内容」「見送った場合の理由」を一覧にして再共有します。役員は多くの案件を抱えているため、前回の指摘内容を覚えていない場合があります。「前回ご指摘いただいた○○について、□□のように修正しました」と文脈を添えると確認が早く終わります。
再承認が必要かどうかを事前に判断してもらうため、修正内容を「軽微な修正（テキスト変更・リンク修正）」と「重要な修正（コンセプト・価格・数値の変更）」に分けて説明します。軽微な修正であれば「ご確認は不要です、ご報告まで」として報告に留めると役員の工数を節約でき、関係性としても好印象になります。
よくある質問
役員からの指摘が「感覚的で具体性がない」場合、どう対応すればよいですか？
「もう少し詳しく教えていただけますか？特に○○の部分について、どのような方向性を想定されていますか？」と具体化する質問を返します。「なんかおかしい」という感想を「ロゴの余白が足りない」という修正指示に変換する場作りが担当者の役割です。
数値クレームの根拠が社内資料しかない場合、役員に共有してもよいですか？
公開可否は数値の算出方法次第です。役員に共有する際は「この数値は○○調査（社内集計）に基づいており、外部への公開については法務確認済み」のように根拠の性質を明示してから判断を仰ぐことをお勧めします。
役員承認が下りた後に軽微な誤字を発見した場合、再承認は必要ですか？
誤字修正程度であれば再承認は不要です。ただし「修正した箇所と修正内容の報告」は必要で、「承認いただいたHTMLの誤字○か所を修正してリリースしました」と事後報告することで、役員との信頼関係を維持できます。