プロジェクトを成功させる魔法の言葉

　あいにく銀の弾丸の持ち合わせはないが、うまくいくプロジェクトでよく使われていた言葉は確かにある。耳にしたときは聞き流していてた言葉を、この本は思い出させてくれた。ここでは、そんな「魔法の言葉」を紹介する。

　ネタ元は「目標を突破する実践プロジェクトマネジメント」。ふつう、図書館で読んだ本はそれっきりだが、こいつは買って周りにばら撒く。薄くて分かりやすくて、すぐにやってみようという気にさせるところがいい。

* * *

■　もし、問題があるとすれば、それは何ですか?

　朝会や進捗会議で「何か問題はありませんか?」という質問はよくするしされる。けれども答えはいつも決まっている→「特にありません」。でもって、不具合が起きると、「あのとき聞いたのにッ」←→「こうなるとは思ってなかった」となる。

　身に覚えない?

　これを、冒頭の質問にしてみると、アラ不思議、いくらでも出てくる。「問題ない?」には無反応だったのが、「これから問題が起きるなら」、あるいは「いま気づいていない不具合があるなら」と言い換えると、様々な「問題」を教えてくれる。

　つまり、「問題ありませんか?」という質問の裏には「潜在リスクを洗い出してください」がある。いっぽうで、「特にありません」という答えの裏には、「顕在化している不都合な点はありません」がある。両者のギャップを埋めるのが、この質問というわけ。

　応用：「この対応をやったことで、別のリスクが発生するならば、それは何だろう? それはどうすれば"見える"ようになるだろう?」。デグレード要因の洗い出しの場では、必ずこの質問をするようにしている。

■　あと何日?

　これまた進捗会議で「進捗率90%です」とある。「そーか、ほとんど完了しているんだなー」と思ったら要注意。残り10%が全然進まないのよ。次回も次々回も90%のまま。「進捗率」は、「予算を消化した割合」なのか「書き上げた行数」なのか、人によってさまざまだったりする

　身に覚えない?

　これを、「あと何日?」で問い直す。スケジュールの予実の割合ではなく、その作業を終わらせるためにあと何日かかるか? と聞く。問うているのは、決して、スケジュール上の完了予定日マイナス消化日数ではない←これ超重要。

　すると、答えるほうはこうクるはずだ「○○さえなければ、あと○日です」、あるいは「△△が間に合えば、あと△日で終われます」ってね。

　作業開始の初日から完了まで、「あと何日」で管理する。経過した時間は1日だからといって、あと○日マイナス一日というわけではないことを、常に意識しながら進める。

　例えば、10日のタスクがある。開始5日の時点で「あと7日かかる」ことが分かれば、2日遅れることがこの時点で分かる。だから手を打たなければならない。あったりまえじゃん、と言うなかれ。進捗率ならこう報告するはずだ→「若干遅れ気味ですが、進捗率は50%です」ってね！

　　□□□□□□□□□□　　10日のタスク

　　■■■■■◇◇◇◇◇◇◇　開始5日目での進捗（■は消化済み、あと◇かかる）
　　　　　　　　　　　　　 　　　↑↑
　　　　　　　　　　　　　　ここを見るべし

　ここで見るべきは、消化済みの■ではない。進捗率50%と言いたくなるのは■に着目した場合だ。終わったものに目を向けるのではなく、完了までにどれぐらいかかるか? こそが本来管理されるべき対象。だから、■ではなく、◇に目を向ける、「あと何日?」という質問でねっ。「先手管理」はマネジメントの肝なんだが、具体的にはこの質問が相当するわけだ。

■　目的は何ですか?　成果物は何ですか?　成功基準は何ですか?

　プロジェクトが混乱する原因の最たるものは、たった一つ→「目標が明確でない」。雀の涙の予算や、二転三転する仕様、尻だけは決まっているスケジュール、どいつもこいつも要因になりうるが、最大は「結局何のためのプロジェクトかハッキリしないままスタートしちゃっている俺ガイル」だろ?「プロジェクトのゴール」や「目標」というとピンとこないかもしれないが、お題の質問に言い換えると座りが良いかも。

　目的：「最大の儲けの実現」「圧倒的なブランドの確立」「業界で注目を浴びる人材を育て上げる」など、みんながワクワクするような、（かつ実現可能性のある）目的―― 何のためにこのプロジェクトがあるのか―― を出し合う。

　成果物：その目的達成のために、具体的に何を作るのか? という問い。「システム一式」、「納品物一式」にしてしまわないで、ブレークダウンする。

　成功基準：前2つの議論の中で、「それは何を達成したら、『成功した！』と言えるのだろう?」と言い換える。具体的に数字や行動で測定できるものを定義する。「利益率40%」でもいいし「社長から『よっしゃ、よくやった』と誉められる」でもいい。

　この、目的（Objectives）、成果物（Deliverables）、成功基準（Success Criteria）の頭を取って、ODSCというそうな。プロジェクトをODSCでデザインする。メンバーで出し合って共有するところがポイント。

* * *

　ネタ元「目標を突破する実践プロジェクトマネジメント」はスゴ本。

　ゴールドラットの制約理論は「ゴール」読んだだけで知ったかぶっていた。あるいはクリティカル・チェーンは、PMBOK3で分かった気分になっていた…が、TOCを実践でどう適用していいのか分かっていなかった。本書はそいつを、徹底的に、肌感覚で分からせてくれる。しかも、『読んだらそのまま』使える仕掛けが施されている。

　「山積み・山崩し」の肝や、「遅れは伝播するくせに、進みは伝わらないひみつ」、あるいは「サバ取りの極意」（←これは読んだ今日使った）といった、いま、わたしが必要とするネタばかり。納期に間に合わせるために無意識のうちにサバを読んでしまう（丸めてしまう/下駄履かせてしまう/バッファ入れてしまう）心理が、いかにプロジェクトを圧迫しているかがよーく分かる（[ここ]にイラスト付きで紹介されている）。

　PMPとしてSI屋である自分の仕事を見るにつけ、かつて輝いてい見えた「開発手法」が色あせて見える。あ、ダメというつもりじゃないよ。開発手法に拘泥する、あるいは開発手法が成否を決めるといった発想から離れようとしている。RADだからよいとか、WaterFallだからダメといった議論が、過去のものになりつつある。

　つまり、「目標に向かって、いかにプロジェクトを運営していくか」という命題を達成するツールとして認識できるようになった。「コンピュータ・システム」を作るために、そのツールとして手法がある、というカンジが感覚として身についた。

　さらに、その上位にあるマネジメントの方法（の一つ）にTOCがあるのだなー、と理解できるようになった。山が開けた感じ。この感覚、PMBOK3読んだ人と共有したい。あるいは、これからPMの仕事する人にも伝えたい―― そういう一冊。

* * *

　以下自分用、P2Mをやってみるか。

　　日本TOC推進協議会 　　TOC-CCPM情報サイト