「反省会」記事はこちら
お仕事プロジェクト反省会【2022年9月~2023年1月】（その1）
お仕事プロジェクト反省会【2022年9月~2023年1月】（その2）
この中でこんなことを書いていました。
プロジェクトマネージャが未熟
お仕事プロジェクト反省会【2022年9月~2023年1月】（その1） – NOBODY:PLACE
メンバーのスキルを正しく見積もれずチーム編成に失敗
一応元技術者のはずだがエンドクライアントとの会議とWBS作成に忙しくてプロダクトを一切見ていない
動作環境を作らずソースコードを読まずstagingも触らないので受けた報告を理解出来ない。ゆえにタスクが遅延しているメンバーに突っ込めないしフォローも出来ない
うーんこれなー。
具体的にどこが間違いかというと「PMがプロダクトを一切見ていない」「動作環境を作らずソースコードを読まずstagingも触らない」という部分。
プロジェクトマネージャーの職責的に見て
職責として仮にプロジェクトマネージャーが開発ベースのプロダクトを一切見ていなかったとしてもそれは問題ないですよね。開発中のプロダクトのクオリティに責任を持つのはチームリーダーやメンバーであって、プロジェクトマネージャーがその中身にまで踏み込むべきではありません。そりゃそうだ。やること他にたくさんあるんだし。ただ僕らチームメンバーがなぜこの不満を感じていたかというとそこには背景があって「開発中のものは本当にきちんと動くのか」というような質問を毎日繰り返しされたせいです。「エンドクライアントがこの機能はこういう実装になっているのかと聞いている」みたいな質問も。それに対し担当メンバーが説明はするんですけど、実物動かさずに説明だけあってもなかなかわからないんですよね。開発中のプロダクトを動かすstaging環境は最後まで用意されなかったからなあ……（大問題）。
せめてなんらかのドキュメントやチケットの説明文が付随していればもう少しは理解に役立ったと思うんですが、それもない。チケット管理についてプロジェクトマネージャーから何かリクエストがあった記憶は無いし、僕以外のメンバーはステータスしか触ってなかったし、そういう「どうやって上手く行くようにするか」を整備する部分はプロジェクトマネージャーの仕事でしょう。最初はそういうこともいろいろ提案していたんですけど、この状態で毎日ミーティングをやられて疲れてしまって、中盤以降は放置してました。不毛だ。
僕の感想は間違いでした、でも
というわけで、もっとプロダクトにコミットしてくれという僕の感想は間違いでした。訂正します。プロジェクトマネージャーにはその必要はありません。ただそういう不満がチームメンバーから出るぐらい、プロジェクトのハンドリングが甘かったってことだよなあという感想は変わりません。ハンドリング出来ていないときに、じゃあどんな仕組みがあればハンドリングしていけるのか、プロジェクトマネージャーにはそれを考えてほしい。エンドクライアントが納得しないなら納得させる方法を考えてほしい。
インフラ周りはエンドクライアントが用意するっていってたのに、リポジトリ作成に2ヶ月掛かった上にstaging環境構築には5ヶ月以上（離脱時にも未構築）掛かっている時点で、成果物のクオリティを（常識的な方法で）エンドクライアントと共有するのは難しいよなあ。そういう意味ではプロジェクトマネージャーも気の毒ではありましたけど、そこをなんとか交渉するのもプロジェクトマネージャーの仕事なんですよねえ。簡単に「はい」って言って帰ってこないでほしい。エンジニアを同席させてエンジニアに説明させて交渉もさせるとか勘弁してほしい。
エンジニア側から見たプロジェクトマネージャーの仕事はエンジニアがタスクに集中出来る環境を作るってことなんですね。振り返ってみてそのことがよくわかりました。今のプロジェクトのプロジェクトマネージャーはその辺きめ細かいからなあ。正直言うと時々鬱陶しく感じますけど、エンジニアがそう感じるぐらいがちょうど良いんだろうなとも感じます。自由にやらせたら収集付かなくなるの、容易に想像出来るので。
さて、リリースのお知らせを見る日が来るのかなー。リリースされたら見物に行きたいと思ってるんですけどね。まだかなー
