下流から見たIT業界

　この業界で長年仕事をしていると、ほれぼれするようなソースコードを見ることがあります。

　JR系列のSIerに呼ばれて、とある業界団体が管理する観光スポット紹介サイトの改修を手がけたことがあります。PC用、携帯用のページはすでにあるから、それに加えてPDA用のページを作るというプロジェクトでした。面白みのない地味な印象のサイトでしたが、ソース解析を進めていくと、なかなか面白い仕組みになっているのがわかってきました。ブラウザからのリクエストが全部同じURLへ集まるようになっているのです。そのURLで呼び出されるServletが、要求されたページの種類ごとに別のURLにディスパッチするようにできている。

　これは有効な方法だと直感できました。まずなんといってもサーバ側のクラスが構造化されます。画面の要求する機能とは別の論理でクラスを構成することができる。それにサイトのURLを一元的に管理できます。ブラウザがアクセスする窓口が一箇所に絞られるのですから、リクエストを管理しやすい。セキュリティの面でも有効である。つまり今で言うところのMVCパターンで作られていたのです。まだStrutsが一般に知られる前でした。JavaのWebアプリケーションがJSPコードをHTMLの間にソースコードを埋め込むという形で作られるのが一般的だった時代です。これは勉強になる仕事だと思いました。

　しかしこのプロジェクトは突然打ち切りになってしまいました。きっとPDA用のページを作っても誰も読みに来ないだろうと判断されてしまったのでしょう。惜しかったけれど、結果的には私にとって勉強しただけ得になりました。ソースにはPGの名前と作成した会社の名前が記されてありましたので、いつか一緒に仕事をしてみたいなと思って会社名を手帳に控えておきました（いまだにそういう機会はありませんが）。ネットで調べると、横浜にある会社です。もしかしたらJR系の会社かもしれません。そうだとしたら、さすがはJR、グループ企業まで技術レベルが高い。

　こんな思い出話から始めたのは、べつにJRをヨイショすることが目的ではありません。この時のソースコードからは、それ以上に重要なことが読み取れたからです。

●プログラミング作業はチームワーク

　MVCパターンは、サイトで使うJavaクラス全体の大枠となるパターンです。これを採用しているということは、プログラミング作業の前に各PGがこのパターンの有効性を納得し、それに合わせて各クラスを実装したということを意味しています。つまりこのソースはPGの綿密な連携作業によって作られたということです。

　それまでプログラミング作業は個人技の世界でした。COBOLでは原則的にSEが仕様を切り分けました。切り分けられたモジュールは完全に独立した世界ですので、PGはプログラムを他人と共同して作るということはありません。C言語では1個のソースからは1個のプロセスが生まれるので、ほぼ完全な独立性を持っています。これを分けてプログラムするのはけっこう難しいことで、1人で作りこむには大変だからといって、作業を分担することはあまりしません。VBアプリケーションは断片化したソースコードが複雑に絡み合っているので、これも作業を分担するのはなかなかに難しい。そのためC言語やVBの開発では、特定のPGに過重な負担がかかって、工程が遅れるということが頻繁にありました。

　ところがJavaはインターフェイスを境にPGの作業をあらかじめ分担しておくことができます。そうすることで得られるメリットは計り知れなく大きい。

●インターフェイス概論

　ここでJavaを知らない人のために「インターフェイス」の説明をしておきましょう。Javaのソースコードは「クラス」と呼ばれる単位に分けて書かれます。クラスには「メソッド」が定義され、その中にそのクラスが持つ機能を具体的にコーディングします。実際にプログラムが作動するときは、このクラスをもとにメモリ空間にインスタンスを必要な数だけ作る、これがコンピュータを動かす実態になるわけです。インターフェイスはメソッドだけ定義したクラスのようなものです。これを使うときには、このインターフェイスをもとにしてクラスを作って動かします。

　いわばインターフェイスとは、形だけ作った中身のないクラスのようなものです。こんなものがどうして必要なのか疑問に思われる方も多いかもしれません。わたしも始めのうちはどのように使えばいいかわかりませんでした。それがようやく理解できたのは、Javaの仕事をするようになって1、2年してからでしょうか。

　インターフェイスとは要するに「接合面」なのです。ロボットを開発するとします。胴体と腕を分担して開発することになりました。まず最初にすることは何でしょうか。接合面の設計です。接合部分の形、寸法、信号端子の種類、電圧、信号体系等々。これらをあらかじめ決めておけば、胴体を作るチームと腕を作るチームは、互いに相手のことを知らなくてもそれぞれの部分の開発に専念することができます。また接合面の規格を守っていれば、別の腕を付け替えることもできる。合体ロボットのように次々とアイテムを変更することも可能です。すなわちインターフェイスは部品を規格化するのです。これを有効的に使うことで大規模システムは整理され、分担して作りやすくなりますし、開発後のメンテナンスも容易になります。

　ですから大規模なシステムでは、何よりも先にインターフェイスを設計することが重要なのです。開発が進んでからでは、インターフェイスを適用するのは極めて困難です。あらかじめ全体の構成を見渡し、規格化できるパターンがあったら、そこにインターフェイスを作っておく。そうすれば複雑なシステム全体が部分部分に分けやすくなり、ロジック自体がパターン化されて、コーディングの量自体も減ります。できれば基本設計の段階でインターフェイスを決めておきたいところなのですが、このことについては十分理解されているとはいえないのが現状です。

●コミュニケーションの必要性

　話題をもとに戻しましょう。実装作業の分担の話でした。個人で作ることができる機能はおのずから限界があります。機能の規模が大きくなればなるほどバグの数は増えていきます。ですから1つの機能を分担して作ることは、大規模アプリケーションを作るときの必須の条件なのです。さらに開発の状況に合わせて人的資源を機動的に使うことができるようになる。ユーザーの気まぐれで急な仕様変更があっても、柔軟に対応できる。すなわちJavaにおいてはプログラミングとは個人技ではなく、綿密なチームワークを必要とする共同作業に変わったのです。

　私がこれまでの開発経験から考える理想的なシステム開発の現場は次のようなものです。5人から10人までのPGがチームを組み、机を並べている。そばにはいつでも使える会議スペースがあり、ホワイトボードが用意されている。開発が始まると、まずクラス構成を綿密に打ち合わせる。ホワイトボードに絵を描きながら、ああでもないこうでもないを繰り返し、やがて総員納得の上で全体のクラス構成を決定し、実装の技量にそってコーディングを分担する。コーディングが始まっても、いつでも必要があればすぐチームミーティングを持つ。システムの変更事項はそこで周知徹底する。こんな開発体制を組めたなら、どんな大規模システムの実装が来てもこわくはありません。

●開発の現状は

　しかしWebアプリケーション開発の現場は、たいていの場合これとはほど遠い現状にあります。PGはたいてい別の会社から呼ばれてきて、互いに交流はありません。配属された先のSEのいうことを聞かなければならないことになっています。PG同士でミーティングを持ったりすると、何かと誤解されます。またPGは個人で仕事をすることが多く、共同して仕事をするという経験が少ないので、他人の意見を積極的に聞こうということもありませんから、その仕事はなおさら孤立したものになります。

　頻繁にミーティングを開いて打ち合わせをするのはSEさんたちですが、プログラミングをあまり知らないSEは、ユーザーの要求を実装者に伝えるだけの単なる「御用聞き」になってしまいがちです。業務の内容に合わせてクラスを設計するなどという高等技術は身についていません。ミーティングは、プロジェクトマネージャから進捗を問いただされ、仕様変更があったことを上意下達的に言い渡されるだけの場になっています。クラス構成を話し合うとか、さっきも触れたインターフェイスを作るとか、テストプランを練るとか、そういったソースコードの品質にかかわる話し合いが行われることはほとんどありません。このような体制で作られるプログラムがオブジェクト指向であるわけはありません。画面からのリクエストごとに1メソッドが動き、そのメソッドに一切合財の機能を盛り込んでしまう、ということになります。

●ウォーターフォール型開発とアジャイル開発

　これまで大規模なソフトウェアが作られる場合、基本設計で大まかなことを決め、機能をいくつかのブロックに分け、細分化するごとに仕様の詳細を決めていくというトップダウンの設計手法がとられてきました。水が下に流れるように設計が進められるということから、これをウォーターフォール型の設計といいます。細分化されたプログラムが相互に関連を持つことがあまりないCOBOLのようなシステムならこれは有効です。しかしオブジェクト指向のJavaはそういうわけにはいきません。これではクラス設計をするPG（あるいはSE）のところに来る前に仕様が断片的になってしまいます。設計者がその能力を持っていても、これでは実力の振るいようがありません。

　ウォーターフォール型の開発がJavaに向かないことは、すでにだいぶ昔から指摘されてきたことです。アメリカではその反省から、PG相互のコミュニケーションを密接にし、開発のスパンを短く繰り返すことで、実装者とユーザーの距離を短くし、ユーザーの気まぐれな要求変更に対応しようという手法が開発されました。これをアジャイル開発といいます。この開発方法の有効性はすでに実証されています。にもかかわらず日本ではこの開発手法が行われることはめったにありません。

　その理由はよくわかりませんが、次のようなことが考えられます。まず日本のユーザーにはドキュメント信仰があります。ソフトウェアはただでさえブラックボックスになりやすく、ブラックボックスになったら最後、改修も再利用もできなくなると信じられています。だからドキュメントはできるだけ詳細に残してもらいたい。アジャイル開発ではどうしてもドキュメントは軽視される傾向にありますので、ユーザーには不評なのかもしれません。

　しかし実際には、詳細すぎる設計書などシステム開発では無用の長物。ソースコードさえきちんと管理されて残っているなら、そのシステムはブラックボックスでもなんでもないし、きちんとしたスキルのある技術者を呼べば、システムは必ず生き返ります（問題はその様な技術者をどうやって調達するかということになります）。

　もう1つは、アジャイル開発は「管理しにくい」と思われているからではないでしょうか。アジャイル開発は、開発技術者が直接ユーザーから要望を聞いたり、技術者同士で頻繁にミーティングを行います。現場から遠ざかって技術に疎くなったPMは、これらのミーティングを仕切りきれません。設計会議から疎外された管理者は「下っ端が集まって造反をたくらんでいるのでは」と不安になりがちです。ましてやアジャイル開発で鍵を握るのは、これまで冷遇してきたプログラマ、会社では要らないからできるだけ外注で調達してきた職種です。自社の請負業務が全部外注の人間で決定されるとなったなら、おもしろかろうはずがない。

●大事なのはコミュニケーション

　別にアジャイル開発を導入しなければならないというのではありません。プログラミングで重要なのはコミュニケーションです。PGは端末に向かって黙々とコーディングとバグ取りをしていればいいというのは昔の話です。理想的なプログラミングは、ちょっとコーディングをしていたかと思うと、立ったり座ったり、同僚と話をしたり、はた目から見ると、まるでまじめに仕事をしていないかと思われるかもしれません。しかし実際には彼らは仕事の上で重要な情報やアイデアの交換をしているのです。こうしてコミュニケートすることで、仕様に対する誤解を修正し、設計過程で見逃した不整合を見つけやすくなります。また、自分のソースコードに対して他人の批評を受けることで、わかりやすく利用性の高いコードが作られていきます。他人と話し合うことで新しい発想も生まれてくる。解けなかった問題が解けてしまう。まるで大学のセミナールームか、工業高校の実習室のような雰囲気、それこそが高い生産性を実現する作業環境なのです。Javaのようなオブジェクト指向言語では、他人が作ったソースコードをいかに有効に利用することができるかが生産性向上の鍵になります。プログラムのような形のないものを相互に利用し合うには、このような気軽で親密なコミュニケーションのできる環境、人間関係が何よりも必要なのです。

　まあ、実際このような開発をしたことがあるわけではありません。日本のソフトウェア開発現場は、さきほども述べたように、このような雰囲気とは対極的な環境にあります。だだっ広い部屋の一角に端末がところ狭しと並べられ（最近は机1つさえ満足に与えてもらえません。折りたたみテーブルにいくつも端末だけ置いて、ほとんど肘を突っつきあうような場所で何カ月も作業させられます）、それぞれ別の会社から派遣されたPGが、それぞれ隣の人の名前も知らずに（ときどき隣の人は日本語を話せないこともある）、与えられた仕様書を黙々と実装しているだけ。こんなタコ部屋現場が多いのではないでしょうか。

　プログラミングの現場でコミュニケーションが足りないのは、もちろんSIerの管理方法にだけ原因があるわけではありません。技術者の方にも責任があります。概して腕のいい技術者ほど寡黙なものです。口を動かすより手を動かして、自分で結果を出すのに夢中になるので、チームワークをおろそかにしがちです。それに熟練したPGは独学でスキルを身につけてきた場合が多く、教えたがりなわりには、進んで他人と情報交換をしようとしない。その点では学校でプログラミングを勉強してきた人間が多いアメリカとは土壌が違うのです。日本のPGがいきなりアジャイルな開発環境に放り込まれても、きっととまどうばかりでしょう。

●もっとおしゃべりしましょう

　このような現状を変えていくのは、やはり管理者の責任であり、年配者のつとめでしょう。プログラミング作業でのコミュニケーションの重要性は、アジャイル開発、ウォーターフォール型開発にかかわらず有効です。このコラムをお読みのあなたがPMならば、毎日ミーティングを開くばかりでなく、頻繁にPGの肩を叩いて声をかけてあげてください。最初は内心いやがられるかもしれません。しかし相手が自分の仕事の内容に親身になって関心を持ってくれているのだとわかれば、やがて態度は変わってきます。声をかけるときは単に進捗ばかりに関心を持ってはいけません。プログラムの中身についても突っ込みを入れてみましょう。未熟なPGなら足りない部分を指導してあげてください。優秀なPGならたいてい自分の作品について自慢したいところを持っていますので、そこをほめてあげてください。また、彼らはプロジェクトについていいアイデアを持っていたりします。それを会議の場では言い出せずにだまっていたりします。それを吸い上げるのにもいい機会です（もちろんこれらのためにはPMがプログラミングについて熟知していなければならないのですが）。とにかく重要なことは、少しでもコミュニケーションの頻度を上げることです。

　コミュニケーションが増えれば、必ずプロジェクトにプラスになります。一見むだ話に見えるかもしれませんが、それが目に見えないところで効果を持ってくるのです。過去に失敗したプロジェクトのことを思い出してください。それは開発者全員が押し黙り、互いに背を向け合ったような、沈滞したプロジェクトではありませんでしたか？ メンバーが死人のように口をきかず破滅に向かって進んでしまうので「デスマーチ」というのです（ちょっとちがうかも？）。

　若いPGの皆さん。もっとおしゃべりしましょう。ひとりで黙々と開発する時代は終わりました。わからないことは積極的に他人に質問しましょう。知っていいる人はたいてい教えてくれます。教えてくれないのは、答えを知らないからです。IT業界は技術革新が早いので、知識が古びるのも早い。ですから知っている人は、その知識が古びないうちに教えなければ結局、損をします。だから技術者はたいてい「教えたがり」です。そしていつか自分が質問される立場になったら、こころよく教えてあげてください。そんな小さな心掛けが、やがては業界を変えていく力になるかもしれないのです。

●わたしと派遣業

　わたしはこの業界で20数年働いていますが、派遣と外注はどの会社でも一般的に行われていました。最初に入った会社の最初に配属された部署では、開発作業に携わっていた人の半数以上は外部から派遣されてきた人たちでした。明らかにプロパーの社員より技量が上で、開発の主力は派遣技術者が担っていました。給与や福利厚生の面では当然差があったわけですが、管理者もこれら派遣技術者は丁重に扱っていましたし、仕事の上ではほとんど外注もプロパーも区別されていなかったといっていいでしょう。

　にもかかわらず、わたしはこれら派遣技術者という身分には偏見を持っていました。当時「プログラマ35歳定年説」というものが噂されていました。派遣労働に支払われる契約料は一定で低く抑えられているので、年齢が上がって給料が上がっていくと派遣会社はその従業員の給与を支払うことができなくなって、会社を辞めさせられるというものです。この説を真に受けていたわけではありませんが、派遣社員という身分は何かと不利なように思えて、最初の会社を辞めた後もずっとプロパー社員で働けることにこだわっていました。

　契約社員で派遣されて働くようになったのは、30歳過ぎてからでした。いざそうなってみると、肩の荷が落ちて、さっぱりしたような感じがしたものです。まず何といっても仕事に集中できるようになりました。電話を取らなくなりましたし、その他の有象無象の雑用から解放されました。ある程度仕事を選ぶこともできましたので、キャリアも自分で組み立てることができるようになりました。わたしはCOBOLからBasic、C言語、VB、Javaの順で言語を乗り換えてきましたが、こんなことも正社員で雇われていたら難しかったことでしょう。いまでは何であんなことにこだわっていたのだろうかと思います（注1）。

●アウトソーシングは正しい戦略か？

　派遣の仕事にもいろいろあるでしょうが、少なくともシステム開発では、派遣は必ずしも不利な労働ではありません。この仕事は専門性が高く、技能が高度に規格化されていますので、一定のスキルのある技術者はどの職場に行っても即戦力として通用します（少なくとも実装作業の場合）。また、その業績が派遣先で正当に評価されれば、気持ちよく働くことができます。技術革新のスピードが速いため、絶えずキャッチアップのための努力をする必要がありますが、その自信さえあれば、わたしのように何の後ろ盾もない個人事業主でも、それ相応の年収を稼ぐことができます。

　しかし、2000年ころからでしょうか、この業界の状況が変わってきました。わたしがこれまでこのコラムで書いてきたように、技術自体は日進月歩で進歩しているのに、それが現場の生産性に結びつかなくなってきたのです。大量のマンパワーがむなしく費やされ、技術者への負担は「3K」とまでいわれるようになっている。業界の技術は空洞化し、資源が偏って配分され、技術に対する軽薄な侮りと忌避が蔓延（まんえん）しています。

　どうしてこんな状態になったのでしょう。わたしはこれまで「下流」の位置から、つまり現場の作業のやり方や管理方法からこれらの構造的問題を説き起こしてきました。前回はSE／PG分業からソフトウェア開発作業の現状を分析しました。もちろん、この分業をなくせば問題がすぐ解決する、というわけではありません。原因はSIerが業務の一部、あるいは全部を外注するという経営方針を採っていることにあるのであって、SE／PG分業は業務を外注する範囲の目安として使われていたにすぎません。現在ではPGはおろかSEですら、建設作業員のようにプロジェクトごとにかき集められるのが普通になっています。SIerはなぜ業務を外注するのでしょう。このことを根本的に考え直さなければ、IT業界の技術空洞化の問題は解決できません。

　しかし、このような意見には強硬な反対論があります。IT業界の多重請負構造は、アウトソーシングを活用した経営戦略として有効かつ必要なものであって、IT業界には必然的な産業形態であるとする意見です。コンサルタントは、これに賛同する方が多いようですが、はたしてアウトソーシングはIT企業には必要不可欠な戦略なのでしょうか。そもそも経営戦略として継続できるものなのでしょうか。今回はこのことに焦点を当てて考えてみたいと思います。

●アウトソーシングを流行らせたのは？

　「IT」という言葉と同様に、「アウトソーシング」という言葉も最近になって使われ始めたものです。いったい誰が使い始めたのでしょう。断言はできませんが、どうやら1990年代後半に旧通産省官僚が、アメリカの産業構造の変化を手本にして、日本の経済競争力の増強を図るため使い出した言葉のようです。

　近くの区立図書館で「アウトソーシングの時代」（注2）という本を見つけました。編著者はわたしと同じ1959年生まれの、旧通産省のお役人さんです。この本はアウトソーシングの啓蒙書として書かれていて、その主張するところは、およそ次のようなものです。

　日本の企業のアウトソーシングはおもにコスト削減などを目的とし、外注先もグループ企業に限るなど、消極的で身内優先なものにとどまっている。このため、アウトソーシングを利用して効率化するという面ではその効果は限定的なものにとどまっている。これに対してアメリカなどのアウトソーシング先進国では、自社の経営資源を本業に集中するために積極的に社外のサービスを利用し、外部委託を戦略的に利用して新規事業に果敢に乗り出すなどの「攻めの経営」が根付いている。このままでは日本の企業は、やがて経営資源の活用の点でアメリカに遅れをとり、大競争時代を生き残れないであろう。

　こうした主張の上で、著者はアウトソーシングの利用を3つの段階に分けて説明します。まず第1段階はコスト削減を目的とした短期的利益の追求として始められます。例えば、給与計算業務や福利厚生施設の運営など。わたしたちの情報システム部門も、この目的で外部委託されるようになりました。それがやがてアウトソーサーの専門性を吸収して自社の業務に活用するようになる。これが第2段階。第3段階になると、外部の専門性を積極的に活用して新規事業に乗り出すようになる。この段階の企業戦略は利益の追求ではなく、創造性追求型となり、発注側と受注側の間にはよりいっそう緊密な戦略的提携関係が構築されることになるだろう、とのことです。

　いかにも旧通産省の官僚さんらしい考え方です。先進的で、頭がよくて、理想主義的で、大所高所からの視点で、あるべき産業界の姿を分かりやすく生き生きと描いてみせる。そして悲しいかな、全体が見えていない。そのため常識的なことを見落としています。落ちついて考えてみればすぐ分かることです。アウトソースされた業務はいったい誰が担うのでしょう。

●アウトソーシングを基本から考える

　企業はなぜ自社の業務を外部に委託するのでしょうか。例えば、会社のトイレ掃除は社員にやらせません。外部の清掃会社に委託します。これは、人件費の高い自社社員にそんな雑用をさせるのは不経済だからです。それならばSIerはなぜPG作業をアウトソーシングするのでしょう。プログラミングは雑用ではありませんし、単純労働でもありません。この答えは前々回簡単にご説明しましたが、もう一度詳細に考えてみましょう。

　まずこちらのページを見てください。こちらに書かれているのはCVP（Cost Volume Profit）図といって、企業の利益設計をする上で基本中の基本となるグラフです。変動費で代表的なのは材料費、固定費を代表するのは工場などの設備費ですが、人件費も後者として扱います。見慣れない人には少々分かりにくいのですが、企業活動が得になるか損になるかの分かれ目である「損益分岐点」が、経費に占める変動費と固定費の割合で変わることはお分かりいただけると思います。固定費の割合が大きい「工場生産型」の事業では、売り上げが伸びた場合の利益が大きいけれど、損益分岐点は高く、売り上げが伸びない場合の固定費の負担が大きい。一方「アウトソーシング型」の事業では、損益分岐点が低いので比較的小さな売り上げでも利益が出ますが、売り上げが伸びても利は薄い。いわば前者はハイリスク･ハイリターン型、後者は安全経営型といえます。このため、コンサルタントは企業に経営の安定化を図るために、アウトソーシングを勧めるわけです。なかでも情報処理業務はその代表選手で、わたしたちIT業界がおまんまを食べられるのも、コンサルタントの方々があちこちでコンピュータ業務のアウトソーシングを薦めてくれるからにほかなりません。

●アウトソーシングの果てに、100年前に逆戻り

　しかし、ちょっと考えてみてください。一般顧客がコンピュータ業務をアウトソーシングするのは分かります。しかしその外注を受ける側、SIerが生産をアウトソーシングしたらいったいどうなるでしょう。元請けは下請けに外注します。下請けもまたその下請けに発注する。企業規模が小さければ小さいほど安定経営を志向するものです。そうしてツケを回していく果てに、固定費を実際に負担してプログラムを作るのはいったい誰になるのでしょう。究極の下請け業者、すなわち契約社員、派遣労働者なのです。

　これこそがいまIT業界で――いや、IT業界に限らず日本の産業界全般で起こっていることなのです。企業は正社員を減らして契約社員を雇う、あるいは派遣業者から人員を派遣してもらう。これは企業にとっては固定費を減らして経営を安定させるのに役立つでしょう。しかし、これは単に売り上げの増減によって生じるリスクを労働者に転嫁しているだけです。労働者は原理的にアウトソーシングすることはできない（生活費は究極の固定費です）わけですから、このリスクから逃れることはできません。すなわち、仕事が忙しいときには死ぬほど働かされて（場合によっては残業代が出ないこともあります）、仕事がなくなったらすぐクビになる。景況の波を一番弱い立場の労働者が直接かぶってしまう。今日の雇用問題の大部分がここにあるのです。

　その昔、産業革命が起こったばかりの資本主義経済の初期には、工場労働者が同じ立場に置かれて悲惨な生活を強いられました。当時は12時間労働が一般的で、文字通り夜明けと同時にたたき起こされ、日が沈むまで働かされたのです。仕事がなくなると容赦なく馘首（かくしゅ）されました。これらの悲惨な状況を改善しようとして、血みどろの労働運動や階級闘争を経て、労働法が制定され、行政によって労働者が保護されるようになったわけです。ところが1980年ごろから、いわゆる「規制緩和」「構造改革」の名のもとにさまざまな修正が加えられて、次第に骨抜きになってきました。「社会のニーズに合わせて制度を柔軟に運用する」という名目で、1日8時間の労働という原則も崩されています。それどころか「サービス残業」などという違法行為まで横行している。まるで100年前に戻ってしまったかのようです。

　アウトソーシングがその本来の目的にではなく、派遣労働と結びついて労働者保護制度の抜け穴に使われていることが明らかです。件の旧通産省のお役人さんには、このことが予想できなかったのでしょうか。概してお役人さんは考え方がタコツボ的で、自分の属するセクション以外のことは見えないとよくいわれますが、それはこのアウトソーシング論にも当てはまるでしょう。アウトソーシング論それ自体はいかにも立派な議論かもしれませんが、一般勤労者のことはまるで考えられていません。まるでそれは他省の管轄だからどうでもいいといわんばかりです。お役人さんには全体が見えているようでいて、実際にはぜんぜん見えていないのです。

●「三丁目の夕日」

　彼らが見落としていたことは他にもあります。それは、彼らが槍玉に挙げる日本的経営の閉鎖性、グループ企業内で受注しあう身内主義的傾向にも、経済構造として一定の合理性があったということです。

　かつては日本にも「町工場」というものがいたるところにありました。今も住宅街に工場が隣接しているところはありますが、昔に比べるとずっと少なくなっています。映画「三丁目の夕日」にそのころの街の風景が再現されていますね。当時は全国に零細企業が無数にあって、大企業から注文を請けて生業を立てていました。日本の産業は少数の大企業と、無数の中小企業に二極分化していて問題であると、社会科の時間に習ったものです。これらの町工場は従業員を雇い入れ、高価な機械設備などを負担していたのですから、相当ハイリスクなビジネスをしていたわけです。平気だったのでしょうか。

　平気だったのでしょうね。こういった町工場の経営者の多くが職人上がりだったと思われます。職人は熟練労働者ですから、けっこう安定した身分だった（注3）のですが、それでも一部の職人は金をためて自分の工場を持ちました。それは、そのことが「出世」であるばかりではありません。売り上げが上がれば、利の厚い、儲かる商売だったからでしょう。大企業は豊富な資金力によって新製品を開発し、常に新しい需要を開拓してくれます。その下請けをしていれば一定の売り上げは期待できます。売れることが確実ならば、「工場生産型」事業は魅力的な商売です。彼らはハイリスク・ハイリターンの事業をあえて引き受けました。彼らの気概のおかげで、大企業は固定費を削減することができ、職人は安定して仕事にありつけたのです。

　もちろん、こういった町工場の経営者はリスクに鈍感だったわけではありません。彼らは売り上げの変動を抑えるために、注文をくれる大企業の「子会社」になることで、親会社から安定して受注し、かつ親会社の信用を背景に銀行から融資を受けることができました。いわゆる「系列」の形成です。大手銀行が乗り出せば、信金や信組も寄ってくる。系列に食い込めない企業は、苦しいけれどいわゆる「町金」の高利融資で急場をしのぐ。中小企業の売り上げ増減のリスクは、大小の金融機関によって支えられたのです。こうしてこれら町工場の経営者の努力が日本の高度経済成長を下支えし、日本の技術力を世界的なブランドへと高めました。

●アウトソーシングの正体

　ところが1980年代から1990年代にかけて「規制緩和」が叫ばれはじめると、こうした日本的な経営が非難の的になりました。大企業中心の「系列」が日本の産業の高コスト体質を維持しているとされたのです。たしかに規制緩和のおかげで「価格破壊」が起きて物価は下がりました。しかしその代わり、深刻な雇用問題を抱え込むことになってしまいました。日本はアメリカの真似をして「アウトソーシング」を取り入れることで、閉鎖的な企業系列を破壊しましたが、同時に中小企業の安定受注の構造も壊してしまいました。

　本来なら金融機関がそれによって増えたリスクを支えるべきところでしょうが、折から起こったバブル崩壊による金融危機で銀行にはそのような余裕はありませんでしたし、元から不動産を担保にした融資による安定経営に慣れてきた銀行には、中小企業の小口融資を詳細にリスク査定する能力などなかったことでしょう。その結果「貸し渋り」や「貸しはがし」が横行しました。こうした中小企業の金融環境の悪化に対して行政的あるいは制度的な保護措置がとられてもよかったと思いますが、それさえもなかった。大手金融機関には破格の救済措置がなされたのに、中小の弱者には「自己責任」の原則が押し付けられたわけです。

　金融の支えをなくした中小企業は、設備投資を抑えられて技術革新から取り残され、発注会社の値引き圧力に抵抗できず、やむなく廃業するか、違法すれすれの外国人労働者を雇うか、人件費の安い海外生産にシフトすることを迫られました。その結果、日本の産業技術が空洞化し、製品の品質劣化を招き、食の安全まで脅かされるようになる。これが「アウトソーシング」の正体です。

●得をするのは誰？

　と、また少々挑発的な書き方をしてしまいました。

　アウトソーシングを喧伝した旧通産省のお役人さんたちには、もちろん日本の産業を空洞化させる意図はなかったでしょう。よしんばそのような懸念はあったにしても、日本の経済にはそれを補って余りある利益がもたらされると信じていたのでしょう。それは例えば、M&Aのような形で経営をドラスティックに転換させることで、経営の合理化を果たし、企業価値を高める――すなわち株価の上昇で実現される。株価が上がれば消費も増えて、それが景気を刺激して労働者の所得も上昇する。たぶんこのようなヴィジョンを描いていたのでしょう。

　しかし、わたしのような「下流」にいる人間からしてみると、これらの話は、現実からあまりにも迂遠な夢物語に思えます。企業の業務をレゴブロックのようにつけたりはずしたり、犬の子をやり取りするようにトレードしたりすることで、企業価値は果たして上がるものでしょうか。それは単なる市場の幻想であることを、わたしたちはITバブル崩壊やライブドア事件のときに痛感したのではなかったでしょうか。製品は誰かが作らなければ売ることはできないし、会社のトイレは誰かが掃除しなければならない。アウトソーシング推進論は、こんな単純なことをどこかに置き忘れてきた主張に思えます。

●こまった「市場」信仰

　さらにアウトソーシング論で問題なのは、市場原理の過大評価です。

　企業が自前で、あるいはグループ企業内で製品やサービスを調達する場合、そこには市場原理が働かず、コスト高になってしまう、それが消費者に転嫁されてしまうというのが、アウトソーシング推進論の論拠の1つです。ご存じのように、この理論は市場経済の価格決定作用を企業内部に持ち込んで、コストの適正化を図ろうという考え方です。その背景には、市場原理が発注する側にも受注する側にも公正公平で、合理的な価格を導き出してくれるという前提があるわけですが、そんなことは実際にはまずありえません。このことは下請け業者の立場で営業に歩いたことがある人ならば身をもって知っているはずです。

　アウトソーシングでは、発注する側と受注する側が対等の立場にあることは極めてまれです。価格の決定権は発注側にあるのが普通で、資金力のない受注業者は固定費の負担に堪えきれませんから、注文主の価格設定に従わざるを得ません。もしこれを対等にしようとするならば、受注側は資本を増強し、営業規模を拡大して銀行融資を呼び込み、マーケットシェアを獲得する必要があります。それからでなければ、対等の価格交渉には望めません。しかしそうすれば、この受注業者は巨大な固定費のリスクを抱え込むことになります。結局その業務をもっと小さな会社に丸投げすることになるでしょう。これでは間に余計な会社が1つ入っただけで、状況は何一つ変わりません（注4）。このようにして、アウトソーシングは必ず「外注／下請け」の関係になります。「アウトソーシングの時代」の著者のいう「戦略的提携関係」が自然に形成されることは考えにくいのです。

●アウトソーシングで品質低下

　市場原理の過大評価はもう1つの弊害をもたらします。一企業の内部で物が生産される場合、その生産に必要な資源配分――すなわち予算配分は、直接の管理の下で評価されます。しかしアウトソーシングの場合、市場原理が働きますから、原価が正当に評価されない可能性がある。すなわち生産者に対する適切な資源配分が保障されないのです。受注業者は競争を勝ち抜くためなら何でもします。例えば見えないところで手抜きをして納品する。そうなっては大変だから、発注側は綿密なテストを行わなければならなくなる。そのテストに膨大なコストが発生する。これでは何のためのアウトソーシングか分かりません。

　市場原理は万能ではありません。業務の発注者と受注者が公平になるのは、金融のリスクサポートが適性に働いて、受注側が設備投資や営業力を強化して市場競争に見合う原価を実現できる場合だけです。それが実現されない場合、受注者は受注業務の品質を下げざるを得ない。発注者は品質のコントロール手段を失い、品質は急速に劣化していく。日本の高品質製品の代名詞だったソニーが、安易なアウトソーシングを推し進めた結果、外注部品の劣化を招き、「ソニーは買うとすぐ壊れる」とか「ソニータイマー」と呼ばれて大いに面目をつぶしたことを忘れてはなりません。

●アウトソーシングしていい場合といけない場合

　また話が長くなりました。そろそろまとめに入りましょう。

　わたしはここまでアウトソーシングの欠点ばかりあげつらってきましたが、もちろんアウトソーシングそのものを否定するわけではありません。世の中には外部委託したほうが合理的な業務もたくさんあります。大型汎用機で行うデータ処理業務はその典型例の1つで、1970年代から専門業者が成立してきました。OAが普及した後も業務アプリケーションを内製するケースは少なく、業者に委託する場合がほとんどです。そもそもIT業界自体がアウトソーシングを前提に成長してきた業界です。前述したように、コンサルタントがその受注営業の最前線に立っていてくれたわけで、その意味でコンサルタントがアウトソーシング論に肯定的なこともうなずけます。

　しかしそれは、ユーザーが自分たちにできない業務を外部の専門家に委託する場合の話です。専門家であるはずのSIerが自社の経営の都合で業務を外部委託していたらいったいどうなるでしょう。前述のとおり、コストばかりを重視した「市場原理」が災いして、品質をコントロールする手段を失い、テスト工程の費用がいたずらに拡大します。結局は逆にコスト増になる。そればかりではありません。景況のリスクが末端の技術者にしわ寄せされ、「女工哀史」や「蟹工船」の時代に逆戻りしてしまいます。「3K」と呼ばれるのもむべなるかな。これでは労働者のインセンティブは甚だしく損なわれ、業界全体に長期的な悪影響を及ぼすでしょう。アウトソーシングの結果、技術が空洞化する問題については前回、前々回に書きましたからもういいでしょう。ソフトウェアの開発自体はアウトソーシングに適した業務ですが、それを分割してアウトソーシングすることは、多くのリスクを発生させ、長期的に会社に不利益をもたらします。

　そもそもアウトソーシングのデメリットについては、わたしがこんなところでいちいち説明するまでもなく、専門家が「コスト面のみに着目した安易なアウトソーシングは、“戦略なき外注”となり、最適なITガバナンスが失われるリスクがある」とすでに指摘していてくれています。こちらをご覧ください（それにしても、この手の専門家はどうしてこんな分かりにくい言葉で説明するのでしょう。わたしも今回以上のことを書くために勉強するまで、このページを理解できませんでした）。

●会社のトイレは誰かが掃除しなければならない

　結論を言いましょう。「下流」の目から見ると、現経済産業省のお役人さんが勧めるアウトソーシング論は、企業の業務を細分化してトレードしやすくするという効果を狙ったものでしかないように思えます。これは投資家目線で見れば、投資対象として合理化された望ましい姿かもしれませんが、実際に現場で働く立場からすると、多くの場合さまざまな障害を作り出し、結果的に投資対象としての企業価値を損なってしまう、不合理極まりない戦略です。アメリカではこんな手法で見かけ上の企業価値を向上させ、株価で儲けるというビジネスが流行っていたようですが、こんなことをすれば生産の実態にかかわりない投機的投資が横行するのは当然です。このマネーゲームの報いがいま起こっている金融危機ではないでしょうか。

　もうそろそろ、アメリカの真似をするのはやめにしましょう。

●企業家の精神に立ち戻れ

　SIerのみなさん。もっと自信を持ってください。みなさんの業界はハイテクの先端にいる業界ではなかったでしょうか。多少の売り上げ増減のリスクなど吹き飛ばしてしまえるような技術革新が日夜生まれている業界ではありませんか。

　MicrosoftだってGoogleだって、つい最近までみなさんと同じような中小企業だったのですよ。彼らがベンチャーから世界的な企業にのし上がるまで、わずか数年しかかかりませんでした。もちろん彼らのまねをしろというのではありません。ライブドアの堀江元社長のように、形だけまねをしてスベった人はたくさんいます。

　わたしが言いたいのは、ITは少ない投資で多大な利益を上げることができるビジネスだということです。その事実を見据えれば、設計／実装技術者の人件費など物の数ではありません。かつて日本の高度成長を支えた「町工場」の経営者などよりもはるかに好条件に恵まれているはずです。

　きちんとリスクを負担して、でっかく儲けましょう。固定費をけちけちして喜ぶのは、リスクをぜんぜん理解できない銀行の営業マンだけです。彼らは担当する企業が安定して利益を上げてくれればいいと思っているだけです。彼らのいうことを真に受けて不用意なアウトソーシングに走ったら、あなたの会社の技術は完全にスポイルされます。むしろ彼らに、こう力説しましょう。

　「うちの技術者は天才ぞろいだ。うちは金のなる木を持っているんだ。あんたはそれを伐れというのか。とんでもない！」

（注1）しかし、わたしのようなケースはやはり稀なのでしょう。世の中、悲惨な条件で働いている派遣社員の話をよく聞きます。ITの会社だと思って契約したのに、回ってくる仕事はデータ入力のオペレータ作業ばかり、そのうち30歳も過ぎると仕事を回してもらえなくなってしまった。いまさらPGにしてくれる会社もない。このような派遣社員使い捨ての例はいくらでも転がっているでしょう。学校でプログラミングを勉強するか、最初の会社できちんとした教育を受けることは、この業界で生き残っていくには重要なことです。

（注2）村上世彰編著、日経BP社、1999年

（注3）もと旋盤工の作家、小関智弘が書いていますが、腕に自信がある労働者はけっこう気位が高く、少しでも条件のいい仕事先を求めて、ちょくちょく仕事先を変えていました。市場価値のある技能を身につければ、たいした貯えがなくとも生活困窮に至らないという見通しがあったわけです。いつの時代も同じですね。

（注4）われらがIT業界では、実際にこの戦略をとって急成長した会社があるようですね。どことはいいませんが。

　刺戟的な題名で続けます。

　前回は日本独特の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歳ぐらいになって会社にいづらくなったとしても、すぐに辞めてはいけません。それは単にあなたの年齢とともに給料がかさんだので、じつは単純作業以外何もできないあなたを追い出したがっているだけかもしれないのです。

　こんなアドバイスをしなければならないこと自体、実に情けないことです。

（注）Javaの設計書がVBの開発と同じ形式になったのは、Java開発におけるドキュメンテーションの難しさが背景にあるのでしょう。Javaはご存知のようにオブジェクト指向言語で、ソフトウェアの機能は各クラスに分化し、実際のコードはさらにその中のメソッドに区分して書かれます。すなわちVB以上に断片的になっていますので、これをそのまま文書化しても一覧して分かるものではありません。それを分かりやすくする手法としてUMLなどの方法が開発されたわけですが、それを使っても一般のユーザーには何のことか分からないのはあまり変わりません。UMLはむしろ開発者間で仕様を確認するための方法なのです。一般ユーザーに分かるという点では、VBと同じ形で仕様書を書くしかなかったのです。

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

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

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

　今日はちょっと本題を離れてアニメの話を。

●ポ～ニョ、ポニョ♪

　先日「崖の上のポニョ」を見てきました。

　わたしはアニメファンではないのですが、宮崎駿の作品は好きで、必ず映画館に見に行きます。最初に見たのは「ナウシカ」。「ラピュタ」「トトロ」は見逃しましたが、「魔女の宅急便」以後は全部映画館で見ています。

　しかし正直なところ、今回ばかりは実際に見るまでは心配でした。封切り1カ月前ごろから各種メディアが予告映像を流し始めましたが、どうも気に入りません。どこか現実離れした色彩。キャラクターの線が少なく単純で、最近流行の「ゆるキャラ」のように立体感がなく、まるで紙切れのよう。背景に描かれた街や家は色鉛筆で書いたスケッチのように思えました。

　それにもう1つ心配だったのは、本作品が宮崎監督の意向で全編「手書き」の絵で作られたことです。監督はなぜそんなことにこだわったのでしょう。1990年代以降CGはアニメーションの世界を革命的に変えてきたはずです。そもそもジブリはアニメーションにCGを取り入れた先駆者の1人ではなかったでしょうか。

●技術の進歩を否定する？

　1秒間に何十枚ものセル画を必要とするアニメーションの作成は動画スタッフに過酷な労働を強います。テレビアニメの場合、1秒間に24枚として30分の放送時間のうち、広告やタイトルを除いた部分を22分と見積もっても、毎週3万1680枚を必要とします。それを1週間で企画して、描いて、撮影して、編集する。途方もない作業であることがわかります。

　それゆえアニメーションの世界では省力化のためさまざまな努力を払ってきました。初期テレビアニメでよく見られたシーンの使いまわし、人件費の安い東南アジアでの動画作成等々。ことに1990年代になってCGが使われるようになってからの質的向上は目を見張るものがありました。風景や室内の豊かなディテール、主人公が変身するときの流れるようなコスチューム。これらの映像を手書きで実現しようとしたなら、どれほどの労力がかかることでしょう。日本のアニメはCGを各所に効果的に取り入れることによって映像の品質を高めることに成功したといえます。

　今回の「崖の上のポニョ」はある意味、そういったCG利用のアニメーション作成の技術進歩を全部否定する意図を秘めていたのです。果たしてそれは正しいことなのでしょうか。監督の個人的な美意識や技術の保守性から制作費をむだに使ったアナクロニズムに陥っているのではないか、と心配でした。

　しかし実際に作品を見れば、それらの心配はいっぺんに吹き飛びました。「崖の上のポニョ」は傑作です。しかも日本のアニメーションの方向性を変えることになるかもしれない潜在的な重要性を秘めているのです。

●「ポニョ」の戦略

　以前NHKのドキュメンタリーでスタジオジブリの製作の様子を見たことがあります。企画を終えて実際の製造段階に入ると、宮崎監督自身は絵を描きません。シナリオにしたがってシーンを分け、それぞれの作画はアニメーターに分担されます。各シーンにおけるキャラクターの動きは各アニメーターの技量にゆだねられるのです。それゆえアニメ作成のマネジメントの主眼は、いかにスタッフへの負担を減らし、そこで生まれた余裕を動画の創造性へ転化させることができるかということにあります。

　キャラクターの輪郭線がシンプルで立体感に乏しいのは、何枚ものセル画を手書きする動画スタッフへの負担を減らすためでした。キャラクターデザインをあらかじめ緩く設定すると、アニメーターの負担が減り、それであまった労力で、例えば画面上で動く固体の数を増やすことができます。その結果、ポニョが棲む海の底はさまざまな形の生き物にあふれ、それが生命の豊かさを具体的に示すイメージとなっています。

　色鉛筆タッチの背景画も決して稚拙な印象を与えるものではなく、「こんな町に住んでみたい」と思わせるに十分な魅力を持っていました。絵が動くということは、それだけで奥行きを感じさせるものです。子供たちはこの映画を見て、まるで自分たちが書いた色鉛筆の絵が動き出し、自分がその中に入り込んでしまったような親しさを感じたことでしょう。それがこの映画が子供たちに人気がある原因の1つだと思います。

●「ポニョ」のもう1つの狙いは

　しかしそれだけならこの作品は「手書きのアニメ」の価値を再認識させたというだけの作品にすぎません。宮崎駿が今回は風変わりな作品を作ったという話題をひとしきり振りまいて終わってしまうでしょう。わたしの見るところ「崖の上のポニョ」の持つ重要性はそれだけにとどまりません。日本のアニメに、ひいては世界のアニメーションに新しい潮流を作り出すかもしれないのです。

　そう思ったのは、エンドロールのクレジットを見た時です。そこにはこのアニメーション作成に参加したアニメーターの名前が列挙されていました。それだけなら普通のアニメ映画のクレジットと同じなのですが、重要なのはアニメーターの個人名が電通、博報堂などの法人名と同じ大きさで並べられていたことです。

　ふつうはそんなことはありません。エンドロールで強調されるのは、ふつうプロデューサーや監督などの映画製作の責任者の名前、出演者の名前、協賛した法人の名前などで、アニメーターの名前など小さな文字で遠慮がちに挙げられるだけです。「ポニョ」のエンドロールは、ジブリがこれらのアニメーターを高く処遇していたことを示しています。

●原点に返ろう

　ジブリの発表では、この作品の完成まで70人のスタッフで1年半かかったそうです。1年半の間ひたすら絵を描いてすごす生活とは一体どのような生活でしょう。しかもそれが70人！

　これら70人のアニメーターたちにとって、この映画がまたとない絵のトレーニングの機会になったことはまちがいありません。彼らからしてみれば、こんなシーンならCGを使えばはるかに楽なのにと不満に思ったことも少なからずあったかもしれません。たしかにCGを使えばCGのオペレータとしてのスキルを高めることはできるでしょう。しかし昔のアニメーターが1枚1枚手作業で絵を描くことで引き出された創造性は、CGからは生まれてこない。みなCGによって生まれた作業の余裕を、「かっこよく見える」といった通俗的な効果や、「本物らしく見える」というような安易なリアリズムにつぎ込んでしまうでしょう。CGの利用によってアニメ作成の作業が細分化され、若いアニメーターの中にはコンピュータを操作することが自分の仕事だと思い込み、周囲とのコミュニケーションもなくアニメ作成全体への参加意欲もなく、たんなる「使用人」に成り下がっているケースも少なくないでしょう。宮崎監督を含めたスタジオジブリの首脳陣には、若手アニメーターの「才能の枯渇」が目に見える現実となっていたのではないでしょうか。

　そもそもアニメーションの魅力は、人間が描いた絵が「動く」、魂（アニマ）を獲得することにあります。宮崎監督は、ハイテクを使い慣れた現代の若手アニメーターたちに前時代的な手書き作業を強いることで、自分の描いた絵が動き出すという原初的な喜びを改めて感じさせ、そこから新たな形が生まれてくることに賭けたのだと思います。そしてわたしが見るところ、その賭けは成功しています。きっと彼らアニメーターたちは壮大な映画を手作業で実現させたことで、自分たちの肉体と感性がもつ力を改めて再認識し、大きな自信を得たことでしょう。

●ジブリだからできること

　しかし「崖の上のポニョ」のような作成方法は今日では例外的です。作品の品質がどうあれ、CGを使って作画工程を省力化し量産体制をしかなければ、メディアの要請に応えることができません。アニメを手書きすることが個々のアニメーターの創造性に有効なことは理解できても、すでにそのような制作方法はメディアの生態系に合わないのです。これは新世代の創造力を引き出すことができない日本のアニメ業界の構造的危機として捉えなければならない事柄です。

　そういった状況を打開するためにもあえて全編手描きで作画するという方針が試みられたのだと思います。今日、前時代的な手書き長編アニメを作成するのはリスクが高すぎて、ジブリと宮崎駿のネームバリューがなければ実現することはできないでしょう。ジブリは自分のブランドの利益を70人のアニメーターの創造性へ還元したのです。もちろんそうしたからといって、この試みが持続できるとは限りません。ジブリといえども、次回同じ手法をとることは難しいでしょう。しかし今回の「ポニョ」が一定の成功を収め、その試みの意図が正しくアニメ業界に受け止められれば、アニメ業界の構造的問題を変えていく大きなきっかけになるかもしれません。少なくとも、70人のアニメーターが1年半の間、作画に没頭したという経験は、アニメ界全体に長期的な好影響を与えることは間違いないでしょう。

　エンドロールに並んだアニメーターたちの名前は、まるで卒業アルバムの卒業生名簿のようでした。彼らはこれから各所に散ってどんなアニメを作ってくれるでしょうか。

●われらがIT業界は

　そう考えると、これら「ポニョ」作成に参加したアニメーターたちがつくづくうらやましくなります。われらがソフトウェア業界は大部分がアニメ業界と同様、技術者のマンパワーによって実現されていますが、その事実が経営者にはまるで認識されていません。常時、技術革新の大波に洗われていながら、それが生産現場に与える影響に疎く、大型汎用計算機時代の古いビジネスモデルを墨守してきました。ジブリのように技術を発展的に継承できるようなビジネスモデルを作るという試みをする気概のある企業などまったくありません。それどころか、技術の核となる実装工程を海外にアウトソーシングして、実装経験の機会を国内の技術者から奪っています。本来ならば生産工程の工夫習熟で生み出される生産性向上を、その技術継承に投資してインテグレートしていかなければならないものを。

　まあ、実際にはアニメ業界もわれらがIT業界に負けず劣らず労働者を酷使するところだそうです。それを考えれば、インターネットを背景にこれからもますます技術発展、市場拡大の可能性を秘めているIT業界のほうが恵まれているのかもしれません。ただ、ジブリのような理解ある経営者がいてくれたら。ああ、ジブリがうらやましい。

　数年前（もうかなり古いことなので恐縮ですが）、ある大手SIerでのことです。

●ありがたいお話

　突然Webアプリケーション事業部長が話をするから、下請けを含めた開発者全員、会社の大会議室に集まるようにと言い渡されました。大学の大教室のような広い会議室で待っていると、年のころは60歳近く、小柄でやせていましたが重役クラスと思しき事業部長が1人出てきて、講壇に上がり、話し始めました。

　話の内容はこうです。わがWebアプリケーション事業部は発足以来、時代の波に乗って高収益を上げてきた。しかしこの数カ月その勢いがなくなっている。個々人の仕事ぶりも沈滞しているではないか。これはいったいどうしたことだ。

　わたしもその職場では組織上の問題があると思っていたところでした。さすが大企業、問題をいち早く認識している、と感心したのはそこまで。あとがいけない。その事業部長の見解は、要するにわたしたち開発者の自覚が足りないということでしかありませんでした。それで終わるならまだよかったのですが、その事業部長、司馬遼太郎を引き合いに出し、東西の文明論にまで発展した話を、延々2時間しゃべり続けました。わたしたちはスケジュールの遅れにやきもきしながら、その事業部長の教養あふれる話をありがたく拝聴させられたのです。

　課長の月曜朝礼ではありません。歴史小説をネタにした素人文明論など、いやしくも200人にもなる事業部のトップが話すことではないでしょう。この長ったらしい訓話の目的が何だったのかはっきりわかりません。もし事業部の収益が低下気味だというのなら、それは事業部長がハッパをかけるようなことで解決できるような話ではありません。きちんと原因を究明すべく人を使って調べさせ、分析結果を元に組織変更なり作業手順変更なりの対策を検討した上で周知実行する、というような話です。事業部長がこれでは会社の品格が疑われるでしょう。

●これで本当に「大手」？

　わたしにはこの大手SIerの事業部が、規模ばかり大きくとも、実質的な管理能力は大変貧弱で、中小SIerと同じレベルだったように思われます。おそらくこの教養のある事業部長さんの実質的な手足になるスタッフはごくわずかだったのでしょう。実際のプロジェクト管理は下請けから派遣されたPM任せにしていました。事実上プロジェクトを「丸投げ」していたのです。いくら人数規模が大きくても組織としてきちんと管理されていなければ、それは単なる群集に過ぎません。

　そもそも「大手」というのは一体何なのでしょう。ユーザーはどうしてアプリケーション開発を「大手」に発注するのでしょうか。技術力に対する漠然とした期待があるから？ それもあるでしょう。しかしそれよりも何よりも大手には資金力があります。システムを開発するために集めた技術者にはまず給与を支払わなければなりません。そのためにSIerは銀行からお金を借りるのですが、当然大規模な開発には多額の資金が必要となります。そのような多額の資金を借りる信用力は中小SIerにはなく、結局規模の大きい開発案件は大手が受注することになります。このとき大手元請に期待されているのは開発のリスクを負担すること。例えば、開発費が予定をオーバーしても、それをユーザーにも下請けにも及ぼさないことです。ある開発で生じた損失は別の開発の収益で補えばよい。数ある受注案件を総合してプラスになれば、個々の案件のリスクは解消できる。それでこそ、ユーザーには安定してアプリケーションを供給することができ、開発者は安心して仕事ができるのです。大手SIerの存在意義は根本的にここにあります。

　この仕組みは一見うまくいっているように見えます。ITという新しい事業にベンチャー企業も意欲的に投資してくれるでしょうが、やはり安定的に設備投資するのは大手企業です。大手はやはり大手に仕事を依頼する。中小SIerはそこから仕事を請けた方が、自社で直接受注するより営業経費もかからないでしょうし、開発費用の超過も負担してもらえるでしょう。Webアプリの開発はまだ開発ノウハウの少ない分野ですから、何が起こるかわからない。「よらば大樹の陰」というわけです。大手SIerがプロジェクトを「丸投げ」しても、開発リスクを負担するなら少しも不当なことではないし、利ざやを取る権利は十分にあります。

　しかし実際にはこのビジネスモデルは正常に機能していません。というのもソフトウェアの開発では製品品質を評価することが困難だからです。

●ソフトウェアには形がない

　これが建物とか機械のように形があるものならば、製品評価はそれほど難しいことはありません。注文住宅がイメージどおりにできていれば、注文主は満足するでしょう。自動車は人を乗せて走ることができれば、完成品であることがわかります。しかしソフトウェアは形がありません。そのよしあしは使ってみないとわからない。そのうえアプリケーションはつねに特注品（パッケージで売られているソフトはわたしたちが作っているのではありません。あれはCDやDVDの生産ラインが作っているのです／注1）。要件定義の行き違いから、思わぬところで作り直しを要求されるかもしれません。だからPMは設計作業に時間をかけます。Webアプリの場合、設計書は事実上この注文者との間に交わす製品評価の約束書きのようなものです。それでもPMが最終的にでき上がるソースコードを想定し、それにかかる作業を見積もることができるなら、さして支障はないのですが、不幸なことにPMがJava（あるいはPerl、PHP、.NET）の実装を知らない場合（WebアプリのPMはCOBOL開発のPMが横滑りしてくることが大半でした）、設計作業は必要以上に膨れ上がってしまうことになります。PMにも製品が「見えない」わけですから、「見える」ようにするために設計工程にお金と時間を費やす。注文する方もその方が安心できる。だから設計工程はなかなか終了しません。その結果設計工程が必要以上に膨らんでしまうのです。

●どうしてそんなに長々と設計を？

　この大手SIerで起こっていた問題は、まさしくそれだったと思います。わたしが参加したのはそこが抱えていた案件の1つ、某新聞社の読者サービスサイトの開発でした。すでに実装作業を目前にしていて、そのマネジメントをしてくれというのです。実装はそれまで設計してきたSEが引き続き行うことになっています。そういうことならそれまでそのチームを率いてきたPMがメンバーの力量を知っているわけですから、自分で直接管理するのがベストですが、なにか別の仕事があるのでしょう、作業工程の管理ならわたしにも多少心得がありましたのでお引き受けしました。

　ところがスケジュールを見て驚きました。それまで設計に半年かかってきた来たものを2週間で作れというのです。わたしの経験に照らしてみると、2週間で実装できるものに半年も時間をかけるのはナンセンスです。設計に半年かかったシステムは、実装にも半年以上かかります。ところが話を聞いてみると、重要なのはサイトの記事を管理する機能で、この部分にはパッケージのフレームワークがあるから大丈夫だというのです。半信半疑で資料を調べてみると、たしかにそういう機能は用意されています。パッケージの設計思想が古く、MVCパターンを想定していないのが不満ですが、たしかにこれなら2週間で（実際には3週間かかりましたが）できそうです。しかしそれならなぜ半年も設計期間が必要だったのでしょうか。

　わたしがPMなら、最初に一部分を手分けして実装してしまいます。そうすれば技術者は製品のパターンを理解しますから、ほかの部分の設計に時間がかかるようなことはありません。実装に1週間（5日間）かかる機能は3日以内で設計できるでしょう。このPMはそれをしませんでした。自分がわからないことを部下にさせるのは（たとえ部下がそれに習熟していても）不安なことです。それゆえ部下の作業をコントロールするために、またあとで元請から責任を問われないために、必要以上に設計工程に時間をかけてしまったのでしょう。いずれにしても彼は設計工程に無用の人的資源を費やしたことになります。

　この傾向はこの会社の他のプロジェクトでも起こっていたと思われます。それは製造費用の上昇となって事業部の利益を圧迫したでしょう。事業部長が出張ってハッパをかけにきたのも、開発費がいたずらに上昇しているのが数字に表れたからだったと推測します。

●これって職場いじめ？

　ちなみにこのプロジェクトでのわたしの仕事は散々でした。工程に余裕がありませんでしたので、実装作業にむだが出ないよう毎日ミーティングを開いて進捗を管理したのですが、それが厳しすぎると思われたのか、SEの1人から猛烈に反発されました。技術的には不安のある人でしたが、そのチームでは1番の年配者で、職場では発言力がありました。進捗会議ではわたしに反抗的な態度を見せ、陰にまわってはわたしの悪口を言っていたようですが、こちらは新参者のPM代理、自分の権限もはっきりしていなかったので、手の打ちようがありませんでした。わたしを雇ったPMも何もいいませんでした。ともかくも実装作業が終わり、わたしはプロジェクト管理からはずされることになりました。やれやれ、これでプログラミングに戻れると思ったところ、いきなり契約を打ち切られてしまいました。理由ははっきりしません。PMからは何も説明がありませんでした。そのときは人間関係のトラブルがマイナスに評価されたからかと思ったのですが、どうやら単にプロジェクトに人手が要らなくなったから、不要の人間から切るということだったようです。

●泣きを見るのは外注PG

　コンビニの「名ばかり店長」に見るように、権限のない管理職は悲惨なものです。この会社のプロジェクトはまだ幸せな方でした。PMが自分の裁量で人員を増やす権限を与えられていたのですから。PMにそういった権限のない場合、またそういった予算のないプロジェクトの場合、事態は悲惨なことになります。しかもその被害は下流の実装技術者が受けやすい。各工程で起こる問題は、例えば人的資源の不足であったり、現場技術者の怠慢であったりしますが、PMはこれらをそれぞれの工程で解決するようなことはあまりしません。スケジュールの遅れにして先延ばしします。増員が無理でも時間の配分は自分の判断で簡単に裁量できるからです。人は自分の自由になる方法で問題を解決しようとするものです。それがたとえ一時しのぎに過ぎないとしても。問題が先送りされた結果、実装工程がひどい労働条件になっても、元請から文句をいわれなければ自分の責任ではない。そして元請は作るものだけ作ってくれるなら文句はいわない。泣きを見るのは外注PG、ということになります。

●本当はすごい実装工程

　こんな理不尽な理由から過酷な条件を突きつけられても、これまでPGが何とか耐えてきたのは、技術革新のおかげで実装工程の生産性が日夜向上してきたからです。JavaによるWebアプリケーションでいえば、IDEツールとしてeclipseが無料で利用できるようになり、Struts、Springなどの優秀なフレームワークがオープンソースで供給されたことなどによって、実装工程は格段の進歩を見ました。それがなければWebサイトの実装を2週間で仕上げろというような無理な注文には対応できなかったことでしょう。

　しかしこのことは「上流」からは見えにくい。eclipseもStrutsも実装者がネットで手に入れたフリー（無料）の資源ですから、コストの要素として意識されないのかもしれません。ふつう技術革新は生産工程にプラスになると考えられていますが、実際はそんなに単純ではありません。逆に全体の生産コストを増やしてしまうかもしれない。「無理を承知でPGにやらせてみたらうまくいってしまった。ラッキー♪」で終わってしまったら、そのPMはこまったPMです。

●技術革新の落とし穴

　本来、技術革新は工程ごとの資源配分とともに評価されなければなりません。ある作業で生産性が上がっているとしたら、それは何が原因でそうなっているのか。それは持続するのか。そのことで生じた利益はコストに正しく反映されているか。そういった分析をしなければ正しいマネジメントとはいえません。この場合、実装工程で生じた余裕が設計工程でむだに費消されてしまっているので、全体のコストが下がらないし、逆に上昇してさえいるのです。

　さらにこの状況を助長しているのが、大手が受注して下請けが生産するというIT業界の産業構造にあるのです。先ほどふれましたように、IT業界ではどうしても大手SIerに受注が集まってしまう傾向がある。というのもソフトウェアの開発は事前にコストを見積もるのがむずかしい。くり返しになりますが、わたしたちが作っているものは「特注品」です。しかも実装にどれだけの時間がかかるか、わたしが自分で作る場合でも正確な数字は出せません。まして実装作業はPGの技量に大きく左右されます。PMはそれを無理やり「人月」ではかって見積もりますが、開発の規模が大きくなるにつれてその誤差は拡大するでしょう。この誤差がもたらすリスクは中小SIerの経営を揺さぶります。それで中小SIerは大手から仕事をもらうようになる。

●まちがったビジネスモデルがもたらす悲劇

　しかしこのビジネスモデルでは、元請SIerからはコスト発生の構造が見えなくなります。元請は案件の受注を増やして見えないリスクを吸収しようとする。それを下請けSIerにばら撒くようにして作らせるわけで、当然個々の案件については目が届かなくなる。下請けの言うとおりに開発費を支払うのだけれど、それが有効に使われていない。たとえていえば穴の開いたバスタブにお湯を張ろうとしているようなものです。

　こんなことをいうと誤解されそうでいうべきかどうか迷うのですが、「下流」のわたしが見るところ、Webアプリの開発はもっと少ない工数で開発することができます。わたしにはソフトウェアの「形」が見えるのでそう思うのです。そして設計工程の人員を減らし、ユーザーとプログラマが直接対話して仕様を作っていけるような開発体制を作れば、その工数はもっと減らすことができます。

　しかしこれはリスクが低くなるということではありません。ソフトウェアの開発リスクはその作業の特性上、下がることはありません。ただそれはお金に換算して負担すべきものではないのです。例えばリスクを絶対に予測できないビジネス、鉱山業や石油採掘ならこのモデルは有効でしょう。大鉱業資本は、有象無象の山師が持ち込む投資話にいちいち耳を傾けお金を出してきました。その投資の多くがむだになったことでしょうが、そんなむだがなければ今日わたしたち人類が利用できる地下資源の多くは発見されなかったことでしょう。しかしソフトウェア開発はそうではありません。リスクをお金で解決しようとしても、余分な投資は本来流れるべきところに流れず、要らぬところに流れてしまうのです。

●これはPMの責任ではありません

　このようなことをいうと、PMにすべての責任があるように聞こえるかもしれませんが、私は決してそういうことを言いたいわけではありません。PMはたんなる労働者にすぎません。PMは雇用主、注文主の求めに従って作業を配分し、経済原則に従ってアウトソーシングしているだけなのです。問題は仕事の性質に適合しないプロジェクト管理が、業界の構造によって維持されてしまっていることにあるのです。

　リスクは本来それを負担できる人が負担し、評価しなければなりません。今のビジネスモデルを維持していこうと思うなら、元請は生産工程に目を光らせ、個々に発生した遅滞の原因を突き止め、工程の誤りを是正していかなければなりません。そうしなければリスクの原因はいつまでも解決されず、IT開発はいつまでもハイリスクな事業にとどまるでしょう。リスクの芽は小さなうちに摘み取ってしまう。そうすればそのリスクは次からは予測可能になる。そのようにして管理を洗練していくことこそ本来あるべきビジネスの姿ではないでしょうか。

　件の事業部長にはこのようなことをするどく指摘してもらいたかったのですが、どうも教養がじゃましたようですね。

●現代の若者は大志を抱けるか

　わたしたちのIT業界は技術進歩の激しいところです。半年前の新技術はもう古いものになっています。技術の進歩は作業工程の生産性を大きく塗り替えます。このことはプロジェクト管理の面から見れば、たぎった溶岩の上にいるのと同じです。プロジェクト管理はそのことに敏感でないと、プロジェクトを大きくゆがめます。われわれの業界は、すさまじい技術革新による生産性向上にもかかわらず、「3K」と呼ばれて若い人に敬遠されています。生産技術の革新が生産現場の労働条件の改善に結びつくどころか、逆に悪化させている場合、それはなによりもまずプロジェクトの管理に問題があると考えるのは常識ではないでしょうか。ところがこの常識がこの業界では通用しない！

　大手SIerの経営者は「10年は泥のように働け」などという前に、このことを考えてほしいものです。

注1：この見解には異論をもたれる方も多いでしょう。最近は「ソフトウェアプロダクト」なる概念も提唱されていますが、この考え方は生産性向上という面においてはあまり効果をもたらさないように思います。これについてはいずれ私見を申し上げようと思います。

　これから申し上げるのは、わたしが実際に仕事の上で経験したことです。これらは今日のIT業界の病根の深さを示すものです。

　とある会社のシステム開発に呼ばれていったときのことです。まず見せられたのは画面見本でした。すでにHTMLで詳細な画面が作られています。画面数が多く、画面上の項目数も多い。これは相当意欲的なシステムだと思われました。これを実装できるなら、きっと充実した仕事になるでしょう。

　ところがいつまでたっても開発が始まりません。誰がプロジェクトを管理しているのかもわからない。誰もスケジュールをはっきり説明できません。おまけにドキュメントサーバのどこを探しても基本設計書がありません。業務フローもなければシステム構成図もない。膨大なER図だけが公開されていて、ときどき修正されているらしい。

　いつまでも遊んでいるわけにはいかないからと、詳細設計書を先に書くことになりました。基本設計書がないのに詳細設計が書けるか！ 普通の人なら驚くでしょうが、この業界ではよくあることです。IT業界の技術は日進月歩で、プログラミング工程はたいへん生産性が向上しています。製造工程であまったマンパワーを設計工程に回すために、詳細設計書はPG自身が書くことは珍しくありません。基本設計書が変更になれば、当然その設計書も手戻りになりますが、遊んでいるよりはいい。

　いやだったのは、それにもかかわらずこってりとレビューをすることです。いったい何を根拠にレビューをすればいいのでしょう。チェックするところといえば、段落はさげてあるかとか、句読点は打ってあるかなどといった形式上の瑣末事です。それもすぐユーザーから仕様変更が伝えられて書き直しになる。またレビューのやり直し。文書直して、アポとって……。

　しばらくそんな不毛な作業を繰り返しているうちに、上流で何が起こっているか次第にわかってきました。元請SIerがユーザーと揉めていたのです。元請は見積もりを誤ったのか、機能が多すぎるので削ってほしいといっているらしい。ユーザーは受け入れたくないし、何より元請業者の開発方針に不審を抱いているようでした。いつまでたっても納得できるような基本設計が出てこない。SE、PGをたくさん集めたけれど、仕事はしていない。きっとユーザーには人手不足を理由に人間をかき集めただけで、管理する能力もなく遊ばせていると見えたことでしょう。

　上流でことが進まないなら、せめて下流ではこの時間を利用して開発準備を進めていたいところですが、それもどうも怪しい。そもそも先行してコーディング作業に入ることが禁止されていました。個々のプログラマにソースを任せてしまうと、どんな勝手なソースを作るかわからないからというのでしょう。いくつかのパラメータを入れればスケルトン（プログラムの原型）を作るツールを作って、それを使うことを義務付けようとしていたのです。ところが何度見ても出力されるスケルトンの構造がわからない。おまけにそのツールの動作が不安定だし、操作方法が意味不明だし、しょっちゅう手直しが入るし、これならEclipseでコピーして作ったほうが早いと思われました。ただ若手の新しがりのSEの自己満足のために作られたようなツールでした。

　そのうえプロパー社員SEの技術レベルは悲惨なものでした。わたしが下についたSEはやたら威張っていました。年のころは30歳前半だったでしょうか。わたしは彼が何か具体的な成果物を作っているのを見たことがありません。単にわたしの詳細仕様書に対する「お目付け役」だったように思えます。まあ、下の人間は上の人間が何をしているのかは理解できないものです。何かしていたんでしょう、きっと。

　あるとき彼は、わたしが書いた仕様書にテーブルの検索条件が書き込んであるのを見つけて烈火のごとく怒り出しました。

　「SQLを設計する前に報告するようにといったでしょ！」

　その声の大きいこと、周りにいた人たちが驚いて振り向いたくらいです。

　要するにその部分は自分が設計するつもりでいたのを、わたしがさっさと書いてしまったので怒り出したのです。あとから知ったのですが、そのSEはSQLしか知りませんでした。つまり自分もきちんと詳細設計ができるところを見せつけて、わたしを恐れ入らせようとしていたのです。

　まったくバカなSEもいたものです。SQL設計など下流に任せておけばいいものを。テーブルの検索条件だけははっきりイメージすることができるので、そこだけは人任せにできなかったのでしょう。人を使うことの基本ができていない。やがて何度かやり取りするうちに、わたしの管理をするのに飽きたのか、異動願いを出して、先述のスケルトンツールを作る部署へと移っていきました。そんなスキルでそこの仕事が勤まったかどうか知りません。

　わたしにはこのSIerが、社員の技術を空洞化させてしまった典型的なケースに思えます。ソフトウェア開発の業界では、PGよりSEのほうが単価が高いので、SIerは自分の社員をできるだけ早くSEにしようとします。そのためSIerにはSEがたくさんいますが、実装技術が未熟な人も多い。わたしを担当したタカビーなSEのように、すこしばかりSQLをプログラミングしたというだけでSEの業務につかされるケースも出てきます。彼らがしてきた仕事はといえば、ほとんどが仕様書作成。わたしはあまり役にも立たない仕様書作りなどまともな仕事だとは思わない（失礼！ でもそう思う理由はあるのです。いずれ説明したいと思います）のですが、それだけを専門にしてきたSEはそれが正しい有意義なシステム開発の手法だと思い込んでいます。それを2、3年も続ければ、当然自分はさらに上流工程で仕事ができると思い込んでしまう。それが出世だと思い込んでいるし、そうしないと自分はいつまでもつまらない仕様書書きを続けさせられることになる。件のSEからは、実装作業に対する根拠のない侮りと、強烈な功名心と自分の置かれたポジションについての不満しか感じられませんでした（真の技術者はあまりポジションには執着しないものです。自分の技術が自分の価値を決めるのだと知っていますから）。

　ユーザーとの間に起こったトラブルも、SIerの基本的なプロジェクト管理能力、設計能力に対する不信が大きな要因だったと思えます。IT開発の基礎体力であるプログラミング技術がなくなると、プロジェクト管理ができません。というのもプロジェクトの管理には実装作業の豊富な経験が必要だからです。仕事を適正に分担すること1つにしても、PG各人の技量を詳しく知らなければできません。未熟なPGはちょっと複雑な仕様にぶち当たっただけでプレッシャーに負けてしまったりします。ですからPMはSE、PG全員をよく知っているベテランがなるのが望ましいのですが、最近は若手社員がなることすらめずらしくはない。人の入れ代わりが激しいので、プロパー社員の絶対数が少ないのです。PMは、たとえば工期の遅れを取り戻すために臨時に作業者を増員するなどの権限が必要な「管理職」、おいそれと外注するわけにも行きません。その結果、経験不足を承知で若手社員をPMとして登用しなければならないのです。若手PMがすべて無能だとは思いませんが、SIerのプロジェクト管理能力を低下させる構造的要因の1つであることはまちがいありません。

　最近ネットで検索すると、ユーザーとSIerの間に信じられないような揉め事が生じたという記述を目にします。わたしたち実装屋には上流で何が起こっているかよくわからないのですが、下流から実際の開発体制を見ていると、そんなシュールな噂がいちいち納得できてしまうのです。恐ろしい話です。

　初めまして。職歴20数年のプログラマです。ときどきSEもやります。

　IT業界でいわゆる下流工程（「下流」とは最近なんともいやな言葉になってしまいました）で長年プログラム製造の仕事をしてきました。ソフトウェア開発の現場に近い位置に身をおいていると、この業界がとんでもない構造的問題を抱えていることがよくわかります。

　IT関連のブログというと、書いているのはたいていがコンサルタントやITライターの方など、「上流」工程におられる方々が多いように思えます。これらのブログも非常にためになるのですが、わたしがふだん思っていることとはだいぶものの見方、考え方がちがっているように思えます。「問題はそんなところにあるんじゃないよ」とか「実態を知らないんじゃないか」と思うことしきり。

　「もの言わぬは腹ふくるるわざ」と申します。王様の耳の秘密を知ってしまった床屋のような気分。葦の茂みに穴を掘って「王様の耳はロバの耳」と思いのたけを叫んでみたくなります。さいわい＠IT自分戦略研究所がわたしに意見発表の機会を与えてくださいました。＠ITに感謝しつつ、ここでわたしなりの問題提起をして見たいと思います。しばしおつきあいのほどを。

　とはいうものの、最初から固い話ではじめるのもなんですので、ちょっと感覚的な話から始めましょう。お題は「におい」についてです。

　どんな仕事についている人も、その仕事独特のにおいがあるものです。街を歩いていて、突然歩道の横にワンボックスカーが横付けして、中から機能的でカジュアルな格好をしたお兄さんがはじけるようにして飛び出してきて、てきぱきと後ろのドアを開け、荷物を降ろし始めたなら、それは十中八九TV業界の人です。彼が引き出すのはカメラの三脚、ジュラルミンケース。そうしている間に、別のスライドドアからはカメラをひざに抱いたおじさんがちょっと重々しく出てきて辺りを見回し、助手席からは女性ディレクターが出てきて仕切り始めるといった寸法。わたしはこの業界の人たちと一緒に仕事をしたことがあるので、においでわかります。

　また法曹関係の人々も一種独特な雰囲気を持っています。大きな書店の法律書のコーナーに行くと、そこにいるのはきまって地味な背広を着て、黒いかばんをさげた男性の方々。せかせかした感じがしないのは、きっとあまりスケジュールに縛られない生き方をしているからでしょう。なかにはすっかり頭の禿げた年配の方もいらっしゃいますが、齢はとっても勉学心旺盛なことが背中でわかります（不思議なことに、こういうところではあまり女性を見かけないような気がします。「辣腕の女性弁護士」というイメージはテレビドラマの見すぎでしょうか）。

　さて、本題のIT業界人のにおいですが、一時期、誰が見てもはっきりわかるにおいをさせていたことがあります。1980年代後半、パソコンの普及とともにコンピュータ関連の書籍がにわかに書店の棚にのさばり始めたころ、その棚の間にたむろしていたのは、年のころは20代後半から30代、しらっぱけたジーンズによれ気味のトレーナーを着、時に髪の毛は寝ぐせのまま、身なりに関心がないというスタンスがあまりに自然に身についたお兄さんたちでした。

　なにやら留年学生風でもあり、かといって暇をもてあましている風でもなく、ひとつ仕事に打ち込んでいるという凄みがどことなく伝わってくる。周囲の人にはほとんど関心を払うようすがなく、表情に喜怒哀楽も見えない。ただじっと本の背表紙を眺めては、頭の中で筋道だった考えを高速で展開しているように見える。

　彼らはプログラミングの魔力に取り付かれた人々でした。キーボードを叩きまくり、複雑なロジックを組んではほぐし、ほぐしては組む、そんな作業を長時間続けてきたことが、ほとんど体臭となっていました。ひとつところをじっと見つめる癖は、CRT画面を眺め続けたためでしょう。無表情に見えるのは、プログラムが思い通りに動いたという、自分にとっての人生最大の喜びが、他人には説明のできない、また説明する必要を感じないものだったからでしょう。

　そう、この時代IT業界（当時はまだ「IT」なんて言葉はありませんでしたが）を代表していたのは、いわゆる正統派「ハッカー」気質の人々でした。1980年代後半16ビットパソコンとMS-DOSという組み合わせが急速に世界中に広まってきたころ、それまで8ビットマシンの上でホビーのなかに閉じ込められていた個人のプログラミングの才能が、安価に提供されたビジネス向けパソコンというプラットフォームの上で華々しく展開されていったのです。これらの才能が数々の優れたアプリケーションソフトに結実し、やがてインターネットを媒介にして相互に結びついて、Linuxをはじめとするオープンソースのコミュニティを形成するのです（きっとトーバルズ氏もスティーブ・ジョブズ氏も、強烈なハッカーのにおいをさせていることでしょう。お会いしたことはありませんが）。

　しかしこんなハッカーのにおいをさせる人々は、書店からいつの間にか姿を消してしまいました。彼らはいったいどこに行ってしまったのでしょう。ネットがあるから、もう情報を書籍に頼る必要はなくなったのでしょうか？ いえいえ、まとまった知識を得るためには書籍のほうがはるかに効率的なメディアです。

　最近、書店のコンピュータ書籍コーナーで見かけるのは、必要に迫られてやってくる人たちばかりです。破綻しかけたプロジェクトに何か妙案はないかと探すプロマネ風の40代。儲け話につながるイノベーションはないかと嗅ぎまわっている30代。就職が決まらず、コンピュータ入門書をこわごわ覗く20代。

　むしろ活気があるのはWebデザインのコーナーですが、こちらに集まる若者たちはまったく違った人種です。ヒップホップかウラハラか、大人たちにはよくわからないけれどとにかくお金をかけずに自己主張したいというスタンスのおしゃれに身を包み、何を見ているのか視点が定まらない夢見る少年少女たちといった風情の若者たち。彼らは、自分が見た夢を他人に理解してもらいたいという欲求を抱えてそこに集まっていると見えます。

　要するに、この業界も広くなって、いろいろな人が参入しているということでしょうが、それにしてもハッカーたちはどこへ行ったのでしょうか。いろいろな人たちの間にまぎれて目立たなくなっているのでしょうか。

　ひとつ気がかりなことがあります。

　わたしには悪い癖があって、休日など暇なとき喫茶店に一人で入って、他人の話に耳を傾け、その人たちの生活や仕事について想像をめぐらしたりするのですが、最近スタバなどのコーヒーショップでは、年のころ20代後半、さりげなく高そうなカジュアルウェアを着て、自分たちの仕事について談論風発している若い人たちを見かけます。彼らの話から「納期」とか「プロジェクト」とかいう言葉が聞き取れますので、もしかしたら同業人かとあたりをつけるのですが、それにしてはコンピュータ用語が少しも出てこない。「OS」も「データベース」も「サーバ」も一切出てこないのです。

　彼らは仕事の愚痴を言い合うでもなく、むしろ今の仕事には十分満足しているらしい。それどころか自分の前に開けた出世の可能性にわくわくしているのが目の輝きから読み取れます。すぐそばでおじさんが立ち聞きしているのも気づかずに、彼らは仕事の薀蓄めいた話題をひとしきり得意げにしゃべった後、

　「技術には深入りしないほうがいいね」「うん」

と、なにやら後ろめたげにうなずき合った後、急に話題を失って黙り込んでしまう。こんなことが2度ほどありました。

　だいぶ前からIT業界は「3K」だとかいわれて、非人間的な使われ方をする産業だという評判が定着しています。そんなおそろしげな世界に果敢に乗り込んでくるのは、こんな野心たっぷりの、恐いもの知らずの若者たちなのでしょうか。それはいいのですが、そんな若者たちが一番恐れているのが、どうやら「技術に詳しい」という社内評価を立てられることのようなのです。彼らにしてみれば、生産部門に配属されるのは、自分のキャリアにとって損失であり、そんなことがないよう、上流をすいすい泳ぎ渡ってえらくなっていきたいというのが本音かもしれません。

　もちろんこれは、わたしが巷で立ち聞きした話の断片から組み合わせた推測に過ぎません。しかしもしこの推測が正しければ、それは日本のIT業界には技術に対する軽視、軽蔑、忌避の傾向が蔓延しているということではないでしょうか。

　1980～1990年代IT業界を闊歩していたハッカーたちは、この環境の変化が原因で激減しているのではないでしょうか。地球温暖化で絶滅の危機にあるホッキョクグマのように。もしそうだとしたら恐ろしいことです。

　銀行が営業できるのは一般預金者の貯金を背景にした信用があるからです。車が売れるのは高性能で安全な車を生産する力があるからです。どの企業も自分の利益の元は大切にし、常に気にかけています。IT業界が自分たちの利益の源をおろそかにしたらどういうことになるでしょう。これは日本のソフトウェア産業の危機ではないでしょうか。

　これからしばらくこのコラムを借りて、「下流」から見た、現在日本のIT業界が抱える構造的な問題について書いていきたいと思います。自分の経験にもとづいた、推測と独断と偏見の入り混じった話になると思います。反感を感じたり、憤慨したりする方がいらっしゃるかもしれません。反論は甘んじてお受けしますので、興味のある方はしばしお付き合いください。

　ところで、わたし自身はどんな「におい」をさせているかって？ さあ、それはわたし自身、他人になってみないとわかりません。