この記事でわかること

• 仕様書がないとき、最初に確認したい資料と管理権限（設定の確認や変更を行うための許可）
• 資料やソースコードの不足状況に合わせた相談の進め方
• 現状調査と保守の引継ぎを分け、業務を続けながら切り替える手順
• 技術に詳しくなくても使える、相談前の整理シート

「開発会社を変更したいけれど、仕様書が見つからない」 「担当者が退職するので、不具合が起きたときの対応が心配」

毎日使っているシステムでも、引継ぎとなるとわからないことが出てきますよね。 画面の使い方はわかっていても、どこで動いているのかまでは知らないこともあります。

仕様書は、システムの動きや条件を記録した資料です。 その資料がなくても、調査に向けて整理できることはあります。 ただし、実際に保守や改修を引き受けられるかは、手元の資産や環境によって変わります。

まずは、わかることと不明なことを分け、調査に必要な情報をそろえましょう。 この記事では、既存システムを使い続けながら、引継ぎを進める方法を紹介します。

仕様書がないときは、資料・管理権限・契約を確認する

最初に確認したいのは、プログラムを調べる手がかりと、作業できる条件です。 社内の共有フォルダや、以前の開発会社とのやり取りから探してみましょう。

ソースコード（システムの動きを記述したプログラムの元になる文章）も、その一つです。 画面を操作できることと、ソースコードを入手して修正できることは別々に確認します。 家の鍵を持っていても、配線図の保管場所までわかるとは限らないのと似ていますね。

手元にある資料を、古いものも含めて集める

仕様書が見つからなくても、操作説明や過去の改修依頼が残っているかもしれません。 次の表を使い、所在と確認相手を書き出してください。

古い資料は「いつの資料か」「現在と違う部分はどこか」を添えます。 画面の説明書だけでも、実際の操作と照合する手がかりになりますよ。 見つからない項目は「不明」のままで構いません。

誰が管理し、誰が変更できるのかを確かめる

サーバー（システムの処理やデータの保管を担うコンピューター）の管理者も確認します。 クラウド（インターネット経由でサーバーなどを利用する仕組み）の契約者も調べましょう。

たとえば、利用料は自社が払い、設定の変更は開発会社だけが行う場合があります。 管理画面の利用者、契約名義、障害時の連絡先を、それぞれ記録しておくと安心です。 担当者が退職するなら、その人しか受け取れない通知や承認依頼も確認してください。

契約では、ソースコードの提供や、第三者による調査・改修に関する条件を確認します。 判断がつかない部分は、契約担当者や必要に応じた専門家に相談しましょう。 引継ぎの相談時には、資料を共有できる範囲も開発会社とすり合わせます。

資料とソースコードの不足状況で、相談の進め方が変わる

資料が足りない場合は、何を入手する必要があるかも含めて相談できます。 手元の状態を伝え、調査できる範囲と、先に確認することを決めていきましょう。

ソースコードがあっても、改修できるとは限らない

受け取ったコードが、今動いているシステムと同じかを確かめる必要があります。 必要なソフトや設定が欠けていると、調査用の環境で動かせない場合もあるためです。 変更を反映する手順や、連携先への接続条件も調査対象になります。

コードを読む作業に加え、現場の使い方を聞く時間も確保しましょう。 たとえば「月末だけ手作業で修正する」という運用は、コードだけでは把握しにくいものです。 入力、確認、出力の一連の操作を、業務担当者と一緒に確かめます。

ソースコードがない場合は、入手と調査を分けて考える

まずは現開発会社に、提供できるものと、その条件を確認しましょう。 自社向けに開発を依頼したシステムでも、市販製品を組み合わせている場合があります。 製品部分の変更は、提供元への依頼が必要になることもあります。

画面や出力データから調べられる範囲もありますが、内部の処理をすべて確認できるとは限りません。 資産を入手できない場合は、既存のまま使う範囲や、別の仕組みに置き換える範囲を相談します。 引継ぎ期限があるなら、入手を待てる期間もあわせて伝えてください。

現状調査と保守移管を分けて進める

現状調査で確認する内容と、保守開始後に担当する内容を分けて相談しましょう。 保守移管は、不具合への対応や日々の管理を、新しい担当先へ引き継ぐことです。

調査前は、改修の影響範囲や、障害時に復旧できる条件がわからない場合があります。 そこで、最初の調査で何を確認し、その結果をどう受け取るかを決めておきましょう。

調査の結果は、構成の図や管理情報の一覧など、後から参照できる形で受け取ります。 すべての機能を一度に文書化するかどうかは、利用頻度や影響に合わせて相談してください。 重要な業務から範囲を決めると、調査の目的がはっきりします。

「調査済み」と「対応できる」を区別する

構成がわかっても、すぐに障害を直せるとは限りません。 たとえば、外部サービスへの接続変更に、別の会社の協力が必要な場合があります。 調査結果には、未確認の箇所と、追加の協力が必要な箇所も残しましょう。

保守の範囲も、「問い合わせを受ける」「原因を調べる」「修正する」で作業が変わります。 受付後にいつ初動の連絡をするかと、復旧までの見込みは分けて確認してください。 機能追加や大きな改修については、別途の見積もりになる条件を聞いておくと安心です。

業務を続けながら、切替え条件と障害対応を決める

保守担当を切り替える前に、新しい担当先が必要な作業を行えるか確認します。 可能なら、現開発会社と新しい担当先が情報を確認できる並行期間を設けましょう。 保守担当の変更だけで、システム自体の移行が必要かどうかも個別に判断します。

引継ぎ完了の条件を、作業で確かめる

完了の条件は「資料を渡した」だけで終わらせず、次のように具体化してください。

• 新しい担当先が、許可された範囲の管理画面や資料を確認できる
• 調査用の環境でシステムを動かし、主要な業務を確認できる
• 変更を反映する手順と、問題が出た場合に元へ戻す手順を確認できる
• バックアップ（障害に備えたデータなどの控え）から復元できるか検証している
• 障害の連絡先と、業務を続けるための代替手順が決まっている

本番環境（実際の業務で使う環境）への変更は、事前に合意した手順で行います。 データやシステムを移す場合は、切替え中の入力をどう扱うかも決めてください。 切戻し（切替え前の状態へ戻すこと）の条件と、判断する担当者も必要です。 戻すまでに更新されたデータをどう扱うかまで、計画に含めましょう。

障害が起きたときの窓口を一本化する

並行期間中に不具合が起きると、旧担当と新担当のどちらへ連絡するか迷いがちです。 社内の受付窓口と、その窓口から各社へ連絡する手順を決めておきます。 原因によって依頼先が変わる場合も、利用者が最初に連絡する相手は明確にしましょう。

たとえば受注登録が止まったら、発生時刻、操作内容、表示されたメッセージを記録します。 再操作で二重登録が起きる可能性もあるため、担当者の確認を待つ手順を用意します。 復旧まで手作業で記録するなら、復旧後に誰が入力し、照合するかも決めてください。

現開発会社の協力を得られない場合は、確認できない項目が残ることがあります。 その場合は、暫定的に対応できる範囲と、手作業で補う範囲を相談しましょう。 旧担当の権限を終了する時期は、新しい担当先の作業確認とあわせて計画します。

相談前に、わかることと不明なことを一枚にまとめる

技術用語を埋めるより、現在の業務と困っていることを具体的に伝えるのが出発点です。 以下は、架空の受注管理システムの記入例です。 「自社の状況」と「確認する相手」の欄を埋めてみてください。 わからないことは「不明」と書いておけば大丈夫です。

聞き取りでは、「この画面が使えないと、どの仕事が止まりますか」と尋ねてみてください。 「月末だけの操作はありますか」「不具合のときは誰に連絡していますか」も役立ちます。 普段の作業をたどると、資料に残っていない運用が見えてきますよ。

相談フォームには、課題の概要と利用環境を、わかる範囲で記載します。 パスワードや実顧客データ、機密資料は入力せず、受渡し方法を相談後に確認しましょう。

おわりに

仕様書が見つからないときは、まず業務担当者と管理担当者に話を聞いてみてください。 上の整理シートに「不明」と「確認する相手」を書くだけでも、次に調べることが決まります。 調査の結果をもとに、保守を任せる範囲と、先に整える環境を相談していきましょう。