エドワード・ヨードン、デスマーチを成功に導く対症療法を説く

ソフトウェアシンポジウム「JaSST'07 Tokyo」の基調講演を務めたエドワード・ヨードン氏は、デスマーチに見られる問題点には、きわめて人間くさい部分が大きく影響していると述べた。

[西尾泰三，ITmedia]

　「デスマーチは人や予算を増やせば解決するという短絡的な問題ではない」――ソフトウェアテスト技術振興協会（ASTER）が開催したソフトウェアシンポジウム「JaSST'07 Tokyo」のオープニングキーノートを務めたのは、エドワード・ヨードン氏。失敗プロジェクトの代名詞となった「デスマーチ」という問題を取り上げた「デスマーチ」の著者である同氏が、「デスマーチ――ソフトウエア開発プロジェクトはなぜ混乱するのか」と題し、デスマーチの原因や対策について語った。

「xpなどの開発手法はあくまで手法であり、それ以前に考えるべき問題は多い」エドワード・ヨードン氏

　冒頭、同氏はデスマーチとは何かを再度定義した。いわく、「スケジュール（納期）のプレッシャーが強く、人員も予算もそれに見合ったものでなく、さらに高い確率で失敗することが予測される」ソフトウェア開発プロジェクトがデスマーチプロジェクトであると話す。

　「わたしもこの業界で43年のキャリアがあり、22歳のころエンジニアとして参加したプロジェクトでは、2年間のプロジェクトで休日はクリスマスと独立記念日の2日のみ。しかも結果としてそのプロジェクトは失敗に終わった」（ヨードン氏）

　続けて同氏は、ケーパース・ジョーンズ氏の著書「Patterns of Software System Failure and Success」から調査結果を引用し、大規模プロジェクトになればばるほど、当初の見積もりとは大きくかい離したものになり、かつ失敗する可能性が高いことを示した。「（一般的なプロジェクトも含めた調査結果でさえこれなのだから）デスマーチについては推して知るべし」とヨードン氏。見積もりというものはベースとなるものがないと難しく、それがなければ単なる推定でしかないと話し、こうした見積もりを行う部署または人材、さらには適正な見積もりのために商用ツールの必要性を説いた。

	Early	Ontime	Delayed	Canceled
1FP	14.68％	83.16％	1.92％	0.25％
100FP	6.06％	74.77％	11.83％	7.33％
10000FP	0.14％	28.03％	23.83％	48％
100000FP	0％	13.67％	21.33％	65％
Average	5.53％	56.94％	13.71％	23.82％

調査結果の抜粋。FP（ファンクションポイント）はジョーンズ氏が定義している単位で、1FPが100行程度のコードであるという。1FPであればほぼ納期を守れているが、1000万行規模のコードが求められるプロジェクトでは、納期を守れるのは14％程度で、しかも65％近くがプロジェクトのキャンセルにつながっていることが分かる。

	Min	Actual Average	Max	Estimate
1FP	0.06	0.16	0.4	0.15
100FP	3.6	10	19	9
10000FP	24.9	49.8	84.66	36
100000FP	44.28	73.8	132.84	48

こちらはプロジェクトマネジャーの見積った（Estimate）プロジェクトの月数と、現実のかい離を示すもの。1FPであれば、ほぼ見積もった月数（0.15）と同等の期間（0.16）で納品できているが、10万FPになると、見積もり（48カ月）と現実（73.8カ月）に大きなかい離が見られることが分かる。

　こうした現実をふまえ、デスマーチをどうマネジメントすべきかについてヨードン氏は、その問題の本質を「政治的な部分」「交渉」「人的な問題」「開発手法」などに大別してそれぞれ語った。特に、「政治的な部分」に重点を置いた同氏。ここでいう「政治的」とは、そのプロジェクトに関係する利害関係者すべての関連性から生じるものであるが、プロジェクトを成功と見なす要素は何か、誰がそれを判断するのかといったきわめて基本的な部分が誰にも説明できなくなっているのではないかと述べた。

　そうした状況下にあって有効なのは、プロジェクトの初日に、そのプロジェクトの実現可能性や、そのプロジェクトがデスマーチになっているかどうかの判断を誰が行うのか、要件などに未決のものがないかなど十分な情報収集およびドキュメント化を行い、それについてキーとなるステークホルダーすべてからコンセンサスを得ておく必要があると話す。

　「要件定義にしてもステークホルダー間でしっかりと定義されていなければ、やり直しや追加が発生し、いずれは政治的な要素に発展する。往々にして起こるものだが、自身にとって都合の悪いものは、都合よく忘れてしまうもの。すべての利害関係者の間で合理的な交渉などはあり得ず、そうならないためにもドキュメントとして残しておくべき」（ヨードン氏）

　さらに、チームとしての生産性の向上を考えた際にできることはないかを考えると、時にはルールを破ってみることも必要ではないかと話す。その一例として、生産性の高いプロジェクトでは作業に集中できる環境が整っている場合が多いことを挙げ、在宅勤務などの施策も本来であれば取り得るはずであると述べるなど、各人のプロジェクトに対する忠誠心とコミットメントをいかにはぐくむか、言い換えれば、仕事が好きになる方法を考えるべきではないかと説いた。

　「開発現場に届けられる言葉は、演説調に美談などが挟まれようが結局のところ「もっと働け」ということに集約されており、開発現場のスタッフからするとそのプロジェクトの忠誠心もコミットメントも育ちようがない。すでにデスマーチに陥っているのなら、少しくらいアグレッシブになる必要があるのではないだろうか。ルールに縛られている状況から、ルールを破って現状を打破することも検討してみるべき。各人がプロジェクトの課程を楽しめることができれば、少しくらいの苦痛でも耐えられるはずなのだ」（ヨードン氏）