概要
ヨードン(Yourdon)の有名な本『デスマーチ』のまとめ。一言で言えば、「現場はつらいよ」
要約
- ソフトウェア開発はほぼ例外なくデスマーチ・プロジェクトである。つまり、開発メンバーが週80時間働かなければ失敗するプロジェクトばかりである。
- デスマーチ・プロジェクトを乗り越える唯一の方法はトリアージである。つまり、開発に優先順位をつけろ。
- しかし優先順位の同意を得るのは至難の業である。つまり、それは政治である。さまざまな利害関係者がある中で、優先順位をつけて、実装する機能と諦める機能を決めなければならない。
- プロジェクトマネージャ(PM)やその部下であるプログラマ達には力(権力)がない。したがって、交渉もほとんど余地がない。せいぜいできることは「こんなプロジェクト進めるなら、辞めてやる！」しかない。
- 結局、「あれもこれもしろ」となり、デスマーチ(死の行軍)となる。
- 他にできることは、余計な作業を増やすなということである。つまり、官僚主義的な面倒な手続きで時間を浪費させるな。何とか委員会とかも口出しするな。PMはプログラマ達を守るためなら、多少でもルールや規則を破れ。
- そこそこ使える(Good Enough)ものを作れ。完璧なんか目指すな。端(はな)から無理だから。
ざっくりした内容
もともと読むきっかけは、プロジェクトマネージャ(PM)に関心を持つようになったからである。それは年を取ったからである。PM関連での名著にはブルックスの『人月の神話』がある。まだそれは読み終えていない。
本書は「デスマーチ」という用語を人口に普及させた名著である。ソフトウェア開発の残酷な現実を突きつけられる。原因究明も解決策の提示もあまりない。むしろデスマーチはデフォルトだから、それに慣れさせるためのシミュレーション開発に投資しろとまで主張する。
本書はPMについての本であるが、その特徴は政治について語っているということである。目次を見ればわかるが、第2章が「政治」であり、第3章が「交渉」であり、第11章が「シミュレーションと「戦争ゲーム」」である。プロジェクトマネジメントを政治というのか、それとも『ピープルウエア』のように社会学というのかはわからないが、少なくとも言えることは、ソフトウェア開発の問題は、技術的な問題ではなく、人に関する問題であるということである。
第1章はデスマーチについてである。その定義とデスマーチ・プロジェクトの分類とデスマーチ・プロジェクトの発生メカニズムについてである。簡単に言えば、デスマーチは馬車馬のように働かなければならない状態である。具体的な数字で言えば、週80時間働かなければ、プロジェクトが失敗するようなものである。
デスマーチ・プロジェクトは主に4象限ある。「成功率」の軸と「満足度」の軸である。
- スパイ大作戦型: 「成功率が高い」かつ「満足度が高い」
- モーレツ型: 「成功率が高い」かつ「満足度が低い」
- カミカゼ型: 「成功率が低い」かつ「満足度が高い」
- 自滅型: 「成功率が低い」かつ「満足度が低い」
どうしてデスマーチ・プロジェクトがあらゆる場所のあらゆる時間で生じるのか。原因はいくつかある。とりもなおさず「政治、政治、政治」である。他にも「若者のカワイイ楽観主義: 「土日に出てくればできますよ」」というものだったり、「海兵隊方式: 「本物のプログラマは寝ずに働く！」」というものだったり、さまざまである。
第2章は「政治」である。ソフトウェア開発という政治劇のアクター(出演者)を定義している。この劇の役には次のようなものがある。
- オーナー
- 顧客
- 出資者
- 利害関係者
- スーパーマン
第3章は「交渉」である。オーナーをはじめとする連中とPMとの間には絶大な権力の差があるので、結局PMができることは高が知れている。
第4章は「デスマーチ・プロジェクトの人々」である。要はプロジェクトメンバーについてである。身内なので、PMは彼らを守らなければならない。そのためなら多少ルールを破ることもある。「まず、やってみて、後で謝れ」
第5章はトリアージについてである。「この章から、または、本全体からたったひと言だけ覚えるとすれば、それは「トリアージ（triage）」である」(p.127)とまで言っている。トリアージとは優先順位ということである。
第6章と第7章は幾分テクニカルである。第6章は「プロセスのダイナミックス」である。ソフトウェア開発プロセスのモデルを議論している。このモデルを使えば、ブルックスの法則(遅れているプロジェクトに人員を追加すれば、プロジェクトはさらに遅れる)がどうして生じるかがわかる。第7章は「クリティカルチェーンと制約条件の理論」である。
第8章と第9章は管理(マネジメント)についてである。第8章は「時間の管理」であり、第9章は「進捗の管理と制御」である。進捗管理で著者は「毎日の構築」というのを提唱している。またプロジェクトのマイルストーンごとにポストモーテム(事後検証)をするべきだと主張している。ポストモーテムとはプロジェクトが終了した後に、課題を洗い直して、今後のプロセスを改善したり、再発防止に役立てる振り返りのことである。だが、筆者はこれをプロジェクトの終了時にするのではなく、マイルストーンごとに(フェーズごとに)実行するべきだと主張する。理由はプロジェクト終了時にはもう次のプロジェクトが始まっていて、振り返る余裕がないからである。またその頃になったら、だいたい忘れているから、具体的な振り返りができないというのがある。マイルストーンごとにポストモーテムをすれば、より具体的な指摘ができる。
第10章は「デスマーチのためのツールと技術」である。「そして、デスマーチ・プロジェクトには、どんなツールであれ、まったく新しいツールを導入してはならないことを警告しておきたい。」(p.237: 強調は筆者)
第11章は「シミュレーションと「戦争ゲーム」」である。著者のアイディアはこうである。現在、飛行士は訓練のためにフライト・シミュレーションを使って、何度も練習している。飛行士として一人前になっても、技術磨き上げるために、フライト・シミュレーションを使い続ける。それならば、PMも同様のデスマーチ・プロジェクト・シミュレーションを実行するべきではないのか? デスマーチ・プロジェクトはいたるところにあるので、それに慣れさせることは重要である。そのためのシミュレーションに投資することは、結果として会社に有益となるはずである。
感想
残念ながら評者はこれまでデスマーチ・プロジェクトを経験したことがない。ここに書かれているエピソードが本当なのかと何度も疑った。海兵隊方式のPMはプログラマに向かって「本物のプログラマなら、24時間働けるだろ!」と言ったり、ウォール街のPMはプロジェクトの初期にわざと「危機」を作って、開発者がその試練に耐えられるか試すらしい。さらにデスマーチ・プロジェクトの抜本的解決も提示しておらず、むしろ「それは普通だから慣れろ」という態度もあんまりだなと思った。せいぜいのところ慰めにしかならない。しかし、今後の開発において非常に役に立った。特に受託開発においては「政治」を考えるようにする。政治劇の役者を実際の人達に当てはめて考えるようにする。例えば、オーナーがどこ出身なのかも気にするようにする。「あの人は経理畑出身か。なら、プロジェクト開発がどういうものかあまり知らないだろう。」
あとプロジェクトを進めることがどんなに難しいのかもわかった。特に大規模プロジェクトなんてほぼ例外なく失敗するということ。いや、そんなのはわかっている。「アポロ計画」を参考に政府主導型イノベーションを支持する経済学者(マッツカート)がいるけど、それはほぼマヤカシだ。「そんな超例外をさも当然として考えるのは間違っていますよ。現場を知らない頭でっかちなお利口な学者さん」と。
引用文
序文
デスマーチ・プロジェクトを経験し、エベレストを素足で登ることが決して楽しいものではないことを知っている百戦錬磨のベテランと話すと、「いや！私は馬鹿じゃない！**もちろん**、私は正しい手法やツールを使いたと思ったさ。だが、上層部とユーザーが、そうさせながったんだ。このプロジェクトの馬鹿げた日程は、我々がこのプロジェクトを知る前から課せられていたんだ！」と答えが返ってくるだろう。
デスマーチ・プロジェクトは、上層部がどうしようもないマキャベリ主義者か、ユーザーが天真爛漫で非現実的であるために起こるのだ。
p.viii 強調は著者。原文では点々がついている。
この現象の説明がどうであれ、私の結論は、**デスマーチ・プロジェクトは、常態であって、例外ではない**というものだ。
p.viii 強調は著者。原文では点々がついている。
別の観点から見てみよう。スタンディッシュ・グループの産業統計や、ケイパーズ・ジョーンズ、ハワード・ルービン、ポール・ストラスマン、ラリー・プットナムなどのメトリクス指導者の統計データを見ると、平均的なプロジェクトが6〜12カ月遅延し、50～100%予算を超過している。状況はプロジェクトの規模や他の多くの要因によって変化するが、たいていのプロジェクトが、プロジェクト・マネジャーと技術スタッフにとって、程度の差こそあれ、ほぼ確実にデスマーチ・プロジェクトに至る条件下で運営されることを**予期すべきである**。
p.ix 強調は著者。原文では点々がついている。
ここまで読んで、これ以上読む時間がないなら、「**トリアージ**」のひと言を覚えてほしい。今、デスマーチ・プロジェクトに携わっているなら、決められた日程と予算内で、ユーザーの求める機能を実現できるだけ資源を持っていないはずだ。どの機能をあきらめ、どの機能に資源を集中的に投入すべきか、きびしい決断を迫られる。重要でない機能は、**まったく**インプリメントされないだろうし、重要性が低ければ消えていくのがベストだ。
p.x 強調は著者。原文では点々がついている。
簡明な説明を心がけたので、2時間もあれば、本書全体を読み終えられると思う。
p.x
第1章
私の定義は、「デスマーチ・プロジェクトとは、「プロジェクトのパラメータ」が正常値を50%以上超過したもの」である。
p.2
現実のソフトウエア・プロジェクトでは、以下のいずれかに該当するものをデスマーチと言う。
＊プロジェクトのスケジュールを、常識的に見積もった期間の半分以下に圧縮したプロジェクト。たとえば、通常は12カ月かかるのに、6カ月以内で出荷する場合。コンピュータ業界が「.com時代」を迎え、インターネットが定着し、ソフトウエア市場が地球規模
に広がり、マーケットを制すために出荷日程が厳しくなった。デスマーチ・プロジェクト発生の最大の原因がこれだ。
pp.2-3 他にも該当のものがあるが省略。
以上の条件からすぐに現れる影響として、生産効率を2倍にしたり、作業時間を2倍にするよう言われる。正常なプロジェクトで週に40時間働くとすると、典型的なデスマーチ・プロジェクトでは、一日14時間、しかも、週に6日も仕事に追われる。こんなプロジェクトでは、プレッシャーや緊張感がだんだん強くなるので、デスマーチ・プロジェクトとは、コーラだけを飲んでダイエットするようなものだ。
デスマーチ・プロジェクトは次のようにも定義できる。
公正かつ客観的にプロジェクトのリスク分析（技術的要因の分析、人員の解析、法的分析、政治的要因の分析も含む）をした場合、失敗する確率が50%を超えるもの。
スケジュール、人員、予算、機能に上記の制限が一切ないプロジェクトでも失敗する場合がある。たとえば、ソフトウエア開発部門とユーザーの間に敵対感情がある場合だ。しかし、失敗するのは、たいてい、上で述べた理由による。
p.4
＊小規模プロジェクト：10人以下のプログラマが3〜6カ月で開発するプロジェクト。
＊中規模プロジェクト：20～30人の技術者が1～2年かかるプロジェクト。
＊大規模プロジェクト：100〜300人のプログラマが3〜5年の予定で作業をするプロジェクト。
＊超巨大プロジェクト：1000～2000人という軍隊並みの陣容（コンサルタントや下請けプログラマも参加する場合が多い）で、7～10年の長期にわたりプログラムを開発するもの。
いろいろな理由があるが、これまで世界中を見てきて、一番多いのが小規模のデスマーチ・プロジェクトだった。幸い、小プロジェクトは成功する確率も大きい。チームワークのしっかりした3～6人のプロジェクトでは、土気も高く、3～6カ月の間なら、徹夜、長期休暇の延期、休日出勤もしばらくの辛抱とばかり、自分の生活（体も）を犠牲にする。
中規模プロジェクトでは、成功する可能性はかなり低く、大規模プロジエクトでは、ほとんどゼロになる。プロジェクトの頭数が多くなるほど、チームの団結力を維持するのは難しい。また、人が増えると、会社を辞める人が増えるだけでなく、車に轢かれたり、現代社会の危険に巻き込まれる確率が急激に大きくなる。重要なのは、プロジェクトの人数ではなく、作業スケジュールだ。週80時間労働は、6カ月なら耐えられるが、2年の長きにわたると、問題が起きる。
超巨大デスマーチ・プロジェクトが本当に存在するのか疑問に思う人もいるだろう。NASA（米航空宇宙局）のプロジェクトで、1969年に人間を月へ送ったシステムの開発は、デスマーチ・プロジェクトが成功した稀有の例だが、大半の超巨大プロジェクトは、始まった瞬間に失敗する。幸い、会社の上層部はこれがわかっているので、ほとんどの大企業（小さな会社では、超巨大プロジェクトを起こせない）は超巨大プロジェクトを止めた。しかし、政府関係機関では、ときどき発生する。
p.5
正真正銘のデスマーチ・
プロジェクトに、予算を無制限に注ぎ込むのだ。愛国心をくすぐられると（たとえば、「9月11日事件」以降の国防体制）、上層部の人間は見境がなくなり、超巨大プロジェクトは成功しないことを忘れる。
デスマーチ・プロジェクトの判定材料として、プロジェクトの大きさのほかに、ユーザー数がある。ユーザーが1部門だけとか、同じ組識内のよく似たユーザーのグループの場合でも、失敗することがある。まして、一つの会社全体を対象にするプロジェクトでは、天文学的に難しくなる。これは、他分野、他組識とのインタフェースという政治問題やコミュニケーションの問題が加わるためだ。この結果、たとえば、組織再編成やビジネス・リエンジニアリングに関係するシステム開発は、デスマーチ・プロジェクトになることが多い。ハードウエアやソフトウエア自体の開発に比べると、組織再編成関連のシステム開発は大きな工数を必要としないが、政治抗争が発生しやすいため、組識全体がマヒし、プロジェクトのプログラマに大きなフラストレーションが貯まる。
pp.5-6
新しい国際化現象として、インド、中国、ロシアなどにソフトウエア開発プロジェクトをアウトソーシングする「オフショア化」がある。私は何カ国かのソフトウエア会社を訪れたことがあるが、プログラマが一日16時間、1週間に7日働くというデスマーチ・プロジェクト状態の「労働力搾取」はなかった。
p.15 このあと「しかし、アメリカでは...」と続く。そこは省略。ここでは「一日16時間、1週間に7日働く」というキーワードを記録するため。
このプロジェクトがデスマーチになる本当の原因は、プロジェクトの規模、スケジュール、コストなどの目に見える理由以外に、未知数の最先端技術をビジネスの中枢で稼働するアプリケーションに適用することにある。新技術が使えても、大規模システムでは効果が表れないことが多い。いかにして新技術の利点を引き出し、欠点を補えばよいか、どのプログラマにもわからない。ベンダーも、どうサポートしてよいか知らないし......。
p.17
政府規制型のデスマーチ・プロジェクトで一番面倒なのが納入日程だ。新システムは何月何日までに稼働させることとの条件で、たとえば、1月1日までに正常に動作しなければ、一日につき何百万ドルもの罰金を科せられる。延期申請をしたり、報酬の受け取りを放棄できる場合もあるが、たいてい、日程は絶対的だ。期日までに完成できないと、上で述べた悲惨な企業と同様、レイオフ、倒産、そのほかすさまじい結果が生じる。
このタイプのプロジェクトでは、技術の新旧はどうでもよい。このデスマーチ・プロジェクトの特徴は「厳しい日程」にある。もちろん、会社上層部が火に油を注ぐ行為をしたり、予算削減がさらに足を引っ張るのだ。
p.18
本書の最初に挙げたテーマを思い出してほしい。「デスマーチ・プロジェクトは例外ではなく、通常の状態なのだ」
p.33
マキャベリの『君主論』を一言一句暗誦しているなら、また、政治ゲームが好きなら、デスマーチ・プロジェクトは格好の娯楽だ。しかし、プログラマの大部分は、（読んだとしても）学生時代以降、『君主論』なんて読まない。プログラマ連中は、政治的に素人であることを認めながら、政治のすべての概念に嫌悪感を示し、政治の駆け引きに明け暮れる連中を軽蔑している。もしそうなら、なぜ、メガリス銀行のトータル・システム 2020プロジェクトへ参加する契約書にサインするのか。考えられる答えはただ一つ。デスマーチ・プロジェクトが1回きりと本気で信じ、また、メガリス銀行に長く勤めるとこのプロジェクトに参加したことが昇進上でプラスになるというものだ。これを本気で信じるのは、ブタも空を飛べると信じるほどおめでたい。
p.34
第2章
オーナーが全員、このように物分かりが良くはないし、すべてのオーナーが会社内で強力な権限を持っているとはかぎらない。ここのポイントは、「普通のソフトウエア開発プロジェクトでは、誰がプロジェクトのオーナーかを知ることは重要だが、デスマーチ・プロジェクトでは、必須となる」ことだ。
p.47
また、私の経験によると、プロジェクトのオーナーは、プロジェ
クト・マネジャーの敵ではなく、味方になる場合が圧倒的に多い。オーナーは、お役所仕事をやめ、官僚主義から発生する有害な制限をなくしたいと考えている。プロジェクト・マネジャーも、そうなるように願っている。
オーナーが完成したシステムを実際に使うとは限らないし、プロジェクトに対し、政治力を及ぼすのはオーナーだけでないことも忘れてはならない。以下に述べる他の人物も十分考慮する必要がある。
pp.47-48
「顧客」とは、デスマーチ・プロジェクトが開発するシステムを実際に使う人（グループの場合が多い）を言う。世の中では、この人（あるいは、グループ）を「ユーザー」と呼ぶのが普通だ。顧客がデスマーチ・プロジェクトのオーナーを兼ねる場合もあるが、デスマーチ・プロジェクトで開発したシステムを実際に使い、操作管理や事務処理をするユーザーの場合がほとんどである。
p.48
第3章
第4章
第5章
第6章
第7章
第8章
第9章
第10章
第11章
僕から以上
