たまには真面目なことを書いてみましょう(笑)
2000年問題が大きな話題になってから10年以上経過しました。
当時はY2K問題なんて呼ばれ方もしていて社会的な大問題となり大きく報道されていたっけ。
コンピュータシステムで保持している日付データの内、年を表現している桁が2桁のものは「日付大小が2000年を境に逆転してしまい正しい計算結果が得られない」というのが問題の核心だったと記憶しています。
当時を思い出すと「COBOLなど古いコンピュータ言語で作られているシステムはそうなる」など古い言語を使って作られたシステム全てがY2K問題にさらされるような報道が随所でみられ「うーーん、開発言語の問題じゃないと思うんだけど...」と感じたことを思い出します。
確かにCOBOLなどで作られたコンピュータシステムにY2K問題が発生したことは事実と思います。しかしこれって、開発言語の問題ではなくてデータベース設計の問題のような気がしてなりません。比較的新しい、オープン系で動作する開発言語でシステムを作ったとしてもデータベース設計で年2桁しかなければY2K問題は発生するわけですから。
これまた当時を思い出すとCOBOLで作られたシステムは「レガシーシステム(某日本車メーカーが作っているAWD車には関係ありません)」などと言われ大きなシステムトラブルを起こした某官公庁システムがCOBOLで作られていたことからもCOBOLが悪者扱いされてましたっけ。
運用、開発ドキュメントが整備されていなく保守困難となっている「塩漬け」システムをレガシーというようですが、先日某大手新聞社サイトでレガシーシステムを扱っている記事があり「レガシーはメインフレームだけにあらず」的なことが書いてありました。
その記事によれば2000年以降、しかも2005年以降に立ちあがったシステムでも既に保守困難となっているものがあるというんです。
しかもほとんどがオープン環境で動くものだそうです。パッケージ、スクラッチ開発に関わらず「保守困難」とのこと。
一体何が起きているのか...
記事には「システムの寿命がきている」ともありましたが、メンテナンスしないとそうなるとのこと。
確かに。
システム利用環境って常に変化にさらされていてメンテナンス無しでユーザーニーズに耐えないことは長年のSE人生で身を持って経験しています。
「システムの寿命」という表現を「メンテナンス無しにシステムを使える限界」を言っているのでは?と経験から読み取れ妙に納得しています。
ではなぜメンテナンス出来ないのか?
多くの場合はパッケージにしろスクラッチにしろユーザー企業からベンダーに開発・導入を依頼しているでしょう。
開発・導入コスト圧縮などが原因で前述の「ドキュメントが無くて保守出来ない」状態になるんでしょうか。詳細はそれぞれ企業でシステム利用環境、開発思想が異なるでしょうから分かりません。
ただ...はっきりしているのはレガシーシステム発生はハードウェア、開発言語などのプラットホームが限定されての発生では無く...メインフレーム、オフコン、オープンなど何処でも発生の可能性があり「道具は関係ない」ってことです。
ちょっとした新聞記事でしたが何だか考えさせられました。
当社に当てはめると...開発スキルが社内にあることから常にシステムを変化させて情勢に対応しています。
一見理想的にも思えますが属人的な開発体制にどうしてもなってしまう、開発着手から稼働開始までのスピードを最優先することからドキュメントの不備が発生するなど悪い面も当然出てきています。
いい面もあり、その裏側にリスクもある体制ですが当面は技術の伝承さえきっちり対応しておけばいいかと考えます。
「プレゼンソフトがあれば簡単にプレゼン作れる」
「ホームページ作成ソフトがあれば簡単にホームページが作れる」
違いますよね、これって。
それなりの方が作業に見合ったツールを使えば「簡単」なわけで...
道具は道具。これもシステムと同じことです。
システム屋の私としては技術偏重、道具寄りになりがちな面もありますが本質を捉えてのシステム開発を忘れずにやってきたいなと思ってます。
と言いながら...ここ最近、「某タブレット端末で会議資料なり製品図面なりを配信するのって面白そうだな」なんて考えてるのでした。
この考え、まったくメリットとデメリットを考えないで「面白そう」と直観的に考えてただけ。ま、直感も大事か...
何だかおかしな文末になりましたが本日ブログはこの辺で終了します。