バッファゼロの見積もあり？な話

はじめに

アプリケーション開発において、バッファの重要性については多くの記事を目にしています。バッファは不確実性に対するクッションとして、遅延や予期せぬトラブルに対処するための重要な手段です。多くのプロジェクトでバッファが役立っていることは事実であり、この記事はそれを否定するものではありません。

しかし、私が現在担当しているプロジェクトにおいては、バッファを見積に含めないという決断をしました。この記事では、その理由と狙いについてお話ししたいと思います。

背景

私は現在、プロジェクトマネージャー（PM）として、特定の機能を開発し、リリースするプロジェクトに携わっています。プロジェクトの計画段階で、いつまでにどの機能をリリースできるかを概算し、スケジュールを立てます。通常であれば、この見積にバッファを含めることが一般的です。

しかし、今回のプロジェクトではバッファを設けないことを選択しました。もちろん、見積通りにプロジェクトが進行することは期待していません。間に合わないタスクが出てくることも想定していますが、それを残業でカバーしようという意図は一切ありません。

バッファを排除した狙い

私がバッファを排除した理由は、プロジェクトが計画通りに進行しなかった理由を正確に把握したいと考えたからです。見積の精度が低かったのか、途中で仕様変更があったのか、開発中に既存の不具合が見つかったのか、あるいはチーム内のコミュニケーションに問題があったのか。こうした問題を早期に検知し、適切に対処することが重要だと考えています。

バッファが存在する場合、これらの問題はバッファによって吸収され、「計画通りに進行している」と誤認される可能性があります。そのため、チーム内で問題を認識するタイミングが遅れ、改善の機会を逃してしまうことがあるのです。

チーム改善のためのアプローチ

プロジェクトの進行が計画通りにいかないとき、それを責めるのではなく、「どこかに問題があるのではないか」と考え、チーム全体で改善に向けたアクションを取ることが重要です。問題が発生した際に、過去に戻って何ができたのかを考え、次のスプリントに活かす。このようなプロセスを繰り返すことで、チームは小さな改善を積み重ね続けられることが重要であると考えています。
これは私自身もそうなのですが、人はさらにうまくできそうな余地がありそうでも問題として露出するまでは行動を移しづらいのかなと思っています。

バッファを設けないことで、チームは問題を早期に認識し、改善のタイミングを逃さないようにすることができます。

おわりに

今回のプロジェクトでバッファを排除したのは、今のプロジェクトが機能リリースに日付の制約や期日の重要性がそこまで高くなかったからできた、というだけだと思っています。当然全てのプロジェクトに適用できるわけではありません。しかし、プロジェクトの状況やチームの特性に応じて、見積にバッファを含めるかどうかを慎重に検討することは重要だと感じています。

改善を続けられるチームを育てるために、どのようなアプローチが最適なのかを常に考え、柔軟に対応していきたいと思います。