いろんなところの議論の火種となるのがIT業界の役の名前とカテゴライズです。

ひとくちにシステム開発といってもいろんな作業があるため、その分担によって呼び分けるわけなのですが、 統一した呼び方がないのが困りもの。
さらに契約上の名目とか、特定の企業やグループでの役職とかが混在して混乱を極めています。

よく火種になっているのはPG(プログラマの略だと思われる)とSE(システムエンジニアの略)ですね。 某企業グループではPG → SEという順で昇進するため、役職としてのPG、SEというものがあり、 役割としてのPG、SEと混用して炎上、というケースが散見されます。

そのような特定の企業文化圏ならではの特殊事情はさておいて、役割として以下のようなものがあります。

そして、このあたりの役割の境界線が非常にあいまいなので、混同して議論にならないことがよくあります。

PG・SE論争とは何か

SEとPGの確執というのは結構ネタにされるわけですが、役割としてのPG、SEというものは、 それぞれが別種の技術を要し、かつ互いの仕事を分かっていないといけないものにもかかわらず、 一部企業グループの役職としてはPG → SEという昇進の仕方をするため、 プログラムを理解しないSEが役職的に下となるPGに文句を言って炎上というワンパターンの展開です。

とくに一部の企業ではプログラミングより要件定義の方が仕事として上という根拠のない序列 がまかり通っていて、無能なSEを量産したところ、一緒に働くPGが割りを食っているという状況です。
今でも要件からコードに直すのなんて誰でもできるだろうという誤った考えは広くあるようです。

そんなプログラマたちが自分たちのやっていることは高度な技能職なのだということを言いたいがために 「要件定義にしたがってコードを書いているだけ」という下級職をくくりだしたのがコーダ。
ですから、積極的に「私はコーダです！」という人はおらず、蔑称のように使われることが多いように思えます。

SEについても、業務要件を分析して要件開発を行う分野を特にアナリストと呼び分けますが、 私はいくつか回ったプロジェクトの中でそのように呼ばれている人を見たことがありません…。

いずれにせよ、よいプログラマは要件定義を考えてプログラムすることができ、 またよいSEはプログラミングを考えて要件を定義することができるわけで、 やれ一方がよいだの悪いだのというのは非常に低レベルな水掛け論にすぎません。 優秀な人はどちらもできるんだもの。

PG・SE論争の正体は、役職としてのSEについた役職コンプレックスの人間が、 自己の地位が上位であるということを言って満足を得ようとしたイタイ発言を火種に、 実際はそういうものではないという主張が火に油を注ぐというものなのです。 役割としてのPG・SEと一部企業ローカルの役職としてのPG・SEを混同することから起こります。

アーキテクトは近年でてきた呼び方ですが、本当に必要な人材は、プログラミングにも要件定義にも精通していて システム全体を設計できる技術者であることから、この上級職を呼ぶ名称として新たに設けられました。 それまでは、プログラミング技術やシステムアーキテクチャがあまりに軽視されていたため、 技術者の地位向上のための象徴のような役職です。 そのためアーキテクトという称号は非常に高度化され、容易に名乗ると罵倒されそうな名乗りがたいものになっていますね。