Project Managementに役立つナレッジ

PM/PMOコンサルタントとして成長するために日々インプットしたことをアウトプットするブログです。

スモールウィン

■スモールウィンとは

  • 小さい部分における、ささやかな成功のこと。
  • 人間は基本的に変化を嫌う生き物なので、相当に良い条件が揃った時以外は、一気呵成に大きな変化を実現するのは難しい。

■スモールウィンの探し方

最も効果が上がることをやる。これによりリーダーがメンバーから信頼を得られる。

  • 最も悪い状況になっている「場所・箇所・部分」
  • 最も簡単に改善できそうなところ
  • 最も困っている人を助けること

■スモールウィンを積み上げる

成果を称賛することでチームの士気を高める。メンバーが主体的に動きたくなる状態を作る。

できる(CAN)→やりたい(WANT)→やるのが楽しみ(ENJOY)

■プロジェクトマネジメント

  • プロジェクトスケジュールにおいて1か月に1つ小さな目標を設定する。それをクリアしたらチームでお祝いする。
  • プロジェクトにおいて多くのメンバーが感じるペインを発見したら積極的に解決する。(無駄なミーティングがあれば無くす、冗長な報告があれば統合するなど)
  • 日々のミーティングなどでもできたことを心から称賛する。うわべだけの称賛は相手に伝わり白けてしまう。

人を動かす力

■人を動かす力とは

人々に物事を実行させる力

■人を動かすプロセス

  • ありたい姿を定義する
  • 状況を分析する
  • 基本スタンスを定める(どんな力を使うのか)
  • アプローチを考える(どのように力を使うのか)
  • 実行する

■力の源

  • 公式の力(役職、権限、予算権など)
  • 個人の力(専門性、経験、信頼、人となり)
  • 関係性の力(人の力を利用する、巻き込む、派閥)

■人が動くメカニズム

  • 合理的判断(得、メリット)
  • 感情価値観(好き、共感、粋)
  • 生物的本能(深層心理)

■それぞれの力が有効な状況

  • 公式の力は、迅速な判断が必要な時。
  • 個人の力は、公式な力がない人が人を動かしたい時。
  • 関係性の力は、応援者を増やしたい、反対者を減らしたい時。

■影響力の武器

  • 返報性(ギブアンドテイク)
  • 社会的証明(みんながやっているから正しいはずだ、行列が出来ているから美味しいはずだ)
  • 好意
  • 権威
  • 希少性
  • コミットメントの一貫性
  • 非言語コミュニケーション(視覚、聴覚)

■プロジェクトマネジメントへの応用

  • プロジェクトオーナーおよびマネジメントレベルへは定期的にプロジェクトの状況を報告して、宿題が出されたら適切に対応して信頼を得ておく。
  • 合わせて、プロジェクトのQCDのうち最も大事にしていることや必達の事項も常に確認しておく。
  • プロジェクトで課題が発生した場合に、どうしてもプロジェクト内で解決できない場合はプロジェクトのQCDを変更する必要がある。
  • 合併などスケジュールが決まっているのであれば納期(D)、法改正対応などスコープが減らせないならスコープ・品質(Q)は必達としてQCDを再設定した案を策定する。
  • 反対されそうなステークホルダーには事前にしっかりとプロジェクトの意義や計画変更の妥当性を説明して根回しをしておく。
  • プロジェクトオーナーおよびマネジメントレベルに対して「これまでご報告してきたとおり」「プロジェクトオーナーおよびマネジメントレベルとっても失敗できないプロジェクトであり必達事項は遵守できる計画を策定」「〇〇部や〇〇さんにもご理解を得ている」などを伝えて計画変更の承認を取り付ける。

リーダーシップ

■リーダーシップとは

自己の理念や価値観に基づいて、魅力ある目標を設定し、またその実現体制を構築し、人々の意欲を高め成長させながら、課題や障害を解決する行動。

■リーダーの定義

  • 付き従う者がいること
  • 信頼がない限り、従うものはいない

■リーダーシップの3要素

行動=能力×意識

 行動:ビジョンを打ち出す、夢を語る、正しく伝える、考えさせる

 能力:決断力、説得力、問題解決能力

 意識:熱心、明るく前向き、誠実、謙虚、オープン、強い責任感

■目指すリーダーの姿の例

  • ビジョンを示し、チームメンバーを共感させ、ゴールに導いていく人
  • 豊富な知識・経験があり、自身とチームの視点・視座を変えて物事の本質をとらえられる人
  • 明るく優しく、自信にあふれ、物怖せず、謙虚で学ぶ姿勢を常に持っている人

■目標を実現するためのステップ

  • 目標を立てる(成功基準を明確化し振り返り評価ができる状態にする、目標の意義を腹落ちする)
  • チームメンバーに目標に共感してもらう(メンバー個人が大事にしている価値観を意識して目標をわかりやすく伝える
  • 計画を立てる(6W1Hで具体的に計画する、メンバーに計画させる場合はエンパワーメントの考え方でメンバーに少しだけ難易度が高い課題を課す、計画はメンバーが作る、必要に応じて支援する)
  • 計画を実行する(まずメンバーに任せる。当初の計画通りに進んでいるなら進捗管理のみを行い、計画と乖離した場合はリーダーが介入して軌道修正をする)
  • 不測の事態が起きた場合は、まずは事態を収拾して(リーダーに結果責任があるという自覚)、今後に向けた改善をする。(リーダーの見落としであれば謝罪、個人の責任追及ではなく組織の構造的な問題がないかを確認する)
  • 振り返りを行う(KPTでできたこと、できなかったこと、今後挑戦したいことを明らかにする)

■プロジェクトマネジメントへの応用

  • プロジェクトの目標を明確に立て、PM自身がその目標を腹落ちする。
  • チームメンバー1人1人の価値観や性格を意識して、目標を腹落ちしてもらえるように説明する。
  • メンバー自身が計画、実行を行いコミットメントと自己効力感(自信)を高めて自律的に動けるチームを作る。
  • リーダーは通常時は過剰に介入しない。計画どおりに物事が進まない場合や不測の事態が起きた場合は介入して問題を解決する。
  • 1 on 1や振り返りを定期的に行い、うまくいったこと・成長したことを共有することで自己効力感(自信)を高める、うまくいかなかったことがあれば今後どうすれば良いかを考える。

 

ファシリテーション

ファシリテーションとは

  • ファシリテーションとは、「会議やミーティングを円滑に進める技法」のこと。
  • 具体的には、参加メンバーの発言を促しながら、多様な意見を瞬時に理解・整理していき、重要なポイントを引き出しつつ、議論を広げ、最後には議論を収束させ合意形成をサポートする、一連の行動。

ファシリテーションのポイント

  • 事前に議論になりそうな論点を想定しておく(品質・コスト・納期・体制など)
  • 冒頭に会議の目的、背景、今日のゴールを伝える
  • 発言者の話に耳を傾ける
  • 発言が論点なのか意見なのかを仕分ける
  • この場で議論する論点かを仕分ける
  • 議論を広げてある程度出尽くしたら収束させる(意見をカテゴライズして結論を導く)
  • 会議の終わりに決まったこととアクションアイテム・担当者・期限を決めて共有する

ファシリテーションの場でのテクニック

  • 枕詞を付けて話をしてもらいやすくする(例えばで良いのですが・・・、1つあげると何でしょうか?など)
  • オープンクエスチョンとクローズドクエスチョンを意識する
  • 自然な気持ちを乗せて、相手の言葉をリフレーズ(おうむ返し)すると共感してもらえる
  • 相手の言葉を受け止めて、議論を前に進める方向に導く。ただ誘導尋問はしない。相手の気持ちを置き去りにしない。

■プロジェクトマネジメントへの応用

ファシリテーターがチームメンバーが話しやすくするための工夫をする。

  • 発言しやすい雰囲気をつくる
  • 発言したことを否定せず、発言してくれたことを賞賛する
  • 意見を要約して全員がわかるようにする
  • 発言したそうにしている方、トピック的に発言して欲しい方に対して意見を求める
  • 声の大きい人や権力のある人だけが発言することのないように意識する

 

 

 

 

クリティカルシンキング

クリティカルシンキングとは

  • クリティカルシンキングとは、経験や直感だけに頼らずに、客観的な視点で分析し、論理的・構造的に思考し、問題を解決する力。
  • 客観的な視点で考えた内容を周囲の人に納得感のある形で伝える力。
  • これにより、計画立案や問題解決そして意思決定の基盤・技術を築くことができる。

ロジカルシンキングとの違い

  • ロジカルシンキングは論理的に物事を構造化して考えること。「前提」から結論を出すなど論理的に正しく考える力。
  • クリティカルシンキングは「前提」を疑うこと。
  • 例えば「ウチのメイン顧客層の高齢者が電子クーポンを使ってくれない(事象)のは、高齢者はスマホが使えないからだ(思考の前提)、よってクーポンは紙で配った方が良い(結論)」は論理的には正しい。
  • しかし、「そもそもクーポンの内容が高齢者にとって魅力がないのでは?」「高齢者の定義は?スマホでPayPayを使っている高齢者もかなりいる印象だけど本当にその前提はファクトなの?」という批判的な思考(クリティカルシンキング)をすることで本当に解くべきイシューを発見できる可能性がある。

■プロジェクトへの応用

  • 問題が発生すると何が課題でどうすれば解決できるのかを思考することに集中してしまう。
  • プロジェクトの目的に立ち返って、本当に解決すべき課題なのかから冷静に考える。
  • プロジェクトの目的とは関係ないのであれば、然るべき部門や他のプロジェクトに引き続ぐことが解決策になる場合もある。

 

ネゴシエーション

ネゴシエーションとは

  • 利害関係がある2者がお互いの意見を主張して、妥結点を決めるプロセス。
  • 勝ち負け(Win-Lose)を決める交渉だけではなく、お互いが譲れないことや守りたいことを開示して落とし所を決める(Win-Win)の結論を心がける。
  • 同じものや事象に対しての希望のように見えてもお互いが「価値」と感じるものが異なることがある。お互いが守りたい「価値」を交換できるような提案が出来るとうまくいく。

ネゴシエーションのプロセス

  • 状況を客観的に理解する。(論点、ステークホルダーBATNA
  • 相手の視点で考える。(感情、規範、利害、相手の立場)
  • 自分のミッションを明確化する。
  • 交渉を進めて決着に導く。(感情への配慮、納得してもらうための規範、利害の整理、どのような場で交渉するか)

ネゴシエーションにおけるポイント

  • 交渉は準備が9割
  • 積極的に準備すること(自分のニーズ、相手の立場・強み・ニーズ・価値観、シナリオシミュレーション、想定問答)
  • 目標は高く設定して安易に妥協しないこと
  • 事前に次善策を考えておく。そうすれば交渉が決裂しても良いという強気の姿勢で交渉に臨める。
  • 心を穏やかに持つ。背筋を伸ばし、相手の顔を見て、大きな声で話す。
  • 相手の話に耳を傾けること(相手が何を大事にしているのかを見極める)
  • 誠実であること
  • 自己開示すること
  • 交渉相手と協働すること
  • 自分から質問、提案することで主導権を得る。
  • 相手が話したそうな内容を引き出す質問をする。
  • 相手のプライド、自尊心に訴える。相手がこうありたいという自分になれると感じてもらう。
  • 状況を冷静に俯瞰して見る、相手のゆさぶりや交渉をゲームと捉えて「その方法で来たか」「であればどうやって返すか」と冷静に考える。
  • 相手を説得するのではなく(相手は変えられない)、相手にわかりやすく説明することに注力する。(自分の行動を変える)
  • 自分の負担はそれほどではないが相手にとってはメリットが大きいと思われる選択しを譲歩カードにする。
  • 最後は相手に決めてもらう。自分が決めたのだからと覆したりできなくなる。
  • 議事録やメールでエビデンスを残す

■交渉術

  • 二分法(イエスかノーの二者択一を迫る)
  • アンカリング(最初に極端な数字を提示し、それを基準として意識させる)
  • グッドコップ・バッドコップ(強硬な態度を取る人、好意的な態度を取る人の2人で交渉する。または1人2役を演じる)
  • タイムプレッシャー(相手のデッドラインギリギリで条件を提示して合意を迫る)
  • サンクコスト(交渉に費やしてきた時間や労力を無駄にしたくないという心理)
  • 最後のおまけ要求(合意の直前・直後にちょっとしたおまけを要求する)
  • ドア・イン・ザ・フェイス(大きな要求を断らせたのち、小さな要求を承諾させる)
  • フット・イン・ザ・ドア(小さな要求を受け入れさせ、徐々に要求レベルを引き上げていく)

■プロジェクトマネジメントへの応用

  • 交渉において相手が求めていることが何なのかを理解する。
  • PMが守るべきはプロジェクトのQCD。
  • 例えばQCDのうち、今期のコスト削減が最も重要なのであれば、優先順位の低い一部のスコープを来期にスライドすることで今期のコストを減らせればお互い納得した結論になる。

AI導入プロジェクト

■AIとは

大量の知識データに対して、 高度な推論を的確に行うことを目指したもの。

■AI導入のポイント

  • 解くべきイシューを考え設定する。(AIに何をさせたいのか?)
  • そのためにはどのようなデータが必要なのか?
  • それらのデータをどうやって集めるのか、更新し続けるのか?

■AI導入プロジェクトの特徴

  • 企業が保有するデータは多岐に渡り、AIによる新たな価値を作るためにはそれらのデータを組み合わせる必要があることが多い。
  • そのためステークホルダーが多く、各部署への説明・理解や部署間の円滑な調整が重要な要素になる。
  • 必要なデータを集めて使えるデータにしなければAIを導入しても効果が薄い。
  • ビジネスの目的は顧客に価値を提供すること。AIはあくまで手段である。
  • イシューが予測・分類といったAIの得意領域なのか、新たな価値提供や省力化など必ずしもAIを使う必要はないのかを見極める。

■プロジェクトマネジメントへの応用

  • プロジェクト立ち上げ時にプロジェクトの目的と特性、各部署の協力が不可欠であることをステークホルダーに理解してもらう。
  • 各部署から適切な人材をプロジェクトチームメンバーにアサインしてもらう。
  • 業務プロセスをデジタルで完結できるのか、それに必要なデータ項目、粒度、リアルタイム性などを確認して目的が実現できるのかを検証する。

プレゼンを成功させる準備

■プレゼンの「成功」の定義

  • プレゼン後に聞き手が狙い通りに動くこと。人を動かすということ。

■プレゼンの準備

  • 目的を明確化する(何のためにこのプレゼンで人を動かしたいのか)
  • 聞き手を理解する(意思決定者は誰か、その方にはどのような困りごと・課題があるのか、プレゼン前の理解はどの程度なのか)
  • 聞き手に何をどうやって伝えるかを決める(聞き手が感じそうな疑問とその答え、ストーリーライン)

■プレゼンのポイント

  • 基本的に相手が知りたい結論は最初に話す。
  • ストーリーとスライドはシンプルにする。言いたいことを詰め込まない。質問されたら答える。
  • プレゼンの最後にこれから聞き手に何をして欲しいのかを明確に伝える。

■プレゼンに役立つフレームワーク

  • PREP(結論[Point]・理由[Reason]・具体例[Example]・再度結論[Point])
  • AIDMA(認知・注意[Attention] 、興味・関心[Interest]、欲求・欲望[Desire]、記憶[Memory]、行動[Action])

■プロジェクトマネジメントへの応用

  • プロジェクトのキックオフミーティングはプロジェクトメンバーを始めステークホルダーにプロジェクトの目的や意義、遵守すべきマイルストーンなどを理解してもらう重要なプレゼンと言える。
  • 私たちは何を行うのか、なぜ行うのか、どうなりたいのか、具体的にどうやっていくのかなどを、わかりやすく、熱意を持って伝え腹落ちしてもらう。
  • みんなが自分事化できずやらされ仕事になるプロジェクトは失敗する確率が高く、前向きにプロジェクトをスタートすることが重要。

プロジェクトマネジメントのポイント

■プロジェクトの定義

  • 独自の取り組みを期限を設定して行う活動。
  • 通常業務や期限がない仕事はプロジェクトではない。

■プロジェクトとの難しさとは

  • 業務内容(前例がない仕事のためリソースプランニングが難しい)
  • 期限(期限が決まっていて遵守する、期限に追われる難しさ)
  • メンバー(モチベーションの維持、向上が難しい)

■プロジェクト開始前の準備

  • プロジェクトのゴール、つまり目標と期限を定めてしっかりとステークホルダーと合意しておく。
  • メンバーにしっかり腹落ちしてもらい、プロジェクトに参画する意義、成長機会、どれくらい何を頑張れば良いかを理解してもらう。
  • 社内外のステークホルダーを特定して、各ステークホルダーと何をどのようにコミュニケーションするのかを定めて合意しておく。
■プロジェクト開始後の段取り
  1. タスクをヌケモレなく洗い出す。
  2. 担当者を明確にする。
  3. 適切に期限とマイルストーンを設定する。
  • 各チームメンバーとコミュニケーションを取りメンバーが動きやすくチームになれるようにする。
  1. 1on 1の実施(話を聞く)
  2. 中間目標を作る(スモールウィンで達成感)
  3. メンバーの強みに合わせた役割分担(貢献実感を持ってもらう)

■プロジェクト中のトラブル対応

  • リスク管理を行い事前にバックアッププランを作っておく。
  • 課題が発生したらプロジェクトの目的に立ち返り対応策を考える。(このプロジェクトで実施するべきことなのか?など)
  • どうしても解決できない場合はQCDへのインパクトを整理して変更要求を挙げて合意を取る。

例)スコープを減らす

  要員を追加する

  期限を伸ばす

■プロジェクト実施後の活動

  • 振り返りを行う。
  • KPTフレームワークを使い次のプロジェクトに残す資産を作る。
  • 振り返りを行うことで各メンバー個人の経験、引き出しも増える。

■良いプロジェクトチームとは

  • チームの雰囲気が良い、ギスギスしていない。
  • メンバーがプロジェクトの目的を腹落ちしてやりがいを持っている。
  • メンバー感が相互に信頼している。

免責事項

免責事項

当ブログからリンクやバナーなどによって他のサイトに移動した場合、移動先サイトで提供される情報、サービス等について一切の責任を負いませんのでよろしくお願いします。

当ブログのコンテンツについて、可能な限り正確な情報を掲載するよう努めています、誤情報が入り込んだり、情報が古くなっている場合があります。当ブログに掲載された内容によって生じた損害等の一切の責任を負いかねますのでご了承ください。

 

Pros/Cons分析

■Pros/Cons分析とは

  • いわゆるメリット・デメリットのこと。
  • ProsとConsは表裏一体になることが多い。
  • 分析後に自動的に結論が出る訳ではなく、整理したProsとConsを見て自分が大事にしていることや組織の方向性(コスト削減が最重要など)と照らして意思決定する。

■プロジェクトマネジメントへの応用

  • 課題解決のソリューションが複数ある場合にPros/Cons分析を行うことが多い。
  • 評価軸はQCDへの影響やリスク、実現可能性、ステークホルダーに与える影響など課題の特製ごとに設定する。
  • 評価自体はフラットに行わないと恣意的なものになり誤った意思決定を下す恐れがある。
  • 一方、PMであればどれを選ぶのか、なぜならばという解をもってステークホルダーと合意形成していることが重要。

 

 

機長症候群

■機長症候群とは

  • 機長症候群とは、優秀なリーダーに反論できずにメンバーが議論や反論を止めてしまった結果、組織にとって好ましくない結果を招くことを指す。
  • 名前の通り飛行機の機長に成功実績と権威があったため、副操縦士が自らの思考を止めて、機長に従い飛行機が墜落を招いたという事例から名付けられた。

■プロジェクトマネジメントへの応用

  • 過去に実績もあり優秀なPMであっても、自分ですべて決めてしまうPMは要注意。
  • 通常時は問題はないが、タスク量が増えた場合などはボトルネックになり、普段からメンバーに任せていないためメンバーにタスクを委任できない。
  • PMOなど第三者がPMに対して意識付けすると良い。「このプロジェクトは〇〇さんがPMなので安心ですが、長期的な視点でメンバーの育成をするためにもぜひメンバーと議論して意思決定をするプロセスにしましょう」のように伝える。
  • 優秀なPMであっても間違えることはある。メンバーがおかしいと感じても「〇〇さんが言っているんだから大丈夫、自分の考えが浅いだけだ」だと思い発言せず、後から言えば良かったと吐露されたことがあった。

問題解決

■問題とは

  • 売り上げが5%落ちた、という事象は問題ではない。
  • あるべき姿(ToBe)と現状(As-Is)とのギャップが問題。
  • 目標が売り上げ20%アップだったときに15%のギャップがあることが解決すべき問題である。

■問題解決のステップ

4つのステップで考える。

  1. What(問題の明確化)
  2. Where(問題箇所の特定)
  3. Why(原因の追求)
  4. How(解決策の立案)

■問題解決で陥りやすいポイント

  • 問題がどこにあるのかの原因分析(Where)をする際は『打ち手』から考え始めず、まずは『結果』を分解して問題を絞り込む。
  • 考えられる原因(=仮説)を見つけたら必ず検証する。思い込み、決めつけをしない。
  • データ分析をする際には目的をもって行う。無目的に行うと時間を浪費してしまう。

■因果関係の落とし穴

原因の追究(Why)を行う際には因果関係を誤認しないよう以下の点に注意する。

  • 直観による判断(検証してファクトを確認する)
  • 第3因子の見落とし(ジュースとアイスクリームの売り上げに相関関係があるのではなく、第3因子である”気温”とこれらの商品の売り上げに相関関係がある など)
  • 因果の取り違え(コストが安いからトップシェアなのではなく、トップシェアなのでスケールメリットを活かしてコストが安い)
  • 最後の藁(たまたま最後に起こったことや目立った事柄を原因と誤認すること)

以下の条件を満たした場合のみ因果関係があると言える。

  1. 時間的順序が正しいこと
  2. 相関関係が存在すること
  3. 第3因子が存在しないこと

■プロジェクトマネジメントへの応用

  • 「タスクが計画より遅延している」という問題が起きた場合は、以下のような切り口で分析して問題箇所(Where)を特定する。
  1. タスク量(分母)は増えていないか
  2. 要員(分子)はアサインされているか
  3. 生産性(タスク量÷要員数)は想定した値に届いているか

例)特定チームのタスク量が計画比1.3倍になっていた。

  • 問題個所が特定出来たらなぜその問題が起きたかを分析する。

例)ユーザー部門から細かいリクエストがあるたびに担当者が受け入れてしまいスコープが肥大化していた。(=スコープクリープ)正式な追加要件ではないため追加予算が確保できず要員不足に陥っていた。

  • なぜなぜ分析を行い真因を分析する。

例)ユーザー部門は正式にリクエストを挙げると変更管理手続きが必要となり手続きにかかる手間が面倒だと思い担当者に直接依頼した。

⇒担当者は良かれと思い対応しており、チームリーダーには報告していた。

⇒チームリーダーも正式に対応すると変更管理手続きが必要となり手続きにかかる手間が面倒だと思いプロジェクトマネジャーに報告していなかった。

  • 仮説(変更管理手続きが必要となり手続きにかかる手間が面倒)が正しいかを検証する。

例)変更管理手続きを確認すると、追加コストが1万円の場合も1億円の場合も必要な手続きは同じであり、少額の変更要求の場合は手続きの負担の方が大きいことが判明した。

  • 解決策(How)を立案する。

例)コストが100万円未満の場合はプロジェクトマネジャー決裁で簡易的な手続きで変更要求を挙げられるように変更管理手続きを改定した。ただし、ユーザー部門からの要求の場合はユーザー部門が起票すること、少額であっても追加予算を必ず確保することをプロセス化した。

ジャムの法則

ジャムの法則とは

  • ジャムの法則とは、検討できる選択肢が増えると逆に選択が難しくなるという法則のこと。
  • スーパーマーケットの売り場でジャムの種類を6種類と24種類置くと、6種類の方が売れ行きが良いという事例がある。
  • 居酒屋の「日替わり定食」も選択肢を狭めてすぐオーダーしてもらうことで意思決定を早めて売上をアップするための工夫。

■プロジェクトマネジメントへの応用

  • ミーティングや意思決定の場では論点は多くても3つ程度にする。
  • 多すぎると議論が発散してしまう。
  • たくさん論点がある場合は別のミーティングを開催するか、論点自体を絞り込む。