タスク分解では、最初に成果物を決め、個別に確認できる結果へ分け、必要な順序や依存関係を整理します。何から始めるか、何をもって終えるか、予定を調整できるかが分かる粒度で実行し、障害が見えたらさらに分けます。
「オンライン発表を準備する」は約束を表しますが、今日の起点は曖昧です。各ステップと最終的な納品をつなげながら、その起点を作ります。
活動を並べる前に成果を決める
例は顧客フィードバックの記録方法を扱う二十分の社内発表です。通して話せる原稿とデモ確認リストを用意し、二十分以内に収まることを計測します。質疑応答は別の枠です。
TodoNoteの親タスクに範囲を残します。記録、確認、次の行動までに絞り、サポート業務全体には広げません。追加したい案が今回必要かを判断しやすくなります。
確認できる結果ごとに分ける
今回は三つの要点、完成した原稿、デモ確認リスト、修正点を含むリハーサル記録の四つを用意します。この数は今回の構成であり、全ての仕事で固定するものではありません。
| 書き方 | 曖昧な点 | 具体的な次の一歩 |
|---|---|---|
| 発表を準備 | 範囲と起点 | 今回話す三つの要点を挙げる |
| 調査・相談・改善 | 確認できる成果 | 最初から最後まで話せる原稿を書く |
| 文書を開く・題名を入力 | 細かすぎて見渡しにくい | 一つの成果につながる執筆にまとめる |
| スライド完成で終了 | 実演と納品の確認 | デモ確認リストと計時リハーサル |
題名は短くし、範囲や完了条件はノートに書けます。原稿は選んだ要点を網羅し、リストには入口、操作、期待する結果を残します。
どこまで細かくすればよいか
開けば着手方法が分かるか、確認できる結果が残るか、進み方が変わったとき独立して調整できるか。この三点に曖昧さがあれば、説明を足すか分け直します。
「デモ準備」が広すぎるなら、まずフィードバック記録を見せる操作経路を列挙します。一続きの操作に含まれる個々のクリックは確認リストに置き、全てを予定上のタスクにする必要はありません。
粒度は不確実さと確認の必要性に合わせます。全タスクを同じ分数に揃えず、慣れた連続作業はまとめ、検証や情報待ちは調整しやすい単位にします。
日付の前に依存関係を見る
要点が決まってから原稿を書き、原稿とデモが使える状態になってからリハーサルします。今進められる部分を予定に置き、続く作業の時間を確保します。
親タスクに全体の納品、サブタスクに各結果と開始日を残します。納期がある場合は期限を設定し、前工程が遅れたら後工程への影響を見て予定を調整します。
実行結果で完了を確認する
例の初回リハーサルは二十四分でした。原稿はあっても二十分の発表準備は完了していません。重複した背景を削り、中心の実演を残して再計測することを記録します。
修正版が範囲と時間を満たし、デモの入口も確認できてから終えます。記録があれば、内容過多か実演の問題か、納品範囲を変える必要があるかも判断できます。
作業中に独立した検証が必要になればサブタスクを追加し、不要になった工程は外します。親タスクはチェック数だけでなく、約束した成果に照らして確認します。
今進めたい仕事一つで始める
成果を一文で書き、次の一歩と完了条件を決めます。実行して残る曖昧さを見てから、さらに分けるかを判断しましょう。
参考:Asanaの作業分解構成図のガイドは成果物に沿った整理を説明しています。ここでは個人の実行単位を扱い、大きな協働案件では責任や検収の合意も必要になります。