プロジェクト手法は表面的な選択ではなくその特性を熟知し使うことが重要

結局ウォーターフォールでやらないとうまくいかないよねっていまだに思ってる化石のような私です。

しかしウォーターフォールってもう50年近く前に始まった手法だというのを知り驚いています。

プロジェクト手法の歴史

• 1970年　ウォーターフォール
• 1985年　スパイラル
• 2001年　XP（Extreme Programming）
• 2002年　FDD（Feature-Driven Development）
• 2003年　リーン
• 2008年　DSDM（Dynamic System Development Method）
• 2010年　カンバン
• 2011年　スクラム

2000年以降にコンサル会社で実施してきたパッケージ導入

SAPやOracleなどの業務パッケージを導入し企業の業務改革を支援してきました。その時のアプローチはSAPはともかくOracleについてはプロトタイプを見せながらとはいえ明らかにウォーターフォールです。

なぜならウォーターフォールにしないと開発規模や開発自体が複雑過ぎて本番リリースできる品質にまで高められないからです。

それに関連システムとのインターフェース部分はパッケージ外のカスタム開発にもなります。

中途半端にスパイラルやアジャイルを歌っても結局トラブって再計画する時にはがっつりウォーターフォール。その段階になって初めて見積もりの精度が高まりかつクライアント側の予算感の認識も変わり合意が可能になるという側面もあります。

手法をきっちり適用するのって言うほど簡単じゃないですよ。

ウォーターフォールだからうまくいかないわけではなくて計画の精度や資源や変更追跡が足りてないからうまくいかないのがほとんどな気がします。

アジャイルだって作ったものの整合性とかデプロイの仕組みとかちゃんと作れなかったら運用の現場は大変です。

参考書籍