無印吉澤（※新エントリはhatenablogに掲載中）

■[mobile][Android]自作Androidアプリ「Where's My Info?」をAndroid Marketに登録してみました

最近日記を書いていなかったので、すっかり書くタイミングを逸してしまっていたのですが、実はDoCoMoのAndroidケータイ「HT-03A」を持ってます。ビックカメラで実機を触って気に入って、HT-03A発売日（7月10日）の1週間後くらいに購入しました。

その後、Hello Worldレベルよりもましな「ちゃんとした体裁の整ったAndroidアプリ」を開発する作法を勉強しようと思って、暇を見ては（日記も書かずに）ちょこちょことプログラミングをしていたわけですが……今日ようやっとAndroid Marketに登録するところまでこぎ着けました。今日はここまでの経緯をネタにいろいろ書いてみようと思います。

----

■ 今回自作したアプリ「Where's My Info?」

最近、引っ越しをしたり、携帯電話を買い換えたりすることが多かったので、色々と不便を感じていました。具体的には、こんなあたりが不満でした。

• 何かの書類に申し込みするときに、メモなどを見ないと、新しい住所/電話番号を正確に思い出せない。
• 古い住所/電話番号をどこに提供したのかわからない。何かの申し込みのときに、古い住所/電話番号を使ってなかったか？

そこで、今回はこの問題を解決するために「Where's My Info?」というアプリを開発しました。あまり「Androidならでは！」という感じはしないアプリですし、既存のパスワード管理ソフトに似た面もありますが、携帯に載ってるとそこそこ便利なアプリなんじゃないかと思ってます。

以下は、Android Marketに載せるために作ったスクリーンショットと紹介文です。スクリーンショットは一部英語になってますが、日本語ロケールならちゃんと日本語が表示されます。

あなたはメールアドレスや電話番号を2つ以上持っていませんか？ "Where's My Info?"はあなたの個人情報を、いつ、どこで、誰に提供したかを管理するソフトウェアです。例えば、以下のような場合に、面倒な作業を手助けします。

• 携帯キャリアを変えたので、メールアドレスや電話番号を差し替えたい。でもどこに書いたっけ？
• 引っ越したので、住所を差し替えたい。でもどこに書いたっけ？
• etc.

自分で使うために作ったアプリということもあって、今後もちゃんとメンテするつもりですので、是非使ってみて感想を聞かせてください。現時点では、これから以下の機能を追加しようと考えています。

• データのimport/export
• 情報提供先へのカメラ画像の追加（どこで情報提供したかわかりやすくする）
• 個人情報の並び替え

----

■ Androidアプリ開発の感想

基本的には、まあ、ものすごく敷居が低いですねー。

開発に使う言語はJavaで、かつEclipseでAndroidアプリを開発するためのプラグインもあります。エミュレータの起動や、実機へのインストールもそのプラグイン経由で出来るので、Java+Eclipseに慣れてる人なら特に楽だと思います。

ただ、これはフレームワーク全般に言えることですが、ライブラリが基本提供する機能から外れて、ちょっと気の利いたことをやろうとするととたんに詰まります。今回僕がつまずいたのは以下のポイント。

• リストを表示するためのListViewをカスタマイズして、各項目の中にテキスト2行を表示したい。

  • Android Series: Custom ListView items and adapters(Software Passion) を見て解決。

• ListViewからコンテキストメニューを呼び出したい。

  • Long click on list activity item - Android Developers や How do you implement context menu in a ListActivity on Android? - Stack Overflow を見てもよく分からず、結局試行錯誤してるうちになんかうまくいった。

• タブを表示させる方法がよく分からない。

  • Add a "footer" in a TabActivity - Android Developers を参考にレイアウトのXMLを手直ししたらうまくいった。

• ListViewの中にチェックボックスを作ったときに、そのチェックボックスの値を取る方法が分からない。

  • Checkbox Text List :: Extension of Iconified Text tutorial :: anddev.org - Android Development Community を参考に手直ししてうまくいった。

• 戻るボタンを押すと古い情報が表示されてしまう……。

  • Activityの後始末し忘れ。もう使わないActivityはfinish()でちゃんと終わらせる。

• ダイアログのタイトルを消したい。

  • Dialog with No Title - Android Developers

で、こうやって見て分かるように、細かいことを気にし出すと日本語圏にはあんまり情報がなくなってきます……。

----

■ 特に参考になった書籍、Webサイト

とはいえ、日本語でもAndroid関係の情報はかなり出てきていて、特に以下の本は役立ちました。幅広い話題についてかなり細かく書かれているので、この本だけ買っておけば大体なんとかなります。

Google Androidプログラミング入門(江川 崇/竹端 進/山田 暁通/麻野 耕一/山岡 敏夫/藤井 大助/藤田 泰介/佐野 徹郎)

あと、WebサイトではTaosoftwareのblogにかなりお世話になりました。Android関係で疑問に思ったことを検索すると、日本語圏だと大体ここにたどり着くような感覚です。

Taosoftware
http://www.taosoftware.co.jp/blog/

とりあえず、今日はここまでで。Androidについては、またネタが溜まったらなんか書きます。

■[programming][GAE]RDBからGoogle App Engineのデータストアに乗り換えるときのつまずきポイントとか実例とか

先週末は、某温泉街に籠もってGoogle App Engine（GAE）を色々いじって遊ぶという2泊3日の合宿に参加してました。合宿と言っても「GAE」以外に特にテーマも決まって無くて、みんな適当に好きなことをやってたんですが、僕はGAEの初心者なので、

「リレーショナルデータベースのために書かれたテーブル定義を、Google App Engineに置き換えようとしたらどれくらい大変なのか？」

をテーマに決めて、下の本を読みながらコードを書いたり消したりして遊んでました。

Google App Engine for Java [実践]クラウドシステム構築 (WEB+DB PRESS plus) (WEB+DB PRESSプラスシリーズ) (WEB+DB PRESS plusシリーズ)((株)グルージェント)

----

■ 先にまとめ

まだ勘違いも多そうですが、今回分かった「リレーショナルデータベースに慣れた人のつまずきポイント」を先にまとめておきます。

• GAEのデータストアでは、複合主キーのある表を作れない。

  • 例えばJDOだと、@PrimaryKeyを複数のインスタンス変数に付けるとコンパイル時に例外が出る。
  • ちなみに、主キーのない表も作れない。こちらもコンパイル時に例外が出る。

• 一意なIDを割り当てるためのカウンター（オートインクリメント機能）が必要なら、自前で実装する必要がある。

  • トランザクション処理を使うことで、このようなカウンターを実装できる。
  • JDOインターフェイスでは、valueStrategyにIdGeneratorStrategy.INCREMENT（なんかそれっぽい）を選べるが、GAEでは使えないらしく実行時に例外が出る。

• UNIQUE制約に相当する機能もない。恐らく、自前で実装することもできない？

  • UNIQUE制約は、自前で定義することもできない、ような気がする……。
  • GAEのトランザクション処理は参照したデータに対する排他処理のため、新しく追加する行の値に対する制約にはなり得ないのではないか。

• 多対多の関係を表現しにくい。

  • リレーショナルデータベースに慣れていると、多対多の関係を表現するときは、関係を表す表を新たに追加したくなってしまうけど……。
  • GAEでは複数の表をまたがるトランザクションは基本的に作れないので、途中で処理に失敗した場合の例外処理を書くのがすごく面倒。
  • 当然、JOIN処理なんて無い。
  • 多対多を実現する方法としては、一方の表に、もう一方のIDのリストを格納する列を用意すると楽。GAEでは、「リスト内のいずれかの値がAに一致する」といった検索クエリを「listItems == :A」のような形で記述できる。

• JDOとJPAのどっちを使えばいいのか分からない。

  • JPAを選んでもリレーショナルデータベース固有の機能は使えないので、JDOを使っておけば良いような気がする。でも、情報がなくてよく分からない……。

以下は、上のつまずきポイントに気付くまでに、実際に書いたり消したりしていたソースコードの話です。文章の最後にソースコードも置いておきましたので、興味のある方はダウンロードしてみてください。

----

■ 具体例

最近作ったAndroidアプリ（Where's My Info?）のテーブル定義がシンプルだったので、これをGAEのデータストアに置き換えることを試みました。GAEのデータストアへのアクセス方法は以下の3種類があるのですが、今回は最も情報が多いJDOを使っています。

• JDOインターフェイス（Java Data Objects、汎用的な仕様）
• JPAインターフェイス（Java Persistence API、RDB向け）
• ローレベルAPI（Key-Valueで値を保持するAPI、高速だが低機能）

まず、元にしたAndroidアプリのテーブル定義は、以下のようなものです。個人情報（information）と情報提供先（knowers）の関係を、主キーのないinformation_knowersテーブルで表現しています。

これを、GAEのデータストアで定義すると、以下のようになります。GAE上で扱う表のことを、ここでは「エンティティ」と呼んでいます。

こうして見ると、リレーショナルデータベースでの定義と比べて、やや汚くなってるのが分かります。以下は、リレーショナルデータベース版との違いです。

• Knowerエンティティの列に、関係するInformationのIDのリストを追加。

• IDを一意に割り当てるためのカウンタを追加。

  • 主キーが必須なので、ダミーの主キーを定義している。
  • 今この資料を書きながら思ったけど、IDを一意に割り当てるためのカウンタ類は、1つのエンティティにまとめてしまえそう……。

で、最後にこのアプリを、ユーザ毎に別の領域にデータを格納できるように拡張すると、データストアの定義は以下のようになります。

• 「110487681081245093660」というのは、Googleが提供するアカウント認証サービスから取得できる、ユーザ毎に一意なユーザID。

• InformationエンティティとKnowerエンティティのキーには、ユーザID + "/" + ユーザ毎に一意なIDを使っている。

  • ユーザIDとユーザ毎に一意なIDを組み合わせた複合主キーが使えたら、ホントはそっちの方がよかったんだけど……。
  • クエリとインデックスの方法を使って前方一致検索をすることで、特定のユーザに関係する列のみを取り出すことができる。リンク先にあるのはPython版のコードだが、Java版でも同じ方法が使える。

実例とソースコードを、それぞれ以下の場所に置いておいたので、もし興味があったら覗いてみてください。

実例（注意：管理者＝僕にはデータ丸見えなので、ホントの個人情報は書かないで！）
http://wheres-my-info.appspot.com/

ソースコード（上の実例で動いてるのと同じものです）
WheresMyInfoWeb.zip

----

■ 感想

Eclipseのプラグインを使ってると、Google App Engineのソースコードを書くのも、本番環境にデプロイするのもすごく簡単です。でも、このデータストアを使って大規模なコードを書くのは、正直言って全然出来そうな気がしません。

こんなのを使ってあんなgmailみたいな巨大アプリを書いてると思うと、やっぱりGoogleの連中はイッちゃってるよ、あいつら未来に生きてんな……と思っていたら、今回の合宿の参加者から「Googleの中では、BigTableに（GAEには含まれてない）Chubbyを組み合わせて使ってるんじゃない？」との指摘が。そんな、ひどい……。

■[書評]2009年4月〜6月に読んだ本（みんなもマーケティング本を読むといいよ！）

元旦の日記で「今年は週一冊は本を読む」と宣言したのはさっぱり守れていないのですが、4〜6月に読んだ本についてメモしておきます。この時期はマーケティング関係の本を色々読んでました。

• ポジショニング戦略
• コトラーのマーケティング・コンセプト
• キャズム
• [新版]MBAマーケティング
• イノベーションのジレンマ
• クリティカルチェーン
• ビジュアライジング・データ

----

ポジショニング戦略[新版](アル・ライズ/ジャック・トラウト/フィリップ・コトラー(序文))

「ポジショニング」というマーケティング用語を生み出したアル・ライズ自身による、ポジショニングの解説書です。

本書によると、ポジショニングとは「消費者の頭の中にあるイメージを操作し、それを商品に結びつける」ことと定義されています。消費者は日々膨大な情報に翻弄されているため、頭の中の情報爆発を防ぐために製品のブランドやランク付け（すなわちポジショニング）が重要である、というのが著者の主張です。原著は30年以上前に発刊されたそうなのですが、この点は今でも有効な主張に思えます。

本書では、有効なポジションをつかむための方法や成功例が多数紹介されているのですが、個人的に特に印象深かった話をいくつかピックアップしてみます。

• 重要なのは、人の頭の中に一番に入っていくこと。(p.29)
• 新製品は、必ず既製品に対抗する形でポジショニングしなければならない。消費者の「頭の中のはしご（ある基準に基づくリスト）」を作り、その中で既製品より上に登らなければならない。(p.42)
• 成功したいなら、ライバルのポジションを無視してはいけない。もちろん、自分のポジションを無視するなど言語道断。(p.46)
• どんなポジションでも良い、自社がすでに消費者の中に確立したポジションを活用する。(p.52)
• パワーのある企業がよい商品を生むのではなく、パワーのある商品がよい企業を生み出す。例えば、コカ・コーラ社は、コカ・コーラという製品が持つ実力（製品力）の反映でしかない。(p.63)
• 自社製品ラインナップの抜け（工場の穴）を埋めるのは間違っている。消費者の頭の中でなく、工場の中で穴を探してしまうと、市場におけるポジションを見逃してしまう。その穴は、市場では既にほかの製品に埋められていないか？(p.76)
• 新商品には新名称が鉄則。新しい商品に既存ブランドの名前を付けるのは、情報社会では命取りになりかねない失策。(p.126)

Eric Sink on the Business of Softwareでこの本が強く薦められているのを見て、「マーケティング本か……」とやや尻込みしながら読んだのですが、マーケティング用語を全然知らなくても、読み物として十分面白く読める本でした。マーケティングに興味を持つための取りかかりの本としては、かなりお勧めできます。

----

コトラーのマーケティング・コンセプト(フィリップ・コトラー/恩藏 直人)

現代マーケティングの第一人者（らしい）フィリップ・コトラーによる、マーケティング用語の一言解説集です。読みやすく、それぞれの用語についての感じをつかむにはよい本でした。一方、マーケティング用語が順不同で（原著はアルファベット順に）解説されているため、マーケティング用語同士の関係や全体感をつかみたい方は、後述する「[新版]MBAマーケティング」の方がお勧めです。

ちなみに、本書によると「日本企業の90%はマーケティングを担当する専門セクションを置いていない」そうです(p.167)。コトラーはこれを、「マーケティング部門を置くと、そこしかマーケティングを考えなくなってしまう。日本では、全社員がマーケティングを意識して行動するのですばらしい！」みたいな観点で書いているのですが、それはたぶん違うよなあ……。個人的には、日本企業でもマーケティング部門をちゃんと用意して、そこに権限を与えた方が良いような気がします。

----

キャズム(ジェフリー・ムーア)

有名な「キャズム」の本です。一時期、ブログがブームになった頃に「キャズムを超えた」だの「アーリー・アダプタの影響力が云々」だの色々言われていたので、本書に出てくるキーワードだけは知っている人も多いと思います。僕も、今までそのへんのキーワードしか知らなかったので、改めて原著を読んで、「そういうことだったのか！」と驚かされるところが多かったです。

本書では、新製品がキャズムを超えるのが難しいのは、アーリーアダプタはその製品で何ができるのかを重視する（製品重視の視点）一方で、キャズムの先にいるアーリーマジョリティはその製品の市場を重視する（市場重視の視点）からだと主張しています。つまり、アーリーアダプタでの採用例がいくら増えても、市場を作れなければいつまでもキャズムを超えられない、と。この難題を解決するためには、ホールプロダクト（製品だけでなくその周辺のサービスなどを含む。今風に言うとエコシステムか？）の構築が重要であり、今後はホールプロダクトをR&Dの対象にしなければならないと論じています。

また、本書ではposition statementのひな形を以下のように定義していました。前回紹介したEric Sinkの定義よりはやや複雑ですが、これはこれで面白いと思うので紹介しておきます。

[ (1) 代替手段 ] で問題を抱えている
[ (2) ターゲット・カスタマー ] 向けの、
[ (3) ターゲット・カテゴリー ] の製品であり、
[ (4) この製品が解決できること ] することができる。
そして、 [ (5) 対抗製品 ] とは違って、
この製品には [ (6) ホールプロダクトの主だった機能 ] が備わっている。

----

改訂3版 グロービスMBAマーケティング(グロービス経営大学院)

※僕が読んだのは第2版なのですが、既に第3版がでているのでそちらにリンクしています。

マーケティングについての良い本を探しているときに、P2P todayの横田さんから「まずは一般的なフレームワークを一通り勉強したら？」とお勧めされた本です。マーケティング用語同士の関係や全体感が整理されており、確かに（僕のような）初心者が基礎知識をつけるにはとても良い本でした。さすがヨコタン。

一方、初心者向けではあるのですが、知識が網羅的に書かれているので、読んでも「マーケティングすげー！これは重要だよ！」みたいなテンションの上がり方はしないのが難点です。もし、マーケティングに興味があるなら、上に挙げたような別の本を先に読んでテンションを上げておいた方がいいかもしれません。

----

イノベーションのジレンマ―技術革新が巨大企業を滅ぼすとき (Harvard business school press)(クレイトン・クリステンセン/玉田 俊平太)

有名な「イノベーションのジレンマ」です。ちなみに初めて知りましたが、原題は "The Innovator's Dilemma" で「イノベーターのジレンマ」なんですね。

本書では、イノベーションのジレンマが起こる理由を、既存の製品を取り巻くバリュー・ネットワークという概念（これもエコシステムと同義か）で説明しています。企業がある製品を開発することが「技術的に」可能であったとしても、実績ある企業は自分たちが属するバリュー・ネットワークの財務構造や組織の文化に束縛されているために、そのバリュー・ネットワークを壊しかねない破壊的技術は採用できない、というのが本書の説明（の僕なりの解釈）です。

イノベーションのジレンマ自体はかなり有名な概念ですが、本書ではその中身をかなり深く掘り下げており、原著に当たる価値はあると思いました。特に、組織の能力はそのプロセスと価値基準にあり、組織の構成員がその両者を強く理解している（現在のバリュー・ネットワークで価値を生み出す能力が高い）ほど、「破壊的技術を導入させるためのインセンティブ」を組織の構成員に与えることは難しくなる、といったくだりは衝撃的でした。そういう意味で、本書の内容は組織論にも近いかもしれません。

----

クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?(エリヤフ ゴールドラット/三本木 亮)

本書もビジネス書なのですが、こちらはマーケティングではなくてプロジェクトマネジメントに関する「ビジネス小説」です。ちなみに、ビジネス小説というのは、「ビジネス上の難題にぶち当たった主人公が」、「○○という新しい技術/手法/考え方を知り」、「仕事がうまくいくようになる」というテンプレートに沿った小説のことです。

冗長な部分を取り払うと、本書の主張はだいたい次のような感じです。小説スタイルで書かれているので、このまとめが正しいのかもあまり自信がないのですが……。

• 従来の経営は、部分最適が全体最適に繋がる、という経営哲学に基づいて行われていた。この経営哲学を本書では「コスト・ワールド」と呼ぶ。
• しかし、実際の現場では、部分的な改善が全体の改善には繋がらず、全体のスループットは強度の一番弱い部分に依存する。つまり、もっともスループットが出ない部分を補強する、という取り組みを繰り返す必要がある。この経営哲学を本書では「スループット・ワールド」と呼ぶ。
• 個々の作業ごとにバッファを用意するやり方は、コスト・ワールドに沿った考え方。スループット・ワールドに沿ったやり方としては、個々の作業見積もりはかなりタイト（作業の終わる確率が50%〜90%のスケジュール）に設定しておいて、作業の合流地点に大きな共通バッファを持たせる。
• 特定のスペシャリストがクリティカルパスだけでなく複数の非クリティカルパスに関わるために、結果として作業が遅れることがある。スペシャリストを守るための人単位のバッファも必要。

「ザ・ゴール」みたいなビジネス小説が好きな人にとっては面白いと思いますし、単に小説として読めば面白いと思うのですが……僕は話の結論や整合性（どこまでが作り話なのか？）が気になってあまり集中できませんでした。

----

ビジュアライジング・データ ―Processingによる情報視覚化手法(Ben Fry)

最後はビジネス書から離れて、プログラミングに関する本です（癒される……）。

本書は、Processingというプログラミング環境を題材に、情報の視覚化（Information Visualization）のやり方を解説した本です。冒頭で、「データの理解において最も重要なポイントは、どういう問いに答えたいのかを知ることです」と訴え、答えに至るまでの過程を以下の7ステップに分解して示しています。

1. データ収集（acquire）
2. 解析（parse） … 構造の付加、カテゴリ分け
3. フィルタリング（filter）
4. マイニング（mine） … パターンを見つけたり、数学的処理をしたり
5. 表現（represent） … 視覚化モデルの選択
6. 精緻化（refine） … 基本表現の改善
7. インタラクション（interact） … 操作、表示のカスタマイズの手段を提供

前半では、このように「情報の視覚化」の考え方を示した上で、後半はProcessingを使って上記の各プロセスをどう改善できるかを示しています。

かなり面白く勉強になる本なのですが、書籍の内容とは別に、ProcessingがJavaベースなのが個人的にはどうしてもなじめませんでした……。これ、もうちょっと軽量なスクリプト言語をベースにした方がもっととっつきやすかったような気がするんですよね（ProcessingはJavaの上に軽量な環境を作ろうとしてるんですが、いかんせんJavaベースなので限界が）。やりたいことと比較して、Javaだとちょっと書くことが多くて面倒すぎるような。でも、この本自体は、色々新しい観点を示してくれていい本ですよ。お勧めです。

----

7〜9月分に読んだ本についてはまたあとで……。