なぜ問題プロジェクトは発生するのか

最近社内でわりと問題プロジェクトになっているところがあって、アフター６メンバーとして何故か毎日終電近くまで働いている生活を送り始めました。

もう１０年以上SEをやってきていますが、実は自分自身のプロジェクトが深刻な問題を抱えたことがなかったりします。終電過ぎても働いていたり、ということそのものはなんどもあるし、それが問題だといえば問題なんでしょうけど、ようは、最終的に出来上がるものが出来上がらなかったことがないというかね。もちろん、僕が超優秀だからというわけではなく、プロジェクト（特に客とベンダー）に恵まれた結果だとは思うんです。

今の問題プロジェクトはシステム刷新プロジェクトなんだけど

現行担当がイマイチ
業務がわからない（現行システムの担当頼み）
ユーザーが時間をとってくれない

等々で、詳細設計がレビューネックで終わらないとか、現行から新規システムで変えればいい点を無理に残したりとかまあ外部要因がいろいろあってリーダークラスが対応に追われている状況下で、作るところの主な構成メンバーの若手の面倒を見れない結果、なかなか思うように進捗しない、みたいな状況になっています。

以前からずっと心がけていることがある。それは「確信をもって設計し、作成する」ことです。このシステムはこうあるべき、と思って設計し、創りあげていく。なぜ確信が必要かというと、そこに理由があるから。理由があるのであれば、仮にそれが間違っていたとしても、間違っていたことがわりと早い段階で明確になる。「たぶん」必要だよねとか、これいらない「みたい」だよ、というのは構想段階の話であって、設計に入ったらそういうものをきちんと理由付けしてそれにしたがって行動していくことが必要だと思っているんです。
確信を持つことの利点は、ユーザーや次工程以降の作業をしてくれる人に説明がしやすいこと。そして間違いと間違った原因が発見しやすいこと。

当たり前って言えばそうなんだけど、これができていないプロジェクトは多くて、課題が課題のまま棚上げにされていつ棚卸しされるんだろうっていう状況なんてそこら中に転がっています。よくそれで先に進めるよな、とある意味感心するんだけど。

その状況は、ともすれば「決めてくれない」客や「話の分からない」客のせいにされがちなんだけど、それはダメプロジェクトの兆候。システムのプロとして、確信を持ってこうでなければならない、というのを言い続けることができれば、そういうものは自ずから決まっていくものです。もちろん、間違っていることに気づいたら全力で謝って直させてもらうのが必要になるけど。でも、そこがシステムの肝なんだよ、みたいなところをしっかりと見せていくことが出来ないと、軽視されて決めてもらえないって状況になるんだよね。
一個一個細かい課題についてというよりは、システム全体のポリシーとか、方式みたいな形で合意出来ればわりと楽チンなんです。あとはそこからはみ出るものを細かく調整していけば良いから。そしてきちんと枝葉末節とそうじゃないものを区別出来れば、客に対してもあとで直せるものと直せないものがはっきりと提示できる。検討期間が厳しいならあとで直せるものの課題は極力先送りにして重要な部分だけをいかに決めていくかってことになるはずなんだよね。

追い詰められてくると、客がバカだから、という理由に逃げがちなんだけど、バカな客を如何に洗脳して、あるいは誘導して自分たちの思っている方向で物事を進めていくことができるか、というのが優秀なシステム屋なんだと思う。

べき論をもったリーダーが引っ張っていくことのできないプロジェクトは絶対どこかで破綻したり、追い詰められたりするんだよね。