担当者の退職で何が失われるのか：レガシーシステムの業務知識と運用を継承する
「あの人に聞けば分かる」。長く使ってきた基幹システムでは、日々の業務がこの一言に頼っていることがあります。しかし、その担当者が退職したときに失われるのは、古いプログラミング言語を読める能力だけではありません。
なぜ月末だけ処理順を変えるのか。どの取引を手作業で補正するのか。夜間処理が止まったとき、どこまで実行済みなら再実行できるのか。こうした判断の根拠が失われると、プログラムが残っていても業務を安全に続けることが難しくなります。
レガシーシステムのモダナイゼーションでは、技術の更新と同時に、担当者の判断を組織で再現できる状態にすることが重要です。
ブラックボックスは、プログラムの外にもある
ブラックボックス化を「仕様書がなく、ソースが読みにくい状態」と捉えると、調査範囲が狭くなります。実際に確認すべき知識は、少なくとも次の四つに分かれます。
知識の種類 | 確認したい内容 | 残すべき成果物 |
業務ルール | 締め日、計上基準、端数処理、例外の承認条件 | ルール一覧、判断表、具体的な入出力例 |
データの意味 | コードの使い分け、空欄の意味、過去データの補正経緯 | 項目辞書、コード対応表、補正履歴 |
運用手順 | ジョブの順序、手作業、確認帳票、社外への受け渡し | 業務カレンダー、実行手順、確認基準 |
障害対応 | 調査するログ、再実行の条件、二重処理の防止方法 | 復旧手順、判断の分岐、連絡・承認経路 |
たとえば、請求プログラムの計算が正しくても、特定の契約では営業部門が別表に基づいて値引きを補正しているかもしれません。逆に、帳票に現れる差額が不具合ではなく、過去の契約条件を維持するための調整である可能性もあります。
ソースコードから分かるのは、主に「現在どのような処理をしているか」です。「なぜその処理が必要か」「本来どうあるべきか」は、業務部門や運用担当者に確認する必要があります。
最初の調査は、日常業務よりも例外と締め処理から
限られた引継ぎ期間の中で、すべての機能を同じ深さまで調べるのは現実的ではありません。優先順位は、システムの古さよりも、担当者が不在になったときの業務への影響で決めます。
具体的には、決済・請求・出荷など止めにくい業務、月末・年度末など実行機会の少ない業務、失敗するとやり直しが難しい処理から着手します。担当者が普段は無意識に行っている確認も、こうした業務を調べる段階で表面化しやすくなります。
ヒアリングでは「この処理を説明してください」と頼むだけでなく、次のような質問もします。
この帳票を見て、どの数値が合わなければ処理を止めますか。
処理をやり直してよい条件と、やり直してはいけない条件は何ですか。
システム外で直しているデータはありますか。誰が、何を根拠に承認しますか。
年に一度しか使わない機能や、最近実施していない例外処理はありますか。
判断に迷ったとき、誰に何を確認していますか。
説明を聞く場と、実際の作業を観察する場も分けます。画面操作、スプレッドシート、メール、印刷した帳票まで追うと、仕様書には書かれていない作業どうしのつなぎ目が見えてきます。
「聞いた話」を、そのまま新仕様にしない
知識を集めていくと、記憶に基づく説明、実際のプログラム、運用実績が互いに食い違うことがあります。どれか一つを無条件に正しいとせず、それぞれの根拠を突き合わせることが必要です。
業務ルールごとに、説明者、対象処理、関連するソースや帳票、確認に使ったデータ、適用期間を記録します。確認が終わっていない内容には「要確認」と明示し、確認済みの仕様と混ぜません。
仮の例として、締め処理の前に売上日付を変更する手作業が見つかったとします。この場合、「日付を変更する手順」を残すだけでは不十分です。
その補正が、契約上の計上基準に合わせるためのものか、連携の遅れを補うためのものか、過去の不具合を避けるためのものかを区別することが必要です。理由によって、新システムに業務ルールとして実装するのか、連携方式を改善して補正を不要にするのか、例外対応として権限と履歴を残すのかという判断が変わります。
現在の操作を再現することと、将来も必要なルールを継承することは、別々に検討する必要があります。
引継ぎの完了条件は、後任が判断できること
手順書のページ数だけでは、引継ぎの品質を測れません。後任者が必要な情報にたどり着き、判断し、結果を確認できるかを確かめます。
進め方としては、担当者が実演する、後任者が説明しながら実施する、担当者が助言せずに見守る、という段階を踏む方法が有効です。障害対応では、安全な検証環境や机上演習を使い、正常系だけでなく途中停止や二重実行の可能性も扱います。
GoogleのSREに関する公開資料でも、経験者との同行、現実に近い障害を使った演習、チームでの災害対応のロールプレイなどが教育方法として紹介されています。継承を資料の受け渡しで終わらせず、判断を練習する場を設けるうえで参考になります。
Google SRE「Accelerating SREs to On-Call and Beyond」(https://sre.google/sre-book/accelerating-sre-on-call/)
たとえば、完了条件を次のように設定すると、足りない点が具体的に見えてきます。
確認対象 | 完了を判断する例 |
月次処理 | 後任者が開始条件を確認し、差額の理由まで説明できる |
障害対応 | 再実行の可否を判定し、必要な承認と連絡を行える |
業務ルール | 境界値と例外を含むテスト結果を、業務部門が確認できる |
調査能力 | 未知の事象でも、ログ・データ・仕様のどこを調べるか分かる |
これらは一律の合格基準ではなく、業務の重要度や復旧目標に合わせて定めるための例です。
モダナイゼーションと知識継承を同じ成果物で進める
調査結果は、新システムの要件定義と運用設計に引き継ぎます。業務ルール一覧は受入テストに、データの意味は移行マッピングに、障害対応の判断は監視・復旧設計に結び付けます。
ここで注意したいのは、旧システムの出力をすべて正解とみなしてしまうことです。新旧比較は有効ですが、旧システムに既知の誤りがある場合や、業務ルールを変更する場合は、差分の理由を承認しておく必要があります。比較結果を「一致・不一致」で終わらせず、「維持すべき差異か、修正すべき差異か」を判断します。
AIによるコード解析やドキュメント作成も、調査を補助できます。ただし、コードに書かれていない商習慣や手作業の理由まで、自動的に確定できるわけではありません。AIが生成した説明は仮説として扱い、担当者の説明と実データで確かめることが欠かせません。
退職日を待たず、継承できない業務を特定する
属人化への対応は、ベテラン担当者に文書作成をすべて任せる形では進みにくくなります。聞き取る人、記録する人、検証する人を分け、ベテラン担当者の限られた時間を判断の根拠の確認に使えるようにします。文書の更新責任者と見直しのタイミングも決めておけば、文書が引継ぎ直後から陳腐化するのを防げます。
株式会社Managetechがモダナイゼーションで重視するのは、現行資産に蓄積された業務知識を、次の担当者が説明・検証・改善できる形へ変えることです。技術の選定に先立って、何が分かっていて何が未確認なのかを明らかにします。この整理が、移行後の運用を支える土台になります。
担当者の退職や保守体制に不安がある場合は、システム全体の刷新を決める前に、止められない業務と、その判断を支える知識の棚卸しからご相談ください。
コメント