【読了】プロジェクト難題解決の12ステップ

§0:はじめに

▼プロジェクトを失敗させるためのCSF
①立ち上げ前:ニーズを深堀しない、目指すべきゴールを曖昧にしておく
②計画時:プロジェクトリスクを考慮しない、スキル不足、役割分担を曖昧にしておく
③実行時:コミュニケーション不全
④監視中:現場任せにする、変更管理や意思決定のプロセスを整備しない

▼D3アプローチ
①Defineフェーズ:最終目標/対象範囲/利害関係者/阻害要因
②Designフェーズ:資源見積/体制構築/作業設計/規範設計
③Driveフェーズ:変更管理/組織運営/問題解決/意思決定

§1:Defineフェイズ

▼①最終目標

・myではなくourな観点

○ビジョン/目的/ゴール
・ビジョン:ゴールに到達して見たい景色
・目的:ゴールを達成したい理由
・ゴール<目標<標的<マイルストーン

○ゴールのSMART要件
・Specific:リソースを検討するため
・Measureble:到達したかどうか判断するため
・Achievable:実現可能な
・Result-oriented:結果として何が得られるのか
・Time-bound:時間内にできる

○マイルストーンの要件
・ゴールとの整合性
・期間的な分散:特定時期に偏ってないか
・成果物による定義
・外的要因に左右されない

○逆算思考
・顧客視点から始める(開発キックオフ時に、プロジェクトメンバー全員が、サービスの意義、価値、利用シーン、ユーザマニュアル、Q&Aなどを具体的にイメージするため)に、プレスリリースを作成してからサービス開発をしている(Amazon、Microsoft)
・未来完了形で宣言する:「来年1月には○○○○ができるようになっている」

○リーダー自信が成功を心底確信しているか
・無謀≠勇敢

▼②対象範囲

○何でもやるは何もやらないと同じこと
・スコープアウト(やらないこと)を理解可能な表現で明文化する
・スコープ変更には責任者承認を必須にする

○スコープ制限により顧客の期待を裏切らないために
・成果物名称ではなく、達成すべき成果を定義(顧客への真摯な質問により、具体的な背景やニーズや期待を引き出す)する

○成果の3要素
・納品物の形状
・受け入れプロセス(いつ、誰が、どうやって確認し受け入れていくのか)
・受け入れ基準(期待する点、どんな観点で確認するか)

○認識のズレを放置しない
・相手の反応が薄いときは伝わってない

▼③利害関係者

○力のない反対派の意見も聴く
・思わぬところから横槍が入る
・利害関係者は社外にもいる
・肩書と力関係は異なる

○コミュニケーションをデザインする
・利害関係者マップ

○コンフリクト解決の難易度
・認知レベル→利害レベル→感情レベル
・認知レベルなら解決できるが、感情レベルは解決困難

○コンフリクトの解決法
・回避:最悪の選択肢、コンフリクトは必ず存在するため見過ごしているだけ
・強制/服従:感情レベルのコンフリクトに発展する原因になる
・妥協:
・協調:関係性を強める唯一の選択肢

○期待値管理 Expectation Management
・上がり過ぎた期待は下げ、下がり過ぎた期待は上げる
・「ご期待は嬉しいのですが、すぐに大きな成果が上がるわけではありません。まずは、○○までに△△程度の効果が見込めるように進めていきましょう」
・期待が下がり過ぎるとクライアントもメンバーも離れていくため、進捗や課題(原因と対策)の密な共有と相談により、利害関係者を巻き込み直して期待値を上げる

▼④阻害要因

・リーダーになったら「何が起きたら、プロジェクトは最悪な状態に陥るか」を考える

○リスク/問題/課題を区別する
・リスク:潜在的な阻害要因、可燃物
・問題:顕在化した阻害要因、燃え始め
・課題:問題を解消するために自分たちが取り組めること、除去消火(冷却消火や窒息消火はその場でできない)

○リーダーはリスクを否定しない
・リーダーは立ち上げフェイズで、可能な限り有識者を巻き込み、できる限り多くのリスクを識別するべき
・一般的に、リスクの大きさは、As-IsとTo-Beのギャップに比例する
・リスクが少ないということは、深く洞察できていないという証拠

○リスク対応
・すべてのリスクには対応できない
・回避Avoided/経過観察Controlled/受容Assumed/転嫁Transferred

○リスク管理
・対応するリスクにはリスクオーナー(解決責任者)をアサインする
・リスク対応の状況は監視プロセスに載せる

§2:Designフェイズ

・方法論やテンプレを選択するだけでは成功できない
・リーダーの管理スタイル(得意な方法、経験が豊富な方法)、調達できたリソース(メンバのスキルや経験)、プロジェクトの阻害要因により、アプローチ方法を設計する必要がある

▼⑤資源見積

・トップダウンで見積もられた概算スケジュールや工数は、変更不可能な必達要件化する場合が多い
・リーダーが見積もるべきなのは、最短工数だけではなく、バッファ(リスクベース)
・管理のプロとして提示すべき見積もりとは、クライアントにウケる見積もりではなく、自分が責任者として最後までリードできる見積もり

○資源見積で外せないチェックポイント
・アプローチ:どのレベルで見積もりたいのか?
 ・経験ベース(トップダウン、スピード重視)
 ・モデルベース(根拠がある)
 ・WBSベース(ボトムアップ、実現可能性重視)
・前提:既に確定している条件、認識ズレがないか?
・仮説:見積値を算定するために借り置きした値
・バッファ:バッファがないということは、もしリスク顕在化や不測事態(変更要求を含む)が起きた場合、対応する余裕がまったくないということ

○最短工数とバッファを分離して管理する
・ボトムアップなリソースを見積もる際に、担当者から最短工数とバッファを理由付きで教えてもらう
・担当者の信頼を得ないと正直に教えてもらえないので注意:「プロジェクト全体のバッファを統合管理することで、スケジュール遅延の責任と対策(リソース追加や納期延長の交渉など)をリーダーに集中させるため」と話す
・日々の担当者からの進捗報告で、最短工数のとバッファの消化率を個別に報告してもらう

▼⑥体制構築

○役割分担
・肩書だけでなく役割を定義する
・メンバー自身が役割と責任を果たせるだけのスキルと経験を持っているかを確認する
・RAM:責任分担表
・RACIチャート

▼⑦作業設計

○プロセス設計
・ITTO
・5W1H(六何):what→who→whenまで最低ライン、モチベーション低いならwhy、経験不足ならwhere→how
・サポート工数:トレーニング、成果物の中間レビュー、など
・依存関係
・マイルストーン
・粒度:遅延インパクトを減らす(リカバリしやすくする)ため、タスクは1人の担当者が1週間(5営業日)で完了できる量(1W&1P)に分割する

○クリティカルチェインプロジェクトマネジメント(CCPM):制約条件理論に基づくプロジェクト管理技法
・マルチタスクの排除:タスクの優先順位づけ
・フォワードローディング:前倒し作業計画
・バッファマネジメント:コンティンジェンシー管理
・バックワードプランニング:最終ゴールからの逆日程算出

○PMBOK知識エリアの優先順位
・時間がコストに変換されていくのは自然の流れなので、その成り行きを見守る(不足を検知してから対策を検討し始める)だけではプロマネではない
・プロマネが何もしないと、スコープは拡がり、品質は落ち(期待値とのギャップは拡がり)、コミュニケーションは悪化し、リスクは顕在化し、ステークホルダーとの関係は悪化する

▼⑧規範設計

○ルールの目的
・品質の向上
・生産性の向上

○ルールの要件
・シンプル:3個ほど
・守りやすいもの:繰り返し伝える
・メンバーが納得できるもの:ルールの目的をリーダー自身が説明できる

○ルールに関するプロセス
・目的の明確化
・設計
・周知
・運用:見直し

○会議体に関するルール
・生産性向上のために一番有効
・会議に参加しただけメンバーの作業時間は減る
・参加メンバーや会議時間は目的により決める
・代替策を組み込む:会議時間の70%を使ったら継続可否を確認する
・議事録には図を入れる

○習慣化にかかる時間
・21日間でストレスを感じなくなる
・66日間で無意識にできるようになる
・「〜しない」よりも「〜したくなったら、〜をする」をした方が習慣化する

§3:Driveフェイズ

○『巨像も踊る』(ガースナー):CEOとしてIBMを再建(1993/4〜2002/3)
・選択と集中
・実行の卓越性
・顔の見えるリーダーシップの徹底

▼⑨変更管理


○変更要求に対する5手順
①要求の文書化
・口頭ベースで受け付けてもOKだが、必ずメールなどの書面で確認し、相手からの返信をもらう(言った言わない問題を避けるため)
・代理入力は認めず本人入力してもらう(認識齟齬を生むため)
②要求の理解
・CCB(変更管理委員会)が検討する
・要求の背景や理由が、プロジェクト目標と整合していない場合は却下する
③影響調査
・後工程への影響:通常は、追加リリース、新規リスク、などが発生する
・前工程への影響:通常は、「横展開」などのやり直しが発生する
④受入判断
・リソース見積もり時に積んだコンティンジェンシー用バッファの範囲を超えて受け入れるのは危険
・要求を却下する場合は代替案を提示する
⑤再見積と作業指示
・変更作業や再作業だからといって気軽に考えない、むしろ生産性は低くなりがちであることを見込む

▼⑩組織運営

○チームビルディング
・タックマンモデル:Form→Strom→Norm→Perform
・グループがチームへと成長するためには、道具的なコミュニケーション(報連相)だけでなく、自己充足的なコミュニケーション(緊張緩和)も必要
・混乱期を経なければ秩序期には至らない、表面的なコミュニケーションに終始していると、自発的に秩序を形成しようとしない
・混乱期にリーダーがすべきなのは1on1

○メンバーの成熟度Readinessに合わせたリーダーシップ型
・S1:指示型、具体的指示と細かい管理
・S2:コーチ型、方針と質問回答のみ
・S3:支援型、動機づけのみ
・S4:委任型、権限委譲empowerment

○リーダーに必要なコミュニケーション経路の構築
・情報を取りに行きチーム内に共有する
・チーム内で解決できない問題はステコミに伝える
・チームメンバの貢献を人事評価で伝える
・メンバー間を円滑にする

▼⑪問題解決

○網羅志向ではなく仮説志向
・網羅的に情報を集めようとすると時間がかかり、分析にも決断にも時間がかかり、そのうち鮮度が落ちて解決に役立たなくなる
・ひとりの視点でMECEしたり分析したり仮説を建てたりするのではなく、チームメンバーのスキルや経験を活用して、複数の仮説を立てて最善を選ぶ
・仮説で動くのはいいが仮説に固執してはいけない、経験豊富なリーダーは確証バイアスに陥り、自分の仮説を落とし処(結論)と錯覚しがち

○フレームワーク
・分析における要素分解と構造化のスピードを上げる
・バックグラウンドが異なるメンバーの共通言語になる
・経験不足や思い込みによる抜け漏れを防ぐ

○報連相
・事前連絡→途中相談→事後報告
・リーダーはメンバーが報連相しやすい心理的環境を作る

▼⑫意思決定

・リーダーに求められるのは判断ではなく決断(責任を伴う)
・しかし、ひとりですべて抱え込むのが責任ではない
・周囲のアドバイスやサポートを真摯に仰ぐこと

○決定事項の実行可能性は巻き込み度に左右される
・例え妥当な決断を行っていたとしても、意思決定プロセスをメンバーに公開しない場合、メンバーの当事者意識は下がり実行可能性は落ちる
・適切なキーマンを含めていない意思決定は途中で阻害される可能性が高い

○確証バイアス
・自分に都合のいい情報だけを集めて、自己の先入観を補強してしまうこと

この記事が気に入ったらサポートをしてみませんか?