職業柄、さまざまなデスマーチを内から外から観察してきたが、始まり方には一定のパターンがある。それまでは順調に見えていたのに、システムテスト（結合テスト）でまともに動作しないことが発覚して始まるパターン。または、ユーザ試用の段階で「これでは使えない」と拒否されて始まるパターンである。いずれのパターンでもまず指摘される問題が「実装品質の劣悪さ」で、アプリがやたらとコケたり、数値が正しく更新されなかったりする。
じつはそこには、「設計品質の劣悪さ」という根本的な原因が隠れている。本当に実装品質だけの問題であれば、開発すべきシステム仕様は明確なので、多少納期が遅れることがあってもデスマーチには至らない。つまりデスマーチは、「設計品質の問題」が「実装品質の問題」にすり替わることで始まる。なにしろ完成させようとしている仕様が的外れなので、技術者がどんなに残業しても問題は収束しない。
システムテストやユーザ試行の段階になってデスマーチが始まるのは、技術者がプログラミングに夢中になってしまうためかもしれない。じっさい我々には、ヒアリングだの要件定義だのといった「社交的」なフェーズを早々に切り上げて、プログラミングに内向したいという欲求がある。デスマーチが始まってからも、「実装品質さえ高めたらなんとかなる」と信じてプログラミングに引きこもったりする。ようするに我々は、設計の是非など意識せずにプログラミングを楽しみたい人種なのである。
そういうことであれば、発注側としての対処方針は明らかだ。技術者の設計スキルを見定めることは当然として、適切な仕様を追及せざるを得ないような態勢を工夫すればよい。具体的には、仕様策定の段階でプロトタイプを用意させ、ユーザによる試用を徹底的に繰り返す。発注側が新システムの仕様の妥当性についてじゅうぶんな納得感を得たうえで、正式な実装フェーズに入るためだ。
ただし急いで付け加えるが、DBとの連係なしで動作するようなモックアップでは意味がない。それではシステムのフィージビリティ（実現可能性）が担保されないからだ。気の利いたUI/UXにユーザが感心したとしても、データ処理結果を矛盾なく保持するためのDB構造が確立されていないとしたら、片手落ちどころか無責任である。DB上で動作するプロトタイプを使った検証、さらにDBへのデータ移行まで実施しなければ、フィージビリティが万全になったとはいえない。
じっさい多くのアジャイル開発プロジェクトが、フィージビリティの甘さゆえにむざむざとデスマーチに陥っている。彼らは「正しいものを正しく作るために、動くアプリの開発を先行させている」と言いながら、広域なデータモデルの確立を後回しにする。それでは正しいものを作っているとは言えない。データ処理の基礎となるDB構造という「エビデンス」が添えられない限り、アジャイルに生み出される「カッコよく動くアプリ」など、詐欺商売の見栄えの良い商品カタログでしかない。
この問題は、WEBサービスや単発のスマホアプリ等にも当てはまるが、規模の大きな「情報管理システム」において決定的となる。この種のソフトウエアにとって「正しい仕様」の核は「UI/UXの完成度」などではなく「管理される情報の形（データモデル）の妥当性」である。しかしこの事実は、一定以上複雑なDB（テーブル数20以上）を扱わない限り実感できないので、開発者側にじゅうぶんに理解されているとは言い難い。
業務システム（情報管理システム）の仕様の妥当性とフィージビリティを確保するために、発注者はデータモデルとこれにもとづいて動作するプロトタイプを業者に要求すべきだ。データモデリングやプロトタイピングのためのツールも今やいろいろと揃っているので、業者にとって無体な話ではない。
ただし、より効果をあげるために、発注側はデータモデルの基礎的リテラシーを身につける必要がある。要件にもとづいてデータモデルを描き出せない業者を見極めるためだ。とくに業者が有名SIerの場合にはじっくりと値踏みしたほうがいい。彼らの多くは高額なプロパーPMの提供と、格安な下請け開発要員の派遣にともなうマージンで稼いでいるので、プロパーの設計スキルが空洞化しているからだ。また、工数規模が大きいほど儲かるビジネスなので、プロトタイピングを含めた実装の合理化にも消極的だからだ。未だにコーディング主体の開発スタイルに固執するのはそのためである。
なお、データモデルとプロトタイプを用いて仕様策定を進める過程は準委任契約で進めたほうがいい。スコープと工数が予測しにくいし、スキルやセンスは要るが人数は要らないからだ（多くて3人で済む）。その後の実装フェーズで、新たに合い見積もりして委託契約すればよい。こうすることで、デスマーチのリスクや開発コストを最小限にできる。望まれている具体的な仕様が既に明らかであるし、的確なデータモデルを基礎にしているゆえにフィージビリティが高いからだ。合い見積もりでは、コーディング主体の実装方針を取っている業者は避けよう。ある程度は発注側で保守できるようでないと、稼働後の保守コストがかさむからだ。
まとめよう。業務システム開発の困難は「決められた仕様の実装」ではなく、今も昔も「仕様の妥当性とフィージビリティの確保」にある。この点に対して手薄であることこそが、デスマーチの最大の原因だ。「データモデルにもとづくプロトタイプ」での仕様評価を取り入れない限り、デスマーチは繰り返される。ただしこの方針に沿える業者は少ないので、オーディション（関連記事）を通じて業者のスキルを値踏みしよう。
