目次
どうマネジメントすれば良かったのか（続き）
どうすればプロジェクトは迷走しなかったのか？という反省会の続き。3. 毎日の定例ミーティングは行わない代わりに、スクラム開発の中のプランニングとレビューを採用する
なぜだか知りませんが「毎日夕方にミーティングをやって進捗報告をする」というのがこの会社の習わしでした。まあそういう習慣があってもいいでしょう、否定はしません。でも今回のようなプロジェクトの場合、日次で報告しても進捗が曖昧で……それは個人のスキルとかプロジェクトのマネジメントがあれとかいろいろと問題はあるんですけど、一番大事なことは目標をきちんと設定することだったと思うんですよね。時間も無いので。4. プランニングでは期日と作業量を明確にする
プランニングで今週絶対にやることを定める、レビューでそれがちゃんとできたかとマージ出来るかを検証する。ダメならなぜダメだったかを検証する。当然プランニングとレビューの間でスタックが生じることもあると思うのですけど、そこはSlackなどで随時解決していく空気感を醸成することでより素早く解決していくように出来るし、少なくとも「Ajaxってなんだ・・？」と3日間学習に費やすなんてことは無くなります。5. レビューでは「何をしたか」の報告ではなく、自分が開発した部分の解説を行ってチーム内で知識を共有することを主目的とする
もう1つ日次の報告で無駄だったなと思うのは、「何をしたか」の報告だけを行っていたこと。個々人が今日何をしたかという報告はPMが知りたいことであってチームメンバーにとってはどうでも良いことなんですよね。大事なことはメンバーが何をしていたかを知ることではなくて、メンバーが新たに付け加えたことについて共有してシステムに対する知識をアップデートしておくことだと思うんですよ。今日リリースした機能こんな感じで、こんな感じで使ってください、次はこんな感じで実装して行く方針です、その過程でこんな機能見つけたんでこれ使えないですか、今これ課題なんですけどなんかアイディアありますか。
6. 「何をしたか」の報告はSlack上で報告があれば十分
そういう建設的なミーティングこそが必要で、ただの進捗報告なんかテキストでやっとけや！！エンドクライアントが二重三重に進捗報告を求めてくる企業で、口を開けば「このチケットのステータスどうなってますか」「今進捗どうなってますか」「皆さんの稼働状況は」しか言わないやつらで、そもそもエンドクライアントの情報提供が遅すぎてプロジェクトが進まないわけで、そんなのに時間使ってミーティング開いて報告作る必要なんて無いんですよ。
5ヶ月間で80時間は全体ミーティングしてました。チームメンバーは最大10人、800時間を無駄に使いましたね。それだけあればどれだけ実装出来たことか。その時間を効率的なレビューに回せたらどれだけの手戻りが防げたか。ミーティング自体が不要とまでは言いませんけど、その必要性を考えないPMはほんとダメだと思いました。たぶん何も考えてないんでしょうね。
まとめ
ダメなプロジェクト過ぎました。エンドクライアントはもうちょっと頑張って欲しいレベルでしたけどPMまでもスキルが水準を満たしていないとは思わなかったです。そりゃ上手く進まないよね。僕自身がマネジメント側に回ることはないしそんなのマジで勘弁して欲しいと思ってますけど（開発がやりたいからフリーランスやってんすよ）、PMがボトルネックだなというプロジェクトに当たったときにはなんらかの対策を取れるようには考えておこうと思いました。今回、PMには最初からかなり意見してたつもりだったんですけど、なかなか意見をくみ取ってもらえませんでした。自分が正しいと思ってたんかなあ。ダメ出しするだけじゃなく具体的にやり方を変えてしまうべきでした。
2月以降もPMはプロジェクトに残って残務を片付けるらしいので、頑張って欲しいですね。お疲れさまでした。
