アジャイルという開発手法の罠
開発案件がスタートするときにいつも考えるのが、
・ウォーターフォールでいくか
・アジャイルでいくか
・それぞれの中間でいくか
という開発手法の部分です。
以前から「アジャイル開発」という言葉には罠があると考えていました。
その罠というのは、
「細かな改善を加えていくのでウォーターフォールに比べお客様満足の高いシステムができる」
というものです。（完全に主観ですが。。）
ただし、アジャイルで開発する成功パターンの必要条件というものも
僕の中で考えがあって、それは
・お客様の要望をプログラム実装イメージまで仕様を決める人間がすぐに落とせること
・開発者がお客様の業務要件まで深く理解してシステムを実装できること
・開発者が一般的な開発者と比較し、10倍以上の高い生産性を持っていること
です。
上記条件が揃わないと、
・永遠にお客様の要望を取り入れ続けるけどシステムは永遠に完成しない
というお客様にとっても、開発側にとっても、残念な結果をもたらすと思っています。
社内のエンジニアにそのような話をしたら、「アジャイル宣言」を教えてくれました。
-「人と人の対話」 を 「プロセスとツール」 より優先する
-「動作するソフトウェア」 を 「包括的なドキュメント」 より優先する
-「顧客との協調を」 を 「契約交渉」 より優先する
-「変化への対応を」 を 「計画の遂行」 より優先する
すごくまとまっていて、本当にそのとおりだー、という衝撃を受けました。
でもやっぱり、罠があるよなーと再認識しました。
—
タグ: アジャイル
