デス・マーチとＣＭＭ

（１９９９／２／１４，２０全面見直し＆一部項目の追加・訂正）

　『デスマーチ』（Ｅ．ヨードン著、松原友夫／山浦恒央訳、トッパン刊）という本が出ています。既に読まれた方も大勢いるのではないでしょうか。この本の副題に「なでソフトウェア・プロジェクトは混乱すのか」とある通り、この本は、現状のソフトウェア開発現場の混乱の状況を分析し、デスマーチに陥らないための幾つかのヒントが紹介されています。

　この本の論点は、最後の７章「常態としてのデスマーチ・プロジェクト」にあります。それは原書の副題が「The Complete Software Developer's Guide to Surviving "Mission Impossible" Projects」となっていることからもうかがい知ることが出来ます。要するにこの本は、これからは市場の要請も厳しくなって「デスマーチ」が「常態化」する。そのような中で生き残るためには、デスマーチにうまく対応する方法を見つけることが条件になる、というのです。ただし、その方法は明快には示されていません。

　我が国においても、多くのソフトウェア開発組織の実態は、その組織の大小を問わず、この本と同じように「デスマーチ」に陥っていると思われます。ニフティのフォーラムやこのホームページの多くの読者から送られてくるメールからも、混乱の淵の中にいる様子が窺えます。

　このような状況の中にいるソフトウェア・エンジニアやプロジェクト・マネージャーがこの本を読んだとき、現状を脱する手立てに気づくよりも、先ずは自分たちと同じような境遇のエンジニアがアメリカにも沢山いることに慰められるでしょう。さらに７章の「常態としての・・・」では、読み方によっては、これからは全てのプロジェクトがデスマーチになることは、ごく普通のことである、とも読むことが出来ます。それはある意味では慰めでもありますが、同時に、避けられないものとして、デスマーチに陥らない方法を探すのを止めてしまう危険も感じます。

　そうでなくても、この本は全般にわたって、デスマーチの原因や、その実態についての記述が圧倒的に多く、対応策の説明が少ないのです。そのため、“うん、その通りだ！”“自分だけではないんだ！”と、そこに書かれている「混乱の姿」に、自分たちと同じ「もの」を感じるものと思われます。この本に書かれている読者の投稿なども、ある意味での親近感を感じるのではないでしょうか。

　もう一つの問題は、そこに書かれている幾つかの対応策自体が、読者、すなわち現実に混乱の中にいる人たちにとっては、手の届かないもの（方法）であることです。実際、「Triage という概念」の導入や、「要求管理の重要性」「ベストプラクティス」の勧め、など、対応策としては悪くはないのですが、現実にデスマーチ．プロジェクトの中にいる人たちにとっては、もっと消化しやすくしないと、とても手に付かないでしょう。

　「デスマーチ」の状態は、偶然に１回だけ陥るのではなく、１度陥ったら、そこから抜けられない性質を持っています。といっても、そんな大げさな仕掛けがあるのではなく、何らかの要因で１つのプロジェクトが遅れることによって、次のプロジェクトの開始時期に重なってしまい、その結果、事前の準備工程などが省かれるため、必然的に次のプロジェクトもデスマーチになるのです。たった一度の失敗が、デスマーチから抜け出せなくなるのです。

　したがって、現実には、デスマーチしか存在しない組織と、デスマーチには縁のない組織に分かれることになります。そして、いつもデスマーチに見舞われている組織のソフトウェア・エンジニアには、この本に書かれているような対応策の切り口では別世界のこととなってしまい、結局は、「上手い方法なんてないんだ」と、自分を慰めるか、諦めさせて、重い足を引きずりながら『混乱の館』に戻ることになります。

　でも、それでは何も解決しません。そこで、このページでは、ＣＭＭのレベル１から２への取り組みによってデスマーチを避ける、あるいは緩和できる方法について、私の考える所を述べることにします。

参考）『デスマーチ』－なぜソフトウェア・プロジェクトは混乱すのか

　　　エドワード・ヨードン＝著　松原友夫／山浦恒央＝訳

　　　トッパン　刊、　ISBN4-8101-8982-1

　　　１．　デスマーチの定義について

　　　２．　デスマーチは何故起きるか

　　　３．　何が問題か？

　　　３．１　もともと無理なプロジェクトか？

　　　３．２　経営者のわからずや？

　　　３．３　見積りミスが原因か？（1999/2/20　訂正）