半年経っても不安が消えない理由
承継から半年が過ぎても、システム面の不安が減らない社長は多い。台帳はある程度埋まった、開発会社にも一度は挨拶した、それでも「どこかに爆弾が眠っているのではないか」という感覚が消えない。
これは気の持ちようの問題ではない。多くの場合、序盤にやったはずの確認作業のどこかに抜けがあり、それが半年経っても解消されないまま残っている。1年目後半に差し掛かって不安が続くなら、新しいことを始める前に、まず序盤の確認手順を時系列で振り返る方が近道になる。
不安の正体そのものについては承継したばかりの社長が、毎月最初に見直しておきたいこと、最初の1週間にやるべきことは会社を継いだ最初の1週間。先代のシステムをどう引き継ぐかで扱っている。ここでは半年経過時点での「振り返り方」に絞る。
判断の分かれ目 — どの段階で止まっていたか
半年経っても不安が消えない場合、序盤の確認作業は次の3段階のどこかで止まっていることが多い。
段階1: 現状調査そのものが浅かった 先代のシステムを「見た」だけで、実際に動かして中身を確認していない。触ると壊れると言われて調査を避けたまま止まっているケース。
段階2: 調査はしたが記録に残していない 確認はしたが、口頭やメモだけで済ませてしまい、体系立てて残していない。担当者本人の記憶に依存している状態。
段階3: 記録はあるが検証していない 台帳や記録はあるが、それが「実際に機能するか」を試していない。特にバックアップは取っているのに復元を試したことがない、というケースが典型的。
どの段階で止まっているかによって、半年後にやるべきことは変わる。
段階1で止まっている場合 — 調査をやり直す
「触ると壊れる」と言われたシステムを避け続けている場合、まずは壊さない前提での調査手順を踏み直す必要がある。「触ると壊れる」と先代に言われ続けたシステムを調査する順番、仕様書が残っていない場合の復元方法は仕様書がない先代システムの仕様を、動きから逆算して復元する方法を参照してほしい。半年経っていても、ここを飛ばして次に進むと不安の根はそのまま残る。
段階2で止まっている場合 — 記録を仕組み化する
調査はしたが記録が個人の記憶頼みになっている場合は、引き継ぎ書がない会社が承継後すぐに始めるシステム記録術を参考に、記録の取り方自体を仕組みに変える。半年経つと記憶はさらに薄れるため、このタイミングで一度形にしておく価値は大きい。
段階3で止まっている場合 — 検証する
記録はあるのに検証していない典型例がバックアップだ。「先代の時代から取ってはいる」という状態と、「実際に復元できる」状態はまったく別物であり、バックアップ、先代の時代から取ってはいるが復元できるか試したことはあるかにあるとおり、多くの会社がこの検証を飛ばしたまま何年も過ごしている。同様に、システムが止まったときに何が影響を受けるかという単一障害点の洗い出しも、記録があっても実際の影響範囲までは確認していないことが多い。先代の代からのサーバーが壊れたら何が止まる？単一障害点の洗い出し方で手順を確認できる。
半年時点でのチェックポイント
不安が消えない理由を探すときは、次の順番で自問すると振り返りやすい。
まず、先代のシステムを実際に動かして確認したか。次に、その結果を自分以外の誰かが見ても分かる形で残したか。最後に、その記録が実際に「使える」ことを一度でも試したか。この3つのうち、答えが曖昧な段階があれば、そこが不安の発生源になっている可能性が高い。
新しい確認作業を積み増す前に、この3段階を時系列で遡って埋め直すことが、半年目の不安を減らす最短の道になる。刷新や改善はまだ先の話でいい。1年目後半の今は、序盤の抜けを塞ぐことに集中する段階だ。