システムエンジニア（以下SEとします）という職業を一度は耳にしたことがあると思います。では皆さんはSEにどんなイメージを持っているでしょうか。何する人？残業多い？将来性は？
私なりの考えを色々と書いていきます。
プロフィール
簡単に私のプロフィールをかいておきます。
- SE歴：２年
- 業種：金融系
- 出身学部：非ITの理系
- 保有IT系資格：基本情報技術者試験、応用情報技術者試験、Oracle Java Programmer silver SE8、Oracle DBA bronze SQL、 AWS Solutions Architect-Associate、JDLA Deep Learning G検定
システムが出来上がるまでの工程
冒頭で上げた疑問に回答するにはシステムが出来上がるまでの工程を知ってもらう必要があるので解説します。
システムが出来上がるまで下記の工程を上から順番に経ていきます。
- 要件定義
- 外部設計
- 内部設計
- 開発
- 単体テスト
- 結合テスト
- 受入テスト
- 運用・保守
この工程を上からなぞって開発することをウォーターフォールモデルといい、金融系などの大きなシステム開発によく使われる昔ながらの手法です。対してこの工程を超短期で何度も行うことをアジャイル開発といいます。
私は金融系のSEなのでウォーターフォールモデルでの開発を前提に書いていきます。
要件定義
お客さんからの要望を聞き、必要な機能を明確化する工程です。
お客さんがどのようなビジネス課題を持っていて、その課題を解決するためにどんなシステムが必要か、どれくらいの性能が必要かなどを整理します。整理したものをお客さんに確認してもらい、OKが出たら次の工程に進みます。
（例）
お客さんの要望：小売店での会計処理をシステム化して業務効率化を図りたい
要件定義：商品の金額を取得する機能、金額を計算する機能、お釣りを出す機能などなどが必要
外部設計
要件定義書を元にシステムを構成する機能ごとの設計をする工程です。
どういうときにどんな動きをするかなどを細かく設計していきます。
（例）
金額を計算する機能の設計書：①商品の金額が預かり金以下の場合、預かり金-商品の金額を戻り値として返却する ②商品の金額がマイナスならエラーを出す
内部設計
外部設計書を元により細かい設計書を作成する工程です。
外部設計ではざっくり設計していますが、内部設計ではプログラミング言語レベルで設計を行います。プログラムをどういう構成でどう書けばいいかまで記載するイメージです。実際のところ外部設計からプログラミングができるので必要がない場合もあります。
（例）
金額を計算する機能：m_amount(商品の金額) <=g_amount (預かり金)の場合、g_amount – m_amount を戻り値 resultにセットして、メソッドreturnResultを呼び出す など
開発
内部設計書を元にプログラムを書いていく工程です。
皆さんがイメージするわけわからないアルファベットやら数字、記号をパソコンでカタカタ書いていく工程です。javaやC言語などプログラミング言語を使用します。
単体テスト
開発工程で作成したプログラムが内部設計書通りにできているかを確認する工程です。
まずは内部設計書を確認しながらテストケースというものを作成します。テストケースは設計書に記載された要件を満たしているか確認するプログラムを動かす手順のようなものです。
続いてテストケースを元にテスト用のプログラムを作成します。
最後に、このテスト用のプログラムを動かして想定通りの動きをするか確認します。
結合テスト
開発工程で作成したプログラムが外部設計書通りにできているかを確認する工程です。
単体テストで動作を確認したプログラムをまとめて動かすことから結合テストなんて呼ばれます。単体で動かすと動作には問題ないが、結合して動かすとうまく動かなかったり、想定外の動きをしたりするのを検知・修正することが重要になります。もちろん、問題なく動いても外部設計書通りの動きをしていないとダメです。
大きなシステム開発では結合テストA、結合テストBのように結合テスト工程をさらに分割してテストを実施する場合があります。
受入テスト
結合テストまで動作確認が完了したシステムを実際にお客さんに動かしてもらい、要件を満たしているか確認する工程です。
ここでOKが出ると納品となり、実際の業務で使われ始めるのでかなりシビアなチェックが行われます。
運用・保守
納品されたシステムが実業務で問題なく動いているか確認する工程です。
特に問題なく動いていればいいのですが、不具合が起きた時に少しでも早く修復するために動く必要あります。
SEは何する人？
一言でいえば、何でも屋です。
要件定義～運用・保守まで何でもこなします。
多くの人はパソコンをカタカタ叩いているイメージがあると思います。多分、プログラムを書く姿を想像しているのだと思いますが、それはプログラマーという人たちです。工程でいうと開発～単体テスト工程を専門で実施する人です。
SEは何でもやると書きましたが、一つ注意したいのが契約形態によって担当範囲が変わるということです。例えば下記のような会社構成でシステム開発が行われているとします。
- エンドユーザ（システム発注者）
- 一次受注者…発注者から直接受注
- 二次受注者…一次受注者から受注
- 三次受注者…二次受注者から受注
この場合の工程ごとの担当範囲は下記のようになります。
- 一次受注者…要件定義～外部設計、受入テスト
- 二次受注者…内部設計～結合テスト
- 三次受注者…開発～単体テスト
必ずしもこのようになるわけではありませんが、一次受け、二次受け…となるごとに担当範囲が開発寄りになっていく傾向があります。
では、一次受けの人は開発工程では何しているのかというと、お客さんとのやり取りの窓口だったり、進捗管理など管理業務をメインで行っています。
あくまでも私の所感ですが、一次受注者になることが多い、大手SIer企業の人は技術よりのことを聞いても全然わかっていない人が多い印象です。もちろん、物凄い詳しい人もいますが、割合的にはかなり少ないです。管理をメインで行っています。
対して二次受注者になることが多い、中堅SIerは広範囲を担当することが多いので技術面でも詳しい人が多く、管理もできる人が多い印象です。もちろんできない人もいますが。
三次受注者はいわゆるプログラマ特化のポジションなので開発が優秀な人は優秀です。多分趣味でプログラム書いてる人とかも多い。ただ、ピンキリで全然仕事してくれない人も多いです。
残業時間多い？
残業時間は毎月30～50時間くらいの時が多く、平均して一日２時間くらいの残業になります。
１７時半が定時、通勤時間１時間とすると帰宅時間は毎日２０時半です。私的には許容範囲内です。残業時間自体はどこのIT企業も同じくらいの数字を公表していると思いますが、注意してほしいことがあります。
それは、「シーズンによって波があるから、落ち着いた時期は残業殆どないよ」という言葉です。
私も採用時にこの言葉を結構聞きましたが、嘘です、これ。全く信用ならない。少なくとも金融系のプロジェクトでこんなの聞いたことがないです。
というのも金融系のシステムは大規模なため、数年かけて開発が行われます。そのため、スケジュールががっちり組まれており、細かい納期も毎月のように設定されています。
一般的に納期が近いと何かとバタバタします。スケジュールに余裕をもって進めていても納期直前にお客さんから追加の要望が入ったり、急なバグ修正依頼が入ってくるからです。
いつも「この要望と修正は次の納期じゃダメなの？！」と思うのですが、日本人はキリ良く終わらせるのが好きなのか無理やり直近の期限にタスクを押し込みます。それを終わらせるために毎月残業をします。
なので波とかないです。毎月３０～５０時間、年末や年度末など納品時期になるとここにさらに数十時間プラスされます。私は最大１１５時間/月くらいです。
残業長いのは嫌じゃないの？
そりゃ嫌です。笑 ただ、わけわからず残業しているわけではないのでもう無理！とかはないです。工夫したり、自分でスケジュール組んでうまく調整すれば、そこまで残業は増えないです。
ただ、急に頼まれる仕事は嫌です。これはプロジェクトに依るのかもしれませんが、「今日中にこれやって」というのが本当に多いです。
SE全般に言えると断言はできませんが、バグ回収など基本的に即日対応なのでこういうことは比較的多いのではないかと思います。
SEを目指していてこういうのが絶対無理という人は気を付けたいところです。
SEに必要なこと・不要なことは？
完全に私の所感ですが書いていきます。
必要：強い精神力
長時間労働に耐えうる精神力が必要です。それだけでなく、わけわからないことを急に任されるのでそのプレッシャーとわからないという自分の非力さ・情けなさに耐える必要があります。
SEの職業病=うつ病 とよく言われるくらいなのでここは本当に気を付けたいところです。
私の場合はいい意味で能天気・マイペースなため、大丈夫だと思っていましたが、配属直後に４か月連続で残業時間が４０～１１０時間だったときは鬱になりかけました。笑
世の中にはもっとしている人はいると思いますが、無理な時は無理といえる精神力だけは必ず持っておきましょう。
必要：コミュニケーション能力
コミュニケーション能力とは書いたものの大そうなものではないです。わからなければ聞く、これができればいいです。
一人で悩んで結果的になにも終わっていないのが一番ダメです。うざがられるくらい聞きましょう。
不要：ITの知識・理系出身
ITの知識も理系出身である必要もありません。実際、IT知識もない、文系出身の人がバリバリ活躍しています。知識は後からつけることができるので大丈夫です。
将来性は？
将来性はあると思っています。世界はここ２０年の間にIT技術により、飛躍的に発展しており、人間の生産性も底上げしています。これからもそうであると思っていますし、IT人材はここ最近ずっと不足しています。
ただ、注意していただきたいことは、IT系の仕事の中にもAIにとって代わる仕事があるということです。
例えば、開発で行うプログラミングはAIによって置き換わることが確実であり、すでにそのようなツール等が存在しています。
また、サーバーを構築・運用するサーバーエンジニアについてもAmazonのAWSのように簡単・高速・低コストにサーバー構築できるサービスができており、一から時間をかけてサーバーを構築するといった需要は低下しています。
じゃあ、何をしたらいいの？と思うかもしれませんが、それは上記に挙げたようなツールやサービスを使う側の技術を付けることです。これに関しては常に技術の進歩に追随していく必要があるので日々勉強が必要です。
もうひとつは要件定義～外部設計を行う立場になることです。どんなにAIが発展しようとも結局使うのは人間であり、その人間から必要な情報を引き出すのは人間です。別の言い方をすれば、人間の情報をAIがわかる情報に変換する人でしょうか。
今ある職業でいえば、データサイエンティストとかが近いのかもしれません。
最後に
ここまでSEという職業について色々と書いてきましたが、いかがだったでしょうか。SEを目指している方、現役SEの方などなど、少しでもお役に立てたら嬉しいです。
コメント