「動いているから触るな」と言われるシステムの安全な改修手順

「動いているものに、なぜわざわざ触るんだ」。会議室でその一言を言われた瞬間、進めるつもりだった改修の話は宙に浮きます。言っているのは、必ずしもITに疎い上司だけではありません。長くそのシステムを見てきた別の担当者や、過去に一度触って痛い目を見た経営層からも、同じ言葉が返ってくることがあります。悪気があるわけではなく、むしろ会社を守ろうとする発言です。しかし担当者の側には、そのシステムに手を入れなければならない具体的な理由があります。連携先のサービスが仕様変更を予告してきた、EOL（サポート終了）が迫っている、業務量が増えて限界が見えている——。このまま何もしなければ、いずれもっと大きな形で問題が噴き出すことは分かっている。それでも「触るな」の一言の前では、その危機感を言葉にして伝えることすら難しく感じられます。

この記事は、そうした板挟みの状況にいる担当者のために書きました。結論を先に言うと、「動いているから触るな」という反対意見は、正しい場合と誤っている場合の両方があります。まず必要なのは、その反対意見がどちらに当てはまるのかを見極めることです。そのうえで、改修が本当に必要だと判断した場合には、反対する人たちの不安をひとつずつ解消しながら、影響範囲を最小限に抑えた手順で進める方法があります。頭ごなしに押し切るのでも、諦めて先送りにするのでもない、第三の進め方を順を追って解説します。

この記事で分かること

この記事では、「動いているから触るな」と言われる社内システムに対して、周囲の懸念を解消しながら安全に改修を進めるための考え方と具体的な手順を解説します。反対意見の背景にある心理を理解するところから、改修前の影響調査、合意形成の進め方、段階的な実施方法、そして改修後に同じ対立を繰り返さないための記録の残し方まで、一連の流れとして扱います。

全体の進め方を先に示すと、次の5段階です。

• 反対意見の分解: 「触るな」という言葉の裏にある本当の懸念を具体的に言語化する
• 現状調査: 改修対象のシステムが何に、どこまで影響しているかを洗い出す
• 小さな検証: 本番環境に触れる前に、影響のない範囲で仮説を検証する
• 段階的な実施: 一度にすべてを変えず、戻れる単位に区切って進める
• 記録と共有: 何を、なぜ、どう変えたかを残し、次に同じ対立が起きないようにする

「動いているから触るな」は、多くの場合、改修そのものへの反対ではなく、「何が起きるか分からないまま変えられること」への不安です。この不安の正体を理解し、順序立てて安心材料を積み上げていくことが、この記事全体を通じた最大のポイントです。

なぜ「動いているから触るな」と言われるのか

結論から言うと、「触るな」という反対意見は、多くの場合、過去の失敗体験に基づいています。頭ごなしに変化を嫌っているわけではなく、「以前、似たような改修で痛い目を見た」という具体的な記憶があるケースがほとんどです。

中小企業の情報システムでは、次のような経験が積み重なっていることが少なくありません。

• 過去にちょっとした修正のつもりで手を入れたら、想定外の箇所が連鎖的に止まった
• 改修を依頼した開発会社が、影響範囲を十分に洗い出さないまま作業し、トラブルになった
• 誰が何のために作ったか分からない機能を消したら、別の部署の業務が止まった
• 改修中に業務時間内でシステムが使えなくなり、現場から強いクレームが出た

こうした経験がある人ほど、「今回は大丈夫」という言葉を信用しにくくなります。これは合理的な学習の結果であり、単なる保守的な態度として片付けるべきではありません。属人化が進んだシステムほど、実際に触ってみるまで影響範囲が読めないという性質があるため、周囲の警戒心が強くなるのはむしろ自然な反応です。

もう一つ見落とされがちな理由が、責任の所在です。改修を承認した人は、その改修が原因でトラブルが起きたときに説明を求められる立場になります。特に決裁者がシステムの中身を理解できないまま「良さそうだから」で承認してしまうと、後で問題が起きたときに自分の判断を正当化できません。この「説明責任を負いたくない」という心理が、「今のままなら誰にも責められない」という現状維持の選択につながっています。

「触るな」と言う人の多くは、システムそのものに反対しているのではなく、「何が起きるか説明できない変化」に反対しています。この違いを理解しないまま説得を試みても、話は平行線をたどります。

反対意見を「非合理な抵抗」として扱ってしまうと、対話の糸口を失います。まずは、その反対意見の裏にどんな具体的な懸念があるのかを、決めつけずに聞き出すところから始める必要があります。

「触るな」が実は正しいケースもある

改修を進める前提で話を進める前に、一度立ち止まって確認しておきたいことがあります。それは、「触るな」という反対意見が、実際に妥当な場合があるという点です。担当者が改修を急ぐあまり、この可能性を見落とすと、周囲の懸念どおりの事態を引き起こしてしまいます。

次のような状態にあるシステムは、通常の改修プロセスをそのまま適用すると危険です。

これらの条件に一つでも当てはまる場合、「小さな改修のつもりが致命的な障害になる」というリスクが現実的に存在します。この場合の「触るな」は、感情的な抵抗ではなく、正しいリスク認識に基づいた警告です。焦って進めるのではなく、まずこれらの前提条件を整えることを優先してください。仕様書の代わりとなる調査、単一障害点の冗長化、バックアップの復元検証、管理台帳の整備は、いずれもこの記事の関連記事で個別に扱っています。

一方で、これらの前提条件がすでに整っている、あるいは今回の改修規模であれば許容できるリスクに収まっている場合は、「動いているから」という理由だけで改修を止め続けることは、むしろ会社にとってのリスクになります。次の章からは、この「進めるべき」と判断した場合の具体的な手順を解説していきます。

ステップ1: 改修が「本当に必要」かを言語化する

反対意見への対話に入る前に、まず自分自身の中で改修の必要性を整理しておく必要があります。「なんとなく古いから直したい」という動機のまま説得を試みても、相手を納得させることはできません。

改修の必要性を言語化する際は、次の3つの観点で整理すると伝わりやすくなります。

• 期限があるか: 連携先のサービス終了、OSやソフトウェアのサポート終了、法制度の改定など、対応しなければ確実に問題が起きる日付があるか
• 放置コストが増え続けているか: 手作業での代替対応に、月あたりどれくらいの工数がかかっているか
• リスクがすでに顕在化しかけているか: エラーの頻度が増えている、処理時間が伸びているなど、限界の兆候が実際に出ているか

これらの観点のうち、特に効果的なのは「期限があるか」です。「いつか直したほうがいい」という話は先送りされやすい一方、「いつまでに対応しないと確実に止まる」という話は、経営層の判断を引き出しやすくなります。連携先からの仕様変更通知のメール、EOLの告知ページなど、根拠となる一次情報を手元に用意しておくと、説得の材料として説得力が増します。

逆に、「今の画面が見づらいから」「もっと新しい技術で作り直したい」といった、担当者側の好みや技術的な興味が動機の中心になっている場合は、いったん立ち止まったほうがよいかもしれません。改修には必ずリスクとコストが伴います。そのリスクに見合うだけの理由が、業務側にあるかどうかを自分自身にまず問い直してください。

ステップ2: 影響範囲を洗い出す

改修の必要性を言語化できたら、次に行うべきは、そのシステムが実際に何と、どこまでつながっているかを洗い出す作業です。これは説得材料を作るためだけでなく、改修そのものを安全に進めるための土台になります。

影響範囲の調査では、次の4つの切り口で確認していきます。

1. データの入出力: このシステムはどこからデータを受け取り、どこへデータを渡しているか(他システムとの連携、CSVのやり取り、印刷帳票の有無など)
2. 利用者: 誰が、どの部署が、どのくらいの頻度でこのシステムを使っているか
3. 依存している他の仕組み: このシステムの上で、別のVBAマクロや自動処理が動いていないか
4. 稼働時間帯: 業務時間中だけ使われているのか、夜間バッチのように無人稼働している時間帯があるか

この調査は、地道な確認作業の積み重ねになります。画面を一つずつ操作して出力されるファイルを確認する、ネットワーク接続の状況を調べる、関係しそうな部署に「このシステムを使っていますか」とヒアリングして回る、といった方法を組み合わせて進めます。仕様書がないシステムの調査手順そのものについては、関連記事でより詳しく解説していますので、あわせて参照してください。

この段階で重要なのは、「分からない部分を分からないままにしない」という姿勢です。「たぶんここは関係ないだろう」という推測で調査を打ち切ってしまうと、後になって想定外の箇所に影響が及び、まさに反対派が懸念していた通りの事態を引き起こしてしまいます。時間がかかっても、確認できる範囲は実際に確認してください。

影響範囲の調査結果は、次のような形で一覧化しておくと、後の合意形成でもそのまま使えます。

このように整理することで、「どこを慎重に扱うべきか」「どこは比較的安全に触れるか」が視覚的に分かるようになります。

ステップ3: 本番に触れる前に、小さく検証する

影響範囲が見えてきたら、いきなり本番のシステムに手を入れるのではなく、影響のない範囲で仮説を検証する段階に進みます。この工程を挟むかどうかが、「動いているから触るな」派を説得できるかどうかの分かれ目になります。

検証の方法は、システムの種類や予算によって選択肢が変わりますが、代表的なものは次の3つです。

• コピー環境での検証: システムやデータベースを複製した環境を用意し、そこで改修内容を試す。最も安全だが、複製に手間やコストがかかる場合がある
• 一部データ・一部利用者だけの試験運用: 全社に展開する前に、特定の部署や一部のデータだけで新しい仕組みを試す
• 並行稼働: 既存の仕組みを止めずに残したまま、新しい仕組みを並行して動かし、出力結果を突き合わせて一致することを確認する

予算の都合でコピー環境を用意できない場合でも、「変更を適用する前に必ずバックアップを取得し、いつでも元に戻せる状態にしてから作業する」という最低限の備えは欠かせません。バックアップを取得しているつもりでも、実際に復元できるかを一度も試したことがないケースは珍しくなく、いざというときに使えないバックアップほど危険なものはありません。改修に着手する前に、必ず一度は復元の手順を確認しておいてください。

小さな検証を経てから本番に反映するという進め方自体が、「いきなり大きく変える」ことへの周囲の不安を和らげる材料になります。反対していた人に対しても、「検証環境でこういう結果が出た」という具体的な事実を示せるようになるため、説得の質が大きく変わります。

ステップ4: 反対する人と対話し、合意を形成する

必要性の言語化、影響範囲の調査、小さな検証まで済んだら、いよいよ反対している人たちとの対話に入ります。ここでのポイントは、「説得する」のではなく「不安を一緒に解消する」という姿勢で臨むことです。

対話の進め方として、次の順序をおすすめします。

1. まず懸念を聞く: 「なぜ触ってほしくないと感じているか」を、決めつけずに具体的に聞き出す
2. 懸念に対応する材料を示す: 影響範囲の調査結果、検証環境での結果、バックアップとロールバック計画を具体的に示す
3. 最小の単位から提案する: 一度に全部を変えるのではなく、「まずこの部分だけ」という小さな提案から始める
4. 戻せることを明確にする: 何か起きたときに、いつまでに、どうやって元の状態に戻せるかを事前に約束する

特に効果的なのが、4つ目の「戻せることを明確にする」です。反対する人の本音は「変えること」そのものよりも「変えた結果、取り返しがつかなくなること」への恐れであるケースが多く見られます。「万が一うまくいかなかった場合は、この手順で30分以内に元の状態に戻します」と具体的に約束できれば、反対のハードルは大きく下がります。

社内の決裁を通す必要がある場合は、稟議の起案書に、この記事で整理した必要性・影響範囲・検証結果・ロールバック計画をそのまま反映させると、ITに詳しくない決裁者にも判断材料が伝わりやすくなります。「なんとなく心配だから」ではなく「何が起きても、どう対応するかが決まっている」という状態を示すことが、合意形成の核心です。

対話をしても意見が平行線のまま進まない場合は、無理に押し切らず、いったん規模を縮小した提案に切り替えることも検討してください。全体を一度に変えるのではなく、影響範囲が最も小さい一部分だけを試験的に改修し、実績を作ってから次の範囲に広げるという進め方であれば、慎重な人からの合意も得やすくなります。

ステップ5: 段階的に実施する

合意が取れたら、いよいよ改修の実施です。ここでも「一度に全部変えない」という原則を貫くことが、安全性を高める最大のポイントです。

段階的な実施の代表的な進め方には、次のようなものがあります。

• 機能単位で分割する: 改修対象の機能をいくつかに分け、影響範囲の小さいものから順に適用する
• 時間帯を選ぶ: 業務への影響が最も少ない時間帯(夜間、休日、月末以外の期間など)に作業を実施する
• 利用者を限定して展開する: 一部の部署・一部の担当者だけに先行して新しい仕組みを使ってもらい、問題がないことを確認してから全体に展開する
• 旧仕組みをすぐには消さない: 新しい仕組みに切り替えた後も、一定期間は旧仕組みを残し、いつでも切り戻せる状態を保つ

この段階で欠かせないのが、作業前後の状態を記録することです。「改修前にどういう状態だったか」を数値や画面キャプチャで残しておくと、改修後に「何かおかしい」という声が上がったときに、実際に改修が原因なのか、それとも別の理由なのかを切り分けやすくなります。

作業当日は、次のようなチェックリストを用意しておくと、実施中の判断がぶれません。

• [ ] 作業前のバックアップを取得し、復元できることを確認したか
• [ ] 作業中に問題が起きた場合の連絡先・エスカレーション先を関係者に共有したか
• [ ] ロールバックの判断基準(何が起きたら中止して元に戻すか)を事前に決めているか
• [ ] 作業後の動作確認項目を、作業前にリストアップしているか
• [ ] 想定していた作業時間を超過した場合の判断(続行するか、いったん撤退するか)を決めているか

問題が起きた場合のエスカレーション先や対応手順が曖昧なまま作業を始めると、トラブル発生時に誰に相談すればよいか分からず、被害が拡大しやすくなります。作業前に必ず、連絡ルートを明確にしておいてください。

ステップ6: 改修後の記録を残し、次の対立を防ぐ

改修が無事に完了したら、そこで終わりにせず、必ず記録を残す作業まで行ってください。この最後の一手間が、次に別の改修が必要になったときの「触るな」の壁を低くします。

記録に残すべき内容は、次の3点です。

• 何を、なぜ変えたか: 改修の目的と背景を、後から読んでも分かる形で残す
• どのように検証し、実施したか: 検証環境での結果、実施時の手順、発生した問題とその対応
• 今後の注意点: 今回の改修によって、新たに気をつけるべき点が生まれた場合はそれも明記する

これらの記録は、システム管理台帳や引き継ぎ資料に統合しておくことをおすすめします。散在したメモや個人のメールに残すのではなく、誰でも参照できる共通の場所にまとめておくことで、次の担当者が同じ調査をゼロからやり直す事態を防げます。

そして何より、今回の改修が無事に完了したという実績そのものが、社内での信頼につながります。「以前、慎重に進めて問題なく改修できた」という事実は、次に改修が必要になったときの「動いているから触るな」という反対の声を和らげる、何よりの説得材料になります。逆に、記録を残さずに終えてしまうと、せっかくの実績が社内の共有財産にならず、次の担当者(あるいは数年後の自分自身)がまた同じ場所でつまずくことになります。

自社だけで対応できない場合の考え方

影響範囲の調査や検証環境の準備まで進めた結果、「これは自社の担当者だけでは手に負えない」と判断することもあります。特に、レガシーシステムの内部ロジックが複雑で解読が難しい場合や、改修に専門的な知識(古い言語での開発経験、特定のデータベース製品の知識など)が必要な場合は、無理に自力で進めようとせず、外部の開発会社に依頼することも検討してください。

外部に依頼する場合でも、この記事で解説した準備(必要性の言語化、影響範囲の調査結果、検証結果)は、そのまま見積もり依頼の材料になります。何も調べていない状態で「このシステムを直してほしい」とだけ伝えるよりも、影響範囲や現状のリスクを整理した資料を渡したほうが、開発会社側も的確な見積もりを出しやすくなり、結果として費用や期間の見通しも立てやすくなります。

外部の開発会社を選ぶ際に、この記事のテーマに関連して特に確認しておきたいのは次の点です。

• 改修前の影響調査を、開発会社側でも独自に行ってくれるか(発注者側の調査結果を鵜呑みにせず、専門家の視点で再確認してくれるか)
• 万が一のロールバック(切り戻し)についての方針が、契約や見積もりの中で明確になっているか
• 改修後の保守契約について、どこまでの範囲を、どのような条件で対応してもらえるか

「動いているから触るな」と言われるシステムほど、改修の難易度も、失敗したときの影響も大きくなりがちです。自社の体制やスキルで対応しきれないと感じた時点で、抱え込まずに外部の力を借りるという選択肢を早めに検討することも、担当者としての適切な判断のひとつです。

よくある失敗パターン

改修を進める過程で陥りやすい失敗をまとめておきます。自分の進め方がこれらに当てはまっていないか、実施前に確認してください。

これらの失敗の多くは、「早く終わらせたい」という焦りから生まれます。「動いているから触るな」と言われる状況は、担当者にとって精神的な負担が大きいものですが、焦って手順を省略するほど、かえって時間がかかる結果になりやすいという点を意識しておいてください。

まとめ

「動いているから触るな」と言われたとき、担当者に必要なのは、反対を押し切る勢いでも、諦めて先送りにする消極性でもありません。反対意見の背景にある懸念を具体的に理解し、その懸念をひとつずつ解消しながら進める、という地道な手順です。

この記事で解説した流れを、あらためて整理します。

• 「触るな」という反対意見の裏にある具体的な懸念を、決めつけずに聞き出す
• 仕様書の不在や単一障害点など、反対意見が実際に妥当なケースでは、無理に進めず前提条件を整えることを優先する
• 改修の必要性を、期限・放置コスト・リスクの顕在化という観点で言語化する
• 影響範囲を実際に調査し、どこが安全でどこが危険かを可視化する
• 検証環境や並行稼働を挟み、本番への影響を確認してから展開する
• 対話を通じて、戻せることを具体的に約束し、合意を形成する
• 改修は一度に全部変えず、機能単位・利用者単位で段階的に展開する
• 完了後は必ず記録を残し、次に同じ対立が起きないようにする

「動いているから触るな」という言葉は、担当者にとって理不尽に感じられることもありますが、その裏には過去の失敗体験や、責任を負うことへの不安といった、汲み取るべき事情があります。順序立てて不安を解消していけば、多くの場合、周囲は改修そのものに反対しているわけではないことが見えてきます。今回整理した手順は、今後別のシステムを改修する際にもそのまま応用できます。まずは、このシステムが実際にどこまで影響を及ぼしているのか、影響範囲の調査から始めてみてください。