デスマーチは、納期や予算、開発規模といった諸条件が極度に厳しいソフトウエア開発プロジェクトを指す。ヨードン氏は「デスマーチは常態」とし、ソフト技術者が生き残るためには、交渉やコミュニケーションの力が重要と説く。ソフト工学の草分けであるヨードン氏にソフト開発の現状と将来について尋ねた。（聞き手は桔梗原 富夫）
ソフトウエア開発プロジェクトの混乱をテーマにした『デスマーチ』（死の行進）を興味深く読みました。この本を書くきっかけは何でしたか。
第一版を書いたのは1996年です（出版は97年、邦訳は98年）。当時、期間が短い上に、技術者も足りない開発プロジェクトが増えている様子を目の当たりにしたので書きました。いわゆる“ドットコムブーム”が始まり、シリコンバレーでデスマーチ・プロジェクトが増えていた時期でした。Y2K（西暦 2000年問題）対策が始まった頃でもありました。
ところが、そうした状況下に、デスマーチ・プロジェクトに全くなじみがない、認識もない、若いプログラマー世代がいたわけです。そうした世代に向けて、過去の色々な経験とそこから得られた知見を伝えることができれば、若い世代の役に立つのではないかと思って書いたのです。私自身は1966年からデスマーチ・プロジェクトにかかわっており、第一版を書いた時点で30年間の経験がありました。
今回、ソフトウェアテストシンポジウム（JaSST）注）に参加して、日本の若いソフト技術者の方々にお会いしました。皆さん、「自分が参加しているプロジェクトだけがデスマーチだと思っていた」と仰るのですね。デスマーチが共通の現象であることをまだ認識していらっしゃらないようです。
2004年に出された第二版（邦訳は2006年）において「デスマーチ・プロジェクトは、常態であって、例外ではない」と結論付けていますね。2007年の今でも状況は同じでしょうか。
ええ。2000年以降、景気の後退ですとか、ドットコム産業が崩壊したとか、Y2Kプロジェクトが終わりを迎えた、といった理由で、デスマーチ・プロジェクトの発生はスローダウンしましたが、今はまた増えています。
 |
| 写真●『デスマーチ』著者・コンサルタント エドワード・ヨードン氏 |
増えている理由はいくつかあります。一つは、グローバルな競争が激化しているということ。日本企業も米国企業も以前にも増して、新しい製品、新バージョンを早く市場に出さなければいけないというプレッシャーを受けています。しかも、ソフトはどんどん複雑化しています。ここにある携帯電話には、300万行ものソフトが入っています。携帯電話のようなシンプルなデバイスであっても、写真も撮らなければいけないし、音楽も流さなければいけない。ありとあらゆる機能が要求されていて、しかも短時間で開発しなければならないのです。10年前に『デスマーチ』第一版を世に問うたときより、複雑性ははるかに増しています。
問題は技術ではなく“政治”にあり
20年前、私はアセンブラでプログラムを記述していました。その後、新しい開発言語やツールが出て、ソフト工学の世界が開けました。それでも、デスマーチはなくならないのですね。
確かに、よりよいプログラミング言語、よりよい開発ツールが存在しています。ソフト工学の手法は20年前と比べるとかなり改善されてきました。ところが、デスマーチの課題というのは、技術やソフト工学の側面ではなくて、プロジェクトの交渉など、主として政治的な部分にあるのです。
今日では、様々な手法があり、ソフトを開発するのにどのぐらいの期間が必要になるのかを、かなり正確に予測できます。ところが、手法を使って出した正確な開発期間を、企業の上級幹部が政治的にはねつけてしまう。「競争が激しい。開発期間をもっと短くせよ」と言ってくる。こうして色々な問題が発生していきます。
20年前、開発期間を予測する手法は非常に原始的なもので、正確とは言えなかった。このため当時の上級幹部は、開発期間の数字を出したソフト技術者に対し、「無能だ」と言いました。今は正確な数字を出しているのに、「非協力的だ」、「頑固だ」と言ってくる。結果はどちらもデスマーチです。
上級幹部の考えを変える方法はありませんか。
政治的側面から言いますと、危機に直面して初めて変わることができるのではないでしょうか。日本の企業も米国の企業も、ソフトでも、それ以外でも構いませんが、市場で大きな問題に直面して初めて、「変わらなければいけない」、「改革しなければいけない」となってくる。残念ながらそれが唯一の機会ではないかと思います。
先ほど指摘された政治や交渉ごとにソフト技術者はあまり興味を持てないように思います。
プロジェクトの成功にとってそれが非常に重要であるということを認識するようになれば、少なくとも一部の人は関心を持つようになるでしょう。もちろん、全員が政治をうまく動かすというようにはならないと思います。そもそもソフトの世界で働きたいという人の多くは、政治的なことが嫌いでソフトの仕事を選んだわけですから。
一番大事なのは、認識を持たせることです。私自身、若きソフト技術者であった頃、ソフトの問題は技術者の自分が現場で解決していくものと思っていました。大学で勉強したときも、人間的要素あるいは政治的な要素がソフト開発に関連している、といった話は一度も聞きませんでしたので、そういった認識に向かえなかったわけです。
今まで27冊の本を書きましたが、『デスマーチ』を除くと、すべてテクニカル系の本でした。技術的な問題があれば技術的な解決策で対応すればいい、対応策は誰にも合理的に受け入れられる、と思っていましたが現実は違う。そこで政治やマネジメントの話に踏み込まざるを得なくなったのです。
ソフト開発に失敗する原因として、無理なスケジュールもありますが、要件定義があいまいなまま開発が始まるという点もあります。要求工学や要求管理ツールの動向をどう見ておられますか。
要求工学のツールや手法を使うという試みはありますし、一部は役に立っていると思いますが、最終的には、人間同士のコミュニケーションが鍵となります。ソフトを使う利用者たちは、自分たちの要求事項を頭の中には持っているのですが、それをきちっと言葉にして、頭の外に出すことがなかなかできない。できたとしても世の中の変化が早く、要求事項それ自体が変わっていってしまう。
要求事項をきちんと文書化して管理していく点にも改善の余地がありますが、開発過程において要求事項が変化していくことを許容する、フレキシブルな開発プロセスが必要だという意識が高まっています。
