僕はイーロンマスクとか、スティーブ・ジョブズに憧れて、エンジニアになりました。
けど、実際にエンジニアとして働いてみると、エンジニアをプログラマーとして捉えてる人がまあまあおり、ギャップを感じました。(Web系でもそういう人が一定います!価値を作る仕事はビジネスサイドみたいな認識をしてるのです(驚))
僕にとって、エンジニアとは「技術を用いて、実現できるあるべきを定義し、その設計を行い、実装をする」人だと思っています
皆さんにとってのエンジニアとはなんでしょうか?
ぜひ皆さんの意見をお聞かせください!
気になる質問をクリップする
クリップした質問は、後からいつでもMYページで確認できます。
またクリップした質問に回答があった際、通知やメールを受け取ることができます。
回答15件
#1
総合スコア118509
投稿2026/07/02 01:59
私の認識ではアイデアを成果物に落とし込む技師です
#2
総合スコア197
投稿2026/07/02 02:59
編集2026/07/02 02:59質問者さんと同意見で、自分にとってエンジニアとは、「何を作るべきかを定義し、それを設計し、実装まで持っていく人」です。プログラミングはその一部でしかなくて、むしろ「あるべきを見極めて形にする」ところにエンジニアの本質があると思っています。
建築でたとえると、施主の要望を聞いて理想の家を図面に落とし込むのが建築士、その図面通りに建てるのが大工さんですよね。世間ではエンジニア=大工(図面通り作る人)だと思われがちですが、本来のソフトウェアエンジニアは建築士と大工を兼ねている存在だと思っています。だから私は、エンジニアを単なるプログラマーとは捉えていません。
#6
総合スコア2163
投稿2026/07/02 12:00
「プログラマは下で、エンジニアは上」みたいな整理にはちょっとモヤりますね。
ビジネス的な世界としてはそうなんでしょう。役割が広がるにつれて肩書きもインフレして、「プログラマ」→「エンジニア」→「アーキテクト」→「CTO」みたいに「偉そうな肩書」が増えていくのは、組織の都合としては自然です。そうやって価値ある人間と思わせてよりたくさんカネをふんだくるわけだし、若手には「お前はまだプログラマレベルだから」と言って低賃金で働かせる、みたいな構造も現実としてはあると思います。
ただ歴史的には1980年代くらいに「賢い大卒エンジニア (SE) が設計して、高卒プログラマ (PG) が黙々と実装する」という分業モデルがあったかと思います。いわゆる工場モデル的な考え方です。でもこれは実際にはあまりうまくいかなかった。ソフトウェアは作ってみないと分からないことが多く、設計と実装を完全に分けるとむしろ破綻しがちでした。結局「ここ設計違いましたね」となって、実装側も普通に設計に関与しないと成立しないこともよくあります。
その後はOSも言語もツールもどんどん進化し、クラウドのような技術も登場して、むしろプログラマが触る範囲は広がっていきました。昔はインフラやOSの下の層はブラックボックスでしたが、今はそこもコードで扱うことができ、IaCのように“ほぼ全部コード”のような世界になっています。
一方、Ken Thompson、Dennis Ritchie、Richard Stallman、Steve Wozniak、Linus Torvalds のような人たちに対して「彼らは優れたエンジニアだ」と言うのも間違いではありませんが、ハッカー文化の感覚で言うなら「彼らは最高にクールなプログラマだ」の方がしっくりきます。
ここでいうプログラマは「設計書どおりにコードを書く人」という意味ではなく、コードを書きながら設計を変え、システムそのものまで作り替えていくような人のことです (この人たちは世の中まで変えてしまいましたが)。
会社で使われる肩書きとしては「プログラマ<エンジニア」という整理も一つの現実ではありますが、そうではない見方もある、という話です。
#7
総合スコア302
投稿2026/07/02 23:51
機械に対して意味不明なことをしてお金を貰う人の事だと思います
「技術を用いて、実現できるあるべきを定義し、その設計を行い、実装をする」
コミュニケーションだったり、スケジュールを立てること、日常で起きうる全ての問題は技術で解決したり、設計、実装することが可能なのでこの定義は私はあまり歓迎しません。
ようは全ての人がエンジニアということになる。
#8
総合スコア86
投稿2026/07/07 03:58
米国では理工系の学部卒と定義されています。
日本では、エンジニアの意味が曖昧です。理工系の大学を出ていなくてもエンジニアと名乗っている人が多いです。
元々、シリコンバレーのVCがどの企業に投資するかを決める基準で「Computer Science(CS)か類似の学位を持ったエンジニアを多く抱えているベンチャー企業に投資すると成功する可能性が高い」というデータを元に投資をします。IT企業も理工系大卒のCS専門者を高い給料で採用していきます。米国移民局でも、CSと類似の大学専門の学位を持ったエンジニアは労働ビザを出す方針とします。労働ビザには明確な資格基準がないと、不法移民で溢れてしまうので、大卒という基準を採用します。ITパスポートのような一回試験では不正受験者を判定できません。
アメリカの高校では、EngineeringかScienceと付いた大学の学部に行くには、代数、幾何、物理などのAPテストを合格する必要があります。数学が苦手な生徒は、この理系科目のテストをあきらめてビジネスや文学などをメジャーにします。彼らが、エンジニアを名乗る事はありません。高校でEngineeringを専攻しないと決めているのに、Engineerと名乗るのはためらいます。どうしてもEngineerになりたければ、大学の夜間コースに行きます。ここが日本との違いです。
仮に大学卒業後に1年間プログラミングスクールを取っただけでエンジニアと履歴書に書いても、米国IT企業では面接もできません。
#10
総合スコア7816
投稿2026/07/07 14:51
黙っていようかとも思ったけど、なんとなくそっち方向の雰囲気にもなってきたから...なかばお約束のツッコミかもしれませんけれど一応。「エンジニア」が無条件にIT系だってのはIT屋さんの内輪だけの話です。世の中では、エンジニアってのは工学を修めた技術者なので、電気電子機械建築自動車航空造船にバイオとか、いろんな分野のエンジニアが居ますからね(自分もソフト屋というよりは根っこはエレクトロニクスのエンジニアにあるつもりなので)。まぁ、この場はそもそも内輪だからそこは省略でもいいと思いますけど。(エンジニアとテクニシャンと...とか言い出すとまた面倒)
#11
総合スコア22
投稿2026/07/07 15:09
エンジニアと言ってもいろんな業界での肩書があるので、(IT・機械・電気・建設etc)スキルシート等でよく目にするSEとPGの違いについて述べると、SEはシナリオを作る側の人でPGはそのシナリオにそってシステムやプログラムを作る・組み上げる人のことを指しているとよく言われています。
仕事の分担で言えばSEの方が広範囲を任されることが多いため、年収もその分高めの傾向になります。
冒頭で触れられたイーロン・マスクはテスラやスペースXの設立に関わっている点で、個人的にはエンジニアというより起業家のイメージですね。就職活動中の学生にとっては尊敬に値する人物ではないでしょうか。私たちの時代は孫さんという意見が多かったですが。
一方で、スティーブ・ジョブズについてはApple社を解任されたのにいつの間にか戻ってきてiPhoneやらiPodやらを世に送り出す日本産業にとって大打撃を与えた危険人物だと個人的には思います。どれだけ苦しい状況に置かれてもあきらめない姿勢だけはすばらしいと評価できますが。
PanaのD-Snapとか東京芝浦電気のGIGABEAT、ガラケーを消し去った輩ですから...
#12
総合スコア316
投稿2026/07/08 02:57
エンジニアとは「技術を用いて、実現できるあるべきを定義し、その設計を行い、実装をする」人だと思っています
ここにあるように、自分は質問者さんがこうなりたいって思うものを目指せば良いと思います
https://www.weblio.jp/content/%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2
weblioに記載されているエンジニアの意味を調べると
「engineer」とは、技術者・工学者・技師などのことを意味する英語表現である。
動詞として使われる場合もある。その際には、たくらむ、工作する、設計するなどのように使われる。
「engineer」は、中期英語のengineour(エンジニア)が語源とされている。印欧語根で出産するという意味を持つgenh-から始まり、ラテン語のin-+gigno(生まれる)+-ium(名詞)が合わさることによって、機械やエンジンを意味するingeniumになる。ingeniumに動作をしている者を指す-atorを合わせて、機関を作る人を意味するingeniatorとなり、古期フランス語のengigneorを経て、engineourとなる。
このようなことが書かれています。
企むって言葉もあるので、他の方々の意見で議題に上がっている創業者やPdMがエンジニアかどうかの論争において、自分としては、創業者やPdMもエンジニアとして扱う場面あってもいいなっておもいます。
ただ、創業者やPdMがエンジニアか否かと簡単に定義できるほどシンプルでもない気もしています。
質問者さんが上げている、ジョブスやイーロン・マスクは、技術領域(IT、ソフト、ハード、機会など)の企業(プロダクト、サービス)創業者です。
一方で、ホテル事業, 飲食事業, 小売事業の領域での創業者になると、エンジニアではなさそう...となります。
もちろん、技術領域でもプロダクトをどう売るかをメインに考えていれば、エンジニアではないなとも思います。
置かれているコンテキストによって変わるので、既存のカテゴリで判別するの難しいなって感じです。
結局何が言いたいかで言うと、「何がエンジニアで、何はエンジニアではない」という線引は人それぞれ意見があっていい話(正直本質ではないはなし)で、質問者さんが「こんなエンジニアになりたい!」があれば勝手にそうなるように自身の中で線を引いて目指せばよいのではと思います!(そういう意味でとても考えさせられる良い問でした!笑)
そしてその境界は強要するものでもないと思います。
ただ難しいのは、自分のこうなりたいと世間からのニーズで、理想と現実は少なからずありますし、ことエンジニアにおいてはこの求められる"現実"は技術の発展によって大きく変わっていってるので、固執せずその時時で内発的に動機づけして、楽しくものづくり続けれたらいいなって自分は思いました(最後感想になっちゃいました笑)
#13
総合スコア86665
投稿2026/07/09 16:50
ITエンジニア(以下エンジニアと略記)とは何かですが、お書きの「技術を用いて、実現できるあるべきを定義し、その設計を行い、実装をする」に違和感はありません。
私はそれよりも広く、「{IT技術を使って|IT技術のスキルを使って}、{課題を解決する|顧客に価値を提供する}人」位ですね。実装は必須と思っていません。実装より設計がポイントだと思っています。
要件定義から機能の設計や実装方法の設計までをして、実装は外部委託している人もエンジニアでしょう。まあ、「時間さえあれば自分で実装できるスキル」は期待します。
こういう人を「自分で実装してないからエンジニアじゃない」と言っちゃうと、AIにコードを書かせている人もエンジニアでなくなってしまいます。
要件だけをAIに伝えてコードを書いてもらい、コピペで実行して、エラーになればエラーメッセージをAIにコピペしたり、期待通りの動作じゃないときは、入出力データとか、画面コピーをAIに渡して解決を依頼して、結果をまたコピペで実行しているような人がエンジニアなのか?
設計は何もせずに要件だけをSIベンダーに丸投げしている企業のシステム部門の人がエンジニアなのかどうか?
という事で、「実装は委託している」「AIにコード書かせている」という外形的な判断だけで、エンジニアかどうかは判断できないと思います。委託先やAIとの間でどういうやり取りをしているかによるでしょう。
創業者かどうかと、エンジニアかどうかも、独立の概念だと思うので、IT企業の場合でも、エンジニアの創業者もいるし、エンジニアでない創業者もいるでしょう。
また、創業の頃はエンジニアとしての仕事をしていたけど、会社が大きくなってエンジニアとしての仕事をすることが出来なくなった人を、「エンジニア」というのか「元エンジニア」というのか。
こういう話と別に、職種をいくつかに分類して、その一つに「エンジニア」とうラベルを貼るという話もあると思いますが、その場合には「この分野の仕事について、こういう風に分割して、そのうちのこれがエンジニア」という前提の共有が無いと他人と話できません。
#14
総合スコア7816
投稿2026/07/09 22:03
しつこく他業界の話をするなら、
建築のエンジニアは設計をするけど、現場で建築物を建てる作業者をエンジニアとは言わないし
テレビの(PCでもいいけど)製品の設計をエンジニアはやるけれど、工場のラインで組み立てたり検査する人はエンジニアとはいわないし
バイオ系で、実験計画とか立てるのはエンジニアだけど、実際に薬剤使ったり培養したりするのはまぁテクニシャンかな。
まぁ、いずれもエンジニア自らやっちゃうこともあるし、業界毎に区分に違いがあってもいいけれど。
「言葉」だから、あまり自由にオレオレ定義して他人の認識と乖離した意味を載せちゃうとコミュニケーションに齟齬を来したりもしそう。
#15
総合スコア1482
投稿2026/07/11 04:15
課題を明確にして、その課題を解決するための手順を具体化する人をエンジニアという認識です。
その手段がITならITエンジニアだし、建築なら建築エンジニアということになるのだと思います。
実現できなかったり、非効率な手順をアウトプットするエンジニアが、巷で「実装できないエンジニア」とか言われている人なのでは。
あなたの回答
tips
太字
斜体
打ち消し線
見出し
引用テキストの挿入
コードの挿入
リンクの挿入
リストの挿入
番号リストの挿入
表の挿入
水平線の挿入
プレビュー
質問の解決につながる回答をしましょう。 サンプルコードなど、より具体的な説明があると質問者の理解の助けになります。 また、読む側のことを考えた、分かりやすい文章を心がけましょう。