猫型エンジニアのブログ

プログラム/ネットワーク系の技術関連をまとめたページです 

プロジェクト管理 その2 

初めてのPLとしての業務の終わりが見えてきたので、今後にその経験を生かすためのメモ。

スケジュール管理の大変さ

 PLということはプロジェクトの進捗管理をする「責任者」という立場。この責任者は具体的には、対上司・対顧客・対チームメンバーとの3者が対象となる。

対上司

 注意しなくてはいけないのは、上司も必ずしも自分の味方とは限らない点である。上司は上司で「このプロジェクトはスケジュールと予算は厳しいが、来季に継続受注が見込める可能性があるため、あえて受注した。」などのように、部下に無茶を承知で仕事を割り振るケースもある。

 こうしたケースでは自己防衛するしかない。「予算・人員・スケジュール的な観点から、定量的に無理」ということを伝えておくこと。上司のイエスマンになってはだめで、ときには喧嘩も必要。特に「定量的」ということがポイントで、ただ「スケジュール的に厳しいです」だけだと、「⚪︎⚪︎の機能を××すればできる」等の水掛け論になって議論にならない。

対顧客

 顧客は顧客で「結合試験もこのスケジュールに入れられませんか?」「この機能も実装できませんか?」等々できるだけ詰め込もうとする。「無理なのものは無理」と伝えるのが必要。ここも上と同じくときには喧嘩が必要。

 それでも要求がきたら、「⚪︎⚪︎に関する機能だと実装に2週間はかかりそうです。その分別の機能を削ることになりますが、いかがしましょうか?」のように「定量的な数値を上げた上で複数の選択肢を与えて優先度をつけてもらう」のが肝要。そうでないとできる・できないが延々と続いて話がいつになっても進まない。

ここの定量的な見積もりの根拠は厳しすぎても甘すぎてもダメなので、慎重に慎重を重ねること。「だいたいトラブルがないと必要となる期間の2倍」くらいが個人的な経験則。

対チームメンバ

 チームメンバの進捗はちょくちょく見回りに行く必要がある。

  • 今回の開発では対象外のロジックを実装しようとしている...
  • 打ち合わせで範囲担当外となった機能を調査している...

などなど定期的に見回りしないど、無駄稼働となることが多い。

大切なこと

 事前に準備不十分だった項目・検証手順でやはり詰まった。結局事前準備の段階で、すでにプロジェクトの成否は8割がた決まっていると思う。

  • 検証用のマシンがなくて進まない
  • 検証環境の構築に思った以上の準備がかかる

などのショボい原因からプロジェクトの遅れが生じることも多い。

とにかく「検証項目・検証環境の構築・メンバの手配」など全てを早め早めに手を打つのが一番

感想

 自分も1機能担当したけど、進捗維持との平行は無理だった。トラブル・課題管理・打ち合わせ等を考慮すると、進捗管理進捗管理に専念すべき

 しかし進捗管理なんて技術者としてはどうかと思う、正直...。