はじめに

ざっくり出してくれって言われて出した納期がいつのまにか確約になっていたり、そもそも無理な(残業が前提の)納期が設定されていたり・・・。
エンジニアの方なら多から少なかれこんな経験があるのではないでしょうか。

アジャイル開発をしていると、納期の考え方について理解してもらえないことが多々あると思います。
弊社でも過去に同じような状況が続いたので、納期の考え方を理解してもらえるように自分なりにまとめてみました。

見積もりについて

まず、大前提として、ソフトウェア開発において、見積もりは難易度が非常に高いです。
特にプロダクト定義のような初期段階での正確な見積もりは、不可能と言っても過言ではありません。

そして、見積もりはあくまで現時点での見積もりであって、確約ではありません。

見積もりと納期について、エンジニアが常々体験しているこをとディレクターなど別の役割の視点で描くとこんな感じ。

まだあまり内容が決まってない段階で、「とりあえずでいいから」と数字を聞かれるので答えた結果、いつのまにかその数字が確約となり・・・

後日こうなる。

そして、こういうのが続くので・・・

こんな思考になってしまいます。（大げさではありますが）

これをエンジニア視点で描き変えると

こんな感じ。

ざっくり見積もりで出した納期を確約にしてしまうと、納期までのバッファががどんどん大きくなっていきます。
バッファが大きくても、早く終わらせてリリースできればいいんですが、パーキンソンの法則で言われるように、基本的にバッファも含めた時間をフルに使って開発してしまうので、生産性は低くなってしまいます。

納期を決める場合は、m月d日と指定するわけではなく、範囲で指定するのが幸せへの第一歩。

過去の開発速度（ベロシティ）の最小値と最大値から完成時期を計算。
あくまで予測値として「a月b日〜c月d日」もしくは、「mスプリント〜nスプリント」のような感じで範囲指定するのがいいでしょう。

直近３スプリントの平均ベロシティから納期を計算。
現時点の平均から算出される予測値として「m月d日」もしくは「nスプリント後」というのを毎スプリント計算し直して共有するのがいいと思います。

とはいっても、状況によっては納期をこの日と決めなければいけないこともあると思います。
そんな場合は機能を交渉できるようにしてください。

ただし、納期や機能の交渉についてはエンジニアが全力を出しているのが大前提です。スプリントに全力ではないのに納期だけ交渉させてくれではいけません。

こういう話をすると、大概 「今までは出来てたじゃないか」 とか言われます。

正確（だと思っている）見積もりが出るのは、だいたい以下の３パターンだと思います。

ただし、一般的には過去から現在までの間に様々なプログラムの修正や追加がされているので、過去に同じものを作ったことがあるからといって今回も同じ工数というのはそんなに多くありません。

詳細な仕様が決まってない状態でざっくり見積もる場合は直感になります。
経験が豊富な方なら、直感でもまぁまぁ当たりますが、経験が少ないと直感の数字が当たることは稀です。
大きな機能になればなるほど、直感が当たる可能性が低くなるので、直感にするなら機能を小さくすることをおすすめします。

このパターン、結構多いんじゃないでしょうか。
少なくとも弊社では、過去このパターンが多かったと思います。

結局、プロジェクトの早期の段階で精度の高い納期を求めれば求めるほど、バッファがどんどん増えていき、精度はどんどん低くなっていきます。

無理な納期を設定すると、現場はどんどん疲弊していく。
納期に精度を求めると、バッファがどんどん増えていく。

だからこそ、プロジェクトを成功させるためには、納期の精度を追い求めるのではなく、柔軟性を持たせることが重要です。
チーム全体で状況を適切に把握し、現実的な目標を設定することで、無駄な疲弊を防ぎながら効率的に成果を上げることができるのではないでしょうか。