見出し画像

「既存踏襲」と言う名の免罪符

今年も早いもので、つい最近正月を迎えたと思ったのに、もう9月。1年の3/4を過ぎてしまった。年と取ると日が経つのが早く感じる(笑)

さて、私ワニはフリーで業務委託で、今、某卸会社の在庫管理システムのシステム更改の仕事をしている。

このシステムはVB.NetとOracleで2020年前後、いや、もっと前からか?に作られたシステムのようである。

IT業界にいる人にはわかるかもしれないが今、この時代にVB.Netか?と、VB.Netの将来性を考えると疑問に思うだろう。普通。

なので、システムオーナのご依頼としてはこのシステムをクラウド化したいという希望である。おそらく、他の多くの企業にサブスクリプションで売り、売上を立てたいのであろう。まあ、まあ、今風ではあると思うが。

問題は既存のVB.Netのシステムである。

IT業界にいる人にはすぐ、わかるだろうが、この既存のシステムのスタイルはOracleのDBサーバは独立して稼働しているのだろう。VB.Netで作成したアプリケーションは各各のWindowsPCにインストールして、VB.NetのアプリケーションからODBCでOracleにアクセスする構成である。

うーむ・・・2020年?いや、もっと前、2000年ぐらいに流行ったクライアント・サーバのアーキテクチャではないだろうか?2020年でもこのスタイルで新規システムを構築しようとする?普通、しないだろうな。もしかしたら、それよりも前のシステムがあって、それを焼き直したのが2020年なのかもしれない。それなら、まー、まー納得できるだろう。

この、既存のシステムが曲者で、あまりもの酷さでXでも呟いているが・・・

そう、Oracleのストアドプロシージャ、使いまくりなのである。何でもSQLでやろうとする、Oracleの、Oracleでしか使えないような機能、関数をゴリゴリ使いまわしているストアドプロシージャにビジネスロジックの大半がある。

大半と書いたのは、どういうポリシーなのか、データベースに対する何らかの変更は必ずストアドプロシージャで書くという謎、ポリシーで、それ以外データベースを検索するだけならVB.Net側にSQLが(これまた、文字列連結で書かれている)書かれている。

つまり、データベースに対するアクセスがVB.Net側と、Oracleのストアドプロシージャに分散されてしまっているのである。

この時代にしても、通常であればGUI部分、ビジネスロジック部分、データベースアクセス(ORマッパー)、その全体の制御部分が分離されているのが普通だと思う(古いがMVCとか、MVVMとか)が、それが渾然一体となっている。

そんな、この時代にこのアーキーテクチャか?という疑問符が付くシステムをクラウド化しようとしてもそのままクラウドシフトはできない。当然、全面的に作り直し、Webシステムで作り直しとなる。

システムオーナのご希望としては、

「とりあえずはクラウド化したい。多少、不要な機能は削除しても基本はいまのまま・・・」

そこででてくるのが、このパワーワード、

「既存踏襲」である

(※「既存踏襲」とも「現行踏襲」とか言われるが意味は同じ)

システム更改のプロジェクトにおいてこの「既存踏襲」というパワーワードは「失敗の道を歩む」ことを意味する。またDXにおいてもそうである。

よくあるパターンとして、システムオーナ(経営者側)は新規システムを導入することによって何らかのビジネスを改革し、売上、利益を上げ会社の発展に貢献したいのである。

しかし、既存のシステムは過去に連連と重ねた継ぎ接ぎだらけの修正が贅肉のように残っている。それを削ぎ落として新しいビジネスを構築したいのだが、それには今の現場の仕事のやり方、業務フローもそれに伴って変える必要が出てくる。

そこで、反対勢力が出てくる。

現場にしてればシステム更改なんて経営者とITベンダの勝手な都合でそんなものは望んでいない。現場は今の仕事のやり方、業務フローを一切変えたくない。そんな余計なことはしたくないのである。

「既存踏襲」それに固執する

現場に「それじゃ、仕事が回らない。顧客に迷惑がかかる。」と言われればシステムオーナ(経営者)も「うぅぅ・・・む、そんなに言うなら仕方ないな」となる。

たいがい、「既存踏襲」と言う言葉がでるとプロジェクトは失敗の道を歩むことになる。

考えてもみてほしい、折角の億単位の費用をかけて開発した、昔のシステムと何も変わらないシステムが、ビジネスに何か価値を生むだろうか?
億単位の開発費用はドブに捨てたのと同じである。

以上がユーザ(顧客側)視点からの「既存踏襲」の弊害であるが、一方開発者側の視点だと・・・

今回のような時代遅れのアーキテクチャVB.Net、Oracle、ODBCとクラウドWebシステムじゃ、全くアーキテクチャが異なる。右から左へと移行はできない。

VB.NetはWindowsネィティブアプリケーションなのでWindowsネィティブだからこそできていることも多い。それがWebシステムになったらできない、他の方式を検討しなければいけないことも多い。

継ぎ接ぎだらけの謎の処理、謎仕様も新システムに必要なのか?不要なのか?今、生きてるのか?死んでるのか?どうやって判断するんだ?等など・・・

作る側(開発者)にとってWebシステムに最適化して書き直すことは考えることが多すぎて、面倒くさいのである。

そこでも「既存踏襲」である

上のように「ユーザ側(システムオーナ)も既存踏襲って言っているし、現場のユーザが既存と動作が違うとクレームを言ってくるかもしれないし・・・」

というなんだかよくわからない弱気な理由をつけて、昔の継ぎ接ぎだらけで無駄な機能、謎の処理が入ったそのままを踏襲しようとするのである。

それは「既存踏襲」を免罪符にした思考停止に過ぎない。

いや、既存踏襲は楽だろう。既存と同じかどうかで白黒はっきりするし、無駄だろうが、謎だろうが、何も考えること無く猿真似のように右から左に持っていけば、それなりに目標は達成できる。

それは猿だ。猿と同じだ。考えることが面倒くさいから思考停止しているに過ぎない。

考えても見てほしい、ま、仮に、仮にだよ、既存のVB.Netのシステムを、一語一句漏らさず既存踏襲したシステムをユーザ側に持っていったらユーザ側は

「これだよ、これが欲しかったんだよ」

と喜ぶだろうか?そんなことはないだろう。

「ここは、もっとこうしてほしかったんだよなー、あ、これは要らないし・・・」とアレコレ、アレコレ・・・絶対言うだろう。

おわかりいただけただろうか?

「既存踏襲」というパワーワードはビスネス側でも、開発側でも失敗の道を歩むきっかけとなるのである。失敗の始まり。終わりの始まりなのである。

この世から「既存踏襲」と言う言葉を抹殺したい。

じぶんが経営者であれば「既存踏襲」というと言葉を発した奴から罰金を取るなー(笑)

いいなと思ったら応援しよう!

ワニ | ITフリーランス | おっさん | フォローよろしくお願いします
100ワニをパクって退職エントリでバズろうとしたけど、全然バズらなかったワニ。 副業のオファーあればよろしくお願いします。 Twitterのフォローもよろしくおねがいします。@180wani