「プロジェクトリーダーの教科書」を読んでみた～PMの「型」を学ぶ

AWS事業本部インテグレーション部のいわほりです。

いきなりですが、天才落語家立川談志師匠の名言の一つをご紹介します。

型ができてない者が芝居をすると型なしになる。メチャクチャだ。

型がしっかりした奴がオリジナリティを押し出せば型破りになれる。

若いころ同僚の先輩に 「突き抜けるほど優秀なPMのスキルは持って生まれたもので、勉強して得られるものじゃない」 と身も蓋もないことを言われたことがあります。

たしかに、強烈なリーダーシップを発揮する方を目の前にするとそう感じることもありますが、過去接してきた優秀なPMの方々はいずれも「型がしっかりした」方々だったようにも思えます。

っというわけで、「型破り」なPMを目指して、プロジェクトマネジメントの「型」に触れている本を読んでみました。

どんな本？

書名：外資系コンサルが教える難題を解決する12ステップ　プロジェクトリーダーの教科書

著者：中鉢 慎 氏

プロジェクトマネジメントのベストプラクティスであるPMBOKを基本としながらも、著者独自の見解と経験に基づいた実践的なプロジェクトマネジメントが書かれている本です。

苦戦中のプロジェクトに対する具体的な打ち手を見出したいプロジェクトマネージャーにおススメします。

目次

著者はプロジェクトマネジメントを「D3アプローチ」という独自の手法・型を使って整理しています。「D3」とは、「Define, Design, Drive」の３つの「D」からネーミングされたものですが、本書はこれに沿って章立てされています。

• 序章　本書でプロジェクトマネジメントを学ぶべき理由
• 第１章　定義フェーズ(Define)
  • Step１　最終目標
  • Step２　対象範囲
  • Step３　利害関係者
  • Step４　阻害要因
• 第２章　デザインフェーズ(Design)
  • Step５　資源見積り
  • Step６　体制構築
  • Step７　作業設計
  • Step８　規範設計
• 第３章　推進フェーズ(Drive)
  • Step９　変更管理
  • Step10　組織運営
  • Step11　問題解決
  • Step12　意思決定

以降、各章毎に見ていきます。

序章　本書でプロジェクトマネジメントを学ぶべき理由

なぜプロジェクトは失敗してしまうのか

プロジェクトの成功率をご存じでしょうか。 「プロジェクト」や「成功」の定義によって何通りも答えはありそうですが、日経コンピュータの調査結果では、52.8％(2018年)だそうです。

本書では、半分ものプロジェクトが失敗してしまうのは不確実性や想定外に起因する問題を適切に処理できていないからだ、としています。

PMBOKとD3アプローチの違い

２つのプロジェクトマネジメント手法の違いを以下のとおり、説明しています。

• PMBOK：精緻な「計画」と厳格な「管理」によって「不確実性」を最小化する。その結果としてプロジェクトが予定とおり進む
• D3アプローチ：「計画」と「管理」にとどまらず、「リーダーの行動原則」に従い行動することによってプロジェクトを推進させる

「計画を作って定期的に状況確認を行えば、プロジェクトは成功する」なんて思ってたら大間違いだぞ、というところでしょうか。

また、一番の違いとして、D3アプローチは、

いくら緻密な計画を立てて、厳密な管理をしても、プロジェクトでは問題は必ず発生する

ととらえているところ、としています。

つまり、問題は必ず発生するので「発生させないようにする」だけではなく「どう対処するか」にもフォーカスすべき、としています。

D3アプローチはプロジェクトにおける実践的な「型」を提供するものであり、これが本書でプロジェクトマネジメントを学ぶべき理由となります。

第１章　定義フェーズ(Define)

キーメッセージは「ゴールのないマラソンは走れない」です。 通常のプロジェクトにおける、立ち上げフェーズについて記載されています。

要点と失敗プロジェクトでありがちなことや個人的な感想を記載していきます。

Step1　最終目標

• (要点)プロジェクトメンバー全員が共感できる目標を設定する
  • (失敗プロジェクト)目標に共感できない関係者からの協力を得ることができない
  • (感想)PMが一人でできることには限界があります。難しいことですが、メンバー全員が納得できるメッセージを発信することが協力を得るためには重要と考えます
• (要点)目標は「SMART」に設定する
  • (失敗プロジェクト)Specific(具体的)、Measurable(測定可能)、Achievable(達成可能)、Result-oriented(結果志向)、Time-bound(時間内)な目標でない場合、成功や完了を判断できない
  • (感想)抽象的な目標は将来の揉め事の要因になります。信頼関係が構築できていない時期ではありますが、遠慮や忖度により曖昧にしてはならないところです
• (要点)大きな目標は細分化し、適切なマイルストンを設定する
  • (失敗プロジェクト)マイルストンの設定箇所が時間軸において偏っている
  • (失敗プロジェクト)マイルストンの達成状況に応じた適切な起動修正を行わない
  • (感想)傷は浅いうちに治さないと大ケガにつながります。浅い傷を定期的に確認し、それを放置しない仕組みと勇気が必要です

Step2　対象範囲

• (要点)やらないこと(スコープアウト)を明文化する／「何でもやる」は「何もやらない」と同じ
  • (失敗プロジェクト)「やる・やらない」が記載されていないことが、いつの間にか「やること」になり、プロジェクトが崩壊する
  • (感想)繰り返しになりますが、遠慮や忖度により曖昧にしてはいけない部分です。人と人、チームとチームの間に落ちる「谷間タスク」は致命的な失敗要因になりかねません
• (要点)成果物スコープを「SMART」に定義することにより、プロジェクトの真の狙いまで踏み込む
  • (失敗プロジェクト)プロジェクトに期待していた効果を得られない
  • (感想)システム開発サイドに立つと非常に難しいことですが、ビジネスにおけるシステムの有用性を考慮できるPMになりたいと思います

Step3　利害関係者

• (要点)力のない反対派の声に耳を傾ける
  • (失敗プロジェクト)力のある中立派が反対派に変わり、プロジェクトの推進を妨げる
  • (感想)言うほど簡単なことではありませんが、発言力の有無にかかわらず関係者全員の想いを汲めるPMになりたいものです
• (要点)潜在的な対立は定義フェーズで洗い出す
  • (失敗プロジェクト)プロジェクトの後半フェーズに入ってからコンフリクトが顕在化し、プロジェクトが破綻する
  • (感想)人間関係が構築されてからの議論では手遅れなテーマもあります。プロジェクト成功のために、初期段階から積極的な意見交換をする必要があります

Step4　阻害要因

• (要点)リスクは否定せず、徹底的に洗い出す／早い段階で全員で100～300個くらい洗い出す
  • (失敗プロジェクト)「プロジェクトにおいて必ず発生する問題」に対して適切に備えることができない
  • (感想)目の前の仕事を増やすことにつながりかねないこともあり、タスクの推進は難しいと思いますが重要です。リーダーシップの発揮どころになります。
• (要点)完璧主義者にならない／対応の優先順位を設定する／リスクは自然消滅しない
  • (失敗プロジェクト)通常のプロジェクトはリスク全てに対応するための予算を確保していないため、結果的に重要なリスクを放置してしまう
  • (感想)徹底的に洗い出したあとのテーマになります。予算にも時間にも上限があるので、優先順位付けにより現実的な対応を推進することは大事なPMタスクとなります

第２章　デザインフェーズ(Design)

テーマは「成功へのアプローチを自由に描け」です。 通常のプロジェクトにおける、プロジェクト立ち上げ時の予算や期間の確保、チーミングについて記載されています。

要点と失敗プロジェクトでありがちなことや個人的な感想を記載していきます。

Step5　資源見積り

• (要点)見積もりには、誠意ではなく根拠を見せる／「大胆」と「無謀」は違う
  • (失敗プロジェクト)顧客からのコスト削減や期間短縮の要望を安易に受け入れることにより、プロジェクトの実現性を下げる
  • (感想)見積りの根拠を示すしかありません。当然そこには利益も含まれるため難しいことですが、「赤字開発→プロジェクト失敗」では元も子もなくなります
• (要点)バッファは隠さずに共有する
  • (失敗プロジェクト)メンバーが個々にバッファを確保することにより、プロジェクトの費用や期間が膨れ上がる
  • (感想)適量のバッファは必要ですが、過剰なバッファは顧客にとってマイナスです。PMは過剰なバッファをなくす必要があります。

Step6　体制構築

• (要点)プロジェクトチームの「肩書」ではなく「役割」を定義する
  • (失敗プロジェクト)体制図上のボックスにメンバーの名前が入っているだけで、ボックスの役割が書かれていない
  • (感想)「Step2　対象範囲」と同様にやることとやらないことをはっきりさせる必要があります。曖昧さは将来の揉め事につながります。

Step7　作業設計

• (要点)IPOが明確なWBSを作成する(I:インプット、P:プロセス、O：アウトプット)
  • (失敗プロジェクト)関係者間の成果物のイメージがズレる。特に、開発者と顧客の乖離が大きい
  • (感想)そうは言っても事前のイメージ合わせには限界があると思います。これがアジャイル型開発が出てきた背景の一つかもしれません
• (要点)１タスクの最長期間は１週間
  • (失敗プロジェクト)実施期間が長い１タスクの失敗により、プロジェクト全体に遅延が生じる
  • (感想)作業担当者がタスクを分割できないのは何をやればいいか見えていないことに起因してたりもします。これは危険な兆候なので、PMは整理する必要があります。

Step8　規範設計

• (要点)会議の数は最小限にする／会議体ルールに規定されていないメンバーは勝手に会議に出てはならない
  • (失敗プロジェクト)キーパーソンの会議の拘束時間が長くて生産的な作業の時間を確保できない
  • (感想)トラブルプロジェクトほど、真面目な人ほど、顕著に見られる傾向です。ルールやPMの判断でコントロールしない場合、悪循環に陥りがちです

第３章　推進フェーズ(Drive)

テーマは「実行されない計画は「無い」に等しい」です。 通常のプロジェクトにおける変更管理、チーム運営、問題解決や意思決定におけるリーダーシップについて記載されています。

要点と失敗プロジェクトでありがちなことや個人的な感想を記載していきます。

Step9　変更管理

•  (要点)お客様から表面的な感謝をもらうのではなく、プロとして認められるようになる
  • (失敗プロジェクト)変更要望を安易に受け入れ、プロジェクトのリスクを高める
  • (感想)顧客からの信頼を失うことなく、うまくさばくのがPMの仕事です
• (要点)「ノー」というときは、代替案を示す／結論は一晩寝かせる
  • (失敗プロジェクト)目先の正論のみを主張すると、顧客とのリレーションを失う。また、全体最適でない構成になる
  • (感想)熱くならずに、チームの代表者として冷静に振る舞う必要があります

Step10　組織運営

• (要点)波風を立てることを恐れずに、メンバーの不満、不安、愚痴を引き出す
  • (失敗プロジェクト)意思疎通が原因で、複数タスクの合流ポイントで問題が発生する
  • (感想)怠ってもプロジェクトは成功するかもしれませんが、円滑な意思疎通は楽しく働くことにもつながるので、PMはその環境作りを心掛けたいものです。
• (要点)権限を手放すと、楽になる
  • (失敗プロジェクト)PMやPLなどのリーダー層がタスクを抱え込み過ぎる。
  • (感想)プロジェクト参画者全員を均等にすることはできませんが、特定要員に集中することは全員の不幸につながるので、避けなくてはなりません。

Step11　問題解決　＆　Step12　意思決定

• (要点)限られた情報を基に仮説を立てる
  • (失敗プロジェクト)見通しを立てるのが難しい問題ほど、有識者のKKD(勘・経験・度胸)で安易に対応方針を決める
•  (要点)リーダーに求められるのは判断ではなく決断
  • (失敗プロジェクト)リーダーが重要な判断や意思決定を後送りにする
• (要点)意思決定プロセスを隠さない
  • (失敗プロジェクト)プロジェクトにおける重要な意思決定の内容に同意できないメンバーの不満が高まる
  • (感想)Step11とStep12は序章に書いた「必ず発生する問題への対処」についての記載になります。文字に書くほど簡単ではない状況が容易に想像できますが、記載されていること一つ一つが「型」であり、これを実践できるPMがプロジェクトを成功に導くことができるのだと思います。

さいごに

冒頭の談志師匠の言葉には続きがあります。

どうだ、わかるか？難しすぎるか。

結論を云えば型をつくるには稽古しかないんだ。

「型破りな芸をするためにはその土台となる確固たるの型の修得が必要で、それは地道な稽古でしか得ることができない」と私は解釈しています。 よって、これからも書籍や実業務でコツコツ学び続けたいと思います。

 

最後まで読んでいただき、ありがとうございました。どこかの誰かの現状打破のきっかけになるとしたら幸いです。