見出し画像

なぜ「エンジニア」を「プログラマー」と呼ぶと怪訝な顔をされるのか?

こんにちは、エンジニアのgamiです。

僕は仕事でもnoteでもYouTubeでも「エンジニア」を名乗っています。今の僕はかなり色々やっていて、世間一般のいわゆる「エンジニア」像からはたぶんズレています。一方で、そんな「色々」を受け止めてくれる寛容さが「エンジニア」という言葉にあるとも感じています。

実はIT界隈には、「プログラミングとかをしてそうな人」を指し示す職種名がたくさんあります。主には次の4つです。

・プログラマー
・コーダー
・デベロッパー
・エンジニア

多い上に、個々の違いもよくわからないですよね。たとえば「デザイナー」という職種を考えると、そこまで似たような職種名はない気がします。「〇〇デザイナー」という言葉はたくさんあるけれど、「デザイナー」自体を置き換える言葉はパッとは思いつきません。

「プログラミングとかをしてそうな人」を指す言葉がたくさんあるのはなぜでしょうか?そこには、いくつかの歴史的背景があるように思います。そして別々の言葉を当てられている以上は、それぞれの職種名がもつニュアンスも結構違います

僕は新卒で富士通の「システムエンジニア」になり、古き良き(?)システム開発の現場を目の当たりにしました。その後は「システム」を外してただの「エンジニア」としてスタートアップ企業に転職し、たくさんのエンジニアの話を聞きながらエンジニアのキャリアに関する発信を続けてきました。エンジニアの歴史を偉そうに語れるほど長く生きてはいないのですが、僕なりの視点で「IT技術者の呼び方多すぎ問題」について説明したいと思います。


IT技術者の呼び方多すぎ問題

まずは、それぞれの言葉のニュアンスの違いについて説明します。(人によっては少し感覚が違うこともあるかもしれません)

「プログラマー(programmer)」は、意味としては文字通り「プログラミングをする人」を指します。実際はプログラミングだけをしているわけではない人でも、「プログラミング」という行為に対してプロ意識を持っている場合に「プログラマー」を自称するということがあります。

一方、特に日本のシステム開発業界では「プログラミングという単価の安い作業をする人」というネガティブな含みをもって長らく使われてきた言葉でもあります。これについては後述します。

プログラマーと似た言葉として、「コーダー(coder)」という職種名もあります。「コーディングをする人」を意味し、「コーディング」とは「プログラムが記述されるソースコードを書くこと」なので、「プログラマー」と意味的にかなり近いです。一方で、「プログラムを組む」のと「コードを書く」という表現の比較から、「コーダー」の方が「単純作業をする人」という含みがある場合もあります。

ちなみに、主にWeb制作の世界で「コーダー」というと「HTML/CSSを書く人」を指すようです。ここにも「HTMLを書くというのは単純作業である」という暗黙の前提があるように感じます。近年はフロントエンド開発の重要性が増していることもあり、この文脈の「コーダー」の役割をより広く捉えて「マークアップエンジニア」とか「デザインエンジニア」と表現するケースが増えています。

「エンジニア(engineer)」という職種名は、「エンジニアリングする人」を意味します。「プログラマー」との対比でいうと、「エンジニア」には「別にプログラミングだけをするわけじゃないよね」というニュアンスが込められています。たとえばソフトウェア全体のアーキテクチャ設計やチームビルディングも「エンジニアリング」に含まれます。なお、実運用上はどこに専門性があるのかを明記して「〇〇エンジニア」と自称する人も多いです。たとえば「フロントエンドエンジニア」とか「ネットワークエンジニア」といった具合です。

ただし、「システムエンジニア(SE)」という言葉だけはどこに専門性があるのか聞いただけだとよくわかりません。この言葉は和製英語とされ、日本独自の職種名です。僕の中では「IT系総合職」の別名が「システムエンジニア」だと思っています。この「システムエンジニア」についても後述します。

他にも、「デベロッパー(developer)」という職種名があります。直訳すると「開発者」であり、「何かを開発する」というところに主眼があります。たとえば「ネットワーク」は一般に開発する対象ではないので、「ネットワークエンジニア」とは言うけど「ネットワークデベロッパー」とはあまり言いません。Androidアプリを作る人は「Androidエンジニア」とも「Androidデベロッパー」とも言います。また、エンジニア向けの製品やAPIを提供している会社からエンジニアに対して呼びかけるときには、大抵「デベロッパー(developer)」という呼称が使われます。

意味の広さでいうと、「デベロッパー」は「エンジニア」より狭く「プログラマー」より広いという感覚です。一方で、NoCodeツールの台頭によっていわゆる「エンジニア」じゃなくても「デベロッパー」にはなれますよという話もあります。ちなみにそうした非エンジニアのデベロッパーを「シチズン・デベロッパー」と呼んだりします。

上記をまとめると、次のような感じです。(繰り返しますが、人によっては少し感覚が違うこともあるかもしれません)

スクリーンショット 2021-02-15 6.31.58

「システムエンジニア」と「プログラマー」の身分制度

このnoteのタイトルにもあるように、プログラミングを主な仕事をしている「エンジニア」であっても、「プログラマー」と呼ぶと怪訝な顔をされることがあります。それはなぜでしょうか?本来であれば、エンジニアリングの中でも特にプログラミングに高い専門性を持ちそれを自負しているなら、「プログラマー」と呼んでもいいはずです。

実は、特に日本のソフトウェア産業においては「プログラマー」という言葉が不当に貶められた文脈で使われてきたという背景があります。

ソフトウェア開発において古くから採用されてきた開発プロジェクトの進め方に、ウォーターフォール・モデルと呼ばれるものがあります。開発プロセスの工程を分割し、左から右へ一方通行で工程を進めていくようなプロジェクト推進方法です。

スクリーンショット 2021-02-15 6.41.05

(「システム構築の標準プロセス体系: - Fujitsu」より)

ウォーターフォール・モデルの問題点は多く指摘されていますが、現代においても主にエンタープライズ向け受託開発を担うSIer(システムインテグレーター)と呼ばれるようなITベンダーで広く標準プロセスとして採用されています。ウォーターフォール・モデルが適していないプロジェクトであっても無理やりウォーターフォール・モデルを採用してプロジェクトが炎上したりしています。ちなみに僕が新卒で富士通に入った時も、SDEMというウォーターフォール型の富士通製標準開発プロセスについて細かい文字でプリントされた紙を研修で配られました。

エンタープライズ向け受託開発案件にはたくさんの開発者が従事するわけですが、その開発者たちはたいてい「システムエンジニア(SE)」「プログラマー(PG)」の2つに分けて扱われます。

「システムエンジニア」は、主にシステムの要件定義(何を作るかを整理する作業)、システム設計、プロジェクトマネジメントを担います。開発プロセスにおいても、基本的にはExcelで設計書を書くところまで関わり、実際のプログラミング作業はやらないことが多いです。この文脈では、「システムエンジニア」は主に複雑な頭脳労働を期待される高単価な人材として置かれています。

対して「プログラマー」は、降りてきた設計書をもとにプログラムに落とし込む作業を任されます。この文脈では、プログラミングはただの単純作業とみなされている節があり、「プログラマー」は単価が安い作業員として置かれています。

エンタープライズ向け受託開発案件の世界では、「システムエンジニア」と「プログラマー」との間に暗黙的な身分制度があります。実際、「この開発案件にはいくらかかりますよ」というのを提示する工数見積りでも、SEとPGの人月単価(1ヶ月働いてもらった場合のコスト)には大きな差が付けられています。

費用相場は、プログラマであれば安くて40万円から60万円程度システムエンジニアであれば安くて60万円~120万円程度となっています。費用はプログラマやエンジニアのスキルや開発規模によって決まる仕組みが多いようです。

(「システム開発会社の平均費用と料金相場を早見表で確認|業者比較と一括相見積りサービスのアイミツ」より)

また開発プロセスにおいても、システムエンジニアがトップダウンで決めた仕様や設計に対してプログラマーは口を出すことができないということがあったりします。そこにはITゼネコンと揶揄される多重下請け構造の問題も複雑に絡み合い、大変なことになっています。たとえば次の記事には、地獄のようなプログラマーの仕事が(たぶん少し誇張されて)描かれています。

この辺りの問題について話すと長くなりますが、こうしたエンタープライズ向けソフトウェア開発における分断やそれに付随する生産性の低下はかなり深刻な問題です。ちなみに、特にソフトウェア開発者が楽しく働けないような惨状は、僕がまさに強く課題に感じ変えようとしてきたものでもあります。

そんなわけで、「プログラマー」という呼称には「エンタープライズ向け受託開発案件に関わる単価の低い単純労働をする技術者」というイメージがこびり着いてしまい、言葉としての地位が下がってしまったわけです。悲しい。

プログラミングは単純労働か?

エンタープライズ向け受託開発案件では、プログラミングという行為は「設計書に書いてあることをプログラムに落とし込むだけの単純作業」とみなされ軽視されています

一方、ソフトウェア産業全体としては、「プログラミングの仕方次第でシステムや開発のパフォーマンスは大きく変わるよね」とか、「プログラムを書く中でより良い設計が明らかになることもあるよね」といったことが普通に言われています。つまり、よりよいソフトウェアを生産性高く作り続けることを目的におくのであれば、プログラミングという行為は非常にクリエイティブで重要なものであるとみなされています

たとえば、プログラムには「可読性」という評価基準があります。多くのプログラムは何年もの間、複数人でメンテナンスされ続けます。プログラムとしてちゃんと動いていても、人間にとって読みにくい書き方がされていると、読むのに時間がかかったり、既存の処理を誤解してバグが生じやすくなったりします。実際、僕が富士通時代に目にしたプログラムも大量のコメントにまみれた非常に読みにくいものでした。この「可読性」一つとっても、読みやすいコードを書くための書籍が出版されめちゃくちゃ売れ続けるくらい、重要視されています。

その役割はヒトで分断すべきか?

上述したような理由から、「プログラマー」という呼称を避けて、より曖昧で広い意味をもつ「エンジニア」という呼び方が好まれるようになってきました。

一方、「プログラマー」と「システムエンジニア」に限らず、「役割を人やチームで分断しすぎると対立が生まれたり個別最適化しすぎたりしてよくないよね」という動きはさまざまなところで起きています。たとえばDevOpsという言葉は「ソフトウェアの開発と運用を分断するのってよくないよね」という文脈から出てきています。

実際、現代のソフトウェア・エンジニアリングが直面する課題はかなり複雑化しており、単一の役割や工程だけでその不確実性を大きく低減するというのが難しくなっています。たとえば、「設計ですべて解決!」とか「プログラミングができればOK!」とか、そういう話じゃなくなっている。そんな中で、「エンジニア」という広い括りの役割定義だけをおき、その状況に応じて役割を柔軟に変えていくような働き方が求められるケースが増えています。「エンジニア」という呼称に支持が集まっているのは、「役割を限定しすぎるとよくない」という主張が浸透してきたことの現れでもあるように思います。

最初に挙げた「IT技術者の呼び方多すぎ問題」については、「IT技術者の役割範囲が繰り返し再定義されたことによって、時代とともに主として使われる職種名が変わってきた」というのが僕なりの直接的な回答となります。

以上が、 "なぜ「エンジニア」を「プログラマー」と呼ぶと怪訝な顔をされるのか?" という話でした。

ちなみに、別の話として非IT業界にも「エンジニア」がいる以上、「ITエンジニア」を単に「エンジニア」と呼ぶのは主語が大きく誤解を生むのでは?という議論もあります。この点についても軽く言及します。(このnoteの主題からはズレるので読みたい人だけ読んでください。)

この「ITエンジニアをエンジニアと呼ぶな」問題については、『エンジニアリング組織論への招待』の広木さんがTweetしていました。

この一連のTweetにはたいへん同意で、結局は程度問題であり、「ITエンジニアをエンジニアと呼ぶな」と発言する人の多くは批判すること自体が目的化しているように見えます。

一方、「プログラマー」がより広い「ITエンジニア」に包摂されたように、「ITエンジニア」を始めとするさまざまな「〇〇エンジニア」がより広い「エンジニア」という概念に包摂される世界もあっていいと思います。つまり、「エンジニアリング」という抽象化された行為に専門性を持っていて、それはWeb企業でも自動車メーカーでも映像制作会社でもある程度共通して求められる役割を指しているのだとすると、そういった人を指して広く「エンジニア」と呼ぶことには対して違和感が無い気がします。

たとえば「デザイナー」という職種は割とそうで、リアルの物をデザインする「プロダクトデザイナー」とWebサイトのUIをデザインする「Webデザイナー」は目に見える作業としては結構違う気もしますが、同じ「デザイナー」と呼ばれます。それに対して「Webデザイナーを単にデザイナーと呼ぶな」という批判はあまり目にしません。

つまり、「ITエンジニアをエンジニアと呼ぶな」という批判の裏側には、「エンジニアリング」という行為への理解がまだまだ広く成熟化した状態になっていないという課題があるように思います。それぞれの「エンジニア」が従事している具体的な行為に対するリスペクトがあり、その共通する役割を「エンジニアリング」という言葉で上手に束ねて表現することができれば、「ITエンジニアをエンジニアと呼ぶ」ことには何の問題もなくなるはずです。言語化大事。

ここから先は

0字
同僚と飲むビール1杯分の金額で、飲み会で愚痴るよりもきっと仕事が楽しくなる。そんなコラムを月に3〜4本お届けする予定です。

【初月無料】デジタル時代の歩き方について考えたことを発信します。ソフトウェアの時代とは何か。エンジニアの頭の中はどうなっているのか。NoC…

サポートをいただけると、喜びドリブンで発信量が増えます!初月無料のマガジン『仕事を楽しくするデジタルリテラシー読本』もおすすめです!