リスクマネジメント の履歴(No.2)

• 履歴一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• リスクマネジメント へ行く。
  • 1 (2022-09-25 (日) 13:58:40)
  • 2 (2023-01-18 (水) 14:50:33)
  • 3 (2023-02-01 (水) 13:27:09)
  • 4 (2023-02-03 (金) 10:13:23)
  • 5 (2023-09-04 (月) 10:34:24)

→プロジェクト管理

リスクマネジメント一般†

• 【「スゴ本」中の人が薦める】ITエンジニアなら知ってほしい。プロジェクトを炎上させないマネジメント術を身につける4冊 | レバテックラボ（レバテックLAB） 2023.1
  • 『プロジェクトマネジメントの基本が全部わかる本』は、PM初心者向けの具体的なノウハウがまとまっており、「プロジェクトあるある」の初見殺しの罠は予習できる。なにより、何をどうしなきゃいけないかを、手取り足取り教えてくれる。
  • 『アート・オブ・プロジェクトマネジメント』は、PM経験者向けにお薦めしたい。どのページを開いても上手く回すアイデアが詰まっており、「PMとは何か」の本質的な議論から、何かしらのヒントが得られることを請け負う。
  • 『アジャイルプラクティス』は、PM、チームリーダー、エンジニアにとって、すぐに使える実践的なプラクティス集になる。どういう風に考え、口癖にして、習慣化していくと、上手く回せていけるかが身につく。拾い読みして、良さげなものを取り込んでいくのが効果的だろう。
  • 『PMBOKガイド』は、オールマイティ―の究極の一冊といっていい。その分、抽象的に書かれているため、使い方に注意する必要がある。

• 奇妙な態度で仕様変更に抵抗するとき

• 問題点やリスクの把握を怠ってはいけない 2008.7.24

• 危険察知に鈍感になってはいけない 2008.7.22
  • ↓危険の兆候
  • 見積もり会議やプロジェクト会議を早期に開催できない
  • 状況報告の資料に定量的データがない
  • 状況報告の資料を毎回（毎月）徹夜で作成している
  • 発注先（協力会社など）の状況把握が行われていない
  • プロジェクト内の問題が報告されない（他システムや顧客の問題ばかり）
  • 大規模プロジェクトである
  • 初めての顧客である
  • 初めて取り扱う業務，技術である

• 必要ならプロマネに逆らってでも助けてと叫べ 2007.12.13
  • PMOとして，プロジェクトマネジャの危険信号をどのように見極めればよいでしょうか。筆者の経験上，次の兆候のうち複数があてはまるようだったら要注意です。
    • （1）プロジェクトメンバーがプロマネの指示に納得していない
    • （2）指揮系統を無視して，末端の担当者にプロマネが直接指示する
    • （3）顧客との関係が悪化している
    • （4）メンバーからプロマネへの不平不満や悪口が噴出している
    • （5）協力会社に対して無理難題を押し付けている
    • （6）プロマネが何をしているのか，メンバーが分かっていない
    • （7）プロマネ一人だけが何日も深夜残業や徹夜をしている

• トラブル削減のための原則17箇条 2007.10.25

• PMP試験対策：リスクマネジメント
  • 「事前に分かっているリスク」は、「何らかの準備をする」か「何も準備せず、監視する」のどちらかになるだけで、その違いは優先度による、ということ。
  • 「優先度が高いにもかかわらず、分かっているのに何もしなかった」ことは、決してしないということ。
  • 「このリスク登録簿にないリスクが発生したら、このお金を使う」という予算が、別に割当てられていること（←マネジメント・コンティンジェンシー予備）も重要。
  • リスクは計画プロセスで全て明らかになるものではない。実行段階でリスクが発見されることもあれば、リスクが現実に発生してしまうこともある。
  • 未知のリスクが発見された：リスク分析からのサイクルを回し、影響度・リスク対策とともに報告する
  • 未知のリスクが現実に発生した：迂回策を取り、問題を回避する[p.355:PMBOK]
  • 定性的リスク分析で高優先順位のリスクに対し、数値による等級付けを行う。要は、発生確率と影響度をカネに換算する。定性→定量の順に行うが、一度にする場合もある。

• リスクマネジメントの考え方を知る

炎上プロジェクト／失敗プロジェクト(デスマーチ)への対応†

※ここでは火を噴いてしまったプロジェクトにどう対応するか、についての記事をまとめる。事前対策はプロジェクト管理そのものになるので。 最大にして唯一の対策はそもそもデスマーチを発生させないことであるのは言うまでも無い。

• ｢炎上の火消し｣ができない会社に共通する盲点 | リーダーシップ・教養・資格・スキル | 東洋経済オンライン | 社会をよくする経済ニュース 2022.9
  • 炎上プロジェクトには必ず「人の問題」がある

• なぜプロジェクトが炎上しているのか自分なりに考えてみた - Qiita 2022.9

• 炎上プロジェクト一度は経験すべき？ – プログラマーやめました 2022.8

• 社内の炎上プロジェクトに飛び込みまくって思った事 2021.6

• デスマーチの行進の仕方 2014.3.3

• 山本一郎氏が語る、プロジェクト炎上のメカニズムと鎮火法 2013.4.16

• プロジェクトの遅れを取り戻す方法10選 2008.12.2

• デスマーチ突入時の打開策 2007.11.22
  • いったん冷静になりましょう。そしてミーティング
  • 各スタッフの残タスクを見やすいように整理整頓
  • スケジュール見直し。安易な延期提案はダメ
  • プライオリティの低いタスクを放置しない
  • エンジニアの周りをうろちょろしない

• 火を噴いてからPMOを入れても遅い？ 2008.2.27
  • 火消し部隊を投入しなければならないと気付くタイミングでは，「時すでに遅し」となっている可能性が非常に高いものです。火消し部隊の役目が，プロジェクトを終わらせるための落とし所を模索する活動に変わっていることも多々あります。
  • PMOはプロジェクトの管理事務部隊ではなく，プロジェクトの生産性を向上させるための組織です。プロジェクトの開始当初からマネジメント・プロセスを整備し，プロジェクトを円滑に推進できるように準備することを，世の中のプロジェクトマネジャに推奨します。
  • この考え方は，現場のプロジェクトマネジャだけでなく，組織のマネジメント層の方々が理解しないと，なかなか受け入れられにくい

• デスマーチの構造＠ヨードン 2007.3.2