スケジュールが無いなんてあり得ない！～アジャイル開発の計画と進捗管理～

アジャイルと無計画は違う

　アジャイル開発が「変更に強い」という特徴を持っていることはすでにお話してきたとおりです。ウォーターフォールに代表される従来型のシステム開発では、実際の開発に着手する前の段階で達成するべき目標を細かくブレークダウンし、その前後関係や実施担当者を決める計画手法をとってきました。

　しかし、全体の計画をあらかじめ精緻に定めるというアプローチは、何千年もの歴史の中でノウハウや経験を蓄積してきた建築・建設などの世界では有効に機能しているようですが、ソフトウェア開発においては必ずしも上手く行かないことも多いようです。

図1：通常の作業計画と作業分担

　要因はいくつか考えられますが、ENIACが生まれた1946年から数えても60年程度の歴史しかないこと、技術やノウハウの変化が著しい分野であること、10～25倍とも言われるプログラマの生産性の違いなどが事前の計画を難しくしていることは想像に難くありません。

　また、ソフトウェアに形がない点も建築物との大きな違いと言えるでしょう。まだ見たことのないものを具体的に想像するのは難しいものです。同様に、実際の業務で使えるものになるのか、技術的に要求を実現することができるのかといった点は実際に作ってみて初めてわかる部分も少なくないのです。そうしたソフトウェアの性質を踏まえて登場したのがアジャイルという開発手法でした。

　このような背景から「アジャイルでは計画自体を行わない」という考えている方が時々いらっしゃいますが、アジャイルでもプロジェクト全体の計画は行います。もちろん、前述のとおり「やってみないとわからない」のがソフトウェアの世界ですから、あまり詳細な計画は立てません。それでも計画をしないということとは全く別モノであることは押さえておきましょう。

アジャイルの作業計画と作業分担

　アジャイルには、プロジェクト全体を管理する「リリース計画」と、1～4週間単位の反復開発期間であるイテレーションを管理する「イテレーション計画」の2種類が存在します。

　リリース計画では、具体的なタスクにまでは踏み込まず、ストーリーと呼ばれる要求単位で大まかに作業見積りを行います。細かい作業分担や計画などはイテレーションという繰り返し毎に行われる計画の時にチームで決めて実施します。

図2：アジャイルの作業計画と作業分担

　だたし、リリース計画なければ、製品のリリースタイミングの予測もわかりませんし、どの程度変更を受け入れることができるか見通しも立ちません。プロジェクトの成功のためには、全体のスケジュールが「見える化」され、チームや関係者に共有されていること重要です。

　また、計画は全体の見通しを立てるためのものであり、変更される可能性があることを忘れてはいけません。「変更がないこと」を前提に計画を立てて、それを守ろうとすると、とってもラッキーな場合以外は品質の低いソフトウェアを納品することになるでしょう。また、開発要員が必要以上に疲弊してしまうことになります。

　（次ページへ続く）