受託開発後の保守先を失わない確認項目

受託開発した業務システムが動いているうちは、引き継ぎの話は後回しになりがちです。ところが担当者の退職や開発会社の廃業、契約終了が重なると、『誰に直してもらえばいいのか分からない』状態が急に表へ出ます。

静岡で中小企業や店舗の相談を受ける私たちも、ソースコードはあるのに環境へ入れない、仕様書が古くて現状と合わない、という場面を見てきました。納品物の量ではなく、別の技術者が保守を再開できるか。そこを基準に確認します。

『開発会社しか分からない』は納品時から始まる

保守先が見つからない原因は、難しい技術だけではありません。たとえば焼津の食品会社で受注管理が止まれば出荷確認に響き、静岡市内の店舗で予約台帳が開かなければ、その日の接客に影響します。業務の止まり方を知っている人が、社内に一人もいないことが大きな弱点です。

契約前には、納品される物と、契約終了後に返してもらう物を分けて書面にします。『システム一式』では曖昧です。仕様書、プログラム、データ、アカウント、操作記録まで名前を挙げ、受け渡し方法と期限も決めておくと話が早くなります。

画面の画像を並べただけの資料では、改修する人が判断できません。注文を登録した後に誰が承認し、どの帳票へ反映され、間違えた時にどこまで戻せるのか。実際の流れが読める資料が必要です。

特に注意したいのが、契約時の要件定義書をそのまま最終仕様書と呼ぶケース。開発中の変更が反映されていなければ、保守担当は古い地図で作業することになります。納品時点の実物に合わせた『完成後の仕様』かを確かめます。

圧縮ファイルを一つ受け取って終わりでは足りません。普段開発に使っていた履歴付きの保管場所へ、自社のアカウントで入れるかを確認します。どの版が本番で動いているか分かる印も必要です。

著作権の譲渡、利用許諾、第三者による改修が可能かどうかも契約書で見ます。ソースコードを持っていることと、自由に改修できることは同じではありません。秘密の文字列はプログラムへ埋め込まず、別の安全な保管先から引き継ぐ形が現実的です。

サーバーやドメイン、データ保管先の契約が、退職した担当者や制作会社の個人アドレスだけに結び付いていると、更新も復旧も止まります。主となる管理者は自社が持ち、開発会社には作業に必要な範囲だけ渡す形が基本です。

パスワードそのものを表計算へ並べるのは避けます。社内の保管庫で管理し、台帳には保管場所と責任者だけを書く運用が安全です。目安として半年に一度ほど登録先が現役かを見直すと、いざという時の連絡迷子を減らせます。

納品会では資料の説明だけで終えず、自社側の担当者が操作します。一般的には、次の順でひと通り試すと抜けが見えやすくなります。

全部を当日に終えにくい場合は、未確認の項目を残したまま検収済みにしないこと。誰が、いつまでに、何を見れば完了かを書きます。清水区の事務所でも藤枝の店舗でも、担当者が替わって同じ手順を再現できれば、引き継ぎ資料は役に立っています。

手元に何があるか分からない段階でも、現行の契約書、請求書、管理画面、社内の操作手順を並べれば、確認先は見えてきます。NIR株式会社では、開発ありきではなく、止まる業務と不足資料を先に洗い出し、保守の引き継ぎ表へ落とし込みます。

仕様書の読み合わせや権限棚卸しだけでも構いません。静岡の現場へ合う進め方を一緒に整理したいときは、システム導入・開発を無料で相談するから状況をお聞かせください。今ある資産を無駄にしないところから始めます。