デスマーチの行進の仕方

 とりあえず、移行が1年延期が発表されたみずほ銀行のシステム統合の行方を占ってみる - プロマネブログ

前回、みずほ銀行のプロジェクトが炎上しているんじゃないかな、と書きましたので、そこからの派生。

システム開発などプロジェクトに関わり続ける限り、いつ遭遇してもおかしくないのがデスマーチ。

クマに遭遇した時にやり過ごすために死んだフリすることもありますが、デスマーチに出会った時にやり過ごすための主な方法についてちょっとまとめてみます。

基本はQCDの再調整

デスマが発生した場合、いろいろなやり過ごし方がありますが、基本はQ(quality：品質)C(cost：費用)D(delivery：期限)を見直すことが基本です。

現在対処が必要となるプロジェクトの要求がプロジェクトメンバーの処理能力の限界を超えた時、往々にしてデスマが発生します。つまり、プロジェクトメンバーの処理能力の範囲となるよう、QCDを見直すということです。

Qualityを見直すということは、品質面を軽度にし、目標をより作りやすいものとすることです。

Costを見直すということは、プロジェクトの生産力を増加させるため、増員や環境などに投資を行うことです。

Deliveryを見直すということは、目標となる成果物作成期間を後ろ倒しにして、時間を稼ぐことで対処を行うことです。

他にもいろいろな方法がありますが、上記方法を抑えておけば大体の場合には対処可能です。

Qualityの再調整　(　設計～システムテストで問題に遭遇した時の対策　)

Qualityの再調整を行う場合は、

1. 要件
2. 仕様
3. 作り

のいずれかを見直すこととなります。

要件見直し（要件定義の見直し）

お客と合意した要件の見直しです。当然、当初約束していたことができなくなるのでお客は嫌がります。このレベルの見直しを行おうとする場合は、基本は政治力の勝負です。

とうとうと現在の仕様で進めた場合の破綻の危険性を説明して要件を削減してもらったり、カンタンに作れる代替案を用意しそちらの仕様に変更してもらったりととにかくお客に納得してもらえるよう、ありとあらゆる泥臭い交渉を行います。

オッサンの得意な交渉は後載せ案件化。とりあえずデスマになった時は、最小限度の機能構築にとどめ、不要不急だけどつくろうとしたモノは全て次回の案件にするってかんじですね。時には、暫定的な業務補助のためのフォローシステムを作ったりもします。

仕様の見直し（外部設計の見直し）

お客へ提供するシステムの機能を縮小し、とりあえず業務を維持できるレベルの品質で提供するよう交渉することとなります。

例えば普段は10回ぐらいしか発生しない業務で1000回連続で取引を行うとトラブルが発生する、や日本の国家予算以上の金額で取引をするとトラブルが発生するなど、通常の利用範囲外に対する保証を削ったりします。

要は、普段使いだけ保証して、それ以外は使わないよう制約とします、みたいな感じです。要件定義と異なり、お客側現場の実担当者と交渉しながら落とし所を調整したりします。

作りの見直し（内部設計・詳細設計・プログラミングの見直し）

お客に見えない部分で楽をしようという作戦です。要は「アーキテクチャやコードを汚くしてもよいから動くものを作る」。

保守性や性能などお客から見えない部分が悪化する事となりますので、お客との交渉は行わずに対応することができますが、プロジェクト内部でどこまで許容するか決めなければなりません。

とりあえず、で無秩序に行うと、保守性などが致命的な事になりますので注意が必要です。

とまあ、上記のように品質を対応可能な範囲にまで下げることで対処しようってわけです。個人的な実感として、効果は「要件見直し＞仕様見直し＞作りの見直し」、対応の容易さは「作りの見直し＞仕様見直し＞要件見直し」って感じです。

どの手段を用いるかはお客との関係次第になるかと思いますが、要件見直しはハードルが高く、作りの見直しは生産性が低下しかえって事態が悪化する場合もありますので、仕様見直しが一番やりやすというのが実感です。

作りの見直しは、当初のアーキテクチャに不良など設計の問題がない限りは手を出さない方が無難。さらに問題が発生した場合、二次災害になりかねません。

※お客への交渉力がない場合は、下手に作りを見なおしてドツボにはまる場面があったりするんでしょうね。。。

Costの再調整　(　プロジェクト通期で問題に遭遇した時の対策　)

 当初予定していたプロジェクト処理能力では対処しきれなくなったということで、プロジェクト処理能力を向上させれるよう、追加要員や高スキル要員の導入、効率的なツールの購入等で対処する方法です。

デスマの原因次第ですが、プロジェクトで発生した課題の難易度が高いといった理由で詰まっている場合は「少数の有識者・高スキルメンバーの追加」。分割可能なタスクで担当者が不足している場合は「要員の追加」。作業環境がダメダメで仕事にならないって場合は「開発環境の改善」。とまあ、問題に応じてプロジェクトに追加投資を行う形です。

請負で仕事する場合、利益を食って対応するわけです。前述のQualityの再調整とは異なりお客との交渉は不要ですけど、社内のステークホルダーとの交渉が必要な感じですね。

きちんとプロジェクトの問題を分析した結果、生産性に問題があった時にだけしか適応できないです。

単純に要員を追加しても問題が解決しないってのは、ブルックスの法則（人月の神話）のとおりですが、要員を追加しなければどうしようもないって場面もあったりするので、きちんと状況を分析することが必要です。

人月の神話―狼人間を撃つ銀の弾はない (Professional Computing Series)

Deliveryの再調整　(　プロジェクト通期で問題に遭遇した時の対策　)

目標とする期限には間に合わなさそうだが、時間があればなんとか解決できそうな場合に期限を延長することで時間稼ぎを行う方法です。

通常、納期には余裕を持たせているわけですが、その余裕期間を超過しても対応が間に合わない場合は期間の調整を行うこととなります。

当然、お客は嫌がります。なので、調整できない、政治力が必要となったりすることもしばしば。

また、単純に期間延長したとしても、他に問題があり解決できてない場合は、結果として期間が間に合わないこともよくある話。

なので、単体でDeliveryの調整だけを行うことはめったにありません。

例えば、QualityやCostの再調整による問題解決のために、時間を稼ぐ目的でDeliveryの調整を行います。

まとめ

それぞれQCDの調整方法をざっくりと上げてみましたが、デスマーチが発生した場合に対処するためには、まずはプロジェクトの運営課題の分析を行った後、QCDのいずれ、もしくは複数の手段を選択する事となります。

なので、きちんとプロジェクトを見ていないと対策を打つことができません。

プロマネはきちんとプロジェクトをウォッチし、問題の兆候を素早く検知することが必要です。

また、お客との交渉力も重要です。ここまで来るとプロマネの政治力の有無がプロジェクトの生死に影響を与えます。

そういった意味では、プロマネはお客との交渉力を鍛え、時にはバーター条件を設計に組み込むだけの柔軟な設計ができる力が必要となりますね。

こういったトラブル対応が得意なプロマネっているんですよね～。

よく火消し屋なんて呼ばれたりするんですけど、こういったプロマネってデスマや障害発生時に重宝します。

※プロマネの種類はあとでまとめようかな。。

とまあいろいろ書きましたが、なにも考えずにデスマーチに突撃するよりも 、対応方法をきちんと知っておくだけでも討死率は減ると思います。きちんと対策を理解して楽しくデス・マーチを行進しましょう！

※ま、デスマにならないようきちんと事前に対応するのが一番ですけどね。

以上