システム開発方法論が失敗しているように見えるのは人に依存しているから

プロジェクトマネージメントに身を置くものとして、ウォーターフォールやアジャイルなどどのようなシステム開発方法論を持ってきてもプロジェクとは失敗する可能性を排除することは難しい。

デミング(PDCA)サイクル
ISO9001のQuality Management Systemが導入されて大分経つけれどその経過した時間分それを運営するエンジニアもその間に代替わりしているので、導入当初の目的はQMSの文書だけにしか残っておらず、だれもその意図まで引き継いでいないから形骸化しているのが実情ではないだろうか。

QMSで自らの組織の先人たちが定めた規定、ガイドラインに“そう書いているから”思考せず、書かれたままを他の事例も参考に焼き直す。その焼き直しには自分の思考がないから本来のQMSが狙っている継続的改善は全く思慮されない。

内部監査員もQMSの実施者と同じようにQMSの本来の主旨を理解の上に立ち監査を実施することができないから、QMSの実施者に継続的改善を促すような指摘や注記を残すことはまずない。

QMSは、その認定を継続するためだけに業務を運用されているのである。

PMBOK
PMBOKへの幻想は、システム開発方法論への無知に依る期待と同じではなかったか。PMPの認定を受けたプロジェクトマネージャがいればプロジェクトが成功するとしていなかったか。実際はどうだったのだろうか。

認定は、合格ラインを越えたものがされるものであり、合格ラインを越えても100点でないなら不正解の部分は誤った理解のまま認定を受けるのである。認定は、その認定を受けたエンジニアが一定の知識を有していることを認めているのであって、実行できることを認めているのではないことを理解していなければならない。

端的に言うなら、PMPなんて4時間ディスプレイの前で問題を解く我慢大会でしかない。情報処理試験プロジェクトマネージャは更に手書きで思考を書き写すという写経が加わるだけだ。

PMBOKは業種に依存しないどの世界でも使えるために汎化した知のフレームワークだ。だからこそ、ただの器でしかなく、情報システムのプロジェクトマネージメントとして採用するなら、PMBOKの“フレームワーク”の上に、システム開発方法論を載せる必要がある。

システム開発方法論
システム開発方法論には、ウォーターフォールやインクリメンタルやアジャイルなど幾つものやり方があって、その古くはウォーターフォールでありいまだ多くのプロジェクトで採用されている。ウォーターフォールがプロジェクトマネージメントを成功に結び付けるものかと言えば冒頭に記したとおりかなりの割合で失敗し、子細な前提を含めればほとんどのプロジェクトで何らか成功と言えない結果になっているものだ。

システム開発方法論も、ただのフレームワークである。プロジェクト管理手法の上で実際にプロジェクトのdeliverableを届けるための段取りでしかないのである。

“deliverableを届ける段取りでしかない”、というここが問題なのだ。段取りは段取りでしかなく、工程と言う作業の区切りをつけdeliverableに次第に近づけるための途中経過の中間作成物の形式は、プロジェクトが唯一無二のものであるという考えに照らせば、プロジェクトごとにテーラーメイドされるものなのである。それを理解せず、過去、たまたま上手くいったように見える結果をいくつか寄せ集め、プラクティスと称して汎化してそのまま適用しようとするから上手くいかないのである。

同じ組織の同じ部署での過去の成功が、今、自分たちの前にあるプロジェクトを成功に結び付けることは誰も予見できないのである。

つまり、いくら知のフレームワークや洗練された段取りがあったとしても、それを運営するエンジニアがそれらの主旨を理解し、実際のdeliverableとして完成させるための具体的な手順やそれを書き残し、維持する仕組みがないからシステム開発方法論が失敗するのである。

結局、エンジニアである人に依存する
どのように洗練されたフレームワークや段取りを用意できたとしてもそれを運営するエンジニアが自分のプロジェクトにテーリングできない以上、プロジェクトを成功に結び付けることは難しい。それは、運営が人に結び付いているからであり人が関わることを変えることが出来ないからなのである。

システム開発方法論は大事なことであるが、幾ら大事と言っても、いくら洗練されていると言ってもそれを運営する人に依存している以上、システム開発方法論だけを論じても意味がないのである。

ただ、システム開発方法論を知らずに食わず嫌いをするより、実践して今の自分にとって効果のある利点のつまみ食いをして、それを継続することが一番の解なのである。