クラウド化と行き過ぎた専門化で不要になるエンジニア

d.hatena.ne.jp

クラウドについては顧客がそれがいいとご所望になるならどうぞどうぞの立場でして、オンプレとクラウドのメリットデメリットを押さえた上で、顧客の課題解決の手段として判断されたのであればそれでいいかと。

SIerやサービス提供をするIT企業は、提供するサービスがクラウド上なのであれば自社の業務システムをクラウドに載せるのはショーケースですから、やらない方が不思議なくらいの感覚です。

HW賞味期限切れ更改

SWより先に賞味期限切れになるのがHWで、ベンダサーポートがEOSになるので渋々HWのみ更改したり、HWのドライバに引きずられてOSを更新、さらに玉突きを起こしてMWの入れ替えまで行ったりすると結局SWの動作検証まですることになり、かなりの金額になったりするのは明白なのでそのままでは役員説明できずに機能追加とか運用対処していた課題の自動化などで単なるHWの賞味期限切れにことを発したシステム更改の投資対効果を何らか言わなければ稟議が進まなかったりするのですよねぇ。

慣習の機械化でシステムが面倒になる

パッケージやASP（はカスタマイズできないけれど）でノンカスタマイズで使う組織が少ないことがHW賞味期限切れによる更新を面倒臭くしている一面があるのですが、というかそれが大部分なのですけれど、カスタマイズしてしまうと引き継がなければならない業務が存在するということになるのですよね。

業務を可視化して業務の主管部署がそれに沿って業務を行なっていればいいのですが、多くはシステム化の機能開発でシステム化に必要な部分だけが文書化され、その上、それはシステムの文書の中に埋め込まれてしまうのです。

業務に必要な手続きが文書化されていれば良いですが、多くは運用対処が多いし、あっても内規扱いが多いですから。内規扱いだとまとめた担当者の属人的対応がひどいので部分最適化されている業務をIT化して行くと個人の嗜好が反映されすぎて面倒でしかないのです。

でも、そうしたことを拾うことが更改の目玉になっていると仕方がないというか。

カスタマイズを捨てるシステム更改の可能性

本来であれば、システム更新を行うなら、過去にシステム化されている特にアドオンの機能については今後業務運用を担う担当者がストレートコンバージョンをするのではなく、業務棚卸をすることで業務自体を軽くしてパッケージに業務を合わせるイベントとして利用するのが良いのです。

なぜそれをやっているかわからないけれど、システム化されているので引き継いでいる的な業務はその目的がわからないのでそのままにしているケースが多すぎなんですよ。

こうした考え自体はシステム延命のためのシステム更改とは違うのでそこから理解をしてもらうのは巻き込まれる人が多すぎで大変ですけれど。

じゃあ、パッケージを捨ててスクラッチでとなるとそれはそれで業務を可視化してやっている業務をそのままシステム化するのではなく、どの部分をだったり、意味のある（手続きすることで価値を生んだり、遵法の意味合いで）プロセス化へしなければならないのでやることが多すぎ問題があるのですよねぇ。その上、業務自体が分掌されすぎていると業務全体を知っている人が少ないという。