デッドラインができたならアジャイル開発をやめよう

僕は普段アジャイルコーチとして、いろんな現場の開発プロセスを支援させていただいています。多くの現場に共通する課題のひとつが「期限が決まったものをどう扱うか？」です。いろんな対策や方法が考えられますが、最近は「アジャイル開発しない」を選択するチームが増えてきた気がします。

見積もりと計画づくりの考え方が違う

従来型の見積もりと計画づくりでは、欲しい機能ありきで期間を見積もります。これは、スーパーの買い物かごに欲しいものを欲しいだけ詰め込んで（機能ありき）、レジで精算するのに似ています。

従来型は、開発する機能とスケジュールが重要なので、このような形をとってリスクをコントロールしようとしています。

一方、アジャイルな見積もりと計画づくりでは、期間（タイムボックスと呼ばれたりする）ありきで機能を見積もります。これは、子どもが駄菓子屋で、お小遣いという制約にあわせてお菓子を選びぬく（期間ありき）行為に似ています。

アジャイル開発は、変化への対応に特化した方法なので、計画に柔軟性を持たせるためにこの方法をとっています。

計画の意味が違う

従来型とアジャイル開発では、計画の意味にも違いがあります。

従来型は、「スケジュール ＝ コミットメント（達成すべきもの）」になりがちです。これは契約などでスケジュールと提供する機能が定義されるためです。

よって、デッドラインが生まれ、そのラインを死守するために開発を進めていく必要があります。

しかし、アジャイル開発の計画は「変更があるのが当然」ものなので、「スケジュール ＝ コミットメント」ではありません。イテレーションやスプリントという短い期間を繰り返す開発では、今週の予定は解像度が高くても、先々においては解像度が低いからです（ただ、前にも書いた通り、スケジュールがずれまくると信頼はなくなります）。

よって、計画はずっと暫定なので、デッドラインは存在できません（注）。

注：スコープを変えられるのであれば、デッドラインありきでアジャイル開発はできるかもしれません。

違いをまぜるな危険

アジャイル開発がうまくいかないチームの特徴のひとつとして、見積もりや計画づくり、計画そのものの違いをごちゃまぜで考えてしまう点があります。

「デッドラインが必要」なのに、アジャイル開発の計画を立てることはできません。

デッドラインが必要だという人に「アジャイルだからデッドラインを作らない。計画は変更し続ける」と説いても伝わりません。大切なのは、「達成したいこと」であって、それなくして「方法」を選べないからです。

というわけで、デッドラインがでてきたら、アジャイル開発をやめて従来型に切り替えるのも手だと思います。

この場合、アジャイル開発から従来型に切り替えるスイッチングコストは大したことはないですが、従来型からアジャイル開発に切り替えるスイッチングコストは大きくなりがちなので注意が必要です。