業務システムの保守について

今回は契約先企業に常駐し、社内システムを保守する仕事について、お話しいたします。

社内システムを利用する利用者には様々なニーズがあります。
一般的に、そのニーズを取りまとめする担当は、社内情報システム部門となります。

情報システム部門には、多くの相談が寄せられます。
・画面に項目を増やしてほしい
・画面の操作を簡略化してほしい
・入力する文字数を増やしたい
・チェック機能を追加したい     etc…


他にも業務のやり方の変更や規定見直しによるものなど、様々な話があります。
システム保守担当者の仕事は、利用者のニーズを聞くところから始まります。
システム開発は設計・開発・テストをする事が仕事と思われがちですが、
実はその工程に入るまでにも、重要なステップをいくつも踏んでいます。
今回はその件に少し触れたいと思います。


社内システムは、部門別又は専門性のある業務に特化した機能が多く
別のシステムやデータベースと連携させている場合が多い。

利用者から見えているシステムは、氷山の一角。
実はシステムの裏側に複数の処理や制約が入っています。
場合によってはそのシステムだけでは完結しない別システムの仕様も存在します。
それらは、当然システム仕様書に記載されていますが、
利用者がそれらを理解しているわけではありません。

■要望の背景の確認
スタートは利用者の声から始まります。
利用者から「ボタンを増やして欲しい」とニーズが出てきます。
システム保守担当者は、利用者のニーズが、社内システムに対して、
理にかなっているのか、ヒアリングします。
・「ボタンを増やしたいのはなぜか」
・「それをすることで誰がどう助かるのか」
・「どうしてそんな要望を出されているのか」

すると徐々に利用者のニーズが「ボタンが欲しい」のは、
「誤操作の抑制」や「新たな業務の追加、変更」である等、
「ボタンが欲しい」本当の理由が浮き彫りになってきます。

ニーズの理由を聞き出す作業が、案件化の前準備になります。

■改修すべきかどうかの判断材料の作成
利用者の「本当の理由」を聞き出した後に進めるのは、
「改修要否の判断材料集め」になります。
現場によって様々ですが、大きく以下のポイントを押さえます。
① 改修することで得られる効果
② 改修に掛かる時間(工数)の算出
③ 上記①と②を比較した上での費用対効果の算出

少し難しい話ではありますが、
「改修することで得られる削減費用」と「改修することで発生する費用」を比較。
※削減時間と改修にかける費用が見合っているかどうかを数値化する作業。

一般的に「定量効果」と呼ばれるものですが、とにかく比較できるようにします。
これらもシステム保守担当一人では作成できませんので、
利用者やシステム開発担当と相談し、時間を確認していきます。

場合によっては今の現場の環境だけでは対応出来ず、
新たなソフトやサーバーを構築する可能性もあります。
全てを自身で算出する必要はありませんが、いかに根拠のある数字にするかが、
技術者の腕の見せ所と言ったところでしょうか。
なお、「定量効果」が少ない場合も、
数字に表せない効果(法令対応やチェック処理強化による誤記入抑制等)は、
「定性効果」といい、こちらを提示することもあります。

■現場の空き状況や納期の確認
上記の試算で効果があると見越した場合、
次に考慮すべきは納期や現場の空き状況になります。
場合によってはこちらを先に進める場合もありますが、
どれだけ効果があったとしても、それを対応できるシステム開発担当者が
居なければ対応はできません。効果が高く是非とも対応すべきとなれば、
現在進めている案件を調整して本案件を進める等、調整が必要になります。
これらも判断材料として検討した上で資料化します。

■システム保守担当者の仕事 (案件化に至るまで)
これら全ての情報を資料化して、
ようやく、判断材料を情報システム部門へ提供できる流れとなります。

情報システム部門担当者は、
私たちが準備した資料(判断材料)と、システム保守担当者の補足説明を聞きながら、
対応すべきか否かの判断を行います。
一度で終わる場合もあれば、何度も資料の修正、打合せを繰り返す場合もあります。

幾度の判断の後、システム開発が必要となり初めて、顧客ニーズが案件化しスタート
されます。

■最後に
上記はシステム開発案件に至るまでの一例です。いかがだったでしょうか?
企画提案に近い流れではありますが、システム保守担当者の仕事(一部)であり、
あまり知られていない仕事の一つです。
ここまでの間にプログラムを触ることは一切ありません。
※解析や仕様書の読込はありますが。

技術はあるに越したことはありません。
けれどそれが全てではない、そんな風に思っていただければ幸いです。

This entry was posted in エンジニアブログ. Bookmark the permalink.