上に述べた原因の他に、日増しに厳しくなっていく「市場の要請」が、デスマーチを起きやすくしているということがいえます。市場の要請が変化しているのに、エンジニアの方が変わっていないことも、デスマーチに繋がっています。
それに対して、何とかデスマーチに陥らないためにも、いろいろな分析・設計手法やそれに応じたツールが開発され、年々開発のスピードが上がっていきます。一方、それを支援するかのように、ＣＭＭ、クリーンルーム、ＲＡＤなどの開発手法も活用されるようになりました。この種の手法や技法は、基本的には市場の要請の方向を察知して提案されてくるものです。したがって、これらの手法は、普及してきた時点で活用される場面が存在している可能性が高く、これらを上手く習得し、取り込んだ組織は市場に受け入れられることになります。
こうして「市場の要請」に対応できる組織が幾つか現れてくると、そのレベルが市場の要請の「水準」となるため、それらを修得していない組織にとっては競争が益々加速され、プロジェクトに与えられる時間とコストは厳しくなります。多くの場合、スケジュール、すなわち納期に気を取られがちで、つい品質の方を軽視してしまう傾向があるようです。その証拠に、「とりあえず早く書いてしまって、テストしながら何とかしよう」という考え方が、今でもまかり通っています。でも、最初から品質を確保できる方法を持たなければ、品質はもちろんのこと、時間もコストも達成できません。こうして、デスマーチが「常態化」していくのです。
どうやら、デスマーチを回避できる組織は、ごく限られているようです。そこでは、無駄な行動が無く、要求を実現するための活動（作業）が合理的に、しかも効果的に連携して作業が行なわれている筈です。多くの組織ではそれが出来ないだけです。デスマーチの本に書かれているように、政治的な対抗が起きたり、適切なマネージメントが行なわれなかったり、必要なスキルが身に付いていないために、デスマーチに陥るのを防ぐことが出来ないのです。
デスマーチを防ぐ方法としては、「何が問題か」の項で、それぞれデスマーチの典型を説明するなかでも触れてきました。実際、デスマーチの状態に陥ってからでは、そこから脱出するための有効な対応策は乏しくなります。やはり、最初からデスマーチに陥らないように取り組んで行くことが望ましいことは言うまでもありません。
中でも、
１）要求仕様書を作成すること
２）作業を見積もること
３）現実的な計画を立てること
４）要求の変更に対応すること
５）プログラムの変更制御に取り組むこと
６）自分たちにあったベストプラクティスを積み重ねること
によって、ある程度デスマーチから身を守ることが出来ます。
勿論、これだけでは足りないことは言うまでもありませんが、先ずは、大きく崩れることを防いでおかないと、勉強するための時間が確保できなくなります。いったんこれくらいの方策で時間を確保しておいて、その上で、更に適切な分析設計手法や、ＣＭＭなどのプロセス管理手法やプロジェクト管理手法などの習得に本格的に取り組むことです。
この順序を間違うと、今までのように、要求の変更の嵐に遭遇したり、次々とプログラム上の欠陥（不具合）に見舞われたりといった事態に遭遇します。その上、時間が確保されていないため何も出来ずに半年、１年という時間も、追いまくられる中で、あッという間に過ぎ去っていきます。
また、ここに挙げた取り組みの幾つかは、実際にデスマーチに陥った（と思われる）プロジェクトにおいても、それ以上の悪化を食い止めたり、上手く行けばデスマーチの状態を軽くしてくれるものです。
デスマーチに陥る原因が、その組織の性質（体質）によるものであったり、経営者や管理者の“わからずや”によるものであったりするケースもあります。そのような場合には、ここで挙げた取り組みだけでは、解決しないと思いますが、それでも、自己防衛的な立場で、これらに取り組むことは有効です。いつまでも、原因を「外」に求めているだけでは、結局、自分の手には何も残りません。その組織の消滅と一緒に、この道が閉ざされることになります。
ＣＭＭのレベル１から２への６つの取り組みは、見方によればこのデスマーチに陥ることを防ぐ取り組みでもあります。全く約束できないレベルの組織を、とにかく約束できる状態に引き上げようというのですから、デスマーチ対策そのものでもあります。
実際、要求管理の問題や、スケジュールのいい加減さ、段取りの悪さや相互の連携を無視した作業など、デスマーチに陥る組織の主な要因は、裏を返せば、レベル１から２へのＣＭＭの取り組みのテーマでもあります。
しかしながら、納期の遅れや開発着手の遅れなど、既にデスマーチの状態に陥っている組織、あるいは、その淵を覗いているような状態にあっては、一般にプロジェクト管理や、新しい技法などの取り組みの学習に十分な時間を投入することはできません。それが出来るぐらいなら、もっと早くそのような状態から抜けることができたでしょう。
現実問題として、この部分がもっとも難しい部分です。もっと、うまく出来る方法を手に入れなければならないにもかかわらず、現実には、デスマーチの状態にあって、とてもそのような方法に取り組む時間などはない状態です。ワインバーグの言う「循環論法」です。
当然のことにデスマーチに陥る組織は、品質も納期も守れないのですから、ＣＭＭの基準でいえば間違いなく「レベル１」です。この組織が、納期を満たし、顧客の要求も殆ど外さず、品質も満たしている状態であれば、デスマーチの状態を脱したといえるでしょう。それがすなわちレベル２の状態なのです。
そして、ＣＭＭ（のレベル２へ）の取り組みは、このようなデスマーチに陥っている組織にあっても、取り組むことが可能なのです。そして取り組んだ分だけ、今回のプロジェクトに効果が現れ、それが次のプロジェクトに対する負担を軽減します。特に、組み込みシステムの開発組織であれば、レベル２への取り組みを使って、比較的容易にデスマーチから脱出することができます。
そこで、ＣＭＭのレベル１から２への取り組みをヒントに、また、ＣＭＭの考えを損なわないように、そのような混乱の状態にあっても、なんとかデスマーチを回避または脱出する方法について、皆さんにとってヒントになるように、以下に簡単にまとめてみます。
もちろん、これだけで簡単にデスマーチから決別出来るわけではありません。ＣＭＭといえどもそんな特効薬ではありません。本格的に研究して頂くことになりますが、少なくとも、レベル１の組織でも取り組めるように考えられています。
デスマーチに陥る最大級の原因は、顧客の要求が正確に把握されていないことであり、開発者にとって、何をすればいいのか明確にされていないことです。当然、チームのメンバーに上手く作業を分担できないし、メンバーも自分の分担が良く分からないまま、時間だけが過ぎていきます。
この状態がデスマーチに繋がることが分かっている以上、まずは、顧客の要求を把握し、「要求仕様書」あるいは「変更要求仕様書」としてまとめることです。（要求仕様書については「要求仕様書について」あるいは「派生モデル開発」を参照してください）
まともな計画（スケジュール）が立たないもの、予定と実績の工数が大きく食い違うのも、殆どの場合、その大元である「要求」が詳細に把握されていないことが原因です。
顧客からの要求、あるいは製品仕様書からは、開発者の行うべき行為が必ずしも十分に見通せるわけではありません。特に顧客からの要求は大雑把であり、時には要求同士が相互に矛盾していたり、何らかの制約で両方を実現することは出来なかったりします。取扱いの範囲や処理上の制限事項、エラーの時の処理、操作上の細かな配慮などは、顧客から出される「要求」には殆ど考慮されていません。でも、これを具体的に決めていかなければ、現実の作業として何も進まないはずです。にもかかわらず、具体的な仕様を決める前に、適当に担当者に割り振ってしまえば、実現レベルは担当者によってバラバラになり、統一した対応は望めなくなります。もちろん、最終段階に入っての調整が避けられないことは言うまでもありません。
社内の企画物の場合、顧客の要求の代わりに、所定の部署や担当者から「製品仕様」の様なものが出てきます。この「製品仕様」を策定する工程にソフトェア・エンジニアの代表が参加していることが望ましのですが、組織のレベルから考えて、現実問題として、それはまだ実現されないものと思われます。通常は、「製品仕様書」が出てきたあとで、これを実現するために具体的かつ詳細に「何」をすればいいのか、つまり「何が実現すればいいのか」を詳細に記述していきます。
製品によって、幾つかのカテゴリを設定して、それに沿って詳細に「どう言う状況の時に、何ができればいいのか」を記述していきます。そうした中で、不明確な箇所や、何をすればいいのか分からない箇所に遭遇しますので、その段階で、顧客や、企画担当と交渉に入ります。もちろん、ある程度まとまった単位での交渉になるでしょう。
「製品仕様」が所定の時期までに、ある程度の達成レベルで出来てこないという組織もあるかと思われます。特に、内製品の場合、製品企画の制定に甘さが見られますが、多くの場合、“仕方がない”ということで放置されています。所定の期日までに何とかする、という方針のもとで、出来ない理由を明確にし、人材を投入したりしてまとめるしかありません。例えば、これを現状のままにしておいて、私に相談されても答えはありません。
もし、どうしても期日までに製品仕様がまとめられないというのであれば、しかも「派生モデル」の開発であれば、開発者自らが動くことで、「要求仕様」を先に作ることも可能かと思われます。何れにしろ、これが無ければ、開発者は動けないわけです。強引に動いても、度重なるリワークなどに見舞われ、作業の効率は低いものになるでしょう。
よく、「概要書」だとか「外部仕様書」という表現で、この種の要求をまとめることがあります。昔は確かにそのようなドキュメントを書いていました。しかしながら、今日の状況にあって、曖昧なドキュメントを作ることは避けなければなりません。ここでいう「曖昧」とは、その内容や構成の曖昧さと、利用価値の曖昧さの両方を含んでいます。そのような曖昧なドキュメントが作られるということは、作業自体も曖昧なはずです。本来、ドキュメント（中間成果物）は、以降の幾つかの作業に明確に繋がるものでなければなりません。
その点、「概要書」や「外部仕様書」というタイトルのドキュメントでは、どうしても「要求」を構成し直しただけのものになりがちで、単に「要求」の粗さに違いが認められる程度のものが多く見られます。結局、その状態で設計作業に入っていってしまうため、設計作業の中で全ての状況を考慮しなければならなくなります。でも設計方法を考えながら、いろいろと具体的に仕様のことも考えるということは、明らかに「プロセスの欠陥」であり、そのことに起因するバグがプログラム上に侵入することになります。
「要求仕様書」で求められていることは、設計者が実現すべき項目、考慮すべき項目が全てこの「１冊」にまとめられていることです。したがって、「要求仕様書」は、あとでこれらが実現されていることの確認に使用されます。
残念ながら、このような「要求仕様書」がまとめられることなく開発作業に突入してしまい、既にデスマーチの危機に遭遇している場合、重要な機能など部分的機能でもいいから「要求」をまとめることです。
多くの人は、“途中から”やり方を変えることを嫌います。でもそれは、殆どがやらないことの“言い訳”です。そのままではデスマーチに陥ることが見えている以上、その固執に何の根拠もないことは明らかです。
うまく詳細な仕様にまとめられない機能や、まだ手を付けていない機能など、たとえ限定したものであっても、まったく「要求」がまとめられていないよりは“遥かに”ましなのです。ドキュメントが途中で変わることに問題があるわけでもありません。逆に、幾つかの部分であっても、「要求仕様書」の体裁で書かれることで、あとで残された部分についても要求を整理し、「要求仕様書」の形に全体を整えようという気にさせる可能性もあるのです。少しでも混じっていれば、それがきっかけになるものです。
また、こうして途中からでも、“良い方法”を取り入れていくことによって、次回のプロジェクトでは最初からその方法で走れるのです。こうした姿勢で臨まないかぎり、いつまでたっても、新しい方法を手に入れることはできません。
多くの現場で見られる「次のプロジェクトから」という姿勢は、それ自身が「先送り」の姿勢であり、次回のプロジェクトにおいても、必ず出来ない理由を持ちだして「先送り」さてしまうはずです。そしてそのような理由は、レベル１の組織には掃いて捨てるほど転がっているのです。
これが、いつもデスマーチに陥る組織と、デスマーチとは殆ど無縁の組織との差です。「先送り」が許される組織では、おそらく永久にデスマーチから抜けることは出来ないでしょうし、そこにいるエンジニアの歩いている道は、未来に繋がることはなく、早晩、麓の村に降りていくことになるでしょう。（未来への道）
既にデスマーチに陥っているか、陥りかけているプロジェクトにあって、はたして途中からでも「要求仕様」に取り組めるかという問題があります。そこまで書かれなかったのには、書けなかった理由があるわけです。その中に、どう書けばいいのか分からなかったということも含まれます。
そのような組織にあっては、やはり「要求仕様」を書くことは難しいかもしれません。もちろん、そのままでは危険な状態に陥る可能性が高いわけです。そのような時にも、「ね〜、今皆さんが抱えていて、まだ実現していない作業をリストアップしてくれませんか」という要請には応えてくれるものです。
そこでリストアップされるのは、殆どの場合「要求」のレベルです。彼らは、それを詳細な仕様に展開できなかったから行き詰まっているのです。当然、詳細な仕様になってリストされることは無いと考えて差し支えありません。
でも、今までそのような「要求」そのものもリストアップされていない可能性があります。口頭で伝えられいたり、別に製品の仕様が「ポン」と渡されているだけであったりすると、意外と「要求」のレベルも整理がついていない可能性もあるのです。
そうして書かれた「残作業リスト」の各（要求）項目に対して、それを実現するための詳細化を始めるのです。マンツーマンでやることになるでしょうから、ちょっと時間がかかるかもしれません。でもそうやって、要求を詳細かつ具体化していくことで、彼は、自分が取り組むべき対象が見えてきます。結局、何を実現すればいいのかが分かるようになるのです。
こうして、「為すべきことの全部」を見える形にすることで、ようやく見積りが可能となり、彼自身の予定（スケジュール）らしきものが立つようになってきます。
要求を整理する段階で、このプロジェクトは全くの「新規」として着手するのか、それともベースモデルがあって、それに対する「派生」として着手するのか決まります。実際には、企画段階で、どちらになるか、またベースモデルが選ばれていることもありますが、最終的には、要求仕様をまとめた後か、ある程度まとめた時点で判断することが出来ます。
「新規」で開発するのか「派生」で進めるのかによって、要求および要求仕様の表現も違ってきます。「新規」の要求には新規の表現があり、「派生」の場合は、要求に“変更”を意識させる表現が求められます。実際問題として、このあとの設計作業が大きく異なってきますので、その作業を円滑に進めるためにも、表現は重要な要素となります。
デスマーチに直面している組織は、少しでも無駄な行動は避けなければなりません。如何にして、必要不可欠な作業を導きだすかが、もっとも重要なところです。これによって、中間成果物の見積もりも変わってきますし、生み出される成果物そのもの（あるいは構成や内容）が変わってくる可能性もあり、そのことは当然スケジュールにも反映します。
多くの派生モデルの開発組織にとって、ここが一つの分かれ道でもあります。
「Software Process」のメニュー に戻る