アジャイルと無計画は違う
アジャイル開発が「変更に強い」という特徴を持っていることはすでにお話してきたとおりです。ウォーターフォールに代表される従来型のシステム開発では、実際の開発に着手する前の段階で達成するべき目標を細かくブレークダウンし、その前後関係や実施担当者を決める計画手法をとってきました。
しかし、全体の計画をあらかじめ精緻に定めるというアプローチは、何千年もの歴史の中でノウハウや経験を蓄積してきた建築・建設などの世界では有効に機能しているようですが、ソフトウェア開発においては必ずしも上手く行かないことも多いようです。
要因はいくつか考えられますが、ENIACが生まれた1946年から数えても60年程度の歴史しかないこと、技術やノウハウの変化が著しい分野であること、10～25倍とも言われるプログラマの生産性の違いなどが事前の計画を難しくしていることは想像に難くありません。
また、ソフトウェアに形がない点も建築物との大きな違いと言えるでしょう。まだ見たことのないものを具体的に想像するのは難しいものです。同様に、実際の業務で使えるものになるのか、技術的に要求を実現することができるのかといった点は実際に作ってみて初めてわかる部分も少なくないのです。そうしたソフトウェアの性質を踏まえて登場したのがアジャイルという開発手法でした。
このような背景から「アジャイルでは計画自体を行わない」という考えている方が時々いらっしゃいますが、アジャイルでもプロジェクト全体の計画は行います。もちろん、前述のとおり「やってみないとわからない」のがソフトウェアの世界ですから、あまり詳細な計画は立てません。それでも計画をしないということとは全く別モノであることは押さえておきましょう。
アジャイルの作業計画と作業分担
アジャイルには、プロジェクト全体を管理する「リリース計画」と、1～4週間単位の反復開発期間であるイテレーションを管理する「イテレーション計画」の2種類が存在します。
リリース計画では、具体的なタスクにまでは踏み込まず、ストーリーと呼ばれる要求単位で大まかに作業見積りを行います。細かい作業分担や計画などはイテレーションという繰り返し毎に行われる計画の時にチームで決めて実施します。
だたし、リリース計画なければ、製品のリリースタイミングの予測もわかりませんし、どの程度変更を受け入れることができるか見通しも立ちません。プロジェクトの成功のためには、全体のスケジュールが「見える化」され、チームや関係者に共有されていること重要です。
また、計画は全体の見通しを立てるためのものであり、変更される可能性があることを忘れてはいけません。「変更がないこと」を前提に計画を立てて、それを守ろうとすると、とってもラッキーな場合以外は品質の低いソフトウェアを納品することになるでしょう。また、開発要員が必要以上に疲弊してしまうことになります。
アジャイル開発手法はひとつに定められるものではないため、リリース計画に関しても様々な考え方があります。例えば、ストーリーを一覧管理するプロダクトバックログを見れば、それぞれの優先順位と現時点でのスプリント割り当てがわかるという考えも存在しますし、リリース計画自体を忌避する考え方もあるようです。また、リリース計画に相当するものを実施するサイクルは、プロジェクトで1回というところもあれば、3ヶ月に1回程度、フェーズゲート毎など様々です。
プロジェクトの状況や業務形態の違いがあるので一概にいえませんが、そのプロジェクトで成功すればどのツールでも構わないというのが筆者個人の見解です。ただし、プロダクトバックログはリリース計画として使用するには粒度が細かいため、大まかなスケジュールやマイルストンを見える化する方法を検討するよう勧めています。
