プロジェクトの完了を定義せよ-デスマーチにしないために
打ち上げパーティーの日がプロジェクトの完了日でしょ！
今回は以前のコラム（※1）で紹介した「プロジェクトマネージャーが知るべき97のこと」をネタに勉強会の話の続編。
「プロジェクトマネージャが知るべき97のこと」という、プロジェクトマネージャー達の持論を集めた書籍がある。この持論について講師役がしゃべりみんなで討論する、という勉強会だ。1回で2人の講師役がそれぞれ選んだ持論について話をする、という構成。
■「完了」をどう定義するか
成功の明白な定義がなければソフト開発が成功するのは困難だ。アジャイル開発では目先のイテレーションを終了することだけを考えてしまって、全体の「完了」に必要なことを忘れてしまうことがある。プロジェクトマネージャは全体的な完了の定義を理解し、広めなくてはいけない。
というのが今回話題にする持論の要旨。
■完了っていつだ？
本の持論の要旨の説明のあと、参加者での議論となった。
そもそもIT開発プロジェクトの完了っていつ？ 納品時でしょ。いやいや、それは形式的な完了であって、システムのカットオーバーが完了だ。でも、カットオーバー後も初期トラブルでバタバタするから、落ち着いたあとじゃないの。打ち上げパーティの日が完了日でしょ。でも、納品後に残るメンバーは全員じゃないから全員の完了の意識はやっぱり納品日かな。
などと、ここに集まった人たちの間でもプロジェクトの完了の定義はバラバラだ。建築業界の人の話だと、家を建て終わって鍵を依頼主にわたすときが完了だとしっかり決まっている。それに対してIT開発の完了はなんと曖昧なことか。だからいつまでも終わらないプロジェクトやデスマーチになるのかもしれない。
■小さなタスクでも完了の定義は大切
プロジェクトの完了が曖昧でデスマーチになったとまではいかなくても、日々のタスクで似たようなことがないだろうか。
部下に、「今日中にこれをやっといてね」と頼む。夕方になって、「できました。お先に失礼します」。手が空いてから確認してみると、まだ途中で全然完了していない。ここまでじゃなくって、その先までやっておいて欲しかったのに。
タスクを依頼する側とされる側の「完了」の定義が違うとこんなことになる。小さなタスクでも大きなプロジェクトと同様に「完了」を定義して認識を合わせておくことは大切だ。
■第3回の勉強会は8月30日開催
こんな感じのことを話し合ったまったりとした勉強会だった。ちゃんとした結論が出るわけではない。技術セミナーと違って、参加して何かが得られるかどうかは分からない。でもいろんな人の意見を聞いてとにかく考えてみる勉強会というのも面白い。
この「プロジェクトマネージャーが知るべき97のこと」をネタに勉強会 の第3回目は8月30日（金）に東京で開催される（＊2）。無料だし、興味のある人は参加してみてはどうだろうか。
えっ、毎年その日は子供の夏休みの宿題を手伝うから忙しいって？ 夏休みの宿題計画の完了日をちゃんと定義しておけばよかったのに(^_^;)。
abekkanでした。
（＊1）10kgの米袋には米は何粒？-勉強会を盛り上げるには
（＊2）第3回目の勉強会の詳細と申し込みはこちら