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

著者 :
  • 大和書房
4.13
  • (24)
  • (32)
  • (10)
  • (1)
  • (1)
本棚登録 : 244
感想 : 30
本ページはアフィリエイトプログラムによる収益を得ています
  • Amazon.co.jp ・電子書籍 (184ページ)

感想・レビュー・書評

並び替え
表示形式
表示件数
絞り込み
  • ・目的が不明確なプロジェクトはぽしゃる(手段は目的でない)「これって、そもそも何のためにやってるんですか?」
    ・プロジェクト初期で、リソース不足を主張する。
    ・有能な人に簡単な仕事を与えて完全に任せ、難しい仕事をリーダー+無能な人で行う。
    ・新幹線の技術、宇宙開発には枯れた技術だけを使う。
    ・プロジェクトのリスク排除:
     ①リソースは十分か?70%くらいの稼働で回るくらいがいい。
     ②論理設計に無理はないか?ホワイトカラーは基本的に、情報の入手→情報の加工→示唆や行動計画のアウトプット、で行う。
    ・プロジェクト・メンバーを知るために、「好き・嫌い」「得手・不得手」のマトリックスをつくる面談を1時間する。
    ・プロジェクト開始時点で、メンバーの懸念事項を把握する。
    ・プロジェクト・オーナーの期待値が上がらないようにコントロールする。10個あったら、2~3個はぽしゃるし、上手くいくのも2~3個。
    ・高めの期待値を投げられたら、低めの期待値をぶつけて、その後高めの期待値を受け入れることで、1つ貸しを作る。
    ・プロジェクト関係者の裏マップを必ず作る。プロジェクトへの賛成・反対が横軸。影響力が縦軸。
    ・最初にスタートダッシュする。早め早めにレポートする。遅れると、マイクロマネジメントされて、悪循環に陥る。
    ・ことあるごとに目的に立ち返らせる。相談されたときに、目的を思い出させて、答えを自分で出させる。
    ・チーム憲章をつくる。何を言っても受け入れると入れる。
    ・複数のプロジェクトオーナーとはできれば個別に合わない。プロジェクトオーナー間の意見の対立がある場合には、一堂に会する場を作り、個人名も挙げて、意見の対立があること、優先順位に齟齬があることを伝える。彼ら同士で決着をつけさせる。なあなあの結論を飲み込まない。優先順位をきっちり整理する。
    ・プロジェクトを成功させるプロジェクト・マネージャーは徹頭徹尾「プロジェクトを成功させるためには何が必要か」を考える。
    ・リーダーは上機嫌たれ。二人きりの時に悩み・相談を聞く。
    ・キーマンの時間は始めの内に押さえておく。
    ・ミーティングでは、進捗報告+そこまでの進捗に基づく仮説を伝えて議論する。
    ・ミーティングでは、表情をよく見て読み取る。
    ・動きの悪い関係部署を動かすために、社長に声をかけてもらう。上手くいっていないプロジェクトは部署の対立がある。
    ・行動とフィードバックの時間感覚は短ければ短いほど良い。必ず、外部からのフィードバックをもらう。
    ・フィードバックを与えるときは、具体的な行動を提案する。
    ・リーダーの条件は「一番先に話し始めた人」。聞きたいことがなくても最初に質問する。
    ・メンバーを比較しない。強いストレスがかかる。
    ・リーダーは率先垂範よりも、目的を決めることが役割。手段を決めるとモチベーションが下がる。

  • 「勝てるプロジェクト」を見極めて、そこに自分の身を置く。これが、プロジェクトリーダーとして成功するための最初のポイントになります。

    簡単なモジュールは優秀なメンバーに任せて、難しいモジュールは、プロジェクトマネジャー自らが腕まくりして手を突っ込み、サポートに「それほどでもないメンバー」を据える、というのが正しいやり方です。

    期待値をコントロールする要素としては「期間」「リソース」「成果」 の三つがあります。筆者の場合、基本的に「ギリギリこれだけあれば大丈夫だろう」という見積もりに対して、だいたい一・五倍程度を提示します。

    フィードバックの基本は「どうすればもっと良かったか」という点についての意見をもらう、ということです。問いは「どうすれば」、つまり 「行動=ドゥーイング」 についての指摘であって、決して「どうであれば=ビーイング」についての指摘ではありません。

    結局のところ、 上機嫌なリーダーが率いるチームではメンバー相互間、あるいはメンバーとリーダーとの間での情報量が増加する のです。  プロジェクトをあずかるリーダーであれば、いつも上機嫌でいることを心がけましょう。

  • 日系、外資系企業の両方で長きに渡りプロジェクトマネジメントを経験された筆者がその重要性と重要なポイントを余すことなく教えてくれる一冊。
    入門書などから基本的な情報を得たうえで本書を読むことで、教科書には載っていないより実践的な考え方を学ぶことができる。

  • 会社でのプロジェクト推進のために読む。

    プレッシャーが大きく、気分が重くなることも多いが、皆で作品を作るために上機嫌でいきたい。

  • プロジェクトを回すにあたって、プロジェクトとの関係のない現場スタッフ等に、予め根回ししておくことの重要性を知った。互助関係を理解することで、よりポジティブにプロジェクトが回るように設計ができた。

  • プロジェクトを進めていく上での「型」。

  • 論点がきれいに整理されていて非常に読みやすい。

    ●リーダー:目的設定と権限委譲

    ●目標設定
     ・合理的計算型:FYxx までに$yy, market share zz%
    --->漸進的な進歩のみ。動機/創意を高いレベルで維持できない
     ・Vision型:アポロ計画。10年以内に人類を月に
    --->単体では具体論につながらずメンバーの動機/創意が駆動しない
     ・ランダム試行型:ソニー(何でもいいからワクワクするようなことを)
     --->強い組織は組み合わせ。全体の目的はvision型、その中で合理的計算型に
       落とす部分、直感的な飛躍や創発を期待する部分はランダム試行型で。

    ●プロジェクトのリスク判断
     論理設計で破綻していないか確認。
     ・Prj目的:百以上あるSKUに対して広告投下量を科学的に最適化
      ・入力される情報:商品別売上、広告費の時系列データ
      ・情報の加工:多変量解析などの統計分析
      ・出力される示唆:商品別の最適な広告投下量
       --->統計的な分析に頼って示唆を抽出。一方で統計分析は”特に明確な示唆が
      出ない”ということも多いわけでその瞬間The end.

    ●生産性を高めるには、チームの稼働率に”遊び”を設ける
    HBSのステファン・トムク氏(数字の待ち行列理論)によれば、
     ・稼働率が80% -> 90%に上昇すると処理待ちの時間はx2以上に
     ・稼働率が90% -> 95%に上昇すると処理待ちの時間は更に倍増

    -->稼働率の上昇と生産性がlinearに相関するのは製造や取引処理などの”変化に
      乏しく例外的な突発事項がほぼ発生しない”ルーチン業務。
    -->非定型、非ルーチンだからprj teamを組織しているわけで、稼働率を高め過ぎる
      と予定外の事象によって致命的な作業遅延に。余裕をもったリソース確保を。

    ●メンバーへの期待(”マタイ効果”)
     ・これまでの評価がイマイチでも、若手であれば必ず成長余力は大きいので
      期待し、信じること。
     ・初期段階の微妙な評価の差が本人の自信に繋がり、それがより高いレベルの経験
      に繋がりそれが更に本人の自信を増幅させる。(4月/3月生まれのgap)
      -->持っている者は益々与えられ、持っていないものは益々奪われる
      -->人間は初期段階の微妙な差によって人を差別しすぎている

    ●関係者の”裏マップ”を作成
     ・プロジェクトへの影響力(高/低)&プロジェクトへの態度(posi/nega)で
      4象限管理、そこに人物間の関係(子飼い/元上司部下/同期など)を記入
     ・Prjの意思決定者に対し態度変容させる最適なjourneyをプランする。
     ・組織認識力。

    ●チーム内の情報流通量を増やす
     ・失敗するprjは情報が根詰まり(適時/適切に共有されない)している場合が多い
     ・縦型(1 to many)ではなくメンバー相互の連携を担保する
     ・適切なheads appができるだけのメンバーの信頼形成ができているか
     ・上司は常に”上機嫌”でいること。上司が常に不機嫌な組織では必ず流通量が低下

    ● Being << Doing
     ・誠実、未来志向、情熱的、、という良きリーダーの”性質(being)を獲得する  
      上では、日常的な行動を変革する。 
     ・なぜなら行動→習慣→人格→運命へと変革の輪が広がるから

    ●一貫性を持つ
     ・時間的一貫性;同じ人に対して、その時々で態度を変えない
     ・関係的一貫性;対人関係においてfareである。垂直(上司部下)水平(部下間)
     ・状況的一貫性;通常でも緊急事態やhigh pressureでも人の接し方/行動が一貫
    --->魅力的な人:”ブレない軸”を持っていること。

  • ■作者が一番言いたいこと

    スキルは

    1.その会社で評価されるスキル
    2.その業界で評価されるスキル
    3.どの業界でも評価されるスキル

    に大別される。
    本当に自分を助けてくれるのは
    「3.どの業界でも評価されるスキル」だ。

    プロジェクトマネジメントのスキルはもっとも業界横断的に活用が可能で、
    「持つもの」と「持たざる者」の間に大きな差を生むスキルである。


    ■勉強になった要点要点

    プロジェクトマネジメントが業界横断的に有用なポジティブスキルということは疑いようの無いところであろう。どこ会社にも必ず「プロジェクト」はあるのだから。

    本書の内容を、敢えてPMBOKに当てはめてみてみると、
    ・「スコープマネジメント」:勝てるプロジェクトを見極めろ、
    ・「品質マネジメント」:目的と意義に立ち返ることで品質を確保する
    ・「資源マネジメント」:とにかく人は多めに確保しろ
    ・「コミュニケーションマネジメント」:いつも上機嫌で。情報を流通させよう
    ・「リスクマネジメント」:期待値は低く持って行く。
    ・「ステークホルダーマネジメント」:不安にさせないことに注力する
    ・「調達マネジメント」:あまり記載は無かったように見える

    といった感じだろうか。

    上記の中でもとにかく「コミュニケーションマネジメント」と「ステークホルダーマネジメント」について色々なテクニックや注意しなければいけないことが紹介されていた。

    その中でも私が特に重要だと思ったのが、

    ・プロジェクトはメンバーで決まる
    ・ステークホルダー管理はきっちりと
    ・リーダーシップはやっぱり大切

    という3点だ。この3点について刺さった個所を抜粋してみる。

    ∇プロジェクトはメンバーで決まるとは
     まずは人員の量。プロジェクトに必要な量に対して100%では必ず破綻する。危機に対応できないから。遊びが発生するくらいの人員が望ましい。成功しても失敗してもプロマネの評価になるのできちんと交渉しよう。
     メンバーの持つ懸念や期待を把握した上で、プロジェクトの意義を伝えモチベーションをあげ、自発的に動けるようにする。メンバー間の情報流通はプロマネがハブになってはいけない。それでは情報の流通量がハブのキャパに左右されてしまう。
     もし、「優秀なメンバー」と「相対的に優秀でないメンバー」、「難しいタスク」と「簡単なタスク」があった時に、やってしまいがちなミスは「難しい仕事」に「優秀なメンバー」、簡単な仕事に「相対的に優秀ではないメンバー」をアサインすることだ。両方とも失敗する確率が高まる。正解は、「簡単なタスク」に「優秀なメンバー」をアサインし、「難しいタスク」を、「プロマネ腕まくりして優秀でないメンバーと一緒にこなす」こと。そうすれば簡単なタスクのことは忘れて作業出来る。
     
    ∇ステークホルダー管理はきっちりと とは
     プロジェクトオーナーの期待を明確にする。そのうえで勝てるプロジェクトと勝てないプロジェクトを見極める。少なくとも「何のために」が抜けているプロジェクトはヤバい。
     プロジェクトオーナーが複数いてそれぞれの期待が異なる場合は、プロジェクトオーナー同士できちんと目的を決めて貰うことが大切。
     プロジェクトを実際に動かす前に関係者の裏マップを作ると良い。プロジェクトをつつがなく終わらせるには政治が不可欠。
     そのためにもプロジェクトオーナーの不安には敏感でいよう。そしてその不安に対し「大丈夫」というメッセージは適切に出していこう。
     それでいてきちんと「期待値」はコントロールすべし。「低い期待値」に落ち着けることもプロジェクトの難易度に関する見通しを共有することに役立つ。要は「成功」させるための布石として成功のラインを下げておくのも有効だということだ。
     目指すところは、「マイクロマネジ」されない環境。プロジェクトオーナーにマイクロマネジされるプロジェクトは最悪だ。プロマネもモチベーションを保つのが難しくなるだろう。

    ∇リーダーシップはやっぱり大切
     嫌われることを恐れない。それでいていつも上機嫌でいること。上機嫌なリーダーが率いるチームではメンバー相互間、もしくはリーダーとの情報量が増加する。 それは「何かおかしい」という感覚の早めの共有にも役立つ。
     リーダーシップは一日にしてならず。いきなり良いリーダーになるのは難しいので、振る舞いから入ろう。そしてトラブルはすべてリーダーである自分の責任という意識を持つ。「The buck stops here = すべての責任はここで止まる」というハリー・トルーマンの覚悟を見習おう。
     それは「助けて下さい」と言える勇気を持つことにもつながる。自分の力量だけで火消ししようとすると炎上させてしまうだけだ。


    山口さんが本書でも述べていたがプロジェクトの半分は人選で決まるという。とにかく「人」だ。
    プロジェクトメンバーに対しての接し方、そしてステークホルダーに対しての接し方。意識して変えて行こうと思わされる一冊だった。

  • - 目的が曖昧なプロジェクトは非常に危険です。炎上するか、しないにしても手続き的でつまらないケースが多い。 注意しなければならないのは、一見すると「目的」らしいのだけれど、実際のところ「何のためにやるのか」という問いに対する答えになっていない目的、「目的のふりをした手法」が多いということ。  本当の意味での「目的」を明らかにするためには、「目的」を訴える人に対して、「それってそもそも何のためにやるんですか?」と問いかけてみると良いということです。
    - 「このメンバーでは戦えない」と強硬に主張することで、関係者の期待値をコントロールすることができる ということです。 「このメンバーでは戦えない」と主張することで、周囲の関係者は、プロジェクトの難易度や成功確率に関する楽観的な期待を改め、緊張感を持つようになります。  こうすることで、あとで実際にプロジェクトが危機的な状況になった時に、メンバー増員や交代の交渉をしやすくなるわけです。
    - リーダーの判断力を効果的に活用するためには、「重要」かつ「難易度が高い」問題の解決にリーダーの時間を集中的に投入するべきで、前記の二つの条件、つまり「重要」かつ「難易度が高い」という条件に該当しない問題については、その処理権限をメンバーに大きく委譲することが求められます。  ここで問題になってくるのが、メンバーの判断基準です。
    - 大きなプロジェクトであれば、ある程度のリスクはつきものだと考えましょう。「何かあったらその時に考えよう」くらいの気持ちで、とりあえず前に動かしてみないと始まらない、というのが多くのプロジェクトの実情なのです。  しかし、だからこそ、 プロジェクトデザインにおいて、排除できるリスクについてはできる限り排除する という意識が必要です。  では、プロジェクトからリスクを排除するための着眼点はどこになるのでしょうか? 大きく分けると「論理設計に無理がないか?」と「リソースが十分か?」の二つになります。順に説明していきましょう。
    - リソースは100%ギリギリではなく、できれば 70%くらいの稼働率で回る程度に確保できるのが理想的 です。/// チームの稼働には、ある程度「遊び」があった方が生産性は高くなる のです。
    - プロジェクトをやっていると「こちらを立てればあちらが立たず、あちらを立てればこちらが立たず」という、トレードオフの状況が必ず発生します。このトレードオフが発生したときに、どちらを立てるかを意思決定するのがプロジェクトリーダーの大事な責務なわけですが、このときに重要な判断の拠り所になるのがプロジェクトオーナーの問題意識になります。  そのため、「プロジェクトオーナーは誰か?」「その人はそもそもどんな問題意識を持っているのか?」「このプロジェクトにどんな期待をしているのか?」 を明らかにすることが重要になります。
    - 聞いてみると、実はプロジェクトオーナー自身が明確にそういった期待をイメージしていないこともあるのですが、そうやってインタビューをすることで、それが明確に言語化されます。  この「言語化される」というのが大事です。なぜかというと、言葉にするとコミットメントが生まれるからです。プロジェクトオーナーとして、プロジェクトのマネジャーとメンバーに対して「期待しているのは○○」とか「このプロジェクトで解決したいのは○○」とはっきり明言してもらうことで、そこを一種の立脚点として設定できることになります。
    - 「人間関係を構築するのがとても上手だし好きだ」というメンバーであれば、若くても対外 折衝 を任せる方が資料の分析や整理をやらせるより良いでしょうし、内向的だけれども 緻密 に考えていくのが好きだし得意だという人であれば、年長者であってもバックオフィス的な仕事の方がチーム全体としては機能するかもしれません。  重要なのは、 プロジェクト内部における仕事や役割において、優劣や上下の感覚を許さない ということです。その上で、メンバーの力量や特性に応じた仕事の割り振りを考えましょう。
    - 「ほとんど人となりを知らない」という新しいメンバーの場合、どうやって力量や特性をスキャンすれば良いのでしょうか?  筆者がいつもやっているのは二つのことです。  一つは、単刀直入に、その人に聞いてしまう。もう一つは、「試験的なタスクを任せる」ということです。
    - どのような期待や懸念を持っているかについて把握することも、プロジェクト開始前の重要事項です。/// 一方で、 プロジェクトに参加するメンバーの期待を聞いておく のも重要なポイントです。
    - アサインメントは逆にするべきです。簡単なモジュールは優秀なメンバーに任せて、難しいモジュールは、プロジェクトマネジャー自らが腕まくりして手を突っ込み、サポートに「それほどでもないメンバー」を据える、というのが正しいやり方です。/// 「優秀なメンバーに簡単なモジュールを任せ、そのモジュールについてマネジャーは忘れる」というのが正しいということになります。
    - 必ずしも評判の良くないメンバーであっても、そのメンバーの「成長余力」を信じて接してあげる ことがとても重要です。  人の成長カーブにはそれぞれの「伸びる時期」があります。
    - 「低めの期待値」を伝える効用の二つ目に、「プロジェクトオーナーとのあいだで発生する様々な交渉を有利に進めるカードが手に入る」 という点が挙げられるでしょう。
    - 「プロジェクトマネジメントはプロ野球のペナントレースと同じ」 ということです。プロ野球のペナントレースで優勝戦線に絡むためには、シーズン初期にどれだけ勝ち星を先行して挙げられるかが鍵になります。
    - 彼らの期待値をできるだけ低めに持っていくことが大事であることはすでに指摘しましたが、それがなぜ大事かというと、実際の進捗が期待値に届いていないと思うと、いろいろと厄介なことが発生してくるからです。  典型的にはマイクロマネージがそうです。/// 逆に、プロジェクトの初期段階で、期待値としての進捗を、実際の進捗が上回っていると彼らが感じると、安心して任せてくれるようになります。さらりと書いているように思われるかもしれませんが、ここはとても大事なポイントです。
    - よく「メンバーの判断能力が低い」とか「メンバーが使えない」とか「指示通りに動かない」と言って嘆いているプロジェクトリーダーがいます。もちろん部下本人の力量の問題もあるかもしれませんが、筆者が見る限り、 その嘆きの原因の半分以上はリーダーの力量の問題 です。 「判断能力が低い」のは、判断の立脚点となるプロジェクトの目的や優先順位をリーダーが明確に伝えていないからです。 「指示通りに動かない」というのも、根っこの原因は同じで、これも「最終目的」がぼやけていて、個別の指示を文脈の中で意味づけすることができないために、「指示通りに動かない」のです。
    - メンバーのやる気のなさ、オーナーシップの低さの原因は、リーダーであるあなた自身にあるから です。したがって、プロジェクトの途中で、メンバーのやる気が減退している、あるいは士気が下がっていると思われるときは、まず自分のどこに、メンバーのやる気を減退させ、士気を低下させる要因があるのか、ということを考えてみましょう。
    - 一つは、「そもそもこのプロジェクトはなんのためにやっているのか」という大義を忘れてしまうと、士気はどんどん低下していってしまいます。こういったときにこそ、リーダーは、「このプロジェクトはなんのためにやっているのか、これがうまくいかないと誰にどういう影響が出るのか」という点を語り続けることが必要になります。
    - 二つ目の要素が、「期待役割の明確化」 です。平たく言えば「あなたにはこれをやって欲しい。これはとても大事な仕事だから頼むよ」といって任せるということです。  人は、自分がかけがえの無い存在として組織に属していると実感できるときに、大きな充実感をおぼえ、士気が高まります。
    - こういった事態を避けるためには、まずは何よりも「関係者を不安にさせない」ということが大事です。  具体的には、 プロジェクトの初期段階において、当初想定されたよりも早め早めにレポートする ということです。「レポートするような明確な進捗がない場合はどうするのか?」と思うかもしれませんが、そういう場合でも「進捗はあまりありませんが、大丈夫です」という報告が必要になります。
    - プロジェクトリーダーの最も重要な責務の一つが「関係者の不安を解きほぐす」ということです。/// 不安を感じさせないための最大のポイントはなんでしょうか? 最も重要な点は 「不安を共有している」と相手が思っていること なのです。/// 不安を感じているにもかかわらず、「不安だ」と伝えることにはストレスが伴います。これは心理学でいうところの「葛藤状態」ですから、これを解消するためにこういったマイクロマネージをし始めるわけです。/// こういったとき、プロジェクトマネジャーは何をすればいいのか。一番大事なのは 「あなたが不安に感じていることを、私は知っていますよ」 と伝えてあげることなのです。 「進捗が遅れていることに、不安でいらっしゃると思いますが、今後、○○○○することで当初の予定通りに追いつきますからご安心ください」と伝えておくだけで、相手の不安は大きく解消されます。
    - 多くの人は 「個々のメンバーの力量が高いチームは、チームとしての力量も高い」と考える傾向がありますが、これははっきり言って誤解 です。  心理学者のアーヴィング・ジャニスは、世界で最も賢い人たちの集団が、信じられないほどに愚かな意思決定をした歴史的な事例を集め、必ずしも集団の個別構成員の平均的な能力の高さが、集団全体のパフォーマンスの高さと相関しないということを証明しました。
    - そして、次に重要なのは、 チーム内で流通する「情報の量」 です。チームの中で流通する情報の量が減ると、必ずといっていいほど、プロジェクトは危険な状況に陥ります。/// メンバー同士の「横のコミュニケーション」が活発化されると、チームの自律性はより高まることになります。 すべての情報を、リーダーをハブにして経由させようとすると、チーム内の情報流通量はリーダーの処理能力に依存することになります。
    - これは何もプロジェクト開始時に限らず、プロジェクト全般を通じて気をつけなければいけない点なのですが、 複数のプロジェクトオーナーがいる場合、それらのプロジェクトオーナーの一人一人と、個別に会うということはなるべく避けた方が得策です。/// このとき、プロジェクトオーナーが一人であれば、別に問題ないのですが、 複数のプロジェクトオーナーがいる場合、これらの要件や仮説が矛盾するケースが必ず起きる のです。/// こういう時、プロジェクトリーダーはあえて「融通の利かないコンピューター」のように振る舞う必要があります。   空気に流されて「なあなあ」の結論を飲み込まない、ということです。/// この局面が、プロジェクトの中盤以降で出てくると、プロジェクト運営が大変難しくなるので、できるだけ早い段階でプロジェクトオーナー間の思惑の違いや期待値のギャップをあぶり出して、それらを調整させるために彼ら自身が議論し、基本的な方針として落ち着かせるための場を設定するように心がけましょう。
    - メンバーというものは、自分が思っている心配ごとについて、いよいよ本当にヤバいという段階になるまで、リーダーに上げてこないものだと考えてください。その上で、リスクを未然につぶしていくためには、メンバーが察知している「心配ごとの小さな種」を、積極的に聞いて回ることが必要です。そして、聞く際には、できる限り「周りに人がいない状況」でやること。
    - しかし、メンバーに意見を求める効用はそれだけではありません。メンバーに意見を求めることで、参画意識を高め、モチベーションを維持・向上させることが可能になります。
    - キーマンとの定例ミーティングを行う際、注意したいのが、 報告するのは「進捗」ではなく「その時点での結論」 だという点です。定例会議等の報告会でよくなされる報告は「やったこと」に終始しがちです。 /// アクションだけではなく、アクションから得られた示唆や洞察を踏まえた上での「現時点での仮の答え=仮説」を提示することで、時間をとってもらったキーマンとの深い議論が可能になるのです。キーマンに時間をとってもらっても「アンケートを実施した」という報告だけでは「あ、そう」で終わりになってしまいます。
    - メンバー間に何かギクシャクしたものが感じられる、あるいはクライアントの様子がおかしい、それまで快活だったメンバーに元気がない、というときには、オープンに「何かがおかしいと思うんだけど、○○さんは思い当たる節がない?」と聞いてみましょう。
    - これはプロジェクトマネジメントに限らず、家庭生活や友人関係や健康についても同じだと筆者は思っているのですが、 直観的に「何かがおかしい」と感じられるときには、その後で必ずといっていいほど何か大きなトラブルが起きます。  こういったとき、つまり「何かがおかしい」と感じられるときは、家庭であれば家族のメンバーと、友人関係であればその友人と、自分の体であれば医者と、話し合うことが必要です。  そうすることで実際に解決することと解決しないことがあるわけですが、そういった違和感や不安を抱えていることを周囲と共有し、話し合うということそのものが大きなトラブルを未然に防ぐためには重要です。  よく言われることですが、 関係性は一瞬で崩壊します。 これはクライアント関係でもプロジェクトチーム内の人間関係でも同様です。それまで「安泰だ」と思っていた関係性が一瞬にして崩壊する。しかし萌芽は必ずあったはずです。
    - そういう言葉では言い表せない微妙な違和感に気づき、「なんとなく嫌な予感がする」ことから、茂みに近づくのを止めて命拾いするか、感覚がもたらす微妙な違和感を無視して天敵に食べられてしまうか。   いま、私たちを脅かす見えない危険は茂みの中ではなく、会議室やフロアに漂う微妙な空気の中に潜んでいます。 これを見抜けるかどうかで、その人の仕事人生は大きく変わってくることになります。/// プロジェクトマネジャーが拠って立つのはあくまで合理性ですが、だからといって自分の体に沸き起こる感覚、特に「なんとなく嫌な感じ」は何かがプロジェクトの水面下で起こっていることを示す重要なサインになるということを忘れないでください。
    - 目の前にある作業に没入しているプロジェクトメンバーは、どうしても近視眼的になりがちで、プロジェクトの途中で接触する情報や向き合う問題に右往左往しがちです。プロジェクトリーダーは常に、足元の障害物をかわしながらも、遠くのゴールを見据えてそれをブレさせないようにしなければなりません。
    - 必要なときには、 自らの考え方が誤っていたことを認め、変化を受け入れるのがひとかどの人物 であり、一方で、表面的には従いながらも、それまでの考え方から脱却できないのが小人だと指摘しているわけです。  プロジェクトチームのリーダーは、別にスーパーマンではありません。  多くのプロジェクトチームでは、リーダーは経験年数が若干長いかもしれませんが、せいぜいその程度の違いでしかありません。  したがって、リーダーが初期段階で立てた仮説やアプローチ、方針が、プロジェクトの進行途中で間違っていたことがわかる、というのはよくあることなのです。
    - 重要なのは、タイミングです。メンバーは、リーダーの仮説や方針、アプローチが誤っていたという事実そのものよりも、 その状況に対して、どのように対応したかという事実によって、リーダーの「格」を見ている のです。
    - 一方で、その逆であればどうでしょうか。自分の仮説が間違いであったことを認め、そのためにメンバーに無駄な仕事をさせてしまったことを謝罪したうえで、再度仮説を構築し、アプローチを再考したいので、メンバーの意見をぜひ聞かせてほしいと真摯に依頼されたら、どうでしょうか?
    - フィードバックの基本は「どうすればもっと良かったか」という点についての意見をもらう、ということです。問いは「どうすれば」、つまり 「行動=ドゥーイング」 についての指摘であって、決して「どうであれば=ビーイング」についての指摘ではありません。 /// 比べてみればわかると思いますが、×のケースでは常に「どうあるか=ビーイング」についての否定がされているだけで、「次はこうするといいよ」という具体的な行動の提案が入っていません。  こんなフィードバックをされてもメンバーは途方にくれるだけでポジティブな効果はまったくありません。むしろ無力感を感じ、仕事へのモチベーションも失ってしまうでしょう。
    - なぜ「ビーイングに関するフィードバック」が横行するのか? 端的に言えばフィードバックスキルがないからです。具体的な行動についてのフィードバックをする、ということはフィードバックをするリーダー自身に力量があって、かつそれを形式知として言語化できるということが求められます。
    - そのデータから、統計的に残酷なほどにはっきりと出ているのは、「慕われるだけのリーダー」でも「恐れられるだけのリーダー」でもダメで、両者を高次元でバランスさせているリーダーこそ、良いリーダー だということです。
    - 多くの人が誤解しているのですが、リーダーシップは「嫌われる」ことと表裏一体の関係にあります。/// なるほど確かに「変革を主導した志士」として、いずれ劣らぬリーダーシップを発揮したという点で共通しているのですが、一方で別の共通項があることにも、すぐに気づくはずです。  そう、全員暗殺もしくは処刑されているのです。  つまり 「殺したいほど憎い」と多くの人に思われていた ということです。/// リーダーとして高いパフォーマンスを挙げようと思うのであれば、どこかで周囲から寄せられる「ネガティブな感情」について、受け入れるかどうかはともかく、少なくとも存在を認めた上で無視する一種の 「鈍感力」 が必要なのです。
    - 結局わかったのは 「一番先に話し始めた人」 だということです。  集団が形成されて、その中で一番先に話し始めた人が、リーダー格になっていくのです。一番先に話した人のことを周囲の人は、より知的で、エネルギーに溢れ、人格が優れていると考える傾向があります。人の認識の歪みをバイアスといいますが、一番先に話し始めた人に対して人はポジティブなバイアスを持ってしまうのです。
    - リーダーがいつも上機嫌であれば、メンバーは悩みごとの相談もしやすいはずです。悩みごとを早めに共有することは大きなトラブルを未然に防ぐことにつながるでしょう。  あるいはちょっと思いついたアイデアを口に出してみるかもしれません。不機嫌そうなリーダーの前で荒唐無稽なアイデアを口に出せばどんな叱責を受けるかわかりません。  結局のところ、 上機嫌なリーダーが率いるチームではメンバー相互間、あるいはメンバーとリーダーとの間での情報量が増加する のです。
    - プロジェクトリーダーにも、同じ覚悟が必要だと思います。 プロジェクトにおいて起こったことは、常にプロジェクトリーダーである自分に責任がある ということです。もちろん、メンバーの些細なミスや知識不足、判断力不足に起因するトラブルの場合、そのメンバーを叱責したい気持ちもわかります。しかし実際は、知識不足・判断力不足を見越して、仕事上の注意を促せなかったリーダーである自分のミスだと思うべきなのです。
    - トラブルが起こって思わずメンバーを叱責しそうになった時などは「ああ、今まさに俺の脳は迂回プログラムに乗っ取られつつあるなあ」と、自分を第三者の視点から客観視してみるのです。そうすることで不思議と落ち着きを取り戻すことができますから、ぜひ試してみてください。
    - トラブルのときはそうはいきません。先述した通り、人間の脳には緊急時に理性を迂回して本能的に反応するシステムが組み込まれています。だからこそ、トラブルのときにどう対応できるかにリーダーが本質的に有している人格が表れてくるのです。

全30件中 1 - 10件を表示

著者プロフィール

1970年、東京都生まれ。慶應義塾大学文学部哲学科美学美術史学専攻、同大学院文学研究科美学美術史学修士課程修了。電通、ボストン・コンサルティング・グループ、コーン・フェリー等で企業戦略策定、文化政策立案、組織開発等に従事した後に独立。現在は「人文科学と経営科学の交差点で知的成果を生み出す」をテーマに、独立研究者、著作家、パブリックスピーカーとして活動。現在、株式会社ライプニッツ代表、世界経済フォーラムGlobal Future Councilメンバーなどの他、複数企業の社外取締役、戦略・組織アドバイザーを務める。

「2023年 『新装版 外資系コンサルが教えるプロジェクトマネジメント』 で使われていた紹介文から引用しています。」

山口周の作品

  • 話題の本に出会えて、蔵書管理を手軽にできる!ブクログのアプリ AppStoreからダウンロード GooglePlayで手に入れよう
ツイートする
×