kaeken(嘉永島健司)のTech探究ブログ

主に情報科学/情報技術全般に関する知見をポストします。(最近は、特にData Science、機械学習、深層学習、統計学、Python、数学、ビッグデータ)

(更新中)『プロジェクトのトラブル解決大全 小さな問題から大炎上まで使える「プロの火消し術86」』まとめ

Amazon.co.jp: プロジェクトのトラブル解決大全 小さな問題から大炎上まで使える「プロの火消し術86」 eBook : 木部 智之: Kindle Store

目次

  • 第1章 最初の準備――9割の人がスタートでつまずく
  • 第2章 状況把握――効率的な現場検証と聴取の方法
  • 第3章 原因特定とリカバリプラン策定――真因特定、優先順位、体制見直しの手順
  • 第4章 リスタートを切る――人心掌握、ルール変えのポイント
  • 第5章 リカバリ遂行――炎上中のプロジェクト管理は「3つだけ」
  • 第6章 メンバーモチベーション管理――モチベーションは「上げる」のではなく「戻す」
  • 第7章 リーダーシップとメンタリティ――新たな信頼を築けるリーダーとは
  • 第8章 クロージング――次につなげる「振り返り」から盛大な「打ち上げ」まで

序章

  • 本書は主にPM向けトラブル対応術
  • 炎上にはパターンがある
  • PMBOKはあくまでもガイドにすぎないので、具体的な炎上対策ではない
  • 大炎上のおおもとは小さな火種

  • QCDのうちQ品質に振り回される

  • 具体的な火消し技法を活用すれば、事前・事後対策になる

【第1章】最初の準備 - 9割の人がスタートでつまずく

01 9割の人が怠るファーストステップ 「腹をくくる」

  • 他責ではなく自分事として取り組む

02 最初に読み込むべき 「重要資料4点セット」

  • プロジェクト計画書
  • 体制図
  • 課題管理表
  • 進捗報告資料

03 プロジェクト関係者を把握する「体制図分析」

  • 人数・チーム数
  • リーダー・キーマン
  • 指揮命令系統

04 現場に入る前に作るべき「100の質問

  • PMBOK10カテゴリそれぞれ10個の質問(合計100個)を事前に考える

The 10 Project Management Knowledge Areas - (PMBOK)

05 原因と対策の仮説を立てる 「1人決断タイム」

  • 初期段階ではPMがひとりで仮説を立てる

06「懐刀」を手に入れる

  • 信頼できる参謀・右腕を見つけ出す

【Column】 面従腹背タイプに足をすくわれる

  • 表面的に協力的だが、実際裏切る方には注意

【第2章】 状況把握 - 効率的な現場検証と聴取の方法

07 現場初日に見るべき「現場検証10のポイント」

  • (オフィスの場合)ホワイトボード
  • (オフィスの場合)机の資料と物
  • (オフィスの場合)会議室の数と広さ
  • (オフィスの場合)座席の配置
  • 会議の内容
  • メンバーの年齢構成
  • 服装
  • 昼食時間の行動
  • 会話の量
  • 勤務時間

08 「課題表のレベル」を評価すればプロジェクト状況がわかる

  • メンテされていない課題表と、実態の差をチェック

09 的確な聴取手法「タテヨコ・ヒアリング」

10 ヒアリングの「3つの落とし穴」を避ける

  • ヒアリングした内容は「事実」ではなく「報告」なので、実際に正しいかどうか確認
  • ヒアリングする相手の性格や心理状態を考慮
  • ヒアリングする相手のポジションを考慮して偏らない

11 キラークエスチョン「それはなぜですか?」を駆使する

  • 回答内容を鵜呑みにせず、その理由や原因などを深掘りする

12 メンバースキルを可視化する 「複数人5段階評価」

  • メンバーのスキル評価は、複数の側面から実施

13 現状把握用「わかっていること/いないことフレームワーク

  • QCDやPMBOK10カテゴリなどで、既知と未知を区別して整理する

14 犯人探しの代わりにやるべき 「犯人活用法」

  • 犯人探しは避ける。冤罪だったりキーパーソン外しのリスクがある。配置換えや対話で状況改善の可能性あり

【Column】ピリッとしていない現場をどうするか

  • 炎上しているのに緊張感のない現場は危険。メンバーの意識やリーダーの意識を高める必要あり

【第3章】原因特定とリカバリプランの策定 --- 真因特定、優先順位、体制見直しの手順

15 「問題」「原因」 「対策」を切り分けて整理する

16 ヌケモレを防ぐ「原因特定フレームワーク&マトリクス」

17 対策は「制約ゼロベース思考」で検討する

18 課題の優先度が一目瞭然「優先順位付けマトリクス&グラフ」

19 やらないこと、「捨てるべき10%」を決める

20 体制見直しポイント「リーダーの置き場」と「責任の所在」

21 トラブルプロジェクトではむやみに人を「増やさない」

22 トラブルリカバリ用のスケジュール立案 「逆算3ステップ」

23 計画は見積りの「−10%」で組む

24 9割の人が間違えている「正しいバッファーの置き方」

25 定例会議をすべて見直す 「3つのチェックポイント」

26 炎上の火を大きくする「スペキャラ」を見つけよ

27 プロジェクトを進めるには、判断ではなく「決断」する

【Column】静けさに包まれたプロジェクトは「怪しい」

【第4章】リスタートを切る --- 人心掌握、ルール変えのポイント

28 リカバリのキックオフ会議でやりがちな「NG発言」

29 キックオフ後に行なうべき 「立食懇親会」

30 社内外に向けた「イメチェン説明会」を実施

31 「社内報告のシンプル化」で実利と期待感をUP

32 「チームの法律」となる新ルールを決める

33 「動線」からオフィスの座席を決める

34 「クイックミーティング・スペース」を作る

35 「オフィス快適化」で生産性を上げる

36 変えるべきでないものを見極める「労力と心理的抵抗の天秤」

【Column】「それで本当にできるの?」というダメ質問

【第5章】 リカバリ遂行 --- 炎上中のプロジェクト管理は「3つだけ」

37 炎上中のプロジェクト管理は「3つだけ」

38 作業管理、作業計画のポイント「1タスク5営業日以内」

39 進捗管理のポイント「森を見て、木も見る」

40 課題管理のポイント「4つの穴」をふさぐ

41 プロジェクト状況は「グラフ化」する

42 毎朝30分の会議で「ミニ軌道修正」をする

43 弱いチームは「均質化と効率化」で戦う

44 強いチームを作る「3つの劇薬」

45 社内定例を危険にさらす「お客様との会議」に注意

46 炎上プロジェクトの会議にないものは「議論」

47 ムダを省いて信頼感を上げる、会議の「30秒リセット」

48 イヤでも締め切りを守らせる 「報告と質問」

49 悪い報告が上がるようにする「4つの受け身」

50 「1日2回のパトロール」が小さな火種を消す

51 マイクロマネジメントの「やり時」と「やめ時」

52 情報伝達のスピードを上げる「中継ポイント管理」

53 「とにかく書く」 コミュニケーションでミス防止

54 PDCAは円ではなく「マトリクス式」で実践する

55 自分の仕事の邪魔をさせない裏技 「上への報連相

56 カレンダーを見ながらの「未来⇔現在妄想」で精度を上げる

57 コントロールできない「人の問題」は諦める

58 本当に忙殺されたらやるべき「一旦ストップ&効率化」

59 「怪しい」と思った時の現地現物

【Column】 凡事徹底

【第6章】メンバーモチベーション管理 --- モチベーションは「上げる」のではなく「戻す」

60 モチベーションは「上げる」のではなく 「戻す」

61 最も手厚くフォローすべきは「平均層+キーメンバー」

62 「ガス抜きヒアリング」では約束をしない

63 フェーズの切れ目に入れる 「休息のメリット」

64 フェーズ別 「モチベーションアップ・リスト」

65 対人ストレス解決には「腹を割る会」しかない

66 メンバーのメンタル不調を防ぐべき「本当の理由」

【Column】 すり抜ける「三遊間タスク」にご用心

【第7章】 リーダーシップとメンタリティ --- 炎上を通じて新たな信頼を築けるリーダーとは

67 リーダーは「9割ポジティブ」を心がける

68 「諦めグセ」は言葉に表れる

69 リーダー自身の「支えになる言葉」を持つ

70 倒れる前に駆け込む 「リーダーの逃げ場」を作る

71 うかつに謝れない時の「範囲限定の謝罪法」

72 チームにいい緊張感を持たせる 「厳しさ」とは

73 リーダーは絶対に「走ってはいけない」

74 「まっすぐ立つ姿勢」はメンバーに頼もしさを抱かせる

75 火を消せる指導者は「メンバーの仕事をしない」

76 正しいと思うことを貫くには 「嫌われる覚悟」を

77 リーダーというのは「単なる役割」と割り切ろう

78 トラブル対応は新たな「信頼と飛躍」を秘めたチャンス

【Column】 「デキないリーダー」でも成功することはある

【第8章】 クロージング --- 次につなげる「振り返り」から盛大な「打ち上げ」まで

79 ゴールが見えてきたら 「カウントダウン」を始める

80 メンバーに「言葉で感謝」する

81 苦しかった時間を失敗ではなく「成功体験にチェンジ」

82 炎上を資産にする「2方向リフレクション」

83 最後のミッション「組織へのフィードバック」

84 チェックリストを「マズい秘伝のタレ」にしてはいけない

85 怠ってはならない「盛大な打ち上げ」

86 もしまたプロジェクトでトラブルが起きたら

おわりに

その他整理

プロジェクトの把握
 プロジェクト計画書
 体制図
  人数、チーム数
   メンバースキルの可視化
    設計
    プログラミング
    業務スキル
    マネジメント
    リーダーシップ
  リーダー、キーマン
   懐刀になる人
   トラブルメーカー
    対応時は影響力を無視しない
  指揮命令系統
 課題管理表
  スケジュール、担当者
  課題収集プロセス
  優先度判断
   重要度、緊急度、難易度、効果、コスト、時間
 進捗報告資料
 
 質問項目
  PMBOKの知識体系ベース
  QCDベース
  仮説を立てる
   トラブルの原因は?
    問題、原因、対策
     あるべき姿と現実のギャップ
     マトリクスで検討
      QCD、機能、開発フェーズなど
  タテヨコ
   具体と抽象、類似
  事実の確認
   なぜそう思うのか
    原因は何だと思うか
   推測の場合は判断基準は
    どの資料を見れば確認できるか
  わかっていること、わかっていないこと
   軸毎に洗い出し
    システム調査なら機能毎、など
  できない理由の精査
   どうすればできるようになるのか
    制約を外す方法は
やらないことを決める
 リソースの集中
スケジュールはゴールから逆算
 10%ほどのバッファー(見積もりの-10%で計画)
 バッファーはタスク毎に乗せない
  メンバーからの見積もりは詳しく精査
  スケジュール全体でバッファーを持つ
 1タスクは5営業日以内
  担当者は必須
  複数人での担当になる場合はタスクを分ける
会議
 頻度、議題、参加者が適切か
  議事録、アクションリスト
 議論の活性化
  各自に意見を求める
 準備不足の場合はリスケ
  スケジュールは決める
プロジェクトの意義を共有
チームのルールは守らせる
 都度なぜ守らないか聞いたりして守る雰囲気を作る
最低限の管理
 作業管理、進捗管理、課題管理
  作業遅延
   原因、対策、リカバリ予定日を確認する
  課題
   内容は明確に分かりやすく
   担当者を決める
    連名にしない
   期限を決める
    最低限の日数で
   起票者は担当にしない
朝会
 前日の状況確認
  問題、課題の状況確認
  共有事項確認
 当日の予定確認
 課題表確認
属人性排除
 手順、プロセス定義
 テンプレート用意
 ツールでの自動化
マイクロマネジメント
 期間限定で行う
 確認頻度を上げる
  朝会、夕会
 確認内容を細かく
  数字での進捗確認からタスク内容の確認へ
PDCA
 PDとCAのマトリクスで考える
  計画、実行内容がどうだったか
  改善点をもとにしたアクションプラン
ガス抜きヒアリングでは約束はしない
 課題を理解したので検討する旨を伝える
  共感はするが解決の約束はしない
リーダーシップ
 9割ポジティブ
  諦め癖の言葉に注意
  メンバーと話し合う
 支えになる言葉を持つ
  転ぶときも前のめり
 責任を持つところと持たないところの線引きをしておく
 チームに良い緊張感をもたせる
  メンバーの成果、仕事ぶりに厳しく
  プロジェクト成功のための妥協をしない