『情シス』という仕事を希望する人はまず『システムの問題地図』を読んだ方が良いという話

情シスって会社の仕事をIT技術で変革する仕事だから、もしかしたらスマートなものだと思われていないでしょうか？

こんにちは！　松田軽太です。

例えば情シスの求人情報を読むと『社内のIT化を担う重要なポジションです。自分たちでIT技術を活用して社内システムを構築するやりがいの ある仕事です』とか書いてあったりしませんか？

でも、それって鵜呑みにして良いのでしょうか？

しかし情シスの仕事の実態ってなかなか知ることができませんね。

そこで情シスの仕事をしてみたい人は、まずは沢渡あまね氏の『システムの問題地図』を読んでみる良いでしょう。

システムの問題地図 ~「で、どこから変える?」使えないITに振り回される悲しき景色

『システムの問題地図』で描かれる「あるあるエピソード」はすごくリアル

沢渡あまね氏の著書は『仕事の問題地図』や『職場の問題地図』といった「みんな、心の中で思っている『自分の職場ってオカシイのでは？』 という疑問を言語化してくれています。

この本でもスゴくリアルな「あるあるエピソード」が紹介されています。

もう読んでいると「そうそう、そんなんだよ！」と共感する内容ばかりです。

なので「この本は情シスという仕事をこれからしてみようと思ってる人が読む良いのではないか？」と思ったのです。

では僕が特に共感した「あるあるエピソード」を紹介します。

なんでもかんでもシステム化したがる

基幹システムのリプレースというプロジェクトを経験した時に感じましたが、なんでもかんでもシステム化したがるのです。

せっかくの機会だからと、現場作業者がExcelで管理している作業も「基幹システムは長く使うのだから、今、Excelで管理している作業も基幹 システムに機能追加したい」と管理者が言い出します。

でも、よく考えたらExcelでも管理できているのであれば、Excelを使いやすく改造してあげれば、わざわざ基幹システムに機能を追加しなくて も済むのではないでしょうか？

しかも基幹システムに機能追加すると高額な開発費が掛かるハズです。

なのでなんでもかんでも基幹システムに可能追加する前に、その機能を追加することは開発費と比較してコスパが合うかどうか？をちょっと冷 静になって考えてみましょう。

業務部門の人は自分の仕事を言語化できない

業務システムを構築する場合、現場作業者にどんな風に仕事をしているのかを聞き取り調査します。

その作業を要件定義といいます。

それに基づいて業務システムに必要な機能を洗い出して、どんなシステムにするか設計します。

だがしかし、だがしかし、です。

現場作業者というのは、長年、自分がやっている仕事は身体が覚えていることが多く、言葉で説明することに慣れていません。

なので現場作業者からどんな仕事をしているのかを聞き出しても、説明している人と聞いてる人の間でズレが生じてしまうことがあるのです。

そしてズレに気がつかないまま開発が進んでしまうと、結果的に完成した業務システムはひどく使いにくい代物になります。

この場合「言った」「言わない」の不毛な泥仕合になります。

説明した側からすれば「あの時、説明しただろう」と主張するし、聞いた側からすれば「その説明では伝わらない」という噛み合わない言い争 いが勃発するのです。

もちろん、業務ヒアリングの際には議事録を書くのは当然としても、議事録を書いた人は業務内容を知らないので、ポイントがズレることはよ くあります。

可能であれば、議事録は業務ヒアリングを行った人が自分で書いた方が、あとで読んだときに、その時のニュアンスなどが伝わるでしょう。

『運用でカバー』と『仕様です』は最悪な言い訳

要件定義の段階で勘違いしたまま構築された業務システムは、実業務から外れた使いにくいシステムになってしまいます。

この場合、業務システムを使い始めてしばらくしてから、現場作業者が「これだと余計に手間が掛かって使いにくいんだけど」と苦情を言って きます。

しかし、現場作業者の意向に合わせて機能を修正して欲しいとシステム開発会社に申し入れても「分かりました。では追加開発の費用を見積も ります」と高額な見積り書を提示されるでしょう。

実際に聞いた話ではあるパッケージシステムに実行ボタンを一個追加してもらうだけで300万円かかったそうです。

とはいえ追加開発費用の予算なんてあるハズないですよね。

そうなると必ず出てくるのは「仕様ではそうなっているので、運用でカバーして下さい」という必殺技のセリフです。

こうなると現場作業者は自分だけが使えるExcelとか作り出して、せっかくお金を掛けて作った新システムは「実績入力システム」となり、実務 の管理はExcelで行われることになるのです。

なので要件の掘り出しって地味ですがスゴく大切な作業なのです。

『今と同じことができるように』と『上手いことやっといて』は通用しない

これ、多くの人がよく言う言葉です。

でもね、これって無理なんです。

例えばですよ、初めて入ったレストランで「いつも食べてるカレーと同じ味にしてよ」みたいな注文なんです。

だって料理する人は、いつもどんなカレーを食べているのか知らないんですから。

そして料理する人が「いつもどんなカレーを食べてるんですか？」と聞いたら「んー、まぁ、美味しければいいから、適当に作ってよ」と答え が帰ってきたようなもんです。

もし、アナタがこの料理人だったら、どんなカレーを作れば良いと思いますか？

「そんなんじゃ、わかんねーよ！」って心の中で叫ぶのではないでしょうか？

つまり『今と同じことができるように』と『上手いことやっといて』って答えは「適当に美味しいカレーを作って」と言うのと同じなので、そ んなこと、できるワケがないのです。

『情シスの人』だからといってIT技術に詳しいワケではない

けっこう多くの人が勘違いしていると思いますが、『情シスの人』だからといってIT技術に詳しいワケではありません。

システム開発が本業のSIerのシステムエンジニアであれば、IT技術に詳しいでしょうが、中小企業の小売業や製造業の情シスの人の場合、意外とIT技術に詳しくない ということがあります。

なぜなら企業の情シス部門の人員は総務部門が配置を決めていますよね。

例えば昨日まで営業とか総務といって仕事をしていた人が「春の人事異動祭り」でそれまでの仕事は畑違いの情シス部門に移動になる場合もあ るのです。

また最近は自社内で業務システムを開発せずにパッケージシステムを導入することが多いので、そもそもシステム開発をした経験がないという 場合もあります。

この場合、情シスの仕事はシステム開発をSIerに依頼して、見積もり比較をすることが仕事になるのです。

最近は『ゼロ情シス』や『兼任情シス』も増えています。

情報システムの管理を専門で行う情シス部門を作るほど人材が確保できないとか、総務や経理でちょっとコンピューターに興味がある人が、うやむやのうちにシステム管理者をやらされるという貰い事故みたいなパターンです。

このような場合は業務システムの管理は片手間なので、IT技術に詳しくなくても仕方がないのです。

まぁ、もちろん知っているにこしたことはないのですけどね。

『システムの問題地図』で書かれた事情はほぼノンフィクションだと思って良い

僕自身『システムの問題地図』を読んだとき「うわー！これ、リアルだなぁ～」と驚きました。

エピソードの中には実際に自分の経験に似た内容もあるし、経験していないエピソードであっても、内容を読むと「あー、なるほど。こういうことはあるだろうな」と思うことばかりです。

言い換えると『システムの問題地図』を読めば、かなりリアルに『世間の情シス』の仕事を感じることができます。

おそらく読むと「この部署、ハズレなんじゃね？」と思うのではないでしょうか？

しかし、たとえ「なんじゃこれ？」と思うようなザンネンなエピソードであっても、実在する課題であるなら解決するいうもの、それもまたひとつの仕事です。

いずれにせよこれからの企業の在り方は、IT技術無しには成立しない世の中になります。

『システムの問題地図』で紹介されているようなエピソードを是非、みんなで解決していけると良いなと思う次第です。

www.matudakta.com

職場の問題地図 ~「で、どこから変える?」残業だらけ・休めない働き方

マネージャーの問題地図 ~「で、どこから変える?」あれもこれもで、てんやわんやな現場のマネジメント

働き方の問題地図 ~「で、どこから変える?」旧態依然の職場の常識