社内SEがシャドーITを嫌がる理由
社内SEとして働いている人にとって、頭を悩ませる一つの大きな問題が
シャドーITといわれるものです。
企業の情報システム部門が管理していないITの事です。
主に小粒なものが多く、例えば経費精算システムなどの規模以上になると情報システム部門が知らないうちに導入されることなどはないと思うのでこれは該当しません。
一方、現場でエクセルに詳しい人が作ったエクセルマクロなどは、まさにシャドーITの代表となります。
モノによってはウナギ屋さんのタレのように、歴代の担当者が手を加え続けて、複雑怪奇なものになっていたりします。
さて、このシャドーITが情報システム部門の何を悩ませるか？
というと
・メンテナンスできない
という一点に尽きます。
情報システム部門が作ったシステムにおいては必ず以下のものを作ります。
・要件定義書
・仕様書
これは
このプログラムは何を目的としたもので、どういう風に作られています
という説明書のようなものです。
プログラムというのは、専門家であるエンジニアでも
その動きだけを見て、中身がどうなっているかを把握するのは困難です。
それは新しい家電を渡されて、取説もなしに使いこなすように言われるのと同じです。
なんとなくこれでいいのかな？ぐらいまではわかるかもしれませんが
それが本当に正しい使い方なのかはわからない
という状況になります。
その為、例え自分が作って、自分がメンテナンスしていくものだとしても、
必ずこういった書類を作ります。
自分がメンテナンスする際の備忘としても使いますし
別の人がメンテナンスする際には、これがそのプログラムの作りを知る為の
手掛かりとなります。
しかし、シャドーITは言ってしまえば素人が作っていますので
こういった書類が作られることはありません。
よしんば作られたとしても、メンテナンスされることはほぼ0%です。
シャドーITの困ったところは
なんらかの理由で動作しなくなったときに
この状態で突然、情報システム部門に持ち込まれるという所です。
こういう場合、ユーザー側からすると
と思って、持ち込んでくるわけですが
情報システム部門からすると
となるわけです。
この時に、情報システム部門からの予想される回答は
1.門前払い
2.対応はするけど、ユーザーが思ってるよりも大幅に時間がかかる
の2つになります。
そして、代替手段がないというような深刻な問題がなければ
基本的には1.の対応をされることが多いです。
ユーザー側からすれば、
それが仕事なんだからやってくれよ
という気持ちもわかるのですが、このシャドーITの対応というのは
いうなれば、
ダイキンの工場内の設備課に、現場でこっそり買ってきた日立の機械の修理を持ち込んでくるようなものです。
管理もしていないし、ノウハウもないものに対しての修理依頼が持ち込まれてくるのですから、システム部門としても積極的には動いてくれませんし、
そもそも情報システム部門もそれだけを仕事にしているわけではないので、こういう飛び込みかつ、得体のしれない案件はどうしても優先順位は下がってしまいます。
そして、2.の対応をしてくれたとしても
・このツールって何？だれが何のために使っているの？
の解析から始まり
・じゃあ、何故不具合が起きている？
の原因追及をして
・最終的にどうなったらよいの？
の対応方針まで決めてから
ようやく修正が始まるので、かなりの時間がかかってしまいます。
なので、シャドーITというものは
ユーザーからしても、トラブル時に迅速な対応ができなくて、仕事に大きな影響を及ぼしますし、
情報システム部門からしても、「業務に深刻な影響が出るから今すぐなんとかしてほしい」とか言われると、優先せざるを得なくなり、他の仕事のスケジュールにダメージを与えてしまうので、どちらにとっても非常に厄介なものになります。
百害あって一利なし
というのが、シャドーITであり、
シャドーITを生むような環境は悪
というのが、これまでITの世界の通説でした。
が、
今、時代はこれとは矛盾した流れが生まれようとしています。
それはまた次回。
コメント
コメントを投稿