| Tweet |
http://itpro.nikkeibp.co.jp/article/COLUMN/20070306/264055/?ST=system&P=1
松原友夫 松原コンサルティング
ソフトウエア・エンジニアリングのリーダーの一人、エド・ヨードンは1992年に、『Decline and Fall of the American Programmer 』を著し、米国のソフトウエア産業の衰退と挫折を警告した。この本を出す少し前まで、彼は「この国が危ない（A Nation at Risk）」というタイトルで講演行脚をしており、同書はそれをまとめたものである。
この本の中で、ヨードンは日本をソフトウエア開発における優等生の一人として挙げ、インドの飛躍を予見している。本が書かれた時点では、インドのＩＴ産業はまだ黎明れいめい期にあったが、彼の予想通り、現在は英語圏で質の高いソフトウエア開発力が得られる国として、欧米から頼られる存在になり、ＩＴ立国を目指す他のアジア諸国からお手本と見なされるまでになった。
「この国が危ない」というヨードンの警告に触発されたのか、米国上院の「米国の通商、科学技術、及び運輸に関する委員会」は91年に、「米国のソフトウエア産業の競合性」に関する公聴会を開いた。出席者は、ジョンＦ. ケリーを含む22人の上院議員であった。証人には、元ＩＢＭで当時は三菱電機研究所の所長を務めていたラスズロ・ベラディー、日本ではおなじみのマイケル・クスマノ（当時はＭＩＴ教授）、ケーデンス社のジョセフ・コステロ、オラクル社のロバート・マイナー、マイクロソフト社のウィリアム・ニューコムの名がある。公聴会でベラディーは次のように証言した。
「ソフトウエアを一つの産業セグメントと見るのは危険です。（中略）どの産業も増え続けるソフトウエアで動いているのです。ソフトウエアの競合性は、既存のある産業の競合性の問題なのではなく、産業全体の競合性に関わるのです」
ソフトはすべてにかかわる
これはソフトウエア産業が他の産業と著しく異なる点である。例えば、自動車産業なら、それを構成するメーカーは数社に限定される。ソフトウエア開発会社の団体である情報サービス産業協会がソフトウエア産業を代表していると思うのは大間違いで、ソフトウエア開発は、銀行、証券、運輸、流通、そして自動車や家電メーカーなどすべての業界で行われており、その質は基幹ビジネスの競合力、時には安全性さえ左右する。
世界のIT産業をリードしてきた米国の政治家が、91年にソフトウエア産業の競合性をテーマにした公聴会を開いたこと自体、意外の感がある。その 5年後、ヨードンは前著と対照的な、産業の目覚めと復活をタイトルにした、『Rise and Resurrection of the American Programmer 』を著し、米国のソフトウエア産業の復活を高らかに宣言した。
米国のＩＴ産業を復活させたのは、オブジェクト指向やアジャイルと呼ばれる創造的なソフトウエア開発方法であった。さらにインターネットを利用したFedExの追跡システムのような、斬新なビジネスモデルの登場も、ＩＴ産業を刺激した。
一方、90年代のほぼ同じ期間に、日本は大型コンピューター（メインフレーム）から、複数の小型コンピューターを組み合わせたクライアントサーバーシステムへの移行に乗り遅れた。ソフトウエアエンジニアリングの世界を見ると、オブジェクト指向への転換が遅れ、アジャイルあるいは「XP（エクストリームプログラミング）」と呼ばれる新しい開発メソッドは拡がらず、インターネットを使ったいわゆるドットコムビジネスの美味しいところは欧米ばかりかシンガポールなどアジア諸国に先取りされる、という状態に陥った。
今でこそ日本の政治家や役人はＩＴの重要性を唱えるが、インターネット出現の初期に、それがあらゆる分野でパラダイムチェンジをもたらすことを予見した政治家や役人はいなかった。既に確立した知識の上にあぐらをかいた権威者たちには、インターネットがもたらす地殻変動のような変化が見えなかった。
ヨードンが前掲書に、またクスマノが『日本のソフトウエア戦略』に書いたように、メインフレーム全盛時代の日本のソフトウエア開発力は、かなり高い水準にあると評価された。当時の調査の実態を知る筆者から見ると、これらは選別されたデータに基づく、やや過大な評価であった。それでも、富士通、日立製作所などコンピューターメーカー各社が、製造業の伝統を継承し、それぞれが「プロダクト指向の品質ドリブンモデル」とでも言うべきソフトウエア開発モデルに沿って、かなり高い水準の品質と生産性を達成していたことは事実である。当時の日本企業はソフトウエア開発環境への投資にも熱心であった。
ところがその後、米国やインドとは逆に、日本のソフトウエア開発の国際競争力を憂慮せねばならない状態に陥った。開発プロジェクトの混乱、製品出荷後の不具合、システム稼働後のトラブルをしばしば耳にするようになり、国内の開発者だけではソフトウエア開発への要求を満たせなくなった。
なりふり構わぬ大量採用
日本のソフトウエア産業衰退の跡をたどるために、少し時間軸を前に戻そう。1970年から80年代にかけて、ソフトウエア開発の需要が急増した。この時期に、日本は産業界を挙げて、プログラマー採用競争が起こった。大企業は軒並み三桁から四桁の単位で新卒をかき集め、内定者をつなぎ止めようとあの手この手を使った。
それでも大手コンピューターメーカーや大手のユーザー企業は旺盛なソフトウエア開発需要を満たせず、ソフトウエア会社から派遣されてくるプログラマーを大量に使うようになった。中小のソフトウエア会社も採用競争に参加し、文学部や商業高校まで枠を広げた。開発要員の調達に苦慮する産業界は、政府にプログラマーの不足を訴えた。
84年に通産省は「90年に60万人のソフトウエア技術者が不足する」と予測した。この数値は後に「2000年に97万人が不足」と修正された。しかし、産業側にも政府側にも、要員の質についての意識が希薄であった。
中小のソフトウエア会社は、市場からの要請に応えて、新卒者をろくな教育もせずに開発プロジェクトに放り込んだ。大企業が採用した新卒者も、大量の採用で教育に手が回らず、事情は大して変わらなかった。
国家プロジェクトの失敗
80年代の初めに、通産省はソフトウエア技術者不足に対処する目的で、250億円もの予算を注ぎ込み、「Σ（シグマ）計画」を発足させた。「ΣＯＳ」と呼ぶ、ソフトウエア開発者が自由に利用できる開発基盤を整備し、ΣＯＳ上で作ったツールやソフトウエアを交換可能にしようという狙いであった。しかし、Σ プロジェクトは五年後に何の成果も出せないままひそかに幕を閉じた。
自由で先進的な考えを持つソフトウエア技術者は、ソフトウエア開発者や研究者が自由に情報やツールやアイデアを交換できる共通プラットフォームを求めていた。彼らは、草の根で普及した「ＢＳＤ版ＵＮＩＸ」という基本ソフトを使った全国的なネットワークの構築を目指した。彼らはワークショップに集い、Σ計画の要求仕様というべきものをまとめて提出したが、それはものの見事に無視された。
結局、日本共通の開発基盤となるべきΣＯＳは、ＡＴ&Ｔ（米国電信電話）が開発した「ＵＮＩＸ ＳｙｓｔｅｍＶ」を基にすることになった。ところが、各コンピューターメーカーが個別にＡＴ&Ｔと交渉して開発を進めたため、ＳｙｓｔｅｍＶを基にしているものの、互換性のないΣＯＳが、しかも複数個できるという事態に陥った。こうしてＵＮＩＸのまがい物がたくさんできあがった。
しかも大蔵省を説得するためにプロジェクトの目的に加えられた「生産性向上」という名目の下で、コンピューターメーカー各社は、自社でさえ使われない開発ツール類をΣ用に焼き直し、成果物として押し込んだ。当然、各社のツール間に互換性はなかった。大手コンピューターメーカーは、ソフトウエア技術者の想いとは関係なく、250億円という国家予算を争って食いつぶした。
技術者一人ひとりの自覚の上に、相互が刺激し合い、ソフトウエアを開発する。そのための共通の場を用意する。こうした共通環境を建設するという理想は、ここに完全についえ去った。後には、相互に刺激を受ける機会の乏しい、人海戦術的開発に従事する60万人のプログラマーが残った。Σ計画の失敗で、日本は、ソフトウエア産業の基盤を強化するまたとない機会を逃した。
この間、ヨーロッパ諸国では、「Ｅｓｐｒ ＩＴ」と呼ぶプロジェクトで、日本のΣ計画と同じような目的のソフトウエア開発環境「PCTE （Portable Common Tool Environment）」を開発していた。ＥｓｐｒＩＴプロジェクトが完了した頃、筆者はたまたまヨーロッパのいくつかのソフトウエア会社を訪れ、各社がＰＣＴＥに基づいて開発ツールを作り販売しているのを知った。他にもいくつかの成果があり、ヨーロッパ諸国が日本より公的資金をはるかに有効に使っているのを知った。
技術伝承の断絶
メインフレーム全盛時代は、メーカー各社がユーザー企業を囲い込んでおり、多種多様な用途に耐えるように、コンピューターハードウエア、基本ソフトウエア（ＯＳ）を自社で開発しなければならなかった。自己流で非効率な部分があったとしても、ハードウエア生産で培ったエンジニアリングをソフトウエアに応用し、直面する品質や生産性の問題を解決してきた。
ところがメインフレームからクライアントサーバーへと技術の世代交代が起きた。このときに、経験を積み上げてきた技術者は表舞台から姿を消し、新たな技術で育った人たちに置き換わり、技術の伝承ができなくなった。
ちょうどその頃、ソフトウエアの開発プロセスを改善する国際的な動きが目立ってきた。87年には、ソフトウエア開発能力の成熟度を示すCMMと呼ばれるモデルが、次いで94年にISO9000が品質マネジメントシステムの国際規格として公表された。日本では、まずISO9000によるソフトウエア開発組織の認証が、次いで国際的なデファクトスタンダードになったCMMによる成熟度レベルのアセスメントが始まった。
それを契機として、グローバル化の旗印の下、これら外来のモデルに基づく認証獲得、またはレベル達成がブームになった。モデルをソフトウエア開発力の改善のための手段と位置付け、プロセス改善の客観的な成果を知るためにアセスメントを受ける真面目な組織も増えた。
その一方で、目的と手段とを取り違えて、モデルに書かれたプロセスを表面的にこなし、小さな範囲で要領よく認証を取得し、あたかも会社全体がレベル達成したように宣伝する企業も増えた。認証獲得やアセスメント自体を目的とすると、達成した途端に経営トップが投資意欲を失い、地道な改善活動を妨げる。後には死んだ規格や形式的に書類に記録をするといった無駄な作業が残り、本来の目的と逆の結果をもたらす。このため、認証やアセスメントは、自主的かつ積極的にプロセス改善に挑戦する闘士ではなく、モデルを金科玉条のように扱い、かえってモデルに振り回される、受け身のマニュアル人間を増やした。
以上のような様々な問題点に加え、日本のソフトウエア開発の産業構造には、決定的な欠陥がある。ソフトウエア技術者の派遣ビジネスである。
大規模な開発プロジェクトの場合、ソフトウエア開発の仕事は、ほぼ例外なく複数の会社に分割発注される。ところがソフトウエアシステムをサブシステムに分割して請け負わせるケースは少なく、多くの場合、「一カ月いくら」で契約する派遣プログラマーを雇い、プロジェクトチームに組み込む。派遣会社の間で技術者を貸し借りするので、技術者が多層化する。いわゆる多重下請け構造である。発注者でさえ、実際の階層数や末端の会社名を知らない。ある政府のプロジェクトで、危険視された宗教の信者が最下層に参画しており、それに管理者は気付かなかったという話さえある。当然、開発責任は曖昧になる。厄介なことに、派遣契約の多くは請負契約を装っているので、書類だけでは実態はわからない。
派遣がすべて問題なのではない。現に欧米でも派遣に相当する契約はある。それは、開発規模を決めるビジネスモデルをコンサルタントが作る場合や、不確定要素の大きい革新的なプロジェクトでリスクを避けるために使われる。また、成果物の品質責任を問われない事務的な仕事では、派遣は便利な形態である。しかし、品質に関して重大責任を負うに至ったソフトウエア開発ビジネスで、成果責任を負わない派遣形態がかくも横行しているのは日本だけである。
派遣ビジネスの問題
派遣ビジネスは、ソフトウエア開発作業を成果で請け負うのではなく、一カ月いくらというように、技術者の時間を売る。派遣指向のソフトウエア会社にとって最大の関心事は、人月単価（技術者一人が一カ月働くときの単価）と、人の稼働率であって、稼ぎが減る開発プロセスの改善や、余計な金を使う技術教育は、できればやりたくない。特に品質は、技術者だけの問題と見なされ、経営者は関心を持たない。極端な話、派遣プログラマーが自分で埋め込んだバグ（ソフトウエアの瑕疵）の摘出に時間を掛ければ、会社の実入りは増える。
開発プロジェクトの混乱は、プログラマーにとっては徹夜が続き地獄だが、経営者にとっては収入が増えるから嬉しい。派遣プログラマーは、派遣先から右向け左向けといいようにこき使われ、精神衛生上は最悪であるが、経営者にとって、これほど安全で安易なビジネスはない。
その一方、ソフトウエアエンジニアリングの知識に乏しいユーザーは、どのようなソフトウエアを開発したいのか、「要求仕様」が書けない。あるいは書きたがらない。取りあえず派遣プログラマーを雇って、「作っては直し」を繰り返してシステムをアドホックに仕上げていく。バグだらけなのは当然で、効率も悪いのだが、もともと効率を競う感覚に乏しいので問題にならない。かくして、ベンダー、ユーザー両者が望むので、日本にプログラマー派遣業が定着してしまった。日本のソフトウエア産業の労働力ピラミッドは、人海戦術で働く派遣要員で支えられている。
人を月額で売買する契約の下では、仕事は単価の安い方に流れる。アジアには、日本より賃金が安い国がたくさんある。日本の派遣業の経営者は「日本語という見えないバリアがある」と安心しているようだが、そんなバリアはいとも簡単に破られる。日本人を雇えば済むからだ。
日本に拠点を持つインドのあるソフトウエア開発会社の社員の六割は、英語ができる日本人プログラマーである。中国にもブラジルにも、日本語を操るソフトウエア技術者はたくさんいる。インターネットの普及で、インドの中国国境近くの雪が積もった山奥にも、パラボラアンテナが立ったオフィスがあり、インターネットを介し、世界各地から請け負ったソフトウエアを開発している。
筆者は2003年に情報処理学会誌に「ソフトウエア産業にもデフレがやってくる」と題した論文を寄稿し、仕事が海外に流れることを警告したが、業界に対策の動きはなく、筆者が予見した方向に事態は推移している。
ソフトウエア開発の仕事が奔流のように中国やインドに流れている。かつて日本が得意としてきたハードウエア製品は、最終組み立てなどを海外に外注しても、中核の技術は国内に堅持してきた。しかし、物理的なモノがなく、ほとんど人の力だけで作るソフトウエアではそうはいかない。
発注する側がプログラミングなど、ソフト開発の最下流部分を発注しているつもりでも、受ける側に力量があれば、技術やノウハウを吸収して自らの力で設計や開発ができるようになる。逆に、発注者は技術とノウハウを維持しているつもりでも、実際にソフトウエアを開発していないと、高い品質で効率よく作る能力は急速に衰え、見積もりを正当に評価する力もなくなる。筆者の経験では、開発力の空洞化のスピードは、ハードウエアよりソフトウエアの方が格段に速い。発注者は、それを知った上で、海外のソフトウエア会社に外注しているのだろうか。
冒頭に挙げた米国上院の「米国のソフトウエア産業の競合性」に関する公聴会で、ベラディーは、ソフトウエア産業を強くするためには、国全体の見地から対策が必要であること、ソフトウエアのレベルは国民の教育レベルの反映であり、それは国の産業全体に影響を及ぼすこと、を上院議員に説いた。インドの成功は、教育の充実と優れた人材の活用という正攻法によって達成された。
米国は、小学校での基礎教育からＩＴを教えている。日本はどうであろう。ソフトウエアエンジニアリングを教えている大学の数はいまだに少ないし、仮に教えてもらったとしても、学生が就職する企業側でそれを生かしていない。情報学科を卒業して大企業に入った技術者は、開発ではなく下請けへの発注業務に忙殺されている。また、ＩＴ政策を統括する省庁もない。
ここまで述べてきたように、日本のソフトウエア産業衰退の原因は、産業構造の劣化にある。これは慢性病のようなもので、回復策は体力回復が重点でなければならず、時間が掛かる。それも、国、教育界、業界、企業、そして個人のそれぞれにおいて対策が必要である。しかも国を挙げての広範な対策が必要である。
「自立」あるのみ
そこであえて個別対策には触れず、処方箋のキーワードだけ挙げておく。それは「自立」である。ソフトウエア会社も、管理者も、技術者も、それぞれの立場で甘えの構造から脱却して、自立しなければならない。ソフトウエア会社にとって、自立とは、技術の自立と経営の自立である。
プロジェクトを請け負って自らの責任で顧客が望むものを作り上げる、これが技術の自立である。これには、ソフトウエアエンジニアリング力に加えて、スケジュール、品質、コストをダイナミックに制御するプロジェクトマネジメント力を磨かねばならない。それを促進するのが改善活動である。
経営の自立は技術の自立が基礎になる。プロジェクトから利益をあげる力が付けば、その一部を改善や教育投資に回し、さらに経営効率を上げられる。
かつて筆者は、派遣技術者だけで出発したソフトウエア専門の開発会社の設立にかかわった。筆者が在籍していた企業が、同社に派遣されていた技術者を集めた子会社を作り、筆者は子会社に転籍したのである。最初の仕事は、親会社のプロジェクトにばらばらに組み込まれていた技術者をチームとしてまとめて、契約は派遣でも、自立した仕事ができるようにすることであった。システムからサブシステムを切り出し、自ら責任範囲を決め、それが果たせるようになると、親会社に執拗しつようにお願いして順次、請負契約に切り替えた。
ところが派遣指向の会社はその逆をやっている。顧客が請負を要請しても、派遣を続けて欲しいと懇願しているのを知って驚いた。経営の自立は、個人の自立を促す。自らの意思で、必要な技術を身につけようとする。それが企業風土になれば、自立した企業と言える。
政府、ユーザー、業界は、ソフトウエア企業の自立を促す必要がある。特に影響が大きいのは、大規模プロジェクトを発注する政府と大ユーザーである。彼らがソフトウエア会社に派遣を要求し続けるなら、この国のＩＴに未来はない。
彼らもソフトウエアエンジニアリングを適用して、大きな塊でなく、切り分けのよいサブシステムに分割して発注することを学ばねばならない。そうすれば、中小のソフトウエア開発会社の請負リスクは減るし、チームワークに秀でた日本の強みを生かせる。
個人の自立とは、プロフェッショナル化であり、無理な要求に「ノー」と言える人を増やすことである。ベンダー、ユーザーが対等に近い立場で要求について議論できるようになれば、ソフトウエア産業は健全になっていく。そうなる日が来ることを切に期待する。
筆者紹介
松原友夫（まつばらともお）
1956年、日立製作所に入社、亀有工場（機械）、神奈川工場（コンピューター）、ソフトウェア工場を経て、70年日立ソフトウェアエンジニアリングに転属。数多くの大規模プロジェクトを担当。91年末に同社を定年退職、コンサルタントとなる。IEEE Software の副編集長、編集委員、Soapboxコラムエディター、および産業諮問委員会委員を歴任。海外の学会や雑誌に多数の論文を発表。これらの活動を通して海外の知己が多い。ソフトウエアエンジニアリング関連の翻訳書多数。
- Re: 日本のソフトウエア産業、衰退の真因【ITpro】 <-- 同意する 健奘 2007/3/10 18:25:10
(0)
投稿コメント全ログ コメント即時配信 スレ建て依頼 削除コメント確認方法
題名には必ず「阿修羅さんへ」と記述してください。
掲示板,ＭＬを含むこのサイトすべての
一切の引用、転載、リンクを許可いたします。確認メールは不要です。
引用元リンクを表示してください。