アジャイルへの間違った理解がプロジェクトを迷走させる

みなさんこんにちは。@ryuzeeです。

アジャイルに関する間違った理解、よく聞く誤解について整理しました。

アジャイルだから仕様変更は自由？

スプリント中で実装中のプロダクトバックログアイテムの変更とスプリント内で実装するプロダクトバックログアイテムの追加は開発チームが受け入れない限り勘弁してください。それ以外のプロダクトバックログアイテムの追加は歓迎しますが、変更や追加を行えば行うほど費用はかかる可能性があります。もしくは優先順位の低い他の機能と入れ替えになります。無制限・無費用な変更はありえません。

アジャイルだから画面から決める？

そうとは限りません。何を表示したいか、何をさせたいかは決めますが、コテコテに画面遷移やUIから決める必要は必ずしもありません。 UIの層は一番変更かけやすく終わりもありません。 UIがビジネス上の大きな価値を持つので無い限り、UIの細かい調整は後回しにします。

アジャイルだからウォーターフォールでやるより早く終わる？

そもそも「プロジェクトが終わる」の定義とは何でしょうか。チームの生産性、プロダクトオーナーのプロジェクトへの協力とか変数が一杯ある中で、どのように終了を保証しますか？言えるのは、ウォーターフォールではリスクがプロジェクトの後半に集中する一方で、アジャイル開発の場合はリスクが前半に来る点です。スコープが不変の場合、プロジェクト完了のスケジュールは確率分布でしかありません。

アジャイルだから計画立てない？

むしろアジャイルの方が計画的です。リスクを減らすために、タスクを制御可能な単位まで落とし込み、自分たちの生産性と照らし合わせながら実現可能なものを積み上げていく。計画には優先順位があり、規模も相対的に算出されている。ウォーターフォールでプロジェクトマネージャーが鉛筆をなめて引いた線表が独り歩きするのとは大きく違います。

アジャイルだからウォーターフォールでやるより安くできる？

デマルコのデッドラインのように、同じプロジェクトを複数のチームでやってみて比較してみてください。この手の比較は、ゴールが完全に一緒でない限り成り立ちません。

アジャイルはテスト不要？

人力でテスト仕様書を大量に書いてテストする、ということは無いかもしれませんが、テスト自体は自動化を中心にして毎日やるのが一般的です。ただ結合テストだとか総合テストだとか、何階層もテストはしないことは多いかもしれません（もちろん案件のリスクや完成の定義等に依存する）。

アジャイルだからドキュメント不要？

動作するソフトウェア＞ドキュメントという価値観を言っているだけで、ドキュメント無しで良いとは一言も言っていません。

アジャイルだから同時並行で複数の案件できる？

まさか！同時に複数の仕事をやると、スイッチングのオーバーヘッドもあって生産性落ちるだけです。スクラムマスターが他の仕事を一杯抱えているチームは危険信号です。目が届かなくなり始めたら、スクラムチーム全体が一気に崩れる可能性もあります。

アジャイルって1人で何でもやる？1人でなんでもできないといけない？

1人じゃなくてチームです。たとえ1人プロジェクトでもチームです。ゴールを目指せるチームを作れば良いのであって、個人の能力のバラつきや得意不得意は当然あります。技術的なレイヤーで分業して人の範囲に口を出さない、という縦割りではなく、人のタスクも把握する、口を出す、助ける、一緒にやるというのは必要です。