🐳
田中 志（のぞみ） Tanaka Nozomi
🖋

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

感じたこと

  • 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（時間内にできる）
‣
マイルストンはゴールへの線上にあり、状況に左右されず、「何」にフォーカスしており、時間軸の上に平均的に分散していること
‣
未来完了系の目標を書く、メモにしておくというのはよくあるゴール設定方法
‣
Amazon：プレスリリースからサービス開発を始める
‣
ボクシング村田選手：未来日記
‣
ステップ2: 対象範囲
‣
スコープを定義するときには、何が対象内かだけではなく、何が対象外かも明記しておく
‣
成果物に関しては3要素から定義しておく
‣
成果の形状
‣
受け入れ基準：ハードであれば色、大きさ、機能、重さ。サービスならば時期、提供機能、パフォーマンス、不具合率など
‣
受け入れプロセス：中間成果についてもプロセスを定義。マイルストンに組み込み
‣
ステップ3: 利害関係者
‣
ステークホルダーマップをプロジェクト立ち上げ前／初期に作成しておく
‣
影響力／力関係が一軸、もう一軸にチーム／自身が受ける影響度をとり、個人または組織をマップする
‣
本プロジェクトに対するポジネガ、それぞれの個人や組織の関係性、協力関係を中に記載しておく
‣
作成にあたっては以下3点を注意
‣
社内に閉じず、社内のステークホルダーも踏まえたマップとする
‣
肩書と力関係を混同しない
‣
印刷しない
‣
対立がある人には、認知・利害・感情いずれかにコンフリクトがあるはず。早めにアラートを上げて対策を練る
‣
ステップ4: 阻害要因
‣
プロジェクトを進める上で代表的なリスクを事前に洗い出す
‣
プロジェクトゴールの理解のズレ
‣
プロジェクトスコープの拡大または変更
‣
プロジェクト予算の削減
‣
スケジュールの変更
‣
協業パートナーのスキル不足
‣
導入予定の新技術の未成熟
‣
プロジェクトオーナーの変更
‣
ステークホルダーの抵抗
‣
外部環境の変化
‣
リスクの量は、チームが目指す「あるべき姿」と「現状」のギャップに比例する
‣
リスク管理プロセスに乗せる
‣
認識（Identify）：最終目標を脅かす阻害要因を洗い出す
‣
評価（Assess）：リスクが顕在化する発生可能性と影響度で重み付けする
‣
計画（Plan）：優先順位の高いリスクから対応策と担当者、期限を決める
‣
監視（Control）：リスクが計画通りに、軽減していることを随時確認する
‣
対応オプションとしては、リスクは放置せず、常に能動的に対応をする
‣
回避（Avoided）：複数の選択肢があれば、リスクの低い選択を行う
‣
経過観察（Controlled）：発生可能性を随時確認し、監視することによって驚異を管理する
‣
受容（Assumed）：予め計画に織り込み、現実のものとなった場合は、策定した対応策を実施する
‣
転嫁（Transferred）：契約歌詞や専門家へのアウトソーシングなどによって、責任を他者に分担する
‣
フェーズ2・Design（デザイン）：リーダーとして自由に、自信ある旅程を描く
‣
ステップ5: 資源見積もり
‣
見積もりを失敗しないためには、以下4つに留意すること
‣
手法：トップダウン／係数モデル／ボトムアップ、どれでやるか。トップダウンは概算、ボトムアップは詳細
‣
前提：クライアント側が持っている前提に対する認識の共通化
‣
仮説
‣
コンティンジェンシー：洗い出したリスク一覧をベースに策定
‣
チームが大規模になると全員が少しずつバッファを積む。各タスクに見積もられたバッファを一元管理し、その消化率も含めて見える化することで安定したプロジェクト管理を実現する
‣
その前提として、バッファを開示しあえる信頼関係の構築が重要
‣
ステップ6: 体制構築
‣
肩書ではなく役割を定義し、体制図に書き込む
‣
RAM（Responsibility Asignment Matrix、責任分担表）を作成し全員で共有しておく
‣
R：Responsibility（実行責任）
‣
A：Accountability（説明責任）
‣
C：Consult（相談対応）
‣
I：Inform（情報提供）
‣
リーダーとは異なる強みを持つサブリーダーを備えることでチームとしては強くなる
‣
ステップ7: 作業設計
‣
プロセス設計にある5つのポイント
‣
IPO（Input→Process→Output）：各ワークに必要なInputを定義し関連付ける。
‣
5W1H：各アクションについて担当者にいつまでに・何を・どのように等を説明し、なぜそれを行うのかのWhyも合わせて伝える
‣
スキルレベル：メンバーの習熟度に合わせたタスクの渡し方
‣
依存関係とマイルストン：分割したタスクごとの前後関係・依存関係を明らかにし、マイルストン化する
‣
1W & 1P：1つのタスクは1週間以内に分割する。1つのタスクに1人乗担当者を割り当てる
‣
納期を左右する「最長経路（クリティカルパス）」を特定する
‣
CCPM（Critical Chain Project Management）：プロジェクトスケジュール上のボトルネックに対して、リソース製薬を考慮し、短納期でのスケジュール遵守を目指した管理手法
‣
マルチタスクの排除（タスクの優先順位付け）
‣
フォワードローティング（前倒し作業計画）
‣
バッファマネジメント（コンティンジェンシー管理）
‣
バックワードプランニング（最終ゴールからの逆日程算出）
‣
クリティカルパス上のタスクが遅延するとプロジェクト全体が遅延するため、リソースを集中して投下する必要がある。特に注視して観察するべき
‣
ステップ8: 規範設計
‣
品質向上と生産性向上に役立つルールであれば採用し、チームの規範とする
‣
設定のためには「目的の明確化」「設計」「周知」「運用」「見直し」のループで進める
‣
特に以下のようなルールはありうるやも
‣
出社／退社時間、遅刻／早退時の連絡ルール
‣
座席表／連絡先（メールアドレスなど）
‣
成果物のネーミングルール及び格納場所
‣
会議体のルール（時間、場所、議事録など）
‣
進捗確認シート
‣
成果物のテンプレート（要件定義書、設計図など）
‣
問題発生時の管理ルール（データベースなど）
‣
プロジェクト辞書（用語説明など）
‣
新しいルール・行動習慣を身につけるには、平均66日の継続が必要（EJSP、2009年7月）
‣
「もし○○になったら、XXする」とうIf-Then Plansという代替行動定義ルールのほうが成功確率が高い
‣
フェーズ3・Drive（推進）：チームとして納得し、意思決定は透明に
‣
ステップ9: 変更管理
‣
計画の変更は以下5つのステップで
‣
文章化：起票は要件変更を希望しているユーザー自らが起票する
‣
要件の認識のズレを防止し、
‣
責任の所在を明確にするため
‣
要望理解：申請された変更要求を、背景や理由の妥当性について関係者で議論（Change Control Board）
‣
影響調査：特にクリティカルパスに影響しないかを重点的にチェック
‣
受け入れ判断：Noであれば代替案と共に
‣
再見積もり・作業指示：変更を反映した再見積もり及び役割分担を定め、プロジェクト内に周知する
‣
ステップ10: 組織変更
‣
道具的コミュニケーション（Instrumental Communication）だけではなく自己充足的コミュニケーション（Consummatory Communication）も行わないと、人間関係・信頼関係が構築されていかない
‣
チームは形成期（Form）→混乱期（Storm）→秩序期（Norm）→活動期（Perform）の順序でグループからチームになっていく（タックマン・モデル）
‣
混乱期に行うべきは1on1で、不満や不安にも心を向けていくことで、チームになっていく
‣
状況対応リーダーシップ（Situational Leadership）も活用してみる
‣
援助的行動と指示的行動の高低で4象限でマッピング
‣
指示的リーダー→コーチ型リーダー→支援型リーダー→委任型リーダーの順で、メンバーのレディネスに対応して選択する
‣
ステップ11: 問題解決
‣
MECEやPPM、SWOTなどのフレームワークにとらわれるな
‣
要素分解・構造化のスピードを上げる、思い込みや経験を超える、多様なメンバーで焦点を合わせるなどのメリットもあるが、課題認識を固定させてしまう可能性大
‣
問題の根本原因は、考え抜くことでしか把握できない
‣
ステップ12: 意思決定
‣
評価軸と評価プロセスを明確に定義しておく
‣
更にそれらをチームに共有し、周囲を巻き込むことを大切に
‣
情報が完全に集まったうえでの判断はプロジェクトにおいては不可能。どこまでいっても決断

引用メモ