新しい開発会社は、未完成の業務用システムを引き継げるか？

新しい開発会社は、動いている部分を確かめ、必要なものに許可を得てアクセスし、重要な業務を最後まで進められる見通しを示せれば、開発を引き継げる可能性があります。まずは範囲を絞って調べてもらいましょう。完成して見える画面でも結果を保存できないことがあり、コードがあっても実行に必要な手順やサービスが不足していることがあります。

すでに実際の業務で使っている版があるなら、調査中に誰がその運用を支えるか決めておきます。今の業務を続けるための対応と、将来置き換えるかどうかは別々に判断できます。

新しい開発会社に何を渡せますか？

最後に使った、またはテストしたソースコードの版と、ビルドの手順や必要な依存関係を揃えます。システムの公開や他のサービスとの接続に使うアカウントは誰の管理下か、業務データとバックアップはどこにあるか、契約などで何の共有や変更が許されているかを確認します。コードの保管先にアクセスできるだけでは、これらの権限は確認できません。

これらは個別に確認します。コピーを動かせても本番を更新する権限がないことがあります。逆に、ホスティングのアカウントに入れても、受け取った資料だけではソフトウェアを再構築できないことがあります。データを移す必要があるなら、別の確認として次のシステムで使える形式でデータを試しに書き出しましょう。

引き継ぐチームに何を実演してもらいますか？

事業にとって重要な作業を一つ選びます。たとえば、サービス部門が未完成の申請ツールを使い、担当者は申請を送れるものの、管理者の承認と後日の確認まで実演できていないとします。チームには、許可を得た独立したテスト環境で特定の版をビルドし、その作業を試してもらいます。架空のデータを使い、実際の通知や決済など本番に影響する処理は無効にします。稼働中のシステムはテストに使いません。

申請を進められるところまで進め、止まった箇所を記録します。承認できても申請を開き直すと結果が消えるなら、具体的な調査対象が見つかります。必要な依存関係が不足して起動すらできないなら、何が足りないかと、業務の流れをまだ実演できていないことを記録します。承認処理での不具合を確認した場合とは、次に取るべき対応が異なります。

ビルドできたという事実が示すのは、その条件でその版を組み立てられたことです。システム全体の安全性や保守性、本番への反映権限、本番運用の準備まで確認できたわけではありません。Google による運用責任の引き継ぎの解説では、運用を引き継ぐ判断を別に扱い、依存関係や運用の準備を見直し、必要に応じて研修や改善を行う例を紹介しています。

開発を続けるか、一部を修正するか、置き換えるか？

どの案も同じ業務を基準に比べ、導入後の運用や保守に必要な作業も考えます。英国政府の調達ガイドには、必要な機能、費用、運用能力をもとに、既存システムの改修と新規開発を比べる例が載っています。

置き換えが適切だと判断したら、今の業務をどう続けるかは別に考えます。二つのシステムを一定期間並行して動かすことも移行方法の一つですが、運用費用がかかり、記録を誰が管理するかも決める必要があります。

調査結果には何を書いてもらいますか？

実際にソフトウェアを使う人と一緒に確認できる、短い記録を依頼します。何を実演できたか、何が失敗したか、何をテストできなかったか、不足するアクセスや権限は何か、今の業務を止めかねない要因は何かを残します。実行可能な案ごとに、次の段階、対応する人、追加作業を承認する前に確認する点を明示します。

申請ツールの例では、記録された承認が消える原因を調べ、管理者が後で申請を開き直しても承認結果を見られることをテスト環境で実演する、という段階を設けられます。この作業を任せるチームを比較するなら、業務用ソフトウェアの開発会社を選ぶ前に聞くべきことも参考にしてください。

未完成のソフトウェアを引き継ぐ際のよくある質問