=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
【狙い】システム思考を応用したリカバリーマネジメントができるようになる
【対象者】プロジェクトリーダー、ＰＭＯ
【効果】リカバリーの実施に関する意思決定の基準を知ることができ、さらに、「まず、安定化」を基本方針としたリカバリーの方法を習得できる
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
__《 このセミナーの効用は 》___________
知識を得る ★★★★
実行力を高める ★★★★
思考力を高める ★★★★
__《 このセミナーへのイントロ 》___________
プロジェクトマネジメントへの熱心な取り組みにより、納期に遅れたり、予算をオーバーするプロジェクトは減ってきました。一方で、ＩＴ業界で「デス・マーチ」と呼ばれるプロジェクトの割合はそんなに減っていません。
デスマーチという言葉は、ソフトウエアエンジニアリングの大家の一人であるエドワード・ヨードンが軍隊の「デス・マーチ」という訓練に見立てて命名したと言われています。具体的には、
人員不足、短すぎる開発期間、予算不足、ユーザからの過剰な要求などの悪条件が重なり、開発チームが過度のオーバーワークや疲弊状態に陥った状態
を指します。
デス・マーチはスタティックな（静的な）問題として取られられる傾向があります。つまり、受注条件、あるいは、要求です。このため、組織として、受注条件や要求の評価（見積もり）に力を入れ、初期のリスク対応をすることによって対応しようとします。
しかし、現場のプロジェクトマネジャーは肌で感じているように、デス・マーチはダイナミックな問題です。しかも、悪循環という典型的な「システム」問題です。したがって、デス・マーチを回避したければ、システム思考的アプローチをする必要があります。
つまり、悪循環を断ち切り、プロジェクトを落ち着かせた上で、好循環を生み出すような手を打っていきます。
たとえば、上のデス・マーチの記述を見てください。開発期間が短く、要員も足らないので、無理な作業（突貫工事）をします。すると、メンバーはだんだん疲れてきて、成果物の品質が下がってきて、リワークが発生します。それによって、スケジュールがますます、苦しくなります。
そこで、新規の要員を追加投入します。すると、コミュニケーションの負担が増え、既存メンバーの生産性はますます下がり、スケジュールに悪影響を与えます。
実際に、以前にメンバー１０名ほどのトラブルプロジェクトで生産性の分析をしたことがあります。このプロジェクトでは顧客との要件合意に齟齬があり、徐々にスケジュールが遅れ、組織として介入するレベルに悪化したので、要員投入を行いました。しかし、その２か月後には生産性が当初計画の３０％強まで落ちていきます。初期計画が妥当だったとしても、１０人が３人分しか働いていないわけですので、初期要員を倍にしても間に合わないことになります。
作業効率もそれなりに落ちましたが、ここまで落ちたのは作業従事時間の問題で、人が増え、打ち合わせがやたらと増え、当初計画の８０％がなんと４０％まで落ちたのです。
図：デスマーチのダイナミックス
ここで、重要なポイントは、要員投入をするタイミングで、生産性の低下が続いていたことです。さらにスケジュールを遅らせてもよいので、まずは生産性の低下を防ぐべきだったのです。これがデス・マーチを起こさないリカバリー・マネジメントの方法です。
この講座は、デス・マーチを起こさないリカバリーマネジメントの方法を体系的に解説します。
