あれ、よく考えたらウォーターフォールのこと「ちゃんと知らない」と気づいたときにしたこと

と気づいたは、15年以上くらい前だったと思います。自分に人差し指を指して、

「お前、システムエンジニアとして必要な基礎知識をどれだけ持っているんだい」

と突き詰めたら、そう言えばウォーターフォールなんて「ちゃんと勉強したことがないなぁ」と。ひとかどのシステムエンジニアとして、その先のなりたいプロジェクトマネージャなら一層そうした知識をちゃんと知って、どうやってシステム開発をすればいいのか使いこなせないとクソの役にも立たないシステムエンジニアで歳だけ取ってしまうゾ、と。だから

「ヤバイ！」

と思っても仕方がないわけです。

たまたまjoinしていたプロジェクトが重厚長大の金融システムのプロジェクトだったこともあって、勉強しなおすにはちょうどいいかと。いやいや、プロジェクトごとのシステム開発手法なんて、それこそプロジェクトごとに亜流でしなくてこれが本流のウォーターフォールだ、なんて言えないことはわかっている。

ただ、重厚長大なプロジェクトであるからこそ、それ以上に無駄にゴージャスにシステム開発手法の開発標準や管理要領にコストを掛けて整備するなんてありえない。たぶん、自分自身、これから同じ規模のプロジェクトを経験することもなかろう、と見切って、これを特上のケースとして位置付けた、と思う。
＃昔のことだからね。

これで、最上級の超ど級のプロジェクトのシステム開発手法の考え方を手に入れた。

これ以降経験するプロジェクトはこれより軽量級だと思うと、いかにプロジェクトの体力に合わせてテーラリングするかと考えるようになる。落としていいところと落としちゃダメなところ。これを判断基準にプロジェクトマネジメント管理も考える。

もし、その超ど級な重厚長大なプロジェクトに参画していなくて、中小のプロジェクトしか経験がなかったらどうだったかなぁと思うとちょっとコワイ。だって、知らないことはわからないんだから。人は経験してできることをベースにしか解決の手段を持ち出せないでしょう。

そういうことです。知らないことはできないし、発想もできない。

クソなプロジェクトでも自分の知らないシステム開発手法の工夫点があるかもしれない。プロジェクトマネジメント管理でも自分の知らないことをプロジェクトマネージャがやっているかもしれない。

そうしたことを自分のシステム開発手法のアイテムとして一旦は取り込んでおくんですよ。いつ、役立つかはわからないけど。プロジェクトマネジメント管理のtipsも同じに。自分のディクショナリを育てるつもりでね。

今はそうそうビックなプロジェクトに参画する機会が少ないから、だったら得られることから得るしかないじゃない。それも、これが正調ウォーターフォールのシステム開発手法と言えるテンプレートや教科書がないんだから。

そういう本を書きたいなぁ。