SEとPG、どっちが頭がいい？

ちょっと刺戟的な題名をつけました。しかし決して挑戦的な意図があるわけではありません。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％以下なら許容できるというような話ではないのです。最近銀行のシステム統合で頻発した不具合のことを思い起こせば、その影響が理解できるでしょう。

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