みなさま、こんにちは。システムエンジニアと聞くとどのような仕事内容を思い浮かべますか？きっと多くの人は、ひたすらPCに向かって黙々と作業する場面を思い浮かべるのでしょうか。
あながち間違ってはいないですが、現実はちょっと違います。今回は、システムエンジニアの開発系として8年以上携わり、採用面談も行ってきた私が
- システムエンジニア（開発系）の主な仕事内容とは？
- システムエンジニア（開発系）の業務に就くには？
のについてご紹介いたします。将来、システムエンジニアの開発系を生業にしたい方は是非参考にして見てください。
システムエンジニア（開発業務）の主な仕事内容とは？
開発業務の流れについては、以下の記事で詳しく紹介しておりますので省略いたします。
なので、「開発の流れ」ではなく「開発業務は何の目的で働くのか」と「開発業務はどのように働くのか」についてご紹介します。
システムエンジニアの開発業務の主な目的
まず、「開発」とは「0から成果物を作り上げ業務の効率化を図る」ことが主な仕事です。それをチームを組んで複数人で完成へと近づけていきます。
なので開発系の仕事は、よく「建設業」に例えられます。例えば、家を建てる事を想像して見てください。
意外と似てる？システムエンジニア（開発業務）と建設業
家を建てるには「建築主」「設計者」「施工者」の大きく分けて3つあります。
| 役割 | 目的 |
|---|---|
| 建築主 | 家を建てる計画を立てて資金調達や設計・施工業者を選定する。 |
| 設計者 | 建築主の要望を基に設計図を作成する。 |
| 施工者 | 設計図を基に実際に家を建てる工事をする。 |
システムの開発も同様、以下の役割が存在します。
| 役割 | 目的 |
|---|---|
| PM・PL | プロジェクトマネージャー・プロジェクトリーダー 上図の「建築主」に当たる役割。お客様の要望を聞いてシステム化するための開発人員の確保や選定、予算や工期を定める。その後は、設計者に要望を伝達する。また、お客様とのやり取りも基本はPM・PLが行う。 |
| 設計者 | PM・PLから降りてきた情報を基に設計書を執筆する。 上図の「設計者」に当たる役割。 |
| 製造者 （プログラマー） | 設計書を基にコードを書く。 上図の「施工者」に当たる役割。 |
そのほかにも、システムエンジニアには試験を行う人（テスター）や、完成したコードを実際にお客様（システムの発注者）が使えるようにする為の移行作業を行う人もいます。
しかし、「製造業」と異なる部分もあります。それは、「システム開発は兼任される事が多い」と言う点です。PM・PLは他の作業を行うと言った事は基本ないですが、それ以外の役割は兼任することが多いです。
（「設計書を書いた人が製造もする」や「設計書・製造・試験を全て同じ人がする」等）
システムエンジニアの開発業務の主な目的（まとめ）
開発業務について一言でまとめると、
お客様の業務効率化を図る為や問題解決の為、
複数人のエンジニアで協力し合いシステムを構築する
ことが開発業務の目的となります。
システムエンジニアの開発業務の主な働き方
まず冒頭でも少し触れた件（システムエンジニアは人と喋らず黙々とPCで作業してる）というイメージを持たれている件について触れましょう。結論、全くの逆です。もちろん、人とのコミュニケーションを必要最小限にとどめるエンジニアが多い事は否定しませんが、それでも最低限の情報共有は必要不可欠です。
意外と超重要？システムエンジニア（開発業務）のコミュニケーション能力
長年、開発に携わっていると立ち上げ直後のプロジェクトではコミュニケーションが上手く取れない方が多いと感じます。しかし、半年・1年・3年と時の流れに比例しコミュニケーションが上手く取れないと私が個人的に感じた人は徐々に減っていきます。
なぜか？それは、「開発業務は進捗の経過と共に必要人員が削減される傾向にある」からです。
新規プロジェクトの立ち上げ直後というのは、基本的に上級エンジニアが少数で回しています。上級のエンジニアがお客様との調整や要件を整理する作業は、プロジェクトの土台（建設業でいうところの土木工事）にあたり非常に重要な工程です。
しかし、その重要な作業を終えたあとは、とにかく手を動かす事が重要になります。その為に人員を多く確保します。誰でも作業できる簡単な内容だったら初級・中級レベルのエンジニアでも事足りる為です。
手を動かす事が重要になる工程は主に「製造（コーディング）」と「試験（単体・結合）」です。ここまでは最低限の知識を付けたエンジニアなら基本的には誰でも作業を任されます。ただし、「試験（総合）」工程まで進むと、すべきタスクは段々と減っていきます。
「タスクが減る」という事は「必要人員も減る」ということになります。なので、今いるエンジニアの契約を切っていくことに繋がります。では、誰から切っていくのか。それは「能力の低い人間」から切っていきます。当然ですよね。
では、何をもって「能力の低い人間」と言うのでしょうか？それは、「コミュニケーション能力の低い人間」と言い換える事ができます。もちろん、例外的にシステムエンジニアとしての能力が突出して上級な人材は契約を切られるという事はないかもしれませんが、これは例外中の例外です。
どれだけシステムエンジニアとしての能力が高くとも、他者と連携が取れなければ宝の持ち腐れです。前章で建設業を例に出しましたが、これも同じです。家を建てる為に複数の建築士が集まり家を建てようとしている中、1人の人間が勝手な行動をしているとどうでしょう。
- 人員管理ができない
- タスク管理ができない
- 身勝手な行動をされると全体の士気が低下する
など、例を挙げるとキリがないですが仕事が上手くいく訳がありません。なので、8年以上開発の現場に携わっている私の感覚ではありますが、とにかく「コミュニケーション能力が低い人間」から現場から居なくなっているように感じます。
システムエンジニアの開発業務の主な働き方（まとめ）
日によっては、1人で黙々と作業をするフェーズもありますが、基本的にはメンバー同士の連携が必要不可欠です。（上述しましたが。製造・試験工程では人と喋る回数は比較的少なく、手を動かす事の方が多い印象です。）
「システムエンジニア ＝ コミュニケーションが苦手」のイメージを持たれがちですが、開発はその逆。非常に重要なスキルです。将来、開発系を目指されている方はこのスキルを是非身につけておいて下さい。
システムエンジニア（開発系）の業務に就くには？
ここまで鬱陶しい位に紹介してきましたが、大前提として「コミュニケーション能力」が問われます。その上で、私が過去採用面談で意識してきたポイントを、優先順位別にご紹介いたします。
- SQLの経験値
- プログラミング言語の経験値
- 保有資格
採用基準第1位（SQLの経験値）
システムエンジニアの開発系は、兎にも角にも製造力が最も重要なポイントです。経歴20年以上の方は製造力が無くても、PM・PL経験を評価されて採用されることがあります。一方若手は、製造力がどうしても重視されやすい傾向にあります。
製造力の中でも特に重要視しているのは「SQLの経験値」です。SQLというのは、プログラミングと違い土台が無い人間は実務でSQLを使いこなす事はほぼ無理です。いや、絶対無理です。
なぜ、そう言い切れるかというと「SQLは各種PG言語と違い、記述する際にイメージし難い」からです。更にいうと、単純なCRUD（「INSERT」「SELECT」「UPDATE」「DELETE」）を使いこなせる事は当然であり、その他にも必要なスキルが多々あります。例えば、、、
- SELECT結果の並べ替え（「ORDER BY」）
- SELECT結果の集約や、その集約結果に対する抽出条件（「GROUP BY」「HAVING」）
- SELECT結果の結合（「UNION」「UNION ALL」）
- テーブル結合（「LEFT OUTER JOIN」「INNER JOIN」「FULL OUTER JOIN」）
- 存在チェック（「EXISTS」）
- PKとは何か
- INDEXとは何か
などなど、列挙するとキリが無いですがSQLに携わる前に必ず知っておいて欲しい事としてパッと書き出しただけでも7つあります。それに加えて、SQL（DB操作）に関する知識として
- トランザクションとは何か
- コミットとは何か
- ロールバックとは何か
- トランザクションの役割により受けられる恩恵は何か（トランザクションの目的とは何か）
- テーブルロックとは何か
- レコードロックとは何か
- デッドロックとは何か
の7つの知識も必須になってきます。これらの知識を開発現場に参画してから教え込むのは、出来ないわけでは無いですが、教える側も教わる側も非常に体力を使います。
その為、私が採用面談をする際は必ずSQLの基礎知識を問うようにしています。もちろん、SQL知識が乏しくても他の知識が突出していれば、（非常に稀ですが）採用することもあります。
採用基準第2位（プログラミング言語の経験値）
PG言語の経験値はあくまで参考程度に伺っています。と言うのも、PG言語は「java」「javaScript（jQueryやReact）」「python」など数多く存在しますが、PGのロジック自体はほぼ一緒です。
何が違うかというと、「分岐やループ等の書き方が若干違う」「目的が違う」というレベルのため、どれか1つでも使いこなせる言語があれば他の言語は見様見真似で何とかなるものです。
その為、採用基準にはしているものの、どれか1つでも勉強していれば（出来れば何かしらの成果物を作り上げた経験があれば）OKとしています。
PG言語に触れた事が全く無い方は、やや厳しい傾向にあります。しかし、それを上回るくらいのコミュニケーション能力があれば採用することもあります。
なぜなら、SQLとは異なり処理が上から順に実行される点でイメージし易く、本気で取り組めばPG言語未経験でもメンバーへの相談・google検索・chatGPTに頼れば何とかなるからです。
採用基準第3位（保有資格）
正直なところをいうと、私は資格について一切評価しません。なぜなら、資格というのは資格勉強さえ頑張れば取得できるからです。そして、資格勉強中に得た知識を実務で使う事は経験上ほぼありません。
しかしながら、「目的のために努力できる人間」という点で評価されることもあります。そして、世の中の採用担当者の多くは一番最初に「保有資格」に目を通す傾向にあります。資格というのは客観的に評価し易く、採用担当者も上長の方から「何で採用したの？」という問いがあれば、「資格を持っているから」と言うのも理由の1つになり説明し易くなります。
ある意味、資格というのは「開発業務に携わるための登竜門を低くする事ができるかもしれない」秘密道具のようなものです。私は「IT系の資格を持っている ＝ 現場で活躍できる」にはならないことを身に染みて理解しているので一切評価しませんが、現場で作業した事のない採用担当者であれば目を欺く事ができるかもしれません。
一応、持っていれば採用確率が上がるかもしれない資格をリストにして紹介します。
- 基本情報技術者（FE）
- 応用情報技術者（AP）＜基本情報の上位互換＞
- Java Silver：受験料は高いが、PG経験は評価されるかもしれません
- python3エンジニア：Java Silver同様、PG経験は評価されるがJava Silverよりは劣ります
- OSS-DB：DB（PostgreSQL）の基礎知識について理解していることを証明できます。
上記資格はあくまで参考程度に留めておいて下さい。
まとめ
これまでIT（開発系）の主な仕事内容や、私が採用基準としている内容についてご紹介してきましたがいかがでしたでしょうか。しかし、これはあくまで現場への採用経験がある私個人の意見であり、他全てがそうではありません。
しかし、これだけは確実に言える事があります。それは、「採用担当者が現役で現場にいる場合、一緒に働きたいか否かが鍵になる」ということです。実際、現場への参画前に軽い業務説明を受ける事があります。その時に「この人と働いてみたい」と思わせることも大事です。（EQレベル）
もちろん、採用担当者が現役で現場にいることが当たり前と言う訳ではありません。その場合は、上述したシステムエンジニア（開発系）の業務に就くには？が重要になると思いますので是非参考にしてみて下さい。
ここまでお読み頂きありがとうございます。参考になったことや、現役エンジニアの方で共感いただける部分があれば、是非他の方にもシェアしてみて下さい。
