SIの更改案件でしばしば「現行踏襲」と書かれた上位設計が降りてくることがあります。その上位設計は、要件定義書のことも、基本設計書のことも、詳細設計書のこともあります。どのフェーズでもしばしば見られるということです。後工程は、その「現行踏襲」という指示と、現行機から取得したパラメータ（たとえばmsinfo32やvmsupportログバンドル）とかソースコードを渡されます。

インフラ設計についてそれらを渡された際によく相談させていただくのが、現行の「設計方針」「設計思想」を踏襲することはできるけど、現行の「設計値」を踏襲することは難しいということです。すべての設計値は、当時の環境下で、上位設計の要求（機能や性能、RASISなど）を満たすために決められています。新しい版数、新しい環境では、同じ要求を満たすのに別の設定値が必要なのです。「更改」は「環境が変わった」から行うことなので、設計値は踏襲できないのです。

プログラムについての話ですが、「消えたプログラマの残したものは」というブログエントリが、そのことを指摘していて、興味深く読めました。

■消えたプログラマの残したものは - megamouthの葬列

インフラについても同様に、消えたSEの残したもの、消えたお客様側ITご担当者の残したものを「信仰」すると、それは時々、危険なことになります。「もの」（設定値、設計成果）ではなく、思想を引き継ぐ方が、結局は安全だと思います。ものしか残っていないときは、それを「糧」として消化して、現行の思想を解釈します。

現行踏襲の更改案件でも、下位工程に「現行踏襲」で設定値を引き渡すのではなく、「現行の思想はこう」という上位設計書を新たな版として起こすのだと思います。

（ヘッダー写真：Abandoned Conveyor Belt by Darkday）