ITシステムが老朽化しているのは他人ごとではない。

日経IT Pro「メインフレーム撤廃、自力で難題乗り越えクラウド化」（2017/09/06）
はメインフレームからの脱却みたいに書いてあるけど、実質はそうではない。古いシステムを刷新する際に発生するよくあることなのだ。
この件に関してはプラットフォームがなにかは関係なく、企業にはすでに数十年たっているシステムを利用しているところは多い。
つまりそれだけ古くなれば、システムを刷新しようにも、担当者が自社・IT業者からいなくなり、詳細不明となり手をつけられないというのが実情だ。

このような場合、記事の東急ハンズの例に倣うことが古いシステムを刷新するために取りえる最善の方法と考える。
状況をまとめるとこうだ
１．ソースコードが不明
２．入出力仕様がわかっている
３．稼働しているシステムの業務の概要はわかっている

これは外部設計はあるが、内部設計がないということになる。スクラッチから作る際と全く同じ、次の内部設計局面を実施すればいいだけである。
問題は、外部設計をすべて洗い出せているか？の一点でシステム内で別の業務システムとの間のデータのやり取りが見つからないケースが怖い。
業務システムには日次で実施するもの、週次・月次・年次のように実行するタイミングが異なるものが含まれているからだ。
このような処理を業務外のJOBスケジューラから起動している場合は比較的に楽である、JOBスケジューラに登録しているものを解析すればいいからだ、しかしこのような場合でも業務システム内で独自に実施されているものは拾えないため並行稼働期間を置く必要がある。

それを外注するとなると外部技術者を長期にわたり保留することになるため、コスト増になり予算がないと頼みづらいし、業務を詳細に理解してもらう必要がある。古いシステムの刷新は、一番業務をわかっている内部の人材が主動して実施するのがふさわしいと私は思う