松田軽太の「一人情シスのすゝめ」#17：嫌われる情シスと感謝される情シスの違いとは
松田軽太の「一人情シスのすゝめ」、タイトルだけ見ると一人情シスを推奨しているように思われるかも知れませんが、思いはまったくの”逆”。様々な事情によりやむなく”一人情シスや専任情シス不在”という状況になってしまっても頑張っていらっしゃる皆様のお役に立つような記事をお届けしたいと思っております。
今回は、『嫌われる情シスと感謝される情シスの違い』についてのお話です。
同じ仕事をするならやっぱり感謝されたい
ひとくちに情シスといっても、会社によって情シスのスタンスは大きく違います。
こんなに守備範囲の広い業務スキルを求められる職種はないのではないかと思うくらいです。
日々の業務をそつなくこなしていると「毎日、何をしているんだ？」と言われ、何かしらのトラブルが発生すると「一体、何をしているんだ！」と言われてきた情シス。だからこそ、せっかくなら皆から感謝されるように仕事をするべきなのです。
そんな「感謝される情シスって何だろう？」と思わせたきっかけは以下の記事からでした。
この記事ではローコード開発を導入して、業務担当者が必要とする業務システムを内製化しているというものでした。
業務システムを内製化しているか、すべてベンダーに丸投げしているかで、その立ち位置は大きく異なります。
嫌われる情シスとは？
嫌われる情シスとは一体どんなことなのでしょうか？ まずは嫌われる情シスのパターンを考えてみることにしましょう。
例えば、業務システムのすべてをパッケージ購入や外注してスクラッチ開発していると、業務システムの中身がブラックボックス化している場合が往々にしてあり、このような場合は軽微な変更であってもベンダーにお願いすることになります。
しかしながら、利用する側にとっては「軽微な修正」に見えたとしても、その修正が本当に他の部分に影響しないかどうかを調査し、テストもしなければならないので、やはり人手が掛かります。
そして人が動くということはそれなりに費用が必要になります。
また、よくある話かも知れませんが、業績が悪くなると急にコストダウン要求の矢面に立たされることが多い情シスとしては、「軽微な修正」なのであれば、あまり費用をかけたくないというのが心情ではないでしょうか？
大規模改修となった場合に一気に改修したいと思うこともあるでしょう。
パッケージソフトやERPを使っていると、ちょっとした改造でも数百万円は軽くかかったりするので、その都度、稟議を通す必要もあり、そのためには「軽微な修正」の必要性を説明しなければなりません。
企業規模が大きくなればなるほどありそうですが、稟議書を出すと必ず一人や二人はネチネチと重箱の隅をつつく人も出てきます。（まるでそれが生き甲斐であるかのように…。）
そうなると嫌な汗をかきながら、「軽微な修正」について発生理由や修正しない場合の影響などを説明しなくてはなりません。影響が大きい場合はスムーズに進むのでしょうが、そうでない場合は、とてもストレスのかかる仕事です･･･。
なので、情シスは業務部門から出される改善（修正）要求を門前払いしたがる傾向にあります。
そして、門前払いが何度か続くと、業務部門から改善（修正）要求が出てこなくなります。
それも当然です、「情シスに言ったところで、まともに取り合ってくれない」と分かっているからです。
しかし、業務部門としては何とかして業務効率をあげたいので、VBAやACCESS、kintoneなどを使って自力でなんとかしようとしてしまいます。
かくして情シスのあずかり知らないところで、現場主導のシャドーITが増えていくのです。
こういうパターンに陥ってしまっては、現場（業務部門）と情シスの間に信頼関係なんて生まれるハズがありませんね。
感謝される情シスとは？
では、逆に感謝される情シスとはなんでしょうか？ それはもちろん、現場（業務部門）の相談に乗ってくれる情シスです。
でも、どうすれば情シスは現場（業務部門）の相談にのってあげることができるのでしょうか？
ここで一度、現場（業務部門）の実情から考えていくことにしましょう。
現場（業務部門）が業務効率をあげるには、なにがしかの道具（ITツール）が必要になります。
社内に開発ツールが揃っていれば良いのですが、業務システムを内製化をする文化がなければ、そもそも開発のやり方が分からないということもあるでしょう。
イマドキであれば、システム開発の敷居が低いローコード開発ツールもありますが、安くても数百万円コースです。
それに業務システムの開発というのは、多分に経験がものを言う部分も多いものです。
いくら敷居が低いとはいっても、使えるか使えないか分からない開発ツールを購入するための稟議書を情シス部長が承認するとは到底考えられません。
なので、内製化に慣れていないのであれば、極力、費用の掛からないツールを使い、まずは小さな内製化をやってみるところから始めると良いでしょう。
とくに業務部門での困り事は「煩雑な沢山の集計作業を効率よくして、余計な仕事から人手を外したい」ということがほとんどです。そのような小さなカイゼンであれば、Excel-VBAやRPAで解決できます。
そうして小さなカイゼンの積み重ねが業務部門と情シスの信頼関係を築いてくれるのです。
情シスにしても、そうした小さな業務システムを作る経験を積み重ねることで、内製化する勘所が培われます。
するとそのうちに沢山の人数で使う業務システムを作りたくなるし、そういう要望も増えていくことでしょう。
そうなったら今度はkintoneやFileMakerなどを使い、グループで使うシステムを作ってみる（考えて見る）と良いでしょう。
釈迦に説法かも知れませんが、kintoneであればサーバーを用意する必要がないので手軽に始められます。
また、FileMakerを使う場合はFileMakerサーバーでの運用になります。FileMakerサーバーを使えば数百人で利用する業務システムを開発することもできます。
やる気になれば信州ハムさんのように生産管理のような基幹システムを作ることもできてしまいます。
しかしながら、費用が掛かるので、これらの有償ツールを利用するのは内製化する自信がついてからでも良いでしょう。
そして、もっと大規模な業務システムを作るのであれば、リポジトリを管理できるツールにした方が良いです。
業務システムは作って終わりではなく、稼働してから運用保守という長い旅が始まるのです。
リポジトリを管理できるツールを使うと運用保守で効果がでます。
それなりに大規模なシステムにも対応可能なローコード開発ツールの中で、個人的にも使ってみたいと思うものは以下に挙げる5つになります。
この中で価格的に一番リーズナブルなツールと言えば、TALON*ではないでしょうか。
*：個人的見解です
そうそう、TALONの要求（仕様）変更に対する柔軟性を説明してくれる動画がありましたので紹介しておきます。
TALONを開発されている古関氏ご本人が分かりやすく解説してくれていますので、参考にしては如何でしょうか？
まぁ、ツールに関してはやりたいことに対する善し悪しもありますが、使い勝手等の”好み”もあります。
無料期間を有効活用し、一度、各ツールをお試ししてみると良いでしょう。
ローコード開発ツールといっても随分と違うことに気がつきます。
ちなみにOutsystemsは個人利用だと無料で使えるようです。興味がある方はお試しくださいませ。
モード2の開発を手厚くする
生産管理システムや在庫管理システムや販売管理システムといった基幹システムはSoRとかモード1とか言われますが、要するに記録システムです。（ちなみに「SoR」とはSystem of Recordsの略です）
要するに日々、発生する沢山のデータを正確に記録することが役割なのです。
それに対してSoEやモード2というのは、差別化システムと言えます。
たとえばその会社ごとの独自のノウハウが蓄積されているのは、業務部門のハズです。実はそれって会社の強みでもあるのです。（ちなみに「SoE」とはSystem of Engagementの略です）
なので、このような差別化システムを構築する場合はローコード開発ツールは役立ちます。
何故なら会社独自の業務の場合、当てはまるパッケージソフトなんか存在しないからです。存在しないなら自分たちで作るしかありません。
そして世の中に存在しない業務システムを作るということは手探りになります。
であれば尚の事、作るのも直すのも得意なローコード開発ツールが威力を発揮するのです。
モード１とかモード２に興味がある方はこちらをどうぞ。
会社の事業を支援することができる情シスになろう
結局のところ「感謝される情シス」というのは、会社の事業を支援することができる情シスなのではないでしょうか。
評判の悪い情シスは、何か相談しても「○○がないからできない」というのが口癖になっている情シスなのでしょう。
どうせ情シスで働くなら、やっぱり感謝される情シスでありたいものです。
※本記事は松田軽太様許諾の元、「松田軽太のブロぐる」の記事をベースに再編集しております。
松田軽太（まつだ・けいた）
とある企業に勤務する現役情シス。会社の中では「何をしているのかナゾな職場」でもある情シス業務についてのTipsや基礎知識などを紹介する。
ブログ『松田軽太のブロぐる』を運営。
関連記事
