オフショア開発の完了後、受入側にはソースコード、文書、システムの説明が提供されているかもしれません。次に確認したいのは、それらを使ってどこまで作業できるかです。TECHNESTは、受入側がテスト環境で小さな変更を実施し、つまずいた点を引継ぎ内容の改善につなげる方法を提案します。
受入側にできてほしい作業を決める
実施前に、作業と確認したい結果を合意します。例えば、該当する処理を探し、メッセージを修正し、テストを行い、変更版をテスト環境へ配置する流れです。実施者、必要な権限、支援者も明確にします。全体を追える小さな作業を選びつつ、引継ぎ後に使う開発・確認・導入の手順を含めます。
実際のバージョンに対応した文書を用意する
確認対象の版に対応するソースコード、環境構築方法、導入用の成果物を作る手順を明示します。サンプルデータ、テストシナリオ、ログの確認方法、テスト環境を元の状態に戻す手順も用意します。各文書の保管場所と更新担当者を明確にし、古い説明や不足する実施条件は、その場で改善項目として記録します。
受入側が主体となって実施する
合意した権限の範囲で、テスト環境とサンプルデータを使って進めます。引継ぎ側は観察し、必要に応じて説明し、文書以外の支援が必要だった手順を残します。操作を見るだけでは、自ら実施できるかの確認材料が十分に得られません。この結果は引継ぎの確認に使い、機能テストとリリース判断は別途検討します。
不足事項と引継ぎ後の責任を整理する
文書の不足、作業に合っていないアクセス権、特定の人に依存する知識をまとめます。各項目に対応者、期限、再確認方法を設定します。移行期間中の質問窓口と、変更時に文書を更新する責任も合意します。口頭で補った内容は文書に反映し、該当する手順を再度実施します。
仮想例：受注登録時のメッセージを修正する
ある日本のSIerが、オフショアチームの開発した受注管理システムを引き継ぐとします。テスト環境で入力エラーメッセージを修正する作業を選びます。受入側はコードを見つけましたが、設定手順の不足により導入用の成果物を作れません。文書を補った後、受入側が再実施し、表示とログを確認してテスト環境を前の版へ戻します。不明点を、確認できる作業に変える例です。
TECHNESTと、開発後の引継ぎまで計画する
TECHNESTは、日本市場での協業、業務システム開発、レガシー刷新の経験を踏まえ、ソフトウェアとともに引き継ぐ知識を重視しています。計画には、文書、受入側の実施確認、未解決事項への対応も含めましょう。DELIVERYサービスをご覧いただくか、引継ぎ先の体制とシステムに合う確認方法についてご相談ください。
