外資系コンサルが教える難題を解決する12ステップ プロジェクトリーダーの教科書 [Kindle]

著者 :
  • かんき出版
3.73
  • (5)
  • (9)
  • (6)
  • (1)
  • (1)
本棚登録 : 140
感想 : 8
本ページはアフィリエイトプログラムによる収益を得ています
  • Amazon.co.jp ・電子書籍 (234ページ)

感想・レビュー・書評

並び替え
表示形式
表示件数
絞り込み
  • 根底に「炎上案件に対応できてる俺すげー」感があり、あまり参考にならなかった。

  • 実践的で非常に参考になる本。お勧めされている本も興味深い。

  • ◾︎感想
    PM/課題解決/リーダーシップスキルが学べる本。
    
    PIMBOK等の理論本ではなく、著者が現場から学んだ経験則が多く書かれているため実務で活かせるイメージが湧きやすい。
    デスマーチと呼ばれる修羅場を潜り抜けたからこそ語れる事も多いと感じた。それぞれニーズの違うステークホルダーが混在するプロジェクトにおける人の動かし方等為になるものが多かった。

    小さなチームをリードする立場の人でも、大規模プロジェクトを管理する立場の人でも学べる事は多くある一冊だと思います。

  • 失敗事例が載っていて参考になる。

    バッファのコントロールが大切と思わせる本である。

  • 外資コンサルが教える難題を解決する12ステップ プロジェクトリーダーの教科書

    ■全ての業務はプロジェクト化する
    ・世間には多くの定期が存在しますがプロジェクトマネジメントインスティテュートというプロジェクトマネジメントに関する方法論をまとめている世界的機関では、次のように定義されています。
    ・プロジェクトとは「独自の製品、サービス、所産を創造するために実施される有期性の業務である」。よって、プロジェクト開始にあたっては以下の4点が定義されていなければいけない。
    1.達成すべき明確な目標までの手順
    2.達成するまでに許容された時間
    3.達成するために必要な人員
    4.達成するまでの手順
    ・ここでのポイントは、プロジェクトには「独自性」「有期性」がある、ということです。すべてのプロジェクトは他のプロジェクトとは異なる独自の目的や目標を持ち、またそれらを実現するために許容されているスケジュール(期間)も異なります。 同じ目標であっても3カ月で実現しなければいけないのか、半年間の猶予があるのかによって、その実現アプローチ(手順)、必要な人員のスキル(技術)やリソース(資源)は異なってきます。

    ■プロジェクトと定常業務の違い
    ・プロジェクトと定常業務(ルーティンワーク)では、性質や時間以外にもいくつかの点で違いがあります。
    ・ 両者の違いで注意していただきたいのは、プロジェクトにおいて必要な人材は「流動的」に集められ、その実行手順についても「都度策定」されるということです。
    ・プロジェクトでは、現状と異なる新たな目標=「変革を推進する」ケースが多く、その実現のためには新しい技術や考え方を適用する必要があります。
    ・その際に、リーダーは自社や自部門の人員だけでは不足している知識や技術、経験を補うために外部の専門家やコンサルタントと契約し、混成チームを組成することがあります。 異なる価値観や経験、知識を持つ初対面の人たちと協力し合い、限られた時間内で高い目標を達成することが求められるため、プロジェクトでは、固定的な人員で業務を行う定常業務以上に「チームビルディング(組織運営力)」が必要とされます。
    ・そこでプロジェクトリーダーは、チームに集まったメンバーのスキルや経験を考慮しながら、最適な手順を策定していきます。その際に大切なことは、「誰が『自分たちの船』に乗っているのか」「自分達はどこに向かうのか」「なぜ向かわなければいけないのか」「いつまでに到着しなければいけないのか」ということをリーダーが深く理解し、その道のりを自分の言葉でメンバーに伝えていくということです。
    ・さらにもう一点と点リーダーがプロジェクトを設計する際に考慮すべきは「不確実性」です。 全てのプロジェクトには必ず、以下のような不確実性が生じます。
    └環境変化により、目標や範囲が変更されるかもしれない
    └利害関係者の変更により、要件が変更されるかもしれない
    └導入予定の新技術や新サービスが未成熟かもしれない
    └業績の影響で、予算が途中で大幅に削られるかもしれない
    └チームが想定どおりのパフォーマンスを出せないかもしれない
    ・いくら経験豊富なリーダーが綿密な計画を立てても、必ずこういった「想定外」が起こります。プロジェクトでは「今までやったことのない取り組み」をするわけですから、すべてのプロジェクトは「成功可能性0%」から始まります。プロジェクトデザインとは、言い換えれば「想定外」を最小化し、成功の可能性を0から100%に近づけるための技術であるといってもいいでしょう。






    【第1章 定義フェーズ】
    ■ゴールのないマラソンは走れない
    ・リーダーはプロジェクトを始める前に、「なぜ自分達はこのプロジェクトを行わなければいけないのか」という理由を自分自身で納得し、一緒に走る仲間に説明する必要があります。プロジェクトを取り巻く環境や背景、前提条件、達成したい最終目標及び目的、求められる成果物、実現できた場合の想定効果、予算や許容されているスケジュールなどの制約条件、プロジェクトリーダーは誰が行うのか、チームの体制図などを文書化していきます。
    ・組織のリソース(資源)を使ったプロジェクトは、個人が勝手に始めることはできません。リーダーはチームメンバーに対して、プロジェクトの目的や意義、チームに求められている役割などを説明することができます。
    ・チームビジョンを語るときは、「私の(MY)ではなく、私達の(OUR)という言葉を使って定義するよう心がけましょう。リーダー本人のみならずメンバー全員がワクワクするようなビジョンを掲げることで、プロジェクトへ参加する動機づけを与えて行きます。

    ■急いでいるときほど、じっくり考えろ
    ・実際のプロジェクトでも、リーダーはチームが目指すビジョン、ゴール、目的、目標、標的、マイルストーンを定義していきます。 しかし、実際には最終目標である「ゴール」と
    「目的」が混同されているケースや、手段が目的化されていたり、ゴールを実現するために達成しなければいけない具体的な中間目標が定義されないまま、見切り発車をしてしまっているプロジェクトが多く見られます。

    ■大きなゴールは細分化する マイルストンを設定する
    ・最後にゴール、目標、標的にたどり着くための中間ポイントである「マイルストン(道しるべ)」を設定する際のポイントについて確認しましょう。プロジェクトリーダーはマイルストンの設定およびレビューする際には、以下の4点について注意してください。
    1.ゴール(最終目標)を達成するために通らなくてはならない条件もしくは状態が具体的に定義されていること(正しい例:◯月◯日要件確定、△月△日設計完了など)
    2.状況の変化に左右されないこと(外的環境で変化されない)
    3. 「どのように」達成するかではなく「何」を達成するかが述べてあること(正しい例: 教育対象者一覧完成、テスト研修書受領など)
    4. 時間軸に沿って平均的に分散していること
    ・マイルストンで忘れられがちなのは、「最終目標に向けた軌道修正を行う」ということです。 道しるべを設定するだけでは不十分。上記の4つのポイントを押さえることで、実現可能性の高いプロジェクト計画に変わります。

    ■成功するプロジェクトは終わりから逆算する
    ・Amazon社では、新サービスに着手する時に「逆算思考」を用いている。その代表的な取り組みとして製品ありきのプロダクトアウトの発想ではなく、「顧客の視点」をスタート地点にする為、開発前に「プレスリリース」を作成している。
    ・プレスリリース内容は、サービスの特徴とユーザーにとってどのような便益が得られるのかに焦点が当たっている。プロジェクトキックオフ時に全員でそれを読み、サービスの意義、価値、利用シーン、 Q & A 、ユーザーマニュアルまで想定する。
    ・ここでのポイントは自分たちの目指すべきビジョンやゴールを美辞麗句ではなく、具体的な利用シーンやユーザーマニュアルに至るまで、期待されるユーザーの行動変容や享受できるメリットは何なのか、なぜこのプロジェクトを立ち上げなければいけないのかを鮮明にイメージできるレベルまで落とし込んでいるということです。それによって、チームは自分たちがやるべきことを明確に理解し、実行することに集中できます。

    ■「やらないこと」を宣言せよ!
    ・「何を対象とするか(スコープ・イン)だけではなく「何を対象としないのか(スコープ・アウト)」をシンプルな言葉で明確に定義する必要があります。
    ・「何をやらないか」を明確に定義するためには、全体像が見えている必要があります。

    ■横槍が入らないように関係者を可視化する
    ・プロジェクトにおいて、利害関係者はプロジェクト推進の「アクセル」にも「ブレーキ」にもなります。リーダーは「アクセル」と「ブレーキ」の場所や使い方を知らずして、車(チーム)を運転することはできません。
    ・ここでプロジェクトを滞りなく進めるために役立つ、利害関係者を可視化するフレームワーク(「利害関係者マップ」)を紹介します
    1.利害関係者が社外にもいることを認識する
    2.力関係と肩書きを混同しない
    3.利害関係者マップは印刷しない

    ■プロジェクトチームの体制図を構築する際は肩書きだけではなく、必ず役割を簡潔に明文化するようにしましょう
    ・役割を定義する際には、「RAM(責任分担表)」を作成します。 「タイトル別」にそれぞれのタイトル(肩書)の名前、主な役割、管理対象、主な成果物、参加する会議体などを記述します。
    ・また、1つの作業に複数の組織(部署、会社など)が共同で関わる場合には、もう一段ブレークダウンし、責任分担を明確にした「RACIチャート」と呼ばれるフレームワークを活用します。RACIチャートは、作成する際には若干骨が折れますが、作業のチャージレート(時間あたりの工賃)が異なるメンバーが混在するプロジェクトの予算管理や工数管理をするうえで有効です 。
    ・リーダーはRAMを作成して満足するのではなく、そこに定義されている各メンバーが自分の果たすべき役割と責任を正しく認識しているか、それを遂行するのに十分なスキルと経験を持っているかを必ず確認しましょう。




    ■大きな仕事は小さく分ける
    ・プロジェクトは「プロセスの連続」と言い換えることができます。プロセスとは「物事を進める順序、過程、工程」を指します。すなわち、「時間軸に沿った作業の固まり」だと考えてください。
    ・プロセスとはインプット(資源)をアウトプット(成果)に変える取り組みです。 各作業は、プロセスを通じて作成されたアウトプットを、次の作業のインプットとしてつないでいきます。
    ・例えばカレールーを作る一連のプロセスは次の四つの作業から成り立ちます。 1.具材カット、2.具材炒め、3.香辛料投入、4.ルー煮込み。
    ・さらに、それぞれの作業は「インプット」「プロセス」「アウトプット」で整理することができます。このように成果を生み出すプロセスを分解した作業群を「作業分解図」もしくは「 WBS」と呼びます。
    ・WBSを作成する際にぜひ注意いただきたいポイントは、「1W &1P」 です。何やら呪文のように見えますが、「1つのタスクには最長1週間以内に分割する」「1つのタスクには原則、1人の担当者を割り当てる」ということです。PMBOKを含め多くのプロジェクトマネジメント関連書籍では「タスクの分割は最長2週間以内が望ましい」と推奨されていますが、私の感覚では、それではリスクが高いと感じます。
    ・開始から終了までの一連のプロセスで最も時間がかかる最長経路(クリティカルパス)を示す必要がある。クリティカルパス上のタスク(作業)が遅れるとそれはプロジェクト全体のスケジュール遅延に直結します。言い換えれば、クリティカルパス以外のプロセスでの遅れはそれぞれのフロート(バッファ)内であれば吸収できるということです。
    ・よって、プロジェクトを遅延なく運営するためには、クリティカルパスを重点的に管理し、リソースを優先的に配置します。納期短縮が要請された場合は、クリティカルパス上の作業にリソースを追加投入することで圧縮できるかを検討する必要があります。



    【12ステップのまとめ】
    【定義フェーズ】
    ■最終目標のポイント
    ・リーダーはプロジェクトのゴール(最終目標)を自分の言葉で「SMART」に語ろう。ゴールを達成するとどんなビジョン(理想像)が見えるのか、メンバーがワクワクするような夢を描こう。
    ■対象範囲のポイント
    ・リーダーは「何をやるか」だけではなく、「何をやらないか」を定義しよう。プロジェクトの成果の三要素(形状、基準、プロセス)を定義し、マイルストンに組み込む。
    ■利害関係者のポイント
    ・利害関係者はプロジェクトの「アクセル」と「ブレーキ」になる。リーダーはできる限り早いタイミングで、プロジェクト内に潜む「コンフリクト(対立)」を洗い出す。上がりすぎた期待は下げ、下がりすぎた失望は上げるように、期待値を管理する。
    ■阻害要因のポイント
    ・リーダーは、起きてしまった「問題管理」よりも、起きる前の「リスク管理」を優先する。「発生可能性」と「影響度」で優先順位を決め、メリハリのついたリスク解決に注力しよう。

    【デザインフェーズ】
    ■資源見積りのポイント
    ・資源見積りにおいて、安易な「誠意」「遠慮」はデスマーチを招く。リーダーは「コンティンジェンシー(不測の事態)」を見込んだ根拠のある見積りを作成し、「バッファマネジメント」を通じて、チームを最終ゴールまで導く。
    ■体制構築のポイント
    ・プロジェクトでの完全無欠の「ドリームチーム」を作ることは不可能。リーダーはメンバーの弱みではなく、強みに目を向ける。体制図を作って満足するのではなく、一人一人の役割と責任を明確にし、肩書きにこだわらずに適材適所に人材を配置する。
    ■作業設計のポイント
    ・リーダーは IPO(インプット・プロセス・アウトプット)を定義し、メンバーのスキルレベルを考慮しながら作業設計を行う。クリティカルパス(最長経路)を重点的に管理することで、スケジュール遅延を未然に防ぐ。
    ■規範設計のポイント
    ・守られないルールでは意味がない。リーダーは、全員が「納得できる」「シンプル」なルールを作る。その中でも、会議体のルール設計はプロジェクトの生産性に大きく影響する。会議への参加人数のバランスに注意して、会議体を設計しよう。
    【推進フェーズ】
    ■変更管理のポイント
    ・変更管理はリーダーの胆力が試される。変更要求の重要度と緊急度を見極め、感情や疲れに左右されずに冷静に判断を下す。NO(却下)と言うだけなら誰でもできる。 なぜ、無理なのかを相手に論理的に伝え、代替案を提案するよう心がけよう。
    ■組織運営のポイント
    ・リーダーは混乱を通じて、単なる寄せ集めである「グループ」を真の「チーム」へと成長させる。権限を積極的に手放し、メンバーへ「エンパワーメント」することで、チームの底力を引き出す。
    ■問題解決のポイント
    どんなに慎重に定義やデザインをしても、プロジェクトでは「問題」が発生することは避けられない。リーダーは「思考の枠組み」である「フレームワーク」に振り回されないように注意しながら、「問題の根本原因は何か」を、積極果敢に探っていく。
    ■意思決定のポイント
    ・いくら技術が進歩しても 、AI は「判断」はできても責任を伴う「決断」はできない。リーダーは、実効性のある決断をするために、「評価軸」と「評価プロセス」を明確に定め、共有することで周囲を巻き込んでいく。

  • 自分用の備忘録。

    ■本書の位置づけ
    ・タイトルの通り、「教科書」。プロジェクトマネジメントのいろはが、再現性を伴った形で記されている
    ・IT関連のプロジェクト等、①目に見えるoutputを求められ、②リスクの極小化を特に求められるプロジェクトを想定している
    ・本書の良さは、教科書的な記述と著者の経験に基づいたリアリティある既述のバランスにあると思う。各章の冒頭の「CASE」と末尾の「武器としてのリーダーシップ」が好き。あと、本のコンパクトさ。

    ■僕なりの読み方
    ・複数の立場に立って読む:マネージャー/メンバーの一員/パートナー・プリンシパル/自分で自分を律する者(=タスク管理の書)
    ・タスクに落とし込む時、一度この本のやり方に従ってみるとよい。読まずにできるまで、真似てみる。ただし、本書で想定されているケースと異なり、抽象度の高いテーマの場合、必ずしも良いとは言えない方法があるので、その場合は目的に応じてアレンジすること(変更管理をネガティブなものとみなす、等)。

全8件中 1 - 8件を表示

中鉢慎の作品

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