「デスマーチ第２版」を写経しました 06/05/15
「デスマーチ第２版 ソフトウエア開発プロジェクトはなぜ混乱するのか」(bk1)(amazon)から気になる部分を写経してみました。
写経ついでに公開するというスタンスですので、誤字脱字や読みにくさ等はご容赦ください。
もし問題等ございましたら修正するなり削除するなり対処致しますのでご連絡ください＞関係者様御中。
第１章
(p.10)
営業部門が顧客に約束した実現不可能な日程や予算は、始めに述べた政治的要因の 別の形といえる。営業部門の管理者には、自分が提案したスケジュールや予算が現実的かどうかはどうでもよい。最大の目的は、まず受注することであり、相手方の見積額と合致することであり、自分の上司を喜ばせることなのだ。(p.16)
「状況は悪化しています。ソフトウェア開発の海外アウトソーシングが増えた効果で コストを大幅にカットできましたが、海外発注しているソフトウェア会社は、非常に厳しいコスト競争にさらされています。生き残る方法はただ一つ。製品を市場へリリースし、コストを下げるしかありません。「デスマーチ」は、標準になりつつあります。景気がよくなっても、市場のこの傾向は変わらないでしょう。(p.28)
「それ以外にこのプロジェクトに入って何千時間も残業する見返りはありますか」と 聞くと、マネージャー氏は黙るしかない。正直に答えるなら、「ノー」としか言えない。こんなプロジェクトは、面白みがなく、新技術など一つもないと相場が決まっている。しかも、失敗する確率は７５％もあるのだ。(p.29)
結局このプロジェクトがデスマーチになるのは、新技術への挑戦が原因 ではなく、馬鹿馬鹿しいスケジュールのせいだ。なぜ、プロジェクト・マネージャーがそんなことをするのか、よくわからないが、友人に１年間威張ってられる格好いいものではない。(p.22〜33)
会社が即決を迫った場合はどうだろう。「プロジェクト参加契約書に 今すぐサインしてもらおう。いやなら荷物をまとめて出ていってくれ」と上司に申し渡されたとする。
(snip)
こんな場合は、少々無理をしても辞めるべきだ。状況は今後ますます悪くなる一方なのだから。数ヶ月は貯金を取り崩して生活しなければならないし、初めての業種で新しい職にありついても、慣れるまでは見習い扱いで給与をカットされる。しかし、白旗を掲げ、昇給・昇格する望みのない職場にしがみつくより、新天地のほうがよほど幸せということだ。デスマーチ・プロジェクトに形だけ参加して、履歴書の職歴を増やしながら職探しをするのも同じ効果がある。しかし、職が見つかって、デスマーチ・プロジェクトを中途で辞めると、同僚を窮地に追いやり、救いのない状態になるので、倫理的なジレンマに陥ることを覚悟せねばならない。第２章
(p.49)
特に重要な顧客やユーザーの例として、「負け組ユーザー」と呼ぶ人たちがいる。 これは、プロジェクトが成功すると自分の利益が大打撃を受ける人たちだ。不利益の典型として、権力や名声が減少したり、保証が少なくなったり、利便性がなくなる。(p.57)
「家に帰って家族に会う必要はない。入院生活している老父母との面会も不要。 とにかく、プロジェクトに関係ないことは一切する必要はない」(p.59)
一番よくある落とし穴は、「モーレツ」型のプロジェクトに巻き込まれることで、その プロジェクト・マネージャーはメンバーを犠牲にすることを認めず、シラを切る。幸い、どれほどマネージャー氏が否定しても、「モーレツ」型であることはすぐにわかる。マッチョな態度や、「本物のプログラマ」になれない弱い人間はプロジェクトの面汚しという考え方は、プロジェクト・マネージャーの行動原理を明確に表している。(p.61)
プロジェクトのメンバー全員が「自滅型」プロジェクトへ放り込まれたことに 気付くと、必要最小限の労力と関心しか示さない。プロジェクト・マネージャーが、長時間、強制的に働かせようとしても、深夜や土日（長時間残業を命令した会社上層部の連中がいないことが確実な時間帯は）、私用電話をかけたり、家族に手紙を書いたり、コーヒーの自動販売機のまわりにたむろして、馬鹿話に興じるのだ。(p.68)
(*11)「モーレツ」型プロジェクトのマネジャーは、これを見ると飛び掛かり、 絶対認めないと文句を言うはずだ。プロジェクト開始直後にこれが起きたのなら心配はない。そのプログラマは二つのうちどちらかを選択せなばならない。妹の結婚式のほうが大事なら、後で醜いもめごとを起こすより、プロジェクトの立ち上がり直後に円満退社するほうがはるかに得策だ。第３章
自由な人間だけが交渉の席に着ける。囚人には、契約する資格がない。〜ルソン・マンデラ
(p.78)
はじめに述べたように、プロジェクト・マネージャーが、見積もりを水増ししていると 上層部が勘繰ることがある。上層部が政治的に狡猾なのは、昔、自分もシステム設計のプロジェクト・マネージャー時代に同じ手を使ったからだ。(p.79)
「じゃあ、このシステムはいつ完成するんだね。ワシは役員会で３月中旬に 出来上がると言ってしまったんだ。キミはワシを失望させたりはせんだろうね」。ここで勇気を振り絞って、現実的な線では１１月中旬が精いっぱいと言おうものなら、寄ってたかって、お前は頭が悪い、信頼できない、会社に忠誠心がない、挙句は、神を信じていないと袋だたきにあう。(p.85)
プロジェクト立ち上げ計画の会議で、顧客や上層部に対し、「この プロジェクトは６ヶ月プラスマイナス25%で完成できます」と言っても、みんなは「６ヶ月」とメモを取るだけだ。何度繰り返し言っても無視される。上司に、上層部の会議の結果を聞いても、スケジュールは「６ヶ月」になっている。(p.89)
「クビにする」との脅しは、デスマーチ・プロジェクトの交渉では常套句だが、 「強硬型」交渉の一形態にすぎない。昇給・昇格の対象外にするのも、よく使う手だ。社会契約を破棄されたのなら、こちらも「強硬型」交渉手段を取る権利がある。交渉の場で最大の武器となるのが、「結果がお互いに満足できるものでないなら、職を辞する覚悟がある」と敵側に認識させることだ。(p.92)
プロジェクトのメンバーを大事に考えるプロジェクト・リーダーは メンバーを騙さない。どれだけ大変なプロジェクトか、成功する確率はどれくらいかを正直にメンバーに話す。プログラマも馬鹿ではない。経験豊かなプログラマには鋭い嗅覚があり、ゴマ化しかどうか簡単に嗅ぎ分ける。プログラマはプロジェクトの政治ゲームには参加しない。これは、プロジェクトが危機になると、ツケが自分たちの両肩にのしかかると知っているためだ。第４章
(p.103)
これと正反対の極端な例が、死にかけている官公庁のプロジェクトである。 仕事は恐ろしく退屈で、プロジェクトの誰の金銭報酬も上がらない。給料は公務員の号棒で計算するし、給与体系もあらかじめ決まっている。特別な臨時給与もないし、利益分配やストックオプションもない。こんな環境では、金銭的な報奨をやる気喚起の手段と考えることすら馬鹿馬鹿しい。そんなことをしても、プロジェクト・チーム全体が欲求不満になるだけだ。(p.106)
花束も素晴らしいが、家族にはもっと「実用的なサービス」を提供するほうが 効果は大きい。ご主人が一日24時間デスマーチ・プロジェクトに追い回されると、奥さんは家事や育児を一人でこなさねばならない。
(snip)
子供の病気が思わしくなく、医者に見せる必要があるなら、全力を尽くして、すべてのお役所規則を破り、必要な治療を受けられるようにする。これにより、プログラマの心配の種を最小限にできる。これには金がかかるが大した額ではない。プロジェクトの「雑費」で落とせるはずだ。会社のお役所仕事に従事している連中がこれを嗅ぎつけると、くどくど文句を言う。そんな経費は会社規則の選択外というわけだが、これしきのプレッシャーに負けるプロジェクト・マネージャーは失格である。
(p.107)
「何！？お前、気は確かか？６ヶ月のデスマーチ・プロジェクトに ６ヶ月の休暇をやるだと？２日休みをやる。調子に乗るんじゃない」。こんな答えが返ってきたら、プログラマを年季奉公の召し使いとしか見ていないのだ。(p.109)
プロジェクトのメンバーが残業時間分の手当てをもらっているかどうかに かかわらず、残業時間を記録していないのは最悪だ。これは、メンバーは年俸制であり、時間いくらで給料をもらっていないのが最大の理由で、残業分はタダと思っているためである。経理部門の人間には、残業分は無償だが、プロジェクト・マネージャーの視点では、残業はタダではない。(p.111)
＜図4.1＞：週勤務時間が120時間を超えると生産性がゼロ以下になる点に注目。(p.119)
一方、銀行や保険会社、官公庁、製造業など、ソフトウェアへの投資はムダ金と 思っている何百もの会社では、プログラマのオフィスはプラスチックで仕切ったキューティクル式になり、また、知的生産力を集中できる度合いが、「貧弱」から「ゼロ」へと悪化した。バックグラウンド・ミュージックが流れ、電話が絶え間なく鳴り響き、外では犬が吠え、誰かが怒鳴り散らしている。そして、社内便の配達係から社長に至るまで、無遠慮に割り込んでくる。第５章
(p.131)
まず誰も、少なくとも主なユーザーも会社の上層部も全員、スケジュールが 非現実的であることを認めたがらない。プロジェクト・マネージャーとメンバーは、自滅型を開始したときに起こる胃の底の悪い予感を感じるかもしれないが、彼らが楽観的なら、最後には奇跡が起こって救われるスパイ大作戦型のプロジェクトだと信じるだろう。期限が十分先なら（たとえば半年先か１年先なら）、だれも、目標の実現が不可能である、という現実に立ち向かわないのである。
(snip)
悲しいかな、ことはそう簡単には運ばない。プロジェクト・マネージャーからの要求やまた、プロジェクト・マネージャーの誠実な約束があっても、ユーザーと上層部が、最終納期どおりに供給できない現実に直面せねばならなくなったときに、「醜い危機」が最後にやってくる。最終納期の１ヶ月前、ときには１週間前、さらには１日前に起こるのだ。(p.133)
しかし、半完成物が最後に廃棄物になる本当の理由は、だれも続きの作業に戻る時間がないからだ。
(snip)
注意してほしいのは、ここで述べたことは、構造化分析、SCI-CMM、 その他の「教科書的」方法論、ソフトウェアのどれを使うかには関係がないことだ。ここでの議論は、単なる常識の類だが、デスマーチ・プロジェクトではきわめて重要な常識である。(p.135)
しかし、私の経験から言うと、大部分のデスマーチ・プロジェクトが、 構造化分析／設計(SA/SD)やオブジェクト思考分析／設計(OOA/OOD)のような公式的なモデリング技法を使っていない。その理由にはこうした方法論は扱いにくく煩雑だし、方法論を支援するCASEツールの使い勝手が悪いせいもあるが、最大の理由は分析モデルを実際のコードに自動的に変換する手段がないからである。結局、デスマーチ・プロジェクトで重要なのは実際のコードだけなのだ。(p.138)
最終納期があと数週間後に迫ると、ユーザーは、以前は絶対に 必須であると言っていたいくつかの要求項目が、結局それほど必須ではないことを、認めざるをえない。(p.139)
実際、上層部とエンドユーザーは、「技術的な」図はすべて理解できない、と 文句を言い、データ要素定義やプロセス使用を詳述した数百ページの文書を読む忍耐力も持ち合わせていない。十分な時間と忍耐力があれば、プロジェクト・チームは抵抗を克服し、念入りに作られたモデルが実際に有用であることを、エンドユーザーに説得できる。だが、デスマーチ・プロジェクトは、時間もなく忍耐力もない。(p.149)
追加される要求項目、既存の要求項目の改訂、などの提案のすべては、 プロジェクト・マネージャーとの会話、一対一の折衝、メールを介して、プロジェクト・チームに「一方的に」やってくる。こうした提案の多くは、「申し訳ない。先週の打ち合わせではこれを提案しようとは思わなかったのだが…」とか「公式の運営グループでこの新要求項目を議論する時間があると思ったんだが…」といった穏やかな前置きがつくだろう。(p.143)
デスマーチ・プロジェクトは、スタッフが新しい（または初めての） 方法論を学ぶところではありません。それなのに、スタッフがそこで新方法論を同時に学んだら、それはプロジェクトを死に追いやる機会を増やすだけでしょう。(p.162)
どうかこの章を、どのようなプロセス、手法、技法も実施しない 言い訳と解釈しないでほしい。実際、これらを実施しないことも、デスマーチ・プロジェクトを殺すだろう。第６章
(p.167)
メンタル・モデルは、この言葉が示すとおりである。つまり、問題や 状況を扱うために、人が頭の中に持ち歩くモデルである。このモデルは、経験や直感、伝承や神話に基づく場合がある。つまり、政治や人間の多岐にわたる感情に左右されるのだ。(p.170)
（成功体験を持つ）ベテランのプロジェクト・マネージャーが、未成熟で 原始的なメンタル・モデルを数年かけて磨き上げ、きわめて精緻なレベルに仕上げることは十分考えられる。どうやって、この知識を、「現実の」プロジェクトに初めて取りかかろうとしている未熟なプロジェクト・マネージャーに伝えたらよいのか？(p.173)
にもかかわらず、図6.1には基本的な問題がある。この表を最初に見た時点と、 いま再びそれを見た時点とで変化がないという意味で、視覚的に静的なことである。表の列は、長い時間をかけてモデル化されてきたソフトウェア組織の行動をはっきり示しているのだが、動的な姿が視覚的なかたちで見えてこない。
(snip)
また、もし8会計四半期移行に続く「パターン」があることがわかったとしても、この表ではまったく見えてこない。(p.175)
ここで興味あることが見えてくる。ソフトウェア開発組織の誰かが辞める場合、 最初にドアから出ていくのは誰だろう？それは最も生産性が高い人たちなのだ！すなわち、生産性の高いエンジニアには好条件の転職案件がいくらでも来るし、現在置かれている状況に最も不満を感じている。優秀な人材が離職した結果、組織の平均生産性はさらに低下し、さらにモラルを下げ、さらに離職率を高め、残っている生産性の高い人も辞めていき、かくして組織が映画「Night of the Living Dead」のエキストラ出演者のようなゾンビになるまで悪循環が続く。(p.185)
一見取るに足らないパラメータの一見穏当な変更が、誰も予期しなかった 重大な影響をもたらすことがある。影響が「一目瞭然でない」理由は、我々人間が、時間遅れとフィードバック・ループの状況の中で、互いに作用する複数の変数の数量的影響を計算するのが苦手だからだ。第７章
(p.195)
マネジャーは、（「私が命令した以上、彼はそうするだろう」と考えて） 作業が８日目に完了すると考えるだろうが、そもそも作業者には理論的根拠がないので、作業者は、あらゆる意味での責任と完了日の判断を放棄する。その結果、機能不全に陥り、作業者もマネジャーもいずれもが、暗闇の中で仕事をすることになる。(p.197-198)
本書の目的は組織全体の機能不全的行動問題を解決することではない。 これは、普通のプロジェクト・マネージャーのゴールが、組織全体を革新することではないからだ。直接のタスクは、目の前のデスマーチ・プロジェクトを生き延び制御することであり、もし機能不全の力があまりにも強ければ、そこを辞める勇気ある決断を下すことだ。同様に、アルコール依存症を患う人の配偶者は、国全体としての解決策があればよいと考えるが、最優先事項はパートナーを助けることであり、それも駄目なことがわかったら、パートナーとの関係を終わらせる勇気を持つことだ。(p.206)
一人のプロジェクト・マネージャーとして、組織全体の文化を変えることは、 たぶんできないだろう。しかし、組織の機能不全とは何なのかを認識できて、自分自身とプロジェクト・チームを、（少なくともプロジェクトの期間中）その文化から隔離できるなら、そしてこの章で要約したクリティカルチェーン戦略から少しでも利益を得ることができれば、成功の機会は大きくなるだろう。第８章
(p.210)
不幸なことに、プロジェクト・マネージャーは、社会や企業の文化に深く 刻み込まれた儀式や活動に従っているとき、自分やメンバーの時間が無駄になっていることにまったく気づいていない。(p.213)
もし、利害関係者からすべての決定を24時間以内に完了すると約束した 公式の文書が得られなければ、できることはたった一つ。重要な決定が遅れている間、一日ごとに納期が後ろにずれることを文書化して発行することだ。前に述べたように、利害関係者は、そのようなやり方で「公式の」納期が後ろにずれるのを決して認めない。従って、提示する文書は、次の形式をとることになる。「公式に認可された納期は変わらない、の事実のもと、こちらからＸについてご承認を要請いたしましたが、そちらの過失により24時間以内に決定が得られなかったため、プロジェクトは必然的に１日遅れました。従って、システムは10月10日に納入されるのではなく、最近の状況報告から推定すると、10月11日に納入されるものと推定致します」。(p.216)
少し回りくどい方法だが、メールの割り込みを確実に先送りにできる、 残酷だが実践的な戦略がある。それは、まったく返事を出さないことだ。マネジャーが忙しいことはみんな知っている。また、一日に100件のメールを受け取ることも知っている。従って、メールにすぐに回答しなくても、おそらくわざと相手を無視してやっているとは思われないだろう。数日後に、相手が「緊急」メールを送ったのに、なぜ返事をくれないのか、とフォローしてこなければ、その「緊急」メールはそれほど「緊急」ではないのだ。第９章
(p.219)
厳しい顧客と現実的な日程や予算を折衝したり、システムを構築する プロジェクト・チームを編成したり、仕事を円滑に進めるためのプロセスや手順を確認するのは大変なことである。残念なことに、一部のプロジェクト・マネージャーは、この重大なステップをやり遂げると、他の全ては比較的スムーズに流れると信じてしまう。(p.222)
Windows95開発プロジェクトでも、毎日の構築の概念を用い、 1995年8月にリリースした販売用システムの直前の最終ベータ版は、「951番目の構築システム」であったことは興味深い。(p.224)
悲しいかな、デスマーチ・プロジェクトが進むにつれて、手に負えない ことが起こる。リスク・マネジメントは、公式のプロセスではなく、場当たり的な気持ちや直感で対処するため、プロジェクトが進むなかで現れる新たなリスクを見逃してしまうのだ。(p.226)
しかし、メンバーが週に127時間しか働かないので、プロジェクトが 終わらないと文句を言うプロジェクト・マネージャーが、一方で自分の守備範囲で起きていることをきちんと把握できず、デスマーチ・プロジェクトを潰してしまうことも多い。(p.230)
プロジェクト・マネージャーは、定期的に「進捗状況会議」を開催して、 進捗状況や、進捗の遅れ、（この章の２番目の節で述べたリスク・マネジメントの文脈での）リスクや問題をレビューし、プロジェクトの現状を評価したいと思うだろう。しかし、こんなことをやっても「過ぎたこと」がわかるだけだ。プロジェクト・マネージャーが本当に知りたいのは、正確で、現実的な今後の評価であり、メンバーに言いたいことは、「現在の状況からみて、いつならシステムを顧客に無理なく納入できるのか？また、いまからその日まで、どんな問題が起こりそうか？」なのである。(p.232)
理想的には、ミニ・ポストモーテムから得られる利益、つまり「教訓」は、 まだ見ぬ将来のIT開発者がトラブルになったときに役立つものではなく、目の前のチーム・メンバーを助けるものだ。プロジェクト完了後のポストモーテムは、「プロジェクトを通じてユーザーを必ず巻き込め」というような、当たり障りのない格言しか生まない。第１０章
(p.240)
C++やJavaといった言語をみんなで使うことだけに同意するのでは十分ではない。 共通のベンダーの共通のツールキットを使わなければならない。チームの一部はSunのJava環境を使い、他の一部はマイクロソフトのVisual J++を使うのは技術的に可能だが、馬鹿げたことだ。(p.245)
退屈で単調と思われていたプロセスを先進技術を用いて省略 することに期待しても、反対する人はだれもいない。しかし、我々が慣れ親しんできたプロセスに新たにプロセスを追加したり、プロセスを改訂したりする必要がある新技術を導入するのはずっと難しい。(p.247)
前にも述べたように、非凡なツールは、通常、対応するソフトウェア・プロセスに、 強い影響を与える。それゆえ、新たなツールの導入は、新たなプロセスの導入を意味する。プロセスとの対応関係がはっきりしているのに、ツールが支援するプロセスをまったく理解していない受講者に、どうやってツールを操作するかを中途半端な５日間のワークショップ（受講者のマネジャーは、ワークショップへの参加で５日間日程が遅れることですでにパニックになっている）で教えるのは、異常なことである。受講者のやる気をくじくだけだ。(p.248)
教育・訓練にはどのくらいの時間がかかるだろう？ツールのタイプや 複雑さのほかに、ユーザー・インタフェース、オンライン・ヘルプ機能など、他の雑多な問題に依存する。理想的には、開発者が正式な教育・訓練をまったく受けなくても、ツールの使い方がわかる場合だ。プロジェクト・マネージャーもほかのマネジャーたちも、ひたすらこれを望んでいる。いかなる教育も訓練も時間の浪費であり、プロジェクトの「現実の仕事」から目を反らすものと見なしているからだ。(p.252)
ときには、政治が状況をひどくする。
(snip)
ツール監査官が「わが社はＸを売る会社だ！社内でＸ以外の鼻持ちならない 製品を使うことはまかりならん！」と命令する。このＸは、コンパイラか、テスト用ツールか、構成管理用ツールか、共働開発用ツールかもしれないのだ。第１１章
(p.255)
少し前に入った新人が最初のプロジェクトに入ってすぐに、プロジェクト・ マネージャーから、「教室で習ったことは全部無視しろ。ソフトウェア開発にはもっと現実的な態度で臨むんだ」、と言われるのは皮肉なことだ。(p.259)
悲しいかな、経営者は、普通こうは考えない。経営者にとっては、教育や 訓練にかかるものは、時間であれ労力であれコストであれ、すべてが不愉快で、デスマーチのシミュレータに関連するコストと工数は、正当化されにくい。その結果として、デスマーチ・プロジェクトの本当の戦闘の前に、この種の「演習」を行うメリットがあると信じているプロジェクト・マネージャーは、「非公式」な方法を見つけなければならないだろう。(p.261)
これについての楽しい例外は、起業家的新興企業である。 文字どおり、この種の組織には置き換えるべき以前の文化が存在しないので、デスマーチ・プロジェクトを完全に「普通」と見なす可能性が高い。結局のところ、既存の大企業に立ち向かうために、全員がとり憑かれたように働き、信じられないリスクを冒す。(p.262)
デスマーチ・プロジェクトを最後に成功させることはもちろん重要で、 そのための実践的な助言を本書でも提供したが、それよりもずっと重要なのは、生き残ることだ。