毎日が納期のデスマーチを普通のウォーターフォール案件に戻した話

毎日が納期！

ウォーターフォールの案件をやっていたはずなのに、気づけば毎日納期に追われてデスマーチになっている。
タスクを細かくして小日程でWBSを書くのは必要なことかもしれませんが、果たして本当に一日単位で遅延したとかしてないとか報告してリカバリー策を立てるのがプロジェクトの前進に貢献しているのでしょうか。

ブラック案件とホワイト案件を分けるもの

一日も休んでいけない案件ってブラックですよね。休みたいときに休める、これが社会人の基本です。それが権利です。権利を行使できない案件はブラックです。
一日単位ですべて予定が詰まっていると、休みたいときに休むことはできなくなります。
納期優先とかコスト優先とか色々言いますが、人よりも大事なものはありません。毎日毎日遅くまで働いてその人が倒れたら、遅延は何日どころではなく、回復を待つにしても代替要員を充てるにしても、大幅に遅れます。
極論、その人が脱落して辞めた場合、誰かが穴を埋めるなら、「その人しかできない」ということもないし「一日の遅延も許されない」こともないです。ならば最初から、休める仕組みにしておくのが安全です。

そもそもの原因は細かすぎるスケジュール

概算を出すために、細かすぎるスケジュールで線を引いてしまったのが悪夢の始まりでした。社内的に細かいスケジュールを出すのはいいですが、社外に出すときは報告したい単位にまとめるべきだったと思います。反省。

さあここから戻すぞ！

自分で細かくしたものは、自分で大きく括りなおしました。

1. 1日単位では計画通りにいかないことは当然ありうる

当然ですが、1日単位では原因が特定できなかったり、他の差し込みの仕事が入ったり、上手くいく場合ばかりではありません。
この当然のことを前提として説明する必要があります。
ここに納得してもらえない場合は、相手方も1日単位では計画に間に合っていないことを色々持ち出して、こんなのはお互いのためにならないと言います。

2. 「遅延は1週間以内にリカバリーします」

1週間以内でその遅延を吸収できるなら不問にしてくれ、という話です。
もともと納期がずいぶん先のウォーターフォールなので、1週間で解消できて最終的な納期に間に合うならということで納得できそうな話です。
1週間のうちにリカバリーすればいいなら、有給を一日くらいとってもよさそうな雰囲気になってきます。残業も、今日は終わりにして明日にしようとできそうです。1日単位から1週間単位へ、これは大きな進歩でした。

3. 遅れが想定されている場合は納期を待たずに早めに報告

最初から遅れることが分かっている場合、早めに言えば「遅れ」から「リスケ」になります。それで結局早く終わったらそれで良いし。首を絞めているのは報告して怒られたくないなみたいな無駄な抵抗で、さっさと頭を下げてリスケしてもらったほうがリスクは減ります。

4. 説明責任は果たす

上記１～３の上で、不明な点があった場合は説明責任が果たせていないので、その場合は説明不足であれば納得してもらえるまで説明します、という「説明や報告したくないわけじゃないアピール」をしておきます。
その案件自体は、説明不足を指摘されたことはないです。
（あるかもしれないですが、記憶に残るほど重大なことはなかったです）

5. チケットの発行先を集約

客先に直接担当を指定させると、その人が指定された納期の中でやらないといけなくなります。窓口となるSEが集約して、内容を把握・納期を調整して、担当に振ります。全部私に振ってください、というのは中々しんどい宣言ではありますが、メンバーを潰さないことが役目なので、そこは頑張るしかないです。名前を指定していくだけなので、慣れれば大したことではありません。
これにより、偏って担当指定されるのを防ぎます。

戻ったプロジェクトの進捗

進捗は遅れたり、前倒したりしています。
戻したからって進捗が全部オンスケや前倒しになるわけではありません。
本当はもう少し色々と反省点もありますが、今回はウォーターフォールに戻すところまでです。