テクノロジー

平成最後に思うこと

次回まで ゴールデンウィークを挟むので、平成最後のブログになります。

私は昭和生まれですが、昭和は64年、平成が31年、次は令和。まさか3つの元号を跨がるなんて考えてたこともありませんでした。

 昭和の頃はまだ学生でしたから、あまりそこまで考えていませんでしたが、こうみると本当に昭和の時代って長かったし、色んなことが起きた時代だったんですね。

 いわゆる情報システムと言われたものが多くの中堅・中小企業にまで普及したのが、昭和60年代くらいでしょうか。

大手企業は1960年代からと比較的早く入っていましたが、中小企業にまで「オフコン」と言えるようなものが入り始めたのが昭和の終わりくらいです。(未だにIBMのAS/400というオフコンがバージョンアップしながら生きながらえているのは、よほど基本設計が凄いんだなと感心します)

 バブル期に向けてIT投資も旺盛で、金融機関なども第三次オンラインと言われる、今のオンラインシステムの基盤ができた頃でした。

 バブル崩壊後はITの大規模投資なんてできる体力がなく、2000年頃に企業の基幹システムをスクラッチ(自前で一から作る)で構築することよりもパッケージを使う動きが早まりERPパッケージやCRMパッケージなどが導入されてきました。

 しかし、本来のパッケージの思想を導入すると言うよりも、古いシステムのリプレースという形でパッケージが導入されたため、根本的な思想(つまりビジネス設計そのものです)が変わっておらず、増築や改修を重ねたり、何とかweb化したりと延命をさせながらここまできた企業も多いのかもしれません。

 本来はパッケージを導入することにより、機動的にビジネスやシステムを運用するはずが、全然それが実現されず、ビジネスの構造も非常に変えにくい環境が作られていったというのもあるかもしれません。そうなると、コスト削減効果さえ見いだすことができず、さらにシステムが温存される悪循環にはまってしまう企業も多いのではないでしょうか?

 増築を重ねたシステムを変えようにも「開発した当時の人財が既に退職している」ということもままあります。当時の仕様書を見ても、途中の改修で仕様書のアップデートがなされていない会社も多く(そもそも書類作ることに意味合いを見いだせない意志決定者が多かった)、それがさらに下手に触るよりもまさに「触らぬ神に祟りなし」と、よく分からないプログラムが温存されてしまう原因にもなりました。

 私たちが扱っている工場設備にも似たようなことがあります。多くの工場が昭和の時代に建てられたものが多く、設備を入れ替えても配線撤去工事までやっていない会社も多いんですね。

配線撤去をしたところで、その時には単に「綺麗になる」というくらいで、そこに投資の意味を見いだせなかったのかもしれません。(ものはなくなりますから、工事費用が資産計上できるわけでもなく、費用が一気に計上されてしまうわけで、利益圧迫の要因になるというのもあるかもしれません)

 そして、それが何年も後になって「何だこの配線は?」と謎の配線が出てきてしまうわけです。そして当時関わっていた人はもういません。そして、配線が混在することでトラブルの原因になってしまうので、複雑な現状調査をせざるを得ない状況に陥ってしまうわけです。

 ITも設備も似ていますね。

 ここまでお読みになって、何となく気付かれた方もいらっしゃったかもしれません。

 その場での判断が実は後になって、大きな影響及ぼし、さらに企業の変化対応力を削いでしまうのです。もうここまでくると「現場で判断を」という限界を超えてしまいます。意志決定者にとっては相当重い意思決定を迫られます。

 たかがシステム、されどシステムです。

 さて、今回の改元において、久しぶりに聴いたのが「プログラムの修正」という言葉。

このカレンダーにかんするプログラムというのは、思っている以上に頻繁に修正する必要性に迫られることがあるプログラムです。古くは平成に変わったとき、さらには2000年問題。また、うるう秒の修正(直近では2017年に行われています)というのも一つです。

 ただ、元号プログラムというのは、改元は明治以降「一天皇一元号」となりましたから、そう滅多に改修することはありません。それだけに「その場の対応」で済まされることが多いんですね。

 また、システムを根本的に見直すときに、元号プログラムを集約すればいいのですが、実態は集約しても「直近のコスト削減には繋がりにくい」ですし、さらにはプログラム全体を見直す必要があり、結局手つかずのものが多いのが現状で、今回の改元においても多くの企業でプログラム改修がなされるのではないでしょうか。

 元号が変わるだけで、なんでこんなに大騒ぎするのか?計算ロジックを変えればいいじゃないか?と思うかもしれませんが、これは技術的な問題というよりも、単純に設計の問題や意思決定の問題だったりします。

 そもそも、シンプルなシステム構成にしていれば、こんなことは起きないのですが、結局縦割りだったり、分散化されすぎていたり、システムの全体像を把握できる人がいないということから、元号プログラムがあちこちに分散していることが多いのです。

巨大なシステムだと本当に「どこにあるか分からない」。樹海に落とした指輪を探すようなこともあります。そして、そのプログラムを探し出して、その影響度合いを検証し、一つ一つ修正してチェックする最終作業がゴールデンウィーク中に行われるわけです。

 今年の10連休は「記念としても休み」というよりも、「システムトラブルを防ぐための休み」と捉えてもいいくらいなのではないかと思っています。 

 ゴールデンウィーク明けにシステムトラブルが起きやすいのですが、それが上手く行くことを心から祈らざるを得ません。

ピックアップ記事

  1. 求人ページ専用のページを追加しました
  2. スカイディスクと 水処理関連のスマートファクトリー化を促進
  3. AIエンジニアリングのWebサイトが公開になりました

関連記事

  1. テクノロジー

    新人の方が知識も経験もある

     昨日の夕方に、AIEの部屋で雑談をしてきたら、たまたま新入社員のM…

  2. テクノロジー

    標準化って「人の工夫」をないがしろにするんじゃない?

     システム化や高度化、自働化などをしていく過程では必ず「標準化」とい…

  3. テクノロジー

    「うちもAI導入しよう!」は意外とバカに出来ない

    「うちもAIを入れてはどうか?」「うちのAIの検討状況はどうなのか…

  4. テクノロジー

    人は必ずミスをする

     令和初めてのブログです。お読みの方々はお休み取れましたでしょうか?…

  5. テクノロジー

    効率的な仕組みも普及すると非効率になる怪

     今回は「効率的な仕組みも、普及してくると何故か非効率になる」という…

  6. テクノロジー

    「無用なデータが多いからデータ収集は無駄」ではない

     とある資料でインターネットを介したデータの流通量にかんする資料があ…

2019年5月
« 4月    
 12345
6789101112
13141516171819
20212223242526
2728293031  

最近の記事

  1. ワークライフ

    「完璧」を保身のためにしても保身にはならないパラドックス
  2. 問題解決

    重箱の 隅をつついて ドヤ顔る そのドヤ顔に 金がかかるとも知らず(字余り)
  3. ブログ

    「俺様システム」が会社から変化対応力を奪う
  4. 問題解決

    「もったいない」がコストを増やすパラドックス
  5. AIエンジニアリング

    お知らせ

    AIエンジニアリングのWebサイトが公開になりました
PAGE TOP