個人事業主にしてベテランプログラマー。人呼んで「IT業界の小関智弘」(?)

SEとPG、どっちが頭がいい?(1)

»

 ちょっと刺戟的な題名をつけました。しかし決して挑戦的な意図があるわけではありません。SEとPGの分業がIT業界にもたらしている問題が今回のテーマです。

●SEとは何か、PGとは何か

 まずそれぞれの職分を正しく認識することからはじめましょう。プログラマ(PG)とはどういう仕事をする人たちでしょうか。

 いうまでもありません。プログラムを作る人たちのことです。大工さんは家を作る人、漁師さんは魚を取る人。こういった人々と同様にPGもその仕事の内容から自明です。

 一方SE――システムエンジニアの方は必ずしもそうではありません。システムのエンジニア? システムの技術者? ひどくあいまいな言葉です。この言葉はじつはもともと英語ではなく、「OL」などと同じ和製英語だといわれます。海外のコンピュータ技術書にもSEという言葉はほとんど見かけません。日本人が適当に言い始めた言葉だとしたら、あいまいなのも当然です。

 それではなぜ日本ではこんな言葉が使われ始めたのでしょう。これは思いっきり個人的意見なのですが、SEは日本にソフトウェア産業が勃興したとき、終身雇用と年功序列型のキャリアパスという企業風土の特色から生まれた日本独特の職種だったのだとわたしは考えています。

●わたしが受けた新人研修

 ちょっと昔のことをお話ししましょう。わたしのIT業界歴は1980年代後半、大学を卒業して、さる金融機関系のソフトウェアハウスに就職したことに始まります。銀行系の子会社のそのまた子会社でした。当時は銀行の第3次オンライン開発というのがあって、ソフトウェア業界は大量に人手を必要としていました。このことを世間では「ソフトウェア危機」と呼んでいました。わたしはそのとき大量に採用されたSE要員の1人です。

 同期の約6割は2カ月のCOBOL研修を受けて現場に配属されましたが、残りの4割はさらに2カ月間のSE講習を受けました。このSE講習、内容はどういうことかというと、一言でいうなら、主に各プログラムをどのように組み合わせて1つの流れにするかという技術です。すなわちこのとき教えられたSEの仕事とは、処理全体の機能を考えて、各ステップの機能を設計し、仕様書に書くことでした。PGはその仕様書をもとにプログラムを作るという分担です。簡潔で一見何の問題もないように見えました。

●いざ現場では

 しかし実際はこの分業は十分に機能していませんでした。SE講習が終わって現場に配属されると、現場のSEはPGをぜんぜん信用していませんでした。PGに仕事をまかせず、全部自分でコーディングしていました。そうした方が早いし確実だというのです。派遣されてきたSEほどその傾向が強かった。おそらく派遣SEさんたちはプロパー社員以上に作業効率を求められるので、プロパー社員の新米PGなど頼むに値しなかったのでしょう。

 当時わたしたちの会社ではプログラミング作業を集中管理して効率を上げようという目的から、「ソフトウェアセンター」という部署を設け、社内のPGを一カ所に集めて作業させる試みを始めていました。ところがSEさんたちはそこに仕事を注文しないで自分たちで作ってしまうのですから、部長は当然渋い顔です。しかし実際問題、そうやってソフトウェアセンターに集められたPGは、仕様書がよくわからないと文句は言うし、テストはいい加減だし、少しも効率は上がりません。よく考えてみれば、このソフトウェアセンターという組織は、企業の中でオフショア開発を始めてしまったようなもので、うまくいくわけがないのです。2年もたたないうちにこの組織は取りやめになりました。

●技術革新は職制を変える

 どうしてこのようなギャップが生まれたのでしょう。わたしが考えるところはこうです。

 わたしが最初に受けたCOBOL講習では、コーディング用紙を使って手書きでプログラムの作成を行っていました。まず原稿用紙のようなマス目の並んだコーディング用紙に鉛筆でソースコードを書き込むのです。それを外部の業者がパンチカードに打ち込み、上がってきたカードをPGが原稿と1行ずつ照合します。打ち間違いがないことを確認すると、データカードと合わせてカードリーダーにかけて機械に読ませ、テストを実行する。バグがあったらカードを抜き取り、自分で打ったカードと差し替える。このような作業環境では、プログラミングとはかなり手間のかかる根気の要る作業でした(このような環境でどうやってデバッグしていたのでしょう?)。

 このような作業をしなければならないのだとしたら、PGとはそれなりに意味のある職分だったでしょう。しかしわたしが実際に現場に配属されてみると、誰もこんな作業はしていませんでした。当時はすでにタイムシェアリング端末によって、SEもPGもエディタが自由に使えるようになっていました。みんなライブラリにアップロードしたソースを自分で手直ししています。そもそも誰も一からプログラムを書いたりしません。みなどこかから似たようなロジックのプログラムを探してきて、部分的に手直しして作ってしまいます。それが一番手早くてバグの起こらない方法だからです。

●形骸化したSE/PG分業

 タイムシェアリング端末という新しい道具がSE/PG分業を時代遅れなものにしてしまっていたのです。コーディングはSEが自分で行っても何の負担にもならないし、むしろPGに依頼すると、仕様を理解させる過程でコストとリスクが発生します。自分でしてしまった方がはるかに生産性が高く確実でした。設計と実装を区別することは現場では事実上、形だけのものになっていたのです。わたしの会社はソフトウェアセンターを廃止すると同時にSE/PG分業を廃止すべきでした。

 ところがそうはなりませんでした。SEという職種は頑強に残り続け、SEを技術的にPGの上位に置く考え方はなおも業界の常識として残っています。これには単にSEとPGの間の関係だけではない複雑な背景があると、わたしは考えています。

●アメリカではPGはえらい

 アメリカではプログラムを実装する人も設計する人もprogrammerと呼ばれます。そもそもPGの社会的地位が高い。プログラミングは大学ではアカデミックな研究の対象です。大学の先生が書いた優れた学術書が何冊もあります。

 COBOLの開発者グレース・マレー・ホッパーは、女性で、軍人で、最後には准将になって、彼女の名前がミサイル巡洋艦に付けられるまでになりました。PGの扱いは日本と外国とでは天と地ほども違うのです。これは、コンピュータ技術の発祥地アメリカではハードウェアとソフトウェアの重要性が同等に評価されて、コンピュータが総合技術として発展してきたことが背景になっているのでしょう。PGを単純労働だなどと誤解する余地などなかったのです。

●産業界とSE/PG

 日本でコンピュータが商業利用され始めたのはIBMの360が普及した1960年代だと思われます。当時日本ではソフトウェアに対する理解が薄く、 OSから言語処理系から基本ソフトウェアを全部アメリカに依存していました(これは今も同じですね)。ソフトウェア製造については学術的な蓄積はなく、ビジネスソフトウェアの作成は企業主導で行われました。そのとき企業の管理者には、コーディング用紙とにらめっこしながらパンチカードの束と格闘しているPGが知的労働者には見えなかったことでしょう。COBOLのプログラムはいくつかのパターンが決まっていて、それを適用して量産することもできました。これゆえ日本の産業界ではPGは「単純労働者」と位置づけられてしまったのだと思います。

 日本の企業は最近まで終身雇用制だったといわれます。それが崩壊して今日さまざまな雇用問題を引き起こしているわけですが、しかし終身雇用制が健在だった時代も、すべての雇用者が定年まで働くことができたわけではありません。業務形態によりますが、単純作業労働を大量に必要とする産業では、比較的賃金の安い労働者を雇用して働かせる必要がありました。そのため企業は、若年者の賃金を低く抑え、一部の従業員には勤続年数が上がって給料が増える前に辞めてもらうようにしていました。

 この雇用形態にぴったりはまっていたのが女性労働者です。女性は雇用されても男性と同じキャリアコースに乗ることはなく、 30歳前には結婚して退職することが暗黙の了解となっていました(いまだにそのような風土を残す企業もあるかもしれません)。企業は「結婚=女性の幸せ」という価値観を利用して一部の単純作業労働者を辞めさせることで、終身雇用という建前を守っていたのです。

 かつてはソフトウェア開発もこのような形態をとっていました。わたしが就職したときには、PGとして働いていた社員の半数以上は女性でした。今では考えられないことです。彼女たちは非能率なパンチカードによるコーディング作業を黙々とこなし、5年も勤めると誰かに見初められ、結婚し、仕事を辞めていったのです。今でも古くから使われているシステムには、彼女たちが作ったプログラムが現役で動いているかもしれません。時にそのソースコードはよくレイアウトされた印刷物のように美しく整えられていたりして、彼女たちの「意地」を感じさせられます。

●「スキル目標」としてのSE

 その一方で男子従業員は会社に残って技術の中核を担っていくことを求められました。彼らにがんばってもらうには、彼らを単純労働者としてのPGとは差別化する必要がありました。SE(システムエンジニア)というあいまいな言葉は、このようにして社員に技術の向上を促すキャリアステップという意味で使われ出したのではないかと思います。

 以上のことをまとめていうと次のようになります。本来ソフトウェア作成の高度な技術の担い手であったPGは、日本ではその現実的な作業形態から「単純労働者」と考えられてしまった、そのためソフト作成の知的性格を表現する言葉として「SE」という言葉が使われるようになったのです。

 これだけならば「システムエンジニア」という言葉は別に害になるものでもなく、たんに上級PGという意味を表す日本独特の業界用語ということに収まったでしょう。ところが実際にはこれによって生まれるSE/PGの区別が厄介な問題を引き起こすことになりました。

●1990年代に起こった変化

 1990年代になってCOBOL開発に呼ばれたことがあります。その頃にはもう開発現場に女性の姿はなく、男ばかりの世界になっていましたが、当時は気にもとめませんでした。ゆっくりした変化はなかなか気付きにくいものです。このときは気付かなかったもう1つの重要な変化がありました。それは設計作業をしているのは元請会社の社員で、実装作業をしているのはもっぱらよそから派遣されてきた外注PGだったことです。

 このときの開発のエンドユーザーは旅館業です。テレビCMでも聞いたことがある伊豆の有名旅館の客室管理システムをOAで作ろうとしていました。実装している外注PGには、十分にスキルのある中堅どころがそろっていました。それに対して設計しているのはプロパーの若手社員。設計力のレベルに不満があったのでしょう、元請の先輩社員がしきりに後輩を叱咤していたのが印象に残っています。

 ソフトウェア開発では早くから派遣労働が普及していました。これは作業の専門性からいって仕方のないことですし、少なくともこの頃のCOBOLの開発現場では、派遣労働を正当に評価してもらっていましたから不利になったという感じはありませんでした。むしろプロパー社員のがんばりに感心していたくらいです。しかし今から考えるとそんなことより、その元請がスキルに不安のある自社社員をあえて設計に起用していたことに疑問を持つべきでした。この会社では設計とプログラミングを分け、後者をアウトソーシングしていたのです。

●アウトソーシングとSE/PG

 ここでソフトウェア開発でなぜアウトソーシングが増えるのか考えてみましょう。製造作業の一部を外注することのメリットを理解するには、損益分岐点分析というちょっと面倒な原価計算の理屈が必要になるのですが、かいつまんで説明すると、固定費である労務費を変動費である外注費に切り替えたほうが、利益が出るようになる売上高、「損益分岐点」が低くなるのです(注)

 売上高を急激に伸ばすことが期待できないソフトウェア開発では、固定費を少なくする方が有利です。日本のIT産業は、かつては女性の結婚退職を隠れ蓑に、ひそかに高齢になった労働者の一部を排除することで非効率な部門の固定費を削減していたわけですが、男女雇用機会均等法の制定などでそのようなことができなくなり、その代わりに固定費をアウトソーシングという形で変動費に変える道を選んだのです。

 まあ、以上のようなことは本当はきちんとしたデータをもとにして主張しなければならないことで、その意味ではこれはまったくのわたしの仮説にすぎません。しかし今日、日本のSIerの多くが企業利益のためにアウトソーシングを積極的に行い、その外部委託作業を切り分けるためにSE/PG分業を境目にしていることは、だれもが認めることでしょう。

 このアウトソーシングによる利益設計、すなわちビジネスモデルは、プログラミング作業に対するある先入見――プログラミングは単純作業であるという思い込みにもとづいています。PGは使い捨てにしても構わないが、SEは設計という「高度な」作業をして、顧客の業務知識を蓄積していってくれると。日本のIT企業のトップはどうしてこの誤った認識を改めることができないのでしょう。それが事実に見えた時代が一時はあったにせよ、少しでも現場に目を向けていればその誤りを容易に理解できることでしょうに。まるきり古い時代の、実質的に意味のなくなった分業区分をいつまでも有効であると信じている。間違った区分で外部委託の範囲を決めたことが、どれほどの問題を引き起こしていることか。

 その実態については、長くなりますので次回に述べたいと思います。

●PGは単純作業ではない

 これはわたしの持論ですが、プログラミングとは究極の「手仕事」です。どんなに技術が進んでもプログラミングという作業は残る。それは絶対にコンピュータにはできないことなのです。なぜならそれはコンピュータがすることを前もって考えることなのですから。この手仕事は職人仕事の性格を持っています。品質が製作者個人のスキルに大きく依存しています。しかもそのスキルはパターン化することができず、訓練では身につかない。PG個人の強い自発性がなければスキルアップしない。

 プログラムは、どんなものでも個人の技術の力量が問われる知的著作物です。上手な人が書いたプログラムは、まるで物理学の方程式のように美しい。そんなプログラムは当然バグも少ない。あっても見つけやすいのです。それがまるで大量生産品のように思われているのは、そういう作り方をすればできてしまうからです。困ったことにそれでもシステムは動いてしまうのです。

 経営者の方はこういうかもしれません。「なるほど、たしかにプログラミングは職人仕事かもしれない。優秀なPGを使えば品質の高いプログラムを作ることができるだろう。しかし優秀なPGを探すのは大変なことだ。安い労働力を使った大量生産方式でも、動くプログラムができるならそれでいいじゃないか」と。

 しかし考えてみてください。プログラムのほんの小さなバグがシステム全体に影響を与えるのです。1箱に不良品が3%以下なら許容できるというような話ではないのです。最近銀行のシステム統合で頻発した不具合のことを思い起こせば、その影響が理解できるでしょう。

 プログラマを粗末にしたらバチがあたりますよ。

(注)こちらのページにわかりやすく説明してあります。

Comment(6)

コメント

今回の記事も興味深く拝見しました。やはり考えるとは同じなようです。私もブログにこの件を書きました。この問題は日本のIT産業で致命的な問題ですよね。
私が思うに、「経営者が現場の事を知らなくてもいい」という日本の風土に問題があるかと思います。経営者が知らないと言うことは、私は非常に可笑しいと思うのですが、日本ではそれが普通であると感じます。何故そう感じたのかと言いますと、経営者が何も知らないと可笑しいと言うと、不思議な事に現場の人から反発を受けるからです。
この様な体質を変えない限り、IT産業は信頼されないでしょう。
無責任にも経営者が知らないものを売っているのですから・・・

Y(^^)Y

記事を拝見いたしました。

私は組込系ソフトの設計/実装/テストをしております。
一応元請けなので、どちらかというと上流(SE)でしょうか。
#ただ、大きな視点で俯瞰すると下流ですね。。

記事を読んで私が感じたことは、「どちらかというと外注先のほうが、そういう『思い込み』が多い気がするな~」ということです。

なぜなら、最近の私の周りの外部委託した開発案件をみると、

・下請け自身も『自分がすべきことは【単純作業】である』という認識で実装を行っている。
・また、そのように会社から指導されている。

というケースが多々見受けられます。
(つまりパンチャー(打ち込む人)なんです。)

そのために、私の会社では「ユースケース、外部インターフェース仕様書および内部設計書」等を外注先にインプットすることが必須となっています。

そして、外注先にはカバレージ記録(設計vs実装)の提出を義務付けます。

私自身の感覚では、もはやSE/PGはもはや同義語になっています。

上流と下流の関係は、記事に出てきた1960年代の分業体制と同じになってきているのかもしれません。。

xon

> この言葉はじつはもともと英語ではなく、「OL」などと同じ和製英語だといわれます。

 リンク先のWikipedia日本語版では「和製英語」と断言していますが,英語版Wikipediaの"systems engineering"の項には"systems engineer"という言葉が何度も出てきますよ。少なくとも http://itpro.nikkeibp.co.jp/NC/members/NC/YONEDA/20021113/1/ にもあるように,IBMに"systems engineer"という呼称があったのはまちがいないでしょう。
 日本語の「システム・エンジニア」と意味が違う(たぶん「システム工学者/システム工学技術者」という意味に近いと思う)のは確かでしょうが,それは和製英語に限らず日本語化された外来語であればほとんどどれでもそうでしょう。複数形の's'が落ちるのも,日本語化される際に起きるごく一般的な現象の一つだと思います。
 本題には影響ないのかもしれませんが,気になったので。

コラムニスト後藤

コラムニストの後藤です。

ご紹介のページを興味深く拝見させていただきました。

わたしはWikipediaの「システムエンジニア」の項目を参考にしました。わたし自身はこの言葉が日本に普及したのは、IBM360あたりのマニュアルにそう書いてあったからではないかと推測しているのですが、根拠があるわけではないので、Wikipedia氏の説に従いました。ご紹介くださったページはその推測を強化するものだと解釈しております。おそらく360のマニュアルにはソフトウェア開発の運営方法としてSE/PG分業が推奨されていたのではないかと考えています。当然マニュアルはどこかに残っているはずなので、将来IT産業史の研究者が解明してくれるかもしれません。

それよりご紹介くださったページには、語源論議より重要な情報が多々載せられていました。筆者もPG作業が日本では低く見られていることに強い憂慮を示しておられます。筆者はその原因を日本のコンピュータ導入がハードウェア主導で行われたことにあると見ておられますが、これにはそれだけではなく、わたしがコラムの中に示しましたように、日本の労働者環境などの経済的要因が絡んでいることはまちがいないと思います。

願わくは、このページの筆者にわたしのコラムを読んでもらって、どのような感想をもたれたかうかがいたいところです(筆者はわたしと同年齢ですので。しかし同年齢なのに、なんというキャリアの違いでしょう)。

よいページをご紹介くださり、ありがとうございました。これからもよろしくご愛読ください。

xon

一月以上前のエントリーへのコメントに目を通し,レスポンスまでくださってありがとうございます。私も基本的には,後藤さんや米田氏と同じ問題意識を持っています。SE/PGという言葉の上での区別はこの際おいておくとして,全てのソフトウェア技術者には,計算機システム工学の素養とプログラミングの経験の両方が必要だと思います。上流工程の人(≒SE)もプログラミング能力を身に付けていなければならないし,下流工程の人(≒PG)も計算機システム工学の知識を身に付けるべきです。今は,両者ともその努力/意欲が足りていないのではないでしょうか?

タカギヒサシ

建設業界の構造とソフト業界が非常に似通っているのは偶然でしょうか?
上流/下流という捉え方自体、きわめて日本的な発想に思えます。あれだけ成長したにも関わらず、世界的な競争力を持たないまま衰退していく大企業、それに引きずられるように消えて行く下請け企業の姿が、今のソフト業界に重なって見えるのですが。

コメントを投稿する