「あぁ、エンジニアやってるよ」
知人から「今どんな仕事してんの？」と聞かれたとき、私はそう答えていました。
未経験でIT業界に転職し、最初に担当したのはプログラムの実装。つまり、主にコードを書いて動かす仕事です。しかし、わざわざ「プログラマー」とは名乗りませんでした。
なぜか。
「エンジニア」のほうが、なんとなくかっこよく聞こえると思っていたからです。
実際、「エンジニアやってる」と話すと「すごい、かっこいい！」と言ってもらえることもありました。私もその反応をちょっと期待していたんです。なんとも正直な話です。
当時の私の頭の中では、エンジニアが上で、プログラマーが下。まるでゲームの上位職と下位職のような関係になっていました。
ところが今の職場で、以前の仕事を聞かれて「アプリケーションの実装をしていました」と話すと、「プログラマーやってたんだね」と言われることがあります。
間違ったことを言われたわけでもないのに、なぜか少しムッとしてしまう私。自分でも不思議です。
実装が中心だったのは確かです。でも、画面の動作や処理を具体化する、フロントエンド側の詳細設計書にも手を加えていました。「プログラマーだけど詳細設計もやってました」と説明すればいいのか。それとも、実装が中心ならやっぱりプログラマーなのか。
そもそも、エンジニアとプログラマーの違いって何なんだ？
この疑問を解消するために、エンジニアとプログラマーの仕事内容を調べながら、昔と今の自分の仕事を比べてみることにしました。
プログラマーとシステムエンジニアは何が違う？
先に結論です。 「エンジニア」は技術者を広く指す言葉で、「プログラマー」はその中でも主にプログラムを作る仕事をする人です。IT業界でよく比較される「システムエンジニア（SE）」は、何を作るか整理して設計する仕事が中心。一般的な役割には違いがありますが、実務では担当工程が重なることもあります。
まずは言葉と仕事内容を整理します。
「エンジニア」は、技術者を指す幅広い呼び方で、 IT業界に限らず、建設や機械など、さまざまな分野でも使われる言葉です。一方、私がここで比べたいのは、主に「プログラマー」と「システムエンジニア（SE）」です。
厚生労働省の職業情報提供サイト「job tag」では、大まかに次のような仕事が紹介されています。
- プログラマー： 設計をもとにプログラムを作り、動作をテストし、問題があれば調べて修正する。
- システムエンジニア： どんなシステムが必要かを整理する「要件定義」や設計を行い、開発・テストにも関わる。
参考：job tag「プログラマー」、job tag「システムエンジニア（Webサービス開発）」
仕事内容を同じ軸で比べると、違いが見えやすくなります。
| 比べる点 | システムエンジニア（SE） | プログラマー |
|---|---|---|
| 主な役割 | システムに必要な機能を整理し、作り方を設計する | 設計をもとにプログラムを作り、動くようにする |
| 中心となる工程 | 要件定義・基本設計・詳細設計・開発やテストの確認 | プログラミング・単体テスト・不具合の調査と修正 |
| 仕事の成果物の例 | 要件定義書・設計書など | ソースコード・テスト結果・保守のための資料など |
※一般的な役割の目安です。すべての会社で完全に分かれるわけではありません。
ここだけ読むと、「SEが考えて、プログラマーが作る」という役割分担に見えるかもしれません。
しかし、同じjob tagには、プログラマーの仕事として「詳細設計書を作成する」ことも挙げられています。反対に、システムエンジニア自身がプログラムを作成する場合もあります。
つまり、職種名だけで『設計する人』『コードを書く人』ときれいに線を引けるわけではないんです。
そして、ここからが私自身の話です。
コードを書く前に、考えることが山ほどあった
IT業界に入って最初の頃、私はフロントエンド、つまり利用者が操作する画面側の実装を主に担当していました。
それに加えて、私はフロントエンド側の詳細設計書にも手を加えていました。当時の詳細設計書は画面側とバックエンド側に分かれていて、私が主に扱ったのは画面側です。コードを書く仕事と設計書に関わる仕事が、私の現場ではつながっていました。
プログラマーの仕事は、設計書に書かれた内容をコードにする。
そう聞くと、すでに答えがあるものを入力する作業のように感じるかもしれませんが、少なくとも私の現場では違ったのです。
そのため、「この機能を、どう書けば実現できるんだ？」というところから自分で考える必要がありました。
「チェックボックスが面倒」から始まった改良
例えば、ある画面には、複数の項目をチェックボックスで選び、確定ボタンを押して処理を進める機能がありました。しかし、項目を一つひとつ選ぶのが面倒だという声がありました。
そこで考えたのが、ドラッグ＆ドロップで項目を別のボックスへ移したり、Shiftキーを押しながらクリックして複数の項目をまとめて選び、移動させたりする操作でした。どうすれば使いやすくなるか、アイデアを出しながら実装まで進めました。
欲しいのは「ドラッグ＆ドロップ」という技術そのものではありません。複数の項目を、もっと楽に選んで動かせること。 そのための操作を考えてから、JavaScriptで実現していく。コードを書く前にも、考える仕事があったのです。
そしてもちろん、動けばそれで終了、ではありません。
後から読んでも分かるコードか。余計に複雑になっていないか。別の人が修正しやすいか。
考えながら実装して、調べて、動かして、うまくいかなければまた調べる。ようやく動いたと思ったところで、思いがけないエラーに出くわすこともあります。
ときには原因の分からないエラーで丸一日が過ぎたり、突然の設計変更に「今更言うなよ・・・」と思ったこともありました。
キーボードを打っている時間だけを切り取れば、たしかにコードを書いています。しかし、その裏ではずっと思考を巡らせています。完成したプログラムには、その試行錯誤が詰まっているんですよね。
振り返ってみると、当時の私の仕事は、ただ動くコードを実装するだけではありませんでした。
ユーザーのニーズに沿った機能を実現する仕事だったんです。
プログラマーがいつも要望の整理から担当する、という意味ではありません。ただ、私の現場では「こうできたら便利」という声を聞いて、方法を考え、実装するところまでがつながっていました。
今の仕事と比べると、違いが見えてきた
現在の私は、実装よりも要件定義や総合テストに関わる仕事が中心です。
要件定義とは、これから作るシステムに何が必要かを整理する工程。総合テストは、個々の機能だけでなく、システム全体が想定どおり動くか確かめる工程です。
以前と今とで、私の仕事を並べてみると、こんな違いがあります。
| 比べる点 | 実装を担当していた頃 | 現在 |
|---|---|---|
| 主に関わる工程 | フロントエンドの実装・詳細設計書への追記 | 要件定義・総合テスト |
| 主に考えること | 機能をどう実現し、どう直すか | 何が必要で、どう確かめるか |
| 仕事の進め方 | コードを調べ、書き、動作を確認する | 要求や仕様を整理し、システム全体の動作を確認する |
※あくまで私自身が経験した仕事の比較です。すべての会社で同じ役割分担になるわけではありません。
昔は「どう作るか」を考える時間が多く、今は「何を作るか」「正しくできているか」を考える時間が多い。私はそう整理すると、自分の仕事の変化を説明しやすくなりました。
ただし、先に述べたとおり実装中にも設計に近い判断はしていましたし、SEがコードを書くこともあります。
やっぱり、職種を二つの箱に分けて、境界線をピシッと引くのは難しそうです。
数年前の自分へ。プログラマーは下位互換じゃない
こうして振り返ってみると、当時の自分に言いたいことがあります。
「プログラマーは決して、エンジニアの下位互換などではない。自信を持って己の職業を名乗れ。」
上流工程を担当する人にも、実装する人にも、それぞれ難しさがあります。どちらか一方が偉いという話ではありません。
そもそも、どれだけ立派な設計を考えても、それが実際に動く形にならなければ、使う人には届きません。私自身、分からないことを調べ、エラーに悩み、何度も考え直してきました。
そんな仕事をしていたのに、なぜ私は名前だけで「下」だと思っていたんでしょう。
当時は「エンジニアだ」と言って、自分をかっこよく見せたかった。でも、あの頃の仕事だって十分に胸を張れるものでした。
かっこいいですよね。プログラマー。
結論｜エンジニアとプログラマーの違いは、担当する仕事の範囲にある
ここまでを整理すると、エンジニアは技術者の広い呼び方で、プログラマーはその中でもプログラムの実装を専門とする職種です。そしてIT業界でよく比較されるシステムエンジニアは、要件定義や設計を中心にシステムの開発を進める仕事。一般的には、仕事の中心となる工程が違います。
しかし、SEがコードを書くこともあれば、プログラマーが詳細設計書に関わることもあります。両者は上下関係ではなく、現場によって仕事が重なる職種なんです。
今なら、以前の仕事について聞かれたとき、こう説明できます。
「最初は主にプログラムの実装をしていて、機能の実現方法を考えたり、エラーを調べて修正したりしていました。今は要件定義やテストに関わる仕事が中心です」
これなら、エンジニアなのかプログラマーなのか、肩書きだけで背伸びする必要はありません。
今回、エンジニアとプログラマーを見分けるために、私は次の三つが大事だと思いました。
- 自分はどの工程に関わっているか。
- そこで何を考え、何を決めているか。
- 最後に何を形にし、何を確かめているか。
名前が一つに決まらなくても、自分がやった仕事を説明できれば、それは十分に意味のあることだと思います。
あの頃の私は、「エンジニアです」と言うと少しかっこよくなれた気がしていました。
しかし、かっこよさは名札ではなく、仕事の中にあったのだと気付きました。
ここまで読んでくださり、ありがとうございました。
コメント