アジアの端っこでグローバリゼーションを考えた
大学卒業してから20数年会社員生活をして、転職もして、それなりに経験をつんで、その立場からあれやこれや考えてみた。あれやこれや。
最初に就職した会社が、米国外資系ハードウェア会社の日本法人（日本DEC）、一年程、米国本社に転勤になってVAX Rdbという製品開発に参加、次が同じく米国系ソフトウェア会社の日本法人（日本オラクル）、その時、米国本社に出向になって、Oracle8というRDBMSの開発に参加、日本に戻ってきて、日本オラクルが出資するミラクル・リナックスを立ち上げて取締役CTO、最後に5ヶ月ほど独立行政法人情報処理推進機構（IPA）に出向。そして今は楽天。ミラクル・リナックスの経営は日本人がやっていて本社も日本だが、日本オラクルという外資の子会社なので、資本的には外資（？）ということになる。なので、わたしの会社員人生は、外資がほとんどだ。
長年外資の子会社に勤めて痛感したのは、重要なことはすべて本社が決める。子会社の裁量は限られている。当然と言えば当然の話である。ミラクル時代、日々のオペレーションはもちろん任されていたが、重要事項は親会社の親会社、すなわち海の向こうの本社の意向に支配されていた。
80年代、日本の経済成長が著しいころ、本社の中で日本の発言力が他の海外子会社に比べて相対的に強い時代もあった。日本オラクルの発言力が強かったのは90年代なかばの佐野力が社長をしていた時代であるが、21世紀に入ってからは、日本固有のオペレーションというのはほとんどなくなってグローバル化ということで、米国本社の縛りがきつくなっていった。
米国系外資の場合のグローバリゼーションというのは基本的にはアメリカ本社化である。それが一番効率がいいので、金太郎飴なオペレーションをして可能な限り例外は認めないという考えである。個別対応はコストがかかるので可能な限り、そのようなことはしないという方針でずんずんやる。
まあ、もちろんまったくローカライズしないというのはいくらなんでもありえないので、若干はやるとしても、それも程度問題である。
IT産業は幸か不幸かほとんどすべて米国企業にやられているので、米国的なグローバリゼーションというのが、当たり前と言うか、そーゆーものだという印象がある。わたしも、そー思っていた時期もあった。
80年代DECが日本市場に上陸し、ソフトウェア製品を売るときの最初の障壁は日本語化だった。当時ソフトウェア製品と言うのは国際化どころか満足な日本語化もされていなかったので、いちいちソフトウェアに手を入れて、漢字が通るようにしたり、マニュアルやメッセージなどをせっせと日本語に翻訳したりした。もちろんすごくコストもかかるし、市場に投入するのに何ヶ月へたをすると年単位で時間がかかったりする。しかも、ソフトウェアに手を入れるので、バグが入ったりして、品質もよろしくないという三重苦を味わっていたりした。
そもそも、ソフトウェアが国際化ということを念頭に実装されていないので、とんでもなくアドホックなやり方で日本語化したり、どう考えても拡張性がないような方法で変更するものだから、日本語版そのものの品質も悪く、もちろん保守なんてのは悪夢以外の何物でもない。
日々、時間との戦いで、ひーひーいいながら日本語化をするのであるが、若い血気盛んなエンジニアは、あまり創造性が高いとは思えない仕事なので、どこか日本語化をばかにして、そーゆーことには関わりたくないと思っていたりした。わたしも、正直、日本語化とか、いーかげんにして欲しいよなあとか思いつつ、ぶつぶつ言いながらやっていた口なのではあるが、何年もやっていると、さすがにパターンが見えてきて、ソフトウェアが元から備えるべき属性の一つとしての国際化という概念がおぼろげながら理解できてきた。
自分の中では、80年代後半の文字コードの開発、JIS X0208:1990, JIS X0212:1990など、VAX Rdbの国際化プロジェクト、日本語COBOLおよび国際化COBOLの開発などを通して、その設計と実装の理解が深まった。
ソフトウェアを後から日本語化などするのは先に記したとおり、（１）実装のコストがかかる、（２）オリジナル発売から日本語化までの時間がかかり、機会損失が発生する、（３）品質も悪い、など諸問題がある。さらには、オリジナルがバージョンアップするごとに、同じ作業を延々繰り替えさなければいけないため、80年代の終わりには、はじめから各国語化をしやすくソフトウェアを作るべきであるという考えが広まった。その概念をより一般化したものがソフトウェアの国際化として後にしられるベストプラクティスである。
80年代ぶつぶついいながら日本語化していた経験未熟なエンジニアであったわたしもさすがにこれじゃいかんだろうと思うようになって、原因は元から断たないとだめだ、誰かがやってくれるわけはない、この問題に一番詳しいのは自分なんだから、いっちょ向こうに乗り込んで根本から解決するしか、みたいな鼻息も荒く海を渡ったわけである。
米国本社も、日本語化するコストが下がって、すぐに日本語版が出荷できて、しかも品質も良いということになれば、いいことずくめなので、ちょっとコストがかかっても日本人のエンジニアを呼んで、コードを書かせてやればいいじゃないかというこになった。
一個一個のソフトウェア製品をいちいち一人で直していたらいくら時間があってもらちがあかないので、それをソフトウェアの国際化というパターンにして、素人でも国際化プログラムが書けるようになるには、もう少し時間が必要なのであるが、まあ、そんな時代である。
米国本社のエラい人を動かすには、日本のエラい人にお膳立てをしてもらって、ビジネス的なジャスティフィケーションとかあれやこれやしてもらうわけであるが、まあ、米国市場で十分儲けていたりすると、国際化なにそれ、おいしいのという感じなので、噛んで含めるように、それがめちゃくちゃおいしいのであるということで理解してもらう。これは技術的な話ではない。お金の匂いである。
ビジネス層が仮にうんと言ったとして、現場の技術者に国際化のイロハを伝えていかないといけない。現場の技術者は、あんまりお金の匂いに興味が無い。最初の一歩は日本語化というか文字コードのお話などを延々念仏のように唱える。なだめすかしお願いしたりする。
いつの日か、日本語化のような不毛なことをしなくても、漢字がふつーに出る日々のことを夢見て、毎日毎日コードと格闘し、無知なエンジニアを啓蒙する。そんなことを丹念に諦めないで行った。時にはくじけそうになったがひたすら続けた。
もちろんUnicodeなどというものはない。なければ作る。DIYの世界である。
まあ、そんなこんなで子会社の従業員の立場から見ると、本社に乗り込んであれやこれや出来たのは牧歌的であるが貴重な経験を積めた時代でもあった。そして、ソフトウェアの国際化が一般化して、Unicodeも普及して、米国で作ったソフトウェアが一切変更なしに世界中で利用でき、何の問題もなく日本語も中国語もヘブライ語もフランス語も英語もドイツ語も扱えるようになると、日本語という非関税障壁がなくなった日本市場はあっというまに、米国製ソフトウェアに席捲されるのである。
日本にあった日本語化をやる開発部隊は必要なくなり、外資系ソフトウェア会社の多くは、本社の製品を効率よく販売する機能だけが残っていくことになる。
そのような組織では当然のことながら重要事項はすべて米国本社で決定することになる。子会社の経営陣に決定権はない。
わたし自身、転職するにあたって、次の会社は外資以外にしようというのがあった。海の向こうで何かが決まるという会社はもうお腹いっぱいなので、本社が日本にあって日本で決まる会社にしようと思って、今の会社を選んだ。日本で住んでいるので、そーゆーことになる。
転職して半年もしないうちに、グローバリゼーションだなんだというお話が出てきた。世間では社内公用語の英語化というのがおもしろおかしく取り上げられているが、グローバリゼーションというのは英語化と同じではない。まあ、それはここでは触れない。
今の会社で、技術のあれやこれやを考える立場にあって、グローバリゼーションってなんなんだろうと考える。
DEC時代にソフトウェアの国際化のアーキテクチャを構築するプロジェクトがあって、それに参加したことを思い出した。そのプロジェクトはDEC本社のCorporate Consulting Engineerをリーダーとして、世界中からソフトウェア国際化の専門家を集めて行われた。イギリス、フランス、スイス、イスラエル、タイ、香港、日本、米国から参加した。そこでDECの国際化アーキテクチャーを定義した。 *1
当時はわたしも若かったのであるが、気がつくと、いつのまにかに国際化プロジェクトを率いていたリーダと同じような年齢になって、グローバル化を考える立場になった。因果応報。
本社が米国東海岸ではなく日本にあるという違いだけかもしれない。
海外子会社の若いエンジニアが何年か経って立場が変わって本社のシニアなエンジニアになった。当時のプロジェクトリーダーは何を考えどのように行動したのだろう。わたしにとっての雲の上の憧れのエンジニアだった人と同じ世代になって、わたしは彼のようになれたのであろうか。
先月、楽天テクノロジーカンファレンスで"What does globalization mean for Rakuten? 〜楽天のグローバル戦略〜"というタイトルでパネルディスカッションをした。楽天海外子会社のCTOなどを集めて社内ミーティングをしたのだが、まさに、そのようなことを議論した。*2
20年前に自分が経験したことをひっくり返して考えれば、ひょっとしたら相手の立場にたって深い理解ができるのではないだろうかと考えた。彼らの問題はわたしの問題でもあり、共通の問題を発見して議論するのがわれわれの仕事である。本社にいることのメリットというのを意識して、海外子会社のCTOたちのハブになることが自分
の課題なのだなあということを思った。
正解はもちろんない。試行錯誤で見つけていく。それだけだ。
*1:Gayn B. Winters Corporate consulting engineer Gayn Winters has 25 years' experience developing compilers, operating systems, distributed systems, and PC software and hardware. He joined Digital in 1984 and managed the DECmate, Rainbow, VAXmate, and PC integration architecture. He was appointed Technical Director for Software in 1989 and contributes to the Corporate software strategy. From 1990 to 1992, Gayn led the internationalization systems architecture effort and is on the Board of Directors for Unicode, Inc. Digital Technical Journal, Vol. 5, No. 3, 1993, http://www.hpl.hp.com/hpjournal/dtj/vol5num3/vol5num3art5.pdf
