社内SE

「Re:ゼロから始める社内SE生活」#02 いい出来のシステムでも使われると困る

 社内SEの体験を色々と振り返るフィクション小説です。「Re: ゼロから始める社内SE生活」#02、いい出来のシステムでも無闇に使われると困る。

 前回は こちら

社内SEはプログラミングしない

 超有名メーカの部長・課長から平謝りされる経験から始まった社内SE業務。先輩社員に話を訊くと僕はある誤解をしているらしいことが分かった。

 社内では「開発部門」と名乗っているので自分たちでプログラミングしていると思っていたが、そういう訳ではないらしい。システム開発は、ユーザー企業が「こんなのが欲しいのだけど」という要求をまとめ、SIerと呼ばれるシステム会社が「承知しました」とシステム一式を開発/構築する。場合によっては要求自体もまとめてもらう。これを通称「丸投げ」という。

 このとき多少ホッとしたのを覚えている。

 学生時代にFORTRANやC++で数値計算をした経験はあるが、バリバリとプログラミングできるのかどうかは不安だった。でもそうか、プログラミングはプロにお願いできるのだとわかり安堵した。それと同時に、他の会社に作ってもらうならば、この人達は何をしているのだろうか。それを開発部門と呼んで良いのだろうか。そんな疑問がふつふつと湧いてきた。

丸投げってラクそうだよねー

 それはおいおい。

無闇にシステムを使われると困る

 障害報告が終わった後、実際に動いているトラヒックモニタを触らせてもらった。具体的な機能は守秘義務に当たりそうなので差し控えるが、まあいい感じだった。そして、このシステムは大阪時代に携わっていた業務に利用できると思った。

「これ、むかしの部門に使ってもらうと喜びますよ!」

 そういったときの先輩社員の顔は忘れられない。うれしそうな半面、やや困った様子だった。

「業務側の意見がいえるのはいいけど、むやみにユーザーを広げると問題あるし、開発側から業務側に提案するのも微妙かも。」

 僕にはその発言の内容がよく分からなかった。いい出来のシステムならば、みんなに開放して使ってもらえればいいんじゃないのだろうか?なんで一部の部門だけに閉じた形で留めておくのだろうか?

システムを広めると部門間の確執を生む

 当時は全く分からなかったが、今になると先輩の発言が理解できる。

想定以上のユーザー増加は困る

 業務支援システムでは利用ユーザー数をあらかじめ規定する。それによりどれだけの処理負荷が掛かるかを見積もり、負荷に応じたハードウェアを用意する。当時は全てオンプレなのでオートスケールなどは当然出来ず、100ユーザーで見積もったシステムを、300ユーザで使ったら破綻するのが見えている。いい出来のシステムであっても安易にユーザーを増やすことは出来ない。

 さらにユーザーが増えればユーザー向け説明を増やさなければならない。不思議なことに、IT業界ではシステムを使ってもらうための操作説明を「教育」と呼ぶ。自社製品の使用方法を教えるのにお金を取る。通常の商慣習では理解できないが、そういうシキタリらしい。

 トラヒックモニタでは、教育もSIerの作業範囲にしていた。新規にユーザーを増やすと教育工数が増えるので、いわゆる仕様変更になってしまう。

オサイフはユーザー部門にある

 丸投げにはお金がかかる。ではそのオサイフはどこになるのだろうか。

 ユーザー企業においてシステム開発は「投資」と見なされる。製造業であれば新しく工場を建てることと同じ扱いである。実際、会計上も固定資産として計上する。投資であるので稟議が必要になり、稟議を通すためにはROI(Return On Investment : 費用対効果)を経営層にコミットする必要がある。

 業務支援システムの ROI を計算する方法は大きく2つある。

  1. システム導入で、業務部門の人数をいまからどれだけ減らせるか
  2. システム導入で、本来必要になる人数をどれだけ減らせるか

 1 は、たとえば10人いて20の業務量だとする。システム導入で効率化し、20の業務量を5人で捌ける見込みが立つならば、10人 – 5人 = 5 人分のお金を使っていい。このときは派遣さんを5人減らす必要がある。

 2 は、たとえば10人いて20の業務量だとする。システム導入で効率化し、40の業務量を10人で捌ける見込みが立つならば、40 – 20 = 20業務量 = 10人分のお金を使っていい。そのときは業務部門は2倍の成果数字をコミットする必要がある。

 経営目線で見れば普通のことかもしれない。だがこのROI構造は部門間の確執を生む。A部門が身を切って投資したものをB部門が身を切らずに利用したらどうなるだろうか。A部門の不平不満がたまり、その矛先が社内SEに向けられるのは火を見るより明らかだ。もちろん、処理速度が遅くなったのはB部門が使い始めたからだとは口が裂けても言えない。

提案を受ける側には責任がつきまとう

 社内SE部門からユーザー部門への提案は難しい。

 上記のオサイフに関連するが、仮に良いシステムであっても、いざ投資をするときには業務部門は人を減らすか数字目標を増やさなければならない。そのため社内SE部門からの提案は否定されるのがオチだ。

「実は社内にこんなシステムが既にあるんですよ」
「いいじゃん!使わせてよ!」
「ユーザーが増えるとハードを増やすので、○○円いただけますか?」
「そのためには派遣さん切らなきゃいけないよね。ありえないでしょ」

 

 かくして旧部門への営業は差し止められ、モヤモヤした気持ちのまま、社内SE業務にどっぷり浸かり始めることになる。

つづく