SEとPG、どっちが頭がいい？（2）
刺戟的な題名で続けます。
前回は日本独特のSE／PGの分業体制がどのようにして発生したのか、ということを説明しました。それは日本にソフトウェア開発が産業として根付いたときに、PGが単純作業労働者と位置付けられてしまったため、上級技術者を区別する言葉が必要とされた、それがSE（システムエンジニア）だというものでした。
●C言語＠UNIXでは
COBOLの開発ではSE作業とPG作業がきちんと分けられていると思われがちですが、これも前回述べたとおり実際には形式だけのものになっていました。これはタイムシェアリング端末の普及によってプログラミング作業が格段に効率化されたからでした。プログラミングに残っていた煩雑な手作業の部分が省力化されたのです。
この事情はBasicやC言語でも同じことです。1980年代後半、わたしは最初の会社を辞め、パソコンの開発をするようになりました。現場では、技術者はそれぞれなんとなくあいまいにSEを名乗ったりPGを名乗ったりしていましたが、SEは必ずプログラミングができましたし、PGは必ず仕様書が書けました。そもそもプログラミングを知らなければ設計ができませんでした。パソコンの開発環境は個人が独占して使えました。そもそもC言語はUNIXとともに作られた言語です。UNIXは大型機の硬直性を打開するためにミニコンで動かすことを前提とした開発されたOSですから、そもそもがPG主体の環境です。開発者なら誰もがプログラミングができて当然の世界です。
●VBでは、なぜ？
ところがVisual Basicが登場してくると状況が変わってきました。再びSEとPGが分かれ始めたのです。
VBは必ずしも前回説明したSE／PG分業アウトソーシング説のモデルに合いません。VBは極めて開発効率が高い言語です。同じ実装をBasic、あるいはC言語で行うとしたら、工数は数十倍に及ぶでしょう。こんな高能率な言語の実装を外注に任せてしまうのは、技術の蓄積という面で会社にとって損だと思うのですが。
●レベルが高いVBのプログラミング
ご存知の通り、VBはフォームといわれるウィンドウの上にテキストボックスやボタンのような部品を置き、それぞれ「クリック」や「フォーカス」などのようなイベントごとにソースコードが書かれます。それまでBasicやC言語では、プログラム自体1つの構造を持ったまとまりだったのですが、VBの場合、プログラムは画面に見える各部品の中に断片的に散らばっているのです。
このことはVBアプリの設計を難しいものにしました。分散しているソースコードを1つ1つ定義していたのでは、手間がかかってしかたがありませんし、仕様が断片的になり、かえって分かりにくくなります。そのため、設計書では画面全体の機能だけを記述し、PGが各機能の相互連携を考えることになりました。PGは仕様書を受け取ると、細部まで読み込み、それが全体ではどのような動きをするのか入念に頭の中で組み立ててから仕事にかかりました。最後には頭の中に機能の入念な地図が出来上がります。PGはそれを頼りに、どんなバグにも対応できるようになります。この地図をドキュメントにしてお見せできないのが残念です。
また「コントロール」と呼ばれる画面上の各部品には、それぞれたくさんのプロパティがあり、それに設定されている値を操作することでさまざまな動きをさせることができましたが、おかげでリファレンスだけでかなり分厚いマニュアルになってしまいました。必要なプロパティやコマンドを覚えるだけでも一苦労です。さらにAccessやExcelのオブジェクトについても該博な知識が必要になります。PGが知らなければならない知識は、C言語と比較してもはるかに多いのです。
●SEは「御用聞き」？
このようなPG作業に比べれば、VB開発のSE作業はお客さんの要望を文書にまとめるだけの地味で単純な作業に思えました。仕様書をまとめ終わったあとのSEは、プログラミングのお目付け役か、表現はよくないのですが、単なる「御用聞き」に思えたものです。もちろんユーザーの要件をまとめて形にするということは創造的で根気が要る仕事なのですが、マシンパワーを味方にして高生産性を挙げている側から見ると技術的に低レベルの仕事に見えてしまったのです。
結局のところVBの開発では、SEとPGの技術的重要性は五分五分といったところで、どちらがより難しいとも、知性を要求される作業であるとも言えないでしょう。ですからSEさんたちは外注のPGに対して十分な敬意を払ってくれました。仕様の不明点は懇切丁寧に教えてくれましたし、設計のミスにも率直に対応してくれました。わたしたちがいつまでもバグ取りが終わらないときは、自分の責任でもないのに、深夜になるまでじっと作業に付き添ってくれたものです。
VB開発においてSE／PG分業がかえって顕著になった理由は、前述したようなPG作業がアウトソーシングされるという傾向に加えて、 WindowsのUIオブジェクトが煩雑になったため、設計作業と一緒にプログラミング作業を負担できなくなったからということが主な原因だったと思います。すなわちVB開発の元請けは、VBのプログラミングが単純作業だから外注したのではなく、極めて専門性が高い技能だから、社外の専門家としてPGをプロジェクトに招待していたということなのです。
●もっとハイテク、Javaワールド
Java開発では、実装作業はVBにも増して高い技術レベルが要求されるものになりました。Webアプリケーションに必要なのは単にJava言語に関する知識だけではありません。画面を構成するHTML、クライアント・サーバ間の情報をやり取りするHTTPプロトコル、Struts、Springなどのフレームワークの活用法、クライアント画面でのUIを補うためのJavaScript、果てはAjaxによるUIの質的向上まで、（Webアプリケーション開発はPGに）技術の最先端をこれでもかこれでもかというほど要求します。
そしてなによりもオブジェクト指向設計の要であるクラス構成も、事実上PGが設計しなければならなくなりました。SEとPGの間のインターフェイスになるのは、SEが書く設計書――すなわち詳細仕様書ですが、これがVBと同じ画面を中心にした機能定義だけの記述です（注）。この方式では、サーバ側のクラス構成を一切規定できません。というか眼中にない。そもそもオブジェクト指向で設計するとどんなメリットがあるのか、きちんと理解していないSEもかなりいることでしょう。
企業がそれまでメインフレームで行っていた基幹業務を次々にオープン系システムにダウンサイジングしていったわけは、ハードウェアの安さもさることながら、ソフトウェアをオブジェクトとして編成することで再利用性を高めることにありました。メインフレームではすでに大規模なビジネスロジックがソースコードとして実現されていましたが、COBOLの言語的性質から他システムに移植するには多大な困難が伴いました。このため、企業の組織変更や業務の合理化のたびに、大規模なシステム改修のコストが発生していたのです。オブジェクト指向プログラミングはソフトウェアの硬直性を解決するための鍵となる技術でした。すなわち、企業戦略上の重要な条件整備の役割をPGが担うようになったのです。
●こんな「タコ部屋」開発、勘弁して！
にもかかわらず、多くのWebアプリケーション開発の現場では、PG作業の高度な専門性はまったく無視されました。
2003年ごろ、ある大規模なWebアプリケーション開発に参加したときのことです。現場に呼ばれていくと、すでに開発はコーディングたけなわ。 PGが数十人大部屋に集められて作業していました。さっそく画面デザインと機能仕様書が渡されました。画面は数カ所のセクションに別れ、サブミットボタンも数個あります。たいへんなボリュームなのにそれを3日で作れという。
その結果PGはどうしていたかというと、COBOLと同じように、すでに誰かが作ったクラスを流用して手直しして使っている。1リクエストに対して1クラス、それも1メソッドにすべての機能をコーディングしていました。当然メソッドのステップ数は数百に及びます。クラス構成もオブジェクト指向もありません。ただひたすらに急いで作って動けばいいという作り方です。こんな作り方ではかえって工数がかかってしまうのですが、そんなことおかまいなしです。
そのうえ工程管理がすさまじいものでした。正副のプロジェクトマネージャがいて、2人で数十人のPGの進捗を管理していました。当然毎日これに忙殺されます。1日中かかってPGを1人ずつ別室に呼び出し、進捗状況を尋ねます。遅れているなら、なぜ遅れているのか厳しく問いただします。まだ環境に慣れてないなどといいわけしようものなら、「ほかの人はみなこの効率で仕事をしています」と圧力をかけてくる。まるで捕まって取調室に呼び出されたコソ泥のような気分でした。
このような開発でできたソースコードは硬直的で、再利用性が悪く、どんなリファクタリングも受け付けないでしょう。この仕事を請け負ったSIerは、目先の開発効率に気をとられてかえって非効率な作りこみをしてしまったばかりでなく、アプリケーションの将来的なコストまでも大幅に引き上げてしまったのです。さすがにこのような開発を強いられたのはこのときだけで、これ以後こんなタコ部屋開発は経験したことがありませんが、もしかしたらまだどこかで、外国人PGを集めて同じ様な作り方をしているところがあるかもしれません。
●IT技術の空洞化
JavaによるWebアプリ開発でPG作業が軽視されている傾向は現在でも一向に変わりません。かえって強くなっているくらいです。特に大規模なアプリケーション開発では、いっそうそれが激しい。ということは、社会的に重要なシステムほど粗悪なプログラミングがなされている可能性が強い。事実わたしがうわさに聞く話では、あの大企業のシステムがそんな状態なのかということが多いのです。これは日本のIT産業におけるソフトウェア設計技術が構造的な原因から空洞化していることを意味しています。いくら見かけのドキュメントを整備しても、それは顧客の要求だけが精緻に文書化されたというに過ぎず、それによってソフトウェアの品質をコントロールしているわけではありません。大事なことはソースコードの品質なのです。にもかかわらず今日のIT業界は、ソースコードの品質を向上させるどころか、かえって悪くする方向に向かいつつあります。いったいなぜでしょう。
前回も触れましたように、「PGは労働集約型の単純作業で、SEこそが高度な技術を担う職分だ」という、1960年代の職制がアウトソーシングによる固定費節減戦略に誤って適用されている傾向が、その原因の1つです。何度もいいますが、本来ソフトウェアの作成という仕事は設計とコーディングという作業に明確に分けることができません。それを無理やりに分けようとするなら、ネット社会を形成してきた数々の技術革新の成果はすべてPGに残り、SEはそれらから完全に疎外されることになりかねません。
●SEの悲惨
下請けSIerは、SEのほうがPGよりも作業単価が高いので、自社の社員をなるべくSEにしようとします。入社してまだ1、2年の若手をSEと称して元請けの現場に送り込む。そんな未熟な技術者に設計作業が務まるでしょうか。務まるのです。彼らに与えられる仕事は、顧客の要望を聞いて仕様書にまとめるだけ。プログラミングよりかえって簡単なくらいです。しかし、そのことで派遣されたSEのスキルに与える悪影響は計り知れません。彼が強いられるのは果てしないユーザーの要求変更をドキュメントに反映させる仕事。ドキュメント変更のたびに長い長いレビューが開かれて、それだけで精力を使い果たしてしまいます。設計に携わることで得られるはずの業務知識も、実際には切れ切れの断片に過ぎず、体系的な技術にはならない。知識として整理する余裕もない。
例えば企業の会計システムを作るとします。その設計に携わって企業の会計を知ることができるようなSEがどれだけいるでしょう。会計の知識はそんな甘いものではありません。大抵はすでに会計の知識を持っているSEが全体を決めてしまって、業務請負で派遣させられたSEはその下働きをさせられるのです。SE作業があまりに非効率で膨大なため、本来の設計作業に参加するSEと、「仕様書書き」という単純事務作業に従事するSEが分離しているのです。長い忍耐の末、下働きSEが獲得できる業務知識とは何でしょう。知識の断片で仕様書を書いたというだけのことです。その結果ほとんどのSEは業務知識からは疎外され、実装技術の習得からも切り離されてしまう。現実的なスキルを何も持たないSEが大量に作られる。
●PGのスキルも劣化
SEの技術がだめになると、PGの技術も同時にだめになります。社内で評価されない職種に誰が労働意欲を感じるでしょう。長時間労働に身をすり減らし、おのれの技量不足に打ちのめされ、少なからざる新人が脱落していきます。残った者は1日でも早いSEへの格上げを待ち望んでいるばかり。ごく少数のPGは実装技術の重要性に気がついて実装セクションに残ろうとしますが、そんな「変わり者」のキャリアパスを許容してくれるのは、人件費に余裕のある大企業だけです。大きな会社では（SIer以外でも）IT関連部署に、いかにも「ハッカー」のにおいをぷんぷんさせた猛者がいたりするものですが、開発技術者の供給源である中小SIerでは、人員に余裕がなく、いつまでもPGとしてモラトリアムさせてもらえないのです。それでも実装作業に残りたいという人間は、契約社員になるか、わたしのような個人事業主になるしかありません。わたしが知っている中で優秀なPGと思えた人は、みな大企業の片隅で仙人のようになっているか、会社を飛び出して一匹狼になっている人でした。高度な技能の持ち主も、正当に評価されなければこのような生き方を選ばざるを得ません。
結果、SIerの社内にはPGがいなくなります。いったいSIerはこれでどうやって開発作業を行うつもりなのでしょうか。いざとなれば外注すればいいと思っているのでしょうけれど、ほかの会社でも同じ方針を採っているのですから、派遣されてくるPGのレベルなど推して知るべしです。低レベルのSEの設計で、未熟なPGが実装する。当然低品質の製品が作られる。ソフトウェアには形がないので、表面上機能すればユーザーからは苦情をいわれない。それを繰り返すうちに、業界全体が急速に必要なスキルを失っていく。度重なる銀行や交通機関のシステム障害の背景には、このような技術空洞化の構造があるのです。
●技術を甘く見るな！
話が長くなりました。そろそろまとめに入りましょう。現在のIT業界で「SEとPGのどちらが頭がいいか」と問われたら、「どちらも頭は空っぽだ」と答えざるを得ません。これは技術者個人個人の責任ではありません。明らかに企業のアウトソーシング戦略の結果です。単に頭が空っぽなだけならまだしも、このような技術者が多数派になってしまったおかげで、技術に対する浅薄な侮りと無知が蔓延（まんえん）するようになってしまいました。
こんなことをいっては「上流」にいる方々には失礼かもしれませんが、IT業界は上流にいるほど得になるような構造になっています。それぞれのプロジェクトについて自分のところで十分な経費を確保してから下流に流しますので、下流にいるほど仕事がきつくなります。それをうすうす感づいているから、若い人は少しでも上流に行きたがります。PGをしばらく勤めたらSEに、SEを少しやったらコンサルに。産卵まぢかの鮭でもあるまいに、自分の技術レベルも分からないまま、やみくもに次のステップを目指そうとする。会社も上流の方が単価が高いので、スキルも経験も関係なく自社社員を格上げする。その結果、技術力のない技術者が泡のように上へ上へと浮かび上がってくる。こんな技術者はそれぞれの工程できちんとした仕事をした経験がないので、自分のスキルさえ認識できない。ドキュメント作成が仕事だと思いこんでいるコンサルタントさえ出てくる。まさしく、同じエンジニアライフ コラムニストの林さんがコラムで嘆いている通りです。
この技術軽視の傾向がIT業界をどれほど蝕んでいることか。たんに若者のインセンティブをそぐばかりでなく、IT業界に対する一般社会の信頼を大きく損ねつつあります。世間は度重なる銀行や交通機関のシステムトラブルを大目に見てくれるわけではありません。このまま技術空洞化の傾向が続くなら、「ITは見かけ倒し」という評価が固まってしまいます。そうなれば企業はITへの設備投資自体を手控えるようになるでしょう。そうなってからでは遅いのです。
SIer経営者の方に申し上げます。SEとPGの分業は実際の作業で不要な障害を作ってしまうばかりでなく、SEを技術のイノベーションから疎外し、スキルに悪影響を与えます。さらにSEには期待するほど業務知識は蓄積されません。もしSEに業務知識を持ってもらいたいなら、お金をかけて教育しなければならない。極端なことをいえば、MBAを取りにアメリカに留学させるくらいの覚悟がなければ、ろくな知識は得られないのです。
また、PGの作業を低く評価し、外注で調達しようとすることは、社員に与えるべき貴重な開発経験を外注業者に流しているも同然です。コーディング作業のオフショア開発を増やしたりしたら、それこそ日本のIT産業の基礎をスポイルすることになりかねません。実装作業をアウトソーシングするという経営方針は決定的に誤っています。SEもPGもわけ隔てなく、固定費でもってじっくり育てていかなければならないのです。
上流を目指す若手技術者の皆さん、自分の技術を過信してはいけません。あなたのいる業界は、PGを2年勤めたら自動的にSEに、SEを3年勤めたらコンサルになれるというような甘いところではありません。年功序列は通用しないのです。この＠ITなどを参照して、つねに自分のスキルを自分で測り、自己研鑽に勤めてください。会社の評価を真に受けてはなりません。悲しいことにいまのSIerは社員をじっくり育てていくという資金的余裕も能力もなくしているところが少なくないようです。あなたがSEとしてどこかに派遣されたとしても、それはあなたがSEとして十分な技量を持っているということにはならない。単に会社の都合で未熟なあなたをSEとして送り込んだのかもしれません。そして派遣先でさせられる作業は、あなたの技術力にほとんどプラスになりません。派遣先では、基本的にあなたに単純作業しか期待しない。あなたが自覚的に自分のスキル向上に努めているのでもない限り、あなたのスキルは空っぽです。そんなあなたがもし30歳ぐらいになって会社にいづらくなったとしても、すぐに辞めてはいけません。それは単にあなたの年齢とともに給料がかさんだので、じつは単純作業以外何もできないあなたを追い出したがっているだけかもしれないのです。
こんなアドバイスをしなければならないこと自体、実に情けないことです。
コメント
インドリ
今回も興味深く拝見しました。全体が良かったのですが、中でも言語別の状況分析が非常に良かったです。私にとっては斬新な切り口でした。
それにしても、本当に技術軽視なこの構造は問題ですよね・・・
「OS実装からシステム構築まで」と職人を目指す私としては生き辛くて仕方がありません。でも、他の業界の人も馬鹿ではなく、何時までもこの馬鹿げた事実が放置される事はないでしょう。その時に社会から必要とされるは我々の様な職人（真のプロ）です。
まやかしが解けるまで、一緒に頑張りましょう！
ドイツ
大変面白い記事でした。
自分も同じ業界に身をおくものとして、感じているのですが、
こういう業界のゆがみでプログラムできないSEが増え、さらに
管理者が増えていくと、 管理者>=作業者(プログラマ)
というおかしい状態になるでしょう。
モノを作ることが基本なのに、管理者のほうが多いなんてへんです。
サッカーで、プレイヤーより監督やコーチのほうが多いなんてことなるような。
スポーツの世界ではありえないことです。
くり
大変共感する記事でした
現在、私はPGとして中小企業に籍を置いています
契約期間単位で次々と現場へ派遣されています
元々、製造が好きでプログラマとして一流を目指していたのですが
会社としては許してくれない様です
また、現場現場でプログラマが軽視されているのはヒシヒシと伝わります
不十分な基本設計書を元に一々確認しながらコーディングするのは時間がかかります
逆に、プログラム経験のある方の設計書は明確で製造が楽です
最近、将来の自分像が不安です
このまま会社の流れにのって単価上昇の為製造から離れていくか
フリーになって製造を続けていくか
年齢も30前半でかつ女性でもあるので、厳しいものです
結婚しても好きな仕事をしたいと思っているのですが。。。。
しん
SEが仕様書（日本語レベル）を書いて、
それ以降の詳細設計書、製造、試験はすべてPGが行う。
これが理想かな。
一般的にはSEが詳細設計書を作るのだろうけど。
（下手なSEが詳細設計書を書いても品質は期待できないし、
そもそも詳細設計書に全て書ききれない。）
でも最近の現場では詳細設計書は
ほとんど書いていないですね。
ざっとクラス設計（UML）くらいはしますけど。
開発期間が短いから詳細設計に稼動かけないプロジェクトが
多い気がする。
ほり
面白いコラムでした。
個人的には半分賛成、半分反対と感じています。
PGが軽視されすぎに関しては、全面賛成ですね。
優秀なPGが少なくなってきている要因かと思います。
（よく見られる、下請けへの丸投げ体質も問題ですが。）
ですが、JAVA（特に大規模アプリ）での開発でPGがさらに軽視され、
粗悪なプログラムが生産されているとの点には疑問を感じます。
まず、大規模アプリではFWや規約をきっちり整理し、
PGの負担を軽減できる環境を作っておくべきだと考えます。
ですので、そこまで優秀なPGが必要でないため、
必然的にPGが軽視されているのかと思います。
（その環境が作れないのでは、何のためのJAVAか。
オブジェクト指向かと・・・）
また上記の考えを元に、粗悪なプログラムが生産されているのであれば、
それはPGよりもPMに問題があるのではないかと思います。
最後に１点。
「UMLは開発者間で仕様を確認するための方法」
に関しては反対意見を。
確かに、クラス図やシーケンス図単体だけを見ると、
そのような扱いかと思います。
ですがUMLの強みとして、ユースケース図などで要件を整理し、
詳細仕様や設計に落とすに連れて、前後関係を紐付けながら
アクティビティ図等を使用してユーザには分かりづらい内部設計を、
要件からトレースできる事でもあると考えています。
（悲しいかな、現実問題それを意識して使えているプロジェクトは
大変少ないとは思いますが）
以上、長文・乱文失礼いたしました。
PM
そもそもアプリケーションの実装は、少人数チームでやるのが理想ではないでしょうか。
レビューや、設計会議は、こんなことを言うと何ですが、個々の実装者がやるべきことで、人間が介在すると、必ず、議論が起こり、考えがまとまらない。
その結果、時間を浪費し、納期の遅れや、品質の劣化に繋がると思います。
実装の簡単なスクリプト言語が、どんどん普及することにより、
ソフトウエア業界の「暗雲」が消え去る日を、待ち望んでいます。
人間を幸せにするのが技術であり、「良い技術は人を不幸にしない」のです。
某MS社などが提供する某フレームワークのクラス階層は複雑で、
余りにもまとまっていない、と感じます。
Object指向開発の特徴として、どんどんクラスの数が増えてゆく、
という問題があると思います。
それでも間に合わず、独自にクラスを実装しなければならないこともあります。
Object指向開発自体が、もはや転換点に来ているように思います。
本当に、データと手続きは一体なのでしょうか？
「そうでなければならない」ではなく、
「そういう考えもある」という柔軟な思考ができるスクリプト言語
に、期待しています。
状況は無数にあり、変化にいち早く対応するには、やはり、少人数のチームが小回りが利くと思います。
とても興味深く読める記事でした。
個人的にはいまだ『タコ部屋』な開発を繰り返している現場もあると思います。
私は自分のスキルを過信するどころか不安だらけです。
というか本当に穴だらけだと思います。
しかし日々の作業においては要求されなかったり
@ITを見て研鑽を深めたくても昨今のセキュリティ云々でサイトが
見ることができなかったりとなかなか学習機会を得ることができません。
もっと会社内でどうしたら技術力が高まるかを考えて
開発をしても良いと思うのですがよそから来た末端PGと
天狗になってるSIerのSEとではなかなかうまく行きませんね。
日本のIT会社組織をぶっ壊したいです。
hirofumi
全くその通りです。あなたのおっしゃる通りです。
個人的には、大いに共感しました。
ここにある「仕様書書き」に徹するSEはまさに5年ほど前の私そのものです。
地場大手のSIer勤務でしたので、多くはメーカーの一次請けでした。
メーカーは案件丸投げ→ご用聞き状態のSE（私）→派遣中心のSIerのSE（実質的に設計）→中小ソフトハウスのPG（実装）といった感じでした。
もちろん、開発言語はVBです。当時は6.0でしたか…
顧客の業務を知らない、ご用聞きしかできないSEの末路はどうなったでしょうか？
結果的に、ガタガタのままシステムは構築されていき、最下流のPGから突き上げられます。
もともと、就職氷河期で地元に残るためにやむなく選んだSEの道でした。
モチベーションはみるみる間に下がり、社内に頼る人間のいない私は、
結果的に中間のSIerのSEに頼り、最下流のPGの「言いなり」となって完結させました。
その後、うつ病に陥った私は、職場を転々とし、完治まで3年かかることとなりました。
最後は、非正社員ですが異業種の事務職へ転職して、今に至ります。
正社員の職を求めていますが、このご時世とSE時代の職歴の汚点が大きく、苦戦しています。
もしかしたら、私の同じような「名ばかりSE」はババ抜きのババを引かないように、
毎日必死に繕っているのかもしれません。
結果的に、ババを引いてしまった私は、自らの頭が空っぽであることに気づかないまま、
精神が蝕まれていき、空っぽのまま理想を求めて迷走したのかもしれません。
「自己責任」と言われれば、返す言葉もありません。
（小泉政権下の自己責任論に則った思考は大嫌いですが）
せめて私に言えることは、「名ばかりSE」になってしまったら、
早いうちにこの構造に気づいて、技術者として技術を磨く道を見いだすか、
この業界から足を洗い、社会人として一からやり直すことを強く勧めます。
30歳近くになって、気づいてからでは遅いのです。
悔しいですよ。本当は。
ii-
まったく共感です。
PG軽視の傾向はどこも同じなのですね。
私は逆に開発工程でなんとかがんばろう！と思った
稀な人間ですが、日々心が折れそうになるのを耐えている状態です。
やはり変えるなら下流より上流かなと。
将来を考えると本当に不安だらけの業界ですね。
三十路前の女性にとっては、昇進の話が来ると、
余計に希望を感じられなくなります。
面白い仕事なはずなのに、はがゆくて仕方ありません。
local_ojisan
大変興味深く拝見いたしました。私は汎用系がほとんどだったのですが。。。
ＳＥとＰＧ・・・１５～２０年くらい前までは明らかに前者が優位ではありました。
当時は、ユーザへ出向して設計業務をこなすと云うのは、現在と違って受託開発が主だったのです。
自社にはＰＧが控えており、ソフトハウスとしては製造物件を請負う必要がありました。
若手に実戦経験を積ませ、後続ＳＥを育てて企業発展してゆく、と云うのが通念でしたので。
当然、メンバーには出来高制で契約するＰＧオンリーの荒稼ぎする猛者も結構、居たりしたのですが。
云うまでもなく、優秀なＳＥレベルの方々ですよ。
ところが、情報産業が花形になってきてから人手不足が顕著になり、標準化が促進したのですが・・
某社で多重派遣による酷使が起こり、社会問題になりました。
それで派遣法が施行されたのですが・・間もなく派遣業が全盛を迎えました。
多くのソフトハウスも派遣出向の方が楽ですので同調してしまいました。
開発の難度はユーザ環境に左右されるので、日が経つにつれ出向者は時間請負が当たり前になりました。
受託の意識は薄れ、どこの社員だか判らないようなサラリーマン感覚の出向者が多数を占めるようになり、
平和ボケするようになったのではないでしょうか？（正直、私もその恩恵？は受けましたが。。）
汎用系はマシンを始め維持費も高いので、ユーザ経営者層からは「金喰い虫」と呼ばれていました。
バブル崩壊後はかなり負担だったでしょう。なんとか経費節減できないものかと。。
そこへＩＴ産業がデビューしました。ＰＣ化への期待は加速度を増し、順風満帆で現在に至ります。
汎用系とＩＴ系は開発概念が大きく異なり、前者はトップダウン指向、後者はボトムアップ指向です。
オブジェクト指向なるものは、汎用系ではＰＬ／ＩのＯＮＣＯＤＥ機能が該当します。
Ｊａｖａなどの書籍を読んでいると、多くの概念が今思うと、ＰＬ／Ｉにヒットしているのです。
もしかしてＰＬ／Ｉって・・オブジェクト指向の母体？なんて思ったり・・・
でも、ＣＯＢＯＬ８５（ＰＬ／Ｉ機能のいいとこ取りをしたのだけれどもメンテ上からほとんど活用されていない？）
が出てからは導入ゆるユーザが激減したようですが。。。
ＰＬ／Ｉ経験者でもＣＯＢＯＬ的にコーディング規約が構えられているので、汎用系技術者はＩＴ系感覚になじめない人が多いようですね。
さらに中高年に達しているでしょうから、給与面からもＳＥ業務に進んでしまい、ＩＴ系のＰＧ感覚は育っていない。
プッツン状態になっていて情報交流が乏しい。おかしな世代交代が起きてしまった、と感じていますが。。
ところで今、ＰＣ－Ｃｏｂｏｌ系がチラホラ出てきてますね・・
業務開発系は、いずれＣｏｂｏｌ系になると予感していますが、どうでしょうか？
Ｃ系なら、後続のＣ＃でしょうかね？
Ｊａｖａって、そもそも電気機器の制御用に開発された言語のようですし、用途が違うんではないんでしょうか？
むしろ、よくここまでＩＴ向けにも育ててきたよな・・って感じなんですが。。
いずれにしても・・・どなたかのコメントにもありましたが、オブジェクト指向の過渡期になってる気がします。
脱線しまくってしまいましたが、ホントにいい記事ありがとうございました。
local_ojisan
再度の寄稿です。
ＩＴって用語・・情報産業全体を指してるんですねｗ
日本人特有の飾り好きな国民性を感じますね。。
簡単な概念をやたら難しく伝えようとして人材を発掘しにくくしているようにも思うけど。。
で・・ＳＥはシステム全体が企業方針にマッチするように配備するゼネラリスト、ＰＧは機能がより完璧な動作をするように実現するスペシャリストってのが役割ですが。。。そもそも比較できないのが本来の姿だと思いますが・・・日本ではね。。
それと人体組成に例えれば・・現代では、経営層が脳機関であるならば、コンピュータは心肺機関ですよね？全機関に上下の差はありませんが、何らかの情報を得て活動を起こすのが生物なのですから、コンピュータの果たす役割は絶大な筈。。
しかしながら・・それを軽視してきたのが瀕死にあえぐ日本ユーザではないのでしょうか？まぁ・・なるべくしてなったな、と感じていますが。。
技術国ニッポンが生命線なのにね。。
情報産業の従事者が正当な評価を受ける社会になるのを願うしかありませんが。。
皆で声を大にして再技術立国を目指すのが日本を救う道かもですね。
あいにく私は高齢者で疎外される身なので傍観しているしかありませんが、皆さんには頑張っていただきたいな・・とエールを送りたい気持ちです。
ユーザの方々には・・経費節減よりも投資発展の感覚を持たないと日本沈没になりますよ・・と。古代文明国家ニッポンが目に浮かんできます、最近。。
失礼いたしました、これにて。。
ntk
10年前にこの業界に入ったときからPGが低く見られているのが不思議でした。
今では、この業界は人月でしか仕事を評価できないから下流の生産性の高いスキルを正当に評価できず、結局上流にいくほどお金になる構造が定着していると私は分析しています。
PGからSEになって、次はPMかコンサルかアーキテクトにならないと給料が上がっていかないなんて、ドラクエみたいな仕組みでちょっと笑っちゃいますね。
似非PM、似非コンサル、似非アーキテクトばかり作ってどうするんだろう？
t_zhuangzi
まったく同感です。
二十数年前に、米国ベンチャーと共同開発プロジェクトに
参加したことがありますので、その時の印象をまとめます。
チームサイズは、20名程度で1年弱程度のプロジェクトでした。
バイトコードインタープリター（SMALLTALK,JAVA等）をベースに
開発基盤をプロトタイプするプロジェクトでした。このチームには、
そもそもSE/PGなどという考え方がありませんでした。1名のチーフ
デザイナー（＋サブチーフ）と各開発パートの責任者で構成されて
いました。（※日本から初心者プログラマ－をつれていきましたが、
基本的には各責任者のアシスタントでした）
チーフデザイナーが全体の枠組み（アーキテクチャー）を定め、
各パートの責任者は、持分のデザイン、実装方針等の策定を行い
ます。これをミーティングにてプレゼンテーションをおこないます。
チーフデザイナー及び関連するメンバーが合意すれば、実装（詳細設計、
プログラミング）に入っていきます。仕様変更等については、各責任者
が、メンバー間の調整、合意の取り付けを行います。もちろん、議論が
収束しない場合は、チーフのおでましですが．．． また、印象的だっ
たのは、プロジェクト開始前に、かなり厳密なターミノロジーの定義が
行われたことです。知らないもの同士が、プロジェクトを組む場合には
重要なことかもしれません。
ほとんどのメンバーがプログラミングをしますが、メンバーの中核は
４０歳前後のひとだったように記憶しています。中には、休日に
UNIX関連講習会の講師のアルバイトしている人もいました。親しかった
社長は、「俺より給料が高い奴がいる！」とぼやいていました。
振り返って日本ですが、日本のソフトウエア産業は、記事に記載されて
いる問題を抱えていると思います。２点、指摘したいと思います。
１．米国では高級取りのプログラマーを支えることのできる、付加価値の
高い事業を経営者が志向しています。MS, GOOGLE等は、あきらかに米国の
基幹産業といえると思います。これに比し、日本のソフトウエア産業
は、他産業の外注産業でしかないのかもしれません。
２．日本には「ソフトウエア開発のプロセスが工業化できる」との神話が
あると思います。これは、日本が世界に誇る製造業を抱えていることと
無縁ではないと思います。しかしながら、ほとんどの開発プロセスを
人力に頼っているプロセスを「工業化」することは至難のわざと思います。
自動車の場合と異なり、工作機械、ロボットなどを使うことができません。
また、生産性、品質の面でも、開発者により、雲泥の差があります。
「工業化」には、各プロセス／部品の品質・生産性にバラツキがない
ことが前提になりますので、この面でも難しいと思います。先の
米国人プロフェッショナルプログラマーは、SE/PGで構成されたチームに
比較し、数倍（上記のような難易度が高い場合は十倍以上？）の
生産性の開きがあるように感じます。
まとめです。
１．日本のソフトウエア産業は、高付加価値の領域にチャレンジすべき。
また、この方向の経営努力が必要と思います。
２．「安価な労働力を調達し利益をあげる」という考え方を捨てるべきだと
思います。しかるべき人材に応分の給与を支払ったほうが生産性は高くなると
思います。
※ソフトウエア産業は、製造業、人材派遣業、建設ゼネコンのいずれでも
ありません！ 安い労働力に胡坐をかくような企業は必要ないと思います。
以上です。これを書いて気持がすっきりしました。
茶
非常に興味深い記事でした。
私も同じ業界にいる者、といっても新参者ですが、
現在の自分のこれからのキャリアに、感覚的ですが不安を感じています。
誰にでも一朝一夕でこなせる事ではないのに、軽視されるというのも
変ですし、何より自分の好きな事が軽視されるって切ないですね。。。
中村 康政
マイクロコード 中村と申します。 はじめまして。
つい最近、個人事業主として立ち上げたばかりです。
一見、幼稚ともとれる表題ですが、熱い語り口に感心いたしました。
最後はきちんとした理由付きで、PGもSEも・・・とくくられていた
ところに、思わずニヤリ。
先輩エンジニアである後藤様から、将来をしょって立つ若い
エンジニアに向けての熱いエールに感激いたしました。
また、彼ら後輩の考えや不安要素を聞き出すヒントもいただきました。
ありがとうございます。 後藤様の今後の連載を、影ながら応援しております。
iccha
後藤様のご意見に共感します。
私は40代男性ですが、主にJava開発環境でPGをしております。
職務上、毎日 客先の情報システム部に常駐してSE作業やコンサルティング
さらにはITコーディネーターもどきの業務をこなしております。
つまり何でも屋です。
Java環境で大規模開発された業務システムを保守する立場でもありますが
保守する立場になってやっとプログラム再利用の重要さを実感できるようになりました。
若い頃、保守未経験で開発だけをしていた時期は、上流SEの指示のまま
短い開発期間で、正常にパフォーマンスよく動けばよいだけのプログラムを
大量生産しておりました。
ですが、一度作った大規模なシステムを１０年にもわたって保守継続させるため
ホスト廃止など周りの仕組みの変化に対応できるように
当該システムのインターフェースを変えていく立場になってはじめて
過去の自分は誤った開発をしていたなぁと深く反省させられることがしばしばありました。
それはさておき、私にとって今は、RDBを捨てて、キーバリュー型のBigTableに挑戦する時期です。しかし、今まで慣れ親しんだ仕組みから脱皮するのは大変なパラダイムシフトが伴います。
でも成功した時の成果の大きさを夢に抱ける記事をたくさん目にしますので実現に向けて奮闘する毎日です。
なにしろ、開発者個人が強力なスポンサーをバックに付けたのと同じくらいのパワーを得ることができる時代になったのですから。
職人プログラマーにとってビジネスチャンスの可能性がまた近づいたと実感しております。
有難う御座いました。
よし
Windows8でのVB6サポートから流れつきました。。。
まさか、こんな話にたどりつくとは思いませんでした（笑）
過去の記憶を思い巡らすと、思い当たることが多々ありました。
VB6のサポートについて、日本のIT業界の構造が良くないことは理解できました。
しかし、VB6のサポートとは別問題です。
まだまだ、VB6は現役でいる必要があります。
.Netが10年超えたとしても。
ソフト開発には、おおくの“手”がかかります。
過去のVB資産も、.Netへつながる言語仕様の互換もありますしね。。。
ウィル
日米両方のソフトウェア業界を経験したものです。アメリカで３年ソフトウェアエンジニア（プログラマー）として働いていますが、未だ日本記事のような状況が日本で続いているとしたら今すぐ辞めるべきです。理由は本記事に書かれている通りですが、プロジェクト効率が非常に悪い、すぐに御用聞き（SE）になってしまうので本当に意味での技術者が育たないです。
恐ろしいことにプログラムを一度もしたことがないSEが何人かいましたが、厳しいですが全員プロジェクトにマイナスの影響を与えていました。
SEの方はプログラマーに回帰すべきです。もしプログラマーというイメージが「下流」と定着しているならアメリカの用語を借りてソフトウェアデベロッパーやソフトウェアエンジニアという言葉でSE/PGを統一すべきです。
はじめ
この記事から10年以上経過しても、全く共感出来る状況です。むしろ悪化しています。仙人たちもいなくなり、優秀な若手はスタートアップへ、優秀な中堅技術者はどこにもおらず、逃げ切りを決めた管理職と、技術者だったことなどないSEと、そもそも仕事に興味のない若手しか残っていません。
kenchan
この記事が書かれてから15年が経ちました。
みずほ銀行のシステム障害に羽田空港の運航予約システム障害、中盤でおっしゃられたことがまるで予言のように発生しています。
まったくもって頷ける内容です。インドやベトナムへの海外アウトソーシングまでもが流行し、
技術の蓄積の機会を海外に明け渡し、優秀な技術者はGAFAか上流工程に流れ
挙句の果てSEと呼ばれる人間が写真撮影加工や介護施設やジムのトレーナーなどに転職し
業界から身を引く事態にまでなっています。
もはやこの国のIT組織に未来はないでしょう。共倒れするのが目前に見えています。
ただただ残念で、悔しくて、やるせなくて仕方がありません。