タスクに日付を設定しない設計思想

日付管理の落とし穴

多くのタスク管理ツールでは、着手予定日や完了予定日を設定することで、スケジュールをコントロールします。プロジェクト型の開発では、この方式は非常に有効です。マイルストーンに向けてタスクを逆算し、緻密な計画を立てることができるからです。

しかし、継続的改善フェーズのタスク管理では、この方式は途端に重荷になります。なぜなら、計画は頻繁に変更されるからです。新しい課題が見つかり、優先順位が変わり、差し込みのタスクが発生する。これは日常茶飯事です。

そのたびに、日付の再調整が必要になります。タスクAの完了が遅れたら、タスクBの着手日をずらし、タスクCの完了日も調整する。一つのタスクの変更が、連鎖的に他のタスクの日付調整を引き起こします。最初は真面目に調整していても、次第にその作業が負担になり、やがて計画の更新をさぼるようになります。そして気づけば、タスク管理ツールの中の計画は、現実とはかけ離れた「絵に描いた餅」になってしまいます。

タスクに日付を指定することの最大のデメリットは、計画が硬直化することです。変更に弱い計画は、継続的改善フェーズにおいては、計画として機能しません。

変更を前提とした設計思想

そこでpitboardは、計画の変更を前提とした設計を選びました。タスク自体に日付は設定せず、想定する所要日数だけを指定する方式です。

タスクの優先順位と想定日数だけで管理すると、何が起きるでしょうか。例えば、急な差し込みタスクが発生したとします。従来の日付管理では、このタスクを差し込むために、後続のすべてのタスクの日付を調整する必要がありました。しかしpitboardでは、差し込みタスクを優先順位の高い位置に配置するだけです。後続のタスクの開始時期は自然と後ろにずれますが、タスク自体の情報は何も変更する必要がありません。

タスクの内容に変更が生じても同じです。当初3日で完了する予定だったタスクが、調査の結果5日かかることが判明したとします。その場合は、そのタスクのサイズを3日から5日に変更するだけです。他のタスクの日付を触る必要はありません。

この方式の本質は、「いつ完了するか」ではなく「どのくらいかかるか」に焦点を当てることです。完了日は計画の変更によって常に動きますが、タスクの所要時間はタスクの本質的な性質です。この本質に着目することで、変更に強い計画管理が実現できます。

あえてリストから選択する理由

pitboardでは、タスクのサイズを自由入力ではなく、あらかじめ用意されたリストから選択する方式を採用しています。この制約には、明確な意図があります。

所要日数は、あくまで計画です。実際にやってみなければ、正確な工数は分かりません。だからこそ、ざっくりとした値で十分なのです。「2.3日」や「4.5日」といった細かい値を入力させるのではなく、「2日」「3日」「5日」といった大まかな選択肢から選ぶ。この制約が、かえってマネージャーの判断を速くします。

厳密な見積もりを求められると、人は慎重になり、判断に時間がかかります。しかし「だいたいこのくらい」という感覚で選べる選択肢があれば、素早く決断できます。タスク管理において重要なのは、完璧な計画を立てることではなく、おおよその見通しを持ち、それを柔軟に調整していくことです。リストからの選択という制約は、この「ざっくり管理」を促す仕組みです。

最大5日という制約の意図

サイズのリストの最大値は、5日としています。これは、タスクの適切な細分化を促すための制約です。

例えば、所要10日のタスクを計画したとします。5日が経過したとき、担当者に「進捗はどうですか?」と聞くと、「順調に50%進捗しました」と返ってきます。しかし、この「50%」は本当に正確でしょうか。

タスクが大きければ大きいほど、進捗の把握は曖昧になります。担当者が思っている50%と、実際の50%には、しばしば大きなズレが生じます。具体的な中間成果物や、明確な区切りがないタスクでは、進捗は感覚的な判断にならざるを得ません。そして、その感覚は、楽観的に偏りがちです。

10日のタスクを、例えば3日のタスク2つと、4日のタスク1つに分割したらどうでしょうか。最初の3日のタスクが完了した時点で、「3日分の作業が確実に完了した」という事実を確認できます。次の3日のタスクに着手し、それが完了したら、また確実な進捗を確認できます。タスクを細かく分割することで、進捗は感覚ではなく、事実として見える化されます。

最大5日という制約は、強制ではなく、あくまで推奨です。しかし、この制約に従うことで、チームは自然と適切なタスク分割を行うようになり、進捗の見える化が実現されます。

開発者としての葛藤と選択

タスクのサイズ指定を設計する際、一つの葛藤を抱えていました。スクラム開発では、タスクの見積もりは「ストーリーポイント」で行うことが推奨されています。ストーリーポイントは、タスクの複雑さや不確実性を相対的に評価する指標であり、担当者のスキルによって値が変わることを認めません。

しかし、pitboardのターゲットユーザーは、3〜7名の小さなチームです。そのようなチームでは、担当者のスキルレベルも様々です。ベテランのメンバーにとっては1日で終わるタスクでも、新人のメンバーには3日かかるかもしれません。

チームのマネージャーが知りたいのは、「このタスクは誰がやればどのくらいかかるか」という現実的な見通しです。

そこで、「わかりやすさ」を優先することにしました。担当者のスキルも考慮した「所要日数」という表現で、サイズを指定する。これは理論的には純粋ではないかもしれませんが、現場での使いやすさを重視した選択です。

ストーリーポイントでの設定については、今後の利用者の意見も踏まえて、機能への導入を判断していきたいと思います。