エンジニアBLOG

2021/09/08

これもエンジニアの仕事です!

はじめまして。
アビコ と申します。

みなさんが持っている「エンジニア」のイメージって、どんなものでしょうか?
プログラムをバリバリ書いている人? アプリケーションの画面をデザインしている人?
WEBページを作っている人の話なんて、ドラマになりそうですよね。

image

エンジニアのイメージ?

今回はプログラムを書いているわけでもない、デザインをしているわけでもないエンジニアの業務内容を紹介していきたいと思います。

まずは、今携わっているシステムとの関係からご紹介します。
【2016年】 すでに稼働10年を超えている基幹システムの運用・保守として参画
     ↓
【2017年】 基幹システムをリプレース(更改)するためのプロジェクト発足
     ↓
【2019年】 度重なる苦労のもと新システムのリリース
     ↓
【2021年】 新システムの運用・保守を担当 (←今ココです)


上の年表を見るとプログラムを組んだり、画面をデザインしていたりしそうですが、一切していません。
その理由は、『システム構築を発注する側の立場だから』なんです。

つまり、『○○のシステムを導入しよう!』と言う側ですね。
※ちなみに、よくイメージするエンジニア(プログラム書いたりする人たち)は、この反対側の(構築する)人たちです。

システムを導入する側の立場だから、実際に利用する業務部門のユーザーから要件をヒアリングして、本当に必要な機能なのかを精査したり、システムを構築する人たち(開発ベンダー)と実現方法やコスト、スケジュールの相談をしたり、と、“利用ユーザー“ と “開発ベンダー “ の中間に立って「調整」することが多々あります。

この「調整」が、私のメイン業務というわけです。

一つ例を挙げると・・・
システムを利用する業務部門から「○○の機能が欲しい」と要求されたとします。開発コストを見積もってもらった結果、「予算に合わない!」なんてよくある話です。このままでは話が進まず、みんな困りますよね?

ここで私の出番です。

業務部門と「利用頻度が少ない機能については、開発の対象外でお願いできませんか?」と相談して、コストを抑える方向に調整します。当然、開発ベンダー側にもスケジュールや工数など、いろいろと調整を入れていきます。

双方の合意が取れなければ話が進みませんので、話し合いを重ねて、お互い納得がいく落としどころを見つけるという流れです。
実際に合意が取れて話に進展があったときは、やりがいも感じますし、何より嬉しい瞬間です。

たくさんの方とコミュニケーションを取る機会が多く、正直、面倒と思われるポジションですが、このスキルは開発の上流工程(要件定義など)や、部下を持つリーダー役になったときにも活かせるものなので、是非チャレンジしてみてほしいです。

image

プログラムを書かないエンジニアもいますw

このブログではたくさんのエンジニアが業務内容を紹介していますが、こんな業務もあるのだと仕事のイメージを広げてもらえると幸いです。
現場では楽しく働いている社員が、皆様に会えることを楽しみにしています。一緒に仕事ができたら素敵ですね。
皆様のご活躍をお祈りしております。

最後まで読んでいただきまして、ありがとうございました。