はじめまして。コラムニストのちょりぽんです。
記事の内容に同意することをお伝えした上で、考察を書いてみます。

私も経歴上ではＰＧからＳＥに進んだクチです。小学生の時にMSXのBASICでゲームを作っていたこともあり、プログラミング好きが興じてこの業界に進みました。

キャリアパスについて会社や先輩から指導があったのではなく、自分の好奇心から派生して徐々に担当ポジションを広げてきた経緯があります。ただしプログラミングの楽しさ無くしてモチベーションを維持することは難しいので、必ずコーディングも兼任しており、これまで出逢った専門PGと比較しても引けを取らないスキルと生産性があると自負しています。何より全ての作業を経験することで得られたノウハウは私の財産です。つまり、私の場合は何れかの択一ではなく、あらゆる意味でボーダーレスの精神が根底にあります。

現実と違う「SE>PG」の認識については、マスコミの影響があると思います。
一昔前ですとIT業界のイメージは「カジュアル」かつ「華やか」。このイメージの代名詞は「SE」で、PGではなかったように思います。

数字を明確に挙げることはできませんが、ある時期以前を境にして、この様なイメージから間違ったSEが大量に増えたと思っています。彼らの大部分は用を成すことができず、数年前から相当な苦労を強いられているのではないでしょうかね。

同感です。よくそれを疑問に感じておりました。
SE／PGの区分って、弊害こそあれ、何の利点もないと思います。
よくこの不可思議な現象を疑問に思っていました。
それで考えたのですが、答えはこの業界の構造にあると思います。
それは、多重請負構造にしたいから（中抜きしたいから）、無理やりそういっている人達が居るせいだと思います。
もし、それを本気で行っているのであれば、その経営者は余りに無知すぎると思います。
日本には無知でも経営できると言う迷信があるようですが、分からないものを商売できる程甘い時代はバブルの時だけだと思います。
もしかして、未だにバブル気分なのかも・・・

Ahfさん、おはようございます。

　相変わらず今構想中のネタと被りかけています（笑）

　おっしゃる事は私も同感です。最近はPGとSEの垣根がなくなりつつあるような気もしますが、一定規模以上の会社は未だに「SE > PG」でしょうね。私が前にいた会社もそうでした。でもSEとPGで仕事が異なるか、と言えばそうでもないので単なる慣習か肩書きのような気もします。

　私が現在所属する会社のように小さくて人を増やす事もあまりない会社では1人何役も要求されます。私自身PMですが、毎日プロジェクト管理、設計、コーディングをやっている兼業PMです。会社の要求はPMだけなのですが、メンバーのスキルや人数・スケジュールを勘案すると自分もやらざるを得ない状況になります。

　システムを知るにはPG→SE→PM→･･･と辿るのが一番良いと思うのですが、業務システムの場合はソフトウェア知識と同じかそれ以上に業務知識が必要になります。この両者のバランスを考慮するならソフトウェア知識が上の人がPG、業務知識が上の人がSEと言えない事もないのかな、と思います。ソフトウェアを中心で考えるとPGの方が上かも知れませんが、現場では業務知識の方が重要だと思うので（知らないときちんとした設計が難しい）「SE > PG」になっているのかも知れません。

　いずれにしても精進あるのみ、なのはどれも同じなんですけどね。

ITブラック系企業から逃げて、とある海外でビジネス系の修士をとるために院生になっていたころ、前職何？って聞かれて、IT企業でサポートのエンジニアをしていた。もしくは、IT　エンジニアだって答えてましたね。IT　エンジニアも和製英語なのかもしれませんが、理解していただけましたね。

がると申します。
個人的には、PGやSEというのは「個人に複数付与しうるタグの１つ」ではなかろうか、と思っています(いやじゃぁSEが何をやる職分？ ってのはおいといて)。
で。
この業界で「本当の意味で真っ当に」食っていくのであれば。PGというタグは、やはり削除してはいかんタグなんじゃなかろうか、と思っています。

こんにちは。
ガルさんがおっしゃるようにタグというのが１番しっくりきますね。
PG 実装
SE　設計
本来はこれでいいのですが、SEの方のイメージって実際は設計＋実装みたいに思われてるんですよねきっと。

みなさんにひとつお聞きしたいのですが、なんで実装したことないもので設計できるんですか？
設計するためにサンプルを作ったり、動かしたりしてある程度情報得てから設計しますよね？だからＳＥは設計＋実装は当たり前だと思うのですが。
それこそ、料理人が材料や調味料を味を調べずにその材料を使って料理のレシピを作ったり、一級建築士が木材や石材の特性を調べずにその材料を使って建物を設計するのかと。

連続投稿すみません。

本文の「昨今の情勢から、PGが知るべき範囲というのは拡大の一途を辿っています。」とありますが、ＰＧが知るべき範囲って具体的にどのへんですか？
残念ながら、現在のＰＧはＯＳの特性やフレームワークやライブラリによって挙動の差異など「知りません」し「知ろうともしません」。
私は寧ろＰＧが知っているべき範囲が縮小の一途をたどっていると感じています。

こんにちわ

みなさんに質問なのですが、設計とはどこからどこまでのことを言われていますか？
要件定義などは、それほど実装を経験してしていなくても可能だと思いますし、
外部設計も記述レベルによりますが、業務を熟知していれば、書けるものも存在
すると思います。

あと、PGの知るべき範囲が拡大というのは正しいようにも思えますが、拡大しているからこそ、逆に専門の分野に分かれており、
浅く広くしか知らないPGも多いと思います。

「みなさんに･･･」とあるので少し反応してみます（Ahfさんのコラムなのに、ごめんなさい）あくまでも私の意見なのでご了承下さいませ。

> なんで実装したことないもので設計できるんですか？

　設計と一言で言っても範囲は広いので難しいですが、出来るか出来ないかと言われれば出来ると思います。もちろんOSやソフト、使用言語についてはある程度の知識は必要です。屁理屈みたいでこういう言い方は好きでは無いのですが、仕事かどうかは別にして初めて使う言語で何かしらのプログラムを組んで動かそうとする場合、簡単でもどの様に動作するか考えてからプログラミングすると思います。この「どの様に動作するか考えて」と言うのは設計だと思いませんか？そういう意味では設計→実装という道を辿るので実装した事が無くても設計は可能だと思います（極端ですが）

　個人的には設計は要求仕様からアルゴリズムに落とし込む作業だと思うのでプログラムの基本である「入出力」「処理」「判断・分岐」「反復」が最低限理解していれば可能だと思っています。もちろん、実装を知っていた方が良い事は間違いありません。

　私はエンジニアと料理人など他職種と比較するのは意味がないと思います。材料や調味料の味を知らなくてもレシピがあれば「料理人」にはなれるでしょうから（良いか悪いかは別にして）昔の会社で私の部下に前職がパティシエだった子がいたのですが、彼女はシナモンが嫌いで食べなかったらしいですが、それでもシナモンを使ったお菓子を作っていたそうです。

　PGだって長年やっていると肩書きはPGのままでも仕事はSEと同じになっている、と言うのは良くあると思います。開発現場ではSEが設計、ではなく出来る人が設計している、と言う形も多いと思いますので確かに「タグ」と考えた方が一番合うと思います。ひとくくりに「エンジニア」で良いと思いますが･･･この辺りはコラムのネタなのでそのうち書こうと思います。

こんにちは。

PGからSEになるのは企業が望むところなんでしょう。

特に大企業はSEを求める傾向があるようですね。
PGは安い下請けにやさせる。
なので入社してすぐにSEとして学ばせる。
ベテランSEの下でSEとして仕事を行う。

建築で言えばPG=大工、SE=建築設計士でしょうね。
大工の事を知らなくても建築設計士にはなれます。

同じようにプログラムを知らなくてもSEにはなれると思います。

メタボぎみさんへ

具体的にＰＧの知るべき範囲を示してもらえませんか？
浅く広くしか知らないＰＧが多くなってきたからこそ、ＰＧが知っているべき範囲が縮小していると感じているのですが。
昔のＰＧは、ハードウェアの知識がないと最適なアプリケーション開発はできませんでした。でも今は、その知識がなくてもアプリケーション開発できます。
環境の違いから知るべき範囲や考え方に相違があると思ってますが、本コラムでも
メタボぎみさんの意見にも具体的な例や範囲が示されていないので、とても拡大しているとは思えません。なので回答よろしくお願い致します。

それと、私が考える設計とは、「要件定義」～「内部設計」までです。（実際はもっと下流のコーディング手前までやってるんですけどね(--; ）
確かに要件定義は実装経験がなくても、できなくはないと思いますが、外部設計以降は業務知識があっても、できないものはできません。まあ、書けるものも存在するとは思いますが。

にゃん太郎さんへ

なんか「鶏が先か卵が先か」って感じがしますね。
私は材料の個性を確認してから取り組む人なので、確認作業は「設計」と思ってなかったので。（それに差分を計測するには使い回しが基本ですから）
あと、料理人の件ですが「設計（レシピ）」があれば作れるのはＰＧであって、特定の材料が嫌いな料理人が、その材料を使った「レシピ」は作りませんし作れませんよね？
揚げ足取りなって申し訳ないです。
私の意図をうまく伝えられていないことも合わせてお詫びします。

ヴァンさんへ
私の例えは悪いですね。私の理論で言ったら「大工は建築設計士になれる」ってことになりますね。
でも、建築設計士って言葉がなかった頃は（ｒｙ。
にゃん太郎さんと同じで、私の意図をうまく伝えられていないことをお詫びします。

がるです。
コメントへのコメントで恐縮ですが。

To CMPさん
> なんで実装したことないもので設計できるんですか？
個人的には「出来ると彼らは主張をしている」、がまずあって。
で、正直今までそういう方々の設計もどきで徹頭徹尾痛い目に遭い倒しているので。あれを「出来ている」と、私は呼びません。
ですので。まぁ「設計」はきっと出来るのでしょう。ただ、使い物になりませんが。

ちなみに。

材料や調味料の味を知らなくてもレシピがあれば「料理人」にはなれるでしょうが、「料理経験が全くない」状態で作ったレシピがおおよそ「惨い事になるであろう」事は、ほかのBlogでも書かれています( http://satoshi.blogs.com/life/2006/03/post_8.html )。

「大工の事を知らなくても建築設計士にはなれます。」はYesです。で…とある一級建築士さん曰く「現場しらないからろくな図面書かねぇし、現場で修正と調整をしないと使い物にならねぇ」んだそうです。
つまり「設計士にはなれます」が、その人が「使えるか使えないか」といえば「使えない」になります。
# 現場で修正をした後、その修正を連絡するそうです。

どんなところに行っても。
「現場を知らない人間がその現場をしきれるか」は、常にNoだと思いますが如何でしょうか？(一応、それなりに幅広い職種の、そこそこ一流どころと多々会話させていただきましたが)。

Ahfさん、こんばんは。
saki1208です。

業務の機能や運用に関係する部分の機能についての設計は実装を知らなくても十分設計可能であると思います。
しかし、設計者が実装を知らないということはその時点で大きなハンデを背負うことも多いのではないでしょうか。

実装経験の無い言語やツールを使用するプログラムの設計を行う場合にとんちんかんな設計を行う人も多くおり、設計の間違いまたは実現が難しいものを指摘しても逆切れするだけでお客様と交渉すらしないSEも沢山見てきました。
もちろん、プログラムを創る訳ですから実際には殆どのことは何らかの手段で実現できると思っていますが、納期や費用に対してそれが妥当であるかは毎回異なります。

私自身は自分の参画するプロジェクトでは殆どすべての工程で作業を行いますので、手伝い程度で作業する場合などでは非常に歯痒い思いをすることもあります。

正直、設計オンリーのポジションはいらない...

みなさんコメントありがとうございます。

>何より全ての作業を経験することで得られたノウハウは私の財産です。（ちょりぽんさん）

同感です。私も一時期開発から遠ざかっていた時期がありますが、そこで得た経験は他の人にはない武器にできている、と（自惚れもありますが）思っています。
ちなみに私、小学時代はシャープのX1でした。似た世代ですねぇ。

>SE／PGの区分って、弊害こそあれ、何の利点もないと思います。（インドリさん）

そうですね。作業領域を表す程度で丁度いいのかな、と思えます。
個人的には多重請負、というところよりも「あまり考えずにとりあえず分けておいた」という人が多そうな気がしています・・・。

>現場では業務知識の方が重要だと思うので（知らないときちんとした設計が難しい）「SE > PG」になっているのかも知れません。（にゃん太郎さん）

システムを構築する上で業務知識は非常に重要だと思います。そしてその知識量の差でSEとPGを区分けするのであれば、まだ納得できますよね。世の中のSEと呼ばれる人たち（自分も含めて）は、そう思われるようしっかりと努力する必要があるのだと思います。
しかし、にゃん太郎さんとは本当に考えが似ているというかなんと言いますか（笑

>IT　エンジニアも和製英語なのかもしれませんが、理解していただけましたね。（tomo@0-stさん）

おお、通じるのですか。意外と造語として伝わっているのかも知れませんね。
口語としてどんどん形が変わるのと同じようなところなのでしょうか。

>私は寧ろＰＧが知っているべき範囲が縮小の一途をたどっていると感じています。（CMPさん）

なるほど、そういう見方もありますね。「知ろうともしない」という人達がいる、という点は物凄く同意します。ですが知るべき範囲は広がっていると思いますね。それはPCでできることが増えたということが繋がると思います。ですので「PCでできること」がそのまま「覚えること」になるのではないでしょうか。また、言われるようにOSやフレームワークにてカバーされているとはいえ、全く知らない人では使うことすらままならないと思います。

>逆に専門の分野に分かれており、浅く広くしか知らないPGも多いと思います。（メタボぎみさん）

現在はPGもSEも両極化してしまっているのだと思います。浅く広くという人もいますし、狭く深くという人もいます。ですがその間というのが減ってきているというか。
それと「設計とは～」についてですが、コラムを書いている際にイメージしていたのは「内部設計まで」（会社によっては「外部設計」までかな、と思いました）ですね。実装に入る前段階まで、と言えばいいでのでしょうか。

>特に大企業はSEを求める傾向があるようですね。（ヴァンさん）

その通りだと思います。実装部分をアウトソーシングといった話は大きいところほど出てきているのでしょう。
あと個人的には、「プログラムを知らなくともSEにはなれる。だが大した仕事はできない」、と思っているのですよ。まぁこれも「SEに何をやらせるか」という点を、その企業がどう考えているかによっては真実でもあり嘘でもあると思います。

コメントを書いている間にコメントが！（笑
返事を書くのが遅いぞ、自分！

>しかし、設計者が実装を知らないということはその時点で大きなハンデを背負うことも多いのではないでしょうか。（saki1208さん）

その通りだと思います。作業としては行えるでしょうが、実装を知るSEと比較すると、恐らくある程度の差が結果として表れてくると思いますね。

あと設計オンリーのポジションはいらない・・・と言われる気持ちは共感します（苦笑
ですが今後はそのような人も増えてくるのだろうなたぶん、とやや悲観的に思っていたりもしますが。

「実装を知らないPGがSEになれるか」、という疑問についてですが、

>個人的には「出来ると彼らは主張をしている」（がるさん）

これが全てだと思っています。

思っているだけ、であり実際にできているかとは別なのでしょうね。

「ＰＧ経験のないＳＥに設計ができるか？」ですが、そういうＳＥとできるといった人達で内部設計までやってねとしか言いようがないですね。外部設計まででもかなり怪しいけど。
百人に一人くらいはできる人がいるかも知れないけど、大多数が使えない人材ってことは周知の事実だと思っていたのですが。
だから「使えない＝できない」と私は主張したのですが、みなさまは優しいみたいで「使えないかも知れないけど、できないわけではない」と。
もし、その主張が主流なら私自身が「井の中の蛙」なので、考えを改めないといけませんね。

あと、「ＰＧが知るべき範囲」ですが、私は以下の項目さえ押さえていればいいと思ってます。ただ、他人が見たら浅いのか深いのかを知りたいです。
・使用する言語の基礎（変数の定義、入出力、分岐、繰り返しなどの記述方法、関数やクラス（構造体）の定義など）
・使用する言語でのＲＤＢへの接続方法
・マルチスレッドシステムの得手・不得手及び使用する言語での作成方法
・Ｃ／Ｓシステムの得手・不得手及び使用する言語での作成方法
・Ｗｅｂアプリケーションの得手・不得手及び使用する言語での作成方法
・メモリの管理方法（確保したメモリ領域の生存期間）

ＵＩのデザインやアルゴリズムに関しては必要に応じて取得すればよいかと。

CMPさん重ねてのコメントありがとうございます。

私の感覚としては「使えない＝できない」という認識で、ここにコメントしてくださっている他の方もそういう認識をされている方が多いように思えましたよ？

ただ付け加えるとして「本人達はできると思っている」というところでして。

またPGが知るべき範囲、についてですが次のように私は考えています。
・言語基礎：必須
・RDBへの接続：ほぼ必須
・マルチスレッド：知っているに越したことがない
・C/S形式の得手不得手：業務によっては必須
・webアプリ：業務によっては必須
・メモリ管理方法：知っているに越したことがない

個人的に付け加えるとすれば、言語に依存せずともアルゴリズムの基本形式（各種ソートや再起ロジックなど）は知っているべきかと思っています。勤務先、手がける案件によって要不要は変化すると思います。

変な話、RDBなどは案件依存に属するかと。

Ahfさん、こんにちは。

スパムっぽくってすみません。
「実装経験がなくても設計はできる」はできると思っている人も結構いるってことで完結したいと思います。貴重な異見ありがとうございました。＞皆様

で、AhfさんがPGに求める知るべき範囲は、そんなに専門性が高く深いですか？
もし、それが一般的な考え方に近いとすると、これも認識を改めないと（大汗。

CMPさんコメントありがとうございます。
ここのコラムでは連投ＯＫですので気になさらずに。

私がPGに求める範囲、についてですが私はどうしても「案件依存」「会社依存」という部分が大きなウエイトを占めると思えているクチですので、PG全般となるとどうしても浅く広く的になってしまうのだと思います。

どのような環境で、という前提条件次第で大きく変わるのではないでしょうか。

仮に販売管理等のシステム制作、ということであれば、C/Sやwebアプリというのも必須内容に昇格すると思います。RDBにしてもSQL文などの基本部分から、効果的な抽出方法、ストアドの実装など範囲は広くなると思います。

これが携帯アプリ制作とかになると、RDBの知識は持つに越したことがないのでしょうが、使う場面は激減するでしょうし。

Ahfさん、こんにちは。
楽しく読ませて頂きました。

「SE＞PG」ってこの業界の悪い慣習はありますよね～。
第一、SEってそもそもなんでしょうね？
コメントにもありましたけれど、私もバブル期にITという目に見えないモノと人を売り込むために勝手に作った記号としか思えません。

個人的にはSEなんて言葉はやめて、PGもDBもNWもそれぞれにスペシャリストがあり、プロマネやITアーキテクトなどのカテゴリに分けるべきだと思っています。

そろそろIT業界や企業は、SEと言って安易に纏める事をやめて
質の高い制度作りを目指さなければならない時期に入っているのかもしれませんね。

Ahfさん、回答ありがとうございます。参考になりました。

この広く浅い知識や技術から一歩進み出ることのできる人がスペシャリストになるんですかね。
できれば、その一歩進み出ることができる人がプログラマだと言える日が来るといいのですが。で、極めた人がスペシャリストに。
でも、プログラミングを極めるってどういうことなんでしょうね。
俺にはわからない・・・教えてエロい人ｗ。

ごんたさん、CMPさんコメントありがとうございます。

>第一、SEってそもそもなんでしょうね？（ごんたさん）

私もSEが登場し始めた背景というのはよく知らないですね。
入った頃にはあったというか。
ITSSとかで定義されるカテゴリに分ける、というのも私も面白いとは思います。
アーキテクトだけでも普及してほしいなぁ。

>プログラミングを極めるってどういうことなんでしょうね。（CMPさん）

難しいところですよね。他の職人と同様に、いつまでたっても本人には
極めたとは思えないところなのじゃないかな、と思っています。
周囲の評価は高まることがあるでしょうけど。

私はいつまでやっても「まだまだ」だな、という道なのかなぁ、と思います。

SE>PGなのは、業界の多重下請構造という体質に起因しているので、テクニカル的には、無価値と思える議論なのですが、逆に根は深いですよね。

下請階層が深い場合から、作業従事者に、高級／低級軸での階層が必要になるのです。
　例）　PM > SE > PG という階層を作り
　　　PM : 300万/月
　　　SE : 200万/月
　　　PG : 100万/月
　とすると、顧客の対面は、単価の高い職種を自社要員で埋め、残りを他に振り
　結果責任は なるべく下に押しつける。　とすれば楽に儲かるわけです。
　また、PG部分は 要件定義→外部設計..　とブレークダウンが進まないと
　出番が回ってこないため、その点でも誰かが先に食い散らかした残りの
　パイを食べざるをえない。
　という構造的な面もあります。

　本来ならば、実装の時点になってから、大きな矛盾が発生しないよう
　設計されているべきであり、設計には、それだけの質が要求されるわけ
　ですから、もっと初期からPGが参画する必要があるのです。
　が、建前上はSEが兼任していることになっています。
　その観点から行けば SE>PG でなければ、仕事は上手くいきません。
　（デスマーチにまっしぐらです。）それゆえの上級職。のハズなのですが
　残念ながら、世の中の仕組みは、そうは なっていないようで...。

tasukuさんコメントありがとうございます。

利益のために必要とされている部分はありますね。
仮にPMもSEもPGも区別無く、エンジニア、とだけだとしたら
単価を設定する基準が別に必要となり、違うところで問題の元になるでしょうし。

言われるように建前上は・・・、なのですがそれでも建前を満たすだけの
能力がついてきてくれていればまだ上手くいくのでしょうけどね。