完成度10％でまず全体を
概要
とあるプロジェクトのPjMを任されることになった私が盛大にやらかした話。
３行で要約すると
- 先にやるべき仕事を後回しにして、
- 後でやればいい仕事に最初から時間をかけすぎた結果、
- 手戻りが発生したときの時間ロスが大きくなり、納期に間に合わなかった
何をやらかしたのか
この辺に近い話。
アルバイトスタッフに生産性向上のコツを伝授した pic.twitter.com/oi9cs88veo
— ゆずたそ (@yuzutas0) September 5, 2021
とある分析案件にて、「データ前処理→データ変換→データマート作成→ダッシュボード作成」という一連の流れを実施するプロジェクトのPjMを担当した。
結論から言うと、（ダッシュボードもまだ作ってないのに）データ前処理に時間をかけすぎた訳である。
ダッシュボードの内容は手戻りが発生し得ることは当然予想できた。（Project Ownerが受け入れ条件を持っている）で、そんなこんなしてる内にテスト用のダッシュボード作成期限を超えてしまい、「いやまだそこ詰めなくていいから！」ってお叱りを受けたという話。
なぜやらかしたのか
実は、プロジェクトのプランニング段階でPOも含んでキックオフを行い、「まずはテストダッシュボードを形作ってその後に細かいところを詰めていこう」という話はしていたし、自分自身もそれは理解していたつもりだ。ではなぜこんな結果になったのだろう？
Done is better than perfect の精神が足りてなかった
Mark Zukerberg 氏の有名な言葉だ。
シンプルにこの辺の意識が足りなかったとは自分でも思う。本投稿のタイトルに書いた言葉は、POに指導いただいたときに言われた言葉である。まずは短時間で完成度10%とか20%で全体を作ってみて、その後に詳細を詰めて、だんだん全体を100%にしていく。
自分にとって、この考え方はなんら新しいものではない。だが、できなかった。知っていることとやれることは別なんだなとつくづく思ったが、もう少し考えを巡らせる必要があるとも感じた。
テストダッシュボードの定義が曖昧だった
振り返り時にメンバーが「テストとはいえ、どこまで作り込めばいいのかが分からなかった」と意見をくれた。実は、今回の失敗の本質はここにあると感じている。「一旦テストでいいので全体をつくる」と計画したときに、大事なのは
そうしなければ、完了条件やスコープがはっきりせず、不安を感じるままに「ここはもう少しこうしておいたほうがいいんじゃないかな？」といった意識が働き、無尽蔵に時間を使ってしまうからだ。（これは個人差があるかもしれない。筆者はかなり心配性なのでこの感が強い）
後回しでいいタスクと先にやらないといけないタスクの認識スキルが不足していた
この面も大いにある。シンプルなプロジェクトマネジメントスキル不足である。
知り合いのPMの方にいただいた以下のアドバイスがとても響いた。
「難しいものや実現方法に目処が立っていないものを後回しにするのはリスクが高い。時間さえかければできるものは後回しにしても致命的なリスクにはならない。」
また、上記に似たフィードバックをPOからももらった。一回やらかしたあとのMTGで次週のプランを説明したときに「一番リスクがあるのはどの工程ですか？」と聞かれて、なるほど！となった。
これまでは、単純にタスク同士の依存関係からクリティカルパスを出す観点しかなかったが、優先順位の決め方の観点の一つとして、今後考慮していこうと思う。
おわりに
今回この失敗で若干落ち込んでいたときに以前から積ん読していた『The Goal』という名著を手にとった。何かプロジェクトに関する話はないかと手元の本を漁っていたときに偶然目にしただけなのだが。
ここで出てきた 「スループット、業務経費、在庫」という考え方はとても参考になった。
「今回は、スループットを高めようという意思が足りなかったとも言えるな…」なんて考えながら本を楽しんだ。
