デスマーチ　第2版　ソフトウエア開発プロジェクトはなぜ混乱するのか

• 

  Maxwell

  4

  笑いごとではないけれど，なぜか笑えてきてしまう

  ソフトウェア開発はとても難しいものです．
  もともとキツいスケジュールでアップアップのところに，想定していなかった技術的な問題，仕様の漏れ，などが出てきてスケジュール遅延の要因となってさらにヒイヒイ言い…，
  そこにお客様から追加仕様や仕様変更が持ち込まれて悲鳴を上げる．．．
  これは追加項目だからと予算が上乗せされても〆切は変わらず，人員増加で乗り切れと言われても，機械でできる作業と違って人を増やせば生産能力が2倍になるわけではない．．．
  今まさにそんなデスマーチの真っただ中にいる（？）身としては，この本に書いてあることにいちいち大きくうなずきたくなります．
  ですが，笑いごとではないのに，この本を読むとなぜかものすごく笑えてきてしまう．．．
  
  デスマーチのまっ最中で時間が惜しい時ほど，この本を読む価値があります．
  デスマーチを解消することはできなくても．
  ちょっとは気持ちが軽くなるかもしれません．
  続きを読む

  投稿日：2013.09.25

  報告する

• 

  dattsu

  トリアージしよう。もっとも大切な要求、課題から手を付ける
  
  【感想】
  　「デスマーチ」をキーワードにして、プロジェクトマネジメントのよもやま話をしていく本。主張は基本的なプロジェクトマネジメント原則と…大差が無いかも。ソフトウェア開発プロジェクトの難しさを理解するために読むとよさそう。書き方はエッセイ的で、メッセージが掴みづらい。既にPMの知見が無いと、難しい。単純にシステム開発プロジェクトについて理解するなら、「システムを作らせる技術」の方が分かりやすい。各章ごとの「まとめ」を読んでから、本文を読んだ方が理解しやすい。勉強のために読むなら、読んだうえで自分で抽象化を試みた方が良さそう。
  
  【本書を読みながら考えたこと、気になったこと】
  　問いを立てて読んだ方が良さそうな本。
  
  ■なぜ、デスマーチが起こってしまうのか
  ・正確に作業量を見積もることが難しい。見積もりより作業量が増えても、納期は後ろに伸びない
  ・時間的、資金的、人的な余裕がない。ソフトウェア開発プロジェクトはビジネスであり、より安く、早いサービスが求められる。市場競争の結果、コンペを勝ち取る際には、他社より少ない予算（人員）、より早いスケジュールでの計画実現を提示できたベンダーが、ソフトウェア開発プロジェクトを受託できる。結果的に、いつもギリギリの状態でプロジェクトはスタートする
  ・失敗が隠される。過去にソフトウェア開発プロジェクトでの失敗があっても、企業は体裁を守るために、できる限りその事実を隠そうとする
  
  
  ■デスマーチに巻き込まれたら、どうすればよいか
  ・トリアージする。優先順位をつけて、対応する。全ての問題に対応しなければ、何もかもうまくいかない、ということはない
  
  
  ●１章　はじめに
  ・デスマーチプロジェクトとは、プロジェクトのパラメータが50％以上超過している物
  　・通常であれ二人月かかるところを一人月でやろうとしている等
  ・デスマーチは、教育効果が大きい
  ・プロジェクトの作業量、難易度を正確に見積もるのが難しい。予想より多くの課題、作業が発生し、デスマーチとなる
  
  ●２章　政治
  ・ソフトウェア開発プロジェクトは、様々な立場の人の思惑に左右される
  　・顧客、プロジェクトマネージャー、出資者、顧客上層部等
  
  ●３章　交渉
  ・納期、人的リソースについて交渉しよう
  ・時には、PMとして、会社上層部に反旗し、プロジェクトメンバーを守ろう
  ・「見積もりが難しいのは、見積もりを現状と将来をベースにした最善の予測を」と解釈するため。これが、上層部においては、『厳守すべき値』に変わってしまう」
  　→見積もりは常に最悪を想定して行いたいな
  
  ●４章　デスマーチプロジェクトの人々
  ・残業時間が多すぎると、途中から生産性は低下し始める
  ・プロジェクトの成功には、優秀な人、チームとして機能すること、働きやすい職場環境が必要だ
  
  ●５章　デスマーチ・プロセス
  ・この本で一番大事な言葉「トリアージ」
  　・「80/20の法則」に従う。いくつかの項目は、永遠に実装されない。それを目指す。全てに手をつけていては、デスマーチプロジェクトは終えられない
  ・システムの要求項目は「must」「should 」「could」に分けよう。そそて、mustから手をつけよう
  ・要求管理をしよう
  ・そこそこ使えるソフトウェアができれば、それでいい
  
  ●６章　プロセスのダイナミックス
  ・もっとも生産性の高い人から辞めていく。好条件の求人など、いくらでも来る
  ・プロジェクト上で大切にする人や仕事の取り扱い方の考え方を、チームに共有しよう
  
  ●７章　クリティカルチェーンと制約条件の理論
  ・プロジェクトのボトルネック、クリティカルパスは確認して仕事を進めよう
  
  ●８章　時間の管理
  ・無駄なミーティングはするな
  ・利害関係者の意見が対立する　→　承認が遅れることによって、スケジュールが遅れることを文書化して提示せよ
  ・緊急で重要度の高い仕事、緊急でないが重要な仕事をしよう。緊急だが重要でない仕事（電話応対）などに対応する機会を減らそう
  
  ●９章　進捗の管理と制御
  ・リスク、問題を整理し、管理し、評価し、対応方法を決めよう
  　・問題が多いデスマーチプロジェクトではなおさらだ。
  ・社内のプロジェクト後に、評価をしよう。同じ過ちは繰り返さないようにしよう
  
  ●１０章　デスマーチのためのツールと技術
  ・便利なツールは利用しよう。作業を標準化し、効率化しよう
  
  ●１１章　シュミレーションと「戦争ゲーム」
  ？メッセージが理解できなかった続きを読む

  投稿日：2022.04.09

すべてのレビューを見る