修正完了の定義の作り方|「直したつもり」と「確認済み」を分ける

修正完了の定義の作り方|「直したつもり」と「確認済み」を分ける

「修正しました」と伝えた側は、もう終わったつもり。

受け取った側は、まだ見ていないから未完了のつもり。

制作の現場では、このすれ違いが納期前に効いてくることがあります。

スキルの問題というより、終わった意味が人によって違うことが多いです。

この記事では、責めずに揃えやすい完了の分け方をまとめます。

「直したつもり」が生まれる日常

実装した人が反映し、自分の画面では直っている。

チャットには「対応しました」と書く。

一方でディレクターやクライアントは、まだ確認していない。

どちらも嘘はついていません。

ただ、「完了」という言葉が、作業終了と確認終了の両方に使われているだけです。

ずれやすいポイント

実装完了と、目視確認が同じ言葉になっている

チームの半分は「反映したら完了」、もう半分は「確認して完了」。

進捗表の数字が、実態とずれて見えます。

チャットの「済」が、完了の代わりになっている

スタンプは速いです。

ただ、誰が・どの環境で・何を見て済にしたかは残りにくいです。

差し戻しのあと、もう一度完了にする条件が曖昧

一度閉じたあと差し戻されると、「何が足りないと同じ完了か」が人によって違います。

まずは二段で十分

難しく考えず、次の二つに分けるだけでも楽になります。

  1. 対応完了: 制作側が反映し、社内で一度見た状態
  2. 確認済み: ディレクターまたはクライアントがOKした状態

公開判断が必要な案件では、その外に「公開可」を置いてもよいです。

ラベル名はチームの言い方で構いません。

大事なのは、作業終了と合意終了を混ぜないことです。

ステータスの最小セット

増えすぎると続きません。

最初はこれくらいで足ります。

状態 意味 ボール
未対応 受付済み 制作
対応中 実装中 制作
確認待ち 反映済み 確認する人
差し戻し まだ足りない 制作
確認済み OK クローズへ

進捗会議で見るのは、「確認待ち」と「差し戻し」だけでも十分です。

ボールの所在が見えると、納期の会話が穏やかになります。

指摘ごとに、完了条件を一行入れる

タスクを切るときに、短い完了条件を添えます。

完了条件: 幅390で注記がボタンと重ならない。依頼者がステージングでOK。

実装する人も、確認する人も、同じゴールを見られます。

曖昧な依頼を受けるときは、指摘テンプレートと合わせると書きやすいです。

クライアントにも、短く共有する

制作側だけで定義を持っていても、相手が知らないと同じずれが起きます。

初回の確認依頼に、これだけで足ります。

この案件では次を分けています。
・対応完了: 制作側が反映・社内確認した状態
・確認済み: 確認者がOKした状態
公開判断は、確認済みのうえで別途相談させてください。

長い説明は不要です。

言葉が共有されているだけで、「修正しました」の解釈が揃いやすいです。

定着のための、小さな運用

  • 進捗会議の議題を「確認待ち」「差し戻し」中心にする
  • 実装した本人が、確認済みまで押さない
  • 期限切れをまとめて完了にせず、公開後へ移すか明示的に閉じる

ルールを増やすより、会議で見る数字を変える方が続きやすいです。

完了を分けると、人間関係が楽になる理由

完了を一つにしていると、誰かが「まだ」と言うたびに、作業した人が否定されたように感じます。

確認待ちと確認済みが分かれていると、「反映はできた。あとは確認の番」と説明できます。

同じ状況でも、責めている感じが薄れます。

特に外部パートナーが入る案件では、この違いが大きいです。

チャットの「対応しました」は残しつつ、正式な状態は一覧側で揃える。

その役割分担があるだけで、納期前のやり取りが少し静かになります。

完璧なワークフローより、言葉のすり合わせが先でも大丈夫です。

差し戻しを、重くしないために

差し戻しは失敗ではなく、確認の一部です。

ただ、返し方によっては相手が萎縮します。

まだここが残っています。完了条件の「注記が重ならない」が未達です。

不足を、完了条件に照らして返す。

感想だけで返すより、次の手が決まりやすいです。

差し戻しが多い週は、完了条件が曖昧なタスクが増えていないかも見てみます。

定義を先に書く習慣が、差し戻しの質を上げます。

完璧を目指すより、同じ言葉で会話できることが先です。

外部パートナーが多い案件ほど、この効果が出やすいです。

公開前の最終週は、確認待ちの件数だけを朝会で共有するだけでも空気が整います。

小さく試すなら、1プロジェクトだけ

全社でステータスを変えなくても、進行中の1案件だけで試せます。

確認待ちを明示する。

進捗共有で、その件数だけ話す。

それだけで「直したつもり」の会話が減るか見てみる。

合わなければ戻せばよく、合うなら横展開すれば十分です。

大きな改革より、案件単位の実験の方が続きやすいです。

言葉が揃ったあとに、ツールの表示を合わせると自然です。

「完了」を急がない日があってもいい

公開前は、全部を確認済みにしたくなります。

ただ、確認者が見終わっていないものを先に閉じると、あとで必ず戻ります。

その日は確認待ちのまま残し、ボールを明示する。

未完了を残す勇気の方が、見かけの進捗より安全なことがあります。

まとめ

修正完了は、コードが変わった瞬間だけではありません。

誰が、どんな条件でOKしたかがそろって、初めて確認済みに近い状態になります。

制作会社では、対応完了と確認済みを分けておくと、納期前の空気が少し楽になります。

Revoolなら、確認待ちと差し戻しをそのまま一覧できます

定義を決めたあと必要なのは、それが見えることです。

タスクテーブルでは、ステータス変更やメッセージを同じ場所で扱えます。

対応漏れ・納期切れを防ぐ、タスク別ステータス管理

全体の進みや、誰の確認待ちが溜まっているかは、ダッシュボードが見やすいです。

ダッシュボードで全体の進捗率と担当者別の進みを確認
ダッシュボードで全体の進捗率と担当者別の進みを確認

完了の認識を揃えたいときの参考に、Revoolトップもどうぞ。