rnishino

IT翻訳者Blog

翻訳、英語、ローカリゼーション、インターナショナリゼーションなどについて書いています。

4 6月

Google Apps Marketplace はこれからか

Google Apps Marketplace」が 3 月 9 日に公開されてから約 3 か月が経過した。公開当初は日本でもニュースになったが、その後は大きな話題にはなっていないようである。

Google Apps Marketplace とは、簡単に言えば「Web アプリケーション提供のインフラ」である。SaaS 型アプリケーション スイートである Google Apps と連携させ、Apps のユーザーがシームレスにサードパーティの Web アプリケーションを使えるようにする仕組みだ。
Web アプリの提供会社は、Google Apps のユーザー向けにアプリを販売できるのである。


◆ 特徴

・Google Apps に統合できる
 → ユーザーは Apps の画面からシームレスにサードパーティ アプリを起動できる

・Google Apps のユーザー数は 2,500 万以上、採用企業は 200 万以上
 → ユーザーベースが大きいため、収益化の可能性が高まる

・自社サーバーを使用可能
 → Google App Engine である必要はない。もちろん使ってもよい

・全く新規で開発する必要がない
 → すでにある Web アプリと連携できる

・利用料はそれほど高くない
 → Marketplace への登録費用は初回の 100 ドル。Apps と統合する場合、売上の 20% を Google に支払う

大きな特徴として、すでに SaaS でビジネス向け Web アプリを提供する企業は、一から開発しなおす必要がない点が挙げられる。連携部分などの開発で対応できる。小規模なソフトウェア会社でも、多数のユーザーにリーチできるというメリットがある。Google App Engine などを使えばサーバーコストも抑えられる。売上の 20% が高いと感じるかもしれないが、相当数のユーザーにリーチできることを考えれば妥当な気がする(Android や iPhone は 30% 取られる)。


◆ Marketplace の現状

5 月中旬に調べたところ、公表されているアプリケーション数は 500 ほどであった。ただし CRM や ERP のような大規模なアプリケーションは数十程度で、ツールに近いアプリ(メール管理など)が数百点と大半を占めている。詳しくは実際の Marketplace でカテゴリ別に確認していただきたい。

また、有料アプリも多い。ユーザー 1 人あたり毎月 7〜8 ドル程度を課金するケースもよく見られる。Android のような個人向けが主のアプリと比較すると、収益化がしやすい印象を受けた。


◆ 技術上のポイント

すでに Web アプリケーションを所有している場合でも新規に開発する場合でも、Apps との統合が技術上のポイントとなる。

・ユーザー認証
ユーザー認証には「OpenID」を使う。これにより、Google Apps のユーザーが再ログインなしでシームレスに外部 Web アプリケーションを使える。

・権限委譲
例えば Apps ユーザーの Calendar から予定を取得し、Web アプリで使いたいとする。この場合 Calendar 情報を提供するかどうかは「OAuth」が扱う。Web アプリ ベンダーはどの情報が取得したいかを表明し、それに対して Apps 管理者が許可を出すという方法である。

他にも技術的なポイントはあるが、基本的には OpenID と OAuth という 2 点のようだ。


◆ 参考情報

・Google Apps Marketplace(英語)
https://www.google.com/enterprise/marketplace/
 → ここにアプリが公開される

・Developer Program Site(英語)
http://developer.googleapps.com/
 → 開発者向け情報。Marketplace での販売方法なども解説している

・Google Apps Marketplace 企業向けアプリ出店入門
http://www.atmarkit.co.jp/fwcr/special/appsmarketplace/01.html
 → 具体的なアプリの公開方法を解説している

あと、私のブログで恐縮だが、Google Apps Marketplace カテゴリでいくつブログ記事を書いている。


※ 本ブログ記事は、執筆時点での最新情報で書いた内容です。
31 5月

続・自分用 URL 短縮サービスを作る: Bit.ly Pro 編

前回の「自分用 URL 短縮サービスを作る: Yourls 編」では、次のように書いた。
こういった自分用 URL 短縮サービスを作るには、大きく分けて 2 つの方法がある。

 A. 自分で用意するサーバで提供する(レンタルサーバ、自宅サーバ含む)
 B. 外部インフラを利用する

今回は B で自分用 URL 短縮サービスを作る方法を説明する。

「外部インフラ」とは第三者が用意するシステムのことである。ここでは Bit.ly という短縮サービスが提供している「Bit.ly Pro」を利用する。Pro といっても通常版は無料である(Enterprise 版は有償)。また、5/30 現在はベータ版となっている。

この方法で有利なのは、自分でサーバを用意する必要がない点だ。サーバ管理が不要になるため、余計な作業が必要なくなる。
また、有償の Enterprise 版を使う場合、自分の長いドメインを誰かが Bit.ly で短縮した場合、自動的に短縮ドメインが割り当てられるという機能もある。これにより、短縮ドメインのリンク先が自分のサイトであることを明示できる。例えば、誰かがニューヨークタイムズの URL を Bit.ly で短縮すると、bit.ly ドメインではなく 「nyti.ms」ドメインに短縮される。
詳しくは FAQを確認していただきたい。

◆◆ 必要なもの ◆◆


 ・自分のドメイン。.com や .net であれば 500〜1000円程度で買える
 ・Bit.ly のアカウント。無料で取得できる
 ・DNS 設定に関する知識。調べれば分かる程度の基礎知識でよい
 ・辞書を使って説明文が読める程度の英語力


◆◆ 手順 ◆◆


ここでは私が行なった手順を記す。どの業者でドメインを取ったのかによって DNS 設定が異なる。適宜読み替えていただきたい。また、この手順は 2010/5/30 時点で確認したため、将来内容が変わっていることがあるので注意が必要である。


1. Bit.ly Pro に申し込む

Bit.ly Pro の Web サイトに移動し、[Sign Up for Free] のボタンをクリックする。次のページに「the signup form」というリンクがあるので、クリックして登録フォームに移動する。

すると、次のようなフォームが表示される。
100530_1


入力が必須の項目は次の通りである。
 ・First Name: 名
 ・Last Name: 姓
 ・Email: メールアドレス
 ・Company Name: 会社でない場合は「N/A」と入力
 ・What is your existing bit.ly user name?: 自分の Bit.ly アカウント
 ・I'd like to use bitly.Pro as a: 自分の職業や自社の業種
 ・List one domain you own that you or other people link to?:
  リンク先のドメイン(私の場合、nishinos.com)。サブドメインは不可。(なぜこれが必須かちょっと分からない)
 ・Are you interested in bit.ly Pro Enterprise?:
  将来、有償の Enterprise 版を使いたいかどうか。不要なら「No」

最後に [送信] をクリックすると、データが送られる。Bit.ly から完了メールが届くまでしばらく待つ(私の場合、数日かかった)。


2. 短縮ドメインを設定する

登録完了メールが届いたら、Bit.ly Pro のログイン ページからログインする。
メニューから「Settings」ページに移動すると、次の 2 つを設定するようメッセージが表示される。
 ・Custom Short Domain: カスタムの短縮ドメイン
 ・Dashboard Tracking Domain: ダッシュボードでトラッキングするドメイン

まず、カスタムの短縮ドメインを設定する。
カスタムの短縮ドメインを入力する前に、そのドメインに対して次のいずれかを行なっておく。

(1)A レコードを「168.143.174.97」に設定する
(2)短縮ドメインにサブドメインを使用する場合、CNAME を「cname.bit.ly」設定する

ちなみに私は「qii.jp」というドメインを「ムームードメイン」という業者から取得した。これが bit.ly の部分に置き換わるのである。

私の場合、サブドメインを使うわけではないので、(1)で行なった。ムームードメインには「ムームー DNS」というサービスがあるため、次の画面のように設定した。

100530_2


Bit.ly Pro の設定画面に戻り、次のようにこの短縮ドメインを入力し、[Add Short Domain] をクリックする。

100530_3


次の画面で [Verify the Short Domain] というボタンを押すと確認手順に入る。DNS に追加しても、DNS サーバに反映されるまでしばらく時間がかかる。少し待って [Check Back] というリンクをクリックし、反映されたかどうか確かめる。

100530_35


うまく確認されると、「Your Custom Short Domain has been verified!」といったメッセージが表示される。


3. トラッキング対象のドメインを設定する

続いて、ダッシュボードでトラッキングするドメインを設定する。
私の場合、ブログで使っている blog.nishinos.com のデータをトラッキングしたいと考えている。しかしドメイン全体(nishinos.com)が対象となるため、サブドメインの文字(blog)を抜いた形で追加する。
画面で次のように設定した。

100530_4


この場合も、ドメインの所有者であることを示すために、次の 3 つのいずれかの手順を行うよう指示される。各ユーザーのやりやすい方法でよいだろう。

・Add an HTML tag to your web site's home page:
 → http://nishinos.com/ の HTML ファイルに指定のタグを追加する(タグはユーザーによって異なる)。

・Upload an HTML file to your web site
 → 指定の URL に対し、HTML ファイルをアップロードする。

・Make a DNS change
 → nishinos.com の CNAME に対し、指定のレコードを追加する。

私の場合は最後の方法で行なうことにした。
nishinos.com ドメインもムームードメインで取得したため、上記の短縮ドメインと同様にムームー DNS で設定した。文字列はユーザー固有のようなので、ぼかしてある。

100530_5


こちらも同様に DNS サーバに反映されてから、[Check Back] をリンクをクリックして先に進む。
これで設定が完了する。


4. 実際に短縮してみる

設定が完了したら、試しに使ってみる。
通常通りに Bit.ly にログインし、例として「http://www.yahoo.co.jp/」を短縮する。

100530_6


これが次のような短縮 URL になる。

100530_7


これを Twitter などに貼り付ければ、よくある短縮 URL として機能する。
27 5月

なぜ IT にはカタカナが多いのか

以前、佐々木俊尚さんがこのようにツイートしていた。
なるほど、シニフィエの翻訳。確かに明治時代の「友愛」とか「理論」なんて言う言葉はシニフィエ的ですね。イメージによって逐語翻訳を超越すべきかと。

http://twitter.com/sasakitoshinao/status/14666875602

これに対し、私が次のように返信した。
翻訳者からするとカタカナを使いたいこともあるんですよね。特に新しい概念に既存の日本語を当ててしまうと、概念自体が誤解される恐れがあります。むしろ見慣れないカタカナを使うことで、新しい概念であることを強調できることもあります。

http://twitter.com/nishinos/status/14668343043

この意見を佐々木さんにリツイートしてもらったため、何人かのユーザーから意見をもらった。興味がある人がいるようなので、これに関して自分の考えをブログ記事を書くことにした。


◆ 言語で異なる意味範囲

上記のツイートで私が「特に新しい概念に既存の日本語を当ててしまうと、概念自体が誤解される恐れがあります」と書いた。これは、言語によって語の守備範囲が違うという点から発生しうる誤解のことだ。
例えば英語の「water」は日本語の「水」である。しかし「water」は「湯」も表す。これは、英語に「湯」を表す一語がないためだ。もし熱い水という意味を伝えたければ、「hot water」と形容詞を加えなければならない。すなわち、「water」と「水」は語の守備範囲が異なるのである。対応関係を図示すると次のようになる。

100520_1


言語によって語の守備範囲が異なるということは、世界に対する認識、つまり世界をどのように切り取るかが、言語によって異なるということである。例えば日本語では虹を 7 色(の語彙)を使って切り取り、別の言語では 6 色や 3 色(の語彙)を使って切り取るといった具合である(この辺りの詳しい話は「サピア=ウォーフの仮説」「ソシュール」などで調べていただきたい)。


◆ 翻訳者は意味拡大にどう対処するか

このように言語によって語の守備範囲が異なる。そのため、ある新しい概念が英語に登場して意味範囲が変わった場合、日本語の既存訳では大きなずれが生じてうまく対応できないことがある。

例えばコンピュータのソフトウェアが一般化する前、「install」という語は「設置」などと訳されてきた。図にするとこうである。円同士が完全に一致しないのは、許容できる程度ではあるものの、言語によって多少の意味範囲のずれがあるからと考えられるからである。

2


install の語源を調べると、機械などを設置するという意味は 1882 年かららしい。恐らくその類推から、ソフトウェア(プログラム)をコンピュータに「設置」する行為を install と呼んだのだろう。これは少なくともノイマン型コンピュータ登場以降であろうから、どれだけ長く見積もっても 1950 年以降である。このとき、ソフトウェアも意味の対象としたことで、install の意味範囲が変わったはずである。下の図で言うなら、青の円が大きくなったということだ。

3


この install の意味範囲の広がりに対し、日本語が対処する方法は 2 つあった。

 (1)既存の日本語の範囲も広げ、英語に対応させる
 (2)別の語によって新しい範囲に対応させる

下の図で言うと、左が(1)、右が(2)である。

4


恐らく数十年前、ソフトウェアの install を最初に「インストール」と訳した人は、悩んだ末に(2)の方法を選択した。広がった意味に対して新しい語を当てることで、新しい現実に対応したのである。


◆ なぜ IT 分野にカタカナ語が多いのか

新しい意味や概念に対応する方法が 2 種類あると書いた。(1)であれば、既存の日本語を使うため、新しい語が作られることはない。また(2)の場合であっても、必ずしもカタカナ語である必要はない。例えば漢字で造語すればよいのである。

ところが、IT 分野では、新しい語は漢字やひらがなではなくカタカナが多い。私が思うに、その理由は次の 2 点である。

・時間がない
IT は技術進歩が速く、日々新しい概念が生まれる。そのため、いちいちコンセンサスを得て訳語を決められないのである。元の英語の音をカタカナにするという方法が手っ取り早い。なんだそりゃ、という感じだが、これが現実である。たとえ苦労して漢字で造語している人がいたとしても、多数派がカタカナであれば、そちらがデファクト スタンダードになる。恐らくこれが一番の原因である。

・カタカナだと原語に遡行できる
仮に日本語にできたとしても、むしろそれが困るケースもある。例えば「設定」という日本語訳があったとする。元の英語は「setting」かもしれないし「configuration」かもしれないし、もしかして「customization」かもしれない。このように英語と日本語が 1 対 1 で対応しない場合、元の英語に遡れない。特にソフトウェアのマニュアルでは、ユーザー インターフェイス(ボタンなど)は首尾一貫させる必要があるため、別々の英語に同じ日本語が当たっていると困ることがあるのだ。これは IT 分野の翻訳者にしか実感できないテクニカルな理由だろう。


◆ まとめ

・言語によって、語の意味範囲(守備範囲)が異なる
・新しい概念の登場によって、語の意味範囲が広がった場合、翻訳者は次の方法で対処しようとする
  - 既存の日本語の範囲も広げ、英語に対応させる
  - 別の語によって新しい範囲に対応させる
・IT 分野では主に進歩が速くて時間がないという理由で、カタカナを使って上記の対応することが多い



:これは私個人の意見であり、評価の固まった学説などではない点にご注意ください。
最新の翻訳書
血と汗とピクセル 『血と汗とピクセル』
筆者について
西野 竜太郎
(Ryutaro Nishino)

翻訳者。合同会社グローバリゼーションデザイン研究所・代表社員。日本翻訳連盟・理事。
プロフィールや連絡先などについてはこちらをご覧ください。
Twitterアカウント
RSS フィード
著書
アプリ翻訳実践入門
『アプリ翻訳実践入門』


ソフトウェアグローバリゼーション入門
インプレス刊
『ソフトウェアグローバリゼーション入門』

達人出版会刊
『ソフトウェア・グローバリゼーション入門』


英語語源が魔術に変わる世界では
『英語語源が魔術に変わる世界では』


現場で困らない! ITエンジニアのための英語リーディング
『IT英語リーディング』


アプリケーションをつくる英語
紙版
『アプリケーションをつくる英語』

電子版
『アプリケーションをつくる英語』
第4回ブクログ大賞受賞】