エンジニアとは一体どんな仕事？分かりやすく解説します！

皆さん、こんにちは！

今回は「エンジニアとは？」にフォーカスして、IT業界に興味があるけど右も左も分からないという業界初心者の方向けの記事となっています。

エンジニアは一体どんな流れで仕事をしている？

さて、そもそもITエンジニアというのは「IT技術を駆使してお客様が求めるサービスを作り上げる」事が主な仕事となります。

では実際にどんな流れで日々の仕事をこなしているのでしょうか？
先ずはシステム開発の一連の流れを、ウォーターフォールモデルというIT業界でよく語られるワードをもとに解説していきます。
このウォーターフォールモデルの詳細な定義等は本記事では取り上げません。
あくまで業界での働き方や役割について、知識がない方に向けてわかり易く説明する事を目的としていますので、一部アレンジしています。

それでは早速見ていきましょう。

エンジニア業界の作業工程

工程ごとにどんなことをするのか？

さて全体の流れに関してはイメージがついたのではないかと思います。

それでは次に、工程毎にもう少し細かく解説していきます。

企画

基本的にはお客様側で「そもそもこんなサービスを作りたい」という元ネタがある場合や、または課題を抱えているお客様に対し、コンサルティングを行い、解決策となるサービスを企画したりする段階です。
本来はここから仕事ができるとよくも悪くも非常にスリリングで楽しい事に間違いはありませんが、当然うまくいかなかった時の責任やプレッシャーは、、、相当なものです。

要件定義

作りたいサービスや改修したい要望が決まった段階で、それをそもそもどんな実装方針で、どんな運用設計で、どんなスケジュールと人員で実現していくかの全体方針を決める段階になります。

設計

要件定義の工程で決めた内容を基に、具体的なシステムの設計を行っていくフェーズです。

「データフロー図」や「データベース設計書」等、開発者としての産みの苦しみや、実際にサービス化した時の達成感を直に体感できるフェーズと言えます。

開発

実際にプログラミングを行っていくフェーズです。
どうしたら処理効率的なロジックとなるのか？汎用的に使える部品化は出来ないか？制御の流れは適切か？等、プログラムを作成し、それをテスト的に動かして結果を確認したり、最終的に機能が形になっていくのが見えるため、開発中は非常に大変な事も多いですが、実際に動くものが出来上がった時の喜びはひとしおです。

テスト

開発が終わったら、作成したプログラムが要件定義で決めた通りの動きをするか？作成した条件分岐や制御が正しく行われているかをテストしていき、最終的には処理全体として正しく動くことを確認するフェーズです。
またテストと言っても、目的に合わせて実に多くのテスト工程が存在するので、よく使われるものだけを簡単に解説していきます。

・UT（ユニットテストまたは単体テスト）

モジュール単位で機能が正しく動作するか確認する。
・IT（インテグレーションテストまたは結合テスト）

モジュールをサブシステム毎に纏めて単位で正しく動作する事を確認する。
・ST（システムテストまたは総合テスト）

リリース

試験が全て完了すれば、それを実際のユーザーが使用できるようにリリースします。
実際のところ、リリース自体はそこまで緊張を伴うものではないことが多いですが、リリースした機能を実際のユーザーが使った時に色々と不具合が見つかったりする事が多く、リリース後のタイミングの方がしびれる事が多いです笑
はい、私が一番嫌いなフェーズでもあります。リリースしなかったら何も意味はないのですけどね、、、笑

保守

さて、実際にサービスが世に出た後も、実際には様々な不具合が見つかることがあります。
それらを、カバーするのが、運用・保守のフェーズになります。
例えば、不備があるデータに修正を加えたり、不具合個所のモジュールを入れ替えたり、システムトラブルの際には、調査を行い、関係各署に連絡を行ったり等、、、
私がＩＴ企業に就職して、一番最初に携わったフェーズがこの運用・保守作業でした。
大手のシステムになると、夜間に動く処理が多く、当番制で何かあった時の電話を持たされるのですが、夜中にその電話が突然なった時のビビり具合が半端ではなかったことを今でも覚えいています笑

どんな役割の人がいるの？

ここまでは一体どんな仕事を日々行っているかを分かりやすく説明する為に、非常にざっくりではありますが、全体の開発の流れを説明してきました。
次に、皆さんがよく聞くであろう役割について解説をしてみたいと思います。

この図は、どの役割がどんな工程をこなしているのかをわかり易くまとめたものになります。

それぞれの用語について、以下で簡単に説明していきます。

ITコンサルタント

さて、ITコンサルとプロジェクトマネージャ(PM)と言われる人たちを混同してしまう人が少なからずいます。
両者の一番決定的な違いは、ユーザー側のシステム構想策定段階から参画するかどうかです。
ITコンサルタントはクライアントが抱える経営課題や業務課題を解決することが目的であるため、クライアントの現状と課題を理解した上で、システムの企画段階から参画することになります。
実際には全体のスケジュール管理等も行う事がおおいので、そういう意味ではPMの上位職業と言い換えることができます。

プロジェクトマネージャー（PM）

サービスの実装方針、運用設計や、全体スケジュールを決め、プロジェクトを推進していく役割を担います。

基本的には管理職という立場ではありますが、現場で見ている場合はプレイングマネージャーとなっている人が非常に多い印象です。

このポジションは何か問題が発生した際の、お客様との折衝等も含め、窓口になる事も多く、また作業メンバーへの指示等も的確に行う必要がある為、非常に高いスキルを要するポジションとなります。

プロジェクトリーダー（PL）

全てのプロジェクトでこの役割を立てる事ないですが、大規模なプロジェクトになると、全体管理するにもPMだけでは無理が出てくることがあります。

そのような場合には、小規模なユニット単位でPLを立て、その取り纏め役としてＰＭを立てる事が多くなります。

PLの主な役目は小規模なチーム単位でのスケジュール管理や指示出し、成果物のレビューを行ったりPMに似た役割になる事が多いです。

システムエンジニア（SE）

基本的には顧客の要求からシステム仕様を決定して、大まかな設計をするまでの上流工程と言われる事が多いです。

プログラムの細かな仕様が理解できていなければ設計は出来ない為、多くの現場ではSE＋PGの役割で仕事をする人が多い印象です。

プログラマー（PG）

SEが設計した設計図を基に、プログラミング言語を用いて、システムを構築していきます。

このポジションはモノづくりが好きなエンジニアの醍醐味を味わえるので、好んでやりたがる人は多いのではないでしょうか？

主に新卒で入ってきた新入社員等に任されることが多く、エンジニアとしての第一歩を踏み出すための役割となります。

まとめ

今回はエンジニアという職業に興味があるけど、全く業界の事が分からない方向けの記事でした。

ITエンジニアという中にも実に多くの役割が存在します。

プログラマーとして、プログラミングを極めていく事を楽しみとする人や、より上流工程でサービス設計からチャレンジしてみたい人など、実に多くの価値観を持って人が存在します。

IT業界は人材不足の状態がこれからも長く続くと予想される業界です。

自分に出来るのかなと不安になる人もいるかもしれませんが、まずは一歩踏み出してみてはいかがでしょうか？