ウォーターフォールの難しいところ

特段、プロジェクトの特性がなければ無意識にシステム開発手法はウォーターフォール型を選んでいるものです。まあ、場合よってはプロジェクトの特性に気づかずにウォーターフォールを選んでいるというケースの方が多いんじゃないかと思うのですが。

どこでこのネタを振っても同意いただくのですが、これがウォーターフォールの標準だよね、という型がないということです。

巷で溢れているウォーターフォールでのシステム開発は、それはもう亜流なのか突然変異なのか出所も何もわからないものばかりです。

幸か不幸か、そうした何者だかわからないウォーターフォールでのシステム開発を経験して、

「これがウォーターフォールなんだ」

と刷り込まれるのですが、そのプロジェクトが終わって次のプロジェクトに参画すると前とまた違うウォーターフォールが用意されているのです。

いや、用意されていればまだマシかもしれません。その場で自転車操業でウォーターフォールぽい何かの肝心なプロシージャを丸投げれさた何かをウォーターフォールだからと読んでいるだけなのかもしれません。

今はこれに尽きるのではと思うのです。具体的にはPMBOKとウォーターフォールは別物なのに、ひっくるめてウォーターフォールと及びされていませんかねぇ。

プロジェクトと前者は管理するための手法であり、後者はシステムを開発するための手法です。

全くもって用途が違うのです。それをわかっているエンジニアとマネジメントは少ないのです。

ウォーターフォールはあくまでもシステム開発手法です。ウォーターフォールの特性に合うシステムを開発するための手法です。手法なのでものづくりには図面が必要です。

図面にも色々あると思うのですが、これまたこれといって標準の図面がない。これとこれを文書として作ればいいというものがないのです。

ないので、直近で経験したプロジェクトの設計書を考えずに流用するわけです。でも、その流用した設計書も考えて選んでいるかどうかは別ですけど。

プロジェクトの目的を達成する、つまり、システムで業務要件を実現するプロダクトを作成するために必要なドキュメントかどうかではなく、過去に作っていたから今回もという程度で作っているのです。もし、違うよという方がおられたら是非どうしてその文書フォーマットが必要なのかご教授願いたいものです。

物理でものを作るのであれば、完成形を見ながらものを作れますし、その完成形の部品を作る、部品を組み立てるというような作業プロセスも可視化しやすいのです。

ところが、システム開発ではそうはいないのです。作るシステムが毎回似て日なるものであり、プロジェクトマネージャの経験によりかなり近似のシステムであってもプロマネの経験と知識によってシステム開発手法の具体的なプロシージャが変わってくるのです。

全くもう、これを覚えればウォーターフォール覚えたよ、がないのです。そこが難しいのです。何を覚え、実践できるようになったらウォーターフォールを使えるかという。