これを書くに至ったきっかけ
私が関わっているパッケージ製品のリプレースで少し思うところがあり、そのポイントを共有したいと思いました。
情シス・エンドユーザ・ベンダーの3者打合せに入るにあたりパッケージ製品の単純リプレースの場合、エンドユーザを入れたミーティングは最後のセレモニー的に考え、情シスとは進め方について、ある程度コミットしていないと、時間だけが浪費する。
並行稼働機関で、高価なRDBのDBサーバを効率よく回すためには、一時的なDBを持つ際の方法論は確立されておかないといけない。例えば、一時的に評価期間として使えるかどうかや、そもそも移行先のDBに2つのDBを持っても行けない訳ではない。
パッケージ製品で、それこそ1日リプレースが当たり前の状況の中で、スクラッチシステムの移行のようなリカバリや検証での懸念払しょくのためには、実績が十分にあるので、スクラッチシステムのようなリスクヘッジはそもそも要らないということを、きちんと説明することも重要で、それでも納得しない場合には、2段階、3段階のフェーズをBプランとして、即答できる心構えが必要。
AWSやAzureなどへの移行の場合は、その機能を十分に利用することが重要
例えば
・リカバリテストなんて、AMIから戻すだけでIP切り替えるだけなので、その想定と問答くらいは即答できる。
・AWSの場合はオンプレからクラウドへの移行評価として、担当セールスにプレゼンして通ると、一定額のチケットを受け取れる場合があるので、そうしたものも利用する。