「アート・オブ・プロジェクトマネジメント」読書感想文(その10)
PMのミッションは、プロジェクトを完遂させることだ←アタリマエなことなのだが、そのために何をしなければならないか、という話題になると多様な方法論に割れる。ここでは、本書から学んだものごとを成し遂げるための2つの方法を考察する。
■ものごとを成し遂げる方法1 ―― どのように、成し遂げるのか?
優先順位付けによってものごとが成し遂げられる。
プロジェクトマネジメントで最も忌避すべきことは、誤った作業にリソースを費やすこと。プロジェクトの目標や、作業の優先順位が混乱すると、進捗に遅れが生じ、最重要なリソース、すなわち時間が無駄に費やされることになる。いま、何をしなければいけないか、「その作業の重要度」について全員が同じ認識をもっていないと成功はおぼつかない。
では、この「重要度」は何によって決定されるのか? その作業に「重要」とラベルを貼っただけでは何の意味も無い。怒り狂った顧客のキメ台詞「全てが最優先!」がいかに愚かしいか知っているならば、説明するまでもないだろう。
なぜ「重要」なのか、という疑問に答えるとき、「この問題の解決の方が、○○の解決よりも重要」という言い方になる。つまり、重要度は相対的なものになる。だから、「何のもまして重要」なものは1つしかないし、「最重要課題」の数も1。
この重要度を見極めて優先順位づけすることが、PMの仕事の本質といってもいい。PMの重要な仕事と言われている「コミュニケーション」は、このリストを作成するためにある。何を優先させ、何を優先させないかを決めるのだ。
ほとんどのプロジェクトにとって、次の3つの順序付き一覧表こそが重要だろう。それぞれ順にブレークダウンされているはずだ。この他に、バグ一覧、要求一覧はあれど、以下のどれかに落とされて始めて、プロジェクトが回ることになる。この一覧表を優先順位づけることで、ものごとは成し遂げられる。
- 目標の一覧表
- 機能の一覧表
- 作業項目の一覧表
優先順位のおかげで、作業すべき項目や議論の焦点から副次的なパラメータが取り除かれる。どんなに議論が紛糾したとしても、収束させるために集中するべき焦点を絞りこむことが可能となる。煮詰まった議論をリフレッシュするために効果的な質問があるので引用する。
- 私たちが解決しようとしている問題は何か?
- 複数の問題がある場合、どれが最も重要なのか?
- この問題は私たちの目標とどう関係しており、どのように影響するのか?
- 目標に見合うようにこの問題を解決する最もシンプルな方法は何か?
PMは優先順位付けマシンとなるべし、と著者は断言する。プログラマやテスタと対話し、彼らが抱える懸案について耳を傾け、副次的な要素を取り除き、彼らが作業しなければならないことに集中させよという。メンバーが自分の重要な作業に集中させることこそが、PMの存在価値なのだから、そのために優先順位付けマシンとなるべし、というわけ。
■ものごとを成し遂げる方法2 ―― いつ、成し遂げられるのか?
あなたが「ノー」と言う時に、ものごとが成し遂げられる。
わたしにとって、ここからは未踏領域。わたしが「ノー」と言うたびに、「ノーという理由を教えろ」というツッコミが入り、あとはナゼナゼ論法で論破される… んで、「イエス」と言ったほうが話が早いので、その場は「イエス」で言いぬけて、あとは体力気力魚心水心でやってきた(イエスの奴隷やね)。
しかし、著者によると、「あなたが「ノー」と言わなければ、優先順位は決定できないのです。(中略)あなたが「ノー」と言えなければプロジェクトをマネジメントすることはできないのです」。するべきことと、やった方がよいことを分け、どのリスクをテイクする(負う)のか決めて、誰がそれを引き受けるのかを判断(指示)する。全て「ノー」というべき瞬間が待っている。何かを優先してする、ということは、それ以外のものをやらないでおくことと等しい。本書には、「ノー」の言い方まで紹介されている。
- 「ノー、それは我々の優先順位に合致していません」
- 「ノー、時間ができた場合にのみ行います」
- 「ノー、あなたが<不可能なことをここに入れてください>を行ってください」
- 「ノー、次のリリースで考えます」
- 「ノー、絶対ダメです」
1と2は使うことがあるが、それは優先順位表ができたからこそいえる「ノー」。3つ目の「ノー」は、厳しいツッコミ(というか罵詈雑言)を浴びせられ、「もういいです、わたしがやります」に変わること多し。最後の理由無し「ノー」は言えない…
本書のかなりの部分までは、自分の経験に照らし合わせて強くうなづくことができる。「気づき」よりも「確かめ」に近い。しかし、マネジメントの部(12~16章)になると、、これから場数を踏むことになる(?)状況が混ざっている。本書の後半はくり返しひも解くことになるだろう。
「読書感想文」シリーズはここまで。本書から得た「宝」を自分の経験と照らし合わせ、まとまりのないまま書いた。本書が単なるTips 集でないことは、あらためて言うことでもないだろう。ノウハウ集でもないはずだ。システム開発の現場で考え抜かれた「宝」が沢山埋まっている。だから、もっと志の高い人が読むならば、さらに得るものがあるだろう。
| 固定リンク
コメント
Babylon C@fe.からたどり着きました。
アートオブプロジェクトマネジメントかなり興味がわきました。
amazonから送られてくるのを楽しみに待っています。
私は、他業界の人間ですが(建築)、
アーキテクチャという言葉に代表されるように建築設計とwebのノウハウって意外と関連付けされてるものが多い気がします。
投稿: ノーミィ | 2006.11.09 22:35
>> ノーミィ さん
IT を特別扱いしている人間は確かにいます。特に太平洋を隔てた反対側の人が影響力を持っていますが、モノ作りの根っこのところで一緒という事実に気づくのには、ずいぶん時間がかかるでしょうね…
アーキテクチャは、建築であれWEBであれ、メタな意味で「アーキテクチャー」だと思っています。
投稿: Dain | 2006.11.10 01:40