プロジェクトの審査・承認・予算を握る。最終的にシステムが動くかよりも、自社製品の売り込みやコミッションに興味があるので、敬して遠ざくべし。味方にすると非公式な方法で有形無形の支援を期待できる。^^^^^^^^^^^^^プロジェクトで、ブタの役割を期待されていると感じ取ったら逃げるべし。†プロジェクトマネージャがプロジェクトを受ける時の心得ちゃんと規模を見積もれ(ツールを使いプロトタイプ開発をする)「(この期間と予算で)やるか死ぬか」と即答を迫られても返事をするなトレードオフの提案をせよ期間が10%削られたら、人員を10%増やす(度胸があるなら1/(n^2)を提案。期間半分で人員4倍)80/20の法則が有効なら、80%の機能を持つ20%のプログラムをリリースできたら、残りの20%の機能を持つ80%のプログラムは削減できないか規模を誤差付きで提案しても、顧客や上層部の頭には残らない。6ヶ月±25%と提案しても、顧客や上層部には6ヶ月しか頭に残らない。雇用側が一生面倒みるという社会的契約を破棄している以上、労働者側が忠誠心を1年単位、プロジェクト単位に限定しても恥じることはないプロジェクトメンバーのためでもある。「作戦に欠陥があることを知りながら強行する指揮官は重大な誤りを犯している。普通の人間に対して、超人的な芸当を求めていることを十分納得させる必要があるそうしないと「自滅」型や「カミカゼ」型、「モーレツ」型になる会社側はあなたのプロジェクトをお荷物人員のゴミ捨て場にしようとするかもしれない「自滅」型プロジェクトになるので絶対に拒否すべきあなたに良心がなければ以下のような方法が使える。人をたくさん要求し、使えない人員にはつまらない仕事をやらせて、どんどん辞めてもらう。年俸制で経費とは関係なくても、プロジェクトは長距離走なのだから、残業時間を管理してチーム・メンバーが潰れるのを防ぐべき。適正労働時間は週60時間以下60〜80時間の場合には、限界であると警告するアドレナリンの影響で一時的に生産性は上がるが早晩バテる80〜90時間を超えたら、休ませるべきであるアドレナリンの影響で一時的に生産性は下がらないが早晩バテる。週90時間以上働くと必ず生産性が下がる。コミュニケーションプロジェクトマネージャは、チーム・メンバーを政治ゲームから守ってやらなければならないしかし、何が起こっているかは伝える必要があるチームの構成(デスマーチチームに必要な役割と分担)作業環境(集中できる環境をどんなことをしても確保すべき)スカンクワークが最強。要求のモデルを作ることに力が注がれてきたところが要求を管理することは、極めて重要であるにもかかわらずなおざりにされてきた要求の優先順位は動的に変化してとらえどころがないデスマーチプロジェクトでは、要求モデルとソースコードがかけ離れている場合が多い(ソースコードが正式文書なので、それからかけ離れた要求モデルに順位をつけても意味がない)最近要求管理を行えるツールが登場してきた逆説的な言い方だが、既にデスマーチになっているプロジェクトに、新しい管理手法を導入してはならない。さらなる混乱を招くだけ。†プロジェクトでは多数の構成要素が複雑に影響し有っている。複雑系では、ほんの少しの変化がフィードバック効果を起こし全体に大きな影響を与えることがよくある。いうツールを使うことによって、この複雑なフィードバック系を事前にシミュレートすることができる。会議を効率的に行う(Amazonで軽く1ダースは見つかる会議本を参考にせよ。基本的なことで十分効果的)利害関係者の無意味な異議どんな問題もこのプロジェクトでは発生から24時間以内に解決することを、プロジェクトの最初に同意をとっておくさもないと、プロジェクトは際限なく遅れる(遅れて困るのはあなたで、誰の責任かは関係ない)タスクに優先順位をつけて処理すべき。メールの自動仕分け(半分冗談)日に100通のメールを処理すると、10分に1通処理しなければいけない。これでは「実務」をできないそういうときにはメールには一切返事をしない。(10%,50%ではなく100%,1000%のオーダーで楽観的)進捗の管理と制御が行われていない進捗の管理について「90%完了」は危険な幻想。進捗は0%か100%で管理すべき進捗は単体テストが通った段階で数えるべきMicrosoftの毎日構築アプローチはすばらしい毎日深夜にテストスクリプトを動かしてその結果を以て進捗とするWin95の出荷版は、Build951進捗の制御についてデスマーチプロジェクトの進捗の制御は、リスクマネジメントリスクを評価するリスクを制御するリスクを回避するリスクが表面化してから対処する(「火消し型」)では、早晩プロジェクトは危機的状況を迎えるあらかじめリスクを算定することが大切リスクが表面化しても組織の許容範囲内に収まると算定できれば安心できる許容範囲内になければ表面化してプロジェクトが制御不能になる前に全力でつぶすリスクの出現に最初に気づくのはたいてい底辺の労働者なので、デスマーチプロジェクトではチーム一丸となってリスクマネジメントをする必要がある多くのプロジェクトで設置される「リスク管理監査官」は実際には役に立たないリスクは見ないふりをされることが多く、そうこうしているうちに本当に忘れられてしまうことがあるので、きちんと記録に残しておくことが必要リスクにまで発展していない問題に関しても記録に残しておくことが必要とにかく官僚主義を避けよたとえば、政治的な大レビュー会はデスマーチでは単なる無駄。必須のツール電子メールグループウェアRAD開発ツールバージョン管理システムテスト・デバックツールプロジェクトマネジメントツール(見積もり・日程・PERT図・ガントチャート)ツールキット・再利用コンポーネントCASEツール必ずしもソフトウェアにこだわる必要はない。(昔有ったが.comバブル崩壊で消えた。sec.ISBN10ISBN139784061426061。