株式会社renue
renueについて
renueは、AIで業務を実装する会社です
AIコンサルティングから図面AI・広告運用エージェント・コールセンターAIまで、実際に動いているサービスをご覧いただけます。renueが何をしている会社か、まずはサービス一覧からご確認ください。
内製アプリの担当交代では、ソースコードや設計書を渡すだけでなく、後任が保守を続けられるかを確かめたいところです。「どこで動いているかは分かるが変更できない」「再実行の方法はあるが、実行してよいか判断できない」。こうした未確認事項を、前任者がいる間に見つけることが引き継ぎの目的です。
残す情報は、環境・権限・依存・運用手順・判断履歴・連絡先の6つに分けると整理できます。本稿では、稼働中の内製アプリを受け継ぐ担当者と管理者に向けて、情報の書き方、確認方法、AIに任せる範囲を提案します。
引き継ぎの完了は「後任が確かめた」で決める
まず、引き継ぐ保守作業を挙げましょう。稼働状況の確認、定期処理の結果確認、軽微な修正の反映、障害時の停止や復旧などです。すべてを一度に覚える計画にせず、業務への影響が大きい作業や、担当交代の直後に予定される作業から確認します。各作業に「必要な情報」「後任が試すこと」「合格とする結果」を付けておくと、資料の不足を具体的な質問にできます。
直近の公開資料では、IPAが2026年3月23日に公表したWebシステム開発・保守業務の入札説明書の仕様書第7章に、引き継ぎ時のトレーニング、検証環境、事前に定めた完了基準による確認が記載されています。担当交代の計画でも、読む・説明を聞く・操作を試す・結果を確認する、という活動を分けておくと、どこまで終わったかを判断しやすくなります。
ここで参照する公開調達の要件や海外の運用例は、それぞれの組織の条件に基づきます。日本の民間企業に共通の義務として当てはめず、権限や承認、保守契約は自社の規程に合わせてください。
進め方は、前任者が通常の保守を実演し、次に後任が自分のアカウントで同じ確認をする形を勧めます。前任者は後任が止まった箇所を記録し、すぐ操作を代わる前に、何が足りなかったかを言葉にします。資料が見つからないのか、権限がないのか、結果の読み方が分からないのかで、直す対象が変わるためです。
引き継ぎ完了の範囲も先に明記します。たとえば、日常の確認は後任が担当し、復旧操作は管理者の承認と立ち会いを必要とする、といった分担です。後任がすべてを単独で行えることを前提にせず、実行できる範囲と相談して進める範囲を決めます。
後任が詰まる順に6つの情報を残す
情報ごとに別の長い資料を作る必要はありません。アプリの入口となるページから、更新の正本へたどれるようにします。同じ設定値を複数の資料に転記するより、所在と確認方法を示す方針にすると、変更時に直す場所を絞れます。
1. 環境：どこで、どの版が動いているか
本番と検証のURL、ソースの保管先、稼働中の版、変更を反映する経路、設定の管理場所、ログの入口を残します。アプリが保存するデータの場所と、バックアップの所在・復元先も関連付けます。画面のURLだけで済ませず、「この画面の裏側の処理を、どこで確認するか」までつなぎましょう。
後任の確認は、稼働中の版を特定し、対応する変更履歴へたどるところから始めます。検証環境で同じ確認を行い、本番との設定差やデータ差を記録します。前任者の端末だけに残る実行方法や設定が見つかった場合は、必要なものを組織で管理できる場所へ移す担当と期限を決めます。
2. 権限：誰の承認で、何を操作できるか
ソースの閲覧、修正、変更の反映、ログの閲覧、データの復元を分け、必要な権限と申請先を並べます。後任自身のアカウントでアクセスを試し、申請済みと利用可能を別々に記録してください。前任者の画面共有で閲覧できたことだけを完了条件にしないようにします。
パスワードやAPIキーの値は引き継ぎ資料へ転記せず、保管場所と利用・更新の手続きを示します。個人名義のアカウントや連携があれば、移管・再設定の要否と確認担当を残します。後任が使えることの確認、組織管理への切り替え、前任者の不要な権限の削除までを一組の予定として扱いましょう。
3. 依存：どこが止まると、何が止まるか
ライブラリの名前と版に加え、認証、外部API、データベース、ファイル受け渡し、定期処理、契約や証明書の更新も確認対象にします。入力が来る場所から、処理されて結果が渡る場所までたどり、接続先の管理者と、停止時に影響する処理を付けます。
英国政府のレガシー技術管理ガイドも、依存するシステムや資料の不足、責任者の不明確さを移行の障害として挙げ、資産台帳の更新と全体像の把握を勧めています。引き継ぎではこの観点を使い、「アプリは動いているが、連携先が止まると結果が届かない」といった境目を確認します。連携の有無が分からない箇所は、推測の線を確定した構成図へ混ぜず、調査対象として残しましょう。
4. 運用手順：実行前と実行後に何を見るか
手順には、対象となる症状、実行できる条件、操作、期待する結果、中止条件、元へ戻す方法をそろえます。たとえば定期処理の再実行なら、前回の処理が終了しているか、重複登録の可能性はないかを実行前の確認に置き、実行後に確認する出力やログの場所を示します。
海外の公開運用例として、GitLabのrunbooksは、サービスの概要と個々の作業手順を分け、アラートから手順へ到達できる構成を示しています。手順は簡潔で、追加調査なしで実行できる内容にする考え方です。内製アプリでも、背景説明は概要へ、操作時に必要な条件は手順へ置くと、確認の途中で長い設計書を探し直す負担を減らせます。
5. 判断履歴：なぜその方法を選び、いつ見直すか
現状の構成だけでなく、選定理由、比較して採用しなかった案、当時の制約、未解決事項を残します。「この設定を変えない」だけでは判断を受け継げないので、何への影響を避けているのか、変更前に誰へ確認するのかまで書きます。
判断した日と根拠の資料を付け、制約がなくなった場合や利用条件が変わった場合など、再検討のきっかけも記載します。理由が見つからない設定は、後からもっともらしい説明を付けず、「理由未確認」と調査担当を残してください。過去の決定を守ることと、条件が変わった後も維持することを分けて考えるための情報です。
6. 連絡先：誰が対応し、誰が決めるか
技術対応の担当、業務影響を判断する担当、変更・復旧の承認者、外部サービスの問い合わせ窓口を分けて整理します。通常の連絡先に加え、不在時の代替先、対応時間、時間外の扱いも必要です。個人の連絡先だけに依存せず、役割に対応する組織の窓口を入口にしましょう。
担当が切り替わる日時、前任者へ問い合わせられる期間、外部保守の対象外となる作業も明記します。問い合わせ時に添える情報を、発生時刻、対象環境、症状、確認したログ、実施した操作などにそろえておくと、後任が何を調べてから連絡するかも分かります。
AIに任せるのは整理案、確定には確認記録を付ける
引き継ぎ資料をAIで整える前に、前任者が実際に何を見て、どの結果を受けて次の操作を決めているかを確認します。説明だけでは省かれやすい、ログを開き直す行動や担当部署へ確認する行動も対象です。観察の方法は、自動化前に確認行動と手戻りを記録する方法ともつながります。
この順番で実作業を理解したうえで、AIには資料の目次案、依存先の候補、資料間の食い違い、不足している質問の下書きを任せます。入力には利用が認められた資料だけを使い、秘密値や不要な個人情報を除きます。元ファイルと版をそろえ、どの記述に基づく整理なのかを出力に付けるよう依頼しましょう。
依頼文は、たとえば次のように具体化できます。「対象のアプリと資料の版を固定し、6つの情報に分類してください。各項目に根拠のファイルと見出しを付け、記述がない欄は未確認としてください。資料同士で異なる点は両方を残し、確認質問にしてください」。完成したマニュアルを一括で求めるより、何を確認すれば確定できるかが見える成果物を目指します。
AIが列挙した権限は申請・付与の記録と、手順は後任の操作結果と照合します。コードに接続先が書かれていても、現在使われているかは設定や実行記録の確認が必要です。矛盾があれば人が正本を決め、資料を直した後で再度整理します。更新日が新しいという理由だけで、自動的に正しい資料と決めないようにします。
権限付与、設定変更、データ復元の承認までAIの整理結果で済ませず、実行の責任者を置きます。小さな範囲から整理を試し、根拠の追跡と確認にかかる手間を見てから対象を広げる進め方です。AI導入全体での役割や停止・復旧の設計は、試作から本番運用・内製化へ進む際の確認項目も参照できます。
担当交代前に、後任の操作と未完了事項を確認する
最後は、6つの情報を使って保守の練習を行います。まず後任が資料から稼働環境と版を確認し、自分の権限でログへたどります。次に、許可された検証環境とテストデータで対象の作業を試し、期待した結果と一致するかを確認します。本番の変更や停止を伴う操作は、必要な承認と実施計画を整えてから行います。
異常時の確認も予定に入れましょう。連携先から応答がない場合などを題材に、どの手順を選ぶか、どこで操作を中止するか、誰に連絡するかを後任が説明します。安全に再現できる条件は検証環境で試し、再現できないものは机上で確認した範囲と未実施の操作を区別します。説明できたことと、復旧できたことを同じ記録にしないのが要点です。
確認記録には、対象作業、参照した資料の版、実施環境、実施者・確認者、結果、証跡の所在を残します。結果は「成功」「失敗」「未実施」に分け、失敗や未実施には理由と次の担当・期限を付けます。資料の誤りを直しただけの場合は、操作をやり直したかどうかも分かるようにしてください。
未完了事項がある場合は、影響と代替手段を管理者が確認します。たとえば、ログ閲覧は後任が行えるが、復元の確認は未実施なら、復元できる担当の待機と確認日を決めたうえで、移管する責任の範囲を合意します。「引き継ぎ済み」の印だけで未確認事項を隠さず、誰が保守を続けられる状態なのかを示します。
担当交代への備えは、自社で運用・改善を続ける体制への移行を考える際にも必要な観点です。変更を反映したときは運用手順と判断理由も更新し、連携先が増えたときは依存先と連絡先を見直します。資料作成を交代直前の作業に集中させず、日常の変更に合わせて更新する担当を決めましょう。
引き継ぎの成果は、渡した資料の量に加え、後任が確かめた操作と判断の範囲で評価します。AIで整理する工程を増やしても、確かめる人と方法を残す。この運用を続けることが、次の担当者へ保守をつなぐための土台になります。