ソフトウェア受託開発の世界では、よく PG(プログラマ) と SE（システムエンジニア)を区別します。SE が要求仕様をまとめて設計書を作り、PG がそれをコーディングするとのことですが、そんなにコーディングって簡単でしょうか？実装方法によって、パフォーマンスや保守性はまったく違ってくるし、それで工数は大きく変わってくると思うのですが。
しかし、SEの地位（報酬) > PGの地位(報酬)が現実です。この事実について、みなさんはどうお考えか意見を聞かせてください。
No.1
508
34
15pt
http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=30693&am...
コーディングは大変です。簡単ではありません。
ただ、SEは要求仕様を作成できるということは、PGの仕事の内容がわかっている（はず）が前提だからではないでしょうか。
また、年を取ってくるとPGの報酬では給料分にあわない（稼げない）ので、SEになって、金を拾ってくる仕事に回るのだと、昔先輩に言われたことがあります。
No.2
23034
15pt
以下の二つの理由が思い浮かびました。
ＳＥは、理科系的（技術的）能力に加え、ＰＧ以上に文科系的能力を要求されます。両方の能力をバランスよく備えるのは難しい為、希少価値があります。
ＳＥよりもＰＧの方が人数が多く必要です。多く必要な場合、単価を安くしなければ、プロジェクト全体の費用を抑えることができないという、生臭い側面があります。
もしかして、後者の方が大きい理由かも知れません。
ご回答ありがとうございます。
そうですね。SE は理系・文系的能力をバランスよくそろえるのが理想でしょうね。ただ、現実には、SE は SE で業務よりに傾いているような気もしますが・・・。
たしかに
■ SE より PG のほうが人数が多いということ
■そして情報の流れからして、SE が PG に指示を出すことが多いということ
■それゆえ、リーダ的な役割を果たすことが多いということ
で報酬をもっと出そうということになっているのかもしれません。
No.3
227713
15pt
http://ja.wikipedia.org/wiki/%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A...
http://ja.wikipedia.org/wiki/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A...
若い頃にプログラマーからＳＥになりかけたところで辞めたしまってのですが、コーディングはＳＥが作る仕様書によって作業の負担が変わってきます。仕様書が詳細に出来ていればコーディングもやりやすいのですが、そうでもないことの方が多かったように思います。自分達の頃はＳＥでもプログラマーのようにコーディングもしていましたのでＳＥとプログラマーを線で引くことは出来ないのですが、確かにシステム設計は難しいですが、プログラマーが簡単な仕事とは思いません。プログラムを組んだ経験のない人にシステム設計は出来ないと思っていますのでシステムの経験上ＳＥの方が長く経験を積んでいる人と考えるべきではないでしょうか。
ご回答ありがとうございます。
Wikipedia の「システムエンジニア」の項目、よくまとまっていますね。
「日本では、企業情報システムの業界におけるプログラマ（Programmer、PG）とは、前述した職域のうち「ソフトウェアの構築」を担当する者のことである。しかし、アメリカでは昔から上記のシステムエンジニアの仕事も、プログラマがすべて担当している。
かつてはシステムエンジニアが仕様を作成し、それに基づいてプログラマがプログラミングを行うという分業が行われていた。 プログラミング環境が進化した現代のシステム構築では、システムエンジニアがプログラマを兼任することも多い。 [1]。 この傾向は小規模プロジェクトで顕著である。逆に、プログラマが要件定義や設計など従来システムエンジニアの職分とされていた職域に進出することも増えており、境界は曖昧化している [2]。」
私は実をいうと日本的な SE/PG の区別が昔からなじめなくて、アメリカのように区別なくソフトウェアの開発に従事する人間は全部「プログラマ」と呼ぶほうがしっくりいくのです。UNIX = Internet 風のハッカー文化に染まっているのかな。
「なお、日本のソフトウェア受託開発業では、プログラマよりもシステムエンジニアの方が上級技術者らしく聞こえて高い単価を要求できるためか、実際にはプログラマであってもシステムエンジニアを名乗ることが多い。」
まあ、ここらへんの泥臭い価格交渉の道具として SE/PG の区別を使っているだけ、というのが業界人の本音なのかもしれませんが。
確かにシステム設計は難しいと思います。顧客の複雑な要求を、予算・納期・リソース・政治的制約の中で、実装可能なレベルの仕様に落とし込んでいく作業というのは十分に報われてもしかるべきだと思います。しかし、その一方で、仕様を実装する人間を「PG」という呼称で貶めて（いるように私は感じますが）しまうのはどんなものかと。本来ならば、要求仕様を取りまとめる人(SE)は、実装のプロであるべき人(PG)と対等の関係で話し合い、設計をまとめていくべきではないでしょうか？そうしないと（業務に使用し得るほどの安定性を備えている範囲で）最新の技術を盛り込んで、作業効率を上げていくことはできないように思うのですが・・・。
No.4
105825
15pt
特におかしくはないと思いますよ。
仕様の段階で練らないといいものはできません。
賃金差はそんなに違いますか?
あと、全体に日本の技術者の賃金は安いかもしれませんね。
http://dummy ダミー
確かに仕様の段階で練るのは重要でしょうね。賃金差はそうですね、私はフリーランスなのでですが、月あたり10万円以上は報酬が違うというのが実感です。日本の技術者は、製造業とかも含めて、報酬も安いし社会的地位も低いのが現実のようです。技術で飯を食っている国なのに、技術者に敬意が足りないのは不思議ですね。
あと不思議に思うのは、これは少なくとも受託開発の世界にいえるのですが、効率化への努力というのがほとんどない業界ですね。設計も重要ですが、工数を落とすためには、実装を徹底的に効率化する必要があると思うのですが、実装者（PG) はエントリレベルの仕事と考えられて、真剣に取り組む人が少ないようです。
COBOL の時代はおそらくコーディング作業がそれほど難しくなかったのかもしれませんが、現在の Java の時代にあの複雑なクラスライブラリやフレームワークを自在に操る能力があまり評価されないのは不思議な感じがします。みなさんはどうお考えですか。
No.5
35232
15pt
確かに日本においては PG と SE は単なる役割分担ではなく、職位として上下に見られることが多いですね。
個人的にはヘボな SE よりは、優れた PG に多くの報酬が支払われて然るべき....とは思いますが、一方で一般の開発現場では優れた一握りの PG ではなく、普通に仕事のできる PG を多く求めているという現実もあります。
逆に SE は頭数よりも、リーダ役となる少数精鋭が求められます。
結果として需要と供給の問題もあり SE の単価があがり、PG の単価は安くなる....という傾向になるのではと思いますね。
ちょっと極端な例かもしれませんが、こちらの社長さんが言っているようなきちんと経験を積んだ SE と、いくら優れたコード書けてもプログラム開発しか経験していない PG とでは、差があっても仕方なし....ではないでしょうか。
http://www.class.co.jp/column/backnm18.html
Ｑ．あなたはSEですよね？
Ａ．はい、経験15年です。
Ｑ．では、システム開発を、提案、プレゼン、要求定義（要件定義）、概要設計（外部設計）、基本設計（内部設計）、詳細設計（SPEC作成、プログラム仕様書作成）、プログラム開発、結合テスト、総合テスト、本番支援まで全て経験したことがありますか？
Ａ．・・・・（無言）
Ｑ．では、どこまで経験しましたか？
Ａ．（言葉に詰まりながら）前の会社ではプログラム開発の仕事しかなかったので、他の仕事はやったことがありません。
ははは。私は業界経験10年ですが、この「自称SE」に近いですね（苦笑）。
確かに顧客の立場からすると、自分のビジネス上の要求を誰かが何らかの方法で解決してくれれば OK なわけで、その手段がたまたま IT であっただけなわけですよね。要件定義や設計と言った顧客寄りの能力というのは、顧客にとって非常に重要で、それに対して顧客が高くお金を払おうとするのは、自然だとは思います。（まあ中小規模のシステムではここまで手順を踏まないとは思いますけど）
だた、私の基本的な問題意識としては、非常に実装に詳しい人の能力を日本の受託開発業界は生かしきれていないような気がするんですよね。それは、顧客にとっても損失ではないかと。だからいまはそういう実装に詳しい人を "PG" ではなく「IT アーキテクト」とか呼んで別枠で評価しようということになってきているのかもしれません。（私自身は、ちょっと中途半端で、実装についても誰にも負けないとはいえません。すごい人は世の中たくさんいるので）
No.6
3159
15pt
一応うちの会社では体制として
SE：お客さんの要求をヒアリングして、システム要求仕様とそれを実装するための設計書を作成し、その後の製造・試験・運用工程を管理する
PG：SEが作成した要求仕様および設計書に基づきコードを実装する
という関係にあります。
SEはお客さんの信頼を得て、要求を明確化し、実装可能な設計書を作成することができ、かつ製造以降の工程を管理し、と長期に渡ってシステム開発に関わります。
PGは設計書に基づきコードを実装し、単体テストが終わった段階で終了し、次々とシステムを渡り歩いてゆくことになります。
上記のとおりであれば、SEには、コミュニケーション・ドキュメンテーション・実現性検討、工程管理、人員管理など多方面のスキルが要求されます。
それにくらべ、PGは要求が定まっており、設計がちゃんとなされているなら、そこからコードに落とす際には、個人のスキルにより品質・スピードがかなり違ってくると思いますが、一応やることは決まっており守備範囲が狭いと言えると思います。この関係ができているならPGにくらべSEに高い地位が与えられるのは至極当然だと思います。
ということから、質問者さんが書いておられる
「実装方法によって、パフォーマンスや保守性はまったく違ってくるし、それで工数は大きく変わってくると思うのですが。」
はそのままSEに
「要求仕様および設計方法によって、システム開発工数はまったく違ってくるし、それで最終顧客満足度は大きく変わってくると思うのですが。」
に置き換えられると思います。
ただ、実際問題としてSEが上流工程において仕様を明確にできてなかったり、実現が不可能もしくは極めてむずかしい設計を行ってしまったり、工数不足のスケジュールを立ててしまうことが多々あり、そのツケがPGにまわるプロジェクトが多いのが現状だと思います。結局現場のスーパーPGが上から下まで直してなんとか完成させるということもありますし、ただ混乱が混乱を呼びデスマーチと化す場合もあります。（何度も食らってます）
個人的には、最初の悲劇（要求仕様から全然ダメ）をPGが止めることはできないわけで、少しでも悲しいプロジェクトを減らすためには、今ご自身がPGで、SEの処遇に満足がいかないのなら、是非SEとなるべく勉強し、ご自身がSEとして活躍していただければと思います。
わたしもずっとPGやってたんですが、SEになってSEの大変さがわかると同時にダメなSEがたくさんのPGに悲劇をばら撒いている実態がよくわかりました。
（自分はそこそこやってるつもりではありますけど…）
参考になれば幸いです。
ご丁寧に、ご回答ありがとうございました。
まったく同感です。
SE：お客さんの要求をヒアリングして、システム要求仕様とそれを実装するための設計書を作成し、その後の製造・試験・運用工程を管理する
PG：SEが作成した要求仕様および設計書に基づきコードを実装する
教科書的にはそのとおりだと思います。直近携わった小さなプロジェクトでは私はいわゆる "PG" として参加したのですが、SE さんが優秀な人で、きちんと設計してくれたおかげで、快適に実装・単体テストを終えることができました。実装面ではもうちょっと洗練した手法を許してもらえるとありがたいなとは思いましたが、少なくとも仕様はしっかり定義してもらって、ぶれなかったので、感謝・感謝です。
ただおっしゃるとおり私は今回単に幸運だっただけで、実際には仕事のできない SE も多く、工程的に PG が尻拭いさせられることは多いですよね。
ksh さんと一緒に仕事ができる PG は幸せだと思います。
No.7
551
14pt
「SE」が上で「PG」が下という用語定義が先にあるのだと思います。
だから、実態がどうであれ、「SE」が上で「PG」が下なのではないでしょうか？。
「SE」、「PG」という分け方をしている企業ではコーディングは単純作業ということになっています。
その結果、汚いコードが大量に作成され、メンテに多くの時間をとられている・・・ようです。
http://dmy ダミー
ksh さんの回答が理想ならば、momomoni さんの回答が現状ではないかと思います。
『「SE」、「PG」という分け方をしている企業ではコーディングは単純作業ということになっています。
その結果、汚いコードが大量に作成され、メンテに多くの時間をとられている・・・ようです。』
まったく悲しむべき現象ですね。この手のコードは何度も目にしましたが、本当に始末に負えないものです。結局、考えて保守性・拡張性に優れたコードを書こうというインセンティブがいまのビジネスモデルでは働きにくいということなんでしょうか。結果的に、関係者全員を苦しめているように思います。どうしたら、この悪循環から抜け出せるのでしょうか・・・。
No.8
1844155
14pt
>PG はなぜ SE より地位が劣るのでしょうか？
本来の開発の分業構造が適正に機能してちゃんと
担当範囲の仕事をしているのであれば妥当と
思いますが・・・・
=================================
SE/PM/PL/PG/SA/OP等色々呼び方があります。
会社により業務内容の違いありますが
線引きすると
営業:
コンサルタント:
SE:
BSE:
-----------------------------
PM - PL
- SA
- PG(SE)
- コーダー
- テスター
- OP
のような感じになる。
SEは、営業的なSEと技術的なSEが
わかれると思われる。
Sales Engineer,System Engineer
対外的な意味としてプロジェクトで
上級技術者をSE/SA/PL/PM,それ以外の技術者を
PG/OP/コーダー/テスター/OPと便宜的に
呼んでコストを一律に算定している。
（例：ｘｘ何人月等）
意味のないｘｘ人月を基準にコストを
積み上げ計算する上で必要だから分けられている。
ところがSEの立場を勘違いしてSales Engineer的
な立場で基本設計・要件定義や設計を
やってしまう人もいる。
プロジェクト初期段階で適正評価・検討
されていれば後工程のトラブルも少なく
なるが、大抵されないため、後の工程で
トラブルが発生する事になる。
PM/PLのプロジェクト運営が適正であれば
そのような問題は起こらないのですが
適正にプロジェクト運営がされていない
事が根本の原因にあると思われる。
そのようなプロジェクトでは仕様の妥当性や
技術検証・承認に関して第三者に合理的説明が
出来ない。
PG/SE等と便宜的に分けてありますが
SEは技術的で技術的に優れている必要は
なく技術的に詳しくなければ○○スペシャリスト
のような形で外部の力を積極的に活用してでも
システム全体を最適な形で実現する方法を
決定、最低でも顧客＆社内両方が満足ゆく合意
を導き出す事が要求とされる。
しかし、現実は・・・・・
http://ja.wikipedia.org/wiki/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A...
ご回答ありがとうございます。
だいぶ頭が整理されてきました。
ウィキペディア「プログラマ」もまたいいですねー。
SE が SE として本来期待されている役割を果たしていれば、SE > PG でもよい、ということですね。ただ、私が現場で納得がいかないことが多かったのは、本来 SE としてなすべき仕事をやっていない SE が多いから、ということだったのかもしれません。
私がこういう質問をしたのは、受託開発の世界は、あまりに多くの不合理・非効率がまかり通っている気がして、好きになれなかったからです。とはいえ、この世界で生きていくしかないとしたら、どういうふうにビジネスを展開していくべきか、考えていたからです。そもそも非効率を改善すれば収益になるはずだし、ビジネスである以上、お金儲けに興味がないひとはいないはずだから、非効率を改善するインセンティブはあるはずだと思うんですが・・・。
あとは、アジャイル開発の考え方にもあるように、ソフトウェア生産の現場をもっと人間的なものにしたい、という気持ちもあります。PG を搾取することで収益を上げるビジネスモデルというのは持続的ではないと思います。PG を大切にするソフトウェア企業が結果として競争に勝ち抜くことができる、というふうになればいいのですが・・・。
No.9
551
14pt
回答2回目です。
>PG はなぜ SE より地位が劣るのでしょうか？
もの作りはトップダウンに行うものという前提があるのではないでしょうか？。
つまり、偉い人が大枠を決めて、下の人間が細かいことをやるというわけですね。
たぶん、建物や衣類などはそれで問題ないと思います。
しかしソフトウェアの場合はボトムアップも必要な場面が多いと思います。GUIライブラリを使う場合など、ライブラリの細かい制限から実現できないということもあります。また、既に作ったソフトウェアへの機能追加の場合、ちょっとしたことなのに、構造的に無理または非常に時間がかかるということも多々あります。
非線形、カオス、バタフライ効果といったことを理解しないとソフトウェアの本質は分からないと思います。
http://ja.wikipedia.org/wiki/%E3%83%90%E3%82%BF%E3%83%95%E3%83%A...
確かにそうですね。
実装を知らない人が設計すると、実装可能だとしてもとんでもなく手間がかかるような方法しか取れないことも多いように思います。お客さんからしてみれば、ガリガリ一から作りこもうが、コンポーネントを貼り付けておわりだろうが、ソフトウェアが仕事をきちんとこなしてくれればよいわけで、これは大きな社会的損失のように思います。ただ、もうちょっと現場の PG たちももっと自己主張すべきなのかもしれません。実装 A ではなく実装 B のほうがこれこれしかじかの理由でよい、ということをきちんと相手の立場に立って説明する能力が必要になってくるのかもしれません。コミュニケーション能力も重要になってくるわけで、そういう意味では「プログラムしかできない」プログラマではいけないとは言えるかもしれません。
No.10
51
14pt
日本の某IT企業のSEで、現在アメリカ駐在員をしているものです。もう少し言うと
俺は（Java）プログラマーだっ！
と常々言い回っているものです。SEとしてSEの仕事を強要されながら、常に貴方と同じ疑問を持って日々自分の将来と戦っています。だから、自分との戦いの歴史から今までに導いてきた事で幾らか答えになるのではと思います。
まずその前に、elm200さんの質問の定義を私なりに明確にします。
・「地位が劣る」
究極的に言えば、お客様（お金を払う人）から見て、より高い金額を払ってよいと思う人が「地位が高い」ということになります。SEだろうがPGだろうが、お客様のために価値のあるシステムを作るという目標は同じですから、お客様にとってはそれを実現してくれる人にお金を払います。
・SE
「１０億円あげるから、うちの業務を助けるシステムを作って」と言われて、「はい」と言う人／言わなければいけない人
・PG
「受注業務の入力システムを～という画面から・・・というデータを入れてOOOというデータが返ってくるように作ってくれ」と言われて、「はい」と言う、もしくは「設計書をください」言う人。
※ 実際は大きく違いますし、本来の定義は他の回答者の方が答えている／引用している定義ですが、お客さんから見るとモノを頼む相手としてはこのように分類していると思います。
さて。ではいろいろな角度から。
１．１０億で１年で大企業の基幹系システムを完成させるには？
・・・っていったって、SEだって一人ではできないし、どちらかと言うと一人でやれといわれたらPGの方が確実に完成に近づけるでしょう。ただ、お客さんにとっては、誰かに責任をもって達成してもらわなければいけないわけで、とにかくそれをできると言い張る人、つまりSEに１０億円預けるわけですよ。そしてSEがそれを使ってPGや様々な人、機材を買って完成させるわけです。もし１０億円以上かかればその人（会社）が負担する、もし９億で完成すれば１億円もらってよい、それだけの話です。だから、優秀なSEはPGより給料が高いでしょう。逆に無能なSEは本来給料が出ないはずです。海外では途中の段階でクビのところですが、日本独特の文化で守られているため、elm200さんのような疑問が生まれるだけです。
PG（やその会社）も、このSEは十分利益を出して自分に利益を還元してくれる＝支給額が高いと思えばやるし、思わなければ断ればよい。ただ、仕事量の関係上、受けざるを得ない場合がある・・・だから、やはりelm200産のような疑問が生まれるわけです。
そういう歪んだ状況でシステム開発の現場が進むために、色々問題が出てきています。大丈夫、こんな状況は絶対に長くはもちません。
２．システムのパフォーマンスと保守性を保証するために
私はシステムのパフォーマンストラブルを調査して解決する仕事をメインにしていましたが（コードをリバース○ンジニアリングして解析することも・・・）、結局お客様は自分のシステム全体の全業務の性能と保守性を保証して欲しい。当然、PGその人だけがそれを実装できるのですが、逆に言えば（電脳化でもしないかぎり）一人のPGがどれだけがんばっても、性能や保守性を保証できる範囲は限られています。elm200さんが１００人分のPGの仕事をして９０％のシステムをカバーしても、残り１０％がめちゃくちゃならば、お客様は満足しないわけです。
どうしたらいいか、やはり誰かが責任を取らなきゃいけない。１０％がダメならもう一人elm200さんのような人を雇わなければいけない。あるいは、elm200さんのPG技術を標準化して１００人の人にコピーしなければならない。あるいは、「既存製品を使う」と判断しなければいけない。それで１００％のシステムがカバーされるなら、常人の１００倍の能力を持つelm200さんよりもそんな要領のよいSEにお金を払うのも仕方がないことです。
※ この考え方は良く私も諭されるが、どうしても納得いかない！１００人分の仕事をしたら、１００人分の（５０人分でもいいよ！）PGの給料をもらえてしかるべきだ！
３．その頃海外では・・・
私も本当に動揺しているのですが、お客様の業務に合わせてスクラッチから開発するなんて方法、ある会社に全て開発を委託するなんて方法は今時日本だけです。少なくともアメリカでは「このパッケージを使ってバニラでお願い（カスタマイズなしでパッケージの機能をそのまま使うこと）」と言われます。業務なんてパッケージにあわせて変えればいい、それで成功しているならなおさら。文句をいうユーザーはクビにすればいいだけです。それでコストが下がるなら。勿論開発者は０にはなりませんが、いわゆるプログラムを組む人の人数は圧倒的に少なくなります。
更にその少ないプログラムを組む人、例えば９９×９９を誰もが暗算で出来るような人種（教育をうけている）のインドの人々は日本の５分の１から１０分の１の値段でその仕事をしてくれます。
なんていうか、それが現実ですから、どっちが偉いとか劣るとか言う前に、「呼び方はどうあれ、あなたは何が出来る？」の問いに答えなければいけないんですよ。SEもね。
４．海外のプログラマー
アメリカには５０歳や６０歳で「プログラムを書いて」生計を立てている人は大勢います。まぁ、億万長者、と言うわけには行きませんが、別荘１軒をフロリダに持つことくらいはできるんじゃないですかね。アメリカではSEなんて職業は逆になくて、SEがやるべき仕事はもっと細分化されてそれぞれ専門化がアサインされます（だから、アメリカで全部日本風開発すると、日本に比べてそれはそれは高い値段になります・・・）当然プログラマーもその１つ。もちろん安いプログラマーもたくさんいますが、スキルによって値段が完全に異なる個人制です。
海外はいいな～、なんて思うかもしれませんが、とんでもない。彼らは個人で評価される代わりに、失敗すれば、失敗しなくてもアサインする仕事がなくなれば、クビです。まぁスキルがあれば次にもっといいポジションで別の会社に行くからいいんですが、逆にそれだけが頼りです。
そういう「専門家」は、ほかの事は出来ませんがプログラムにかけては大学も情報工学系を当然でていて、たとえ使わなくても基本的なアルゴリズムは当然人の名前付きで出てきて、常に最新の技術を取り入れ、更に自分の強みをアピールし続けます。
例えば、私もメンバーとして日々精進しているTopCoderなど見てみてください。この際とは、世界中のPGを集めて毎週PGの天下一武闘会を開いています（是非elm200さんも出よう！）。ここの幹部の人が、日本の記事を紹介してくれました。http://www.itmedia.co.jp/enterprise/articles/0703/01/news013.htm...夷藤さんも言っていますが、ここまできて（ここで上位をとって）「私はプログラマー」と言えないといけないわけです。
５．そんなPG>SEなPGはあそこに！
私が思うに、そんなPGがいる、そんなPGだけがいるのがGoogleだと思います。上記の大会で上位入賞してGoogle本社に入った人を知っていまして、話を聞きましたが、彼らは１日中プログラムを書いているものの、幹部社員という存在は異様に少なく、また仕様がどこからか降ってくるわけではなくて自らプロジェクトを立ち上げて提案します。全プログラマの提案は常に公開され、面白そうな人間の所に人が集まり、プロジェクトが成立するわけです。
全員がPG+SE。これがelm200さんのいう、もっと評価されていいPGの姿、ですよね？
６．長くなりましたが、最後に・・・
私の結論です。
我々がもし本当に優れたPGならば、そして常に優れたPG・・・それは、出来る限り多くの人に使われ、喜ばれるプログラムを作り出すPGでありたいと思うならば、バグのない、生産性の高い、性能の良いプログラムを書くだけでは満足しないでしょう。人々は何を求めているのか、世の中には何があって、他の奴らは何を作っているのか、畜生やるな奴らめ、ならば俺はこんなのを作るぞ！・・・
そうやっていたら、きっと普通のPGの作業では収まらなくなる。人々に要件を聞き、賛同者を集めるために提案し、人を集め、お金を集め、管理し、説明し・・・きっといわゆるSE作業をしたくなる、せざるを得なくなる。
そしてPG作業は日曜日に。
それがサンデープログラマー。給料云々は度外視。自分がやりたいと思うことを成功させるだけでお金は入ってくる、だからPG作業は日曜日に、自分の楽しみで、自分の理念をエディタにぶつける。無償で。
今はそういう人たちに支えられ、オープンソースというプログラムで世の中は満ちています。
「地位が劣る」、そんな悲しい言い方は止めましょう。地位が劣るのは人であって、プログラマーという職業ではない！
一緒にがんばりましょう。まずはTopCoderで、世界へ！
うーむ。熱い文章をありがとうございました。
実は私はカナダに4年ほど住んだことがありまして、その間は小さなソフトウェアベンダーでプログラマをしていました。（特に先端的な企業ではありませんでしたが）ですから、北米と日本の考え方の違いについては、いろいろ考えたことがあります。
アメリカは、パッケージ重視なんですね。そして機械的なコーディング作業も安価なインド人などにアウトソースしてしまうと。本当に生産性が高そうなやり方ですね。
TopCoder おもしろそうですね。見てみます。
＝引用始
ただ、お客さんにとっては、誰かに責任をもって達成してもらわなければいけないわけで、とにかくそれをできると言い張る人、つまりSEに１０億円預けるわけですよ。そしてSEがそれを使ってPGや様々な人、機材を買って完成させるわけです。もし１０億円以上かかればその人（会社）が負担する、もし９億で完成すれば１億円もらってよい、それだけの話です。だから、優秀なSEはPGより給料が高いでしょう。逆に無能なSEは本来給料が出ないはずです。海外では途中の段階でクビのところですが、日本独特の文化で守られているため、elm200さんのような疑問が生まれるだけです。
＝引用終
そうですね。まさしくその通りだと思います。お客さんにとっては IT は巨大なブラックボックスで、とにかく欲しいものを納品してくれる（と主張する）人にお金を払うだけなんでしょうね。そのコミットメントに対して、報酬が支払われる。ただ、日本の場合、なあなあの生ぬるい風土があるものですから、無能な人もある地位にとどまり続け、下にいる人間が犠牲になるという悲劇はあると思いますね。
私が最近下請けでやった仕事では、3年まえの古い PHP を使い、フレームワークを使えば3人日で出来る簡単な仕様を4人月ほどかけて、何のライブラリも使わずフルスクラッチで開発していました。お客さんはそれに対して、600万円以上払っていたようです。こういう状況というのは、誰にとっても不幸だな、と思うですが・・・。（私一人に任せて好きなやり方で開発させてくれて、1月500万円もらえるなら喜んでやるんですけどねえ・・・）
（もちろん、お客さんの言い分としては、「後々の保守等まで考えて」大手の SIer に高い単価で発注しているのかもしれません。まあ、ミッションクリティカルでかつ毎月100人で開発するようなシステムなら、まだしも、よくある中小のアプリまで大手 SIer に依頼する必要ってあんまりないような気がするんですが）
端的に言ってしまえば、日本の文化はソフトウェアを作るのには向いていない、ということなのかもしれませんが・・・。そう言ってしまうとあまりにも悲しいので。僕がどうこういうことでもないのかもしれませんが、日本のプログラマは本当に幸せなんでしょうか。幸せになるためには、技術者としての道を全うでき、それが金銭的にも報われる仕組みが必要だと思います。
No.11
520
14pt
日本ではSEがPGのキャリアの延長線上にあるからじゃないでしょうか。
もちろん大手ベンダーや、コンサル会社などでは最初からSEとして
働くケースもありますが、一般的なソフト開発を行う現場の場合は
PGを何年かやってからSEになるケースが殆どかと思います。
本来ならば、SEというのも一つの職種では無くて、アーキテクト、
アナリスト、プロマネ、プロダクトスペシャリストなどなどと細分化された
役割と職種がありますが、一括りでSEとしてしまっているケースが多いですね。
アメリカでは生涯一プログラマーというのもあるみたいですよ。こちらは参考までに。
>日本ではSEがPGのキャリアの延長線上にあるからじゃないでしょうか。
あらためて考えると何でなんでしょうね？
アメリカ人から言わせると、「レントゲン技師が修行積んで医者になる」くらい不自然なことなのかもしれません・・・。
ThomasTT
2007/03/28 22:58:55
4
2
1
2
2
9
9
ご回答ありがとうございます。
SE ＝ コーディング能力＋要求仕様作成能力
PG ＝ コーディング能力のみ
という前提で、要求仕様作成能力に対して追加の支払いがある、ということでしょうか。
うーん。ただ現実を見ると、何年も要求定義だけをしている SE たちは、最新の技術に非常に疎くなっていたりします。それで足かせになって、PG は古い技術を使うことを強制されて、生産性があがらなかったりしませんか？それでいいのかなあ・・・。