アイキューブドシステムズで CLOMO や CLOMO MDM for Android のプロジェクトリーダー (PL) をしている id:oda-i3 です。こう書くとエラそうな印象をうけますが、2020 年 1 月に就任した新米リーダーです。
今回は私が PL に就任した半年間でプロジェクト運営で経験した失敗とそこから得た学びを挙げたいと思います。私の体験談が皆さんのプロジェクトマネージメントの一助となれば幸いです。
最初は一つの大きなプロジェクトだった
私が携わったリリースは以下になります。
- 2020.05.12. CLOMO PANEL 新バージョンリリースによる修正
- 2020.05.12. MDM Agent for Android 新バージョンリリースによる修正
- 2020.06.15. CLOMO PANEL 新バージョンリリースによる修正
ご覧の通り 3 プロダクトをリリースしていますが、当初は 2 プロダクトをリリースする 1 プロジェクトの予定でした。プロジェクト開始当初はこのプロジェクトで満たさなければいけない要件は分かっていたものの、実際にどの程度の規模になるのかは判明しておらず、お客様が要望されているサービスから先行してリリースしていく方針としました。
プロジェクトを分割してみたが…
“満たさなければならない要件に優先度を設け、優先度の高いサービスから着手していく”
弊社に限らずよくあるケースかと思いますが、よくあるケースにはよくある落とし穴がつきものです。
落とし穴その 1 ： 共有されない情報たち
プロジェクト発足時、キックオフミーティングでは通常以下のようなことが行われます。
- メンバー全員とプロジェクトが全体像を確認する
- メンバー全員とゴールを確認する
- メンバー全員の役割を明確にする
実際に行ったのは以下の内容でした。
- サーバー開発メンバーとプロジェクト全体像を確認する
- サーバー開発メンバーとゴールを確認する
先述した通り、当初は 2 プロダクト（サーバー開発とアプリ開発）をリリースする 1 プロジェクトでした。
しかし、アプリ開発メンバーが別プロジェクトの佳境だったため、この時は「キックオフミーティングで長時間拘束してしまうのは申し訳ないので、アプリ開発メンバーには別途、情報共有の場を設けよう」と考えていました。先にオチを書くと、アプリ開発メンバーはその後もずっと忙しい状況が続き、情報共有の場は設けられませんでした…。
また、「誰が」「いつまで」「何をするのか」という役割も不明瞭なままキックオフミーティングを終了させてしまいました。「いつかやる」のいつかが必ずくるとこの時は信じていたのです…。
そしてプロジェクトが始まった
開始前に問題を抱えているプロジェクトは果たして正常に運営できるのだろうか、いやできない（反語）。
落とし穴その 2 ： タスクを抱えすぎた PL
PL 就任当初、プロジェクト開始前から期日が設けられたタスクがありました。開発メンバーにはそのタスクに集中してもらうため、管理業務のほぼ全般を PL の私が一人で抱え込んでいました。
「このタスクは PL がやらねば。このタスクも PL がやらねば」と自らタスクを増やし、結果どのタスクもこなせなくなる状況に陥りました。期日が設けられたタスクの完了目処がついた辺りで開発メンバーから「次のタスクはどうなっているのか？」とつっつかれます。「すぐに準備するから」と回答したまま塩漬けの状況が続き、最終的に開発メンバーが勝手にタスクを取っていき矢継ぎ早にタスクを終わらせてくれました。
落とし穴その 3 ： 報告されないスケジュール遅延
タスクを抱えすぎ、プロジェクトが正常に運営されていない状態であるため、私自身がプロジェクト全体のタイムマネジメントをできていない状態になっていました。よって、最初に設定していたマイルストーンの期日が近づいているけども、
- タスクを予定通りこなせていない
- 工数も計画通り使えていない
- スケジュールだけが遅延している
という状況にあると認識していました。そしてマイルストーンの期日の数日後、改めてタスクを確認しなおしたところ
- タスクを予定通りこなせていない
- 工数を計画以上に使っている
- スケジュールは遅延している
という最悪の事態に陥っていました。この事実を上長に事後報告する時の虚しさは今でも忘れられません。
気を取り直して新プロジェクト始動だ！
「失敗続きのプロジェクトを終えたから、新プロジェクトでは失敗しないぞ！」
落とし穴その 4 ： PL の知らない稼働
〜キックオフミーティングにて〜
私 ： じゃあ、要件を確認して…
メンバー： はい
私 ： まずはこの要件の技術調査を…
メンバー： あ、もう終わってます
私 ： …はい？
メンバー： その要件の技術調査は終わっています
私 ： …なんで？
この開発メンバーは別ルートで情報が共有され、見積もっていない工数で稼働していました。開始早々に悲しい現実を目の当たりにし、謝罪ファーストで始動しました。
それでもプロジェクトは始まっていく
失敗が続いてもいつかはプロジェクトが終わり、そして新たなプロジェクトが始まるのです。同じ過ちを繰り返さないために「何がまずかったのか」をふりかえる必要があります。
巨人の肩の上に乗る
私はプロジェクトマネジメントについて資格を取得したりなど体系的な勉強をやった事がありません。今まで開発メンバーとして参加していたプロジェクトで「あの時リーダーはこんな事をしていたなぁ」という経験則からプロジェクトを運営しました。結果はここまでに書いている通り、惨憺たるものでした。
そこで社内の有識者にプロジェクト運営について勉強会を開催してもらいました。そこで私がやってきたプロジェクト運営と、いわゆる教科書通りのプロジェクト運営の違いを教えていただきました。
また、社内ツールにプロジェクトの進捗状況を可視化できる仕組みを共有してもらい、工数の予実管理をグラフ化して管理するようにしました。
やるべき事は手続き通りにやる
最初のプロジェクトでの失敗は、正常なプロジェクト運営とは言い難いものでした。
- キックオフミーティングっぽい事をやった → 全メンバーに情報は共有されていない
- 要件からタスクを割り出した → 以後、タスク管理はされていない
主にこの 2 つが要因となり、スケジュール遅延につながったと考えています。
プロジェクトの開始から終了までどのような手続きで進めていくのかを先に決めるべきでした。
実は弊社にはプロジェクトをどのように進めるべきかを定めたワークフローが設けられており、多くのプロジェクトはそのプロジェクトワークフローに従って運営されています。しかし、今回の失敗はこのワークフローから逸脱してしまっていたことが大きな要因でした。
「自分が今どのような状態にあるのか」を各メンバーに自覚させる
「このままだとスケジュールが遅延しそう」という情報を PL だけで検知するのは非常に困難であると考えています。そこでメンバーからもスケジュール遅延や工数超過になりそうな情報を共有してもらうことになります。
ある日とあるメンバーから「自分が使える工数を把握しにくいのでそのような情報共有が困難である」という相談を受けました。それまで朝会では作業の進捗状況のみを共有していましたが、作業の残工数も確認するようにしました。
この結果、各メンバー毎のデッドラインを朝会で共有でき、スケジュール遅延や工数超過が起きそうなことを事前に把握することができるようになりました。
まとめ
- 知らない／分からない事は素直に人から教えてもらう
- 情報共有は 5W1H を意識して、必要な人たちに確実に共有する
- データを可視化して根拠のある数値をもとにプロジェクトを管理する
過去の失敗をふりかえると「当たり前のことを当たり前にできていなかった」と感じます。また「当たり前のことを当たり前にやる」ということが簡単ではないということも個人的に学べました。
「俺はこんなにもできないのか」と思いましたが、「まだまだこれだけ伸びしろがある」と捉えて精進に努めています。
