コンテンツにスキップ

『外資系コンサルが教えるプロジェクトマネジメント』

約10年、IT業界で働いていますが、リーダーというものがやってこずこれまで来ました。さすがにそろそろやりそうなので、事前に必要な知識を得たいと思い、この書籍を購入しました。

プロジェクトをリーダーとしてやっていくために気をつけていくことが実体験や歴史的事例を基に分かりやすく書いてあります。

以下は私が本書で気になった部分の抜粋です。（自分用メモ）

第1章 プロジェクトは始まる前にすべてが決まる

  • 目的が不明確なプロジェクトはポシャる可能性が高い。「目的」がないと大きく二つの問題が起きる。
  • プロジェクトに問題が起こったとき迂回路を取れないという問題が発生する。
  • チームメンバーの管理が難しくなる。
  • 「問題」とは「現状と理想のギャップ」なので、「問題」を議論するということは「何を、どう変えたいのか」ということを議論するということ。目的をはっきりさせないと、人はどうしてもどこかでシラケてしまい、熱量を維持することができないくなる。
  • プロジェクトに必要な人材の質と量に対して、ちょうど100%になるようなチーム体制では必ず破綻する。なぜなら、機器対応できないから。何らかの想定外の事象が発生したとき、ギリギリのメンバー構成では対処できず、プロジェクトが破綻する。70%ぐらいの稼働率が理想的。
  • 成功も失敗も、リーダーの評価になる。プロジェクトが成功すれば、すべては丸く収まり、失敗すれば、すべてはリーダーの責任になる。
  • プロジェクトメンバー全員が、物理的にいっしょにいられるかどうかで、業務効率は大きく変わる。想定通りに進んでいる場合はいいが、プロジェクトの難易度が高く、当初の想定通りにはいかない局面がでてきたばあいのコミュニケーション労力が大きく変わる。
  • リーダーはプロジェクトの目的を明確化する必要がある。チームが掲げる目標には三つのタイプがある。
  • 合理的計算型
  • ビジョン型
  • ランダム試行型
  • 強い組織は上記三つのパターンをうまく組み合わせている。
  • 人間は、意義を感じない仕事には情熱を持って取り組めない
  • プロジェクトデザインにおいて、排除できるリスクについてはできる限り排除する
  • チームの稼働には、ある程度「遊び」があったほうが生産性が高くなる
  • 「プロジェクトオーナーは誰か」「その人はそもそもどんな問題意識を持っているのか」「このプロジェクトにどんな期待をしているのか」を明らかにすることが重要。これを知るには単純に「聞く」しかない。「言語化」が大事。=> プロジェクトオーナーの期待値と問題意識を把握する。
  • プロジェクト内部における仕事や役割において、優劣や上下の感覚を許さない
  • 参画するメンバーの懸念や期待を把握する
  • 評判の良くないメンバーであっても、そのメンバーの「成長余力」を信じて接してあげる
  • 「マタイ効果」を意識する
  • 関係者の期待値より高い結果に終われば「成功」であり、関係者の期待値より低い結果に終われば「失敗」
  • プロジェクト関係者の裏マップをつくる。この辺に無頓着なメンバーは意外と多い。

第2章 プロジェクト序盤に注意すべきこと

  • 最初期のミーティングでは期待値を超え、「貯金」をつくる
  • ことあるごとに「目的」に立ち返らせる。プロジェクトの開始段階で、チームメンバーに目的を浸透させる。ことあるごとに意識させ、「自分で答えに至る」感覚を覚えさせること。
  • メンバーの士気が低いのはリーダーのせい。士気を高い水準に保つリーダーの特徴として2つある
  • プロジェクトがどのような意義を持っているのかを継続的にリマインドさせる
  • 期待役割の明確化
  • 関係者を不安にさせない
  • チーム形成のプロセスの例としてタックマンモデルがよく知られている
  • フォーミング（形成期）
  • ストーミング（混乱期）
  • ノーミング（規律確立機）
  • パフォーミング（活動期）
  • ストーミング（混乱期）を早期に乗り切るには、リーダーによるチーム憲章の宣言が有効
  • チームの力量が高いチームの要素の一つは「チーム内で流通する『情報の量』」が多い。メンバー同士の「横のコミュニケーション」が活発化されると、チームの自律性はより高まり、情報量は大きくなる。

第3章 プロジェクトをうまく「着陸」させる

  • 「メンバーの時間」にはデリケートな配慮が必要。
  • リーダーはメンバーに相談されるようになったほうがよい。そのためにはとにかく「聞く」こと
  • キーマンとは月に1回程度コミュニケーションをとり、プロジェクトの向かっている方向に大きなズレがないことを確認する。
  • 定例会議では「やったこと」ではなく「その時点での結論」を出す
  • 直感的に「何かがおかしい」と感じたときは早めに共有する
  • プロジェクトが進行していくに従って、プロジェクトが当初掲げた目的や問題からズレていってしまう、というのはよくあること。リーダーは遠くのゴールを見据えてそれをブレさせないようにする。
  • 「最初に立てたお題にはこだわり続ける」必要があるが、当初考えていた仮設やアプローチがうまくいなかいということがわかったときは、迅速にそれを認めて仮設を作り直す、あるいは別のアプローチを考えることも必要。自らの考え方が誤っていたことを認め、変化を受け入れる。
  • プロジェクトでトレードオフとなる要素は「時間」「コスト」「品質」
  • メンバーへのフィードバックは「その場で」が基本。「自分のやった行動」と「結果のフィードバック」は、時間軸が短ければ短いほどいい
  • メンバーには「行動」ではなく「目的」を伝える。力量が足りていない、まだ未熟だという人には「目的と行動」を一緒に伝える。
  • フィードバックの基本は「行動＝ドゥーイング」について指摘する。「どうあれば＝ビーイング」の指摘ではない。

第4章 計画を成功に導くリーダーシップ

  • 慕われるだけのリーダー」でも「恐れられるだけのリーダー」でもダメで、両者を高次元でバランスさせているリーダーこそ、良いリーダー
  • 優れたリーダーは必ず嫌われる。敵がいないリーダーなどありえない
  • 「場をコントロールする」という意識をもつ。みんなから自然とリーダーとされる人の特徴は「一番先に話し始めた人」ということ
  • 必要なときに「助けてください」と声をあげること
  • いつも上機嫌でいること。そうすることで、メンバー相互間、あるいはメンバーとリーダーとの間での情報量が増加する。
  • メンバーを他人と比較することはしない。過去の自分（メンバー）と今の自分（メンバー）を比較する
  • 「率先垂範（人の先頭に立って物事を行い、模範を示すこと）」によって、組織は活性化するどころか、むしろ停滞する。
  • なにか失敗したときは、「犯人探し」よりも「原因究明」に軸足を置く