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

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

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

しかしウォーターフォールってもう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についてはプロトタイプを見せながらとはいえ明らかにウォーターフォールです。

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

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

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

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

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

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

参考書籍



このブログを書いている人

電子書籍「システム導入のためのデータ移行ガイドブック」著者。
新卒から外資系コンサルティングファームに所属。15年に渡り販売物流、特にCRM領域のコンサルティングに従事。
100名を超えるプロジェクトのPMOなど全体を推進していく役回りや、ユーザ企業への出向を通じた実務経験を持つ。

このブログでは、自身がかき集めた知識や経験を共有する。クライアントへの提案やソリューション開発に直結しないガラクタのようなもの。将来再利用する自分のために。同じような悩みを抱える誰かのためにブログ「外資系コンサルのガラクタ箱」を運営

スポンサーリンク