はじめに
アジャイルでプロジェクトを管理するとは何か？を理解するために、アジャイルはどういうプロジェクトの管理に不向きなのか？という側面で整理してみました。アジャイル開発のイメージがついている方が、そのイメージをさらに納得感あるものにするのをゴールにしています。
参考書籍
アジャイルとは？
参考文献の書籍ではアジャイルを
正しいと確認できるものを継続的に作り続けるソフトウェア開発法
と定義していました。
一般的な「完成系のひな型であるプロトタイプを早い段階で作成し、それを磨いて最終成果物に近づける」というアジャイルのイメージは誤りであり、本質は「中間成果物を極力排除し、最終成果物の品質を確認し続ける」ことにあるという視点です。
この「中間成果物を見ない」という姿勢が重要で、例えば従来のウォーターフォール型であれば最終フェーズのテストでしか評価ができないという前提のもと、前段階での摘出バグ数などをベースに品質を判断しますが、アジャイルの世界ではそれが不要になります。マネジメントとして、最終成果物をウォッチし続けます。
アジャイルによるプロジェクトマネジメントの肝
プロジェクトは、Qが品質，Cが費用，Dが期間とすると以下の式で評価ができ
アジャイルは「CとDが決定している状態でQを高めていく」際に強みを発揮するプロジェクトマネジメント手法です。故に、如何にQを目標よりも大きくできるか、がプロジェクトマネジメントの方針になります。
逆に、ウォーターフォール型の場合は品質を指すQのスコープを事前に要件定義として固定した上で「CとDをどれだけ減らすことができるか」がプロジェクトマネジメントの方針になります。
よってアジャイル型の開発は万能ではなく、「あるスコープでプロジェクトを受注し、コストと期間を予定内に収めて収益を上げる」というモデルはアジャイルではマネジメントできないことが分かります。
終わりに
アジャイルは品質を高めるために用いられるプロジェクト管理方法なので、ITベンダーの請負型のようなモデルでは有効に機能させづらいです。よって、請負型でまるっと費用を請求するのではなくユーザ企業の売り上げ増加やコスト削減の一部がITベンダーに支払われるような契約が増えればアジャイルでプロジェクトを進めるメリットがあると参考書籍では述べられていました。
以上、アジャイルの入門記事でした。ご参考になれば幸いです。
