nekoTheShadow’s diary

IT業界の片隅でひっそり生きるシステムエンジニアです(´・ω・`)

予定を守らせるのではなくて守れる予定を作ってくれ

楽しみにしていた4連休の前日に休日出勤を命じられたのに、何とか反発しまくって、お休みになったのでこんな記事を書いています。

プロジェクトマネージャーやチームリーダを生業にしている人、それで得たお金で家族を養っているような人にいいたい。予定を守らせるのではなくて、守れるような予定を立ててください。世の大半のシステム開発プロジェクトでは、必要なタスクをすべて並べ挙げて、それぞれのタスクにどれぐらいの工数がかかるのかを見積もるところから始まります。ただこの見積もりというのがかなりの割合でぶれてくる。予定に先行して終わればまだよいのですが、大半は工数の上振れ。つまり当初の工数ではタスクが完了できず、予定をどんどんオーバーしてしまうわけです。これが積み重なってにっちもさっちもいかなくなると、いわゆる炎上とかデスマーチとか呼ばれる状態になっていきます。

タスクが見積もり工数では終わらないとなったとき、その終わらない理由を分析し、真因を突き止め対処するというのが、プロジェクトマネージャのお仕事です。すくなくとも教科書にはそう書いているわけですが、これができる人は少ないというか、たいていはメンバーの稼働を上げて対処しようとします。要するに残業とか休日出勤とかで何とか完了させようということですね。これをすぐに言い出すマネージャは個人的に本当にだめ。遅れの原因の分析や対処をする前に休日対応・残業対応を言い出すと、そのプロジェクトマネージャを見限りたくなるというか、生理的嫌悪すら覚えます。遅れの原因を考える前に稼働を上げることを決めるというのは、要するに「事前に建てたプロジェクトプランは完璧でひとつとして修正するところがないにもかかわらず、低能メンバーどもがその高尚なプランを理解できずに遅らせている。だから何も考えられないメンバーどもには馬車馬のように働いてもらって、綺羅星のような計画を実現させてもらう」と宣言しているのとあまり変わらないわけです。こういわれて気分を害さないのであれば、よほどの聖人かマゾヒストかのどちらかでしょう。

個人的な経験からいうと、休日対応・残業対応をしても、たいていはろくなことにならないですね。目の前の納期は守れるかもしれませんが、長期的な目で見ると、悪影響しかないような気がします。いわゆるQCDの観点からすると「稼働をあげて対応」というのは、人員=Costを増やさず、納期=Deliveryも変えないということで、要するに品質=Qualityが著しく低下します。ふつうに考えれば、休みなく長時間働いていいものなんて作れないですよね。前工程の成果物の品質が下がると、後工程の品質も下がります。後工程は前工程の低品質な成果物をもとに作業を行うので、当たり前といえば当たり前。ただ品質の悪さというのは、いってみれば借金のようなもので、借金が利子で膨れ上がっていくように、後工程になればなるほど品質の悪さというのは拡大していく傾向にあります。「前工程が遅れたときに休日残業対応で乗りきったせいで、品質が悪化し後工程が遅れに遅れてしまった。あのとき、きちんと真因を分析して問題に向き合っていれば、その時は時間がかかっても、トータルで見れば安くついた」なんてプロジェクトはいくつも見てきました。

あと「前工程の遅れは後工程を圧縮して取り戻します」とかいう人もいますよね。個人的な経験では、前工程が遅れたらたいてい後工程も遅れます。前工程が遅れた場合「納期は延びたけど品質は当初予定通りのものができた」ということはまずなくて、成果物の品質が下がっています。そのため後工程もその品質の悪さのあおりを食らうことが多く、後工程で挽回なんてのは夢のまた夢。何が何でも納期=Deliveryを守りたいなら、人員=Costを増やすか、品質=Qualityを下げるかをしないといけないというのは、基本情報処理試験でも勉強するレベルのことだと思うのですが…。