新鮮

頑張らないために頑張る

いい出来のシステムでも無闇に使われると困る

f:id:hiizumix:20180316001811j:plain

超有名メーカの部長・課長から平謝りされる経験から始まったユーザ SE 業務。

先輩社員に話を訊くと僕はある誤解をしているらしいことが分かった。

感動した書籍 SE職場の真実 どんづまりから見上げた空 に触発された連載記事です。情報システム開発で不幸になる方を一人でも減らすため、ユーザ SE 体験を小説形式(フィクション多め)でツラツラ書いています。全編はカテゴリ ユーザ SE の真実

ユーザ SE はプログラミングしない

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

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

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

f:id:hiizumix:20180225162327j:plain

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

それはおいおい。

 

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

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

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

そういったときの先輩社員の顔は忘れられない。

うれしそうな半面、やや困った様子だった。

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

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

 

なぜ困るのか

今になるとその真意が理解できる。

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

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

さらにユーザが増えればユーザ向け説明を増やさなければならない。不思議なことにシステムを使ってもらうための操作説明を「教育」と呼ぶのだが、教育も開発メーカの作業範囲にしていた。新規にユーザを増やすと教育工数が増えるので、いわゆる仕様変更だ。

自社製品の使用方法を教えるのにお金を取る。通常の商慣習では理解できないが、システム業界ではそういうシキタリらしい。

オサイフの出処

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

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

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

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

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

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

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

提案体質

開発部門から業務部門への提案は難しい。

上記のオサイフに関連するが、仮に良い仕組みであっても、いざ投資をするときには業務部門は人を減らすか数字目標を増やさなければならない。そのため開発部門からの提案は、まず否定からはじまる。

 

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

おわり。

www.hiizumix.net

SE職場の真実 どんづまりから見上げた空

SE職場の真実 どんづまりから見上げた空