よくある原因
「ボタンが押せない」というレポートは実際には複数の症状を指しています。(1)視覚的にdisabledでグレーアウトしている、(2)クリックできるがイベントが発火しない、(3)クリックできるが別の要素が上に重なっていてズレた動作をする——この3パターンで原因も修正方法もまったく異なります。
相手のレポートが「なんか押せない」だけだと、どのパターンかわからないまま試行錯誤になります。最初の返信で「ボタンがグレーっぽく見えますか？」と一問だけ追加するだけでも絞り込みが一段階進みます。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
自分側で確認すること
相手から情報を受け取る前に自分でも同じURLを開き、報告されたボタンをクリックして再現するか確認します。自分の環境では動く場合は環境依存の可能性が高く、動かない場合はHTML側の問題です。どちらかを把握してから返信すると会話の効率が上がります。
HTMLソースで`disabled`を検索し、該当ボタンに`disabled`属性がついているか確認します。ついていれば削除してアップロードし直し、「修正しました。再度試してください」と伝えます。ついていなければDevToolsで`pointer-events`とz-indexを確認します。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
相手側で確認すること
非エンジニアの相手への確認依頼文面例：「お手数ですが、以下を教えてください。①ボタンはグレーに見えますか、それとも普通の色ですか？②クリックしたときにカーソルが「手のひら」マークになりますか？③使っているブラウザとデバイスを教えてください（例：iPhone Safari）。」
エンジニアの相手であれば「F12でConsoleタブを開いて、クリック時にエラーが出るか教えてください。あわせて問題のボタン要素を右クリック→Inspectして`disabled`属性とpointer-eventsの値を教えてもらえますか」と追加します。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
再発防止の運用
確認依頼メッセージのテンプレートを2種類（非エンジニア向け・エンジニア向け）用意しておき、相手に応じて送り分けます。SlackのBotやNotionのテンプレートに登録しておけば、トラブル発生時にすぐ送れます。
ボタン不具合の報告が2件以上続いたら、共有前チェックフローを見直すサインです。全ボタンを自分でクリックして確認する手順を標準化し、問題が再発しない体制を作ります。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
よくある質問
確認依頼を送ったのに相手から返信が来ません。どうすればいいですか？
24〜48時間待ってから「先日の件、ご確認いただけましたか？」と1行リマインドを送ります。それでも反応がない場合は、公開URLを開いて自分でクリック確認し、問題があれば修正して「念のため修正しました」と送るのが現実的です。
相手が「どのブラウザか」を確認するのはなぜ重要ですか？
ボタンのクリック判定はブラウザによって挙動が異なります。特にiOS SafariとChrome for Androidでは`<div onclick>`への反応が異なるため、ブラウザ名を知ることで修正方向をすぐに絞り込めます。
相手に送る確認依頼が長すぎて読んでもらえない気がします
3項目以上あるときは番号付きリストにして視覚的に分けます。本文は「①②③を教えてください」の一文だけにして詳細をリストで書くと、斜め読みされても必要な情報が目に入ります。