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