アジャイルもリーンもシステム開発の基本を身に着けなければどのシステム開発手法が良いかなんて言えない

ワタシのシステム開発手法とかプロジェクトのフレームワークの変遷を大雑把に記せば、ウォーターフォール、PMBOK、スクラムのように変遷してきた。その合間にはプロトタイプ手法とかRADとかもあったけれどね。

ウォーターフォールも小規模開発から大規模開発まで経験してきて、今の思考のベースラインになっているのは大規模のウォーターフォールなんだ。大規模なシステム開発で学んだことが今、様々なプロジェクトのプロジェクトマネジメントを考える際の基本とする軸とナレッジで、そのベースと目の前のプロジェクトとの差異を考慮して必要な部分だけに削ぎ落とすテーラリングするわけです。

その大規模のプロジェクトマネジメントのベースになるものがあって、それはPMBOKなんですよ。あれ、2003年に取りました。だから2000年版で認定されているわけですが、あれ、そうPMBOKだけではプロジェクト何て回せないのは一度ゆっくりPMBOKを読めばわかることです。ワタシはPMBOKを器とかどんぶりとか表現したりします。スコープマネジメントとか、進捗管理とかあるけれど、管理の概念があるだけで、現場で必要な“どうやったらいいのか”は記載されていません。

それはそうです。PMBOKはITばかり見ているわけではないんですから。医薬や建設など業種横断での共通的なプロジェクトマネジメントの概念をエッセンスとして定義しているんです。その昔、実際PMI東京支部の某委員会を担っていたとき、ITが多かったですけれど建設業界の方もおられて、「そうなんだよなぁ。いろいろな業種の知恵でてきているんだよなぁ。」と実感したものです。

ウォーターフォールをdisる人はウォーターフォールのシステム開発の標準を作れるの？
何でもそうだけど、批判的にdisる評論家のような人は実際に手が動かない。そう、言い切っていいくらい実際、「じゃあ、ワタシたちでは上手くできないので助言を頂けないか。」とアドバイスをお願いしても出てくるのはそれこそ教科書に書いてあるようなことしか言わない。

disるエンジニアに「じゃあ、どう変えたらアナタが考えるように上手く回ると思う？教えて。」と問いかけると大概「それは自分が考えることではない。」とか言うんだ。

そう言う評論家だったりdisるエンジニアは、自分の中に批評やdisるだけの対象のウォーターフォールしかもっておらず、こうやれば上手くいくんだという自分の中での標準的なシステム開発手法を持っていないんだ。ウォーターフォールだって“中途半端”でしか形式知を持っていない。中途半端でしか形式知を持っていないから、どうやればいいかという実践知が体系的にできていないんだ。

どのシステム開発手法から身に着けてもしいけれど標準化までできるようにならないと他の手法の良し悪しを本質で見極められない
今、アジャイルのスクラムが露出度としては随分目に付くようになってきたので、スクラムからシステム開発手法を覚えるエンジニアも多いのかもしれない。ワタシはね、「それもいいなぁ。」って、思うんです。

でもね、どのシステム開発手法でもなぜそうしたしくみとして出来上がっているか、“なぜ”という視点を持ってプロジェクトを体系的に見て欲しいんです。

その上で、自分がプロジェクトマネージャならどう回すか、それを興味を持って接して、習得して欲しいんです。例え、アナタがプロジェクトマネージャにならなくてもシステム開発手法は知っておかなければなりません。エンジニアとしてプロジェクトにどうかかわるか、どう振る舞うことが期待されているかを知っているか知らないかでアナタのプロジェクトの価値が変わります。知っているエンジニアには、高いコンテキストで会話できるので期待が高くなるのです。

そうしたシステム開発手法の概念を知っていること、身に着けていること、そしてそれを実践していること。そのようになれるということは、自分でプロジェクトをキャリーすることになったときのチーム運営の標準を定義して運用することが出来ると言ってもいいでしょう。

そこまでできて、全部が見渡せる、そう言ってもいいです。そこで初めていえるですよ。どのシステム開発手法が、目の前のプロジェクトに適用できるのか、を。基本となるシステム開発手法を持っているということが大きな視点での見極めができると言えるのです。