システムを作ることが課題解決になると思ってませんか？
解決方法に「新しいシステムを作る」って、なんか違くないですか？
残念ながら、システムを作るときこと自体が目的になってしまっているケースって多いような気がします。
「手段が目的化する」ってやつですね。
「そもそも何がしたかったんだっけ？」ってなったりします
システム刷新で情シスとユーザの仲は険悪になりがち
ここもまあ難しいと思っておりましてですね。よくあるのは、トップダウンでシステム刷新が降ってきて、ユーザが全然納得していなくてシステムに丸投げしようとするケースですね。
「予算〇〇だけど、どこまでできる？」
って、残念ながらよくある。
予算も聞きたいけど、その前に「何をしたいか」が知りたいんですけどね。
なので、中核となる人としっかりコミュニケーションをとることが大切だと思います。
ハードウェアのリニューアルがDXの話に進展していくプロセス
最近よくあるシステム刷新のプロセスは、こんな感じだと思います。
めっちゃよくある。
・ハードウェア（大型機やオンプレ）が寿命を迎える
・寿命を迎えるタイミングとあわせてシステム移行しようとする
・今まで積み上げてきた資産が大量にあり、移行費用が膨大になる
・業務から見直さないと移行できないという結論になる
これは別に大型機だけの話だけではなくて、オンプレサーバなんかでもあったりするし、これがボトルネックになってネットワーク環境刷新できないとかもあるし、まあいろいろとあるのです。
しかしまあ、業務全体を見直す必要などは実はなくて、業務を適切にカテゴライズして「これは移行する」「これはSaaSに移行する」とかばっさりやっちゃえばよいのだと思うんですけどね。
「夜間バッチ」はもはや時代遅れ？
これも最近思っています。まず、大型機から脱却するのなら、スペックに任せた大量処理ではなく、トランザクション処理前提に業務を考える必要があります。
となると、夜間の一斉チェックとか、大量の集計処理から見直す必要があるわけで。
このあたりから考えられないと、先には進めませんよ。
そういったアーキテクチャ起点での話は、ユーザは基本不得手なので、システムも適切にコミットしていく必要があります。
まあしかし、DXを推進しようとするときの情シスの役割は重いです。
システム開発への適切なコミットも求められています。
「思い通りのシステム」を作らせるのって、難度高いですからね。。。。
ちなみに感覚的にいつものベンダーに委託していると、DX案件は難しいです。発注・導入のプロセスをきちんと把握しておくことが必要になります。
いやー難しいですね。。
やっぱり情シス自体が変革しないといけないのだなあ、と思い始めています。