チャットでホームページの修正を頼み続けると、依頼した事実は残っても、今どこで止まっているかが見えなくなります。管理表には、依頼日・対象URL・内容・優先度・担当・状態・完了条件の7項目だけを置きます。1修正1行にすれば、次に動く人を一覧で追えます。
この表は、連絡の全文や変更履歴を保存する場所ではありません。状態は未依頼・対応中・確認待ち・完了・保留の5つに絞り、今どこで止まっているかだけを共有します。
この記事でわかること
- 修正依頼の管理表に残す7項目
- 1修正1行にする理由
- 未依頼・対応中・確認待ち・完了・保留の使い分け
- 完了条件を依頼時に決める書き方
- 管理表、チャット、更新履歴の役割分担
修正依頼の管理表は7項目で始める
最初から承認欄や作業時間まで増やす必要はありません。依頼日、対象URL、内容、優先度、担当、状態、完了条件があれば、依頼から受け入れ確認までを1行で追えます。
| 項目 | 残す内容 | 書き方の例 |
|---|---|---|
| 依頼日 | 相手へ依頼を送った日 | YYYY-MM-DD |
| 対象URL | 修正する公開ページ | https://example.com/service/ |
| 内容 | 現在の状態と変えたい内容 | スマートフォンで見切れるボタンを枠内へ収める |
| 優先度 | 今日・今月・保留の区分 | 今日 |
| 担当 | 次の行動を持つ人や役割 | 制作担当、社内確認者 |
| 状態 | 未依頼・対応中・確認待ち・完了・保留 | 確認待ち |
| 完了条件 | 何を見れば終わりか | 指定ページのスマートフォン表示でボタン全文を読める |
依頼日は、修正を思いついた日ではなく、相手へ渡した日です。まだ社内で優先順位を決めている項目は、依頼日を空欄にして状態を「未依頼」にします。
対象URLの欄は、ページ名だけで済ませません。同じ名前の下書きや旧ページを取り違えないよう、公開ページのURLを入れます。サイト全体に関わる共通部品なら、影響を確認する代表ページを内容欄へ添えます。
1修正1行にすると、止まっている場所が分かる
一つの行へ複数の修正をまとめると、状態を一つに決められません。文章は直ったが画像は素材待ち、パソコンは完了したがスマートフォンは確認中。こうした差が隠れます。
同じページを同じ日に依頼しても、完了条件が違うものは行を分けます。
- 営業時間の文章を差し替える
- 問い合わせボタンのリンク先を変える
- スマートフォンの余白を整える
この3件は別の行です。一つずつ完了にできるため、未完了の作業だけが残ります。まとめて見積もりや連絡をしても、管理表まで一行にまとめる必要はありません。
反対に、同じ目的のために切り離せない作業は一行で構いません。たとえば、見出し文とその直下の説明文を一組で差し替え、両方が公開されたら完了という依頼です。判断基準は作業数ではなく、完了を一つに決められるかどうかです。
状態は5つに絞る
状態の名前を増やしすぎると、担当者ごとに解釈が変わります。未依頼・対応中・確認待ち・完了・保留の5つで、誰の行動を待っているかを分けます。
| 状態 | 意味 | 次に動く人 |
|---|---|---|
| 未依頼 | 内容は出ているが、まだ相手へ渡していない | 優先順位を決める社内担当 |
| 対応中 | 担当が決まり、修正または調査を進めている | 制作担当・作業担当 |
| 確認待ち | 修正案や公開結果が出て、受け入れ確認を待っている | 依頼した側の確認者 |
| 完了 | 完了条件を満たし、確認も終わった | なし |
| 保留 | 今は着手せず、再開条件を待っている | 条件を用意する担当 |
「返事待ち」だけでは、誰の返事か分かりません。作業者から質問が来ているなら担当を社内確認者へ変え、状態を確認待ちにします。修正作業そのものが続いているなら対応中です。
保留には、理由と再開条件を内容欄へ短く足します。「商品写真の受領後に再開」「サービス内容の社内承認後」のように、何がそろえば動くかを残します。期限だけを置くより、再開の判断が明確です。
完了条件は依頼するときに書く
修正が終わったかどうかは、作業した量ではなく、依頼時に決めた状態で判断します。「いい感じに調整」「見やすく修正」では、確認する人によって終わりが変わります。
完了条件は、対象、端末、操作、見える結果のうち必要なものを組み合わせます。
- 指定したサービスページで、新しい営業時間が表示される
- スマートフォンの縦向きで、ボタンの文字が枠内に収まる
- 問い合わせフォームへ入力して送信し、完了メッセージまで進める
- パソコンとスマートフォンの両方で、差し替えた画像が切れずに表示される
修正方法まで指定する必要はありません。CSSをどう変えるかではなく、利用者から見て何ができれば完了かを書きます。
私は、作業方法を指定した依頼より、完了条件がはっきりした依頼のほうが早く終わると考えています。担当者が、影響の少ない手段を選べるからです。
確認する人も先に決めます。制作担当が「作業済み」にしただけでは完了にせず、依頼した側が完了条件を見てから状態を変えます。確認できない事情があるなら、誰の判断で完了にするかを依頼時に決めます。
チャットは連絡、管理表は現在地に使う
相談や質問はチャットで進め、決まった現在地だけを管理表へ戻します。管理表を会話の全文で埋めると、肝心の状態と次の担当を探せなくなるからです。
運用の流れは次の形にすると迷いません。
- 管理表の1行を使って依頼する
- 質問や資料の受け渡しはチャットで行う
- 担当または状態が変わったら表を更新する
- 完了条件を満たしたら依頼者が完了にする
- 公開後に残すべき変更だけを更新履歴へ移す
表には、会話を探すための件名や社内で決めた参照名を内容欄へ添える程度で足ります。チャットの文章を毎回貼り付けると、個人情報や認証情報まで複製する原因にもなります。
パスワードや個人情報は管理表に残さない
修正依頼の管理表は、社内外の複数人が見ることがあります。WordPressやサーバーのパスワード、認証コード、APIキー、顧客情報を置く場所には向きません。
表へ書かないものを決めておきます。
- WordPress、サーバー、ドメインのログイン情報
- APIキー、秘密鍵、アクセストークン
- 問い合わせ送信者や顧客の氏名、連絡先、注文内容
- 管理画面を開くための一時コード
- 公開前の機密情報や契約内容
認証情報が必要になったら、依頼を受ける人と共有方法を決めてから、管理表とは別に渡します。表には「管理情報は別途共有」のように、秘密を含まない事実だけ残します。
スクリーンショットも同じです。公開ページで撮り直せるなら、管理画面の画像をそのまま貼りません。個人情報が必要な不具合では、閲覧できる人を限定した保管先を社内で決めます。
完了した変更だけを更新履歴へ移す
修正依頼の管理表と、サイトの更新履歴は目的が違います。前者は作業中の現在地、後者は公開後に何を変え、どう戻すかを残す記録です。
完了になった行のうち、公開サイトや設定を実際に変えたものは、ホームページの更新履歴に残す6項目へ移します。日時、場所、変更、理由、担当、戻し方を残し、依頼中のやり取りは持ち込みません。
調査した結果、変更しなかった依頼まで更新履歴へ移す必要はありません。修正依頼の表には完了または保留として残し、サイトの状態が変わったものだけを履歴に渡します。二つの表を分けると、進行管理の列を更新履歴へ増やし続けずに済みます。
優先度を決められない項目は、依頼前に戻す
未依頼の行が増え、すべて同じ優先度で並んだら、原因は管理表ではなく判断基準のほうです。依頼する前に、影響と順番を分けます。
たまったWeb修正の依頼で優先順位を付ける方法では、修正を今日・今月・保留へ分け、緊急性、事業への影響、作業の依存関係で最初の1件を決めています。管理表に入れる前の整理として使えます。
自社で続けられる範囲と、外部へ相談する条件
管理表を作り、既に依頼している修正を1件1行へ分け、担当と状態を入れるところまでは自社で進められます。過去の会話をすべて転記せず、今の時点で分かる事実から始めれば十分です。
外部へ相談したほうが整理しやすいのは、次のような場合です。
- 制作会社、広告担当、社内担当へ同じ修正を重ねて依頼している
- 誰が確認すれば完了なのか決まっていない
- 修正と質問が混ざり、1件ずつ分けられない
- 状態を更新する担当が決まらず、表が止まっている
- 依頼の管理だけでなく、実際の更新作業も継続して止まっている
管理表を代わりに埋め続けても、承認者が社内にいなければ完了は決まりません。社内に残す判断と、外部へ任せる作業を分けるところから始めます。
おわりに
修正依頼の管理表は、依頼日、対象URL、内容、優先度、担当、状態、完了条件の7項目で始められます。1修正1行にして、状態を5つに絞り、誰の次の行動を待っているかを見える形にします。完了した変更だけを更新履歴へ渡せば、依頼中と公開後の記録も混ざりません。
複数の依頼先があり、担当と確認待ちを分けても管理が止まる。そんな場合は、社内に残す判断を切り分けるところからお手伝いできる場合もありますので、お気軽にご相談ください。
