最後に，設計/アーキテクチャの不具合で火を噴いたプロジェクトの火消し術を取り上げよう。この場合の主な対処法は，（1）原因を特定して技術的な対策を打つ，（2）設計書をレビューする，（3）運用でカバーする，の三つである。
システム開発プロジェクトのコンサルティングを手がけるフィッシュボーン研究所の大坪保行氏（代表取締役社長）は，テスト・フェーズで当初見込んでいた処理性能が出ないことが露見したEDIシステムの開発プロジェクトを支援したことがある。
そのシステムは，あるWebアプリケーション・サーバーを使って開発していたが，システムの総合テスト・フェーズで，トランザクション処理性能が全く出なかった。詳しく調べてみると，システムが受け付けたすべての処理を，Webアプリケーション・サーバーが待ち行列（キュー）で管理していることが分かった。
本来ならWebアプリケーション・サーバーの特性をつかんで，キューで管理する必要がある処理と，必要がない処理に分けてアプリケーションを設計すべきだった。ところがそのプロジェクトでは「利用実績があるのでこのWebアプリケーション・サーバーを利用したい」というユーザー企業側の申し出を受け入れ，開発を請け負ったベンダーのメンバーがWebアプリケーション・サーバーを全く検証していなかった。
原因究明のために大坪氏は，改めて処理フロー図と業務ルールをまとめた表を作成した（図4）。これらを使って「この画面に入力したデータの一部は，キューにためなくてもよいので，直接データベースに記録できるようにする」などの対策を施し，設計/アーキテクチャおよびプログラムを改良していった。このように，設計/アーキテクチャに原因がある場合は，原因を特定したうえで技術的な対策を施すのが基本的な火消し術となる。
三つの視点で設計書をレビュー
20年以上金融機関のシステム開発プロジェクトの現場でシステム設計/開発作業に携わり，危機プロジェクトの火消しの経験もあるエーチームの羽鳥宏信氏（代表取締役）は，「設計書をまとめて表紙を付けてしまえば，内容が厳密でなくてもそこで設計作業は終わる。もし設計書の内容に問題があれば，次の工程である開発作業で手戻りが発生するのは当たり前」と語る。
設計書の内容が厳密でない場合は，設計書のレビュー/修正が必要になる。
羽鳥氏は，開発作業がなかなか進まない問題を抱えていた金融機関のプロジェクトを立て直したとき，次の三つの視点で設計書の内容の厳密さをチェックした。（1）設計者の説明なしにプログラマがプログラミングできるか，（2）その設計書を基に利用部門のユーザーや運用担当者向けのマニュアルが作成できるか，（3）ユーザーへの確認作業は必要ないか，だ（図5）。「基本設計書でも詳細設計書でも，手戻りが発生するのはこの三つの視点が抜けているとき。この三つの視点でレビューすれば，設計書の内容を厳密にできる」と羽鳥氏は太鼓判を押す。
例えば，図5の「元の設計書」ではエラー条件が示されていないのでプログラマが設計者に確認する手間がかかり，作業が遅れる。羽鳥氏は，これを図5右のように変更。設計書の内容を厳密にすることで，開発作業は円滑に進むようになった。
最近はオブジェクト指向設計・開発が増えているが，オブジェクト指向設計・開発でも設計図の不備のためにプロジェクトが危機に陥ることは少なくない。実際，オブジェクト指向開発プロジェクトのコンサルティングなどを手がけるフルネスの古川正寿氏（代表取締役）は「『UML（Unified Modeling Language）図』として，クラスの構造とクラス同士の関係を表す『クラス図』しか作成しないことが多いのは問題」と指摘する。
「『UMLイコールクラス図』とSEが思い込んでいるのが原因のようだが，クラス図だけで開発してもまずまともに動くシステムはできない」と古川氏は言う。「どのクラスをいつ使うのか」はクラス図だけでは表現できないため，プログラマが自分の解釈でプログラミングしてしまう可能性が高いからだ。
その結果，構造が複雑な実装になってしまい，「開発途中で機能追加が発生したときにスケジュールが大きく遅延してしまう」（古川氏）。このような状況では，概要レベルでもかまわないので，時間の流れを表す「シーケンス図」やユースケースを検証するための「ロバストネス図」などを使って設計内容を見直すしかない。
まずは運用によるカバーを検討する
設計やアーキテクチャが原因でプロジェクトが火を噴いても，場合によっては運用で解決できるケースもある。
危機プロジェクトの支援を数多く手がけているシステム・コンサルティング会社，メタジトリーの丸山則夫氏（代表取締役）が，ある小売業のコールセンター用システム開発プロジェクトを支援したときのことだ。システムを稼働させる直前に，性能に大きな問題があることが判明した。新製品の発売/バーゲン時期に，当初想定していた最大同時利用者数の300人を上回ることが分かったのである。
そこで丸山氏は，まず運用で同時利用者数が300人を超えないようにできないかを検討（図6）。その結果，利用者をいくつかのグループに分けて，グループごとにシステムの利用時間をずらし，同時利用者が300人を超えないようにすることにした。
丸山氏は，稼働直前で性能問題などの問題が判明したプロジェクトを支援する場合，まずは運用で回避できないか検討する。運用でカバーできないことが分かった時点で，初めて技術者を投入して改善する。「コストを抑えるうえでもまずはシステムの運用面での対策を検討すべきだ。技術的な対策はその次の策」と丸山氏は指摘する。
