時間が足りないという言い訳は残念

システム開発の納期は短くなる一方だ。充分な時間が確保出来ているのなら、正規の開発プロセスに従い、然るべき成果物が出てくるはずだが、工数が不足するということは、必然的にそのしわ寄せが何処かに出てくる。残業や休出で頑張るとは言え、限度がある訳だし、幾ら頑張ったところで「最終的に時間が余った」なんていうプロジェクトは未だかつて見たことが無い。結果的に、プロジェクト終了後のふり返りの場では、反省点のオンパレードとなってしまう。

  • 工数が不足していたので、要求仕様の検証が不十分でした」
  • 「時間が足りなかったので、インターフェースの整合をとっていませんでした」
  • 「納期が近かったので、充分な検証が出来ていませんでした」

だが、ちょっと待って欲しい。時間が足りないという状況は、そもそもプロジェクトの開始時から分かっていたはずだ。その前提条件を無視して、作業ワークフローを見直さず、いつもと同じやり方をいつもと同じように実行するなら、時間が足りなくなるのは当然のことだ。充分な作業工数が確保できないという前提条件なら、その対策を事前に取るべきなのだ。

  • 工数が限られるので、xxxのレビュー会議を取り止める」
  • 「開発期間が短いので、優先度の低いxxx機能の検証を省略する」
  • 「時間不足の可能性があるので、xxx処理の実装を後回しにする」

開発プロセスの適切なテーラリングを行い、ステークホルダー間で合意を取れば、「後出しジャンケン」の様な指摘は出てこないはずだ。プロジェクトの反省として「時間が足りなかった」という総括が出てくる度に、その言い訳を残念に思う。時間不足という状況に対して、絶対的な解決策はもちろん無いけれど、それなりに賢く対処する手段は有るはずだろう。少なくとも、言い訳を減らす為の工夫が全く出て来ないのは、変な話だと思う。問題の発生を見抜き、対策を事前に考え抜くのがプロジェクト計画の基本だと思っている。