bon now

ありのままの現実を書き殴る吐き溜め。底辺SEの備忘録。
Written by bon who just a foolish IT Engineer.

モダンなツールが現行システムを殺す

Created Date: 2019/03/01 01:13
Updated Date: 2024/01/01 02:55

僕らの仕事領域であるIT界隈は、大変すさまじいスピード感で新しい技術が生まれている。

ついこないだまで「Dockerだ!コンテナ化してオーケストレーションすればみんな幸せになる!頑張ってオーケストレーションツールの習得に励もう!」とか言って、 やれMesosだのMarathonだのDocker-composeだのやってたのに、 いまやKubernetes一強の図式が生まれちゃってて、「これからはKubernetesができなきゃインフラの仮想化は語れない」みたいな流れができている。
そしておそらく、あと2年後くらいには「KubernetesもいいけどXXXっていう新たなオーケストレーションツールがあってだな、そいつはもはやKernelも云々」みたいな 便利ツールが生まれるのであろう。実際Kubernetesも複数クラスターをいい感じに扱えたほうがいいよね、それを管理できるともっといいよねみたいな感じで、 Rancherみたいなのも出てきてるし。なんやねん。

語れば長くなるであろうフロントエンド界隈だってそう。どうせ1年そこらで変わるからって追いかけなくなってしまったんで、 今どういうものがモダンなのかもうわかんないけど、キャッチアップする時点でそれがモダンだと分かりきってるから現状では全然困らない。 そう、困らないのだ。

モダンであること=ソリューションではない

僕自身それなりに長くIT業界にいるわけで、若い頃はよく「今どきJavaなんて流行らない!これからはRubyだ!」とか、 「COBOLはもはや化石!」っていうパワーワードをよく吹聴してたんだけど、 最近マネジャーという立場になって考えるのは、ソリューションできるのであれば古い技術であっても問題はないということだ。

COBOLが悪なのは現代のプログラミングやシステム開発に鑑みて、保守の面や運用の面で大きなデメリットを抱えているからだけど、 多くの金融系SIの現場では品質保持のための独自ツールやプロセスが存在していて、 それをきっちり守ってさえいれば少なくとも不具合は発生しないという桃源郷が既に構築されている。 だからこそCOBOLからJavaっていうテクノロジートランスファーを未だに選択しないユーザーも存在する。 住み慣れた環境でそこが安全だとわかっているのに、あえて冒険しようとは思わないのが保守的な意見の代表格だからだ。

モダンな開発を取り入れたからメリットのほうが多くなり、結果IT投資したほうが良いという決断が出ることももちろんある。 最近の日本の事例でいうと、あの悪夢のデスマーチ案件となってしまったみずほ銀行のシステムリプレースがそうだ。 結果的に大失敗してしまったんだけど、それはモダンな開発を取り入れたことが直接の要因ではないのでここでは割愛する。

他にも古い開発スタイルが解決していることは多くある。
Jenkinsは2011年に初版がでたCIツールである。8年も立つが未だ現役バリバリで活躍しているという企業も多いはずだ。 もちろんクラウドベースのCIと組み合わせて使っているユーザーもいるだろうが、 Jenkinsがローカルサーバーで可動してシステム開発に貢献する部分はとても大きい。
なんてったって何かあったら自分たちでなんとかすればいいからだ。そう、これなのだ。 自分たちでなんとかできる範囲であれば古臭い技術のソリューションも立派な手段なのだ。

現行システムがそもそも古臭いのなら、モダンは凶器でしかない

e-tax(確定申告をWebから行う)がIEを前提に作ってあることは皆さん知ってのとおりである。 こんなところにVue.jsやReactを放り込もうと考える人間がいるだろうか。ああ、いるだろう。いるんだよ。間違いなく。

百歩譲ってそれはそれで良い。でもまずやるべきはスタイルの統一と、 モダンブラウザでの動作保証をするところからだ。 すべてをプロジェクト化してもいいかもしれないが、タスクをきれいに分けることも意識しないといけない。 なぜかというと、動作保証をすることとモダン技術を取り入れることは同列ではないからだ。

とにかくどんな人が使っても動くことを優先させる。動かなければユーザーにとってはゴミだ。どんなにエレガントなモダンな技術であろうとも。 IEでなら動くという状況のほうがまだ救いようがある。全く動かないわけではないのだから。 モダンな技術が現行システムを殺すのは、こうやって「モダンであることが今後のメリットである」と信じて疑わない、 仮説・検証をすっとばして誤った選択肢を敢えて選んでしまった結果である。 モダンな技術の検証と、親和性については十分に吟味しなければならない。

IT技術も温故知新

過去を知ることは恥ずかしいことでもなければ遠回りでもない。 Kubernetesを使いたければDockerを知る必要があるし、Dockerを使いたければネットワークや仮想化技術について知らなければならない。 モダンな技術は不変の安定した技術で支えられていることも多いのである。

温故知新を以て地道にソリューションを検討していくことこそ、唯一の施策である。

まとめ

IT技術は一朝一夕の進化をしているが、根本的な部分はインターネットが生まれたあたりからほとんど変わっていない。 通信はTCP/IPだし、ネットワークはCSMA/CD CSMA/CAだし、コンピュータはノイマン型が一般的なわけで、 まだまだこの辺が大きく変わるシンギュラリティは訪れていない。もうすぐかもしれないがすぐに消え失せる技術でもない。

古い古いと言われようが、それが正しいソリューションになるのなら使ったほうが良い。 そして、その状態から次への移行を検討できるデータとフィードバックがそろったとき、モダンに移行してもなんら問題がない。 僕らの抱える問題は「古臭い技術をなんとかしよう」ではない。 殆どの場合「正しく動く現行システムをリプレースしたい」という問題が歪曲されているだけである。 リプレースの手段としてモダン技術を取り入れることはもちろん選択肢の一つだ。でもそれは必須要件じゃない。 エンジニアである以上、手段と目的はきちんと分けて考えなければならない。

local_offer
folder work