Web制作・運用

Web制作案件を始めるときに決めておきたいタスク管理ルール

Web制作案件の開始時に、課題の登録単位・担当者・完了期限・状態・コメント・確認方法をそろえ、チームが迷わず仕事を始めるためのルールを解説します。

この記事で分かること

  • Web制作案件の開始時に、チームでそろえておくタスク管理ルール
  • 課題の登録者・担当者・完了期限・状態の意味を決める方法
  • 最初から運用を作り込みすぎず、開始後に見直すポイント

Web制作案件を始めるときは、要件、制作物、スケジュール、参加メンバーなど、決めることが多くあります。タスク管理の方法を後回しにすると、課題が増えてから「誰が登録するのか」「期限欄は何の日付なのか」「どこまで終われば完了なのか」が人によって変わります。

開始時に細かなルールを完成させる必要はありません。課題を受け渡し、進捗を同じ意味で確認するための最低限だけを合意し、実際に運用してから見直すことが大切です。

案件開始時に決めないと後からそろえにくい

課題が少ないうちは、口頭やチャットでも状況を覚えていられます。しかし、デザイン、実装、原稿、確認などの作業が同時に動き始めると、個人の記憶だけでは追えなくなります。

ルールがないまま課題を増やすと、次のような違いが生まれます。

  • チャットで依頼を受けても、課題にする人が決まっていない
  • 一つの課題に複数の作業が入り、どこまで終わったか分からない
  • クライアントへの提出日と、担当者の作業期限が混ざっている
  • 作業が終わった時点と、確認が終わった時点で同じ状態を使っている
  • 判断の経緯がメール、チャット、コメントに分かれている
  • 担当者未定や期限未定の課題を誰も見直していない

課題が増えてから過去分を直すより、案件の最初に意味をそろえる方が負担を減らせます。

何を一件の課題として登録するか決める

まず、チーム内で「どのような仕事を課題にするか」を決めます。会話やメモをすべて登録するのではなく、誰かの対応が必要で、完了を確認したいものを課題にします。

Web制作では、たとえば次のようなものが課題になります。

  • ワイヤーフレームを作成する
  • トップページのデザインを確認する
  • 支給された原稿をページへ反映する
  • お問い合わせフォームの送信テストを行う
  • クライアントからの修正依頼へ対応する

一件の課題には、担当者と完了条件を一つにできる範囲の作業をまとめます。デザイン作成、クライアント確認、実装のように担当者や完了のタイミングが異なる作業は、分けた方が進捗を確認しやすくなります。

一方、数分で終わる関連作業まで細かく分ける必要はありません。別の担当者へ渡す、別の期限で確認する、単独で完了を判断する必要がある場合を、課題を分ける目安にします。

課題を登録する人と担当者を分けて考える

課題を登録した人が、そのまま作業を担当するとは限りません。登録者と担当者の役割を分けて決めます。

  • 登録する人:依頼を受け取り、対応が必要な内容を課題にする
  • 担当者:課題の作業を進め、状態やコメントを更新する

たとえば、クライアントから修正依頼を受けた窓口担当者が課題を登録し、デザイナーや実装担当者を担当者に設定します。登録時に担当者を決められない場合は、誰が割り当てを判断するかと、いつ確認するかを決めます。

担当者未定の課題を作ってはいけない、というルールにする必要はありません。ただし、未定のまま見失わないよう、毎朝または週初めに課題一覧を確認する人を決めます。期限や案件への影響から今日動かす必要がある未担当課題は日次で、それ以外は週次で確認すると、毎日の確認を重くしすぎずに済みます。

期限欄に入れる日付の意味をそろえる

期限欄には、その課題自体を完了する必要がある日を設定します。クライアントへの提出日、サイト公開日、次回確認日を無条件に同じ欄へ入れると、何を終える期限なのか分からなくなります。

たとえば、金曜日にデザインを提出し、その前に社内確認が必要なら、次のいずれかで整理します。

  • デザイン作成と社内確認を別の課題にし、それぞれに完了期限を設定する
  • 一件の課題として扱うなら、社内確認まで終える日を完了期限にし、提出日を詳細へ残す
  • 複数の課題が同じ提出日に向かう場合は、マイルストーンでまとめる

提出日を詳細へ残す場合、その日付は課題一覧に直接表示されません。チーム全員が詳細の同じ箇所を確認する運用をそろえます。複数の課題が同じ提出日に向かう案件では、マイルストーンとして管理する方が全体を確認しやすくなります。

完了期限をまだ決められない場合は、無理に仮の期限を入れません。決められない理由と次回確認日を詳細またはコメントへ残し、期限未設定の課題を定期的に見直します。次回確認日は完了期限ではないため、期限欄とは分けて記録します。

Tasselの課題編集画面。件名、詳細、担当者、状態、優先度、期限などを設定できます。 課題編集画面では、担当者と完了期限を設定し、作業を始めるために必要な情報を詳細へ残します。

4種類の状態の意味をそろえる

Tasselで使う状態は、「未対応」「処理中」「処理済」「完了」の4種類です。案件開始時に、どのタイミングで状態を変えるかをチームでそろえます。

  • 未対応:まだ着手していない
  • 処理中:担当者が作業を進めている
  • 処理済:担当者の作業が終わり、確認などが残っている
  • 完了:必要な作業と確認がすべて終わっている

Web制作では、制作担当者の作業が終わっても、社内確認やクライアント確認が残ることがあります。この時点で「完了」にすると、確認前の課題が一覧から見えにくくなります。作業終了時は「処理済」、必要な確認が終わったら「完了」とするなど、完了の基準を決めます。

「確認待ち」「返答待ち」のような独自の状態が追加できる前提にはしません。待っている相手、内容、次回確認日は詳細やコメントへ残し、状態は実際の進捗に合うものを使います。

詳細とコメントへ残す内容を決める

情報を一か所へ集めても、詳細とコメントの使い分けが決まっていないと、必要な情報を探しにくくなります。

詳細に残す内容

課題の前提として、作業中に繰り返し確認する情報を残します。

  • 対応内容と対象ページ
  • 完了条件
  • 参照する原稿、デザイン、資料の場所
  • 公開や提出など、課題に関係する日程
  • 注意点や対象外の範囲

コメントに残す内容

課題の進行中に発生し、時系列で残した方が分かりやすい情報を記録します。

  • 対応した内容と確認結果
  • 途中で変わった要件や判断
  • 誰へ何を確認したか
  • 待っている相手・内容・次回確認日
  • 次に行う作業

元のメールやチャットをすべて転載する必要はありません。作業や判断に必要な要点と、元の情報へ戻れる手がかりを残します。

カテゴリとマイルストーンは必要な範囲だけ使う

案件開始時に、考えられるカテゴリやマイルストーンをすべて作る必要はありません。

カテゴリは、「デザイン」「実装」「原稿」のように課題の種類を分けて探したい場合に使います。誰が何を確認するために使うのかを決め、実際に課題一覧の確認や絞り込みへ使う分類だけを作ります。マイルストーンは、「デザイン確定」「公開前確認」「サイト公開」のように、複数の課題が同じ成果や期限へ向かう場合に使います。

最初は、実際に複数の課題をまとめて確認する必要があるものだけ設定します。使われない分類を増やすと、登録時に選ぶ手間が増え、似た意味の分類が増えやすくなります。

優先度や開始日なども、案件の判断に必要な場合だけ使います。すべての項目を埋めることを、正しい運用の条件にしません。

毎日・週初めの確認方法を決める

課題を登録しても、誰も一覧を見なければ担当漏れや期限の遅れに気づけません。案件開始時に、いつ、誰が、何を見るかを決めます。

毎日確認すること

  1. 期限を過ぎている課題
  2. 今日・明日が期限の課題
  3. 期限や案件への影響から、今日動かす必要がある担当者未定の課題
  4. 「処理中」のまま、次の行動が分からない課題

週初めに確認すること

  1. 今週が期限の課題
  2. 期限未設定の課題と、期限を決められない理由
  3. 担当者未定の課題
  4. マイルストーンの期限と残っている課題
  5. 同じ担当者への期限の集中

Tasselの課題一覧画面。状態、件名、担当者、期限日などを一覧で確認できます。 課題一覧では、担当者・状態・期限を並べ、対応が必要な課題を確認します。

進捗を読み上げるだけの長い会議にせず、担当者を決める、期限を調整する、確認を依頼するなど、必要な判断につなげます。

最初の1週間でルールを見直す

開始時に決めたルールは仮のものです。案件の種類やチームの経験によって、必要な情報や確認頻度は変わります。最初の1週間を目安に、実際の課題を見ながら見直します。

確認するのは次の点です。

  • 課題に分けた方がよい作業が、詳細の中に埋もれていないか
  • 登録者や担当者が決まらず、依頼が止まっていないか
  • 期限欄の日付を同じ意味で使えているか
  • 「処理済」と「完了」を同じ基準で使えているか
  • 詳細やコメントに、使われていない記入項目がないか
  • 日次確認と週次確認の範囲が重すぎないか

一度だけ起きた例外のために、すぐ新しいルールを追加する必要はありません。同じ困りごとが繰り返される場合に、その原因を減らすルールを追加します。誰も判断に使っていない項目や、重複している確認は外します。

案件開始時の確認項目

キックオフ時には、次の4つのまとまりで確認します。

登録

  • 何を一件の課題にするか
  • 誰が依頼を課題として登録するか
  • 担当者未定の課題を誰が見直すか

期限と状態

  • 期限欄に何の完了日を入れるか
  • 期限未確定時に、理由と次回確認日をどこへ残すか
  • 4種類の状態をいつ変更するか
  • どこまで確認が終われば「完了」か

記録

  • 詳細へ残す初期情報
  • コメントへ残す変更・判断・次の行動
  • 元の資料や連絡へ戻るための情報

確認

  • 毎日と週初めに誰が一覧を見るか
  • それぞれ何を確認し、どの判断につなげるか
  • 最初のルールをいつ見直すか

この確認項目をすべて細かな規定にする必要はありません。迷ったときに同じ基準で判断できる程度に、チームで共有します。

複数案件を同時に進める場合の確認順は、Web制作で複数案件を同時進行するときのタスク管理方法で紹介しています。ルールが増えて更新しづらくなった場合は、小規模チームでタスク管理のルールを増やしすぎない方法も参考にしてください。

まとめ

Web制作案件を始めるときは、何を課題にするか、誰が登録して担当するか、期限欄と4種類の状態をどの意味で使うかを最初にそろえます。詳細には作業の前提を、コメントには進行中の変更や判断を残します。

カテゴリやマイルストーンを最初から増やしすぎず、毎日と週初めに確認する範囲を決めます。開始時のルールを完成形と考えず、最初の1週間で実際の困りごとを確認し、必要なものだけ残します。

最低限の合意から始めることで、課題が増えたあとも、チームが同じ意味で担当者・期限・状態を確認しやすくなります。

関連記事

関連する使い方ガイド

課題の作成・管理 カンバンボードで進捗を管理 コメント・添付ファイルを使う
お役立ち記事一覧へ戻る