初心者PMのあるある９選 - 室長のひとりごち

自分が初めてプロマネをやってくれと言われて入ったプロジェクトは実は途中からで、それまではSEリーダと担当エンジニア二人のチームだった。SEリーダはプレイングマネージャが嫌だったこととそれなりに作業ボリュームがあったらしく、お鉢が回ってきた。適用技術は畑違いだったが、走りながら勉強する他なかった。

結果的には、若干コストが増えたがそんなものじゃないかと当時は思っていたが、今思えば大らかにプロジェクトコストをマネジメントしていたのではないかと思うと余計な汗をかきそうだ。

次のプロジェクトは綺麗な状態で始められたので、実質、そのプロジェクトが初めてのプロジェクトといっていいかもしれない。そんな初めてのPMでの初心者アルアル。

必要な要員を確保できない

アーキテクトというか今風に言えばテックリード役のメンバが丁度並行して始まったこともあり、兼務となった。代替策もなく、受け入れる他なかったわけだが。

その他のメンバもかなり怪しい状況で、なんとか始められたというか初めてしまったのは背筋がゾッとする。

提案仕様で曖昧なところがある

割と定量的なキャップを掛けた提案だったが、提案書を読み込むと「はてな、どういうこと」というところがあって。提案チームや担当営業に尋ねても誰も答えられない。

WBSがいまいち

今思えば、WBSの分解レベルがいまいち。経験不足はこうしたところに出る。

メンバが口を開けて作業指示を待っている

やっぱりWBSを作るときとか、作業展開とかをやるチームのメンバで展開しないと自分たちがやるんだという意識は持ってもらえない。だから、手すきになっても自分たちからあれこれしようと考えてくれない。

違和感を見逃す

ある仕様があって、相談されたときにやらない対応をしたのだがあとで問題になった。ああいった違和感は対応しておくか、識者に相談してリスクを評価しなければ。

客にいい顔してしまう

開発チームのバッファを使い切りそうになってまで顧客担当の仕事を待ってしまったことがある。あれは非常によくない。チームのリスクを考えてのバッファだったじゃないか。バッファを使う相手を間違っていたのだ。

進捗が遅れる

先のアーキテクトの担当に難易度の高いテーマを積み上げれば、それは進捗は遅れる。

WIPの大切さを実感する

当時はWIPなんて知らなかったが、担当エンジニアは一人しかいないのだから、アーキテクトにいくら作業を積んでもできるのは1つだけだ。当然、積んだタスクを他のメンバに渡すことになる。

テストでメンバが泣きを入れる

できることを手伝うからと、いって実際作業を分担して乗り越える。

プロジェクトとしては計画日にリリース出来たし、コストは計画内だったし、品質も安定していたので成功プロジェクトだったが、ヒヤヒヤものだったのは間違いない。