余裕を持って仕事を進めたいなら、余裕は後半に使いましょう


システムエンジニアのみなさんは設計書やプログラムの仕様を決めてアウトプットすることを生業とされているので、言わば「意思決定すること」が仕事と言っても過言ではありません。
#というか、さっさと決めて次のタスクに進んでください。


とは言え、現場ではもっと情報を集めてからとか、ヒヤリングしないととか、相手の情報をもらってからとかとか、どれだけ受け身なんですか。提案内容なり、要件なりからやる範囲は決まっているのだし、--もし提案内容と違うことをしなければならなことが発覚したのならそれは再見積もりがスコープの変更管理ですよ--、提案しているくらいなんだから業務知識なりソリューションなりでのテンプレートはお持ちでしょう。
#だったら、先回りしてプロジェクトのシナリオを誘導しないといけないんですよ。


WBSを作るとき、正味の作業時間に作業時間を見積もりした担当者がそれなりの作業時間を仕込んでおきますよね。その作業時間をどう使うかがそのアウトプットの納期の観点での成功/失敗の分かれ目になります。その貴重な作業時間を先の情報を受け身でもらうための時間に使ってしまっていいのかということです。それでいいの、と聞けばよくないですと答えますよね。えぇ、わかっていますよ、そう答えるのは。


計画で確保した作業時間は必要だという情報を待っているだけでも消費してしまっていることを理解しましょう。WBSを着手した時点から作業開始と思っていたらちょっと間に合うかどうか怪しくなっていると思うようにしたほうがいいです。


WBSWBSで計画した時点で完了予定日が決まるものです。予定日は「終わらすんだよね」と認識されている日付です。その認識されている日付を超過するると借金取りのように顔を会わせるたびにいる終わるのだと聞かれるんですよ。でも、しょうがない、約束してしまったんですから。


後続のWBSが幸いにもなくて調整できるなら幸いですが。


であれば、待っている受け身で時間を使うのはやめることを考えましょう。貴重なWBSの作業時間の中の一部分を待ち使うのではなく、仮説を立てて、50点や60点で進めておいて、いままで待つことで使っていた時間を後半に回して推敲したり、仕様の仔細を考えるほうに使うことにしましょう。


作業時間の余裕は前に使うものではありません。後ろにとっておいて使うものなのです。