前職ではPGとして働いていたのですが、
上司がなんちゃってPMでした。
大雑把な指示と判子の捺印、口頭で進捗を把握できていれば良いという人でした。
結局、見積もりからスケジュール管理、お客様とのMTGでの要件定義、進捗報告まで、
実質的に私がPMとして動いていました。
今回は、そのなんちゃってPMの下で働いて感じた「予算ありきの受注」の弊害と、そこから学んだことをまとめます。
予算ありきの受注がもたらす弊害
プロジェクトを失敗したわけではないですが、
お客様の予算ありきで仕事を取ってきて、受注するため予算の範囲で納めることを要求してきます。
大抵の場合、予算が少ないため要件定義ではいかに工数を減らすかの提案がメインとなり、
お客様の課題解決のヒアリングより何が不要かが議題に上がります。
そして、パツパツのスケジュールになるため予備日や仕様変更にかかる工数がないです。
それでも良い顔するためエンジニアが残業などをして時間を作るしかないのです。
予算超過が起きない「からくり」
実はこのプロジェクト、予算超過は一度もありませんでした。
エンジニアは裁量労働制で働いており、さらにタイムカードは労務側で調整されていたため、
残業をしても数字の上ではコストが増えない仕組みになっていたのです。
PMからすれば「期日までに収まれば予算はかからない」という考えなので、
残業を強いることに何のためらいもありません。
コストを管理していないというより、コストが可視化されない仕組みを都合よく利用していた、というのが正確なところです。
こういう働き方を続けていると、私自身もそうでしたが、
メンバーの離職につながったり、状況によっては納期遅れが起きたりします。
予算ありきで受注(見積もり)を取るのは止めましょう。
お客様の予算は参考程度として、必要に応じて予算では収められないことも、ちゃんと伝えて課題を解決することを最優先に、見積もりまたは代替案を提案することがPMとして必要なことだと思います。
なんちゃってPMの下で働いて学んだこと
振り返ると、このなんちゃってPMから学んだことは3つあります。
1つ目は、予算だけを軸にした受注は要件定義の質を落とすということです。
「いくらでできるか」が先に決まっていると、「何が課題か」を聞く前に「何を削るか」の話になります。
これでは本来お客様が解決したかった課題が中途半端にしか解決されません。
2つ目は、コストが可視化されない仕組みほど、しわ寄せは現場に来るということです。
裁量労働制やタイムカードの調整によって、残業は数字の上では「なかったこと」になっていました。
数字に出ないコストは誰かが払っています。それはエンジニアの時間であり、いずれは離職という形で会社に返ってきます。
3つ目は、口頭とハンコだけのマネジメントには限界があるということです。
感覚や経験則だけに頼ったPM業務は、属人化しやすく、再現性がありません。
だからこそ、なんとなくで乗り切るのではなく、体系立てて学ぶ必要があると感じました。
体系的に学ぶために読んだ本
当時は、なんとなくPMの真似事をしながらネットで情報を調べる、という独学に近いやり方で乗り切っていました。
ただ、それでは同じ失敗を繰り返しかねないと感じ、プロジェクトマネジメントの本を読んで体系的に学び直すことにしました。
こちらの本は先日Kindleで半額キャンペーンで購入したのですが
非常に分かりやすかったです。
iPadでもKindle Paperwhiteでも綺麗にレイアウトされるのでどちらでもちゃんと読めました。
ITの分野でのプロジェクトマネジメントに書かれているので理解しやすいです。
ただし、一般的なプロジェクトマネジメントの話になるので要件定義以降の基本設計のやり方などの技術的な部分は書かれていないので、技術的な部分は別の本でカバーが必要です。
コメント