要求仕様書が書けた（出来れば８０％の出来を期待する）ことによって、「見積もる」ことが可能となります。もちろん、一足飛びに工数の見積もりやコストの見積もりに入ることは、まだまだ難しいでしょう。そのまえに、作業で生み出される成果物の「サイズ」を見積もることです。
「設計書の作成」作業に入れるかどうか判断して下さい。要求仕様書で求められている項目に対して、それを実現するための知識が不足していたり、確認のための予備調査などが必要な場合があります。要求仕様書を読み直して、「新規性チェックリスト」を作成してみて下さい。（「ＣＭＭとリスク管理」参照）
担当者によっては、要求仕様書の中に新規性の高い項目があるということは、そのままでは取り組めないということです。場合によっては、予備的調査などの事前の取り組みが必要なことを意味します。もちろん、そのような箇所があるからと言って、そのほかの項目（機能）についての作業まで、全部止まってしまうことはありません。少なくとも、ある程度の達成レベルで「要求仕様」がまとめられている状況では、作業を進めていくことが出来ます。
本来は、要求仕様書を受けて、設計書の作成に入るのですが、このように新規性の高い項目があるということは、それぞれのテーマに対して調査の作業に入ったり、仕様をまとめたりする必要があるということで、このような状況を元にして、このプロジェクト用の「作業フロー」が確定します。
デスマーチに陥るプロジェクトでは、殆ど例外なく、このようにプロジェクトに応じた作業フローが考慮されていません。教科書通りの作業フローがあって、“強引に”進めようとします。でも、現実問題として、項目によっては準備不足や、知識の不足などで「設計」作業に入れないわけです。
ここでいうサイズには２種類在ります。最終成果物（一般にはソース）のサイズと、中間成果物のサイズです。確実に最終成果物を手に入れるためには、適切な中間成果物が幾つか必要になります。これがあることで、問題が生じた場合でも、少ないコストで適当に戻ることが出来るのです。
１冊の「設計書」のサイズを見積もることは難しくても、その中に含まれる記述内容にそって章建てした状態でサイズを見積もることは、それほど難しいものではありません。また、見積もりが外れても、全体の中では、影響が小さいものなります。
兎に角、サイズを見積もることです。見積もるためにどうすればいいかを考えることです。サイズを見積もらないかぎり工数が出てこないのですから、見積もれない理由を並べることに何の意味もありません。
サイズは途中で見積もり直します。作業を進めていく中で、よりはっきりしてくることが在ります。そのときは、サイズを見積もり直すことです。その際の「差」によって、スケジュールにどのように影響するかを予測することが出来ます。
また、サイズから工数を算出したときの「仮説（式）」も記録しておくことです。これによって、はじめてサイズ見積書が、追跡可能なドキュメントに変身します。これによって、実際の作業に入った時点で、見積もったサイズや工数とどれほどの「差」があるかが明らかになり、それによってこの先のスケジュールの影響を予測できるのです。
見積もりの対象となる成果物と、その成果物を生み出す作業（行為）とは一体ですから、（中間）成果物をイメージするときには、同時にそれを生み出す作業もイメージしていなければなりません。このとき、最終成果物を生み出す作業から、逆にさかのぼる形で、成果物とそれを適切に生み出す作業を想定していくことがポイントです。
また、成果物の名称だけでなく、その構成や内容までも出来るだけ正確に想定することです。そうでなければ、その成果物を生み出す作業を、正しく設定することが出来なくなります。何となく、あるいは一般的な工程名を並べるだけでは役に立ちません。その場になって、事前の準備が足りなかったり、設計の着手の順序が適切でなかったり、他の人に提供するＩ／Ｆの決定が遅れたりします。それこそ、これまで何度も経験している「うまく行かない」作業のやり方ではないですか。
その成果物を生み出す作業を具体的にイメージ出来ない状況に陥ったときは、その生み出すべく成果物の内容が曖昧なままで進めていることが多く、その時点で、もう一度、成果物の内容を具体的にイメージすることが必要です。
多くの開発組織では、作業の流れを順方向に考えてしまうため、最終納期に間に合わないものになるのです。つまり、約束できない作業の流れを創り出してしまうのです。このとき皮肉にも、そこで考えられた連続した（不適切な）作業のどれ一つとして明らかに無駄と言える作業はないかも知れません。つまり「この作業は要らないや」と言って取り去ることのできる作業は含まれていないということです。すべてが、その前後の中で「有効な作業」であるため、対応に行き詰まります。
その行き詰まりは「発想パターン」の問題と言うことも出来ます。この「前方思考」の姿勢からは、問題に対する対応策は殆ど出てきません。ちょうど、『原価＋利益＝出荷価格』というこれまでの計算方式と似ており、この発想からは、出荷価格を半分にするアイデアはなかなか出てこないのと同じです。『出荷価格ー適正利益＝投入原価』と言う発想が求められているように、作業も、後ろの工程から考えることです。
この行為は、たとえデスマーチに遭遇している組織であっても、それなりに取り組むしかありません。ただ、作業の流れを想定するための前提となる「要求仕様」または「それらしきも」は作られており、「何を実現すればいいのか」が分かっている分だけ、作業の流れは考えやすくなっているはずです。
新規開発が中心の組織では、一度デスマーチに陥った状態から抜け出すことは容易ではないかもしれません。たとえば、顧客の求めるシステムを新たに開発することを生業とするようなソフト会社の場合、次に控えている顧客が別の顧客であることが多く、そこでは一度デスマーチに陥ることで、次の顧客の初期の工程にまともに被さってしまいます。事前の調査や要求の聴き取り作業などが手抜きになり、次のプロジェクトもデスマーチになる可能性が高いのです。
それに対して、組み込みシステムのメーカーなど、継続的に派生モデルの開発を行う組織の場合、デスマーチから脱出する方法はあるものです。もちろん、現状はそれでもデスマーチの機器に直面している可能性がありますが、それは、要求されている「こと」と、実際の開発行動とが一致していないことから起きている問題です。
したがって、実際に、そこで要求されている「こと」に徹し、それを実現するための合理的な作業と成果物を想定し、スケジュールも、その「要求仕様」の実現に集中します。ＣＭＭのレベル２へのステップは、まさにこのような「派生モデル」の開発の場面にぴったりな取り組みを提案しているのです。もちろん、そのことが明言されているわけではありません。解釈の仕方によるものですが、レベル２が「Repeatable」と定義されていることがヒントです。
要するに、多くの組織では、実際に求められている作業（行為）と、そこで計画されているスケジュールや段取りが一致していないものです。そてそのことが、デスマーチを部屋に招き入れることになるのです。
今回のプロジェクトの要求を実現するために必要不可欠な成果物と、それを生み出す作業が一体として想定されていることで、初めて現実的なスケジュールが書けることになります。頭で、わかったつもりでも、実際にその場において どのような行為をするかです。ディレクトリを作ったり、ドキュメントの構成や、そこで使われる「原紙」を作る行為なども、その作業と成果物を一致させることで、無駄な動き（作業）を無くすことができます。
そのためにも、求められる成果物の内容を定義することから始めることです。つまり、そのような成果物を“ある時点までに”作るには、どのような入力（成果物）があればいいのか、を考えるのです。
もう一つは、求められている作業は、全部を作り直すことなのか、部分を手直しする事なのかをしっかり捉えることです。つまりおおもとの「要求」はどっちなのかということです。一般に、後者の場合は、与えられる開発期間は変更量に応じたものとなります。したがって、よほど効率的な方法を考えないと、硬直的な作業工程を持ち込んでは失敗します。
多くの組み込みシステムの開発組織では、殆どの案件は「派生モデル」の開発です。したがって、そこに与えられる開発期間は新規案件とちがって、非常に短いことが想定されます。にもかかわらず、開発工程は、新規開発の工程を持ち込んでは、最初からデスマーチになることは避けられないでしょう。その要求のタイプに合わせた作業工程を手に入れることです。
兎に角、時間が少ないのですから、無駄な作業をしないことです。
無駄な作業を排除するためのもう一つの視点は、中間成果物の目的を明らかにすることです。最終成果物は、要求を実現する仕組みを、間違いなく組み入れることですが、要求仕様書や設計書はもちろんのこと、特定のテーマでの事前の調査資料や、ドキュメント体系や管理用のマトリクスなどの補助的成果物も、生み出された以上は「目的」があるはずですが、現実には、「目的」が曖昧になっているケースをしばしば見かけます。
目的が曖昧な状況で生み出される中間成果物は、必然的に、それが後の工程の何処に使われるのか明確にならないのです。その成果物を作ることが主たる目的になっていて、成果物が生み出されることで、目的を達成したかのような気持ちになっている光景を多く目にします。
その成果物を“どこで”“どのように”活用するかという視点が欠けているため、内容や構成に工夫が為されないのです。つまり「ユーザー」不在の成果物を生み出したのです。中間成果物に含まれる内容や構成は、その成果物を利用する「ユーザー（＝作業）」の要求を考慮したものでなければなりません。
先にも述べたように、工程を後ろから逆方向に考えると、入力となる成果物にどのような事が、どのような構成でまとめられていれば都合が良いか考えやすいのですが、順方向に考えると、ユーザー不在の成果物が出来てしまうのです。まるで、「ここまでまとめたから、あとはそっちで何とかしろ」と言わんばかりの作業になってしまいます。
そのため、後の工程で、もう一度、成果物の内容と、実際にあって欲しい要求との「隙間」を埋める作業が行なわれることになります。もちろん、そのような作業（行為）は、それ自身の成果物を持ちませんので、どこにも残されない事になります。こうして、当人にしか分からない仕様（仕掛け）がそこに組み込まれたことになるのです。それが正しいものかどうか、誰も見てあげることは出来ません。
このような事態に陥らないように、その成果物の「目的」や「使い道」、あるいは「制限」などを明確に捉えて取り掛かることです。成果物は、「利用されて」こそ価値があるのです。決して「書くこと」に意義があるのではありません。
こうして少しでも要求が明確に詳細化され、ゴールに向かう筋道が見えることで、各自の具体的なスケジュールと言えるものが書けるようになります。
今まで、（ある程度詳しい）スケジュールが書けなかったのは、何をすればいいのか分からなかったのであり、どのような手順で進めていけばいいのか分からなかったのであり、どのような中間成果物を作りながら進めていけばいいのか分からなかったからです。
それが見えてきたのですから、今は、それなりの現実的なスケジュールが書けるはずです。ただし、いい加減な気持ちでは書けません。今まで書いたことが無いのですから、それなりの姿勢で望まなければ書けません。
デスマーチに遭遇している組織では、このスケジュールを書く時間も惜しいという気持ちになるかも知れませんが、ここで時間を惜しんでは、後になって何倍もの利息を付けて返さなければならなくなります。
もちろん、時間的に余裕のない状態ですし、まだまだうまくスケジュールが書けないのですから、そんなに先のことまで考えてもうまく書けない可能性があります。と入っても、全く先のことまで考えなければ、いつまで経ってもスケジュールは書けません。
そこに投入できる時間と、その時間を活かせるスキルとの兼ね合いで判断しなければなりません。何れにしても、何らかの時間を投入しなければ、何も変わりません。
もう一つ重要なことは、要求（あるいは仕様）は変更されるということです。したがって、そのことを前提として作業や成果物を想定する必要があります。
適当に中間成果物を生み出しながら作業を進めていくのは、このような途中での要求（や仕様）の変更に耐える仕掛けでもあるのです。もし、適切な中間成果物が作られていない状態で要求（や仕様）の変更が求められたとき、いったいどのように対応するでしょうか。もっとも、この場合は答えに窮する事ではないのかもしれませんね。それは実際にデスマーチの現場で行なわれている行為でもあるのですから。でも、今は、そのような状態から脱却したいのです。
要求が変更されるタイミングによって、作業の影響の範囲は異なります。仕様の検討段階に変更されるのと、設計作業に入っているとき、あるいはテスト作業に入っているときに変更が求められるのとでは、作業の影響範囲は大きく異なります。
もちろん、変更内容による機能面での影響範囲の問題は、これとは別に存在していますが、その影響範囲は、作業の進捗によって大きく変わるものではありません。ただし、作業の進捗状況に応じて、機能面での影響範囲を見極める方法が手に入っていなければなりません。実装に入っているときであれば、直ちにその箇所を押えなければなりません。
このように、工程の途中で要求が変更されても、影響箇所を追跡出来る仕掛けが必要なのです。後になればなるほど、その仕掛けが重要になるのです。適切な中間成果物は、その仕掛けを提供してくれるのです。いや、提供できるように内容や構成を考える必要があるのです。
しかしながら、このような仕掛けも、最初の段階で要求が整理されて仕様として表現され、それぞれ固有の番号を付けているからこそ可能なのであって、要求が整理されていない状態では、途中の変更に耐えるような仕掛けは難しくなります。
このような準備が為されないまま走りだしたプロジェクトで、途中で要求（や仕様）の変更に遭遇したことで、急遽変更に耐えられる仕掛けの必要性を感じたような場合、その時点からでは、全ての要求に対して、まとめ直すことは現実的ではありません。今後も、変更が続きそうな機能部分や、まだ着手していない新機能の部分などに限って、要求（や仕様）に固有の番号を付けながらまとめることを進めます。
つまり、途中から何かを始めるときには、今から投下する（投下可能な）作業時間と、それに見あう効果とのバランスを考える必要があります。「必要だから」「有効だから」といって、コストを無視して導入することに、合理的な根拠はありません。それは、ただでさえ苦しいスケジュール（納期）を一層苦しくするだけで、そのような取り組み方では、結局のところ、後になって「やっておれない」という理由で、中断し、元の形に戻す根拠を与えることになります。
この種の取り組みは、“途中から”でも取り組んで欲しいのですが、その場合は、最初から取り組む以上に、思慮深さが求められます。そうでなければ、いくらうまく考えられている「ＣＭＭ」も、何の効果ももたらしません。
そうは言っても、いったん躓くと、なかなか軌道修正が出来ないものです。お尻に火が付いているのに、要求の把握とか、仕様への展開だとか、成果物のサイズ見積もりだとか、詳細なスケジュールを書きましょうなんて言葉は、そのような組織の人たちには耳に入らないかも知れません。「とにかく早く取り掛からないと間に合わない」という言葉が、その場を支配するかもしれません。でも、これまでそれでうまく行きましたか？
「とりあえず思考」に慣れすぎたため、数ヶ月後の状態を考えることが出来なくなっているかもしれません。「そのときになって考える」思考パターンを骨の髄まで染み込ませた状態では、そんな先のことは想像できないかもしれません。要求を具体的にまとめるところから始まって、それに続く効果的な作業がイメージ出来なければ、分岐点にあって、右に行くのと、左に行くのと違いが判断できないかもしれません。
だから、何時も行き慣れた道を選ぶのも、無理はないのかもしれません。その選択が、何時もと同じようにバグに引っかき回され納期に追わることになろうとも、それは６ヶ月前に選択しそこねた結果であることには気付かないのかもしれません。
でも、ここは冷静な判断が必要です。今までは、力業でなんとかやってきたかも知れませんが、顧客にも選択肢があります。それがたとえ社内の企画部門であっても、その部門に課せられた責任を全うするために必要な選択肢を行使する可能性があるのです。特に、これからはその選択を行使する可能性が高くなります。競争が激しくなる以上、その選択肢を行使しなかったために、製品そのものを市場に送り出せないという事態に陥るわけには行かないのです。
「うまいやり方」は、まちがいなく「製品開発」という商品のセールス・ポイントです。『プロダクティブ・パフォーマンス』を構成する主要な要素です。それも、競争が厳しくなるに連れて、価値の高いポイントとなります。性懲りもなく「慣れた」道を選んでいるうちに、そのようなセールス．ポイントを手に入れる機会を無くすとしたら、その判断は取り返しのつかない判断となります。
今の「デスマーチ」の状態から脱却する方法はあるかもしれないのです。そして、実際にデスマーチから脱却できたとき、それを経験した人たちは、貴重な経験を手に入れたことになります。同時に、それは多くのデスマーチに苦しんでいる組織や、そこにいる人たちにとって勇気と方法を与えることになります。