Chapter 08

【アンチパターン】プロジェクト管理

たなかなた
たなかなた
2022.12.13に更新
このチャプターの目次
  1. 口八丁手０丁（Blowhard Jamboree）
  2. 分析地獄（Analysis Paralysis）
  3. 文書化地獄（Viewgraph Engineering）
  4. 計画倒れ（Death by Planning）
  5. 取り越し苦労（Fear of Success）
  6. 横紙破り（Corncob）
  7. 知的暴力（Intellectual Violence）
  8. 理性の欠落（Irrational Management）
  9. 誇大営業（Smoke and Mirror）
  10. 暴走プロジェクト（Project Mismanagement）
  11. あとは野となれ（Throw It over the Wall）
  12. 泥縄（Fire Drill）
  13. お家騒動（The Feud）
  14. 人食いメール沼（E-mail Is Dengerous）
  15. 資産防御
  16. グラウンドホッグデー
  17. メール駆動アーキテクチャ
  18. クッキー型
  19. 蜂の巣にされた死体

口八丁手０丁（Blowhard Jamboree）

  • 発生
    • 不十分な情報で廃れた情報を持ち出す自称業界通の意見を、管理職や意思決定者が鵜吞みにし、技術に関する決定を下す
  • 回避
    • 内部にエキスパートを持って報道や記事の真偽念実を見分けてもらう。内部にいなければ育てる。
  • 参考文献

分析地獄（Analysis Paralysis）

文書化地獄（Viewgraph Engineering）

  • 発生
    • デベロッパが説明用スライドや企画文書などに凝り過ぎて、ソフトウェア開発への着手が遅れる
  • 回避
    • デベロッパにプロトタイプの構築を命ずる。本来の役割を全うできるのと同時に、顧客との認識齟齬を文書を介さずとも解消する事ができる
  • 参考文献

計画倒れ（Death by Planning）

  • 発生
    • 多くのプロジェクトは過剰な計画によって失敗する。計画過剰は以下の要因で発生する。
      • 箱入り娘（一度作成した計画を変更もせずに安心しきっている状態）
      • 微細主義（納期を確実に厳守するために計画の新規作成や微調整を事細かに行ってる状態）
  • 回避
    • 何をいつ完成させるかを明確にしつつ、進捗管理の中で成果物の完成度や下流に引き継がれたかなどを評価し、日程計画を調整する
  • 参考文献

取り越し苦労（Fear of Success）

  • 発生
    • プロジェクトが成功しそうな時に一部の人が過剰な心配をし始め、それがメンバーに伝染し、不合理な行動を招く
  • 回避
    • プロジェクトの終わり近くで管理職が成功を宣言する事が重要。（個人の不安を対処するには個人面談や個人指導が効果的）
  • 参考文献

横紙破り（Corncob）

  • 発生
    • 破壊的な言動を行う人物によってソフトウェア開発チームに問題をもたらし、最悪の場合は企業全体に波及する（横紙破りな言動をする人を評価する組織体制が問題になる事もある）
  • 回避
    • 戦技レベルの解決では、その人物に責任を転移したり、問題を正式に議題化して組織として否決する
    • 戦術レベルの解決では、管理職が矯正的に1on1を行ったり、ヘッドハンターに斡旋して円満退職を促す
    • 戦略レベルの解決では、横紙破り集団を作って自己破壊を招いたり、窓際をあてがう
  • 参考文献

知的暴力（Intellectual Violence）

  • 発生
    • 理論や技術や流行語に通じている者がその知識をひけらかして、会議の席で他の人々を馬鹿にしている
  • 回避
    • 知識や技術に差があるという多様性を認めた上で、フランクかつ積極的に教え合う組織を作る
  • 参考文献

理性の欠落（Irrational Management）

  • 発生
    • 重要な問題に関して、議論ばかりしていて結論を出さない。管理者による管理能力が欠けている。
  • 回避
    1. 問題を自覚し助けを求める
    2. 開発スタッフを理解する
    3. 明確な短期的目標を提供する
    4. 目的を共有する
    5. 工程の改善可能箇所を探す
    6. コミュニケーションを促進する
    7. コミュニケーションのメカニズムを管理する
    8. 例外的な現象のみを管理する
    9. 効果的な意思決定テクニックを適用する
  • 参考文献

誇大営業（Smoke and Mirror）

  • 発生
    • デモ用システムは重要な営業ツールだが、デモ用システムを実製品と思い込ませる。「ホラ吹きウェア（Vaporware）」とも呼ばれる。
  • 回避
    • エンドユーザの期待を管理する（倫理的にも、信頼持続的にも）
  • 参考文献

暴走プロジェクト（Project Mismanagement）

  • 発生
    • 計画の時点でアーキテクチャの定義を正しく行っておらず、技術計画や品質管理活動などが疎かになっている結果、実装しづらい設計になっていたり、コードの校閲や検査がたまにしか行われていない
  • 回避
    • 「管理の視点」「質の視点」「プロジェクトエラーの視点」で、正しくリスク管理を行う
  • 参考文献

あとは野となれ（Throw It over the Wall）

  • 発生
    • プログラムは存在しているが、ガイドラインとなるドキュメントが存在しない（読み解くにはリバースエンジニアリングしないと分からない）
  • 回避
    • 管理者のための概説資料と、デベロッパのための概説資料を用意する
  • 参考文献

泥縄（Fire Drill）

  • 発生
    • 問題が発生してから慌てて対策に講じている状態。こういう状態になると品質低下を招いたり、納期に間に合わせるためにデスマーチが発生したりする。
  • 回避
    • 内的なプロジェクト環境を作って、チームメンバーを集めてアジャイル開発に切り替える
    • 外的なプロジェクト環境を作って、ステークホルダを集めて緊急事態だと認識させた上で、外部環境活動を行う
      • 内と外で分ける事によって、それぞれを干渉させないようにする
  • 参考文献

お家騒動（The Feud）

人食いメール沼（E-mail Is Dengerous）

  • 発生
    • 複雑でセンシティブな話題をメールで取扱ってしまい議論の水準（知的・文化的・技術的）が低くなる
  • 回避
    • メールと対面を的確に使い分ける。メールを使う際は以下に注意する。
      • 対立衝突、批判、機密情報、品位に欠ける話題、法に触れる恐れのある声明
  • 参考文献

資産防御

  • 発生
    • 選択誤りの恐れによる、選択や決定の放棄や先延ばし
  • 回避
    • 最終責任時点まで決定を下さない。物事の決定が実現できるように開発チームをサポートする。
  • 参考文献

グラウンドホッグデー

メール駆動アーキテクチャ

クッキー型

  • 発生
    • プレゼンテーション作成者が、スライドを余計な装飾で埋め尽くそうとする
  • 回避
    • 1つのスライドで全てを表現しようとせず、複数のスライドに分けてアイディアを表現する
  • 参考文献

蜂の巣にされた死体

  • 発生
    • スライドがプレゼンテーション発表者のメモでしかない状態
  • 回避
    • プレゼンとは「視覚」「聴覚」の２つの情報チャンネルがあるので、うまく使い分ける
  • 参考文献