古い資料などを整理していたら昔の日経コンピューター誌が出てきました。
特集記事は「崖っぷちのIT部門 戦略組織への改革、ラストチャンス」というセンセーショナルなタイトルです。
こんにちは! 松田軽太です。
5年前から「もう情シスなんか要らない」と言われている
この日経コンピューター誌は2014年1月23日号です。
もう5年も前に書かれた記事なのですが、今でも「もう情シスなんか要らない」というのはネット記事などで見かけますよね。
しかし情シス部門からしてみれば、この5年の間にAIだのIoTだのDXだのRPAだのと、矢継ぎ早にいろんな話が出てくるので、ぶっちゃけ情シス部門のスタッフだって追い切れないのが現実でしょう。
情シス部門の仕事は概ねどこの会社でもこんな感じでしょう。
-
ERPパッケージなど基幹システムを安定して稼働させるための運用管理
- 情報漏洩やウィルスなどのセキュリティ対策
- 通信回線のお守り
- サーバーやパソコンやプリンターなどの機器の入れ替え
ところが、ここ最近はAI、IoT、DX、RPAといった新しいサービスが沢山できてましたが、そんなん言われても「知らんがな!」って感じですよね。
しかし情シス部門に対する世間の認識はというと「何かやりたいというとすぐに『○○だから無理です』と出来ない理由ばかり並べ立てて、新しいことをやる気が無い」とか「そもそも何をしている部署なのか知らない」とか「あー、パソコンを入れ替える部署だよね」といった印象だろうと思います。
実際、日経コンピューターの記事にも情シスのイメージは抵抗勢力と書かれています。
もともと、情シス部門の役割は業務をつつがなく運用できるように環境を整えるための裏方な存在だったので、基本的に「守りの姿勢」が染みついているんですよね。
だから他の部門からすると「情シスってなんか地味でやる気が無い人たちの集団」みたいに見えるのです。
会社中をシャドーITが浸食する
クラウドサービスがたくさん生まれてますよね。
様々なサービスが安価にいとも簡単に利用できるようになりました。
そうなると会社のいろんな部門で自分たちが使いたいサービスを手軽に利用できるので、わざわざ情シス部門に相談しなくなります。
それにどうせ情シス部門に相談したところで「情報漏洩の危険性が・・・」とか「そのサービスが無くなったら・・・」とか「回線に負荷が掛かるので・・・」とかいろんな理由をつけて「使うな!」と言ってくるに決まっていると考えるでしょう。
ユーザー部門からすれば、最近のクラウドサービスは費用もサブスクで月数千円〜数万円なので気軽に利用できるし、思ったように使えなければ解約すれば良いだけなので楽ちんです。
「ちょっと試してダメならやめる」ということが可能なのはクラウドとサブスクの利点だと言えます。
こうして情シスが把握していない謎のサービスが会社の中に蔓延していくのです。
そういった情シス部門が把握していないシステムをシャドーITと呼びます。
「これからは攻めの情シスに転換だ!」と言われてもね・・・
この記事でも「これからは守りに徹するのではなく、攻めの情シスに転換すべき!」との結論になっています。
「既存のシステムのお守りをするだけではなく、どんどん経営に直結する攻めのITを提案する存在にならなければいけない」というのは、そりゃごもっともです。
しかしそれはこの人手不足の時代でも、人を集められるような会社でなければ難しいでしょう。
この記事でも「攻めのIT」として紹介されている企業はJAL、パルコ、バンダイナムコ、日本郵船、セイコーエプソンといった誰もが知っているような有名な大企業です。
しかし世の中の99.7%は中小企業です。
そして中小企業といえば「ひとり情シス」とか「ゼロ情シス」とか「兼任情シス」が大半を占めています。
ただでさえ既存の仕組みのお守りで手がいっぱいなのに、それに加えてなんだかよく分からないクラウドサービスの面倒まで見るのは現実的に不可能ですよね。
「攻めのIT部門」に転換させたいなら、人手を増やして欲しいところですが「募集したけど集まらない」とか「人手増やさずに業務を効率化するのがITのチカラだろう?」とかワケの分からないことを言われるのがオチです。
今の情シスにはシステム設計をする能力がない
多くの会社ではERPパッケージの導入が進んでいるのではないでしょうか?
情シス部門はこれらのERPパッケージの安定的な運用を行うことが仕事ですが、ERPパッケージを運用することは出来ても、新しいシステムを導入する能力が欠落している可能性があります。
ERPパッケージを導入する前では多くの会社ではオフコンとかメインフレームとかを導入しCOBOL言語だのRPG言語だので、システム開発を内製化していました。
その時代の情シスの人たちは、いわば職人気質の人が多く、自分でシステム開発の要件定義を行い、マスタやトランザクションやサマリーといったデータモデルを設計し、画面や帳票などのUIを設計しプログラムも自分コーディングして動作テストを行い、完成したら利用部門に使ってもらっていました。
そう、昔の職人みたいな情シス部門はすべての作業を自分で出来たんですね。
しかしERPパッケージを導入してからというもの、システム開発の要件定義から操作画面や帳票などのUI設計、コーディング、動作テストをすべてSIer任せになっています。
では情シスは何をしているのかというと、SIerと利用部門の間の通訳であったり、見積りの値引き交渉であったり、導入後の操作説明といったことしかしている会社が多いのではないでしょうか?
ERPパッケージを導入して10年も経っているような会社の情シス部門は自分でシステム設計する能力が無くなっている可能性が高いのです。
そんな状態の情シス部門に「これからは攻めのITだ!」なんて言っても無理ゲーなんです。
超高速開発ツールでアジャイル開発に取り組むべき理由
とはいえ「だからシステム設計は今さらできません」では、本当に不要な部門になってしまいます。
ではどうすれば良いのでしょうか?
「そうは言ってもねぇ・・・。コーディングなんか出来る人材、いないしなぁ・・・」と途方に暮れてしまうかもしませんね。
ところがそれを解決できるのが、超高速開発ツールと呼ばれる開発ソフトです。
ノーコード開発ツールとかローコード開発ツールもしくはRADツールとも呼ばれている場合もありますね。
WikiからRADツールの説明を引用してみます。
Rapid Application Development(ラピッド・アプリケーション・デベロップメント、RAD)とは、ソフトウェアの開発を容易にする仕組みの1つである。ユーザーを含む少人数のチームで開発を進め、プロトタイプを作ってそれを評価するというサイクルを繰り返すことで、完成品に近づけていく。
基幹システムのような何をやりたいかが明確になっている大規模なシステムはウォーターフォール型開発を行うのが一般的ですが、昨今のように「なんとなくこういうことがやりたい」というように使いながら修正していくようなシステムはアジャイル開発が向いています。
そしてアジャイル開発と相性が良いのが超高速開発ツールなのです。
従来の開発にくらべてコードを書かずにシステム開発ができるので、要件定義などの設計に注力することができまたツールを使えば開発も簡単なので、自分で思い通りのシステムを作ることができるのです。
超高速開発ツールも種類が沢山ある
実は最近は超高速開発ツールにも種類が沢山あります。
有名なところではキャノンITソリューションズの「Web Performer」ですかね。
超高速開発についての解説はWeb Performerのサイトにある「【超高速開発とWeb Performer】第1回:超高速開発とは」に詳しく書いてあるのでまずはこのページを見てみましょう。
Web Performerの他にもあるので製品名だけ紹介しておきます。
・楽々フレームワーク
・Wagby (ワグビィ)
・Magic-xpa www.magicsoftware.com
・OutSystems www.bluememe.jp
・Genexus
実はまだまだありますが、まずはこのくらいにしておきましょう。
これからの時代の経営戦略はスピード重視になる
DXが重視される時代ですが、ここ5年を振り返ってみても、かなり経営環境の変化が激しいのではないでしょうか?
今は特に大きな変化の無い業種であっても、ある日突然、GAFAのようなプラットフォーマーが攻めてくるかもしれません。
そんな変化の速い時代に「要件定義をして、画面を設計して、利用者に確認とって、見積して、開発して、テストして・・・なんてことを数ヶ月もかけてやっていたら、たちまち経営戦略そのものが陳腐化してしまいます。
これからの時代は、完成度を重視するのではなく、まずは使えるモノを作って、試しながら完成度を上げていく時代なのです。
似たような例を挙げるとするなら、3Dプリンターでしょうか。
商品の試作では3Dプリンターを活用するようになりましたよね?
3Dプリンターが発明されたことで、金型とかを作らずとも設計情報から試作品を製造し、気になる部分があれば、設計情報を修正して、再度、3Dプリンターで試作品を作りますよね。
それと同じです。
情報システムの開発でも、作っては試して、気になる部分は修正して、また試すのです。
そのためには「速く作れる」「すぐに直せる」ということが必須になります。
それを実現するのが超高速開発ツールなのです。
これから重視されるのは要件をまとめる上流工程
このように超高速開発ツールを使えば速くシステムを開発できますが「この業務をするためにはどんなシステム設計にすべきか?」という要件をまとめるのは人がやらなければなりません。
この「要件をまとめるチカラ」はRPAでも活躍するはずです。
なのでこれからの情シス部門のスタッフは要件定義などを行えるように上流工程のチカラを養うべきでしょう。
要件定義を独学するのであれば「データモデル」というキーワードで書籍を検索すると良いでしょう。
グラス片手にデータベース設計 販売管理システム編 第2版 (DB Magazine Selection)
- 作者: 梅田弘之
- 出版社/メーカー: 翔泳社
- 発売日: 2016/02/09
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
実践的データモデリング入門 (DB magazine selection)
- 作者: 真野正
- 出版社/メーカー: 翔泳社
- 発売日: 2003/03/01
- メディア: 単行本
- 購入: 9人 クリック: 388回
- この商品を含むブログ (22件) を見る