この記事はリンクアンドモチベーションAdventCalendar2023の20日目です。
はじめに
リンクアンドモチベーションでモチベーションクラウドの開発をしているymk25です。
今年はプロジェクトマネジメントに挑戦させてもらっていました。
…はい、掲題のプロジェクトマネージャーは私です。
プロジェクトマネジメントで大切なことは、いかに早く不確実性を見つけ、対処できるように動くことだと考えてます。
それに対して「たぶん」は不確実性の塊です。
この記事では、私の経験をもとに「たぶん」に潜む本音と脱出する方法を共有しようと思います。
「たぶん」に潜む本音
「たぶん」と発していたあの時の私の心は、このようなものでした。
- スケジュール遅延しているけど、あとQAだけなら巻いて実施できるだろう
- タスク担当者も大丈夫って言ってるし、人の追加とかも不要だろうな
- このプロジェクト、関係者連携周りでこれまでも何度か遅延発生したけど、これ以上はもうないでしょう
- 正直早くプロジェクト終わらせたい、何も起こらないで終わってくれ〜〜
恐ろしいまでのだろう運転…希望的観測によってプロジェクトの進捗を判断しています。
しかし現実は遅延しているし、問題が起こる可能性も否定できないから不安に感じて「たぶん」という枕詞がついてしまう。
では、どうすれば「たぶん」を抜け出すことができるのでしょうか。
「たぶん」から脱出する5つのステップ
そもそも、プロジェクトマネージャーが進捗を把握できていない、希望的観測で判断している状況ってどんな時でしょうか？
私の場合は以下のようでした。
- ガントチャートを作成して進捗を管理していたが、タスクの粒度が荒く（実装: 3日、QA: 2日など）、担当者が今何をしていて、どこまで進んでいるのかよくわからない
- 自分も実装やプロジェクト外のタスクを持っていて、他タスクの進捗を細かに確認する余裕がないし、把握しておけない
- リリース日は決まっているが、実際にあとどれくらいの工数が必要で、現在のチームメンバーのリソースだけで達成できるかわからない
- リリースまでに複数の関係者への確認や承認が必要だが、漏れなく対応できているか不安
上記の状況に対して、5つのステップを踏んで解消しようと試みました。
1. 一旦、立ち止まる
チームでは毎週金曜日にKPTでプロジェクトの振り返り、翌週のプランニングをする時間を設けていましたが、「たぶん」で進んでいた私のプロジェクトはこれが機能していませんでした。
ある日、メンバーから「理想系のスケジュールを描いていないか？」と声があがるものの、理想と現実にどんな差分があるのか見えていないのでうまく回答できず、不穏な空気が流れます…
このままでは絶対良くないが、走り続けながらでうまく整理できる気がしない、、
そこで、メンバーや他チームマネージャの助言もあり、半日プロジェクトを止めて、残タスクとスケジュールの見直しを徹底的に行いました。
リリース日は決まっていたため「貴重な作業時間を削っていいのか…？」という不安もありましたが、チームメンバーと視界が揃ってリリースまでの道のりが明確になり、気持ち的にも前向きになれたため、立ち止まって良かったと思っています。
立ち止まって実施した具体的な内容と効果は次になります。
2. タスクを1日で完了できるサイズに細分化
まず、チームメンバーと一緒にガントチャート上の「実装: 3日」と書かれているふわっとしているタスクを細分化しました。
細分化の基準は1日=4時間で消化できるタスクと定義しています。
この作業によって、タスク内でのさらなるTODOが整理され、その過程で漏れていたタスクやもっと工数が必要だったということに気づき、より正確なスケジュールを見積もるのに役立ちました。
また、1日単位のタスクの遅延ならリカバリーしやすい点や、毎日タスク消化することが可能になるのでプロジェクトが進んでいる実感が得られてモチベーションにつながるなど、効果は大きいです。
3. 「失敗するとしたら何か？」からタスクを洗い出す
希望的観測スケジュールになっていないか、他にリリースまでに考慮が漏れている作業はないか、この不安を払拭するために「失敗するとしたら何か？」という観点からタスクの洗い出しを行いました。
以下は一例です。
失敗するとしたら…
関係者連携で漏れが発生し、顧客に十分な説明ができずクレーム発生
・必要な関係者と連携事項をマトリクス表で整理
QAで考慮できていない箇所からインシデント発生
・モンキーテストを追加実施
・過去のインシデントから追加QAしておくべき観点がないか確認
4. 実際の稼働状況からスケジュールを引く
毎日プロジェクトにフルコミットできるわけではありません。
プロジェクト外のタスクを持っていたり、開発部署全体でイベントがある日はほぼ開発が進まなくて終わる予定だったタスクが終わらない、という事象が発生します。
たぶんいけるだろうスケジュールをやめるため、実際に1日のうちどれくらいの時間をプロジェクトに割けるのかチームで確認・認識を揃え、稼働できる範囲内でスケジュールを引き直すようにしました。
これによって、その週の何のタスクが遅れそうで、誰か別の人がカバーできるのか、確認や調整がしやすくなりました。
5. 日々の進捗をモニタリングし、断言できる仕組みを作る
最後に、これまで出したタスクや稼働スケジュールをもとに、進捗が大丈夫なのかダメなのか日々モニタリングして断言できるようにする仕組みを作ります。
今回採用したのはバーンアップチャートで、毎日の朝会で進捗チェックするようにしました。
下記は当時のプロジェクトのものになります。
バーンアップチャートの詳細な説明は割愛しますが、
進捗を表しているのは水色線ですが、10/13~23間は赤線を下回っており、バッファを使っても予定していたタスクを消化できず遅延している状態です。何か対策を打たなければいけない状態であることが一目でわかり、「進捗ダメです」と断言できます。
進捗はダメですが、このダメであるか否かが一目で分かることが一番大切です。
ダメであれば何が原因なのか分析し、人員を追加するなり、リリースの延期を検討するなど早めの対策に動けます。
しかし、「たぶん」ではこの原因分析が出来ないため、いざ問題が発生してからしか手を打てず、手遅れになる可能性が高いです（そしてたぶんうまくいくでうまくいった経験はn年の開発人生でゼロです）
何よりも人は先の見えない状況に強いストレスを感じます。
プロジェクトマネージャーの仕事は不確実性を見つけ、チームで対処できるように動くこと
そのために誰よりも不安に向き合い、チームで不安と戦える仕組みを作っていきましょう。
さいごに
上記はあくまでも私が他チームのやり方などを参考に実践した一部を紹介したもので、どのプロジェクトでも使える手法ではないかもしれません。
しかし、「たぶん」と発した時、誰かの発言を聞いた時、それは不確実性を解消してプロジェクトの進捗を光のもとへ連れ出すチャンスです！
「たぶん」に潜む本音に耳を澄ませるため、まずは一旦、立ち止まってみてください。
そんな時に私のこの記事が少しでもお役に立てれば幸いです。