高石市のホームページ修正依頼｜症状を再現できる依頼票の作り方

「スマートフォンでレイアウトが崩れる」「送信ボタンを押しても反応しない」「昨日までは見られたページが開かない」。ホームページの修正を急いで頼みたいときほど、「とにかく直してください」とだけ伝えたくなります。しかし、修正担当者の端末では症状が出なければ、原因調査はそこで止まります。

早く直すために必要なのは、専門用語ではありません。どのURLで、どの端末を使い、何をしたら、何を期待したのに、実際はどうなったかを一件にそろえることです。症状を再現できれば、調査範囲、見積もり、仮対応、修正後の確認条件を具体化できます。

この記事では、高石市でホームページ修正を外注したい事業者向けに、表示崩れ、リンク、フォーム、画像、動作不良等を「再現できる依頼票」にまとめる方法を解説します。部分改修全般の選び方ではなく、不具合の伝達と受入確認に焦点を絞ります。

「直してほしい場所」と「起きている症状」を分ける

依頼者が見えている場所と、原因がある場所は同じとは限りません。スマートフォンのボタンが押せない原因が、ボタンそのものではなく、透明なメニューの重なりにあることもあります。画像が表示されない原因が、画像ファイル、URL、権限、配信設定のどこにあるかは、調べるまで分かりません。

依頼票では、原因を推測して指示する前に観察事実を書きます。

曖昧な依頼	再現に役立つ依頼
スマホ表示を直して	このURLを幅390pxで開くと料金表が画面右へはみ出す
フォームが動かない	必須項目を入力して送信すると読み込み中のまま完了画面へ進まない
画像がおかしい	トップの2枚目の画像だけ縦に伸び、元画像の比率と異なる
ページが遅い	モバイル回線で対象URLを開くと主画像が長く空白になる
前と同じに戻して	変更前の画面と比べ、見出し下の余白とボタン位置が違う

原因の候補は修正担当者が調べます。依頼者は、再現条件と事業への影響を正確に伝えます。

不具合は一件一症状で管理する

「スマホ崩れ、料金変更、写真差し替え、フォーム確認をお願いします」と一つの依頼にまとめると、何が完了したか分かりません。料金変更は定型更新、写真差し替えは素材更新、表示崩れとフォーム不良は原因調査を伴う修正です。

一件一症状に分けると、次が明確になります。

再現できたか
緊急度はどれくらいか
調査と修正の担当者は誰か
見積もり対象はどこまでか
仮対応が必要か
何を確認すれば完了か

同じ原因で複数ページに症状が出る場合は、一つの親案件にまとめ、影響URLを子項目として記録します。

依頼票に必要な8項目

専門的なログがなくても、次の8項目があれば初期調査を始めやすくなります。

項目	書く内容	例
1. 対象	完全なURL、ページ内の場所	料金ページの比較表
2. 環境	端末、OS、ブラウザ、画面幅	iPhone、Safari、縦向き
3. 前提	ログイン、会員、入力済み情報	未ログイン、初回訪問
4. 手順	症状までの操作を番号で記載	メニュー→料金→申込
5. 期待結果	本来どうなるべきか	完了画面と受付メールが出る
6. 実際の結果	画面・文言・動き	ボタン後に同じ画面で止まる
7. 発生状況	毎回・時々、初回日時	3回中3回、15時頃から
8. 影響	誰が何をできないか	新規顧客が予約できない

修正担当者が同じ操作をして同じ結果を得られることが目標です。端末名が分からなければ、「会社支給のAndroid」「WindowsのChrome」程度でも構いません。分かる範囲と不明な範囲を分けます。

URLは画面の住所欄から完全な形で送る

「サービスページ」「問い合わせ画面」だけでは、似たページやテストページを取り違えることがあります。ブラウザの住所欄から、`https://`で始まる完全なURLをコピーします。

次の違いにも注意します。

パソコンとスマートフォンでURLが変わるか
ログイン後だけ表示されるURLか
広告やメールのリンクから入ったときだけ値が付くか
入力画面、確認画面、完了画面のどこか
PDFや外部予約サイトなど自社サイト外か

外部サービスで起きている症状は、WordPressの修正だけでは直せない場合があります。責任範囲を特定するためにもURLが必要です。

端末・ブラウザ・画面幅を記録する

同じURLでも、画面幅、ブラウザ、OS、ログイン状態、キャッシュ、通信環境等で症状が変わります。「スマホ」とだけ書かず、分かる範囲で環境を残します。

表示崩れでは、端末の機種名より実際の表示幅が重要な場合があります。ブラウザの文字サイズを拡大している、横向きにしている、表示倍率を変えている場合も記録します。

W3Cのリフローに関する解説では、通常の文章等は狭い表示領域でも情報や機能を失わず、二方向のスクロールを必要としないことを目的としています。一方、表や地図のように二次元配置が必要な部分は例外になり得ます。依頼票では「ページ全体が横へ動く」のか「表の中だけ横へ動く」のかを分けます。

再現手順は最初の画面から番号で書く

修正担当者が同じ状態を作れるよう、途中の操作を省略しません。

対象URLを新しいタブで開く
画面上部のメニューから「料金」を選ぶ
比較表を下までスクロールする
二つ目のプランの申込ボタンを押す
必須項目を入力し確認画面へ進む
送信ボタンを押す

「何度か触ると止まる」ではなく、何を何回したかを記録します。前の画面へ戻った、ページを再読み込みした、別タブから戻った等も再現条件になります。

操作順が長い場合は画面録画も役立ちます。ただし、入力中の氏名、電話番号、メールアドレス、顧客情報、管理画面URL、認証情報が映らないよう確認します。

期待結果と実際の結果を別の文にする

「送信できません」だけでは、正しい動作が明確ではありません。期待結果と実際の結果を一文ずつ書きます。

期待結果：送信後に完了画面へ移り、利用者と社内窓口へ受付メールが届く
実際の結果：送信ボタン後も入力画面のままで、どちらにもメールが届かない

期待結果は仕様書がなくても、事業上必要な状態で表現できます。修正担当者が「画面遷移だけ直せばよいのか」「メール受信まで含めるのか」を判断できます。

発生時刻・頻度・最後に正常だった時点を残す

常に起きる症状と、一時間に一度だけ起きる症状では、調査方法が違います。次を記録します。

初めて気づいた日時
最後に正常動作を確認した日時
何回試して何回起きたか
特定の時間帯、端末、回線、入力内容だけか
直前に更新した投稿、プラグイン、テーマ、サーバー設定等

「昨日までは正常」という情報だけでも、変更履歴やバックアップを確認する範囲を絞れます。原因と断定せず、「直前に行った変更」として記録します。

スクリーンショットは全体と拡大の2枚を用意する

症状部分だけを切り抜くと、どのページのどこか分からない場合があります。まずページ全体で位置関係が分かる画像を撮り、次に症状を拡大した画像を用意します。矢印や枠で示す場合、元画像も残します。

画像を送る前に、次を隠します。

氏名、電話番号、メールアドレス
顧客名、注文番号、予約内容
管理画面URLやユーザー名
ブラウザの別タブ、ブックマーク、通知
APIキー、パスワード、認証コード

IPAの用語解説でも、エラー画面のスクリーンショットをサポートへ添えると解決を早める手掛かりになる旨が案内されています。ただし、証拠を増やすために機密情報まで共有しないことが前提です。

緊急度は「困っている人数」と事業影響で決める

見た目が大きく崩れていても問い合わせは可能な場合と、見た目は小さな違いでも価格や受付が誤っている場合があります。緊急度は事業影響で判断します。

緊急度	状態	初動の例
最優先	予約・購入・問い合わせ不能、誤料金、安全上の誤案内	受付停止・代替連絡先を出し、原因調査
高	主要ページが閲覧不能、スマホ利用者の多くが操作不能	影響範囲を確認し、仮表示を検討
中	一部端末、一部ページで表示崩れ	再現条件を集め、計画修正
低	余白、装飾、軽微な文言	定期更新へまとめる

「社長が気づいたから最優先」ではなく、利用者が何をできないかを根拠にします。緊急対応の受付時間と追加費用も契約前に確認します。

仮対応と恒久修正を分ける

すぐに原因を直せない場合、事業影響を止める仮対応が必要です。たとえばフォームが送れないなら、電話・メール等の代替窓口を案内する。古い料金が表示されるなら、該当箇所を一時非表示にして確認先を示す、といった方法です。

仮対応では、いつまで使うか、誰が恒久修正を追うかを決めます。一時的な注意書きが数か月残れば、新しい不整合になります。

区分	目的	完了条件
仮対応	利用者の損失・受付停止を抑える	代替手段が案内される
原因調査	再現と影響範囲を特定する	条件・原因候補・修正案が説明される
恒久修正	原因を取り除く	対象条件で期待動作になる
再発防止	同種不具合を見つける	確認項目・監視・運用が更新される

WordPressのサイトヘルス情報を安全に共有する

WordPressの「サイトヘルス」では、WordPress、テーマ、プラグイン、サーバー、データベース等の技術情報を確認できます。修正担当者が環境を把握する手掛かりになります。

ただし、診断情報にはサーバー構成やパス等が含まれることがあります。公開掲示板や誰でも見られるリンクへ貼らず、契約した担当者へ必要な範囲で共有します。サイトヘルスの警告が一つあるからといって、目の前の症状の原因と断定もしません。

デバッグ情報を公開画面へ出し続けない

WordPressにはデバッグとログの仕組みがありますが、公開サイトの画面へエラー詳細を表示すると、内部パスや技術情報が利用者に見えるおそれがあります。WordPressのサイトヘルス文書も、公開画面へのエラー表示や公開され得るログに機密情報が含まれる可能性を注意点として示しています。

調査でデバッグが必要な場合は、担当者が保存先、閲覧者、実施時間、終了後の無効化を管理します。依頼者が検索で見つけた設定を本番へ追加するのではなく、バックアップと復旧手順を確認してから行います。

修正は安全な確認環境で試す

原因が分かっても、営業中の本番サイトへ直接変更を重ねると、新たな不具合が起きたときに戻しにくくなります。影響が大きい修正は、テスト環境または限定公開の確認方法を用意します。

修正前に確認する項目は次のとおりです。

ファイルとデータベースのバックアップ範囲
現在のWordPress、テーマ、プラグインの状態
変更対象と触らない範囲
テスト用フォームが実顧客へ送信されない設定
本番反映の日時と担当者
不具合時に戻す条件

投稿本文のリビジョンで戻せる変更と、テーマ、プラグイン、設定、データベースを含むバックアップが必要な変更を分けます。

受入条件は修正前に決める

「直りました」という連絡だけでは完了を判断できません。依頼票の期待結果を、そのまま受入条件にします。

受入確認では、次を記録します。

どのURLを確認したか
どの端末・ブラウザで確認したか
再現手順を行って症状が消えたか
期待する表示・動作になったか
関連ページや共通部品に悪影響がないか
フォーム、電話、外部リンク等の行動が完了するか
確認日と確認者

修正担当者の確認と、事業者による内容・業務確認の両方が必要です。料金や受付条件の正しさは、制作会社ではなく事業者が承認します。

見積もりは「調査」と「修正」を分けて読む

再現できない不具合は、修正時間より調査時間が大きくなることがあります。見積もりでは、原因調査、仮対応、修正、テスト、本番反映、公開後確認を分けます。

確認したい内容は次のとおりです。

調査時間の上限と途中報告
再現できなかった場合の扱い
外部サービス・サーバー会社への問い合わせを含むか
修正案が複数ある場合の選択方法
対象端末・ブラウザと確認範囲
追加不具合を発見した場合の承認方法
修正記録と引き継ぎ資料

安い一式見積もりでも、調査が含まれなければ原因を追えません。反対に、明確な文言修正へ大規模な診断は不要です。依頼票が作業の不確実性を減らします。

高石市の事業目的に合わせて影響を書く

高石市の事業者向け公式ページには、商工業、創業、労働・雇用、企業立地等の異なる情報があります。同じ表示不良でも、地域店舗の予約、製造・建設会社の見積もり、採用応募、法人取引の資料請求では影響が違います。

依頼票の影響欄には「見た目が悪い」ではなく、次のように書きます。

高石市周辺の利用者が営業時間を確認できない
法人の購買担当者が仕様書をダウンロードできない
求職者が応募フォームの確認画面へ進めない
既存顧客が緊急連絡先をスマートフォンで押せない

目的が分かれば、仮対応と修正順を事業上の優先度で決められます。

そのまま使える不具合依頼票

欄	記入内容
件名	何が、どこで、どうなるかを一文で
対象URL	完全なURLとページ内の場所
発見日時	初回と最後に正常だった日時
環境	端末、OS、ブラウザ、画面向き・幅
前提条件	ログイン、会員、入力内容、流入経路
再現手順	最初の画面から番号で記載
期待結果	本来の表示・動作
実際の結果	見えた文言、動き、停止箇所
発生頻度	試行回数と発生回数
影響	誰が何をできないか
証拠	全体・拡大画像、必要なら画面録画
直前の変更	分かる範囲で更新・設定変更
希望	仮対応、恒久修正、希望期限
受入条件	どの環境で何ができれば完了か