デスマーチの構造： プロジェクトは始まる前に失敗している Vol.1：ITアーキテクトを探して （14）（1/2 ページ）

2007年1月30〜31日の2日間、東京・目黒雅叙園で「ソフトウェアテストシンポジウム 2007 東京（JaSST'07 Tokyo）」が開催された。初日に行われた基調講演には、ソフトウェア開発方法論の世界的権威であるエドワード・ヨードン氏を招き、「デスマーチ　ソフトウエア開発プロジェクトはなぜ混乱するのか」をテーマに、著書「デスマーチ第2版」の内容から、高品質ソフトウェアを開発するための方策について語った。

[構成：唐沢正和，＠IT]

　「ソフトウェアテストシンポジウム 2007 東京（JaSST'07 Tokyo）」は、ソフトウェアテストやソフトウェア品質に関する技術交流・情報交流・人的交流を図ることを目的に開催されるイベント。NPO法人ASTER ソフトウェアテストシンポジウム東京実行委員会が主催し、テストツールや開発ツール、サービスの導入を検討する企業のための情報収集の場として、またアカデミックすぎない現場のための技術、方法論、ツール、サービス紹介の場として、2日間で延べ1300人の来場者を集めた。

エドワード・ヨードン氏：「デスマーチ ソフトウエア開発プロジェクトはなぜ混乱するのか」という題で講演を行った

　シンポジウムでは、エドワード・ヨードン氏の基調講演をはじめ、デバッグ工学研究所の松谷徹氏による招待講演「ソフトウェアテストの展望：SW機能テストから、システム挙動の評価へ」、パネルディスカッション「“Taming a Monster”　品質をいかにコントロールするか」が行われたほか、さまざまなセッションが用意され、1日目のセッション終了後には情報交換会も開催された。

　今回は、これらのセッションの中から、エドワード・ヨードン氏の基調講演の内容を紹介する。ヨードン氏は、ソフトウェア開発支援コンサルティング企業であるNODRUOY社の協同創立者で、約40年間、多くのソフトウェアの開発に携わり、27冊の技術書と550以上の技術論文を著している。今回の基調講演では、その著書「デスマーチ第2版」の内容から、「デスマーチ　ソフトウエア開発プロジェクトはなぜ混乱するのか」と題し、ソフトウェア開発プロジェクトが“デスマーチ”となってしまう原因の分析と対策など、高品質ソフトウェアを開発するための方策をコンサルタント経験を交えて紹介した。

スケジュール・人材・予算に厳しい制約

ヨードン氏：

　今日は「デスマーチプロジェクト」について、私の書いた著書の中から、いくつかのトピックをまとめながらお話ししていきたいと思います。まず、「デスマーチプロジェクト」とはいったい何なのかを説明しておきましょう。米国では、まったく説明する必要がないほど浸透している言葉なのですが、日本ではあまりなじみがないかもしれません。「デスマーチプロジェクト」には、いくつか共通した特徴がありますが、一番よくある特徴は、非常にスケジュールのプレッシャーが大きいという点です。要するに、ソフトウェア開発のプロジェクトを、自分の考えている以上に短い時間で終わらせなくてはならないという状況です。

　もう1つの特徴は、エンジニアの人員不足です。例えば、10人掛かるプロジェクトだと思っていたものが、実際には5人でやらなくてはならない状況。これには、予算不足の問題も絡んできます。追加で人材を入れたくてもそれだけの予算がない、さらに新しいソフトウェアのツールを買いたいと思っても買えない、という予算に制約のあるプロジェクトも「デスマーチプロジェクト」になります。そして、リスクが高いという点も「デスマーチプロジェクト」の要素です。通常のプロジェクトよりも失敗の可能性が高く、50％以上の確率で失敗してしまうともいわれています。

　では、なぜ「デスマーチプロジェクト」は生まれるのでしょう。それには政治的な要素が大きくかかわってきます。ほとんどのエンジニアは、さまざまなエンジニアリング、コンピュータサイエンスの場面でたくさんの経験を積んできていますが、一方で、政治的な部分にはできるだけかかわりたくないというのが本音だと思います。しかし、「デスマーチプロジェクト」の中では、政治的な要素が非常に重要なカギを握っています。

　十分な時間がない、人材がいない、予算もない、……。そんな状況の「デスマーチプロジェクト」は、政治的な圧力で立ち上がります。そして、そこで成功を収めるために、プロジェクトにかかわるエンジニアは、より多くの残業が求められます。しかも、毎日1〜2時間の残業ではありません。かなりの残業が強いられることになります。

　ここで、1960年代、私が若いころに携わった「デスマーチプロジェクト」の実例をご紹介します。それは2年間のプロジェクトでしたが、この間に休んだのはわずかに2日間だけでした。1日はクリスマス、それが1年目。そして2年目は、独立記念日でした。それ以外は1週間7日、1日12時間から16時間くらい働いていました。54時間、休みを取らず寝ないで働き続けたこともあります。ただ、そのときは非常に若く、独身で、面白いプロジェクトであったことも、過酷な仕事を続けられた背景にあります。

　こうして必死で取り組んだプロジェクトですが、実は成功することはできなかったのです。予算的には数百万ドルのプロジェクトでした。これは、私にとっては非常に驚くべきことでした。といのも、私も含め、すべてのチームメンバーが一所懸命働いていましたし、これだけ頑張ったんだから、絶対成功するはずだと思っていたからです。しかし、実際には失敗に終わってしまいました。チームメンバーの中には自律神経失調症になってしまったり、離婚して家族を失ってしまった人もいます。それ以外にも、健康上の問題を抱えた人は多くいました。このように、個人の犠牲を払わなくてはいけないプロジェクトは、まさに「デスマーチプロジェクト」といえるでしょう。これでは、多くの残業をしたとしても、クオリティも生産性も非常に低いものになってしまい、求められる結果を出せなくなってしまうわけです。

　それから40年がたち、テクノロジも進化しました。1960年代に比べたら、コンピュータは何百万倍もパワフルになったといえます。ですが、「デスマーチプロジェクト」はまだ存在します。しかも、その数は、いまの方が多くなっているのではと感じています。