XPの中古パソコンを探している会社がある
設計に使っているソフトがWindowsXPでしか動かない。ソースコードはない。作った会社はもう存在しない。だから中古のXPマシンをネットで探して、壊れたら次の中古を買う。
笑い話のように聞こえるかもしれないが、中小製造業では珍しくない。自分の会社にも、32bitのVBAで動いている業務ツールや、16bitのコマンドプログラムが現役で動いている。ただし、これらは中身を把握した上で「今は乗り換えなくていい」と判断して残しているもの。把握しているのと放置しているのでは、同じ「触らない」でも意味がまったく違う。
触らない理由自体はよくわかる。動いているものを下手にいじれば業務が止まる。ソースコードがなければ中身を読むこともできない。仮に作り直すとしても、仕様書はないから、動いているソフトの挙動を見ながら仕様を読み解くしかない。その工数を誰が出すのか。日常業務を回しながらそんな余裕はない。
だから「動いているうちは触らない」は、怠慢ではなく合理的な判断だと思う。ただし、それは中身を把握した上での判断であるべきで、「よくわからないけど動いている」のまま放置するのとは違う。
「いつか止まる」ではなく「必ず止まる」
古いソフトが止まるタイミングは3つある。
ハードウェアの故障。 XPが動くパソコンは生産終了から10年以上経っている。中古で手に入るとしても、いつまで見つかるかわからない。SSDやHDDは消耗品だし、マザーボードのコンデンサも劣化する。ある日突然起動しなくなる。
OSの世代交代。 Windows自体が古いアプリケーションの互換性を少しずつ切り捨てている。32bitアプリは今のWindows 11でもまだ動くが、16bitアプリはWindows 10の64bit版からすでに動かない。次のWindowsでさらに何が切られるかは誰にもわからない。
人の退職。 「あのソフトの使い方を知っている人」「何をやっているか説明できる人」がいなくなる。ソフトが動いていても、操作できる人がいなければ同じこと。そしてこの3つの中で、人の問題が一番予測できない。
どれも「いつか」ではなく「必ず」起きる。問題は、いつ起きるかがわからないこと。
突然止まったときに何が起きるか
ある朝、設計用のパソコンが起動しない。修理に出しても、部品がもう手に入らない。
ここからが本当に厳しい。
そのソフトで何をやっていたのかを、ゼロから読み解く作業が始まる。ドキュメントはない。ソースコードもない。使っていた本人が「こういう数字を入れるとこう出てきた」と記憶を頼りに説明するしかない。その記憶が正しい保証もない。
以前の記事で「属人化のトリアージ」について書いた。ベテランの頭の中にある暗黙知をどう備えるかという話だったが、古いソフトの問題はさらに厄介になる。ベテランの知識は聞けば引き出せるが、ソフトの中のロジックは動かさなければ確認できない。動かなくなってからでは遅い。
→ 中小製造業の「脱属人化」は最初から目指さなくていい ── 属人化のトリアージという考え方
そしてこの状況で「作り直す」となったとき、相当な時間がかかる。仕様の把握だけで数ヶ月。開発にさらに数ヶ月。その間、その業務はどうするのか。手作業で回すのか、仮のツールを急いで作るのか。どちらにしても、通常業務と並行して進める負荷は大きい。
移行先の話は後でいい
こう書くと「じゃあ早く新しいソフトに移行しよう」という話に見えるかもしれないが、この記事で言いたいのはそこではない。
移行先を決めるのは、まだ先の話でいい。CADなのか、生産管理なのか、積算ツールなのかで答えはまったく違うし、業種や規模でも変わる。汎用的な正解は書けない。
今すぐやるべきなのは、 棚卸し のほう。
棚卸しは日常業務の延長でできる
棚卸しといっても、工数をかけてプロジェクトにする話ではない。日常業務の中で、気づいたときに以下の4点を確認していくだけでいい。
1. 何が動いているか。 どのパソコンで、どんなソフトが動いているか。名前すら正確に把握されていないケースもある。
2. 何の上で動いているか。 OS、バージョン、32bitか64bitか。これがわかるだけで、いつ動かなくなるリスクがあるかが見える。
3. ソースコードや設定ファイルはあるか。 ソースがあれば移行の選択肢が広がる。なければ覚悟を決める材料になる。逆アセンブリで中身を読むという手段もあるが、現実的ではないことが多い。
4. 操作や仕様を説明できる人は誰か。 この人がいなくなったらどうなるかを考える。定年が近いなら、時間はもっと限られている。
以前の記事でExcelの棚卸しについて書いたが、考え方は同じ。棚卸しの目的はファイルを整理することではなく、 「何がどうなっているかを把握すること」 にある。把握できていないものは、壊れたときに直せない。
「いつかやろう」が一番危ない
棚卸しに特別な工数は要らない。普段の業務で古いソフトに触れたとき、「これ何のOSで動いてるんだっけ」「ソースコードってあるのかな」と確認するだけでいい。週に1つ確認するだけでも、半年もあれば全体像が見えてくる。
一番危ないのは、「わかってはいるけど、今は動いているから」と先送りにすること。それが5年、10年と続いて、ある日突然止まる。そのとき、棚卸しすら終わっていなければ、何があったのかを把握するところからのスタートになる。
古いソフトを「動いているから大丈夫」と思えるのは、それを支えているハードと人がまだ残っているから。どちらも永遠ではない。
以前の記事で「DXは地固めから始める」と書いた。まず知る、守る、その後に変える。古いソフトの棚卸しは、まさにこの「知る」の部分にあたる。
→ 中小製造業のDXは「地固め」から始める ── 改善の前にやるべき3つのこと
動いているうちに、動いているものを把握する。それだけで、止まったときの選択肢が変わる。
このシリーズの他の記事：