刺戟的な題名で続けます。
前回は 日本独特の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歳ぐらいになって会社にいづらくなったとしても、すぐに辞めてはいけません。それは単にあなたの年齢とともに給料がかさんだので、 じつは単純作業以外何もできないあなたを追い出したがっているだけかもしれないのです。
こんなアドバイスをしなければならないこと自体、実に情けないことです。
●●コメント●●
0 件のコメント:
コメントを投稿