「日本翻訳ジャーナル」のNo.262 2012年11月/12月号に私の記事が掲載されました。
同ジャーナルはこちらで無料で公開されています。ほかにも興味深い記事があるので読んでみてください。

以下に私の記事を転載します。
思い切って図式化したり造語したりしたので、同業者や当該分野に詳しい方から意見をいただけるとうれしいです。

----------
ソフトウェア・ローカリゼーションのこれから

1. はじめに
 ソフトウェアのローカリゼーション(L10N)における主要な顧客は、ソフトウェア会社である。近年、ソフトウェア会社における開発手法に変化が起きつつある。特に米国を中心とした海外において従来の「ウォーターフォール型」に代わり、「アジャイル型」が増えている[1] 。ソフトウェアの多くが米国で開発されていることを考えると、この変化がローカリゼーション・ビジネスに与える影響は大きいはずである。本稿では、2つの開発手法の違い、それらに適合したビジネス・モデル、および今後の展望について考察したい。

2. これまで
 まずソフトウェア・ローカリゼーションの歴史を簡単に振り返ってみたい。2003年に書かれたEsselink氏の論文[2] によると、1980年代からローカリゼーションの歴史は始まった。例えばマイクロソフト社は1978年に東京、1979年にヨーロッパに進出し、サン・マイクロシステムズ社は1983年にヨーロッパ、1986年にアジアに進出している。当初こういった企業では社内のローカリゼーション・チームで対応していたが、徐々に外注を増やしていく。そして1990年代になると専門業者が数多く誕生し、ローカリゼーション業界が形成されることになる。2000年初期の段階では、翻訳対象としてデスクトップ・ソフトウェア、オンライン・ヘルプ、マニュアルといったものが多かったようだ。現在ではさらに多様になっている。ローカリゼーション業界はソフトウェア業界に歩調を合わせて発展して来たと言えるだろう。
 さて、特にローカリゼーションとの関連から見て、2000年代までのソフトウェアの特徴とは何であっただろうか。まず、デスクトップPC向けが主流だった点が挙げられるだろう。またソフトウェア自体はCD-ROMなどの物理メディアで配布され、インストールするケースが多かった(もちろんダウンロードがなかったわけではない)。また製品のアップデートは、数か月や数年など、ある程度の期間をおいて行われるのが普通であった。
 こういったソフトウェアの開発に主に用いられていた手法が冒頭にも登場した「ウォーターフォール型」である。ウォーターフォール型とは、その名前が示す通り滝のように上流から下流に計画的にプロジェクトを進め、基本的には後戻りしない方法である。ソフトウェアの企画を立てたら、図1のように「要件定義」、「設計」、「開発」、「テスト」の段階を経て、最終的にリリースされる。

waterfall

図 1 ウォーターフォール型開発


 ローカリゼーション(翻訳)作業が行われるのは「設計」あるいは「開発」の段階である。ソフトウェアの機能やユーザー・インターフェイスが決まれば、外部のローカリゼーション業者(翻訳会社)に発注し、翻訳を進められる。ウォーターフォール型の開発の場合はスケジュールが比較的長く、見通しやすく、かつ「基本的には」[3] 後戻りしない。そのため、ソフトウェア会社が翻訳会社に発注し、それをさらに外部のフリーランス翻訳者に発注するという「外注ドミノ」とも言えるプロセスが成立しやすい。ソフトウェア会社にとって、翻訳会社と在宅フリーランス翻訳者という組み合わせは、ウォーターフォール型開発で活用しやすいリソースだった。ローカリゼーション業界が発展した要因の1つはここにあると思われる。
 このウォーターフォール型開発におけるローカリゼーション・ビジネスで優勢だったのは「ワード単価方式」であった。この方式では客観的な数字で見積もりを出せるため、明確で分かりやすい。また、マニュアルやヘルプといったワード数が多いドキュメントの場合、翻訳会社にとって利益が確保しやすい。半面、例えば翻訳メモリーのマッチ率によるワード単価値引きや、翻訳の「質」にかかわらず単価は同じといったデメリットもある。

3. いま
 今日では、従来のようなデスクトップ・アプリケーションがソフトウェアで圧倒的多数を占めているとは言えない。代表的なのはWebアプリケーションで、例えばGoogleのGmailやFacebookのゲームである。また、iPhoneやAndroid上で動作するモバイル・アプリケーションも増加している。デスクトップ向けではなく、まずモバイル向けを開発せよという「モバイル・ファースト」という言葉も生まれている。
 こういったソフトウェアは、CD-ROMのような物理メディアではなくインターネット経由で配布されることが特徴である。その背景には、インターネットの世界的な普及と回線の高速化がある。実際、2006年から2011年の5年間で世界のインターネット・ユーザー数、ブロードバンド契約者数(固定回線)、および携帯電話契約者数は倍増している。モバイル・ブロードバンド契約者数に至っては4年で4倍以上になっている[4]。また別の特徴として、アップデートの期間が比較的短い点が挙げられる。例えば「IMVU」というアバターを使ったチャット・サービスでは1日に20回、Flickrという写真サービスでは1日に10回アップデートしたこともあるようだ[5]。Webアプリケーションではサーバー側で更新すればよいので、こういった方法が可能となる。数か月や数年に1回という頻度でローカル側をアップデートしていたデスクトップの時代とは異なるのである。
 さてこういったソフトウェアの開発で頻繁に用いられるのが「アジャイル型」である。典型的なアジャイル型の開発では、数週間程度の短い期間で要件定義、設計、開発、テストという1サイクルを完了し、リリースする。例えばWebアプリケーションで機能を1つ追加するケースである。こういった短いサイクルを繰り返し、小さなリリースを何度もしながら、最終的な完成を目指すのである。企画を立てたあとは、図2で示すような流れとなる。

agile

図 2 アジャイル型開発


 ウォーターフォール型と同様、翻訳が行われるのは設計あるいは開発の段階である。しかし図を見て分かるように、ウォーターフォールとは異なり短期間で小さな翻訳を何度も行うという作業を余儀なくされることになる。ここに従来の「外注ドミノ」によるプロセスの難しさがある。ウォーターフォールにおいてはスケジュールを見通しやすく、基本的に後戻りしないため、ソフトウェア会社は翻訳会社に発注し、その翻訳会社はさらにフリーランス翻訳者に発注するというプロセスを採用できた。アジャイルでは時間が短いため、このプロセスを採ることは難しい。開発にアジャイル型を採用しているためか、少量の翻訳を短い納期で納品してくれと要求されるという事例はすでによく聞くし、今後も増え続けるのではないかと予想できる。従来の「外注ドミノ」というモデルは、ここに来て当然のものとは言えなくなったのである。ただし、もちろんあらゆる開発がアジャイル型になるわけではないし、開発はアジャイルだがローカリゼーションはまとめてウォーターフォール的にやるというソフトウェア会社もあるだろう。
 アジャイル型においても「ワード単価方式」は機能する。ただしアジャイルでは少量で短納期が基本であり、ウォーターフォール型であったようにマニュアルやヘルプの翻訳を大量に一括発注してもらえるケースは減るだろう。少量であれば見積や連絡といったオーバーヘッドにかかるコストが大きくなり、利益を確保することは難しくなる。また、最近増え始めているモバイル・アプリケーションの場合、画面が小さいため文字数も少ない。デスクトップ・アプリケーションと比べ、長いヘルプやマニュアルも同梱しにくい。ここでも「単価×ワード数」で料金を請求する方法は不利になってしまう。つまり、ワード単価方式は全く使えなくなったわけではないものの、開発手法やアプリケーションの変化により、かつてほどのメリットは享受できないということである。
 「これまで」と「いま」について説明してきた内容を表1にまとめる。主流のソフトウェア、主流のソフトウェア開発手法、およびローカリゼーション業界でメリットとなっていたビジネス・モデルの3点である。注意していただきたいのは、「これまで」のものがすべて変わったあるいは使えなくなったわけではない点である。相対的に特徴的であると思われる項目を挙げている。

now-then

表 1. 「これまで」と「いま」で特徴的な要素


4. これから
 ソフトウェア業界と共に発展してきたローカリゼーション業界であるが、ウォーターフォール型開発は徐々に減り、「ワード単価方式」と「外注ドミノ」によるメリットは必ずしも明白ではなくなりつつある。近年台頭しているアジャイル型開発やモバイル・アプリケーションに対応してビジネス・モデルを構築するにはどうすればよいのだろうか。その明快な答えを私は持ち合わせているわけではないし、答えが1つとは限らない。結局はローカリゼーション業界に所属する各人が考えるしかないのだろう。しかしそれで結論としてしまっては生産的ではないので、私のアイデアをいくつか例示してみたい。
 まずアジャイル型で発生する少量、短納期についてである。ここではワード数が少ないため「ワード単価方式」による利益が低下し、短納期であるためフリーランス翻訳者を使った「外注ドミノ」が難しくなるのであった。1つの案としては、ソフトウェア会社に常駐したりビデオ通話(Skypeなど)を用いたりして、逐次翻訳を提供するサービスが挙げられる。チーム内での緊密なコミュニケーションはアジャイル開発において重要だと言われているため、こういったサービスはソフトウェア会社にとっても価値はあるはずだ。
 次に台頭するモバイル・アプリケーションに関してである。上記のとおりモバイル機器は画面が小さいためワード数が少なく、ワード単価方式は厳しい。こういったケースでは別のサービスと組み合わせて包括的に請求するという方法が考えられる。例えば近年、ソフトウェアにおけるユーザー・エクスペリエンス(UX)が重要性を増している。つまり翻訳サービスにモバイルUX改善サービスを組み合わせて包括的に提供する方法である。実は私は2010年JTF翻訳祭で「翻訳者だからできる!世界に向けたアプリの開発と販売」という講演をした際、「翻訳自体は無料(フリー)で提供し、別の関連サービスで利益を上げたらどうか」と提案した。これは私が実際にモバイル・アプリケーションを開発および販売し、モバイルはローカリゼーションだけではビジネスとして厳しいという実感から生まれた提案である。上記でUX改善サービスと組み合わせる例を挙げたが、他にも語学の強みを活かして海外ユーザーサポートを代行するサービスなど、組み合わせのアイデアはいくつも考えられる。
 経営学に「近視眼的マーケティング」という言葉がある。企業が自らの事業ドメインを狭く定義してしまい、変化に対応できず機会を逃してしまうことを指す。例えばかつて米国の鉄道会社は自らを「輸送事業」ではなく「鉄道事業」と狭く定義した結果、自動車業界や航空業界との競争に敗れた[6]。同様にローカリゼーション企業、翻訳会社、あるいは個人翻訳者も、自らの事業ドメインを狭く定義することは避け、変化に柔軟に対応すべきであろう。「これまで」の延長線上に「これから」があるわけではない。


<注>
[1] 独立行政法人・情報処理推進機構の資料が参考になる。「非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査報告書」 http://sec.ipa.go.jp/reports/20120611.html (2012年7 月8日アクセス)
[2] Esselink, B. (2003), “The Evolution of Localization,” Guide to Localization 2003, 4-7, Multilingual Computing Inc.
[3] あくまで「基本的には」であるため、実際には翻訳ファイルが送られてから修正が入って苦労したという翻訳会社あるいは翻訳者も多いだろう。
[4] International Telecommunications Union (2011). "Key Global Telecom Indicators for the World Telecommunication Service Sector,” http://www.itu.int/ITU-D/ict/statistics/at_glance/KeyTelecom.html (2012年7 月8日アクセス)
[5] 渡辺千賀氏ブログ「ITアントレプレナーになりたい若者のみなさんはプログラミングを習得しましょう」 http://www.chikawatanabe.com/blog/2010/04/lean_startup.html (2012年7 月8日アクセス)
[6] ダイアモンド・オンライン「セオドア・レビット マーケティングの本質」 http://diamond.jp/articles/-/5507 (2012年7 月8日アクセス)
----------

以上です。