2007年11月19日
イノベーション・テストとソフトウェア開発のための5つの習慣
講師： 小野和俊株式会社アプレッソ 代表取締役副社長・CTO
報告： 砂田薫
日本のIT業界は本当に元気がないのか?
近年「日本のIT業界は元気がない」「ソフトウェア産業は国際競争力が低い」という声をよく耳にする．しかし，小野和俊氏は「元気がないのは伝統的な企業情報システムの分野だけではないか．例えば，まつもとゆきひろさんが開発した Rubyは今や世界的に名の知れた言語になったし，Perl のCPANには日本人のプログラマーが数多くのライブラリをコミットしている．また，はてな，ミクシィ，グリーといった会社はみんな元気がいい」と3月15日に開催されたIECPセミナーにて語った．
1976年生まれの小野氏がCTO（最高技術責任者）をつとめるアプレッソもまた元気がいい会社だ．米国サン・マイクロシステムズでの勤務経験を活かして「シリコンバレーの良さと日本の良さを併せ持ったベンチャーをつくってみたい」と考え，2000年に同社の経営に転じた．主力製品のデータ連携ミドルウェア「DataSpider」が2002年にSOFTICソフトウェア・プロダクト・オブ・ザ・イヤーを受賞するなど，パッケージソフト専門ベンダーとして順調に成長を続けてきた．また，個人的な活動として，2004年度未踏ソフトウェア創造事業で仲間と協力してミーティングツール「Galapagos」の開発にも取り組んでいる．
セミナーでは，はじめに小野氏が「ソフトウェア開発のための5つの習慣」と「イノベーション・テスト」の2つのトピックについて講演した後，フリーディスカッションが行われた．小野氏のようなITベンチャー系と，伝統的な大手IT企業の双方から参加があり，両者が率直に意見を交換させる場となった．
「5つの習慣」でソフトウェア業界の体質改善を
「アメリカのソフト開発の強みはダイナミックな発想にある．一方，日本は品質とユーザービリティにすぐれている．日本には優秀な技術者がたくさんいる．それでもソフトウェアの輸入大国になっているのは習慣の問題が大きい」と小野氏は指摘する．そして，ソフトウェア開発のために5つの習慣を身に付けようと提案した．
第一はひらめきを可視化することだ．たとえば，あるソフトウェアを開発したとき，市場の競合製品と機能や能力を比較する．比較すべきポイントを整理したうえで，強み（山）と弱み（谷）を明確にして可視化する．ここまでは一般的なSWOT分析でも行われているので，それほど新味はない．重要なのは「谷を気にせず山があるかどうかを気にする」ことだという．その山がまったく新しい製品やサービスになるかもしれないからだ．山を活かす戦略は二つある．一つは，一つの山に注力して谷となったポイントは最低限まで埋める努力をしたうえで製品化する．もう一つは，山だけをプラグイン製品として提供し他のポイントは他社製品を利用する．いずれにしても，強みを徹底的に活かせという考え方だ． 第二はユーザービリティを追求することだ．日本の得意分野であるソフトウェアの操作性をさらに伸ばしていくことを提案している．ユーザーははじめて使うソフトウェアに対して，今までの経験から理解している操作ルール（たとえばテキスト画面でマウスを右クリックしたら「切り取り」「コピー」といったメニューが出てくるはず……）に照らしあわせながら新しいツールを理解する．ペルソナ・シナリオ法（仮想的なユーザーの詳細なプロフィールを定義して誰のために開発するソフトウェアなのかを明確にする）などを用いて，対象となるユーザーがストレスを感じずに操作することができるように設計されたソフトウェアは手触りの良いソフトウェアであると言える．そういう「手触りの良さ」を重視せよと小野氏は主張する．
第三は現役プログラマーであり続けることだ．日本では，プログラマーよりSE（システムエンジニア）が上級職とみなされている．そのため，日本のソフトウェア会社では，プログラマーとして何年かの経験を積むとSEに「昇格」させるという人事がまかり通っている．また，ソフトウェア開発の上流工程を担当するほど上級であるという認識が広まっている．そのため，プログラマーは下流職種として扱われがちとなり，それが大問題だというわけだ．小野氏は「プログラマーの地位向上が不可欠」として，プログラマーのタイプを4種類に分類し（図1参照），どのタイプも必要とされ，プログラマーのキャリアパスとして「火のスーパープログラマー」や「風のフェロー」をめざす方向も考えられると提案する．
第四は，徹夜をしない，させないことだ．ソフトウェア業界では長時間労働で徹夜が当たり前という風潮がある．これは，ソフトウェア会社のマネジメントの問題であると同時に，業界体質を変えていこうという主張である．
そして，第五は，責めないで攻めることだ．これは小野氏が米国勤務時代に出会った有能な上司から学んだマネジメントのコツである．たとえ能力が不足している人であっても責めるな，その人の良い点を探せという教えだ．その理由は，責めるチームではひらめきが摘み取られやすいためだという．
図1：風林火山によるプログラマーの分類
| 風のプログラマー | 迅速な設計／実装によってチームを加速させる風のプログラマー．風のプログラマーがいない開発チームでは，他に先駆けて新製品やサービスをリリースすることが困難になる． |
| 林のプログラマー | 突発的なトラブルが発生しても冷静に対処し，チームに乱れぬペースを提供する林のプログラマー．林のプログラマーがいない開発チームはトラブル発生時に何をすべきかの正確な判断を行えず，混乱に陥りやすい． |
| 火のプログラマー | 新しい技術／方法／ツールの積極的な導入によってチームやその成果物の競争力を高める火のプログラマー．火のプログラマーがいない開発チームは同じやり方を繰り返すことはできるが，進歩する機会が少ない． |
| 山のプログラマー | 厳密なエラーチェックと堅牢なプログラミングによって成果物の安定性を高める山のプログラマー．山のプログラマーがいない開発チームは常に品質の低さからくる不安にさいなまれる． |
投稿者 noc : 17:52
日本のソフトウェア産業の変遷───企業・政府・市場
砂田薫国際大学GLOCOM主任研究員
ソフトウェア産業の分水嶺
1955年，世界初のソフトウェア会社が米国に誕生した．それから半世紀余りを経て，ソフトウェア市場は激変期を迎えた．パッケージソフトが提供してきた多くの情報処理機能がウェブへ移行し，オープンソースソフトウェア（OSS）が普及期を迎え，新たにSaaS（software as a service：サービスとしてのソフトウェア）が台頭する兆しをみせている．もはや「パッケージか受託開発か」「オープンかクローズドか」「有料が無料か」といった議論を超えて，ソフトウェア産業の存続自体が大きく揺さぶられている．
はたして，今後もハイテク産業の一分野としてソフトウェア産業の発展は続くのか．それとも，伝統的なソフトウェア産業が衰退し新たな産業が生まれる創造的破壊が起こるのか．あるいは，ソフトウェア産業そのものが消滅し，組み込み型ソフトウェアのように，さまざまな業界で業務プロセスの一つと位置づけられるようになるのか．
ティム・オライリーは，ソフトウェアの長期的傾向として，①コモディティ化，②ネットワークが可能にするコラボレーション，③SaaS，の3点をあげたうえで，ソフトウェアは「プロダクト（製品）」から「プロセス」になったと指摘した．
たしかにプログラムやコモディティ化したコンポーネントといったソフトウェア製品は存在する．しかし，コモディティ化しない動的なプログラム言語が光る分野もある．とくに，アマゾンやグーグルのようなユーザーからダイナミックに反応が返ってくるサイトのソフトウェアは，プロダクトではなく「プロセス」である．マイクロソフトのWordは10年後も動くだろうが，インターネット時代においてはアマゾンやイーベイのサイトで常に最新版が入手できるような環境が整っていなくては，アプリケーションはその機能を発揮できない．もともとエンタープライズソフトのビジネスではこのような特徴を備えていたが，これが新しいパラダイムで支配的なビジネスになってきたのである★1．
一般的に，ソフトウェア産業の歴史はアンバンドリング・モジュール化・オープン化・コモディティ化の進展としてこれまで理解されてきた．しかし，ウェブサイトやSaaSの重要性が高まるにつれて，産業進化の方向に変化が起こりつつある．オライリーの予測はパッケージソフトよりもエンタープライズ向けのカスタムソフトを，モジュール化よりも統合化を得意としてきた日本のソフトウェア産業にとって，朗報なのだろうか．
本稿では，ソフトウェア産業が歴史的な分水嶺にさしかかっていると認識を出発点として，日米の産業史を「企業と政府の関係」「市場変化」という二つの視点から振り返ってみたい．そして，日本のソフトウェア産業が新たな発展をめざす戦略について考察する．
米国ソフトウェア産業と国防総省
ソフトウェア会社を「コンピュータのプログラム開発を手がける独立した営利企業」と定義するならば，世界で最初に誕生したソフトウェア会社は，エルマー・クビーとジョン・シェルドンという二人のIBM出身者が1955年に米国で設立したコンピュータ・ユーセージ社（CUC）である．同社は1960年に株式を公開し，1967年には従業員が700人を超える企業に成長したが，1970年代の終わりに財政難に直面し，1986年に倒産した．1956年には，ランド・コーポレーションから独立した非営利のシステム・ディベロップメント・コーポレーション（SDC）とCEIR社が発足した．1959年にはユニバック出身の7人のプログラマーがアプライド・データ・リサーチ社（ADR）を設立した．また航空産業でコンピュータ経験をもつ技術者の二人がコンピュータ・サイエンシズ社（CSC）を同年に設立し，10年後には業界トップの座についた．
1960年代末，米国では創業資金がかからないソフトウェアのベンチャー企業が続々と誕生し，2000社近くまで急増していた．しかし，年間数十億ドル（推定）のソフトウェア投資総額のうち，市場取引の対象となったのは一部にすぎない．市場プレーヤーのトップはSDCに代表される非営利企業や大学であり，二番目がハードウェアとの一括販売を行っていたコンピュータメーカーだった．独立ソフトウェア会社は市場取引の主役ではなかった．
転機となったのは1969年である．この年，IBMが司法省との独禁法をめぐる裁判に負けて，ハードウェアとソフトウェアのアンバンドリングを発表した．これによってソフトウェアの有償化が進み，独立した産業として急成長をはじめる．そこで大きな役割を果たしたのが国防総省である．当時の米国では国防総省をはじめとする政府機関がソフトウェア需要の85％を占め，半導体など他のデュアルユース・テクノロジー（軍産両用の汎用技術）と比べても，ソフトウェアは軍需比率が格段に高いという特徴をもっていた．国防総省は，マサチューセッツ工科大学をはじめ大学とも連携して先進的なソフトウェアを開発した．いわば，産学官の強力なトライアングルで先端ソフトウェア技術の開発と独立ソフトウェア産業の育成の両方に力を注いだのである．主な成果には，半自動地上防衛システム（SAGE），各種タイムシェアリングシステム，COBOL言語，BASIC言語などがある．
米国政府は，1960年にCOBOLが開発されると，翌年には政府調達の条件にCOBOLを含め，コンピュータ企業に製品化を急がせた．COBOLは事務処理用の標準言語として全世界に普及した．米国政府は技術の開発だけでなく普及および利用にも大きな役割を担ったのである．米国のソフトウェア産業にとって，国防総省をはじめとする政府機関は今もなお大口需要者であると同時に，デファクトスタンダードの決定や新しい応用分野の開拓にも影響力をもつ存在であり続けている．
日本製ソフトウェアと電電公社
日本では米国より11年遅れて最初の独立ソフトウェア会社が誕生した．大久保茂が1966年8月に設立したコンピュータ・アプリケーションズ ★2である．2カ月後の10月には富士通・日立製作所・NEC・日本興業銀行の共同出資による国策ソフトウェア会社の日本ソフトウェアが設立された．1969年になると，日本EDP，日本コンピュータ・システムなどの独立系に加え，コンピュータメーカー系のソフトウェア会社も次々と設立された．
当時，独立系ソフトウェア会社上位8社の売上高総額に占める政府関連は6割弱だった．しかも，このうちの大半が1966年から1971年にかけて実施された最初の大型プロジェクト「高性能電子計算機開発」の仕事で，これを除く純粋な政府需要の比率は25％程度しかなかった．日米の政府需要には大きな開きがある．
日本で大口需要者の役割を担ったのは1968年に「DIPS」コンピュータプロジェクトを開始した日本電信電話公社（以下，電電公社）だった．プログラム発注先はソフトウェア会社ではなく，DIPSの研究開発を共同で進めたNEC・富士通・日立製作所が中心となっていた．電電公社のプロジェクトは国産のハードだけでなくソフトの技術力向上にも貢献した．カスタムメイドのため技術内容は公表されていないが，「データベースの原型となるファイル管理技術などはすでに米国と同水準だった．日米の格差をほとんど感じなかった」と富士通でソフトウェア事業部門の創設に関わった中村洋四郎氏（元同社システム本部担当取締役）は証言している．
コンピュータメーカーがソフトウェア開発力を高める一方で，国策ソフトウェア会社は失敗に終わった．政府は日本ソフトウェアに6年間で30億円の補助金を支給し，助成終了後はソフトウェアの外販で独立採算の会社運営を期待していた．しかし，労使紛争が深刻化し，大型プロジェクト終了後の資金難も追い討ちをかけて，1972年12月に解散するという結末をたどった．日本の初期の政策は，米国と違って，独立したソフトウェア産業の育成よりもコンピュータメーカーの技術力向上に焦点が当てられていた．
通商産業省のソフトウェア産業政策
通商産業省で独立ソフトウェア産業が政策対象となったのは1970年である．7月に同省の電子工業課は，コンピュータ産業担当の「電子政策課」とソフトウェア産業担当の「情報処理振興課」に分離された．また，IPA法★3が公布され，10月にはIPAが発足した．とはいえ，当時はIBMへのキャッチアップが最重要課題だった．1971年の「特定電子工業および特定機械工業振興臨時措置法（機電法）」の制定を受けて，6社を，富士通と日立製作所，NECと東芝，沖電気工業と三菱電機の3グループ体制に分け，5年間で約650億円の資金援助を行って国産機開発を急がせた．1974年に国産機が完成すると，外国コンピュータ企業の資本・貿易自由化を急速に進め，1976年にはソフトウェア関連資本を含め完全自由化へと踏み出した．
1977年11月，IBMに8年遅れて国産6社もハードウェアとソフトウェアのアンバンドリングを発表した．1978年には「機械情報産業高度化促進臨時措置法（機情法）」が制定され，6月には汎用ソフトウェアの有償化と流通促進を目的に「ソフトウェア流通促進センター」が発足している．しかし，日本ではなかなか汎用ソフトの流通が進まなかった．メインフレーム用パッケージソフトでは，大半が海外製品の輸入で，国産製品で売れたのは富士写真フィルムが社内利用を目的に開発し，後にソフトウェア・エージー★4が商品化した自動運用管理ソフト「A-AUTO」くらいだった．日本のソフトウェア産業はメーカーの下請け的なプログラム開発が多いのが特徴で，パッケージの輸入販売，ましてや自社開発・製品化は非常にわずかだった．
バブル崩壊後の1992年，日本のソフトウェア産業の危機感はいっきに高まった．通商産業省の委員会★5は同年12月に「緊急提言：ソフトウェア新時代」を発表し，ハードウェア重視の従来の方針を早急に改め，情報サービス産業の構造転換を促すべきだと強調した．技術者の人月単位の労働でソフトウェアを取引する状態から脱するために，パッケージソフトやシステムインテグレーション（SI）サービスの育成を目的とした政策が強化された（図1参照）．しかし，それから15年を経て，産業の構造転換は進まないまま現在に至っている．
図1：日本のソフトウェア産業政策の変遷
|
市場変化と日本の戦略
ソフトウェア市場では過去半世紀にわたってモジュール化が一貫して進展してきた．カーリス・ボールドウィンは，IBMが1964年に発表したシステム/360をモジュール設計された最初のコンピュータであると指摘している．それは，図2で示すように，初めてオペレーティングシステム（OS）の概念を採用するなど「メインフレーム中心の時代」のコンピュータの要素技術を定義したからである．ただ，モジュール間インタフェースはまだ企業内の各部門間で共有されるにとどまっていた．ところが，「パソコンとインターネットの時代」になると，プロセッサはインテル，OSはマイクロソフト，データベース管理システムはオラクルなど，モジュールごとの専門企業が台頭し，IT産業自体がモジュール構造へと変化していった★6．
図2：IT市場におけるモジュール化の進展
|
この変化に乗れなかったのは日本企業だけではない．「メインフレーム中心の時代」はIBMやDECなど，米国では東海岸が技術とITビジネスの発信地だった．しかし，「パソコンとインターネットの時代」になってそのリーダーシップは西海岸とくにシリコンバレーへ移った．IBMは1990年代初頭に大規模なリストラを余儀なくされ，DECはコンパックに買収された．IBMキャッチアップ路線でメインフレームへの依存度を高めた日本のコンピュータメーカーは，1990年代に軒並み業績を悪化させた．
モジュールごとに専門企業が存在し，企業間でインタフェースが共有される設計のコンピュータシステムは，特定メーカーがユーザーを囲い込めないので「オープンシステム」と呼ばれた．IBMは市場がオープンシステムに変化したことでリーダーの座を奪われた．ところが，IBMはアウトソーシングサービスで復活を遂げる．その過程でLinuxへの10億ドルの投資や自社ソフトウェア特許500件のオープンソース化など，ライバルに先駆けてオープンソースに力を入れている点が注目される．企業内から企業間連携へ，さらには技術者個人を中心とするオープンソースコミュニティへと，イノベーションの震源が移行しつつあることを重視したのだろう．
それに対し日本企業は，昔から優れたソフトウェア技術が存在し，現在でもまつもとゆきひろ氏が開発した「Ruby」のように世界的なプログラミング言語まで登場しているにもかかわらず，新しいビジネスを創出できず，技術者を消耗させるような状態が続いている．特許を保有する既存技術については，保守コストの節約と技術継承の両面からもっとオープンソースにすることが検討されていいだろう．オープンソースコミュニティからのフィードバックは技術開発における貴重な資源となりつつある．
同時に，オライリーの予測をあらためて考えてみる必要がある．エンタープライズ向けカスタムメイドという日本が得意とする技術を新しいビジネスへと発展させていく道筋を考えることも重要である．日本の製造業はプロダクト・イノベーション（新しい概念の製品の創造）よりもプロセス・イノベーション（工程革新）に強いという特徴を持っている．ソフトウェアのサービス化を推進し，プログラムをプロダクトからプロセスへ変化させる動きを先導していくこと.それが日本のソフトウェア産業に有利な戦略となるだろう．
参考文献
★1── O'Reilly, Tim [2004] The Open Source Paradigm Shift（http://tim.oreilly.com/lpt/
a/4868）から要約・引用．
★2── 現シーエーシー．
★3── 情報処理振興事業協会等に関する法律．情促法ともいう．
★4── 現ビーコンIT．
★5── 産業構造審議会情報産業部会政策小委員会．委員長は今井賢一氏．
★6── モジュール化については，青木昌彦・安藤晴彦［2002］『モジュール化：新しい産業アーキテクチャの本質』（東洋経済新報社）および，カーリス・ボールドウィン＆キム・クラーク著・安藤晴彦訳［2004］『デザイン・ルール：モジュール化パワー』東洋経済新報社，柴田友厚・玄場公規・児玉文雄［2002］『製品アーキテクチャの進化論』白桃書房，を参照した．
投稿者 noc : 17:50
企業の人材育成───日本企業の人事制度で人材は育つのか?
城繁幸 人事コンサルティング「Joe's Labo」代表
聞き手：庄司昌彦┼砂田薫┼森田沙保里
優秀な人材の行方
─── ソフトウェア産業界の優秀な人材の流動という観点から，人事制度との関係をお伺いしたいと思います．東大の理工系大学院を卒業した学生の就職先データをみると，最近では日本の大手情報サービス系の企業以外に，Googleや金融，コンサルが挙がっています．
「若い頃に働いた分は45歳以上の報酬で受け取るが，その保障はない」というのが年功序列の本質です．今の日本のメーカーでは35歳を過ぎた時にどうなるかが見えない．実際，2000年以降，エンジニアは多くの企業でリストラされています．成果主義の定義はこの逆で，タイムリーに報酬が上がる．外資金融やコンサルは，リスクはあるがリターンも大きく，キャリアパスもある程度見えています．40歳過ぎで会社に残る人はほとんどいませんが，30歳ぐらいから経営に近い仕事に携わっているので，ベンチャーなどの経営陣としてキャリアアップする人が多いんです．将来を意識している人は，理系であっても金融やコンサルに行く人が増えている．僕としてはベンチャーがもっと増えて欲しいですね．
─── 日本の優秀な人材は，大手企業の中で実力を発揮することができているのでしょうか．
これは意見がわかれるところで，学士と修士以上で決定的に違いがあるという人もいれば，修士以上はいらないという人もいる．確かに有効に活用できてないなという気はします．修士以上を評価する人たちは，本人の資質を評価しているのだと思います．実際に社員に聞くと，一部の研究職を除いて自分の専攻はほとんど役に立っていないと言います．研究職の場合は学会のコネを通じて入社する人が多いから活かされますが，それ以外の部門では，専門が活きることはほとんどないのではないかと思います．
─── なぜ優秀な人材の能力が企業内で活かされないのでしょうか．
二つ理由があります．まず，日本社会の全体としてあまりにも産学連携がなかった．アメリカを理想とするならば，日本の大学はあさってのビジネスの方向を向いてきてしまった．完全に企業のニーズと乖離してしまっているんです．大学自身も，組織として変われないんですよね．企業は推薦をやめて自由応募にしたいのですが，人材を確保できるかわからない．逆に，大学は貴重な枠を守りたい．それで学生を統制している面もあるわけです．例えば，ある自動車メーカーから枠を2名もらったのに1名しか行かないと翌年から枠を減らされる可能性が極めて高い．だから学校は学生に「お前何やりたい？」と聞いて，「ソフトウェアの開発」と答えると「自動車にもソフトはあるから」と無理やり推薦するわけです．負のジレンマですね．
もう一つは，採用が現状に追いついていないということがあります．これは，企業も大学も両方悪いのですが，日本の理系の就職はやはり学校推薦なんです．学校推薦は，学校の偏差値，どういうエンジニアを何人出しているかという過去の実績，また役員がいるかどうかということで決まるので現状の変化に対応できていないんです．特に90年以降は非常に変化が激しい．97，8年は物性系に人気があって半導体やシリコンをつくる学部にエリートが進学しましたが，半導体が壊滅してソフトの需要が高まると物性の人気は低下し，情報学科やシミュレーションを作るところが人気になった．この間たった5年です．つまり過去の実績やネームバリューは全く意味がなくなっているんです．
─── 企業からの人材流出についてはいかがでしょうか．年功序列が残っていて優秀な人材が会社に居づらいということがあると思いますが．
人材の流出はおこっています．成果主義がないからやめてしまう．ただ，直感ですが，エンジニアは事務系・フィールド系に比べると離職率は低い．これは彼らが満足するような転職先が，少なくとも日本にはないからだと思います．起業もみんなができるものではないですし．電機で言えば外資の転職先もIBMのほかは，たまにSunに行くぐらいですね．エンジニアが行く外資はITコンサル系で，コテコテの開発エンジニアが行く転職先はあまりないですね．畑違いのデジタル家電の会社などにいけば別ですが．日本企業は五十歩百歩ですからね．
企業の人事制度のあり方
─── 大手ソフトウェア産業を含む日本企業の多くは，成果主義や目標管理制度の導入に失敗してきました．問題はどこにあったのでしょうか．
理由は二点あります．一つはシステム上の問題．これは今も変わらない問題ですが，目標管理自体が日本企業にあわなかった．海外の企業は職務給制度なので，入社した時点で「この仕事に対して年俸が何百万」と仕事に給料が結びついていて，個人の業務範囲が明確です．一方，日本は職能給制度といって，大部屋で働くシステムなので業務の切り分けが不可能です．そこが決定的に違う．日本企業というハードウェアにアメリカ産のよくわからないOSをインストールしたら動かなかったということだと思います．
二つ目は，従来の組織体制の見直しを全くしなかったということです．最終的に，中高年社員の賃下げや降格，あるいは解雇を抜本的にやらない限り成果主義は機能しない．でも現状では，法令上の制限があって労働条件の変更や解雇は難しい．結局，上層のポストが空かないわけです．日本では定期昇給がないのに初任給が20年前と同じ水準で始まっていますが，本来は初任給を50万から始めるべきです．もちろん，ダメな人はそこから下がる．合わない人は転職すればいい．
─── 部門による影響の違いなどはどうでしょうか．たとえばチームワークや開発プロセスなど，開発部門や技術系エンジニアへの影響はどうだったのでしょうか．
最初は，営業と開発部門で数値目標がマッチすればいいという認識があったんですが，やってみて成果主義が一番合わなかったのは営業，次が開発部門だった．なぜなら，「原価を2000円下げる」という目標をたてられるのはマネージャーであって，それを20人のエンジニアで割って1人100円ずつを削減することは現実的ではないからです．末端の数値化による目標管理は，そもそも日本企業に合わないんです．現状の成果主義によってモチベーションが低下することはあっても，プロジェクトの遅延やチームワークの崩壊につながることは基本的にないと思います．
─── 企業は成果主義にどう対処すべきなのでしょうか．
成果主義は避けられないものですから問題は企業の運用です．まず年齢給は完全に廃止し，職務給に一本化する必要がある．ハード系の製造業では年齢給を残す余地はありますが，ITに関しては完全に職務給にするべきです．目標管理はやらなくてもいい．欧米のメーカーのように，数値に頼らないアナログ式の評価をするべきです．日本の目標管理はA3の用紙にびっしり書きますが，欧米の企業はA4用紙1枚に今期の方向性やミッションが箇条書きになっているだけで数字もない．そして，年度末に来期の年俸について上司と交渉する．これをやってほしい．日本では，現場のマネージャーが絶対的な評価権をもっていないので交渉することができないし，人事部が評価枠を決めてしまう．
優秀な人材への処遇
─── 技術者をプロフェッショナルとして処遇する制度のあり方についてはどんなご意見をお持ちですか．
本質的に，世代間の格差と，エンジニアとしてのキャリアパスがないことが問題だと思っています．キャリアパスを複線にしなければいけない．序列と給与体系を切り離して年齢給を廃止しないといけない．20代でも40代でも活躍した人についてはそれに応じた金額を払う．プロ野球選手に年齢給という制度がないのと同じです．まあプロ野球も本質ではかなり年功序列的なのでサッカーのほうが例としていいかもしれない（笑）．日本代表の監督だったトルシェも選手としては母国の2部，3部リーグで終わっていて全く実績はないけど，ヨーロッパは職務給の国だから監督としてのキャリアパスが明確にわかれていて彼はそこで評価されているんですよ．日本はそういうものが社会としてない．いい選手だったらコーチも監督もなんでもできるだろうと考えてしまう．
投稿者 noc : 17:46
世界に認められた日本の天才───スクリプト言語Rubyの開発者
まつもとゆきひろ
聞き手：砂田薫 構成：森田沙保里
子供時代から学生生活まで
─── 初めてプログラミングをされた頃から学生時代までのお話を聞かせてください．最初はお父さんのコンピュータをおもちゃで使っていらしたとか．
プログラミングをする以前からマイコンには触っていたのですが，プログラムとして認識してはいなかったんです．「数字の羅列があって，それを打つと動くよ」と言われた通りにやってみたら動いて，おもちゃというかパズルみたいなものでした．創造性も何もなく，紙に書かれたものをただ打っただけ．小学校6年生の頃です．ポケットコンピュータに触わり，コンピュータを制御するんだという気持ちでプログラミングしたのは中学3年生です．中学から高校にかけては，ポケットコンピュータでパズルのプログラムなどを作っていました．サンプルプログラムをいじったり直したりしていました．大学では，言語学や心理学も面白そうだと思って取ってみたんですが，いまいち心惹かれなくて，計算機言語の方がよかったですね．専門課程になって入った研究室はコンパイラを作らせたら日本一というところでしたが，僕はコンパイラにはあまり関心がなく，言語をどうデザインするかをやりたかったんです．大学時代には途中でお休みして2年間宣教師をしていましたから，ソフトウェア一色というほどでもなかったです．
プログラマーの仕事───働く場所と時間
─── 大学卒業後はソフトウェア会社に就職されましたが，仕事としてプログラミングをやりたいという気持ちは強かったのですか．
それ以外に能がないので，ソフトウェアを書いて生きていこうかなと思っていました．大学院に行くかとも言われたんですが，数学がだめですし，試験もしんどいし，親のすねをこれ以上かじるのもなんだろうと思ったので就職しました．
─── 会社でのお仕事は？
受託開発の会社でしたが，配属されたのは社内OAシステムを作る部署でした．今で言うデスクトップソフトウェアです．画面を置いて，画面の上にアイコンを置いたりとか，メールに添付ファイルをつけたりという，今だと当たり前の機能を当時は開発していました．それ以外では開発ソフトウェアを部品化して，データベースとして登録していく，というようなこともしていました．バブル経済がまだ終わってなくて，わりと好き勝手していました．浜松に研究所が出来て，僕はそもそも浜松で就職できるからということでその会社に入ったんです．バブルが崩壊して浜松の会社が結構傾いてきたので転職先を探しました．東京じゃないところ，と言ったら「名古屋はどうでしょう」と．それで名古屋に行きました．会社自体はトヨタの子会社で，トヨタの部品系CADを開発していましたが，僕は造船関係の部品管理をしていました．造船業界は高齢化し，技術伝承について結構危機感を持っていました．ですから部品の管理とかを含めて，オントロジーと呼んでいたんですが，それを電子化することに対して非常に関心が高かった．その一部として，船の部品かくあるべし，と造船側が決めて，僕のチームはデータベース上に表現するにはどうしたらいいか，画面上で設計するにはどうしたらいいかを考えて実装していました．この仕事は面白かったですね．
─── そこを辞められて今度は松江にいらしたわけですね．ところで，働く時間についてはどう考えていますか．
僕はこの業界で一番悪いのは残業だと思っていて，効率の悪い人がたくさん稼ぐ構造はまずいと思ったので，ネットワーク応用通信研究所（NaCl）を設立するときのミーティングで残業をやめようと主張して通ったんです．禁煙にしようという意見も通りました．だから入社したという感じです．この会社では，研究員は裁量労働制になっているんです．ホワイトカラー・エグゼンプション制度がないのでみなし残業をつけないといけないですが，後はどう時間を使ってもいい．個人には家族が病気になったとかいろいろな事情がありますが，それを会社が管理する必要はないわけです．仕事の締め切りさえ守られれば時間をどう使おうが自由であるはずなんですね．そういうふうに会社を運営してきて，今のところ大きなトラブルは起きていません．だから，どこの会社でもやろうと思えば出来ると思います．ミーティングや打ち合わせがあるなら集まります．締め切りでデスマーチ状態で働いている人や会社に住んでいるような人もたまにいます．労働基準監督署の立場からすると，あまりうまくないこともたまに起こるのですが，われわれはあまりこだわっていないので大きな問題は起きていません．
─── 働く場所は会社を選ぶ際の重要な要素ですか．
そうだと思います．日本では受託開発系の会社だと，完全裁量労働制というのはあまりないです．松江は真ん中に大きな川があるのですが，橋が5本くらいしかないので時間によってはかなり道路が渋滞するんです．ですから，出勤時間を決めちゃうと非効率でばかばかしい．ただ，松江はどちらかというと保守的な土地で勤務時間が固定の会社のほうが多いかもしれません．
Rubyの開発と発展
─── Rubyの話を伺いましょう．以前，講演で「新しいものをつくるというよりも，自分にとって快適なものをつくりたかった」と強調されていたのが印象に残っています．
Rubyの開発は1993 年で，浜松にいたときです．Rubyはビジネスとして開発したのではないのでマーケティングする必要がありませんでした．Rubyが広まっても広まらなくても，僕の生活は変わらない．注目を浴びる必要がないので，新しいものだと言う必要もなかったのです．結果的に，他の人がRubyの新しいところを発見してくれて，これはいいと口コミでマーケティングしてもらいました．もう一つは僕自身が環境改善オタクということがあります．コンピュータの設定をいろいろ変更すると使いやすくなるので，コンピュータ好きの人は割合よく設定を変えたりするんですね．これを僕はプログラマー環境問題とか，環境改善オタクと言っているんです．この場合の環境はソフトウェアの設定という意味ですね．そういう人を喜ばせるために，設定の幅が異様に広いソフトウェアが世の中にはあるんですね．僕はそういうソフトウェアが大好きで，延々とこうしたらもっと使いやすい，このソフトとこのソフトを組み合わせるともっと楽になるとやるんです．Rubyはその延長線上です．自分がプログラムする環境をいかに改善するか．自分にとって快い環境とはなんぞや，と日々追求しているわけです．僕以外の人から見たら，Rubyという素晴らしいものが世の中に降ってきたということなんですが，僕にとってみれば，環境の一部を日々改善しているだけなのです．開発，発明というのは元々そうなんですね．周りから見ると，それが結果的に新しいものとなるわけです．
─── オープンソースにしようと思った理由は？
逆に，しないことを思いつかなかったんですね．僕は元々オープンソースソフトウェア，当時はそういう言葉がまだなかったんでフリーソフトウェアという発想をしていましたが，emacsというエディタの上でソフトウェアを書いて，GCCという有名なフリーソフトコンパイラの上でコンパイルをして，Rogueというゲームで遊んで，Linuxもわりと早い時期，94年くらいから使って，オープンソースの中で生きてきました．ですから，業務で作ったものでなければ，ある程度使い物になるようにしてフリーソフトにすることが自然でした．
─── Rubyは公共財のようになってきました．
このペースだと少なくともあと10年は遊んでいられる，ああでもないこうでもないと言えるネタはあるんじゃないかなと思ってます．誰かすごい人が来て，僕の考えるものをどんどん実装していってくれて，数年で使い切ってしまうかもしれませんが．ただ，言語の寿命は長いので，僕が今死んだとしても，Ruby1.8安定版として出ているものはそれなりに生きていくんじゃないか，放っておいても消えないくらいには出来たんじゃないかなと思います．
─── 世界のRubyになった時は嬉しいものでしょうね．
イチローが大リーグで頑張っているな，くらいの距離感がありますね．あまり僕がどうこうという感じではないです．多くの人がRubyを使っているんだけれど，実際に使われているのはRubyの上に書かれたプログラムなんで，僕が書いているわけではありませんから．「Ruby使っていますよ」と言われても，それはRuby onRailsを使っていて，僕のはその部品のひとつだよね，という話で．嬉しいといえば嬉しいですけど．
日本のソフトウェア産業の課題
─── 日本のソフトウェア産業は輸入超過が続き，国際競争力が低いという議論が盛んに行われていますが，Rubyはブレイクスルーになったように思います．
でもまあ，売り上げがないので経済にはあまり貢献していません．それにRubyには日本人以外の開発者もたくさん協力してくれています．Rubyがここまで話題になった理由はRuby on Railsですが，それを作ったのはデンマーク人で，今アメリカに住んでいます．Rubyで使えるライブラリのかなりの部分は日本人が作っていますが．
─── 日本のソフトウェアをどう強くしていくかという課題が国の重要な政策課題となっているわけですが，グローバルなオープンソースコミュニティにいるまつもとさんの目からご覧になると，議論が若干ずれている感じがしますか．
そういう政策を議論されておられる方にとって，私はいないのも同然ではないでしょうか（笑）．ただ，よくわからない部分もあります．たとえば会社ではRubyを使って仕事をしていて，Rubyでソフトウェアを開発するお客さんに納めてお金をもらっていますが，そのお客さんは日本人だけなんですね．その辺で国を越えられない部分が確かにあります．国は関係ないといっても，実はある．それは確かです．特に日本では国を越えるソフトウェアビジネスはほとんどないのが現実です．アメリカやヨーロッパでは国を越えるのはわりと普通なので，その辺の違いはあると思います．
─── すでに世界で使われているRubyが日本のソフトウェア産業にどういう影響を今後与えられると思いますか．
オープンソースやソフトウェアのサービス化によって伝統的なソフトウェアビジネスは変わってくるでしょう．たとえばパッケージビジネスをしているところは厳しいところが出てくると思う．マイクロソフトやオラクルをはじめとして多くのパッケージビジネスはオープンソースとの競争がますます増えてきます．イノベーションを維持していかないと生き残れないし，かといってパッケージ市場への新規参入はあまり現実的ではありません．その辺についてはかなりいろんな圧力がかかってきているんじゃないかなという気がします．
一方，受託開発系の会社は仕入先が変わるだけなので，産業構造がまったく変わらないのではないかという意見も出ています．統計によれば日本のソフトウェア産業の7割か8割は受託開発系だそうなので，あまり変わらないかもしれないなとも思いますし，一方で，変わらなくていいのかという気もします．逆に，オープンソースをうまく利用しているIT企業もあります．IBMはオープンソースに投資する事でかなり業績を回復させましたし，後はサンですかね．サンとIBMはサービスの販売に力を入れているので，そこがマイクロソフトとの違いです．日本の受託開発系のソフトウェア会社も，サービス系企業がもっと出てくれば変わる可能性もあります．Web 2.0じゃないですが，そういう会社がオープンソースを使ってすばやくサービスを提供するという話になってくると，構造変化が起きるかもしれません．でもそういう会社はベンチャーで小規模なので，ほんとうに産業構造を変化させる力があるかどうかは分かりません．受託の中での生き方がちょっと変わってくるということはあると思います．構図そのものは変わらずに，もしかしたら温存する方向に働くかもしれません．実際うちの会社もオープンソースの代表企業みたいな格好をしていて，コンサルや教育といったこともやっていますが，産業構造的には受託会社です．
自分の仕事の将来
─── 最後に，今後5年，10年，どんな仕事をしていたいですか．
今と同じようにずっとやっていたいなと思っています．今Rubyを開発していますし，経済的にもあまり困っていないので，わりと幸せな生活をしていますから．この業界では大変な思いをして仕事をされていらっしゃる方も多いので，僕は苦労も少なく，平安な生活をしていると思います．通勤の苦労もないですし．
─── やりたいことが仕事になり，自分の望ましい方向へ来られた感じですか．
後は生活の安定ですね．僕は金勘定もあんまり好きじゃないし，ビジネスを新しく作るとかもあまり関心がない．そういうのは他の人にやってもらって，どちらかというとソフトウェアに向き合っていたいと望んでいます．技術的な裏方で行きたいと思ってるんですよ．ちょうど今の会社NaClではそういうポジションで仕事ができます．NaClにはいろんな人がいて，自分で開発もする，事業もする，金儲けをするという人もいます．そういう人はすごいなあ，うらやましいなあ，と思うんですけど，僕はそうじゃないんで，NaClさえ変わらない限り，僕はここでやっていきたいなあと思っています．
─── 今日はどうもありがとうございました．
2007年2月20日収録
- 1993年 2月 Rubyの開発を始める
- 1995年12月 Ruby Ver.0.95をfj.sourcesに投稿
- 1996年12月 Ruby Ver.1.0をリリース
- 1997年 オンラインソフトウェア大賞入賞
- 1998年11月 「Perl Conference Japan」でRubyについて講演
- 1999年10月 『オブジェクト指向スクリプト言語Ruby』が出版
- 2000年10月 英語で書かれた初の解説書『Programming Ruby: The Pragmatic Programmer's Guide』（Addison-Wesley刊）が出版
- 2000年10月 未踏ソフトウェア創造事業で「オブジェクト指向スクリプト言語Ruby次期バージョンの開発」が採択される
- 2000年11月 初めての専門カンファレンス「Perl/Ruby Conference」が京都で開催
- 2001年10月 海外では初めての専門カンファレンス「Ruby Conference 2001」が米国フロリダで開催
- 2007年 Language of the Year 2006受賞
Ruby on Rails，Enterprise Ruby，JRubyが話題に
投稿者 noc : 17:36