最遅の日を締め切りにしない

Last updated at 2024-01-14Posted at 2022-11-09

複雑な要素や関係性は抜きに、たとえば2月1日にリリースしたいものがあるとします。

この場合、ぜったいに開発が終わってないといけない日は1月31日です。正確には1月31日の29時ぐらいでしょう。

ちゃんとやれば、いつもと同じように進むなら、1月31日までには確実に終わりそうな規模感であることは、なんとなくみんな承知しています（適当な前提ですみません）。

1月31日が締め切り？

このとき、開発メンバーに「1月31日までに開発を完了してほしい」と伝えるのはどうでしょうか。

筆者はこのような伝え方をすると、次のようなトラブルに見舞われる可能性が高いと感じています。

開発が本当に1月31日ちょうどに完了する
- 前日・前々日はとても慌ただしく、品質も不安
開発に遅延が起きていることを、締切直前になって知る
- 「昨日までは1月31日までに終わりそうだったが、実は今日〜が発生して終わらないことがわかった」みたいなことになる

とくにひとつめの事態は、パーキンソンの法則として知られています。

第1法則
仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する¹

次の言い換えも引用させてください。

パーキンソンが言わんとしているのは、私たちは作業完了までの期間が決まっていると、許される限りの時間をすべて使ってしまう、ということだ。²

ここで押さえておきたいことは、締め切りを「それが完成/完了していないとトラブルが起きる日＝最遅の日」にしてはいけないということです。

「トラブルが起きる日」を締め切りにした場合、その計画の半分がギリギリでトラブルを回避でき、もう半分はトラブルを引き当てます。

締め切りを考えるとき、もっとも簡単に浮かぶ日付はたしかに「最遅の日」ですが、何も考えずに最遅の日をただ相手に伝えることは避けるべきだと感じます。

アンチパターンは説明できても、ベストプラクティスはなかなか難しいのが本件の苦しいところです。

筆者は、許されるなら、こちらが相手の支援や開発の遅延を意思決定できる最遅の日にすべきだと考えています。

たとえば、次のような理由から1月24日を締め切りにするのはどうでしょうか。

このように、なにかアクションを起こせる日付をベースにできると、多少のトラブルにもある程度余裕を持って対応できることが多いように感じます。

もうひとつ自分の考えを書くと、このような「締め切りを考える工程」そのものを相手と共有すべきだと感じることも多いです。

2月1日までにリリースしたい、直前の遅延は判断できない、リソースの調整も検討するぐらいには重要な作業である......そのほか色々な情報や計画、感情を共有し、そのうえで締め切りをいっしょに決定する。

これができると、合理的な締切が決められるだけでなく、途中の進捗確認もやりやすくなりますし、各自のモチベーションの向上にも繋がる気もしています。

相手を縛るための締め切りではなく、自由に安心して集中できるための締め切りになるようなイメージです。

とても純粋な開発を例に挙げましたが、この考え方はとくに「チーム間の依頼」で強く意識すべきだと感じることが多いです。

ぶっきらぼうに相手のチームに最遅の日を伝えるのではなく、たとえば上述したような工夫をすることで、お互いに気持ちよく仕事ができる可能性が上がるはずです。

ベストプラクティスは場面によると思うので、「〜の場合はこう考えて締め切りを決めている」などあれば是非コメントで教えてください！

締め切り≒コミットだとすると、アジャイル開発には締め切りは存在しないのでしょうか。むしろ締め切りを日々更新し続けるのがアジャイルかもな、と感じた記事です

締め切り≒目標が設定されたうえで、その目標が達成できそうかを判断することも難しい作業です。そのとき使っているフレーズをまとめてみました

似たような話題として、期待値の設定方法を考えてみました。