多くのデスマーチ・プロジェクトでは、最初の数ヶ月（初期の予定では３０％程度の相当）は、何をすればいいのか分からず、関係者は毎日を何となく過ごしてしまっているものです。顧客から示された要求が大雑把過ぎたり、どこから取り組めばいいのか分からず、調査や検討という名前の作業を掲げて、その周囲をぐるぐる回っていたりするものです。
こうして無為に数ヶ月が経過したところで、「これではいけない」と（トップダウン式に）適当に担当者が割当てられ分担されます。まだ、要件が具体的に把握されていない段階であっても、このまま放置していては、管理者の責任になってしまうため、兎に角急いで分担を決めて割り振るのです。そのような組織では、これであとは担当者の責任になるのです。
でも、分担された担当者だって、いったい何をすればいいのか分からないのですから、作業が進むはずはありません。その結果、再び先の管理者の出番で、担当者に対してもっと具体的に作業の指示（アクション・アイテム）が出されますが、現実的なスコープに基づいて指示されたわけではないので、担当者間の連携に隙間があることは避けられませんし、具体的な作業も、作業者本人がイメージしたものではないので、その作業の成果物は、まったくちぐはぐなものとなってしまいます。
このような状況で、もっとも漏れやすい作業は、それぞれの担当者が分担しているモジュール間のインターフェースです。ここで「一物二価」すなわち、同じ構造体に別の名称が割当てられたり、データの「型」が微妙に食い違ったりします。同じような処理モジュールが複数個作られるようなことも生じます。そして何よりも問題なのは、まともな設計書が書かれることがないため、全体の流れを誰も知らないことです。これは、この後の作業において致命的となります。実際、この状態で仕様の変更が入ってくると、何が起きるか想像できるでしょう。
この後、メンバー間の調整作業が指数的に増えていき、個々の担当者の作業の能率はどんどん低下していきます。テストの段階に入ると、この問題はますます深刻になっていきます。どこで何が起きているのか分からないため、欠陥の仕掛けが掴めないのと、見つけた場所が適切な場所であるかどうかを判断する材料がないため、修正ミスをやったり、修正モレ、２次災害をもたらしたりして、どんどん遅れだします。
すでに数ヶ月遅れの状態であるため、お互いに疑心暗鬼に陥り、正しい情報が出てこないという困った状態になることもあります。こうして、あとは既に述べた「お決まりのコース」に合流することになります。
この状態に堕ちる最大の原因は、作業フローを持っていないことです。このような場合、最初に要件を整理し、顧客の求める機能や性能などを正確に把握し表現することから始めなければなりませんが、そのような作業パターンを持っていないため、どこから、どのように手を付ければよいのか分からなくなってしまうのでしょう。特に、新しい案件の場合に、「何をすればよいのか？」という状態に陥りやすいのですが、基本的な作業フローを持っていれば、ある程度防ぐことが出来ます。
もちろん、要求を正確に表現し、仕様化していく作業は退屈で、時間の掛かる作業です。でもそのような作業が１ヶ月も続いて、なおもまとまらないということは、通常ありません。逆に、この１ヶ月を省くことで、このあと数ヶ月が混乱の中で浪費されることになるのです。しかもその場合は、一人分のロスではないので、合計すれば大きな損失となります。
要求仕様書をまとめる作業は、開発期間が１年程度のものでも、１〜２ヶ月もあれば、大体まとまるものです。それでも、決まらない項目もあるでしょうかが、８０％ぐらいまとまれば、あとは「要求管理」のなかで対応することができるので、作業を進めることができます。もっとも、この場合「要求管理」について習得してもらう必要がありますが。
デスマーチの反省として、「仕様がしばしば変更されること」が、原因として挙げられることがあります。つまり、途中で仕様が変更されなければ、こんなに遅れないで済んだというのです。当然、これだけの理由になるくらいですから、数件の変更では済まなかったのでしょう。
実際に、最初に出された仕様に対して、その後１／３もの変更や追加が行なわれることもあります。ある意味ではこれが現実なのですが、もしこのことに対して何の防御体制（対応）も講じていなければ、このプロジェクトは破綻するか、大きな混乱に見舞われることは避けられないでしょう。
昔のソフトウェア開発の考え方では、要求は最初の工程で「ＦＩＸ」するものでした。でも、最近のソフトウェア・エンジニアリングの考え方では、最後の最後まで「ＦＩＸ」できないものとして、それを上手く管理する方向に進んでいます。途中で変更されても、それに伴う作業の影響を最小限に留めるように工程を工夫し、（中間）成果物を工夫します。
時代の変化も激しく、競争相手もある中で、「要求」の変更を伴わないで６ヶ月とか１年のプロジェクトを企画することは無理でしょう。その願望は、開発者の都合であって、市場の実態に合わないのです。
もっとも、現実問題として、仕様の変更原因の過半（時には７０〜８０％）は開発者自身にあります。つまり、初期の段階で具体的に要求を詰めていないため、設計段階やインプリメントの段階に入って、「if 命令」の行き先の処理を書こうとしたとき、そのときの処理を決めていなかったことに気付くのです。ひどいときには、テストに入って思いもよらないエラーが発生したことで、仕様が決まっていないことに気付くということもあります。
ここで漸く、具体的な要求の詰めが行なわれることになりますが、時既に数ヶ月、場合によっては６ヶ月も経過していることもあって、間違いなく顧客の不信を買ってしまい、以後の交渉において大きな障害となるのです。すなわち、これ以降、開発者の「お願い」は、殆どが門前払いにされ、時には、敵対関係なのかと思うほどに悪化してしまうのです。
しかも、この段階での仕様の変更は、一人の変更だけで済むことは少なく、一つの変更の決定が、他のメンバーの作業にも影響し、ますます混乱していくのです。３ヶ月前なら、一つの決定を受けて、それぞれの担当者が作業に入ることが出来たのに、今となっては、作業が広がっているため、一つの決定によって影響を受ける人が沢山出てしまうのです。
したがって、最初に「要求仕様書」を作成する工程を設けて、そこで綿密に要求を検討し、具体化し、仕様に落としていくことが必要です。そうすることによって、早い段階で要求の矛盾や、要求の隙間が埋められるのです。こうなると今度は逆に、顧客の方が恐縮することになり、望ましい信頼関係を気付くことが出来ます。それに、こちらのムリも、少しは聞いてくれるかもしれません。要するに、早く対応することが重要なのです。
そもそも「要求仕様書」が書けないことが問題かもしれません。「要求」と「要求仕様」の違いを正しく認識できるエンジニアが少ないことは確かです。多くは、要求と要求仕様が交じり合った内容になっています。彼らは、それが「要求仕様」だと信じています。いや、それしか見たことが無いと言った方が正しいかも知れません。
そしてそれがデスマーチの原因になっていることなど、思いもよらないのです。ＣＭＭなどで求められている「要求仕様書（Requirment Specifications）」というドキュメントを書いているつもりなのです。
でも、そこからは作業を見積もれないし、成果物の量も予測するのは難しいのです。一つの「要求」を実現するために、多くの詳細な仕様が実現されなければなりませんが、それが事前に把握されていないことが、作業途中での仕様の変更に繋がるのです。
また、「隠れ仕様」というのも、ここから生まれる問題です。仕様に書かれていない仕様ということですから、それは「仕様」ではないわけです。おそらく、そこにあるのは、「要求」を「少し細かくブレークダウンしたもの」と思われます。「要求」と「要求仕様」の違いを正しく認識していなければ、この種の問題はおそらく避けて通れないのではないかと思われます。
しかしながら、「要求」と「要求仕様」の区別が、必ずしも簡単なわけではありません。だから混じってしまうのです。そのため、ある機能については、相当に詳細に記述されているために、そこだけ見れば「要求（機能）仕様」として満たしている可能性があります。また、本人もそのつもりかも知れません。ただし、その他の部分を見れば、明らかに「要求」のままになっているものです。
この問題を深刻にしている一つの原因は、「要求」と「要求仕様」の違いを分かりやすく解説した文献が非常に少ないことです。私自身、翻訳本で数冊手に入っていますが、日本の文献としては手元にありません。
また「仕様」という言葉の曖昧さも、混乱に拍車をかけているかも知れません。確かに「仕様」という言葉にそれなりの意味を感じることなく、何となく使っているのではないでしょうか。でも「仕様」の意味が分からないと、「要求書」と「要求仕様書」の違いが見えてきません。
いずれにしろ、「要求」のレベルで作業に取りかかっていては、いつまでたってもデスマーチから逃れることはできません。急いで「要求」と「要求仕様」の違いを研究し体得することです。
デスマーチの原因を、「リスク管理の不在」という観点から捉えることもできます。中には、「見積もりミス」や「何をすればいいのか」という方に分類することも出来るかもしれませんが、明らかにリスク管理の問題であると認定できる場合もあることは確かです。
彼にはその機能の担当は無理なことは分かっていたのに、何とかなるだろうということで、強引に担当させ進めてしまった結果、案の定、お手上げの状態となってしまったり、ＮＴ上で動くドライバーを作ったことがないのに、特別な配慮もされないでスケジュールに組み込まれたりすると、彼は、どこから手を付ければいいのか分からないまま、時間だけがズルズルと過ぎていきます。
最初から、要員が確保できないことが分かっていながら何の対策も講じられなかったため、納期が大幅に遅れてしまう結果となったり、初めての言語に対して、事前のトレーニングが全く不十分なまま本番に突入したため、品質を著しく悪化させてしまったりします。
これらは明らかにリスク管理の問題です。
リスク管理が上手く為されない理由の一つは、リスク管理そのものが分かっていないことです。一体、何をすることがリスク管理なのかが分かっていない可能性があります（国のレベルでも怪しのですから）。リスク管理について詳しい説明は、別の機会に譲ることとしますが、少なくとも、マネージャーであれば「プロジェクト上のリスク」を意識しなければならないし、担当のエンジニアであれば、その担当に於ける「ソフトウェア・リスク」を意識しなければなりません。
「ソフトウェア・リスク」の場合は、「新規性」という角度から捉えたほうが、分かり易いかもしれません。何れにしろ、初めてのことであったり、今までと勝手が違うことである場合、その「新規性」の程度に応じて、うまく行かない可能性があるわけで、最初から、または途中で気付いたときから、その危険を意識し、それを回避する方法を考えて手を打っていくことが求められます。
ちなみに「リスク」とは、まだ「問題」になっていない事項で、放置しておけば「品質の悪化」を招いたり、「納期の遅れ」など、問題として顕在化する可能性のある事項です。したがって、事前の対応とか、予備的な処置によって問題にならずに済む可能性があるわけです。もちろん、そうして未然に防いだほうがコストも安く、影響範囲も広がらないで済みます。
新規性チェックの場合、その度合を「５段階」程度で捉えて整理しておくことで、その段階に応じた対応策を考えることが出来ます。また、リスクは時間と共に消滅したり、意味がなくなったりすると同時に、新しくリスクとして浮上してきますので、常に、上位１０項目程度をしっかりと追跡することが望まれます。
これからのマネージャーにとって、プロジェクトのリスクを想定出来ず、リスク管理も出来ないようでは、その立場を全うすることは出来なくなる可能性が高いでしょう。一人の不出来のために、大勢のメンバーを路頭に迷わせるような事態は避けなければなりません。もし、そのようなプロジェクト・マネージャーを配したまま、何の対策も講じられなかった場合、彼の上司が、その能力を疑われることになるでしょう。そして最後は、経営者自身が市場から見捨てられることになります。
ソフトウェア・エンジニアにとって「管理」と言う言葉は、忌み嫌われる言葉になっています。それは「管理」の意味を正しく認識出来ていないことからくる誤解なのですが、現実問題として正しく理解されていないことは確かです。そのため、多くのエンジニアは、設計手法や分析手法には興味を持つものの、プロジェクト管理とか、スケジュール管理、プロセス管理、要求管理など、「管理」と名の付くものには拒否反応すら示すことがあります。
しかしながら、最新の分析設計手法も、適切な「管理」の下でなければ、その持てる効力を十分に発揮できないことを認識すべきです。おそらく「一人プロジェクト」でも、適切な管理手法を使ったほうが、作業が上手く進むでしょう。ましてや、チームで作業を進める場合には、適切な管理手法なしに、まともにプロジェクトは進行しないでしょう。
オブジェクト指向で、最新のＣＡＳＥツールを駆使しても、適当に工程を区切って、確実に中間成果物を生成し、その完成度をメンバー間でチェックして進めて行くほうが、途中の勘違いも未然に防ぐことが出来るし、お互いの成果を利用する方法も考えられます。各自の詳細なスケジュールを公開しておくことで、協力体制を強化することも出来ます。
一人で出来ることは僅かです。チームで協力しあえば、その人数以上の効果が得られるのです。それには適切な「管理手法」が欠かせないのです。多くのエンジニアは、たとえば工程管理というと、それに時間が取られると勘違いしているようですが、「管理」というのは、その人の持っている能力を最大限に活かすためにあるのであって、そこに適切な「管理」がなければ、いちいち確かめたり、どこまで出来ていればいいのか気にしなければなりません。
工程管理では、それぞれの工程に於ける作業を特定し、その成果物の構成を具体的に指定しておくことで、その工程（期間）での作業に集中できるのです。この方が、エンジニアの持てる能力を発揮することに集中してもらえるのです。この考え方を正しく理解していないため、あるいは各自が勝手に「自分流」を発揮？するために、後になって、特定のインタフェースに関して誰も決めていないことが判明したり、終わったと思っていたことが、実は、「仮の仕様」のままであったりしてリワークとなるのです。
適切に管理していれば起きなかった問題も、そのような詰らない作業（管理）上のミスによって納期が遅れたり、プログラムを不用意にいじり回したことで品質を低下させているようでは、市場の要請に応えられない可能性があります。すなわち「管理」について正しい認識を持たなければ、２１世紀にわたって、この仕事を続けていくことは難しくなるでしょう。
デスマーチになってしまう原因として、確かに経営者の考え方に問題があったり、最初から無理なプロジェクトということもあるでしょうが、それでも、そこに居るソフトウェア・エンジニア自身の力量の不足ということも何割か入っているものです。
要求定義技法や、しっかりした分析・設計手法も持っていない状態では、いったいどのような方法で、顧客の要求を実現していくのでしょう。凝集度、結合度、複雑度といったモジュールの尺度（オブジェクト指向でもそのまま使用します）も知らないようでは、幾らでも欠陥が入って下さいと言っているようなものです。
このような先人の知恵を手に入れずして、いったい何の仕事をしようというのでしょうか。顧客の「要求」から「要求仕様書」の形にし、さらにそれを「要求モデル」にして行く部分がもっとも難しいということから、この部分に対して特別に「Requirement Engineering」と呼んで、世界中の研究者が取り組んでいるのです。ソフトウェア開発の中で、わざわざ「Engineering」と呼ぶのは、他に２つの領域しかありません。すなわちソフトウェア開発全般を扱う「Software Engineering」と、保守（修正保守、適応保守、完全化保守）の領域を扱う「Re-Engineering」です。
にもかかわらず、多くのエンジニアは全く無造作に取り掛かってしまう。そしてそのような組織の管理者（マネージャー）もまた、それに輪をかけるかのように、要求を詳細に取りまとめることを無視して、少しでも早くコード化に着手させようとします。その方針に、何の根拠もないにも関わらず、そして前回も失敗したにも関わらず、今回も同じように進めようとします。いや、前回の失敗の反省から、逆にもっと早くコードに着手しようとすらするものです。
個々のエンジニアも、マネージャーも、もっと深く勉強しなければ、このデスマーチの状態は何時まで経っても救えません。これからは、いろんな国の人がこの世界に参加してきます。そうなると、うまい方法で仕事を進めていく組織と、そうでない組織の差は、益々開いていくことになります。人もそれにそって移動するでしょうから、ますます差が開きます。当然、大きすぎる差は、事業として成立しないことになるでしょう。
勉強しなければならないテーマを探して、確実に勉強していかないと、完全に行き場を失うことになるでしょう。勿論、デスマーチに対抗できる技術を持っていない除隊では、この世界では転職もままならないでしょうし、そのようなエンジニア？を雇う会社があるとすれば、その内情は想像に難くありません。
西暦２０００年問題が終わったとき、日本のソフトウェア開発組織と、そこに居るソフトウェア・エンジニアやマネージャーのスキルが、改めて問われる時がくるでしょう。そして経営者自身も、その経営方針を問われることになるでしょう。そのときになって慌てないように、今からしっかりと取り組むことです。
「Software Process」のメニュー に戻る