2019年につぶやいた「情シス必要論」のツイートに再び反応が多くて驚きました。
よくよく見たら、これ2019年につぶやいてたんだよね。
— 松田軽太 （ソリュエイ亭門下生）5550 (@matudakta) 2023年6月29日
この頃と比べるとノーコード・ローコード開発での内製化が脚光を浴びてるから、状況が変わった会社と変わらないままの会社で、むしろ格差が開いたのだろうと思う。 https://t.co/vionxr8kl9
こんにちは！ 松田軽太です。
「情シス必要論」とは2018年9月に山下光洋氏（@yamamnx）が公開した「徹底討論！情シス必要・不要論 ～これまでの情シスと明日からの情シス～」です。
2019年に僕もこれを読んで「確かになぁ」と読みました。
それから4年が過ぎ、その間にコロナ禍を経験したり、DXブームになったり、生成AIが登場したりと世の中は大きく変わったと感じます。
それらを踏まえて、いま改めて「情シス必要論」を見てみるのも良いかと思った次第です。
「情シス不要論」とは何か
ということで、そもそも情シス不要論とは何なのか？ですが、スライドを引用させていただくとこう書かれています。
・2013年頃からささやかれている。（もっと前かも）
・システム導入は事業部門が直接やればいい。
・システム開発を内製するなら事業部門がやればいい。
・情報システム部門を担当にするメリットはない。
などなど、システムの導入／開発には情報システム部は不要で、事業部門が直接やればいい、その方が早く確実である。
という論
昨今のDXブームの中でも言われている「ノーコード・ローコードを活用した市民開発者によるシステム内製化」に通じる話ですよね。
KintoneやMicrosoftのPower Appsの登場で、業務部門の中でITに長けている人が、自分の仕事をロジカルに整理できれば実現できる環境になっていますね。
この動きがもっと活発になると、事業部門の業務システム構築という場面では情シスの出る幕は少なくなってくるかもしれません。
そして更に耳が痛いのは10枚目からのスライドです。
その部分を引用させていただきます。
■自社ビジネスに貢献できないから
・事業を知ろうとしない
・現場を知ろうとしない
■事業部門のIT活用に対して
・「忙しくて対応出来ない」という
・セキュリティ、ガバナンスを盾に断る
・管理することが成果だと考えている。
■運用だけで手いっぱいだから
運用にとらわれその運用を改善する事なく、ブラックボックス（秘伝のタレ）化させる。そしてされにその運用から手が離せなくなる。
■経営層からすると何をしているか見えないから「どうせ理解されない」、と説明しない。
会社の方向性と合っているかズレていないか確認をしない。場合によっては、やってる事自体が会社にとって意味ああるのかどうかも
経営層から見ると懐疑的になってくる。
■とってつけたROIを揚げるから根拠の薄い工数改善を時給換算などして数字を報告している。
ただしそれによる会継受の数値は何も変化していない。
■丸投げしかしないからSIerへの丸投げしかしない。
取次だけであれば担当部門としての必要性はない。
提案精査もなければ要件取りまとめもしない。
■逆に抵抗勢力になっているからクラウドやOSSを事業部門が使いたいと言っても、自分たちが扱う事ができずに理由をつけて抵抗する。
もしくは自分たちの運用業務がなくなる事を恐れる。
■ITを知らないから昔は知っていたかもしれないが、外に出なくなり、勉強もしなくなり、自社業務しなしなくなり、
その世界に慣れてしまい危機感が無くなる（ゆでガエル現象）世の中の変化にもついていけず、事業部門よりもITについての知識が足りないことも…。
■開発が出来ないから開発をやらなくていいと本気で思っている。
思いつきの丸投げを「企画」や「設計」と呼んでいる。
■ベンダーに対してBtoBでないからベンダーコントロールとか言ってる。提案は無料で当たり前だと思っている。
発注した後は食べ放題でも頼んだかのように見積もり外の依頼を要求する。
■すべてが他人事当事者意識がない。守っている運用でさえｍのその手順は引き継いだもので、何かあっても自分には責任はないと言い張る。報告をし、放任を受ける事を責任回避と思っている。高いコストをかけて社外から保証を買う事でしかリスクヘッジが出来ないと思っている。
■一体何が出来るのか分からないから人事部門の問題ともとれますが、社内全般にITスキルが不足しているため、情報システム部員のスキルを測ることが誰もできない。
新しいシステムやサービスの構築／開発もないので、具体的に何が出来るのかが誰も分からない。
う～む…。
情シスの仕事を経験されている人であれば「あれ？これってウチの部署のことでは？」と思い当たる節がいくつかあるのではないでしょうか？
確かに耳の痛いことばかり書かれているので、2019年にこれを読んだ時も精神的に吐血したような気がします。
しかし視点をひっくり返せば「ここを改善すれば必要とされる情シスになれる」とも言えますよね。
特に今の時代はクラウドで見たことも聞いたこともない便利なサービスがいつ間にかに生まれています。
以前であればベンダーから提供される情報に頼らざるを得ませんでしたが、今では、情報を手に入れようと思えばいくらでも手に入ります。
でも、それは「手に入れようと思えば」です。何もしなければ何も知らないままなのです。
「木村岳史の極言暴論！」を見てみたら、こんなことも書かれてた
やはり日本企業のIT部門はオワコン、DXで「最終処分」の日は近い
こちらの記事でインパクトがあるなぁ～と感じたのは、この部分。
では、なぜ既存のIT部門の立て直しは不可能で、DXの推進役になれないのか。
単なる組織の劣化や素人化だけが問題なのではない。
むしろ組織の劣化だけならば、中途採用の技術者を増やすなどして再建できるだろう。根っこの問題は、IT部門の組織文化が「腐って」しまっていることだ。
何せ「守りのIT」ならぬ「守りの姿勢」一辺倒で、自ら新しいことを仕掛けることはない。しかも、利用部門の要望に対しても「無理！」と言うばかりで、利用部門からひんしゅくを買う存在となっている。
にもかかわらず、「毎日ミスやトラブルなく仕事をしても評価されないのに、何かあると怒られて評価を下げられる」などと不平の声が漏れる。
確かに、システム障害の発生はほぼ避けられないから、それをもって怒られたり評価を下げられたりしたのであれば、同情を禁じ得ない。
だけど、毎日ミスやトラブルなく仕事をしているだけでは、どんな仕事であっても評価されないのは当たり前だぞ。被害者意識に凝り固まっていると言うしかない。
もちろんIT部門の組織文化が腐ってしまったのも、長年のリストラや経営者のITに対する無関心に起因する。
そういえば、IT部員の人員が少なくなり過ぎて業務が回らなくなったので増員を求めたら、いわゆる「働かないおじさん」が異動してきて若手部員の心が折れてしまった、なんて話も聞いたことがある。
その若手部員は、全く戦力にならない人が「増員」されたことよりも、IT部門の社内評価がその程度であることのほうに衝撃を受けたと聞く。
だが理由は何であれ、組織文化が腐ってしまったIT部門は本当に使い物にならない。
そして組織文化が腐ってしまっているのなら、立て直すのは恐ろしく困難だ。それこそ、IT部員を総入れ替えするぐらいのことをやらないといけない。
苦労して中途採用した技術者を下手にIT部門に配属したら、腐った組織文化に毒されてしまう可能性が大だ。
あるいは「ここじゃ自分の能力を生かせないし、キャリアも築けない」と早々に見切りをつけて、再び転職してしまうかもしれない。
これをこのまま鵜呑みにするとしたら、今や情シスは「役に立たない人材のゴミ箱」みたいな扱いの部署になってしまっているのですね。
もちろん、ここで書かれていることが全ての会社の情シスに当てはまるワケではないでしょう。
しかしザンネンながら世間一般的には、これくらいポンコツな状態だと思われているのかもしれませんね。
なぜ「役にたたない情シス」になってしまうのか？
なんでここまで情シス部門がボロクソに悪口言われてしまうのかと言えば、自分たちで業務システムを開発する環境がなくなってしまったことが大きな原因なのでしょう。
実際に僕の働いている会社でも、その昔、メインフレームの白黒画面が活躍して頃は、COBOLなどのプログラム言語で、自分たちの業務システムは自分たちで開発していました。
そしてそれらの自社開発システムを作ってきた世代の人たちが定年退職を迎えるにあたり、「これからの時代はパッケージソフトを活用すべき」ということになり、せっせと手作りされてきた業務システムはパッケージソフトに置き換わりました。
しかし、それと同時に「自社で必要となる業務システムを自社で開発する」という文化も一緒に消えていったのです。
開発する環境自体が無くなったからです。
そして数年の時を経て出来上がったのは基幹システムのお守りをするだけの「役にたたない情シス」という部署なのです。
どうすれば「役にたたない情シス」から脱却できるのか？
自社での開発経験が消失したことで「業務で必要な道具を作れない」というのが大きな弱点になってしまったのでしょう。
そしてDXブームの到来によって「情シスに頼んでも埒があかないから自分たちで作ってしまえ！」という市民開発者が増えています。
KintoneやMicrosoftのPower Appsなどのノーコード・ローコード開発ツールを活用すれば、自部署内で使うような小さなシステムであれば少し学習すれば作れてしまいます。
謎の呪文のようなコードを書かなくても済むのですから。
自分で必要とするモノを自分で作るのであれば、他の人にたどたどしい言葉で要件を伝えて作ってもらうよりも、そりゃ、使い勝手が良いシステムになりますよね。
ノーコード・ローコード開発で重要となるのは「どう作るのか」よりも、まずは「何を作るのか」という部分だからです。
ということは、情シス部門でもKintoneなどのローコード・ノーコードを触ってみればいいのです。
ノーコード・ローコード開発はほとんどがクラウドでのサブスクです。サーバーを立ててインストールして…という手間は必要ないので、だから情シスに頼らずに事業部門が主体で導入できるのです。
ということは「まずは試してみる」が手軽にできるということなので、その手軽さを情シスも活用してにみればいいのだと思います。
また昨今ではChatGPTを代表する生成AIがあらゆる場面で話題になっています。
システム開発の現場でも生成AIを活用することで、更にシステム内製化の敷居が下がることでしょう。
昨今はコードを一切、書いたことがない人がChatGPTと相談しながらExcelのVBAで自分のツールを作るという事例が増えています。
ChatGPTへの相談のしかたの事例はこちらなど。
この数年で業務システムの開発環境の敷居はだいぶ下がったと言えます。
もし全く開発経験がなかったとしても恐れることはないのです。
「必要とされる情シス」とは？
結局のところ「必要とされる情シス」というの、誰かの役に立てる情シスなのでしょう。
情シスはついつい「守り」の部分を重視しすぎてしまうことが多いと思います。
もちろんそれも重要です。
しかし、そこだけに捕らわれすぎると「情シスに頼んでも文句しか言われない」と妙な悪評だけが広まります。
なのでもしセキュリティ上で問題がありそうなどの事情があるなら、キチンとそれを説明して、そして代案も一緒に考えてあげるのです。
親身になっている姿を見れば、相手も情シスの悪口を言ったりしないでしょうから。
