移行設計の落とし穴 | さすらいコンサルの徒然なつぶやき

さすらいコンサルの徒然なつぶやき

まだまだ新米のコンサルですが、日々思うことなど書き綴ってます。ITだったりマネジメントだったり、たまに趣味だったり、仕事だったり。
読んでくださった方に、何かが伝わるといいなぁ

システム構築案件では、完全に新しいサービスのスタートでない限り、普通は移行というものが付いてきます。

移行はシステムが出来上がって、今あるものを新しいシステムに切り替える時データであったり、

インフラの機能であったり、業務などを古いものから新しいシステムで使えるようにしていく作業です。

 

だから新しいシステムが出来上がらないとできないのです。

 

ここが勘違いを起こします。

もし、その前提で移行を設計したならばいつ設計書ができるでしょうか?

 

詳細設計で移行先のテーブルが出来上がらないと移行の設計はできないということになります。

では、その手順で推進した場合どうでしょう?

 

詳細設計の後はエンジニアは結合テスト、総合テストとシステムテストが続きます。

それと並行して移行の設計を進めるということになります。

 

そのタイミング、テストでバグの発生しないことがあるでしょうか?

普通は何らかのバグが発生します。

逆にバグが発生しないテストは品質上問題があるということになります。

 

そしてバグが出た場合、対応を進める必要があります。

テスト対応リソースと移行検討のリソースを別リソースで賄うことできるのでしょうか?

通常困難だと思います。

 

つまり、完璧な製造を行わない限り(テストでバグを出さない限り)リソースが足りないということです。

そして、そんなことは普通はあり得ません。

 

結果、移行の設計はまともに進められないということになるわけです。

 

ならばどうすれば良いのか?

 

移行の設計は基本設計の段階から新しいシステムの設計と並行して作る必要があるということです。

移行設計と通常の機能設計は対に進める必要があるということです。

 

これと同じことは運用設計にも言えます。

ただ、こちらは現状の運用を流用できることが多いので、移行の考え方と全く同じとは言えません。

しかし、新しいシステムである以上、現状の運用と同じという訳には行きません。

やはり、設計段階から、現行の設計との違いを明確にし、現行との違いを明確にする必要があります。

 

また、その現行との違いこそが移行のベースにもなります。

 

システム開発は業務要件に目が一がちですが、それを作る上での移行、運用も同等のレベル感で

要件定義、設計、構築を進める必要があるのです。