最近仕事をしていて、日単位で細かくスケジュールを立てることでやりにくくなって、かえって進捗がでないと感じることがあった。
一般的に、大きなプロジェクトを小さなタスクに分解して、それぞれのタスクにスケジュールをつけることで、全体のスケジュールを管理するということはよくあることだと思う。
プロジェクトの管理は必要だが、ソフトウェア開発の現場ではタスクの細かすぎるスケジュール管理はかえって非効率になるときがある。
予定通りには進まないし、調整コストが大きい
数日単位でタスクが並んでいると、非の打ち所がない計画のように見える。しかし当然だが予定通りには進ない。障害対応などの差し込みで予定していた作業ができないことがある。自分や家族の体調が崩れて普段通り働けないこともある。そもそもいつも通りに働けていても、事前に決めた予定通りには終わるとは限らない。
一日単位の細かいスケジュール管理を行っていると、少し予定がずれただけで修正しなくてはいけない。このスケジュール管理自体が開発からリソースを奪うことになり非効率的だ。
例えば日礼のミーティングがあるとする。そこで「昨日は〜があって作業が少し遅れてます」などの情報を報告し合ったり、毎日タイムラインを確認して調整したり、細かくスケジュールを立ててしまうとそういう作業が発生する。
調整コスト以外の問題
細かいスケジュール管理は、個人のエンジニアにもパフォーマンスに悪い影響を与えるだろう。毎日スケジュールどおりに進行しているかということを考える負荷が常にかかっている。
締切がある方が集中できるという考えもあるだろうが、個人が自分の持っているスケジュールを守ることに気を取られていると、誰の責任でもないがチームにとって重要なタスクは見逃されたり先延ばしにされてしまう。
個人的にはタスクは週単位でざっくり持つぐらいがちょうどいいんじゃないかと思う。体調が悪い日もあればいい日もある。思ったより長くかかったタスクもあれば、一瞬で終わったタスクもある。平均したらだいたい予定通りならそれでいい。スケジュールを調整するのは毎日ではなく、１週間や２週間くらいサイクルで行う。それくらいのスパンでみるのが割に合うんじゃないかと思う。
同じ人でも、欠乏に気を取られているときのほうがそうでないときよりＩＱが低くなるのだ。これは私たちの主張の鍵である。 (センディル ムッライナタン; エルダー シャフィール. いつも「時間がない」あなたに 欠乏の行動経済学 (早川書房))
