IT翻訳者Blog

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

カテゴリ: アプリ/IT

MOOCプロバイダーであるedXに「Entrepreneurship 101: Who is your customer?」というコースがあったので視聴してみました(制作はMIT)。

アプリや製品を開発するスタートアップを念頭に置いた講義です。とにかく顧客やエンドユーザーに注目して製品企画を立てるという内容で、シンプルで分かりやすい方法だと感じました。
英語もやや早口な人が出てきますが、字幕でキーワードを追っていけば、まあ分からないレベルではないのではと思います。

講義の概要は以下の通りです:

・Step 1: Market Segmentation
特定の同質な顧客層に集中し、その他の層は無視する。とにかく集中が重要(Focus, focus, focus)。

・Step 2: Beachhead Market
最初に攻略し、また次への足がかりとなるマーケットのこと。独占できるような狭いマーケットを1つだけ選び、他を捨てて集中することが重要。

・Step 3: End User Profile
エンドユーザーを狭く定義した下位セット(類似する特徴やニーズ、口コミ関係を持つ)に関する記述を行う。

・Step 4: Total Addressable Market(TAM)
特定のマーケットでシェア100%を達成した場合の年間収益のこと。「ターゲットとなるエンドユーザー数 × 1人あたりの平均収益(米ドル)」で計算。TAMが2000万〜1億ドルを推奨。10億ドル以上だと大きすぎ、500万ドル以下だと小さすぎる。

・Step 5: Persona
エンドユーザー・プロファイルを代表するような具体的な1人の人物のこと。顧客が誰かを思い出すのに使う。ペルソナを使うとチームで意識統一が図れる。


以上です。

このエントリーをはてなブックマークに追加

公開しているAndroidアプリ「シンプル体重レコーダー」のダウンロード数(総インストール数)が100万を突破しました。
ユーザー各々の想いから「よし、これを使ってみよう」とダウンロードしてくださったわけで、単純に数字には還元できないものの、やはりうれしいことです。



最初に公開したのが2009年なのですでに6年目のアプリになってしまいました。
当時は日本ではドコモが初めてAndroid搭載端末を出すか出さないかの時期で、アプリも個人開発者が趣味で出しているようなものが中心でした。この変化を考えると実に感慨深いです。

そもそも英日言語対応のアプリを開発しようと思ったのは、来るべきスマートフォン時代のローカリゼーション・ビジネスにいち早く参入しようという意図がありました。
確かにスマートフォン時代は到来したのですが、スクリーンに表示される文字数が少ないため「1ワード翻訳していくら」が主流のローカリゼーション・ビジネスでは大して儲からないことが分かるという残念な結果になりましたが……。

以上です。
このエントリーをはてなブックマークに追加

ほとんど電話をしないのでスマートフォンをやめ、7インチのタブレット「ASUS Fonepad」で音声通話もすることにしました。
本当は電話も要らないのですが、本人確認で電話番号を求められるケースがあるので仕方なく…。

やはり画面が大きいのは素晴らしい。入力も楽で、バッテリーも長持ちする。

ただ7インチを片手で持って通話するのも疲れそうなので、昔の黒電話風の受話器を買い、さらに昔のダイアル風アプリをインストールしたらこんな感じになりました。

phone

街中でカバンから取り出し、ダイアルを回して電話をかけたい、ドヤ顔で。

このタブレットはSIMフリーなので、通信会社もMNPで「日本通信」に変え、「スマホ電話SIM」を契約しました。音声通話の月基本料が1,080円、データ通信は1GBまで定額で1,980円のプラン、合計月3,060円です。まあ自宅や学校ではWiFiを使っているので、私の場合は1GBもあれば十分でしょう。


ちなみに、受話器はLEICKEという会社のもの、ダイアル用アプリは「Rotary Dialer PRO」です。

あと、タブレット通話は面白そうだがでかい受話器を持ち歩けないという方は、Bluetoothの小型無線受話器みたいなのもあります(例えばGreen House製品)。
このエントリーをはてなブックマークに追加

以前の記事「いい設計をするには豊富なボキャブラリーが必要か」に記載したように、英語でメソッド名を付ける方法に関して興味を持っているプログラマーは少なからずいるようです。

メソッド名で使う英語に関するサイトや研究はないかと探したところ、少し見つかりました。
基本的にJava言語です。


まず、Stephen Colebourne氏のブログ記事「Common Java method names」です。
動詞や前置詞が合計20個ほど紹介されています。
CommonJavaMethodNames



次に、Einer Host氏の博士論文「Meaningful Method Names」です(PDFはページ最下部「閲覧/開く」からダウンロード)。
こちらはかなり長いため私は全部目を通しておらず、内容の紹介はできません。面白そうな論文が見つかった、程度です。

具体的な英単語を載せた図表がいくつかあったので、興味があれば前後の文脈も含めて読んでみてください。まず57ページからの一部引用です。
CanonicalMethodNamesForJava_58

次に123ページからの引用です。
CanonicalMethodNamesForJava_123


ちなみにHost氏は「Java Programmer's Phrase Book」(同博士論文の第8章)というものを作成していて、論文内では部分的にしか触れていません。フルバージョンもあるらしいのですが、紹介されているリンク(http://phrasebook.nr.no)が切れているので、このPhrase Bookの内容は不明です。非常に面白そうですが。

ブログのリンクや論文の参考文献を辿って行くと、関連したリストや研究も見つかります。
以上です。
このエントリーをはてなブックマークに追加

(プログラミングの話なので専門的です。)

先日、メソッドや変数の命名方法に関する勉強会に参加しました。
そこで聞いて印象的だったのは「いい名前をつけようと思ったら設計をしっかりしないといけない」という話です。例えばちゃんとクラスが分割できていないと、その内容をきちんと表す言葉で命名もできない。つまり「設計→言葉」という方向です。これはまったくその通りだと感じました。

その後しばらくして、言語学のある理論を思い出しました。100年くらい前までは言葉というのはラベルのようなものと考えられていました。例えばワンワン吠えるあの動物に対し、日本語は「犬」、英語は「dog」というラベルを付けて認識するという考え方です。
しかしソシュールという学者が登場して以後、実体(犬など)がまずあって次にラベルを付けるのではなく、ラベルがまず存在することで初めて実体を認識できるという考え方が出てきました。例えば虹の色です。日本語では虹を7色で認識しますが、もっと少ない色数で認識する言語もあります。日本語であっても、一般的な日本人なら7色かもしれませんが、多くの色名を知っているデザイナーであれば更に細かく認識するかもしれません。ボキャブラリーの豊富さが認識の精度に関わるわけです。

つまり「設計→言葉」という方向とは逆に、多様な言葉を知っているからこそうまく設計や分割ができるという方向も考えられるのではないかということです。すなわち「言葉→設計」の方向です。いわゆるデザインパターンもそれに近いのかもしれません。

もしよい設計をするために豊富なボキャブラリーが必要なのであれば、プログラミング言語能力を鍛えると同時に、自然言語の能力も鍛えなければならない。この辺りは卵か鶏かという話かもしれません。
このエントリーをはてなブックマークに追加

↑このページのトップヘ