トップ
>
SEへの道

運用・保守プロジェクト編

2024年05月22日
広報担当
自己紹介
所属部署
第2システム事業部第1グループ
名前
K・M(女性)
役職
サブチーフ
勤続年数
13年(2024年現在)

仕事内容

某通信会社の会社内外への請求/精算情報、および会計情報を管理するシステムの運用保守を行っています。
システムの稼働状況のモニタリングやシステム利用ユーザーからの問い合わせへの対応、
また、システム内で利用するデータの登録や機器のメンテナンスなど多岐にわたる作業を行っています。

SEというとパソコンと向き合ってプログラミングをするイメージは強いかもしれませんが、
実際にプログラムを書く時間と同じくらい、お客様と会話をする時間も多いです。
メールや電話などでのやり取りや、ミーティングで直接お話しする機会もありますが、
最近ではTeamsチャットを利用する機会も増えています。

SEとしてのポリシー

業務に携わるうえで大切にしているのは、話をすることです。
なぜ話す事を大切にしているか、お客様のご要望とシステムの仕様の乖離を防ぐためです。

我々SEはお客様からのご要望を受けてプログラムを書くことが仕事です。
しかしお客様はシステムに関して理解されていることは多くは無く、やりたいことはどんな方法で実現が出来るのか、
システムに要望を落とし込んだ時にどのようになるのかを大半の方がイメージ出来ません。
そういった背景から、お客様からのヒアリングが十分でない場合に、実際にシステムで実現できることと
お客様のご要望が乖離した状態でシステムの仕様が決められて実装されるというケースも発生しています。

せっかく作ったシステムでも、ご要望と異なる点があることで使いづらい、または使えないといったことになる可能性もありますし
作り直しが発生する可能性も出てきてしまいます。
そうならないためにも、最適解を導き出せるようにお客様となるべく多く話し、必要な情報を引き出すことを大切にしています。

SEの1日

9:00 出勤 システム不具合やお問合せが無いか確認後、ミーティング資料準備
10:00 プロジェクト全体ミーティング
11:00 運用保守作業
13:00 システム①の運用保守チーム内部打合せ
13:30 ユーザーとの問い合わせ内容確認
14:00 開発チームの進捗状況確認
14:30 システム②の運用保守チーム内部打合せ
15:00 お客様との打ち合わせや運用保守作業、お客様要望説明用の資料作成など
17:30 明日以降の作業確認
18:00 退勤

某エンジニアがSEになるまで

私の場合は新卒採用で入社したため、この業界での歴=エルティの勤続年数となります。
大学時代にプログラミングの授業はあったもののほとんど未経験に近い状態でしたので、実際の業務に携わりながら必要な知識を学んできました。

さて、SEになるまでというからには、まずはSEとは何かという定義が必要ですね。
Wikipediaを調べると日本の企業では以下の業務を行うものを指すことが多いそうです。沢山ありますね。

==================================
企画
要件定義
設計
開発
評価
プロジェクトマネジメント
コンサル
工事
保守
運用
==================================

自分自身が上記の全て確実に出来るかと言われると正直なところ自信はありませんが、お客様に信頼頂き仕事を任せて頂いていますので、要点は抑えられているのかなというのが私自身の自己評価です。
様々な経験を積んでの今がありますので一概にコレというのは難しいのですが、これからSEを目指す方としてはまずは下記の点を意識してみると良いと思います。

・話をする
「SEとしてのポリシー」にはお客様から如何にして情報を引き出すかという自分へのインプットに焦点をあてて書きました。
これももちろん大切ですし、インプットとは逆に自分から他者に話をするアウトプットする方も大切です。
人に話そうとすることで自分の中にある情報も整理できますし、何か問題がある場合はその問題を他者に共有することが出来ます。

必要な情報に絞って伝えなきゃいけないというプレッシャーや、作業が滞っているからと情報を溜め込んでしまうということがあると思いますが、これが良い方向に働くことはありません。
入社直後は何が必要なのか自分自身で判断することは難しいものですし、最初のうちはちょっとくらいの情報過多には目をつぶってもらって、まずは発信することを心掛けると良いかと思います。
ただしずっとそのままでは仕事の効率も悪く相手の時間を奪ってしまいますので、回を重ねるごとに少しずつ必要な情報に絞っていくようにしましょう。

・何事も経験してみる
自分の目指す方向には関係のないと思えるものでも、案外関係していたりすることがあります。
要件定義をするためにはある程度システムの設計を理解する必要が、またその逆で開発時に実装理由を理解していないと設計時のバグの混入に気が付けなかったりなどなど。
最終的に例えば設計のプロフェッショナルになりたいと思ったとしても、ただそこの部分だけを学ぶのではなく、色々なことをバランスよく学んでいくことが大切です。



自分がなりたいもの、目指す方向を模索しつつも色々な人やものと関わって様々な経験を積んでいくことを日々大事にしたいものですね。
私自身もSEとしてはまだまだ学ぶことの多い身だと思いますので、日々精進しているところです。