4822282716

 

現在、何かと話題になっているデスマーチです。
私自身この業界で数年過ごしてみて、デスマーチでないプロジェクトはなかった。
普通は、デスマーチにならないような方法論を考えようという話になる。
ところが本書は、どうせデスマーチが常態なんだから、どうやってデスマーチの中をうまく生き残ればよいかを述べている。
本書はシステム開発におけるコロンブスの卵的な処方箋であり、IT業界人のサバイバル読本。

はじめに †

  1. デスマーチの定義
    • 人員・予算・機能のいずれかが必要な量の50%以下しか見積もられていないプロジェクト
  2. どのプロジェクトがデスマーチになるのか
    • 全部のプロジェクト
    • 10人以下の小規模プロジェクトならば、士気さえ保てれば、徹夜・休日出勤・休暇延期で何とかなるかもしれない
    • 中規模・大規模・超大規模は必ずデスマーチの泥沼にはまる
  3. なぜどのプロジェクトもデスマーチになるのか
    • 「(仕様)理解不足のシステム」の開発を成功させるのはほぼ不可能
    • 「複雑度の高いシステム」の開発を成功させるのはほぼ不可能
    • これに、政治問題やコミュニケーションの問題が加わるとプロジェクトの統御はさらに難しくなる
    • これが今日のシステム開発の常態
  4. この業界で飯を食うということは
    • デスマーチで生き長らえること (エンジニアとして…、ＰＭとして…、ということではなくて、生命を保つという意味で生き長らえること)
    • 本書は、デスマーチで生き長らえるための指南書
↑

政治 †

  1. プロジェクトの性質 
    満足度↑
      ｜カミカゼ型  スパイ大作戦型
      ｜
      ｜自滅型      モーレツ型
      ＋─────────────→
                          成功の確率
  2. スパイ大作戦型のプロジェクト
    • 最高の人材・最高のバックアップ体制・幸運で不可能を可能にする
    • デスマーチが常態である以上、システム開発が成功する唯一のプロジェクト形態
    • 技術よりも政治が重要
    • 関係者のコンセンサスを得るのがＰＭの主要な仕事
    • 問題発生時には２４時間以内に承認・承諾・レビューを終える言質を取ること
    • 味方につけよ
      オーナーユーザ企業側担当者。金主。非常に強力な権限を持つ。手なずければプロジェクトから官僚的な無駄を一刀両断してもらえる
      顧客(エンドユーザ)詳細仕様のソース。多くの場合今作っているシステムにより権限を失うので、そのシステム開発に対する積極的な支援や協力は得られない
      出資者(ベンダー)プロジェクトの審査・承認・予算を握る。最終的にシステムが動くかよりも、自社製品の売り込みやコミッションに興味があるので、敬して遠ざくべし。
      利害関係者ITサポート部門。味方にすると非公式な方法で有形無形の支援を期待できる。敵にする(無視する)と妨害のための妨害をされるかも
      スーパーマン「銀の弾丸」何か知らんがプロジェクト内で強い政治力を持ち、会社の規則を無視してVB Enterprise Editionや夜食のピザを経費で落としてくれる
  3. 逃げよ！
    • スパイ大作戦型のプロジェクトでなければ逃げるのも一つの処世術
    • 途中で逃げ出すことに比べれば遙かに責任ある態度 
      ブタとニワトリが朝食を作るのにどちらの貢献度が大きいか口論している
ニワトリ「ボクは毎日卵を産むために一生懸命働いているんだよ」
ブタ　　「ボクはベーコンを作るために 死 ぬ ほ ど がんばっているんだよ」
                                    ^^^^^^^^^^^^^
      プロジェクトで、ブタの役割を期待されていると感じ取ったら逃げるべし。ベーコンにされる前に・・・
↑

交渉 †

プロジェクトマネージャがプロジェクトを受ける時の心得

  1. ちゃんと規模を見積もれ(ツールを使いプロトタイプ開発をする)
  2. 「(この期間と予算で)やるか死ぬか」と即答を迫られても返事をするな
  3. トレードオフの提案をせよ
    • 期間が10%削られたら、人員を10%増やす(度胸があるなら1/(n^2)を提案。期間半分で人員４倍)
    • 80/20の法則が有効なら、80%の機能を持つ20%のプログラムをリリースできたら、残りの20%の機能を持つ80%のプログラムは削減できないか
  4. 規模を誤差付きで提案しても、顧客や上層部の頭には残らない。
    • 6ヶ月±25%と提案しても、顧客や上層部には6ヶ月しか頭に残らない。
    • しかし、いざというときのために文書で誤差部分を残しておくことが重要
  5. 初期段階で、スパイ大作戦型にするための提案をすべて拒まれたら辞職するのも一つの選択肢
    • 雇用側が一生面倒みるという社会的契約を破棄している以上、労働者側が忠誠心を１年単位、プロジェクト単位に限定しても恥じることはない
    • プロジェクトメンバーのためでもある。「作戦に欠陥があることを知りながら強行する指揮官は重大な誤りを犯している。欠陥があると思う理由をきちんと主張し、作戦の変更を求め、最後の手段として自分の兵隊を犠牲にするのではなく、自分の職をなげうつ覚悟が必要だ（ナポレオン）」
↑

デスマーチプロジェクトの人々 †

  1. プロジェクト成功の鍵はピープルウェア
  2. プロジェクト・マネージャは理不尽なスケジュールや予算を飲まされる
    • プロジェクト・マネージャはプロジェクトの人選や処遇、作業環境の改善を一任するよう会社に迫り、認めさせることが可能
    • このことは会社全体の官僚主義的な雰囲気を変えることはできないが、あなたのデスマーチプロジェクトを救う起爆剤となりうる
  3. 人選問題
    • デスマーチプロジェクトにスーパースターを集めようとしてもそれは非現実的
    • 現実的な解は、「普通のプログラマを呼び集めて、なぜこのプロジェクトに連れてこられたのかを十分に自覚させる」
      • 普通の人間に対して、超人的な芸当を求めていることを十分納得させる必要がある
      • そうしないと「自滅」型や「カミカゼ」型、「モーレツ」型になる
    • 会社側はあなたのプロジェクトをお荷物人員のゴミ捨て場にしようとするかもしれない
      • 「自滅」型プロジェクトになるので絶対に拒否すべき
      • あなたに良心がなければ以下のような方法が使える。 
        人をたくさん要求し、使えない人員にはつまらない仕事をやらせて、どんどん辞めてもらう。
そうやって上位２０％の上澄みのみをいただく
         
  4. 報酬
    • 昇級・休暇・差し入れ・家族への心遣い・次の興味深いプロジェクト
    • ただし、既に１日１８時間働いていたら、どんな報酬をちらつかせてもこれ以上働かせるのは不可能
  5. 年俸制で経費とは関係なくても、プロジェクトは長距離走なのだから、残業時間を管理してチーム・メンバーが潰れるのを防ぐべき。
    • 適正労働時間は週60時間以下
    • 60〜80時間の場合には、限界であると警告する
      • アドレナリンの影響で一時的に生産性は上がるが早晩バテる
    • 80〜90時間を超えたら、休ませるべきである
      • アドレナリンの影響で一時的に生産性は下がらないが早晩バテる。週90時間以上働くと必ず生産性が下がる。
  6. コミュニケーション
    • プロジェクトマネージャは、チーム・メンバーを政治ゲームから守ってやらなければならない
    • しかし、何が起こっているかは伝える必要がある
  7. チームの構成(デスマーチチームに必要な役割と分担)
  8. 作業環境(集中できる環境をどんなことをしても確保すべき）
    • スカンクワークが最強。スイートルームとはいかないが、会社から離れた倉庫や雑居ビルにプロジェクトルームを作る
  9. プロジェクトマネージャがこれだけいろいろしてやれば、手下どもは喜んでデスマーチに身を捧げるだろう
↑

デスマーチプロセス †

  1. トリアージの考え方をマネジメントに導入して、そこそこ使える(good enough)システムを目指す
    • トリアージ
      災害医療において多数の傷病者が発生した場合に、治療の優先順位を決める方法
      順位類タグ状態
      1最優先治療群赤色直ちに処置を行えば、救命が可能な者
      2非緊急治療群黄色多少治療の時間が遅れても生命には危険がない者
      3軽処置群緑色軽易な傷病で、ほとんど専門医の治療を必要としない者
      4不処置群黒色既に死亡している者又は直ちに処置を行っても明らかに救命が不可能な者
    • デスマーチでは要求の順位付けが極めて重要
      順位類
      1やらねばならぬ要求
      2やった方がいい要求
      3やれればやる要求
  2. 要求の順位付けをするためには要求を管理する必要がある
    • ここ20年にわたり、DFD/ER図/UML など要求のモデルを作ることに力が注がれてきた
    • ところが要求を管理することは、極めて重要であるにもかかわらずなおざりにされてきた
      • 要求の優先順位は動的に変化してとらえどころがない
      • デスマーチプロジェクトでは、要求モデルとソースコードがかけ離れている場合が多い(ソースコードが正式文書なので、それからかけ離れた要求モデルに順位をつけても意味がない)
    • 最近要求管理を行えるツールが登場してきた
  3. 逆説的な言い方だが、既にデスマーチになっているプロジェクトに、新しい管理手法を導入してはならない。さらなる混乱を招くだけ。
↑

プロセスのダイナミックス †

  1. プロジェクトでは多数の構成要素が複雑に影響し有っている。
    • 複雑系では、ほんの少しの変化がフィードバック効果を起こし全体に大きな影響を与えることがよくある。
    • 例えば、退職率の数％の上昇が、巡り巡ってプロジェクトを崩壊に導くかもしれない
  2. iThink というツールを使うことによって、この複雑なフィードバック系を事前にシミュレートすることができる。
  3. シミュレーションを行い、どこがボトルネックになるかを事前に見極めておく必要がある
↑

クリティカルチェーンと制約条件の理論 †

  1. これまで、スケジュールを立てる際には、成果物同士の依存関係によって発生するバッファ（仕掛かり在庫)が意識されることがあまりなかった
  2. クリティカルチェーン・スケジューリング戦略は仕掛かり在庫を最小限にするスケジューリング法
  3. 「クリティカルチェーン」(エリヤフ・ゴールドラット 2003)を読んできちんと勉強すると、週80時間労働から救われるかもしれない
↑

時間の管理 †

  1. 会議を効率的に行う(Amazonで軽く1ダースは見つかる会議本を参考にせよ。基本的なことで十分効果的)
  2. 利害関係者の無意味な異議
    • どんな問題もこのプロジェクトでは発生から24時間以内に解決することを、プロジェクトの最初に同意をとっておく
    • さもないと、プロジェクトは際限なく遅れる(遅れて困るのはあなたで、誰の責任かは関係ない)
  3. タスクに優先順位をつけて処理すべき。 
    緊急性
  ↑
  ｜Q3(低重要度・高緊急性)     Q1(高重要度・高緊急性)
  ｜Q4(低重要度・低緊急性)     Q2(高重要度・低緊急性)
  ＋──────────────────────────→重要度
    • メールの自動仕分け(半分冗談)
      • 日に100通のメールを処理すると、10分に1通処理しなければいけない。これでは「実務」をできない
      • そういうときにはメールには一切返事をしない。誰かが怒鳴り込んできたら、それがQ1案件であると自動的にわかる
↑

進捗の管理と制御 †

  1. デスマーチプロジェクトに起きる現象
    • 見積もりが非常に楽観的 (10%,50%ではなく100%,1000%のオーダーで楽観的)
    • 進捗の管理と制御が行われていない
  2. 進捗の管理について
    • 「９０％完了」は危険な幻想。進捗は０％か１００％で管理すべき
    • 進捗は単体テストが通った段階で数えるべき
      • Microsoftの毎日構築アプローチはすばらしい
      • 毎日深夜にテストスクリプトを動かしてその結果を以て進捗とする
      • Win95の出荷版は、Build951
  3. 進捗の制御について
    • デスマーチプロジェクトの進捗の制御は、リスクマネジメント
      1. リスクを評価する
      2. リスクを制御する
      3. リスクを回避する
    • リスクが表面化してから対処する（「火消し型」）では、早晩プロジェクトは危機的状況を迎える
    • あらかじめリスクを算定することが大切
      • リスクが表面化しても組織の許容範囲内に収まると算定できれば安心できる
      • 許容範囲内になければ表面化してプロジェクトが制御不能になる前に全力でつぶす
    • リスクの出現に最初に気づくのはたいてい底辺の労働者なので、デスマーチプロジェクトではチーム一丸となってリスクマネジメントをする必要がある
    • 多くのプロジェクトで設置される「リスク管理監査官」は実際には役に立たない
    • リスクは見ないふりをされることが多く、そうこうしているうちに本当に忘れられてしまうことがあるので、きちんと記録に残しておくことが必要
    • リスクにまで発展していない問題に関しても記録に残しておくことが必要
  4. とにかく官僚主義を避けよ
    • たとえば、政治的な大レビュー会はデスマーチでは単なる無駄。全員の貴重な１日をつぶしてしまう
    • 同僚同士のピアレビューが効果的
    • というような実践的な教訓を書き残しておくことが必要（数ヶ月おきに、たとえばイテレーション終了日の午後を使ってポストモーテム＝ミーティングを開くのがよい）
↑

デスマーチのためのツールと技術 †

  1. 必須のツール
    1. 電子メール
    2. グループウェア
    3. RAD開発ツール
    4. バージョン管理システム
    5. テスト・デバックツール
    6. プロジェクトマネジメントツール(見積もり・日程・PERT図・ガントチャート)
    7. ツールキット・再利用コンポーネント
    8. CASEツール
  2. 必ずしもソフトウェアにこだわる必要はない。壁にピン留めした巨大な図が最強のツールとなりうる場合もある
  3. ツールを銀の弾丸にできるたった一つの方法は、プロセスを変えざるを得なくすること
    • コンパイラが10倍早くなったので、以前の詳細設計を慎重に行うプロセスから、テストファースト開発に進化することができた
  4. 再利用はすばらしい
    • ツールキットを使ったり、通信や描画をブラウザに任せることによって再利用率が20%から80％にあがったら、それだけで生産性が4倍になる
  5. 新しいツールを導入するには教育が必要なことをお忘れなく
    • 5日間のワークショップに参加しても使いこなせるようになはならない
    • 習熟には数ヶ月〜6ヶ月必要
    • デスマーチプロジェクトになんの支援や教育もなく新しいプロセスを導入するとかえって混乱を招く
    • 限定的に導入・導入しないのも一つの賢いやり方
↑

戦争ゲーム †

  1. プロジェクトマネージャーはデスマーチのシミュレーション訓練を行う必要がある
    • プロジェクトで起こる様々な事件に対する対処法をシミュレーションし最適解を検討する
      • テーブルトークRPGのように中立的なゲームマスターをたてて事態を進行させる
      • さいころの代わりにDYNAMOやiThinkを使って、プロジェクトマネージャーの選んだ対処法の影響を客観的に導き出す
  2. 惜しいことに、DOOM や Sim City のように、コンピュータ上でできるデスマーチ・シミュレーション・ゲームは現在の公開されていない (昔有ったが.comバブル崩壊で消えた。コンサル会社が講習に使うために開発したものはいくつかある)

Culture

トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS   sitemap
Last-modified: 2006-07-12 (水) 02:01:13 (7088d)
Short-URL: http://at-sushi.com/pukiwiki/index.php?cmd=s&k=075f84b26a
ISBN10
ISBN13
9784061426061