「そのタスク何日で終わる？」と、メンバーに聞かない
タスク管理でのあるある。マネージャーに「このタスク、いつまでですか？」と聞くと、逆に「何日くらいで終わりそう？」と返ってくる。僕は言われた側でもあったし、マネージャーになってから言った側にもなった。
タスクの内容は、作業する本人が一番わかっている。だから作業の見積もりも本人に聞く。定石だと思う。でも僕は、これをやめた。マネージャーである僕が日数を出して、外れたら僕の読み違いにする。理由は、メンバーより正しく見積もれるからではない。それは「バッファ」との向き合い方にある。
なお、今回の記事は「自社サービスの開発チームのプレイングマネージャー」を対象にしている。プレイングマネージャーだからこそ、タスクの日数はマネージャーが出す、という考えを書いていく。
タスクの期日は、約束なのか？
僕は、Noだ。約束にしない。そもそも不確実性が高いタスクなんだから、見積もり自体が外れてる可能性も高い。だから単なる「物差し」として機能させたい。
例えば、だれが今どれくらい抱えてるのか、今週はどのタスクが消化予定か。その大きさは、10日と20日の差は測りたいが、3日と4日の差は気にしない。だから、見積もりに精度は求めない。
それを踏まえた上で、メンバーに「何日で終わる？」と聞くとする。でもメンバーからすると、答えた数字は「約束」になってしまう。そこには、無意識のうちに「バッファ」が入る。メンバーが、コミットメントに真面目だからだ。
- 不確実性があるから、それも考慮したい
- 自分で申告するのだから、守りたい
- 終わらない確率より、間に合う確率を上げたい
だからバッファが必要になるし、その気持ちはよくわかる。でも、個々のタスクのバッファには副作用がある。それは「問題に備えてバッファを設けたが、問題が起きなくても、結局そのバッファまで使い切ってしまう」。例えば、余った時間で細かい磨きをかけたり（パーキンソンの法則）、時間に余裕があるから着手が遅くなる（学生症候群）など、身に覚えがないだろうか。バッファを積んだ分だけ、問題が発生しようがなかろうが、そのタスクは遅くなる。個々のタスクにバッファがあると、全てのタスクで起きる。
安易な上限選択
メンバーに見積もってもらうことには、バッファ以外にも問題がある。僕のチームでは、タスクのサイズが5日を超える場合は分割するルールとしていた。詳しくは、前回の記事に書いた。
2026-08-27マネジメントが嫌い。だから、管理しないタスク管理を実現したい。タスク管理が嫌いなプレイングマネージャーが、2年におよぶタスク管理ツールの個人開発で悟った「任せる管理」についての思想。
yamataka.blog
その前提でメンバーに見積もりをしてもらうと、多くのタスクが5日になった。「安全のために、とりあえず5日」「タスクを分割するほどではないから、とりあえず5日」。上限の5日が選ばれやすいが、そうすると物差しとしても機能しなくなる。
バッファも上限の採択も、どちらも「メンバーが出す数字」に起因する。
マネージャーに責任を寄せる
個々のタスクにバッファを入れたくないし、安易に上限の5日も選択したくない。だから、僕が出すことにした。
見積もりは面倒だし、労力が大きい。だから、メンバーに委ねたい。こう思うプレイングマネージャーもいると思う。
でも、ここに労力は不要だ。前回の記事で、5日を超えるタスクは分割する、そのためにはマネージャー自身がタスクを理解する必要がある、と書いた。プレイングマネージャーはコードも設計も読めるから、この時点でサイズも見えている。労力が大きいのは、見積もりではなく、タスクの分割作業のほうだ。でも分割作業には、その後にメンバーに任せるためにも、労力をかける価値がある。任せるのは中身とやり方。3〜5日という枠だけは、僕が出す。
それに、細かく正確な見積もりをする必要はない。僕は、「迷ったら小さい方」 をルールにしてる。3〜4日くらいかな、と思ったら3日を選択する。それは、バッファを排除した上で、目安として十分機能する。
バッファがないと、外れの度に調整が生じる？
マネージャーがバッファ無しで見積もる。でも、バッファがないのだから、問題が生じる度にリスケが必要になるのでは？
実は、基本的には「何もしない」で大丈夫。そのための前提として、計画を「期日」ではなく「サイズと優先順位」で考える。期日（いつまで）で計画をすると、急な差し込み作業に弱くなる。後続の作業の期日にまで影響を及ぼすからだ。予め急な差し込みを想定して、期日を後ろに伸ばすのは、バッファと変わりない。あくまで、そのタスクがどれくらいかかるか、そのサイズ（日数）と優先順位だけを定める。
これをカンバンで管理する。カードは優先度順に並んでいる。ここで、予定3日のタスクに5日かかったとする。次の優先度のタスクは、着手が2日ずれるだけ。カンバンのタスクを再調整する必要がない。これこそが、個々のタスクからバッファを排除できる仕組みだ。
もちろん、納期の厳しいプロジェクトだとこうはいかない。でも、自社サービスの継続的改善になると、納期よりも変更に柔軟に対処することが価値になる。実際に僕のチームでは変更が価値になった。だからこそ、チームの性質によって、タスク管理のやり方は大きく変わる。その話はこちらに書いた。
2026-09-16プロジェクトじゃないのに、プロジェクト管理ツールを使っていたサービスを運用しながら改善し続けるチームは珍しくない。それなのに仕事の見た目がプロジェクトだから、ツールとのミスマッチに気づかない。僕自身がそうだった。yamataka.blog
外れが大きければ、別タスクを起こす
小さな外れは何もしないが、大きな外れは、新しいタスクとして作成するのがよい。これは差し込みの扱いになる。担当するメンバーとしても、サイズを使い切ったタスクのお尻を曖昧にしたままズルズル作業するよりも、新たなタスクにしてサイズを明確にしたほうが進めやすい。
メンバーから異論が出た時
マネージャーがサイズを出す副作用で、メンバーから異論が出ることがある。特に、見積もったサイズにはバッファが無いので、メンバーからすると「足りない」と感じることがある。
このときは、基本的に「マネージャーの数字」を採用させてもらう。もちろん「メンバーの意見を無視する」という話ではない。メンバーが「足りない」と言ったとき、それが僕のタスクの理解不足なのか、単なる不確実性への備えなのかを分ける。何よりも、メンバーの数字を採用した瞬間、それはまたメンバーの約束に戻る。外れたときの責任をマネージャーの側に置き続けたい。
実際に、僕のチームでも「これだと足りないと思う」との意見がメンバーからでる。でも、話を聞いた上で、明らかな考慮漏れでなければ、こちらの数字でやってもらう。前提として「これは期待であって、責任ではない」ことをきちんと伝える。
こちらの数字で進めてもらえるのは、プレイングマネージャーの強みだ。プレイできるスキルがあるからこそ、「マネージャーは何もわかってない」とならない。
なお、異論を断った結果、実際にその日数では終わらないことも普通にある。でも、それで良いと思ってる。そもそもバッファが無いから、外れるのも当然だし、外れても、後続のタスクの再調整も不要だ。
まとめ
今回の話は、「マネージャーが見積もったほうが、正確な見積もりができるから」という趣旨ではない。バッファを断るためには、マネージャーがサイズを持つ必要がある。外れても、サイズで管理していれば、計画はその外れを柔軟に吸収できる。だから、個々のタスクにバッファをいれるメリットがなくなる。
僕が個々のタスクにバッファを積みたくなかったのは、積んだ分だけチームが遅くなるから。それを、メンバーに無理を押し付けずに断れる形が、この考えになった。