はじめに

前回の続き
https://qiita.com/abe_shiro/items/59781017b2f999f01e18

急遽プロジェクトマネージャー就任

バックエンドエンジニアだった筆者、プロジェクトマネージャーの休職や退職により、突然複数の案件のプロジェクトマネージャーとして担当することになった。

大規模プロジェクトの遅延と問題

引き継ぎがない中で担当した案件は、n億円規模の新規モバイルアプリ開発。
プロジェクトは遅延しており、メンバーは高稼働状態。
ルールや責任範囲が不明瞭で、開発範囲も不確定な問題が多数存在していた。

経験の振り返りと改善点の考察

PMとしての立ち回りを振り返り、どのように対応すればよかったか、改善点を考察していきます。

問題

開発とテストメンバー（プロパー＆パートナー）の入れ替わりが激しく、それぞれが認識しているルールが違いコミュニケーションエラーが生じている状態だった。
また、誰が判断をするかも明確ではない状態で、判断待ちのチケットがかなりの数溜まっていた。
私が案件に入った時点だとメンバーは、開発とテストを合わせて40人くらいの規模。
人の入れ替わりが激しく、マネジメント職の人だけでも下記のような変遷があった。

PM①(退職)→PM②(休職)→PM代理のエンジニアリーダー(退職)→私

解決方法

社会あるところに法ありなので、案件に入ってる人が守る共通認識のルールを作って運用する。
抜粋ですが、下記の内容をまとめたドキュメントを作成。

・エスカレーションプロセス
・意見やフィードバックの共有方法
・タスク管理と進捗報告のルール
・進捗報告の頻度とフォーマット
・チームワークと対人関係のルール
・チケットのワークフローと対応する人

作るところまではよくても運用をしなければ意味が無い。
ルール運用は監視してチェックする人が居ないとだんだん形骸化していくので、ルールが浸透するまでは逐一アナウンスしていました。
ある程度ルールが共通認識になってくると、チーム内に社会性が出てきて自発的な動きが出てくるようになった。

おわりに

炎上案件あるあるなのかもしれないが、炎上する一因としてコミュニケーション不足があると思った。
コミュニケーションを円滑にするにはルールが必要で、メンバーもあれやっていいのかな、誰に報告しないといけないのか悩んでしまい動きが遅くなる。
今回の件で思うのは、ルールは人数が多くなればなるほど必要。
案件に居るメンバーが5人くらいのプロジェクトなら、ガチガチのルールがなくてもその場その場で認識を合わせてやっていけるかもしれない。
ルールを作り案件全体で共通の認識を作る事で、トラブルを少なくして円滑に案件を進めることが出来る。
後は、ルールを形骸化させてないこと。