この記事で分かること
- 大きなタスクを分けた方がよいサイン
- 担当者・期限・完了条件を基準に課題を分ける方法
- 親課題・子課題とマイルストーンの使い分け
「トップページを作る」「お問い合わせフォームを改善する」のような大きなタスクは、目的は分かっていても、誰がどこから始めるのかが見えにくくなります。複数人の作業や確認が一件に混ざると、一部の作業が終わっても、課題全体は長期間「処理中」のままになります。
大きなタスクを進めやすくするには、単に細かな作業へ分けるのではなく、担当者・期限・完了条件が変わる地点で課題を分けることが大切です。
大きなタスクは「処理中」のまま止まりやすい
課題名が大きな成果だけを表していると、担当者は作業を始める前に、必要な工程や確認相手を考えなければなりません。
たとえば「トップページを制作する」という一件の課題に、構成、デザイン、実装、確認がすべて含まれていると、次の問題が起きます。
- 最初に誰が着手するのか分からない
- 複数人の作業を一人の担当者だけでは表せない
- デザインの期限と実装の期限を分けて確認できない
- どこまで終われば「処理済」なのか人によって異なる
- 前の工程が終わったことを、次の担当者が把握できない
- 一部が終わっても、全体の状態から進み具合が分からない
課題が長期間「処理中」の場合は、作業が遅いと判断する前に、一件の中へ異なる作業が混ざっていないかを確認します。
タスクを分けた方がよいサイン
次のいずれかに当てはまる場合は、課題を分けると進めやすくなります。
- 作業の途中で担当者が変わる
- 工程ごとに完了条件が異なる
- 別の人による確認や承認が必要になる
- 作業ごとに期限が異なる
- 一つの作業が終わらないと、次の作業を始められない
- 一部だけ完了・延期・中止になる可能性がある
反対に、同じ担当者が同じ期限に向けて進め、まとめて完了を判断できる短い作業は、一件の課題内にチェック項目として残すだけでも十分です。
担当者が変わる地点で分ける
一件の課題に設定できる担当者だけで、すべての作業を表そうとすると、ほかの人の作業が見えにくくなります。
たとえば、トップページ制作を次のように分けます。
- ディレクター：構成を確定する
- デザイナー：デザインを作成する
- 実装担当者：トップページを実装する
- 確認する人：表示と内容を確認する
それぞれを子課題にすると、実際に作業する人を担当者として設定できます。誰かが全体を見る必要がある場合は、親課題に責任者を設定します。
担当者が変わるだけでなく、作業を渡す条件も明確にします。「構成が確定したらデザインを始める」のような前提は、子課題の詳細またはコメントへ残します。
完了条件が変わる地点で分ける
課題を開いたときに、何を確認すれば完了かを一文で説明できない場合は、複数の完了条件が混ざっている可能性があります。
「トップページを作る」だけでは、デザインの完成、実装の完成、表示確認の終了のどれを指すのか分かりません。次のように、各課題の完了条件を分けます。
- 構成を確定する：掲載する要素と並び順について関係者の合意が取れている
- デザインを作成する：確認に出せるデザインデータが用意されている
- 実装する：確定したデザインが対象環境へ反映されている
- 表示と内容を確認する：対象端末で表示とリンクを確認し、必要な修正が終わっている
完了条件を分けると、各担当者が自分の作業をどこまで進めるか判断しやすくなります。
確認や承認が入る地点で分ける
制作作業が終わっても、社内確認やクライアント確認が残る場合があります。確認する人、確認期限、確認後の行動を別に管理したい場合は、確認を子課題として分けます。
ただし、すべての簡単な確認を別課題にする必要はありません。同じ担当者が作業直後に行い、同じ期限でまとめて完了できる確認は、元の課題の完了条件に含めます。
次の場合は、確認を分ける目安です。
- 作業者とは別の人が確認する
- 確認結果を待って次の工程を始める
- 確認の期限を個別に管理する必要がある
- 差し戻しや再確認の経緯を独立して残したい
確認待ちを独自の状態として追加する前提にはしません。担当者の作業が終わり、確認が残っている課題は「処理済」など実際の進捗に合う状態を使い、誰の確認を待っているかをコメントへ残します。
期限が異なる作業を分ける
一件の課題に複数の期限があると、期限欄へどの日付を設定するか分からなくなります。構成確定、デザイン完成、実装完了が別の日なら、それぞれを課題にして完了期限を設定します。
完了期限をまだ決められない課題には、無理に次回確認日を期限として設定しません。期限を決められない理由と次回確認日を詳細またはコメントへ残し、期限未設定の課題を定期的に見直します。
決められる場合は、親課題に全体の完了期限、子課題に個々の作業を終える期限を設定します。子課題の期限が親課題の期限を越えていないかを確認し、確認や差し戻しに必要な時間も残します。
細かく分けすぎない
課題を細かくするほど管理しやすくなるとは限りません。登録と更新に時間がかかり、一覧から重要な作業を探しにくくなる場合があります。
たとえば、一人の担当者が同じ作業の中で行う「見出しの文字サイズを調整する」「余白を調整する」「ボタンの色を変更する」を、必ず別課題にする必要はありません。同じ期限と完了条件でまとめて確認できるなら、「トップページの表示を調整する」という一件の課題の詳細へ記載できます。
分けるか迷ったら、次の順で確認します。
- 担当者が異なるか
- 完了条件を個別に判断する必要があるか
- 期限を別に管理する必要があるか
- ほかの作業を始める条件になるか
- 独立した確認や承認が必要か
すべて同じであれば一件にまとめ、異なるものがあれば分けます。
親課題と子課題で全体と作業を整理する
Tasselでは、同じプロジェクト内の課題を親課題・子課題として関連付けられます。大きな仕事の全体像を残しながら、実際に着手する作業を分けたい場合に使います。
基本は、親課題と子課題の2段階で整理します。
親課題に設定する内容
- 大きな仕事や成果の名前
- 全体を確認する責任者
- 最終的な完了条件
- 全体の完了期限
- 子課題を進める順序や共通の前提
子課題に設定する内容
- 担当者が実際に着手する具体的な作業
- その作業の担当者
- 個別の完了条件
- 個別の完了期限
- 次の作業へ渡すために必要な情報
階層を深くすると、どの課題を見ればよいか分かりにくくなります。まずは親課題と子課題だけを使い、子課題をさらに分ける必要が続く場合は、親課題と子課題の切り方を一度見直します。
すべての課題を親子構造にする必要はありません。一人で完了できる課題や、ほかの課題とまとめて確認する必要がない仕事は、単独の課題として管理します。
親課題と子課題はそれぞれ更新する
親課題と子課題には、それぞれ担当者・期限・状態があります。子課題を進める担当者は自分の課題を更新し、親課題の責任者は節目ごとに親課題と子課題の状態を確認します。子課題を完了しても、親課題の状態が自動的に変わる前提にはしません。
最後の子課題が完了しても、全体確認や公開準備が残っている場合は、親課題を完了にしません。誰が親課題を更新するかを最初に決め、親課題の最終的な完了条件を満たした時点で状態を更新します。
作業の順序と前提条件を残す
親子関係を設定しただけで、子課題間の依存関係や着手順が自動管理されるわけではありません。必要な順序は、親課題や子課題の詳細へ簡潔に残します。
- 構成の確定後に、デザインを開始する
- デザイン承認後に、実装を開始する
- 実装後に、表示と内容を確認する
予定が変わった場合や前提となる作業が完了した場合はコメントへ残し、次の担当者へ開始できる状態になったことと確認すべき資料を共有します。期限や着手時期が異なる場合は、各子課題へ開始日と完了期限を設定して確認します。
親課題とマイルストーンを使い分ける
親課題とマイルストーンは、どちらも複数の課題をまとめるために使えますが、目的が異なります。
- 親課題：一つの大きな仕事を、着手できる具体的な作業へ分ける
- マイルストーン：複数の課題を、共通する成果や期限のまとまりとして確認する
たとえば、次のように分けます。
親課題
トップページを制作する
子課題
- 構成を確定する
- デザインを作成する
- 実装する
- 表示と内容を確認する
マイルストーン
コーポレートサイト公開
トップページ制作以外にも、下層ページ、フォーム、原稿、公開準備など複数の課題が同じ公開日に向かう場合は、「コーポレートサイト公開」のマイルストーンでまとめます。
親課題は作業の分解、マイルストーンは案件の節目として使うと、役割が混ざりません。
Web制作での分解例
「お問い合わせフォームを改善する」というタスクを例にします。
親課題
お問い合わせフォームを改善する
完了条件：必要な入力項目と送信後の動作が確定し、対象環境で利用できる状態になっている。
子課題
- 現在の問い合わせ内容と不足項目を確認する
- 入力項目とエラーメッセージを確定する
- フォームを実装する
- 送信・通知メール・エラー表示をテストする
- 確認結果を反映する
各子課題には、実際に作業する担当者、完了条件、期限を設定します。前の作業が終わらないと始められない場合は、その前提と完了したことを詳細またはコメントで共有します。
親課題の責任者は、子課題の完了だけでなく、親課題に定めた完了条件を確認します。すべての子課題が終わっていても、通知先や本番環境での動作が未確認なら、親課題は完了にしません。
小規模チームで続けやすい分解ルール
タスクを分けるときは、次のルールから始めます。
- 担当者・期限・完了条件が変わる地点で分ける
- 確認や承認を別に管理する必要があれば分ける
- 同じ担当者・期限・完了条件の細かな作業はまとめる
- 大きな仕事をまとめて確認する場合だけ親課題を使う
- 親子課題は同じプロジェクト内で、基本は2段階にする
- 順序や前提条件は詳細へ、変更や引き継ぎはコメントへ残す
- 親課題と子課題の状態は、それぞれ担当者が確認して更新する
このルールで分けても「次に何をするか」が分からない場合は、子課題の件名や完了条件を見直します。反対に、更新する課題が多すぎる場合は、同じ担当者が同じ期限で進める作業をまとめます。
案件開始時に課題の分け方をそろえる場合は、Web制作案件を始めるときに決めておきたいタスク管理ルールも参考にしてください。分けた課題へ担当者・期限・状態を設定する方法は、タスクに着手できる状態を整える方法で紹介しています。
まとめ
大きなタスクは、担当者・期限・完了条件が変わる地点で課題に分けます。確認や承認が別の人や期限で行われる場合も、分ける目安になります。一方、同じ担当者が同じ期限でまとめて完了できる細かな作業は、一件の課題内に残します。
全体をまとめて確認する必要がある場合は、同じプロジェクト内で親課題と子課題を設定します。親課題には全体の責任者と最終的な完了条件を、子課題には実際に着手する作業と担当者を設定します。
親課題と子課題の状態は個別に更新し、作業順や前提条件は詳細またはコメントへ残します。親課題を作業の分解、マイルストーンを共通する成果や期限のまとまりとして使い分けると、大きな仕事の全体像を保ちながら、チームが次に着手する課題を判断しやすくなります。