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

May 9, 2021

今回から始まりました雑な読書感想文。本はまあまあ読むけど、notion にメモるのとほぼ同じ行為なのでどうせならブログの方にメモっておこうかなと。基本読みながら線引いて、読み終わったら線引いたところをダラダラ書いてく。

はじめに

プロジェクトを進めていると、トラブルやルールだけだと判断できない事象が多発する。そんな中でも自分の判断で物事をすすめるためにプロジェクトマネジメント能力が必要
以前よりも何が hit するかわからない時代で非定形な仕事を取り扱うことが多くなってきているので、目的や価値観を共有することが大事になってきている

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

プロジェクトは目利きが大事
目的が不明確なプロジェクトは失敗する可能性が高い
目的が明確に設定されていない場合、問題が起こったときに別の手段を思いつきにくくなる
具体的な支持ではなく目的を伝えて「〇〇を達成せよ」と伝達するとよい
メンバーの質と量がプロジェクトが要求する水準に対して 100%だと思われる場合はプロジェクトの途中でキャパオーバーになることが多い
とりあえず初期の段階で warning を出しておけ
「一旦始めてみるか」で始めるのは気が重い仕事を先送りしている(わかる)
半分のプロジェクトは立てた計画が全く役に立たないほど変貌する。なので物理的に一緒にいることは効率に関わる。(オンラインでどこまで実現しようかね問題)
リーダーは夢を見る時間がないメンバーに夢を見させるのが仕事
プロジェクトの目的や意義をシンプルに落とし込んで共有するのが最も重要
プロジェクトが進行するに連れて想定していなかった問題が起こる。これら全部を意思決定していたら回らなくなる
なのでメンバーが判断できる基準が重要
些末な問題の処理権限を委譲するためには共通の判断基準や優先度が必要
リスク排除のためには「論理設計に無理がないか」「リソースが十分か」の 2 つ
リソースは 70%くらいの稼働率で回る程度確保できると、想定外の事態が発生して負荷が高くなる局面を乗り越えられる
プロジェクトの真のオーナーが誰なのか明確にする。関係者によってはプロジェクトを通じて達成したい目的が異なる
目的が不明瞭だと判断が必要な局面でストレスを抱える
メンバーごとに「好き・嫌い」「得意・不得意」のマトリクスを作る。聞いとく
どんな経験を積んできたか、担当したタスクは何だったかを聞いとく
メンバーに試験的なタスクを任せてどういう仕事の進め方するか、どういう能力があるか知る
メンバーにどのような懸念を持っているか聞いとく
メンバーは懸念を知らせずに、やばい状況になって初めて報告する
プロジェクトを通してどういう知識やスキルを得たいか、どういう成長をしたいか、どういう弱みを直したいのか聞いとく
飲み込みに時間がかかる人がいることを頭に入れとく。関係性を整理しないと納得できない人とか。そういう人に対して遅いとか飲み込みが悪いとか判断しない
メンバーに期待を伝えすぎない
- 期待に答えようとして報告を上げにくくなる
- 楽観的な見積もりや成果を報告してしまう
だいたい 1.5 倍の見積もりだしとけ
- 正確に見積もらないが、トータルで同じくらいになるような見積もり出せるとよさそう
「全てのモジュールが成功することはない」と伝えておく
10 個あったら 2,3 個は空中分解する
一応完了したが 8 割、素晴らしい成果を出したが 2 割くらいの達成度でよい
早めに warning 出しておくと、「やっぱだめか」になって「少し延ばそう」になる
低めの期待値を伝えて高めの期待値を受けるのは「貸し」を作るコミュニケーションになる(譲歩を引き出すコミュニケーションなるほど)
裏組織マップを作って利害関係整理しとく
誰がキーマンなのか見抜いておく
ネガティブなメンバーがいたらその人がどうやったら動くのか知る

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

序盤は期待値を超えておく。期待を進捗が上回ると安心して任せてくれるようになる
プロジェクトマネージャーはオーナーシップ持てるので楽しい仕事
プロジェクトマネージャーはゴールを描いて、ルート設計、体制をデザインする
アーティストが作品の制作途上で横から口出しすることが嫌なように、自分のプロジェクトを自分で仕切りきって完遂するのが重要
プロジェクトの目的を伝えるのに最も適したタイミングは「メンバーが判断に迷って相談してきた時」
判断能力が低いと思うのは、プロジェクトの目的や優先順位を明確に伝えきれていないため
↑ この辺が伝えられていると個別の指示はあんま必要ない
プロジェクトの途中でメンバーがやる気を落としている場合は、自分が何を伝えきれていないか考えてみる
メンバーはプロジェクトが始まるとプロジェクトの意義が忘れられて目の前の問題の解決に意識を集中してしまいがち
リーダーはなんのためにやっているか、うまく行かないと誰にどういう影響が出るのか語り続ける
人は自分がかけがえのない存在として組織に属していると実感できるときに充実感を覚え士気が高まる
プロジェクトにおいては「便りがないのは悪い便り」
不安を感じさせないための最大のポイントは「不安を共有している」と相手が思った時
大事なのは不安要素を潰すのではなく、「あなたの不安を理解しています」と伝えること
チーム形成のプロセスとして、タックマンモデルというものがあり、「形成期」→「混乱期」→「規律確立期」→「活動期」と遷移していく
混乱期を通らずそれ以降のフェーズに行ってもパフォーマンスが出ない(らしい)
混乱期を早期に乗り切るにはチーム憲章(チームが守るべき基本ルール集)をつくるとよい
「すべての意見を歓迎する、絶対に否定しない」というのはいれたほうがいい
できるだけ短期間で「長く一緒に働いている」ような関係を作る
情報を伝える相手がどのように反応するか、伝えたが判断でいない場合に情報の流通量が低下する
情報流通をリーダーに頼っていると、危機的な状況でスピーディに対応できない
プロジェクトで起こる問題は、往々にして利害関係や政治力学が絡んでいるので問題が処理できずに大きくなっている
なので、プロジェクトチームではなく、プロジェクトオーナー間で解決できる場を作るとよい
プロジェクトマネージャーはそういう場で理路整然と論点を整理していく
↑ その手前である程度関係者から個別に情報収集しておくことは重要
「決定したら教えてくれ」くらいの温度感で関係者に整理を求めてもよい
生意気だと思われるかもしれないが、プロジェクトが失敗したら評価が下がるのはプロジェクトマネージャーなので生意気くらいでよい

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

1 週間くらいの塊で何にどれくらいの時間を使うのかについては整理しておく
メンバーは本当にやばくなるまでリーダーに相談してこないものである
リーダーは上機嫌で居続けないとメンバーが本当に相談してこなくなる
キーマンとは少なくとも月に 1 回はコミュニケーションを取って軌道修正する
意思決定のクオリティを上げるには反対意見をどれだけ引き出せるか
議論の場ではやったことを報告するのではなく、「示唆・洞察」「その時点での結論」を提示する
何回も出てくるけど「なぜやっているか」が大事
リーダーの決断が間違っていた、メンバーの言っていたことが正しかったなんてことはありうる。むしろチームの強みが発揮されている状況と考えてよい
常に素直に向き合う
関係部署は日常のビジネスで忙殺されているので基本手伝いたくない
ので、利害関係を抑えて動きの悪い部署には働きかけてもらう
うまく言っていないプロジェクトは同じ方向を向いてなくて、対峙している
マネージャーの仕事は資源配分である
プロジェクトが進むと、スコープを広げたい依頼が来る。必ず人員か期間の面でのトレードオフを即座に提案する
提案があとになると言われた側は釈然としない。時間があくと「貸し借り」がリセットされているので。
- ↑ 高い期待値を押し付けられた側は貸しができているという以前の話の流れがチャラになってしまう
- 交渉力ﾀﾞｲｼﾞﾀﾞﾈｰ
出てきたアウトプットは即座にフィードバックする
- フィードバックしてもらう環境を作るべし
フィードバックは being ではなく doing に対して行う

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

正しいことをやっている、高いパフォーマンスを出していると誹謗中傷されたり反対されたりする
変革には破壊が伴うので
リーダーとみなされるには一番先に話し始める、一番はじめに質問する
日本はあんまりリーダーシップについて議論されない
上機嫌であれ
まずは「リーダープレイ」をやろう
失敗してしまうような仕事を与えてしまった、未然に防げなかったのはリーダの責任
人は比較されていると感じるとコルチゾールが発生してパフォーマンスが落ちる
メンバーの強み弱みを理解して、成長を見守る
大事なのは内省する経験
仕事の目的と達成する手段は分ける
IQ は成功や幸福感に統計的相関が見られないが、EQ(心の知能指数)は必須らしい
苦しい状況でその人のレベル、本質が垣間見える

個人的学び

交渉力大事
思い返すとできる人っておんなじこと何度も言っているイメージある
裏組織マップ絶対作る
今持ってるプロジェクトのリーンキャンバス的なやつは思考整理のために軽く作って提案する
情報の流通量を増やすためのコミュニケーションをオンラインでどうやってくかむずそう、考える
リーダープレイやる

最後に

次は PMBOK の本読んで、別のトピックに移る予定。