システム再構築案件にて、再構築方式について調べたので、
各方式におけるポイントを書きます。
私は、実際にリライト案件を担当したことがあり、
その際に現行踏襲と安易な作業見積をされており非常に苦しみました。
そこでの経験も踏まえて、システム再構築の際の役に立てばと思います。
システム再構築パターン
ハードウェア更新
ハードウェアやミドルウェアのバージョンアップのみで、アプリケーションの変更は無し。
※バージョンアップに伴いブログラムが必要な場合もあり
リホスト
ハードウェアやミドルウェアの移行のみで、アプリケーションの変更は無し。
※ハードウェアの移行に伴いブログラムが必要な場合もあり
リライト
現行システムの言語を新しい言語に書き直すこと。
リビルド
現行の要件定義から作り直しをする。
もしくは、現行業務の最適化を図り、再度要件定義を図る。
システム再構築コスト
ハードウェア更新が最も低コストで、リビルドが最も高コストです。
ハードウェア更新 ＜ リホスト ＜ リライト ＜ リビルド
パターン別ポイント
ハードウェア更新
更新に伴う影響箇所が問題なく機能するか確認する。
リホスト
設計
アーキテクチャの変更を互換するような設計をすること。
例えば、ミドルウェアの変更に伴う、インターフェースの変更など。
テスト手法
- 非互換テスト
アーキテクチャの変更に伴う、非互換部分が期待通りの結果になるか確認する。 - 現新比較テスト
スポット的に現行システムと新システムに同じインプットデータを与えて、アウトプットデータを比較する。 - 業務運用フローテスト
業務運用に沿ったフローが問題なく動作することを確認する。
※私の経験では、全体を細かくというよりも浅く広く確認するようなイメージでした。
リライト
設計
アーキテクチャの変更や言語変更など互換するような設計をすること。
例えば、言語、FW特有の処理を新言語、新FWではどのような考え方で置き換えるか。
テスト手法
- 非互換テスト
アーキテクチャの変更や言語変更など非互換部分が期待通りの結果になるか確認する。
例えば、言語特有の処理のマイグレーションなど。 - 現新比較テスト
現行システムと新システムに同じインプットデータを与えて、アウトプットデータを比較する。
リライトにおいては、設計書ベースにマイグレーションしていきますが、
ドキュメントが最新化されていないことがよくあるため、品質確認としては本テストが最も重要だと思います。
また、費用対効果としても非常に高いと思います。 - 業務運用フローテスト
業務運用に沿ったフローが問題なく動作することを確認する。
リビルド
通常の新規開発同様の考え方で進めていく。
リリースにおけるリスク対策
- 並行稼働
一定期間の間、現行システムと新システムの両方で同一オペレーションで業務を行い、問題なく運用可能か確認する。
※利用者側の負担増になるため、並行稼働するケースは少ないと思います。 - 段階リリース
複数拠点で稼働する場合は、ある拠点のみで稼働させて問題ないことが確認する。
※連携システムの兼ね合いなどから、段階リリースができない場合もあると思います
最後に
システム再構築において、現行踏襲と簡単言葉で表現せずに、アーキテクチャや言語の変更に伴う影響などがないか考えた見積をしていただけると良いと思います。
安易な見積で、作業を初めて想定外のコストがかかることは一番避けたい部分です。
特にリライトは、上層部から同じ仕様で作ればいいだけでしょと、簡単に思われがちですので、
そこを説得するための少しでも参考になればと思います。
参考
https://www.ipa.go.jp/sec/reports/20180226.html
https://www.ipa.go.jp/files/000057294.pdf