4/22/2014

[&] Tiny Pictures : An Optimization Case Study



Tiny Pictures : An Optimization Case Study
Penultimate (by Ben Zotto)
-----------------------------------------------------------------

要約:Evernoteと同期できる手書きアプリPenultimateの画像圧縮に関して。
UIImagePNGRepresentation()は遅すぎるので、PNG-8を使うことにし、
pngquantも遅すぎるので、あらかじめカラーパレットを作っておきループを無くしました。
最終的には OpenGL ES のルックアップテーブルで超高速化しました。


-----------------------------------------------------------------

Evernoteのユーザーの方、手を挙げてくれるとうれしいんですが...
Ben Zotto といいます。このような機会を設けてくださり、ありがとうございます。

今日は Image Optimization ということで、かなり技術的な内容になります。
Evernote API, SDKのことを聞いたことがありますか?

簡単に API, SDKはご存知のように、非常に人気のあるクラウドメモサービスを同期する仕組みです。
私たちのアプリはこのプラットフォームは、アクセスのための汎用ツールですが、
パワフルな APIを公開していますので、開発者の方々に使ってもらえると思います。

特にこのアプリケーションによって様々なコンテンツを、永久的に保存したいと
思っている人たちにとって、素晴らしい仕組みだと思います。
もうすでに github に iOS SDKが使えるようになっています。
もっとシンプルなバージョンを作っていきたいと考えています。
使った印象を寄せて頂けるとうれしいです。

●さて、Evernote Platform Awards に関して。
一年に一回開催しているアワードです。
最高のアプリケーションをお祝いするものです。
このアワードに是非参加して欲しいと考えております。
9月の頭にアワードが発表される予定です。

●Image Optimization というテーマに入っていきます。
Penultimate という iPad アプリをご存知の方は?
iPad 用の手書きアプリです。
一冊一冊の本としてメモが存在するというアプリです。

iPad でメモを書くと、Evernote に同期されます。
この段階ではすべてイメージとして保存されます。

●さて問題は?
同期のプロセスの際に、すべて画像としてレンダリングする、
編集するたびに頻繁に更新されます。
ところが事情としては、帯域も限られていますし、
Evernote のアップロードの容量も限られています。
そこで、もっとも小さなイメージを作るのが課題となってきます。

●イメージとは何か?
イメージとは、色の値の集まりです。
ビットマップは大きなグリッドとして存在します。
すべてのピクセルが数値として表されています。
イメージを保存したり、転送したりすると、
バイトストリームのエンコードをすることになります。



●RGBA
7 254 7 255
RGBは色、Aは透明を表します。4バイト、4チャンネルで32ビットになります。

●どこが問題なのか?
iOSの世界では二つの関数があります。
UIImagePNGRepresentation() ロスレス、差異は無い
UIImageJPEGRepresentation() ロスがある。
ロスレスの方はソリッドカラーに向いていて、
JPEGの方は写真のようなものに向いています。
このシステム関数があって、高速に使えます。

Evernote に同期する際にどうするのか?

●一つの実験として、
3つの種類のイメージがあります。
メモ、図、それらを組み合わせたもの(Dense)

Raw PNG JPEG
------------------------------------
Writing 2.5mb 145kb 155kb
Diagram 2.5mb 110kb 136kb
Dense 2.5mb 251kb 191kb
------------------------------------
素材はすべて 2.5mb と違いはありません。
実際に PNGと JPEGを比べたところ、数値としては小さくなっています。
PNG と JPEG を比較すると、Dense に関しては JPEGの勝利。

確かにもともとの数値と比べると小さくなっていますが、
いつもEvernote と同期しているのであれば、この数字で充分なのか?と考えます。

JPEGの圧縮パラメータをもっとも小さくなるものにしていますが...

●どちらが良い?
PNGはロスレス PNG と同じくらいしか期待できません。
24bit のカラーとアルファ、
サブセットしか使っていない、ページの下地もだいたい白い。
そこで色深度をベースに最適化を計ります。



●PNG-8
PNG が登場して GIFに代替する際に、PNG-8 というのがありました。
PNG-8 は 256色のパレットを使い、
ピクセルをフルで使うのではなく、インデックス化して使います。
もともとは pixel あたり 4バイトでしたが、1/4 のサイズになりました。

パレットの場合には、255色、32bit カラーをパレットに格納してあります。

●Quantization
フルカラーのイメージをパレットに変換していくのですが、詳しく説明していきます。
Quantization は3つのステップです。

1. 元の素材から、色のヒストグラムを作ります。
2. 256の共通項をみつけて、最適解を導き出します
3. パレットの中から最良の色を、各ピクセルに対応づけます。

実は pngquant というコマンドも出来ます。

●pngquant
---------------
Writing 61kb
Diagram 36kb
Dense 91kb
---------------
Mac で 0.7秒くらい。
まず、Penultimate では使える色が限定されていることあって、
圧縮された後と比較してもほどんど違いが分からないくらいです。
これが写真であれば、だいぶ異なるのですが。
これは大歓迎できる数字です。

まずは pngquant を使うことで、だいぶ改善できました。

●First attempt
実際にアプリの中で pngquant を使ったところ、1ページあたり6秒かかりました。
これは遅すぎます。iPad で 6秒なんて、とんでもない遅さです。
6秒、悲惨な数値なのですが、ぜひ問題がどこにあるのかプロファイルをとります。
remap_to_palette と nearest_search, colordifference にかなり時間がかかって
いることがわかります。

どこに時間がかかっているのか?
Quantization のプロセスのどこに時間がかかっているのか?
リマッピングにかなり時間を食っているということが分かりました。

for (pixel in image) {
for (color in palette) {
// evaluate color distance.
}
// emit best match for pixel.
}

要は、ループの中を分析することで、もっと速くできないかと考えました。

●Inner Loop
元の pngquant はベクトル式の SSE コードが使われていました。
iOS の ARM 用には ARM NEON があり、それを使って実装しました。

●Outer Loop
元の pngquant では OpenMP を使っていて、ピクセルの並列処理を行っていました。
OpenMP は iOS では使えます。
Grand Central Dispatch を使ってだいたい同じようなことができます。

●Second attempt
これからがクールな作業です。
アウターループの処理を行いましたが、前回は 6秒でした。
今回は ..... 5秒でした。遅すぎますね。(ため息)

●Face
何が問題化というとアルゴリズムが遅い場合は、
いくら実装を速くしたとしても、遅いのだ
ということです。
ここでの命題はインナーループを消してしまったらどうなる?
ルックアップテーブルをあらかじめ持っていたとしたら、
そこから当てはまる色をすぐにピックアップできるだろうということです。

現実の世界では、色合いは違うのですが、
このアプリの場合は、あらかじめルックアップテーブルを予想することができます。

●Third attempt
さて、オフラインで使うことによって、
パレットとルックアップテーブルを、あらかじめバックグラウンド、オフラインで作るようにしました。
前回は 5秒でした、インターループが無くなると、
0.5秒でした!

デスクトップだとしても速いですし、iPad 上の処理としても0.5秒は
素晴らしいスピードだと思います。
イメージのサイズによってスピードは異なりますが、指数的には増えません。



●Is that the end?
いろいろ努力してきました。
そこまでくると、もうちょっとしてみようと、もっと速くできないかと
考えるようになりました。
ルックアップテーブルは3Dテクスチャに見えないか?と考えました。
GPU, OpenGL はもしかしたら使えるのではないかと考えました。


スライシングされているように見えると思います。
OpenGL のスライドがありますが、詳細は省略します。
OpenGLの実装は、2Dのジオメトリ, 8bit のパレット、
さらにオフスクリーンのレンダーバッファーを活用。

●Fourth attempt
すべてを GPU の上でやってみました。今回は
0.025秒でした。
これは本当に速いですよね。
どうして 0.025秒まで速くなったのか。
その鍵は、GPUは超並列処理だということ、
シェーダーがピクセルを並行して同時に計算することができます。
Texture lookup も非常に高速です。

●Ship it
UIImagePNGRepresentation よりも、55〜70% 小さくなりました。
見た目は見分けがつかないほど、
とても速い。
特定のユースケースではとても効果がある。

●Morals of the Story. まとめ。

- プロファイリングをしよう。ボトルネックを見つけよう
- 標準のツールは、多くのケースに対応しているので、実際の利用にはどういうニーズ、用途で使われているのか見極める
- 今回はOpenGL を使いましたが、目的のプラットフォームの上で動作するか確認する必要があり

だいたい一週間かけて、このような努力を行いました。
よりよいプロダクトにすることができるのか?
改善できなければ無駄骨です。

Q ルックアップテーブルの大きさは?
A. すべての色が含まれたルックアップテーブルが 4GB ぐらいで大きすぎます。
透明(アルファ)の部分を削除すると、16Mbit まで下げることができます。
最終的には 64x64zx64 のルックアップテーブルになりました。

Q. GPUでバッテリー消費は?
A. テストしてません。懸念も持ちませんでした。

4/18/2014

[&] How to make Conference Apps



あんざいゆき×秋葉ちひろはカンファレンスアプリをどう作るのか?
---------------------------------------------------------------------
ABC 2014 Spring カンファレンスアプリ
https://play.google.com/store/apps/details?id=com.uphyca.abc2014s

(お二人ハモって)よろしくお願いします〜
どうデザインして実装したのかという話しです。

あんざいさん:Y.A.Mの雑記帳というブログがよく知られています。

秋葉さん:ツクロア、2人のデザイン会社です。今はハードウェアとかも....

今日の前半は設計、デザインについて、

●新しいアプリを作るステップ
1. 既存アプリの調査
2. ざっくり機能を考える
3. 構成(画面遷移)を考える
4. 各画面のレイアウトを考える
5. 実装する
6. 使ってみる

秋:動きだけ一緒に決めて、レイアウトを引き取る感じ、
あ:実装しながらも、デザインも変わっていって、
最初に決めてではなく、作りながら画面どうするかを
決めていったことも何個かありました。

●1 既存アプリの調査

- どういう機能があるか
- どういう構成(画面遷移)になっているか
- こういう機能もあればいいのになあ
「必要な機能がみえてくる」

秋:それぞれの個々のよいところの寄せ集めみたいなことはやります。
あ:すでにあるアプリを見ると、いいところはあるし、
そこから新しい発想も出てくるし、漠然と一から考えるのは難しい。
だいたい必要な機能が見えてくる。
機能作るまえに調査することが多いです。

秋:調べたアプリで使いにくいところを改善してやろいうということにもなります。

ABC 2014 Spring 関連のアプリ
ABC2013 Autumn 関連のアプリ
Google I/O アプリ
Google Play で「Conference」で検索した結果からよさげなもの

あ:あんまりいいのなかったよね〜
秋:WebView ですか〜みたいなのとか。
あ:ガイドラインにそった良いアプリが無かった
でも参考にならないわけではなかった、
良いアプリが無いと、よいアプリを作ってやろう!というモチベーションになった。
だいたい20個ぐらい見て、そこから機能を考えようと、

●ざっくり機能を考える

すでに既存のアプリであるもの、必要な機能は既存のアプリを見ているとわかる。
公式サイトに飛べるようになっていたり、
特定のタスク、ゴールを満たすようなものに特化していって
細かい情報はなんでもかんでも載せるべきではない。
ので、残りは公式サイトに行ってね〜

秋:載せすぎてもわからなくなるから〜
あ:講演内容を見るのが重要、それ意外にスケジュール作りたいとか、
お気に入りとしてチェックしたい、地図を見たいとか、
既存アプリには地図出てくるのが無くって.....

どんなに沢山セッションがあっても一つの時間には一つの講演しか見れない。
同じ時間帯の講演から、どれ見ようかなって考えるよね
→タイムテーブルが欲しい

秋:ユーザーになってみないと分からないですよね。
エンジニアは XML のデータがあるから、それを出すだけで終わってしまいますが、
ユーザーから見ると、時間軸が全然なかったので、
それはやっぱり重要だよねと気づくというプロセスは大事。

あ:いかに使う場面を想像できるのかというのが
使いやすいアプリを作れるのかになってくるのかな。
時間割みたいな、表みたいなのが、Webに載っているのですが、
それをそのままスマホに持っていくのは難しい。

タイムテーブルの項目をタップしたら応援の詳細がみたい
どれがお気に入りになっているか知りたい
どの部屋の講演か知りたい

タイトル、講演者、概要、時間、部屋、カテゴリが知りたい
カテゴリをタップしたらそのカテゴリの講演一覧が見たい
講演部屋の地図がみたい
お気に入りにチェックしたい

●しなりおを考える2(想像する)
バザールの見せ方って難しい
「地図が無いとつらい、常に見たい」
ブースの数が多いので、地図のどこにあるかすぐ見つけられるようになってて欲しい

色分けわかりやすい。
あ、い、う、え、か も別の色がいい

あ:色分けって分類したりする時に分かりやすいものだな〜と思ったんだよね。
色によって島がわかれているのであれば、色を見ればその島なんだなというのが
すぐわかって。
秋:色が脳にアピールする力は強い、記憶と結びつくと思って

その島のブースかすぐわかりたい
色分けの色を表示するとか
ブースがたくさんあるから下までいくのたいへん
インデクスラベル + fast scroll
ヘッダーが残るリスト

あ:パターンクックブックに載っているのがいい!と。
Android にもあるんだ〜と。

●詳細の要求

地図と一緒にみたい
地図を見るときにブース番号を覚えておかないといけないのはイヤ
どの島のブースがすぐわかりたい
色分けの色を背景にするとか
隣りのブースの詳細に簡単に移動したい
(ある島を流れ歩きでぐるっと見て回るときとか)

あ:今回ABCにいって、インプレスのブースに行くまでに苦労し.....
地図重要です。
秋:デザイン作らずとも色付きのものを作ってくれていてわかりやすい!と思って
あ:スワイプすると、隣りのブース情報に行けるんですよ。
便利だな〜と思ってそうしています。

●お気に入りの要求
それをみて行動するからスケジュールっぽくなっているのがいい
時間順に講演が並ぶ
地図が常にでている

あ:今回考えていて、講演内容が見えるのが重要ですが、その次ぐらいに
地図が重要かなと。
秋:今回会場が離れていたんだよね。紙の地図みても.....

あ:最後に実際使っていて、開場までの Google Map も無いと、
日付とか住所とか出ていて、そこから Google Map が開けるようになっています。
秋:すごくいい!

●トップレベルの画面
タイムテーブル
お気に入り(毎スケジュール)
カンファレンス一覧(カテゴリごと)
画面きりかえを使いたい
Navigation Drawer

あ:タブだとちょっとダメなので、Navigation Drawer かな〜と

●タイムテーブル
タイムテーブルを載せたいと、それを一画面に入れるのは
相当無理。

特定の時間枠ごとにどれを見るか考えるなら、時間枠ごとに1画面にするのはどうか
→横軸を時間にする
→スワイプで隣りの時間枠に移動

あ:横軸を時間にしたのはナイス!という人も入れば、
ぱっと見わからないという人もいて....
秋:慣れるとわかるけど。
あ:画面のデザインというよりも情報デザイン的にどういう画面があるとか。
隣りの時間軸に行けるとか、全体のでっかいタイムテーブルの一部分を
見るようにしたかった。

講演詳細の画面遷移
特定の講演の情報
地図アイコンタップ→地図
カテゴリタップ→そのカテゴリの講演一覧

秋:地図をボタンで設置したのは、内容を見るのは、前日ぐらいで、
この画面の中に常にだしておく必要は無いかなと。

●カンファレンス一覧の画面遷移

あ:個人的にはタイムテーブルがあったら、タイムテーブルしか見ないんじゃないかなと。
特定のカテゴリを見たい人はいたいのかな?
とりあえず、デザイントラック、残りの時間は他を探すとか、
秋:サブ的でもいいので、ある方がいい。

●バザールの画面遷移

秋:あるきながら使うという想定もあり。

●お気に入りの画面遷移

あ:お気に入りが最初と最後で一番変わったところ。
バザールもお気に入りつけたかったんで、
最初一画面に入れようと思ったのですが、
一画面だと、微妙だったんだよね。スワイプで隣りになるようにしました。

●各画面のレイアウトを考える

メインの色を決める
タイムテーブル
詳細
お気に入り
バザール
マイスケジュール

秋:考える時は考えるのですが、ネイティブUIを使うときは、
使う要素が決まっているので、色をどうするのか?ぐらい。

メインの色は白ベース、色は最初に2人で話していて、
黒ベースは無いよな〜 白ベースでアクションバーをグレーにする?
グレーは暗くなってしまう時があって、
白がメインカラーで、サブカラーでグレーを使っていて、
それだけだと葬式っぽくなるので、
ABC なので、ドロイド君の黄緑と、オレンジをここで使ったのですが、
黄緑の補色で。青だと死んでしまうので、オレンジを目立たせる色として
選びました。

あ:補色選ぶのって難しい? 近くに置くとパキパキしてしまう。
秋:そこは感覚でやっています。

●タイムテーブル
ActionBar のタブではなく、ViewPager TabStrip
文字のジャンプ率と色で情報の優劣をつける

秋:大きくする必要は無いなと思ってViewPager TabStrip
タイトルが黒なんですよね。人の名前がグレーなんです。
両方黒だと見分けが着かなくなる。
ジャンプ率、大きさの比率を考えて、どちらかを小さくすると
見やすくなると思います。

●詳細が面
ヘッダで領域をとらないように
文字がかぶらないように

あ:配置を悩む画面だよね
秋:要素は少ないけど、項目がおおくって、



タイトルが長いと、追加ボタンが被ってしまう。
右に変えて、線を入れてましたが、線無い方がいいんじゃない?
横幅を延ばして、余白を狭めるかたちで、中のコンテンツが上の方に来るように工夫しました。

秋:綺麗になったよね。
あ:そうだね。カテゴリの色があってていいよね。

●お気に入り
アイコンだけだとわかりづらい
マイスケジュールに登録



秋:しおりのマークだけだとわからないじゃないですか。
背景色もつけたのですが、上下2列並んだときに、
今は余白付きのオレンジにしました。

あ:へ〜 なるほどなるほど

「マイスケジュールに登録」文言を吟味
「登録」だけだとわからないし、どっちが自然かな?と思って、
「マイスケジュールに追加」

あ:出て来たものをホイホイ作ってたのに。

秋:お気に入りのオレンジがなかったらこんなに悩まなかったのに、
真ん中も綺麗だな〜と思ったんですが、
あ:場所が小さくてぱっと見わかりにくい。



●マイスケジュール

あ:最初、これはないだろ〜
すでにお気に入りにしたものしかここには入っていないハズなので、
秋:まだ未登録の場合、これどうしようとなって。
今、エンプティの画面作るときこつがあると思っていて、
上に寄せてしまうと、カッコ悪い。何も無い画面を楽しく見せないといけないと
考えていて、エンプティの枠の中で、上下方向の真ん中ぐらい。
真ん中に何かを配置すると、エンプティ画面っぽい感じがして、
ドロイド君が真ん中にいて、
探すというボタンがあって、無いと、どっから何をするのかが
分かりにくいから。

あ:画面上に追加ボタンがあって、→を向けて、みたいなのがあって、
Navigation Drawer を出すところを示そうかな〜と思ったけど、
今回は直接飛べた方がいいかな〜と思って、
バックボタンを押すと、アプリが終了しちゃって、そこの遷移に
悩んでいて、エンプティの画面からアクションに飛んだ時に、
どうやって階層構造を持たすのかが難しい。

秋:階層構造難しいですよね。
あ:いっかいチラ見せしてからかな〜と思って
作りながら悩んでいることが多いです。

後半は実装の話しをしたいと思います。

Q. 画面のレイアウトを考えたり、デザインを考えたりするとき、紙?ツールを使ったり?
A.
あ:最初相談したときは、ノートに書きました。紙に書くと、その後わりに綺麗なものを作るときは?
秋:紙で書いたやつを、144pix とか、かっちり決めてイラストレーターで起こしています。

Q. 機能を考えた後に、遷移図はどの段階で作りますか?
A.
あ:一人で作ったからだと思いますが、ちゃんとした画面遷移図は作っていません。
ノートに書いた時に、設計段階で画面の関係性は決めてしまう感じ。

Q. デザインをイラストレーターで作っているという話しでしたが、Photoshop ではない理由は?
A.
あ:テクスチャモリモリのころは、Photoshop でしたが、フラットデザインになってから、
イラストレーターでちょっとグラデーションつくれるくらいで、早く作れる。
クリエイティブクラウド版を使っています。

Q. ノートは実際にどのくらい細かく書いてますか?
A.
あ:わたしかなりがっーっと書いて、かなり汚いですが、
秋:A4 のノートに小さい感じで書いていくぐらい。
あ:ステンシルとか、枠が印刷してあるのとか、使ってないです。
けっこう殴り書きな感じです。

---------------------------------------------------------------------------------------
後半:実装編

あ:ABCのサイトで公開されている XML をまずパースします。
ローカルDBに入れて、見るという形になっています。

今回難しかったのは、一個のカンファレンスの中に
スピーカーの ID を持たせて、
スピーカーが複数なので、いい方法があったら、それやりたいんですが、
スピーカーの IDをセミコロンで結合して、
分解して、スピーカーテーブルからひっぱってきて表示するという形にしました。

カンファレンスアプリを一般カンファレンス用に拡張するとか、
このへんを上手く考えて、最終的には XMLからそのままDB設計を考えるのではなく、
こういうDB設計になっていればアプリとして使いやすいという風に。

秋:XMLは使われていない?

最近は JSONの方がうれしい。
XMLだと文字列処理をしなければいけないが、
JSONだといろいろやってくれるライブラリがあるので楽。

バザールも、IDと出展者の名前が group になっていたり、
ここもちょっと悩んでいたのは、ロケーションの情報が「イ1」とか
それだけなんですよ。
そのへんがアプリとして使いやすい API設計に関係していくと思うのですが、
今回は「ア」はどの島なのか、しょうがないので、むりくり。
そのへんの島と番号は別にして、APIを設計して欲しいな〜というのがありました。

秋:API設計の問題もあるんですね。

あ:コードを書き換えないといけないので、優しい設計ではない。
今回フラグメントを使っているのでActivity はあまりない。
MainActivity にほとんど入っている。
スワイプのところもフラグメント、
マイページもフラグメント
バザールもフラグメント
かなり沢山入っています。

Navigation Drawer は一個の Activity に沢山フラグメントが入る事になります。
カンファレンス一覧のアクティビティもそれだけ。
最初はタブレットのことも考えたのですが、
間に合わなかったのですが、タブレット対応も一応考えてあります。
詳細をタップしたらというタブレットの構成にしたい場合も考えて。

バザールの部分も、スワイプで下の部分が変えられるようになっていて、
ViewPager の中がフラグメントになっています。
画面遷移は今日初めて作りました(笑



秋:詳細にはいろんなところから行けるんですよね。

タイムテーブル
ViewPager
PagerTabStrip
ListFragment
複数の Cursor を持つ
Adapter

フラグメントの中にフラグメントが入っているような構成になっている。
APIレベル17以上になっているのはそういう理由。
LTって同じ枠の中に複数のセッションが入っているので、
カラムを一個にしたいということで、
各部屋が Cursor で、複数の Cursor を持つアダプタという実装になっています。

複数の cursor を持つ Adapter
連絡帳アプリで使っているのがあって、
ヘッダーの表示も対応している。
http://tools.oesf.biz/android-4.4.2_r1.0/xref/frameworks/ex/common/java/com/android/common/widget/CompositeCursorAdapter.java

BaseAdapter を継承していて、
パーティションを内部で持っていて、この中に cursor も持っていて、
中に cursor 、うまくポジションを渡してくれたり。コードを読んでみるといいです。
それを使うと、
それぞれのパーテションに対して、そこの cursor を取ってこれて、
cursor に一個しか入ってなければ、時間を表示していなくて、
複数の cursor が入っている時はLTの時間を表示する実装になっています。

●カテゴリー一覧
ListFragment
SimpleCursor Adapter
カテゴリー名(カテゴリーIDのCursorを作る)
重複していないヤツが欲しい。
ただ単にコンテントプロバイダーからカテゴリを取ってくると、
IDが違うから、同じカテゴリ名が並んでしまう。
SQLの group By を使う。
カテゴリでグループにして、そのリストを作る。

Content Provider で group By を使うのはベタの方法しかなく、
appendQueryParameter で取得して、そのまま group by に渡す。
結構SQLを理解していると、Java側で頑張らなくても、欲しい cursor を取ってくる
方法があるので、知っていると楽。
罠があって、
SimpleCursorAdapter には _id カラムが必要
group By したカテゴリーIDを as を使って _id として取得

カーソルラッパーを使う方法もありますが、SQL を使うと良い。

すべてのトラックを表示するための行もほしい
MargeCursor を使って Cursor を合体
すべてのトラック用の Cursor は MatrixCursor で用意

秋:すごいですね!簡単そうに見えて.....

ほんとに楽しようとおもったら、カテゴリの表示を文字列にしておいて、
のちのちこれを次のカンファレンスで使おうとおもったら、
ハードコーディングはできないので、
こんなことをしないと。

秋:すごい考えているんですね!

次回使うことも考えて、書いているのですよ!

スピーカー
ListFragment
SimpleCursor Adapter
カンファレンスのテーブルにはスピーカーID
スピーカー名は別テーブル

スピーカーのIDを名前に変換しないといけない。
カンファレンスのテーブルにはスピーカーの IDが ; 区切りで入っている。
シンプルカーソルアダプターでごにょごにょやりたくない。
スピーカー名に変換されているカラムがあって、それを表示するだけ
にしたくて、どこでごにょごにょ変換するかというと、
CursorWrapper を使いました。

CursorWrapper と何がいいかというと、内部で実際にテーブルから帰ってきた内容に
編集したものを返したいとか、ごにょごにょした部分を隠せるのが利点です。

カンファレンスの詳細
ListFragment
ヘッダー
カンファレンス情報
リスト本体
スピーカー
お気に入りボタン

結構がんばったのは HTMLボタン。
HTMLボタンをCSSで動きを書いたのが送られてきて.... 中身読みました。

FrameLayout を継承した CustomView
ToggleButton と★を重ねたレイアウト
CHeckable を実装し、ToggleButotn に流す
ONでアニメーション
トグルボタンですが、チェックボタンの属性を指定しています。

秋:そうなっているとは知らなかった

見た目はそんなに難しくないです。
一番難しかったのはバザール一覧

ListFragment
各島が一つの Cursor
複数の Cursor を持つ Adapter
FastScroll +ヘッダーが残る

CompositeCursorAdapter を改造
もともとヘッダーの表示に対応している
ヘッダー情報を使ってインデックスラベルを作成
ヘッダーの残るリストに対応

CompositeCursorAdapter に辿りつくまで試行錯誤した感じです。

マイスケジュール
ViewPager
PagerTabStrip
Fragment + ListView

実装はだいたいこんな感じなんですが?どうなんですか?

秋:デザインしてもらってから実装するまで時間がかからなかったのですが、
こんなにめんどくさいことをしているのかと思うと、心が痛みます。

あ:デザインからすると、どれが簡単で大変なのかが分からないですよね?

秋:ここまでの動き、触ってて気持ちいい。これ作ってもらって「いいな」となりました。
あ:うふふ

秋:逆にデザインに対して「くっそー」っていうのは無いですか?
あ:最初、どうやって内側に入れればいいんだべなーと思って

秋:今思うと Web っぽいかなと。
あ:内側の区切り線も、あのへんとかも、最初どうしようかなと悩んでたんですよ。
秋:そこはデザイン都合しか考えられないですよね。
あ:けっこうチャレンジングなデザインでした。でも出来るってことで。
「あんざいさんが出来る!って言ってました!」と言ってください。

Q. ABC の API はリアルタイムで更新されるようになっていますが、更新を
リアルタイムで取るとして、どのタイミングでトリガーにするか?更新ボタンはどこに入れるか?
A.
あ:リアルタイムでやると Sync サービスみたいのがあって、
Google I/Oもコンテントプロバイダーで同期する。
ひっぱって更新する? タイムテーブルに入れると変
秋:何が更新されるかわからない。
あ:プッシュでやるべき? プッシュは API 出している人でないので分からないですよね?
秋:そもそも更新があるものではない。
あ:でも前日とかにいっぱい変更が来るんだよね。
秋:オーバーフローに入れる。こっそり。

Q. アクティビティにするか、フラグメントにするか悩むのですが。トラックの一覧から、
講演一覧、講演詳細はアクティビティですが、
フラグメントの判断基準は?
A.
あ:階層構造をフラグメントでやるのは好きでなくて、
同じ階層の切り替えはフラグメントでやって、階層が変わるところはアクティビティで。

Q. デザイン側とプログラミング側で、アクティビテイ/フラグメントは細かい話しをするのですか?
A.
秋:アクションバーとかデフォルトUIを使おうという話しだけ。

4/15/2014

[&] birthday


( Photo by Theresa Thompson )

1452.4.15 [ レオナルド・ダ・ビンチ ](モナリザの作者/ヘリコプターの考案者)

1707.4.15 [ オイラー ](パイπとルート√記号の考案者)

1933.4.15 [ エリザベス・モンゴメリー ] (奥さまは魔女の魔女サマンサ)

1940.4.15 [ ジェフリー・アーチャー ](小説「百万ドルをとり返せ」の著者)

1948.4.15 [ マイケル・ケイメン ] (未来世紀ブラジル、バロン他、映画音楽家)

1970.4.15 僕(?)

1971.4.15 [ ジェイソン・ボーン ](ボーン・アルティメイタムで使った暗号)

1990.4.15 [ エマ・ワトソン ](ハリーポッターのハーマイオニー)

4/01/2014

[&] takram academy @s1kun



takram academy @s1kun
「モノづくりと企業づくり」高宮 慎一(グロービス・キャピタル・パートナーズ)
------------------------------------------------------------------------------------
田:takram 田川さん
高:グロービス 高宮さん

田:
高宮さんは、グロービスという会社で投資をされているのですが、
センサーネットワークの専門家や、社会のデザインの話しをしてもらったり、
いろいろなひとの声を聞いていったら、ビジネスの話しをしてもらいたい、
どなたがいいのかな?と思った時に、一番最初に高宮さんがあがりました。

いくつか理由があるのですが、8年くらい前、2007年、当時、
東大経済学部、コンサルティング会社で6年半くらい、
渡米され、ハーバードでMBAを取得されている時に知り合いました。
なんかいか食事しました。まだ takram が2人の時でした。
大学にいきながら、デザインコンティニューでインターンをされていました。
奥様がお花のデザイン系、作る仕事をされています。

僕らの人の繋がりのなかで、クリエイティブとビジネスの両方の話し
をされるのは珍しいのですが、高宮さんにお話ししてもらいます。
両方の視野をいかんなく発揮されていて、カヤック、ゲーム会社、
クリエイティブ系の投資も、日本の中では珍しいですよね。

ランサーズ、メルカリの投資にも入っていらっしゃいます。
モノづくりというのを入れてもらったと思うのですが、
これまで仕事で考えていらっしゃることを教えてもらおうと、
今日は UStream はないので、オフレコのはなしも聞きましょう。
一方的ではなく、質問とかコメントとか出来たらな〜と
僕はここに居て、みなさんとインタラクティブにやりましょう。

今日の皆さんは、クリエイティブデザイン系の方、
takram の皆さん、ビジネス系?の方、
ベンチャーやってますという方。アカデミー系、
僕らが愛すべき方々がオーディエンスで揃っているので、
皆さんから、活発なコメントを交換できれば良いかな〜と思っています。

高:
ご紹介いただいたように、グロービスというところでベンチャー投資をやっています。
イノベーションをどう企業にというコンサルをやっていて、
その家庭で、経営者をどう、その先にデザインが、
学生の頃から、クラブイベントやっていたりしたり、

そんな感じなので、自分の軸としは、
アントレプレナー、76世代ど真ん中なので、mixi, gree みたいな
起業と投資をどうつなげるか。というキャリアを歩んできました。

デザインファームを日本に持ってくるために、
エンジェルを探していて、Design Continuum Japan を作ってしまえ!
ところが 2007年ころからサブプライムローン、リーマンショックで..
デザインファームは一番大企業にとっては、切りやすい部分で、先が見えなくなりました。
セカンドベッドでVCかな〜と思っていて、
クリエイティブマネジメントはないと思っていたのに、
コンシューマー向けの 0〜1 ビジネスの場合、
稀少リソースの天才をどうマネジメントするかが、会社の使命だったりします。
やりたいことをしていったら、6年くらい経ってしまいした。
VCはものづくりやクリエイティブとつながらないと思っていましたが、
ベンチャーでも大企業でも必要となります。

いかに使われるものを作ってユーザーに支持されるか?
100年企業、持続的成長
その間に事業づくり、
良いものを作る、事業価値をつくる、100年企業を作る
3つのレイヤーがある。目線が違ってくる。
一見コンフリクトするところをどう調整するか。

戦略
もの作り、
いかに企業側、事業側から、クリエイティブを込めながらユーザーのニーズにこたえるか。

事業でいうと、収益最大かするのか?
自社的合成、競争環境、市場性

自分たちのビジョンに対してものすごく忠実であるベキかな。と、
主観に基づく。どっちを選ぶ?

特にネット系で面白いイノベーションが起きていると思います。
広告収入か、ユーザーからお金をもらうか。

ビッグデータがホットになっていて、あるユーザーが前に何を買っていたのか?
そのユーザーにあった広告をぶつけていく。
広告枠を広告枠と入札しているクライアントをオープンな市場でマッッチングさせて、
一番お互いとって効果のある、アルゴリズムトレーディングがなされていて、
ビッグデータを分析して効果が高い方になっている。
付加価値が高い広告が回せるようになっているのかな。

都度課金、アプリのダウンロード時課金、
パッケージ課金が、今、非常に下火になってきている。
それに対して起こってきている、

都度課金
サブスクリプション
アイテム課金
機能課金

サブルクシプリョン、死蔵アカウント、使われないまま積上っていく。
本質的なところは、毎月払ってくださいねという「縛る」という対価は何なのか?
サブスクロプションコマース
Shoe Dazzle, Manpacks, Birchbox など
利き酒や、有名なスタイリストの選んだ服、キュレーション、物じゃないサービスの価値を載せてくる。

アイテム課金、社会問題化されましたが、これは結構大きなイノベーションなのかなと思っていて、
基本プレーは無料。時間がない人は、アイテムを都度買って、時間を省く。
射幸心、社会問題化、ユーザーが幾らはらってもいい?
1to1 で値段を決めていった。
ソーシャルゲームだと、100万人、5%の課金、2-3000円払うと、月10億円稼いでしまう。
射幸心をあおって焼き畑をするのではなく、事業としてライフライムを延ばせる

機能課金
クックパッドが良い例。
無料で見れる、レシピを見たいという根源的なニーズは無料、
ランキングごとにソートするにはプレミナム会員でなければいけない。
直接的な価値ではなく、制約を解除するところに課金するモデル。

アイテム課金
10万はらうひともいれば、ただの人も居るし、
Willingness to Pay (支払い意思額)
ミクロでもマクロでも最大の売り上げを上げられるようになっている。

トレンドとして、高いものはいいよねと思い込まされていましたが、
逆に根付けの意思決定をユーザーにゆだねて
ユーザーの感じた価値にいくら払うのか? 

提供価値を考えたとき、提供する方法、
クックパッドでいうと、コアバリューは無料、
提供方法にわざと制限を設ける。
普通に考えると、ユーザーのとってわざと使いにくくしているようなものですが、
ネットの世界でいうと、夢中にさせる。
楽しませておいて、お金を払うようしむける。

Spotify も同じようなサービスかな。
Spotify が面白いなとおもっていたのがあって、
コアバリューは無料で、提供方法に制限をもうけてそこに課金するのは同じ、
PCだと無料、広告は出ますが、
モバイルになると急にプレイリスト作れなかったり、ダウンロードできなかったり、
実感するコアバリューは、コンテキストによって変わってきます。
モバイルにダウンロードして聞けるようにするのは、大きなストレスにならない、
課金メニューに対して、日本でやるとしたら、キラーサービスに課金。
Spotify は北欧から始まっていて、主要先進国にはいっているサービスですが、
国によって、プレミアムサービスで出来ることが変わっている。

Q. あえてフリクションを作るのは難しい、
ユーザーが離れていってしまう。

ものをつくる時、コアバリューは何と考える?
そのものに影響を与えるフリクションは大きすぎる。
Spotify でどこでも聞ける、
曲を探すディスカバリの時に一回 100円とかすると、
そもそも無料版も使ってもらえない。
PC版で気持ち良さを知ってもらって、
コアバリューのところにフリクションを設けてはいけない。

Q. フリクションの設定ポイントは無限にある?地域ごとに違うのはどうやって見いだす?

ネット世界だと、セグメントわけて A/B テストしたり、
実験してみればいい。ラピッドプロトタイピングを高速に回している。
最先端のテストは、ハードの世界にも染出てくる気がしている。

Q. パッケージとアイテム課金の比較で、
払わない人は全然払わなくて、中間層が居ないと思う。

カーブはとても急。2:8 どころか、上位 10%ぐらい、
ゲームのジャンルが成熟してくると、重課金
無料ユーザーに体する優越感、尊敬される、社会的報酬があることで、
課金設定になっている。
課金的には上位の人たちだけで良いように思えるが、賑やかしも絶対いる。
運営者側の意図コントロールできて、
重課金ユーザーに課金しすぎて疲弊されてしまうとダメ、
運営は暗黙値なのですが、ノウハウは提携化できるところ、

サービスは、ローンチした後の運用が大事だと言われるとともに、
ゲームそのもののポテンシャルは、ゲームシステムのデザインだったりするので、
0〜1 の天才の領域もまだ残っている。
全部分析で、実体を引き上げることはできるが、
最初のポテンシャルを上に上げることはできない。

クリエイティブのマネジメントが大事。

Q. 時間軸の話し、ライフタイムバリュー、
学生の立場からすると、
19歳は無料、学生限定で無料とか、Amazon スチューデント、
学生でなくなったとたんに、即入会とか。
それに気づいていても、抜けられない状態。
そういうセグメント分けで、バリューを一時的に体験させて上げるとか。

それも実は、ビジネスの取れる人から取れという理論。
ソーシャルゲームでも女子にもてたいから、アイテムを買ってもてたいオッサンがいて、
30台以上、可処分所得が高い層が、いちばん重課金ユーザーになりやすい。
女子にちやほやされないといけないから、無料ユーザーはF1, F2 が居ないとだめ、
どうユーザーの成熟のパスを辿っていかなければいけないのか考えている。

時間軸を長くしても、いつかは事業が終わるので、次の授業に生まれ変わって
いけないといけないので、
強みを活かしていくのか、次の授業を活かしていくのか、
ネットだと競争が早く変わっているので、
ガラケーのゲームが死んでいって、より広くとらえると、
ネットサービスは、EC の競合や Yahoo 楽天、Amazon
ほんとうの競合はリアルなスーパー、
どこからシェアをとりにいくのか、
そもそも狙っているのはどこですか?
大きな市場で延びているところにのれば1位になれなくて、
伸びていったり。

前者としては、どこで事業するのかが
一番戦略の要素としておおきい。
何をやるのかがビジョンからきている。
思いがある仲間と価値をとどけていきたいなら規模を追わなくてもいいし、
どこでたたかうのか?
モバゲーの会社は、オークションだったのに、モバゲーの先に、
漫画ボックスというアプリや、ショールームというニコ生みたいなアイドルサービスを
作ってきたり、
インターネットをより良くしようということであれば、進化を遂げられるし、
どこで戦うのかは大事かな?と

gree は当初ゲームにこだわっていたので、
DeNAほど、ゲーム事業がさちっていった時に、
ゲームでこだわったときだけに、当たった時の確変は、すごい
何に思いがあるのかで変わっていくのかな〜と

成し遂げないこと
「できることを増やす」nanapi ハウトゥーを積み重ねて
世の中から出来ないことをなくす。毎月 10万記事、

定量的な目標も大事。
1超円企業、1000億円企業か?
世界一になるのか、国内独占をめざすのか、

美学的
クリエイティブ嗜好、数字指向
数字を追うのか、仲良くやっていれば良いのか。
結果指向、プロセス指向、
経営判断、物作りの判断をしていくのは大事。
バラバラになるとちぐはぐになって、世の中的には売れるものを作っても
モチベーションがわかないし、魂がこもったものにならない。

オペレーション上でも
PDCA を回していくのはどこでも同じですが、
事業がヒモづかないものをきりわけると、

Quality / Cost / Delivery
オーバスペックにならず、市場のニーズにあわせてだしていく。

単年度での予算、事業計画
KPIをマネジメントしないといけない。

全社、企業となると、
事業構成、リソースの調達、分配
どんだけ事業にリソースをとうにゅうするのか。

ミートしていないなら、ユーザーにもう一度ぶつけるとか、
全社および事業てきに考えると、
有限なリソースを突っ込んでいるのであれば、

売り上げをあげていく、いちどキャッシュフローが凹んで
そのあと立ち上がっていく。そういう予算や計画を描いていくのですが、
うまくいかなければ?
売り上げはどういう方程式で成り立っていくのか、
何を延ばすのが良いのか?コントロールしやすい指標は?
課金率は、動線を改善すれば良いが、1% が 2% になるだけでも....
PDCA を回していく。

企業というと、企業が目指していくもので、
成長しなければ儲からない事業はやめてしまう。
成長しないけど儲かっている事業もある。
外部から、ヒトカネモノを調達して、どこに配分するか、
目標値を縦長ら推移を見守っていく。

あるプロダクトが縦軸にあります、それぞれにアサインされていて、
職種ごとにプールがあります。
事業のステージによって、アサインされています。

最初はリソースが少なくて、儲かれば人が入っていく。
まずモノづくりにおいては、
割と開発の初期の段階でいろんな視点が入っていること、
ユーザーの視点が入っているのは大事じゃないかな。
売りが経っていない段階でもディレクターがしっかり追うべき KPIの
責任をとりきるのが大事。
売上利益の責任の所在地はどこに?リソースを担保した上に
人事権、誰、権限をもらわないとそれは達成できない。
責任と権限をセットで持たせる。

強みの拡大は重要、
縦割りの中にバラバラにいると、横の職種間の交流はないので、横串で。

縦軸の QCD 責任
自分の縦にいるエンジニアが勉強会で抜けるとか、
短期的なバランスと、長期的なバランス、
今そもそもキャッシュがいいから、長期的な
今はリストラで厳しいので、縦の権限を強化しようとか、
その時々の戦略で変わってくる。
組織の箱を作って人を当てはめていくのではなく。

最後に、コメント

そもそも、一番思うのは、ユーザーに受け入れられるものを作る、
そのもので事業価値が高まるわけではなく、
企業はずっと続かなければいけないので、一事業で焼き畑して事業価値があがるのではなく、
バランシングして、短期的にはコンフリクトしても長期的に考える。

3つのレイヤーをつなぐ共通のビジョン、
どこに向かうか、迷ったらビジョンに立ち返る。

課金のところの話し、コアバリューは実感させて、夢中にさせる。
ネット系では
課金モデルはビジネスモデル、
リアル系のビジネスのヒントにもなる。
3つのレイヤー、視点は違うのですが、
お家芸の、継続的な改善、高速に。
イネーブラーとしての IT, ネットを使うと
リアルタイムで解析できるのでオペレーションのイノベーションが起こる価値。

組織は How である。
箱ありきにしないで、一番合理的に戦略を達成する組織にする。