記録#252 『プロジェクトリーダーの教科書 外資系コンサルが教える難題を解決する12ステップ』
外資系コンサルが教える難題を解決する12ステップ プロジェクトリーダーの教科書
- 作者: 中鉢慎
- 出版社/メーカー: かんき出版
- 発売日: 2018/07/19
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
感じたこと
- PMBOKの内容、改めて勉強してみようかなあ。PMI会員。。。
- 普段無意識で行っていることがたくさん散りばめられていて、それが3Dモデルとしてまとまっており、納得度が高い
- あらゆるプロジェクトで、Defineをしっかりするようになれば、職場のハピネスは高まるだろうなぁ。
内容
- すべての業務がプロジェクト化する
- 常に定まっている、定常業務はどんどん減っていっている。プロジェクト化の時代。
- プロジェクト:独自の製品、サービス、所産を想像するために実施される有期の業務。 よって以下4つが定義されている必要。
- 達成すべき明確な目標
- 達成するまでに許容された時間
- 達成するために必要な人員
- 達成するための手順
- プロジェクト vs 定常業務の差異
- 性質:独自性 vs 反復性
- 時間:有期性 vs 継続性
- 目的:変化に対応 vs 複雑さに対応
- 人材:流動的 vs 固定的→チームビルディングが都度必要になる
- 手順:都度選定 vs 既存
- リスク:不確実性 vs 確実性
- 環境変化により、目標や範囲が変更されるかもしれない
- 利害関係者の変更により、要件が変更されるかもしれない
- 導入予定の新技術や新サービスが未成熟かもしれない
- 業績の影響で、予算が途中で大幅に削られるかもしれない
- チームが想定通りのパフォーマンスが出せないかもしれない
- 姿勢:柔軟性と機動性 vs 秩序と一貫性
- プロジェクトの成功を阻む4つのハードル
- 要望・ニーズを的確に捉えていない、達成すべきゴールが明確ではない
- 非現実的なプロジェクト計画、フェーズごとの責任者が分断、リスク対応不十分
- 役割分担が不明確、メンバー/チーム間のコミュニケーション不全、スキル不足
- 現場に丸投げ、当事者意識の希薄さ、変更管理/意思決定プロセス不全
- D3アプローチに基づく12ステップに分解し、VUCA時代のプロジェクトに対応したい
- D3アプローチでは、PMBOKと違い、「いくら精緻な計画を立てて厳密なコントロール・管理をしても、プロジェクトにおける問題は必ず起きる」と捉える
- フェーズ1・Define(定義):ゴールのないマラソンは走れない
- ステップ1: 最終目標
- プロジェクト憲章をまとめる
- ゴール:最終的に達成したい事柄
- 目的:達成したい理由
- ビジョン:ゴールを達成したことによる理想像
- 目標:標的:ゴールを構成する要素
- マイルストン:種類と時間軸で細分化された道標
- 優れたビジョンはチームが逆境にあるときにメンバーが諦めずに前を向けるような力を与える。不格好でも、自分の言葉でビジョンを繰り返し伝えるべき。
- 目標はSMARTに設定すべし
- S:Specific(具体的な)
- M:Measurable(測定可能な)
- A:Achievable(達成可能な)
- R:Result Oriented(結果思考な)
- T:Time Bound(時間内にできる)
- マイルストンはゴールへの線上にあり、状況に左右されず、「何」にフォーカスしており、時間軸の上に平均的に分散していること
- 未来完了系の目標を書く、メモにしておくというのはよくあるゴール設定方法
- プロジェクト憲章をまとめる
- ステップ2: 対象範囲
- スコープを定義するときには、何が対象内かだけではなく、何が対象外かも明記しておく
- 成果物に関しては3要素から定義しておく
- 成果の形状
- 受け入れ基準:ハードであれば色、大きさ、機能、重さ。サービスならば時期、提供機能、パフォーマンス、不具合率など
- 受け入れプロセス:中間成果についてもプロセスを定義。マイルストンに組み込み
- ステップ3: 利害関係者
- ステップ4: 阻害要因
- プロジェクトを進める上で代表的なリスクを事前に洗い出す
- プロジェクトゴールの理解のズレ
- プロジェクトスコープの拡大または変更
- プロジェクト予算の削減
- スケジュールの変更
- 協業パートナーのスキル不足
- 導入予定の新技術の未成熟
- プロジェクトオーナーの変更
- ステークホルダーの抵抗
- 外部環境の変化
- リスクの量は、チームが目指す「あるべき姿」と「現状」のギャップに比例する
- リスク管理プロセスに乗せる
- 認識(Identify):最終目標を脅かす阻害要因を洗い出す
- 評価(Assess):リスクが顕在化する発生可能性と影響度で重み付けする
- 計画(Plan):優先順位の高いリスクから対応策と担当者、期限を決める
- 監視(Control):リスクが計画通りに、軽減していることを随時確認する
- 対応オプションとしては、リスクは放置せず、常に能動的に対応をする
- 回避(Avoided):複数の選択肢があれば、リスクの低い選択を行う
- 経過観察(Controlled):発生可能性を随時確認し、監視することによって驚異を管理する
- 受容(Assumed):予め計画に織り込み、現実のものとなった場合は、策定した対応策を実施する
- 転嫁(Transferred):契約歌詞や専門家へのアウトソーシングなどによって、責任を他者に分担する
- プロジェクトを進める上で代表的なリスクを事前に洗い出す
- ステップ1: 最終目標
- フェーズ2・Design(デザイン):リーダーとして自由に、自信ある旅程を描く
- ステップ5: 資源見積もり
- ステップ6: 体制構築
- 肩書ではなく役割を定義し、体制図に書き込む
- RAM(Responsibility Asignment Matrix、責任分担表)を作成し全員で共有しておく
- R:Responsibility(実行責任)
- A:Accountability(説明責任)
- C:Consult(相談対応)
- I:Inform(情報提供)
- リーダーとは異なる強みを持つサブリーダーを備えることでチームとしては強くなる
- ステップ7: 作業設計
- プロセス設計にある5つのポイント
- 納期を左右する「最長経路(クリティカルパス)」を特定する
- ステップ8: 規範設計
- 品質向上と生産性向上に役立つルールであれば採用し、チームの規範とする
- 設定のためには「目的の明確化」「設計」「周知」「運用」「見直し」のループで進める
- 特に以下のようなルールはありうるやも
- 出社/退社時間、遅刻/早退時の連絡ルール
- 座席表/連絡先(メールアドレスなど)
- 成果物のネーミングルール及び格納場所
- 会議体のルール(時間、場所、議事録など)
- 進捗確認シート
- 成果物のテンプレート(要件定義書、設計図など)
- 問題発生時の管理ルール(データベースなど)
- プロジェクト辞書(用語説明など)
- 新しいルール・行動習慣を身につけるには、平均66日の継続が必要(EJSP、2009年7月)
- 「もし○○になったら、XXする」とうIf-Then Plansという代替行動定義ルールのほうが成功確率が高い
- フェーズ3・Drive(推進):チームとして納得し、意思決定は透明に
- ステップ9: 変更管理
- 計画の変更は以下5つのステップで
- 文章化:起票は要件変更を希望しているユーザー自らが起票する
- 要件の認識のズレを防止し、
- 責任の所在を明確にするため
- 要望理解:申請された変更要求を、背景や理由の妥当性について関係者で議論(Change Control Board)
- 影響調査:特にクリティカルパスに影響しないかを重点的にチェック
- 受け入れ判断:Noであれば代替案と共に
- 再見積もり・作業指示:変更を反映した再見積もり及び役割分担を定め、プロジェクト内に周知する
- 文章化:起票は要件変更を希望しているユーザー自らが起票する
- 計画の変更は以下5つのステップで
- ステップ10: 組織変更
- 道具的コミュニケーション(Instrumental Communication)だけではなく自己充足的コミュニケーション(Consummatory Communication)も行わないと、人間関係・信頼関係が構築されていかない
- チームは形成期(Form)→混乱期(Storm)→秩序期(Norm)→活動期(Perform)の順序でグループからチームになっていく(タックマン・モデル)
- 混乱期に行うべきは1on1で、不満や不安にも心を向けていくことで、チームになっていく
- 状況対応リーダーシップ(Situational Leadership)も活用してみる
- 援助的行動と指示的行動の高低で4象限でマッピング
- 指示的リーダー→コーチ型リーダー→支援型リーダー→委任型リーダーの順で、メンバーのレディネスに対応して選択する
- ステップ11: 問題解決
- ステップ12: 意思決定
- 評価軸と評価プロセスを明確に定義しておく
- 更にそれらをチームに共有し、周囲を巻き込むことを大切に
- 情報が完全に集まったうえでの判断はプロジェクトにおいては不可能。どこまでいっても決断
- ステップ9: 変更管理