« Wikiでプロジェクトマネジメントする4つの方法 | トップページ | 「ナラタージュ」より「____の_」の方が良い »

「はじめてのプロジェクトマネジメント」はお買い得

良い本に出合えてうれしいので、報告。枕詞「入門」「やさしい」が付く本はハナから使えねェと思っていたが、「はじめてのプロジェクトマネジメント」は優れた一冊。ただし、下手な小説仕立ての小話がなければもっと良し。

PMの入門書をイチから書くと、どうしても底本(PMBOK)のダイジェストになる。ところが、これは「実用企業小説 プロジェクト・マネジメント」のエッセンス本なので、より実践的なツールが紹介されている。二番煎じという声もあるが、これだけのノウハウが880円なのはコストパフォーマンスが非常に良い。

また、このテの本にありがちなのが、エラそうに一席ぶっている筆者の経験の「狭さ」「浅さ」を垣間見て思わず微苦笑を招くこと。しかし、この著者は本物の(残虐非道プロジェクトを潜り抜けかつ生き残った)人だなぁ、と気の毒に思った。なぜなら彼のいうプロジェクト成功要素の一つに、「犠牲者を一人も出さないプロジェクト」が掲げられているから。また、反面教師の台詞「プロジェクトとはタコ壷であり骨壷でもある」は、けだし名言。文字通りお亡くなりになった方がいたんだろうなぁと忖度→黙祷したくなる。

特に使ってみたい方法はPRP。PRPとは Project Re-Plannning の略で、「プロジェクト再計画」のこと。即ち、プロジェクト開始前の制約条件に基づいて、プロジェクト計画をメンバー自身の手で組み立てることを指す。

一般に、PMであれメンバーであれ、プロジェクトに参加するときには、プロジェクト計画は「すでに決定されている」こととして与えられる。計画そのものが「前提条件」となるのだ。スケジュールやリソースは与件として与えられ、その変更は認められない。

そんな中、PMやメンバーができる最大限のことは「与えられた条件でいかに成功に近づけるか」であるにもかかわらず、成功/失敗の二択でしか評価されない。これって非道くねぇか? 営業や上層部がともするとテキトーに決めた「計画」が「制約」としてノシ歩き、自分がしたわけでもない「約束」に振り回されるのはもうゴメンという人は、p.68を読むといいかもー

p.68のPRP手法をまとめると、プロジェクト計画は2つ存在することになる。

  1.最初の受注レベルのプロジェクト計画
  2.プロジェクト開始前の制約条件に基づいた再計画(PRP)
  3.プロジェクト完了後の実績

1.営業や上層部が「約束」してくるプロジェクト計画のインプット情報は極めて限定的であるが故、「ざっくり」「エイヤっと」決めた計画[案]で、こいつを後生大事に実行フェーズに移すのは正気の沙汰とは思えない。

2.だからこそ、プロジェクト開始直前/直後で再度プランニングをする。するのはPMとメンバーだ。つまり、そのプロジェクトを推進する人が「これならできる」「これでしかできない」ものを作り上げるのだ。この本では詳細まで触れていないが、具体的にはWBS作成だろう。自分が携わるタスクを洗い出すことで、プロジェクトの全体像の見通しをつけ、メンバー間でスキルや個性を知ることもあるだろう。

3.完了後の実績は確定情報。1.や2.が天気予報ならこれは天気後報。実際にマイルストーンを通過した日や成果物の量・質を洗い出す。

で、「3と1」を比較し、「3と2」を比較するわけだ。
で、「3と1」の結果と、「3と2」の結果を比較するわけだ。

「最初のプロジェクト計画は絶対」「時 間 が な い」「メンバーだけの再計画は、ただのマスターベーションにすぎない」「そもそも1と2乖離しているはず。いつ誰がオーソライズするんだよ?」というツッコミはわたしもした。しかし、これこそPMの仕事。上層部とのネゴシエーションを通じ、1→2に近づける。1の「できない理由」と代案を提示し、改変を迫る。2の甘い部分を絞り込んで、1との親和性を高める。上層部は撥ねつけるかもしれないが、折にふれ粘り強く説得するしかない。
2の作業ポイントは、


  • どのように評価するかといった指標値も織り込んでおく
  • 基準値は目標値ではないため、右肩上がりに設定しない
  • ともすれば易きに流れがちな各人の議論は、最終的にPMの責任で(独断で)決める(「全員で議論→PMが独断」が王道)

成功するべくして成功する、これ最強。非現実的な計画を現実的なものに落とし込む。これこそプロジェクトマネジャーの仕事。他の使える手法をピックアップすると…

■プロジェクトの理念

そのプロジェクトでどうしたいのかを自分の言葉で(できれば下手でも自筆で)書いて貼っておく。多少こっ恥ずかしいが、メッセージを出さないよりも1000倍まし。「このプロジェクトでは一人の犠牲者も出さない」「このプロジェクトの全員に○○を身につけてもらう」など、成果物やマイルストーンに関係ないものが面白いかと

■プロジェクト計画フェーズの決め台詞

[問] リーダーの言っていることは分かりますが「みんなで話し合いながら決めていこう」といわれても前に進めません。「これをこうする」というように具体的に指示していただかないと

[答] あなたが言いたいことは分かるが、プロジェクトマネージャの私が全てを知っているわけじゃないんだ。むしろ、私は今のプロジェクトについてもメンバーの皆についても何も知らないに等しい。だから計画を立てることを通して知っていくしかないんです。これは私だけでなく、皆にも同様だと思う。

■問題解決のための臨時チームを作る

問題発見時の対応方法をルール化しておく(しないと全ての問題を故障処理票で管理することになる)。ポイントは「発見者≠対応者」にすること。期間限定、人数限定、特定された課題だけを解決する。全権を与えられる。若手を据えてとことんまでやらせるといい(ただしバックアップはちゃんと)。んで、解決の暁には「発表の場」を与えてきちんと活躍させる。

■オフサイトミーティング(p.88)

  • 「気楽にまじめな話をする」場
  • 主語は「私」(肩書きや役職でない)
  • 批判なし、人の話を聞く(ブレーンストーミング)
  • 分かり合うための場、メンバー全員の個性や能力を知るための場
  • 酒は入れないこと(その後に飲み会なら可)

■DPM(Decision & Progress Meeting)プロジェクト意思決定会議(p.94)

  • リーダー全員参加、欠席不可(代理可)「聞いていなかった」とは言わせないため
  • 議事は全て即断即決(するのはPM)
  • 議事録はアクション項目を登録、PMのメッセージを記入
  • 方法、計画をオーソライズ、問題解決、方向性の決定、進捗管理、作業項目のフォローアップ
  • 全員で議論、PMが独断

■問題提起を歓迎する(p.103)

  • 問題検出をルール化
  • 問題対策をルール化
  • ともすると故障処理票しか問題提起できない状況を打破するため
  • 問題を内在化させないため。これは特に組織が大きくなるときに効いてくる

■作業者が申告した内容で管理する(P.117)

  • PMが管理したいのは「今全体のどこ」「あとどれぐらいかかる」「それを阻害するのがあるか」「あればそれはどうオミットするのか」
  • 画面数で管理するのはおろか。実装方法(サーブレット、アプレット、HTML、DBアクセスありなし、参照テーブル数、コミットあるなし)で管理
  • 作業の進捗度合い(分子)ではなく、分母に着目。検討するべきことが出てくるのなら分母が変わってくる。だから順調なら分子を、問題を見つけるなら分母の増え具合を見る

すべては成功するべくして成功するために。

|

« Wikiでプロジェクトマネジメントする4つの方法 | トップページ | 「ナラタージュ」より「____の_」の方が良い »

コメント

この本は見逃してました。日経文庫のマーケティング上「はじめての」とついているようですが、著者の経験の深さに加え、業界が私に近く、リアル感あふれる内容でした。紹介感謝です。
読んでみると、Dainさんのまとめは単なるまとめでは無く、ご自身の言葉であるのにも感心しています。

プロジェクト的現実が、経営的現実に潰されず[生き残る]。ビジネス数値の冷徹に、いかにクールかつ熱く立ち向かうのか、しみじみと重さを感じます。

PRPは、差分を明確に見つめることで打開策を探るためにあります。1→2というだけでなく、2→1方向、メンバーの動機付けもPMの責務ですね。
プレッシャーがきついと、ひたすら体を使う方向に行きがち。皆の頭をどれだけ回せるか、そんな、コミュニケーションと動機づけのマネジメント手法を語った本と読みました。

とはいえ、差はいっこうに縮まらず、むしろ拡大していくもので、いやはや苦しいしんどい辛いものです。
でも、そこをチームみんなで突破し、チーム、顧客、上位マネジメントが満足出来る結果を出したときの達成感こそが、PMの醍醐味なのです。

投稿: 円山貫 | 2005.07.19 05:56

こんなに誉められるとくすぐったいような恥ずかしいような気持ちになります。読んでいただいてありがとうございます。この本からメンバーの動機付けまでくみ取れる円山貫さんの部下がうらやましいです。

わたし自身が味わったマネジメントの成功/失敗例をもっと開示したいのですが、どうしても守秘義務にかかってしまいます。そのため、こうした「本のレビュー」を介したやりかたでしかお伝えできないのが残念です。

ともすればOJTや慣習で相伝されそうなマネジメントの極意は、どんどん形に表わして共有化していきましょう。

投稿: Dain | 2005.07.20 00:58

コメントを書く



(ウェブ上には掲載しません)




トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/18285/4668305

この記事へのトラックバック一覧です: 「はじめてのプロジェクトマネジメント」はお買い得:

« Wikiでプロジェクトマネジメントする4つの方法 | トップページ | 「ナラタージュ」より「____の_」の方が良い »