ヨードンは、その著書の中でデスマーチ・プロジェクトの定義として４つの項目を挙げています。
１）与えられた期間が、常識的な期間の半分以下である。
２）エンジニアが通常必要な半分以下である。
３）予算やその他のリソースが必要分に対して半分である。
４）機能や性能などの要求が倍以上である。
この「２倍」とか「半分」という割合は厳密なものではないと思われますが、目安としては使えるのではないかと思います。
しかしながら、最初から顧客の要求が詳細に見えていて、それに対して開発期間が半分しか与えられていないというのではありません。顧客の要求が良く見えていない状態、あるいは、顧客の要求を詳細且つ具体的な「仕様」に展開されない状態で、開発作業に着手しているのです。また、途中での要求や要求仕様の変更を想定していないため、途中で発生した変更要求によって開発期間が倍以上に延びてしまうという形になるのです。実際、デスマーチに陥った人の話しでは、最初に示された「要求」は、「紙切れ１枚」だったと言いますが、それ自体、必ずしも悪いわけではありません。むしろ顧客から示されたそのような「要求」に対して、詳細かつ具体的な「仕様（要求仕様）」に展開する能力を持っていないことが問題なのです。（「要求」と「要求仕様」の違いについては「要求仕様書について」を参照して下さい）
結局、要求が具体化されること無く、「これくらいだから・・・６ヶ月で」ということで始まったものの、実際には作業を進めていく中で要求の変更が相次いだり、エラー処理が非常に難しかったり、顧客の要求とは別に、その種の製品に常識的に求められる機能や性能というものがあって、そのあたりの事情が分かるのに６ヶ月近く要した、という形になるものと思われます
もちろん、開発期間が２倍になる過程で、残業時間も２００ｈ／月（休出割増）にも達することになり、関係者は、身も心も疲弊してしまうことになります。当然、作業の効率も悪くなり、プログラム上に欠陥が多く入ってしまうことになります。つまり、このような進め方自体が、不用意に作業を増やしているのです。
ただ、注意しておかなくてはならないことは、「Ａ社」にとってはデスマーチの案件であっても、「Ｂ社」においては、その案件は問題なく解決される可能性があるということです。つまりデスマーチは絶対的なものではなく、プロジェクト（案件）と開発組織の相対関係でデスマーチになるということです。
デスマーチは、誰も望んでいる分けではありません。誰だって、予定通りに終わりたいし、顧客から感謝されたい。でも、いつも納期は遅れるし、管理者からは、「これじゃ赤字だ！」と嫌みを言われる。土日も会社に出て、何とか間に合わせようとするが、月曜日になれば、また仕様が変更され、作り直さなければならない。テスト中に、考えていなかった組み合わせのエラーに気付き、またまた仕様変更となる。こうしていつ終わるという見通しもないデスマーチが続くのです。実際、あるフォーラムによると、こうしたデスマーチ・プロジェクトの中で、精神的に行き詰まったり、体調を壊して、リタイヤしていく人が後を断たないようです。
あぁ、やっぱりこうなってしまった。
なぜ、いつもデスマーチになってしまうのか？
売上のノルマ達成のために、無理な案件を取ってくることがあります。最初から危険性の高い案件だけに、金額はそこそこ張っているが、その分、納期が厳しい。またその種の案件は、最初の企画時点からすでに時間が経過していることが多く、その間ソフトハウスを何社も当たったが、すべて断られてきた案件であったりする。そのため、最初の予定では１年の期間があったものも、このソフトハウスに話しが持ち込まれた時点ですでに３ヶ月が経過している。こうした案件は、最初からデスマーチに陥る可能性は非常に高いことは確かです。
また、営業部門がバラバラで動いた結果、他のプロジェクトと技術的に関連性の薄い案件であったりすると、ソフトウェアの開発部隊の作業効率の悪い状態が続くことになりますが、この場合も、最初からデスマーチに陥る可能性が高くなります。
このように、開発部隊の事情が考慮されない案件が続くようだと、有能なエンジニアは精神的にも肉体的にも疲弊し、その職場を離れていくことになって、残されたエンジニアにとっては、ますますデスマーチに陥る確立が高くなります。
やはり、ソフトウェア・エンジニアを大事にし、時代の求めるように育てるくらいの考え方がなければ、結局のところ、その組織は消滅することになるでしょうし、その前に多くの犠牲者が出る危険もあります。
では、このような状況の中で、ソフトウェア・エンジニアは如何に振る舞うべきか。案件にもよりますが、この状態でデスマーチを回避することは一般には難しいと思われます。それでも、貪欲にそこから確実に自分にとって役に立つ「何か」を手に入れることができそうなら、それを考えるべきです。
たとえば、要求の整理に思いきって時間をかけてみるとか、納期に間に合わせることが不可能なことを証明するために、反論の余地の無い詳細なスケジュールの作成に挑戦してみることも可能です。つまり、途中でプロジェクトが中断したとしても、あるいはあなた自身が、そのプロジェクトから何らかの形で離脱したとしても、「何か」次に使えるものが手に入っているようにすべきです。
そして最も大事なことは、このような状況にあっては、「拒否できる力」を身に付けることです。
ただしその場合でも、一つ注意することがあります。それは、本当に無理なプロジェクトなのかということです。本当に可能性のないプロジェクトなのかということです。その時点で成功の可能性が見えないとしても、開発期間によっては、途中で状況を変化させることができるかもしれません。というより、状況の変化を呼び込むような作業の取り組み方も考えられます。
その時点では、確かに要員が絶対的に不足しているかもしれません。「こんな人数でどうしろといいのか」と言いたくなるかもしれません。しかしながら、そのような人数しか割当てられていないのは、その時点で成功の見通しが低いからであったり、まだ序盤であったりするからです。
インクリメンタル開発などを取り入れることで、作業フェーズを定義し、そこで必要な機能や基本となる機能を確実に実現していくことで、管理者の考えを変えさせることができるかもしれません。「そこまで来ているのなら、これだけの要員を投入して一気に・・・」ということになるかもしれないのです。いや、そのような方向に持っていくことに挑戦して欲しいと思います。
そうして、たとえ今回は納期遅れとなったとしても、このチームは、今後の開発に必要なスキルの何割かは手に入れた可能性があるのです。「転んでもタダでは起きない」― 最初から転ぶ可能性が高いとわかっている以上、確実なステップを刻むことが重要です。多くの人は、転ぶと分かっているからと言って、いい加減な対応をしますが、それは全く逆の対応です。その証拠に、要求仕様もまとめないでしょうし、まともな計画も立てることはないでしょう。そうしてプロジェクトが頓挫したとき、いったい彼の手の中に何が残っているというのでしょう。ただ疲弊しただけ、ただ失敗の体験を一つ重ねただけ。でも、この世界で活躍しようと思うのなら、これだけは避けて欲しいのです。
人生において重要なことは、何時でも「選択肢」を持つことです。成功体験からも、失敗体験からも、自分の選択肢を強化するための栄養素を手に入れることはできます。というより、それを意識して行動して欲しいのです。「選択肢」のない人生・・・それこそ“デスマーチ”ではありませんか。
これも、この種のフォーラムでは原因の一つに持ちだされてくるもので、前項の「もともと無理な案件」とも関連します。特に、請負型のソフト開発会社の場合、抱えているソフトウェア・エンジニアのスキルや陣容によって、契約できる案件に制限がついてしまいます。付加価値の高いソフトウェアを開発できる組織であれば、最初から無理な案件はパスします。そこでは経営的にも安定しているでしょうし、単価を落とすような案件に手を着けなくてもいいわけです。
しかしながら、多くのソフト開発会社では、それほど高いスキルのエンジニアを揃えていることは稀で、どうしても収益性の低い案件に手を出さざるを得ない状況にあると思われます。付加価値の高い案件と比べると、時間当たりで３０〜２００％以上の差が生じてしまいます。もちろん、その分エンジニアに支払う報酬も高いのですが、それでも、組織としての収益の差は、大きく開いてしまいます。
そうなると、ツールの装備にも影響が出るし、エンジニアに対する教育・訓練にも差が出てきます。こうして「富める者はますます富み・・・」という状態になっていくわけです。その結果「富まざる組織」は、ますます無理な案件に手を出してしまうことになります。教育・訓練が不足していることもあって、問題の解決方法が決定的に不足していることも、「無理な案件」になってしまう原因です。
したがって、同じ案件でも、別の開発会社があたれば、デスマーチにならずに済む場合もあるのです。ただ、その案件の予定価格が低いため、開発能力の高いソフト会社は手を出さないのです。そうして残った案件に開発能力の不十分なソフト会社が手を出すわけです。その意味からも、いつもデスマーチになる組織と、ほとんどデスマーチに遭遇しない組織があるわけです。
あなたがこのような組織に属している場合、デスマーチを回避することは非常に難しいかもしれません。ソフト会社の場合、基本的に、そのような組織にあってはデスマーチになる危険性の高い案件しか入ってこない可能性があるからです。しかも全ての持ち時間が、そのデスマーチ・プロジェクトに投入されるため、必要な技術の習得もままなりません。「チーム」のメリットも、そこには存在しない可能性があります。
そのような組織にあってやれることは、
１）要求の定義に挑戦する・・・要求仕様書の研究と試行から要求管理へ
２）サイズを見積もることと、詳細なスケジュールの形にしてみること
３）詰らない変更ミスをなくすために変更制御に取り組むこと
ぐらいですが、それでも、組織的に行なわれることは期待できませんので、個人の取り組みとしてやっていくしかないでしょう。もちろん、要求仕様やスケジュールの取り組みは、周囲から簡単に崩されてしまいますが、それでも自分の分担だけは変更に耐えるように工夫することは可能ですし、変更制御は個人でもそれなりに効果は上がります。
これらは一種の「自己防衛」ですが、少なくとも、このような組織の「いいなり」になっていては、明日の見通しは全く立たないでしょう。
よくデスマーチの原因に挙げられるのが、この「見積もりミス」です。ヨードンの本の中でも、見積もりミスが原因として扱われていて、対応方法として適切な見積もりツールを使うことを勧めています。「CHECKPOINT」のような見積もりツールがあるのに、それを使わずに“適当に”見積もった、あるいは“楽観的に”見積もった結果、実際と大きくずれたというわけです。言い換えれば、そこではツールが使えたはずだということが前提になっています。
わが国の場合、この種の見積もりツールが殆ど使われていないのと、その前に見積もりツールすら使える状態ではありません。「CHECKPOINT」というツールは、要求仕様の中から「Function」をカウントし、荷重調整して全体のポイント数を割りだすわけですが、それは、要求仕様の内容がそれなりの内容になっていることが条件です。紙切れ１枚の要求をインプットして、まともな見積もり結果が出てくるツールはありません。
見積もりというのは、一般に「工数（人月）」の形で表現されます。金額の見積もりも、基本的にはこの「工数」の見積もりから割り出されます。そして「工数」は何から出すかというと、その大部分は成果物の「サイズ」の見積もりがベースとなります。ところがこの「成果物」には、最終成果物としてのソースプログラムのサイズしか考慮していないことが多く、設計書など、ソースに至るまでに必要な各種の中間成果物のサイズが見積もられていないのです。
どのような設計書が必要か。最後までうまく作業を進めるために、何について書かれたものが必要かが見えていないのですから、「設計書」のサイズも見積もれません。また設計に入る前に詳細に調査しなければならない機能や項目があるにも関わらず、それが見積もれないだけでなく、要求を詳細な仕様に展開できていないため、その必要性すら見えていません。
最終成果物にしろ、中間成果物にしろ、サイズを見積もるために必要なのは「要求仕様」です。一体、そこで何が（出来ることが）求められているのかが明確でない限り、まともにサイズは見積もれないし、先の「CHECKPOINT」などのツールも使えません。
顧客の「要求」はわずか一言（エラーが発生しても、他の回線に波及させないように）であっても、その要求を実現するために、“バッファを回線毎に別に管理する”など、具体的かつ詳細に仕様化して客の１つの「要求」を満たす方法を考えることになります。この具体的な行為（機能）や振舞い（実行されるべきこと）などを、主に設計者（分析者）の立場で記述したものが「要求仕様書」です。それだけに、「仕様」によっては、「設計（HOW）」に近くなる傾向がありますが、あくまでも、そこで「為すべきこと」に踏みとどまるべきです。
このような「仕様」があれば、双方の思惑の違いなどが分かるのですが、残念ながら、プロジェクトの初期の段階でこのような作業が為されないために、設計工程に入ってから要求の食い違いや、例外処理などの未決事項が吹きだしてくるわけです。当然、すでに設計に着手していますので、一つの要求の変更は、多くの設計箇所の変更を伴うことになります。丁度、一度塗った壁を剥して、その下の作業をやり直して再度壁を塗り直すようなものです。その場は対応したように見えても、後になってバグとして剥げてくるわけです。
プロジェクトの最初の段階で「見積り」に耐えられる成果物を作り出していないため、要求や仕様の変更が止まらず、スケジュールは崩壊していきます。さらに変更作業がコントロールされていないことが、変更ミスを生み、混乱に拍車をかけるのです。
これが「見積もりミス」が原因のデスマーチの代表的メカニズムです。
これに対応するには、顧客の「要求」を具体的に詳しく把握し、記述していくことです（この方法に付いては、後の方で触れます）。たとえ、営業の人から、“ざっくりでいいから今日中に見積もって欲しい”と言われても、それを拒否することが望ましいのですが、拒否できないとすれば、その見積もりに責任を持てないことを明言しておくことです。少なくとも、もっと正確な見積もりを出すための行動が認められないかぎり、責任は持てないと。
実際、顧客もこのような営業マンを信用しないでしょう。確かに、急いで見積もって欲しいと言ったものの、そんなに簡単に見積もれるとは思っていないわけで、それが“ざっくり”で見積もってきた（だけ）となると、この営業マンは信用できないわけです。少なくとも、私が顧客の担当者であれば、このような“いい加減な”営業マンのいうことは信用しません。
納期や稼働時期が最初から決まっていることが問題になることもあります。これは場合によっては「もともと無理なプロジェクト」という判断が為されるかもしれませんが、必ずしもそうとは限りません。
計画を立ててみるものの、どうしても指定の納期に間に合わないというわけですが、そこでは、要求分析に１ヶ月、概要設計に２ヶ月、詳細設計に３ヶ月、インプリメントに３ヶ月、結合テストに３ヶ月、運用テストに２ヶ月・・・、合計で１４ヶ月“どうしても”かかってしまうという結論になります。ところが顧客の要望は１２ヶ月です。そうなると何かを省かなければなりません。
ところが元々、この種の見積もりには、その裏付けが無く、「これだけ掛かる」と思われる作業をイメージして考えられたものです。したがって、そのまま放っておけば、イメージした通り（厳密には、身体に染み付いた行動パターンのまま）に行動するはずですので、概要設計に２ヶ月（以上）、詳細設計に３ヶ月（以上）掛かってしまいます。スケジュールというものは、具体的かつ詳細に見積もらない限り、予定した日程以上の工数が掛かってしまうものです。
また、顧客の要望に合わせるために、スケジュールの紙の上では２ヶ月縮めてみたものの、そのことに何の裏付けもありませんし、実際には段取りの不足から、各工程でそれ以上の時間が掛かってしまいます。また、テスト仕様書の作成といった工程が考慮されていなかったことなども重なって、２ヶ月の遅れでは済まなくなるわけです。
こうしたプロジェクトの反省会では、「最初に納期が決まっていることが問題なんだよ・・」とか、中には「最初に稼働日が決まっているのだから、計画なんて立てる意味はない」という言葉まで出てくるのです。そして、これがまた、そのような組織においては「そうだ、そうだ」と共感を呼ぶのです。彼らには、理に叶っているように見えるのでしょう。
でも良く考えてみて下さい。最初に期日の決まっていない仕事なんてありますか？ 自分たちの出来るスケジュールで通るのは役所だけであって、民間の世界では、そんなプロジェクトは存在しないでしょう。本当は、役所と言えども、こんな調子では困るのですが、この国の官僚機構や役所の機構は、完成された社会主義の制度であるために、そんな悠長なスケジュールが大手を振って通ってしまうのです。
「競争」というものが存在するかぎり、このような「積み上げ式発想」では通用しないことを知るべきです。先ず初めにゴールがあって、あとはどうやってその期日内に要求を満たしながらゴールに到達するかです。製品の価格も、最初に販売価格があって、後から、それを達成するには、どのような部品を使って、どのように設計し、どこで製造する必要があるか、というように「逆方向」に考えなければなりません。
何時までも、ＮＴＴの電話料金の算定基準のように、「利用料金＝必要コスト＋適性利潤」という発想は通用しないのです。でも、多くの人はこの発想から抜けられないのかもしれません。あまりにも長い期間、「納期＝必要工数＋適性余裕」でやって来たものですから。この発想に立つかぎり、最初に稼働日が決まっていることは「けしからん」ことになってしまうでしょう。
問題なのは、このような発想であって、稼働日が最初に決められていることではありません。納期が決まっていることで、「投入可能工数＝納期ー適性余裕」という式で、そこに投入できる工数や最適の開発方法を考えだすことが出来るのです。もちろん、いろいろな方法を持っていなければ、顧客の要望に応えることが出来ない可能性はあります。でも、それを手に入れて、顧客の要望に応えていくことが競争であり、そのような技術が競争を支えるわけです。だからこそ一所懸命に勉強（研究）して、ＣＭＭなどの新しい開発方法や設計技法を手に入れるわけです。
もちろん、「投入可能工数＝納期ー適性余裕」によって求められた工期では、どうしても実現しない可能性があります。その組織の持つ技術力とのバランスによっては、そのような事態も生じてきます。そのような場合、具体的にどのように工数を満たさないのかを明らかにすることで、客との間で交渉の余地があるものです。
納期を２段階にするとか、中間成果物の構成を一部簡略化するとか、テストの体制を顧客と分担するとか、適切な時点でインプリメント作業で増員するとか、指定の納期で実現する為にいろんな方法を考え交渉します。もちろん、省いてはならない作業もありますが、完全に省くのではなく、別の方法で代用することで、欠陥の入る余地を制限することは必要です。そして何よりも大事なことは、早い段階で顧客にそこまで話しを持っていくことで、現実問題として、殆どの顧客は交渉に応じてくれるものです。そこで行われるのは、出来ない相談をするのではなく、出来るための相談だからです。
「Software Process」のメニュー に戻る