2/28/2015

[&] 1000 books #74 - Display





「安藤日記の千冊紹介」74冊目は『Display: 2-d and 3-d Design for Exhibitions, Galleries, Museums, and Trade Shows』

展示に関する事例満載の本。二次元(壁)の展示も、三次元の展示も。
博覧会、ギャラリー、美術館、展示会など、55のプロジェクトがとりあげられています。
詳細な設計図とかは無いですが、空間デザイン、インテリア、照明、バナー広告、
ブランディングの考え方、コーポレートアイデンティティの打ち出し方、
インターフェースデザインや、パッケージングまで。
ひと味違った、展示をしたい時にとても役立つ本です。




2/27/2015

[&] 1000 books #73 - Graphic Design Referenced





「安藤日記の千冊紹介」73冊目は『グラフィック・デザイン 究極のリファレンス』

タイトルどうり、いろいろ参照するためのリファレンス本。
歴史と用途と、各種ブランド、世界のグラフィックデザイナーの作品が少しづつまとめられている。
探しものとか、インスピレーションの元になる本。
デザインの原則、タイポグラフィの原則、印刷の原則など、いろいろ載っているけど、それぞれの記載量は少ないです。
こういう本は数年前の本でも全然古びないのがいいところ。
under consideration の本の翻訳本です。


2/26/2015

[&] 1000 books #72 - INFOGRAPHICS



「安藤日記の千冊紹介」72冊目は『インフォグラフィックス』情報をデザインする視点と表現

インフォグラフィックスの例を紹介する本やWebは数多くあれど、
インフォグラフィックスの作り方をちゃんと説明して、学べる本は少ない。

ダイアグラム、表やテーブル、グラフ、地図、ピクトグラムに分けて、
どのように情報を可視化していけば良いのか、具体的な事例を元に、
インフィグラフィックスの第一人者がノウハウを伝授してくれる本。
見せ方の考え方がわかる本です。

人の関心をひきつける
明確にする
簡略化する
流れが人の目の動きに従うこと
言葉が無くても伝わること


[&] WebGL Performance Tuning



( via. Behind the magic of AKQA Winterlands )

#WebGL Performance Tuning

WebGLコンテンツ/プログラムの速度をコツコツと速くするための、
パフォーマンスチューニング観点をまとめました。

まずはプロファイリングが重要。
闇雲にチューニングしても、あまり速くならない場合もあります。
また、最初の設計や、ハードウェア性能を知った上でのデータ量の見積もりも重要です。

■WebGLプロファイリングのコツ

●グラフィックスパイプラインを理解し、どこに時間がかかるか、どこがボトルネックか見極める。
●画面サイズを1/2や1/4にして確かめる(GPU性能か、それ以外が原因か解る)
●目的のハードウェアがどれくらいの数、物量の描画が描けるのか単純なサンプルで限界を測定する。
●機能をON/OFFして確かめる(テクスチャ有り/無しとか、入力操作有り/無しとか)
●JavaScriptが遅い部分と WebGLが遅い部分を切り分ける

■WebGL高速化のコツ:ハードウェアの仕組みを理解して性能をあげる

●CPU-GPU間のやり取りを最小に。事前に計算できることは、できるだけ前処理で計算しておく。
また、GPU側にデータを送り込むような場合は、できるだけまとめて一気に。

●1枚のテクスチャに押し込め、テクスチャコーディネートで使い回す
最近の環境だと、複数テクスチャを bind しておき、切り替えるだけでも高速。
使うたびに毎回読み込んだりするのは極端に効率が落ちる。

●解りやすい結果を得るには Draw Callsを減らす。
むやみに減らすのではなくクオリティとのバランス。減らすとどれくらい速くなるのかを把握しつつ。

●ポリゴンの描き方、描き順を、グラフィックスハードウェアに最適化する。
三角形よりも、四角形が速い環境、または逆の環境もある。
頂点座標の扱いはできるだけまとめてしまう。
連続していないデータでも、ダミーの三角形を挟んで、アレイ化する方法も有効

●WebGL Inspector で繰り返し呼んでいる命令を見つけ削除または、削減につとめる

●WebGLベンチマークで利用するグラフィックスハードウェアの遅い命令、速い命令を把握する

●OpenGL エラーを排除する。デフォルト値が設定されていないとか、範囲外の値を設定したとか、
エラーを皆無にすることで、引っかかりを無くすことができる場合もある。

●WebGL コンフォーマンステストで使えない命令、曖昧な命令を見つけておき、避けるようにする。

●シェーダーはできるだけ分岐判断させない。分岐判断はできるだけ最後に
計算速度の速いシェーダーで代替できないか考える。計算式によるが、単純に短いと速い。
シェーダーの動的コンパイルの時間もあるので、使い回せると速い(と思う。測ってない)。

●ターゲットとなるハードウェアを確認し、EXT命令で活用できるものを探す。
高速化のための拡張命令は積極的に使う。

●GL系、画面データを読み取るのは時間がかかる。
画面のピクセルZ値を取得するなど、get() 系の命令を使うのを控える。
または、ループ外で一気に使うようにする。
ループ内で使うと読むのと書くのと、コンテキストスイッチの切り替えに時間がかかる。

●設定しなくて良いものは、デフォルト値を使う。
何がデフォルト値なのは、決まっているが、まれに初期値が不定なことが仕様の値もあるので注意。

●目標のフレームレートが決まれば、その1フレーム内でどれだけの計算や描画が行えるか計算し、
その秒数内で様々な事象が完結するようにする。30fps 目標であれば、33.3msec 以内。

■WebGLコンテンツの作り方の工夫

●フレームワーク Three.js,GLGE,PhiloGL,SceneJS,SpiderGLは開発速度を上げるけど、
生のOpenGL ES を使うよりは、動作速度は遅くなる。
フレームワーク内部の計算部分など、速度に関するオーバーヘッドもあるので注意して使う。

●テクスチャサイズはクオリティが許せるまで極限まで小さく。
2DのPhotoshop 画面で見ているクオリティと、3D画面内のどこかで使っているテクスチャは
それほど高解像度で無くとも十分な場合がある。

●テクスチャの種類によっては、極限まで圧縮されたJPEGファイルを展開するCPU負荷よりも、
BMPファイルをそのまま使う方が早かったりする場合もある。常に計測。常に臨機応変に。

●テクスチャファイルもヘッダ情報を削除したり、少しでも小さくしておく。便利なツールがいろいろある。

●ハードウェアによってはブレンドが超遅い、並び順序、色順序を考慮しておくと良い。
モデルの描画順序をコントロールしておくのが良い場合もあり。

●古めの環境だと、まれにテクスチャのRGB格納順序で速度が違う環境がある。
考え方としては、画像フォーマットに合わせるのではなく、ハードウェアが最適とするフォーマットに合わせる。

●並行処理、ベクトル演算の考えを行き渡らせる。一緒にできることはまとめて扱う

●イベントループを工夫
requestAnimationFrame() を使う。setInterval() は止める。

●数値計算的なものはJavaScript でやらず、WebGL/GPUに任せる

●模様的なテクスチャであれば、画像よりも、シェーダー生成で。圧倒的にサイズが違う。

●最近は自由なサイズのテクスチャが使えるが、ハードウェア最適化を考えると、
いぜん正方形テクスチャの方が速い場合が多い。常に2のベキ状サイズで考える。

●画面解像度が極端に大きい時はSVGの方がいい。WebGL 以外で実装した方が良い場合もあり。

●視点から近い時には細かく、遠い時には荒く LOD(Level of Detail) という考えは基本。

■WebGL環境の工夫

●ハードウェア環境の OS やグラフィックスドライバを可能な限り最新なものにしておく。
またOSやドライバの環境で、バグや性能が異なることを把握しておく

●画面密度の高い Retina ディスプレイの場合は、
50%サイズで描画して、HTMLで2倍拡大表示しても十分な場合も。

●環境が違うと動かないことを常に考慮しておく。
ブラウザの種類、バージョン、WebGLの設定のON/OFF,
グラフィックスハードウェアのメーカー、チップの違い、OSの違い、メモリ量の違い
シェーダーの複雑度、ドライバの実装の違い、対応しているテクスチャ圧縮フォーマットの違い

●なにかバグを見つけたら、Chrome も WebGL も、NVIDIA,ATI,Intel もどんどんバグレポートすると治るのが早いよ!

●最終ターゲットの主流がモバイル(iOS, Android)の場合は、
パソコン上で開発すると、リッチコンテンツになりすぎて、それを削ってモバイル用にするのは辛いので、
最初から、モバイルターゲットの物量、質感に調整した上で、出来上がったらデータ量を増やしてパソコン用にすると良い。
(AKQA の Winterlands snow.akqa.com がとてもいい例だと思う)

■WebGL関連の役立つツール

●WebGL Texture Tester
http://toji.github.io/texture-tester/
対応しているテクスチャ圧縮方式を一気に確認する方法。画質も確認できます。
WebP, DXT1, DXT2, DXT5, PVRTC, ATC, ETC1



●WebGL Inspector
http://benvanik.github.io/WebGL-Inspector/
Webインスペクターの WebGL 版。必須ツール。
Chrome Canvas Inspector も活用できます。
http://www.html5rocks.com/en/tutorials/canvas/inspection/

●Google Web Tracing Framework
パフォーマンス状況をトレースできるツール
http://google.github.io/tracing-framework/

●WebGL Report
http://webglreport.com/
ブラウザ環境、グラフィックスハードウェア環境を見て、
各種最大値、使える拡張命令などを一気に調べられるツール



●Chrome about:tracing
Chrome に "about:tracing" と書き込み、メータをON にするだけで、
画面右上にパフォーマンスメーターが表示されるように。
FPSやGPUメモリ消費量などを逐一チェックできる。
ただし、WebGL以外の普通の描画でも GPU は使われている。
http://www.html5rocks.com/en/tutorials/games/abouttracing/



■WebGL関連の役立つ動画資料

GDC 2012: From Console to Chrome:コンソールゲームをChrome上で実現!


Google I/O 2011: WebGL Techniques and Performance : 内容はちょっと古いけど基本を知るには良い。



「早すぎる最適化は諸悪の根源である」ドナルド・クヌース
「スマートなデータを使う、つまらないコードを書け」ロブ・パイク

[&] France movie style


(photo (CC) by jeanmichelpignol)

昨日 #uxnama というUX系のイベントに参加していました。
参加者から「フランス映画のようなUXをデザインすることは可能ですか? 」
という質問がTwitter経由でありました。
パネルセッションの流れとは関係なかったせいか、スルーされてしまって、
質問として取り上げられず、その場では解答はありせんでした。
けれども、僕自身、ハッとして、とても考えさせられるきっかけになりました。

単にフランス人でも使いやすいとか、グローバル化されていて万人ウケするとか、
ペルソナがフランス人とかいうことではない、
ブランディングとしての「フランス映画風」とは何か?ということです。
フランソワ・トリュフォー風? リュックベッソン風? はてさて?

少し考えると、アプリとしての世界観を作ることが重要なことは明白です。
色合いとか、フォントとかである程度、「フランス映画風」を醸し出すことはできますが、
それは「風」な見栄えなだけであって「フランス映画のようなUX」とは異なります。

そこで、フランス映画のようなUXとは何だろうと、考えはじめました。
「フランス映画」というキーワードから自分が勝手に想像するのは、
こんな感じです。

●時間がゆったりと流れる、けだるい雰囲気
●起承転結があいまいで、明確なオチが無い物語
●独特のボケ感や、空気感、色使い
●ハリウッドの有名俳優ではない、知らない、個性的なフランス人俳優
●しゃれたセリフの言い回し
●背景がパリ、エッフェル塔などの風景
●その時代の最先端のファッション

ではこれを、実際のアプリとして具現化するにはどうしたら良いのか、考えました。

●アニメーションはスムーズだが、止まるまでに少し猶予が長い。
●明確な目標達成画面!とかは無くて、ナラティブな始まりも終わりも無いような画面フロー
●色使い(基本色、さし色)がフランス風のものをチョイス。いっそグレースケールに、さし色だけ。
iOS8 のような背景が、すりガラス風になるエフェクトを使う
●アプリのキャラクタなどを作らず、有名メジャーアプリ風にはしない。
それぞれのプラットフォームで一般的に使われている操作アイコンを使わず、
ちょっと崩した独自アイコンを使う。線を細くするとか、カーブを増やすとかが有効
●vやf,r,s などを使った小文字だけのアプリ名。L'e とか、e' とか混じるとそれっぽい。
男性名詞と女性名詞があるので、アプリそのものの人格も決めておき、
女性が使う男性人格のアプリなのか、女性が使う女性人格のアプリなのか考える。
フォントも手書き風とか、巻き装飾のある文字とかをピンポイントでまぜる。
●背景画像、背景色は、日常を排除したもので。
●現在流行の色ではなく、来年計画されている流行色を取り入れる。
(パントーンのレポートや、ファッションカラー誌とかでわかる)

なんだか、だんだん面白くなってきた。
アプリのブランディングだけを集中して考えるのもいいな。
この調子で「村上春樹風UXのアプリ」も作ってみたい。

●完璧な完了など存在しない。完璧な絶望が存在しないようにね。
●エラー「馬鹿みたい。見ればわかるじゃない」
●エラー「それはそれ、これはこれ、冷たいようだけど」

[&] 1000 books #71 - GeoGraphics






「安藤日記の千冊紹介」71冊目は『デザインを生み出すカタチ』平面と動画で楽しむ幾何学的視覚デザイン
この紹介を書くまで気付かなかったけど、イギリスの本の翻訳本。
印刷の世界と、モーショングラフィックスの世界の本なのだが、
なかなかどうして、今までに無いタイプのアプリのデザインを考えるのにとても役立つ本。
圧倒的に歴史の長い分野に学んで損はない。結局同じことやっているような気がするから。

Geo / Graphics from Tomas Markevicius on Vimeo.



2/25/2015

[&] #uxnama - UX whereabouts




#uxnama UXデザインの居場所/村越さん

組織の方針で、部署がつぶされるかもしれないという話し....
胃が痛いです。

個人が組織のなかで、どう考えなければいけないのか?
今、Japan Game 事業本部。HCD-net の認定を持っています。
既存のタイトルのユーザーテストと、
新規の企画、UI設計、プロトタイピングを中心にやっています。

グリーは、大規模なネイティブアプリを作るところで、
ライトフライヤースタジオ「消滅都市」300万ダウンロード。
支援しています。

Garage Studio 少人数短期間スタジオ
数週間単位で、切ってスプリントを走らせている。
mg.CUBEはグローバルリリース、
ランキングで調子がいいタイトルです。

プロジェクトマネジメントまで一連のサービスを提供しています。

Sound Design
ゲームタイトルのサウンドトラックを配信
こちらも内製のサウンドチームを持っていて、音も内製で作っています。

●精神論です。
がんばろうぜ!という話しではなく、
どういう精神でやるのか。
みんなに悩みを打ち明けて、僕がすっきりしたいです。

悩めるUXデザイナー
今日登壇した人も基本的に悩んでいます。
「人を動かすことができる人は、他人の気持ちになれる人である。
その代わり、他人の気持ちになれる人というのは自分が悩む」本田宗一郎

UXデザインとは?
広いのです。IAや、インダストリアルデザイン、インタラクションデザイン
全ての領域、解釈で、どうとでも言える。
悩む背景の一つになっちる。

「デザインとは何ですか?」 「設計」と訳される。
「計画」という意味もある。
それをつくること自体もデザイン。
人間の好意をより良いものにかえる。

Google の求人:リサーチも含めて広くやっていくもの
プロジェクトのメンターとして良くやっていくもの。

ある求人:新しいアイデアを作って、プロダクトチームに渡す。
ワイヤー書く仕事だとか。

まちまち。

組織の個性に応じて、求められているデザイン責任が違う。
自分が求められている責任と理想のギャップに悩んでいる。
広いがゆえに、悩む。
求めている理想のギャップに常に悩む。
自分の現場におきかえると全然そうなっていない。

マクルーハン
「人間の作った環境が、役割を決めてしまう。」

そうなると居場所を決める、居場所を作る必要がある。
グリーの中で、1UXデザイナーとしてやっているのは、
自分自身の活動をデザインする。

一年のマネジメントをまとめた生地。
テストの工数を削減して、全社に導入しました。

チームが6人。
基本的には、限られたリソース、
限られた責任からスタート。
ユーザーテキストをできるだけ工数圧縮して、属人化を排除した。
まずはそれを浸透させることをやっていました。
チームの存在が広がってくれば、ナンパの成功確立もあがる。
本当にキモい人扱いされてましたが。

プロトタイプ文化の浸透。そういう活動ができるようになってきた。

UX Tokyo のアドベントカレンダーに投稿した内容。
小さな成功を積み重ねるしかない。
組織における自分の活動自身も製品なので、
それをマーケティングして、営業していく必要がある。



自分HCDサイクル。
それをやっていたら、社内のMVP になりました。
「テストの人でしょ」と言われるようになってしまった。

人が見えるところで、これみよがしに、付箋紙を開いてブレストしたり、
プロトタイピングを強要したり、
皆を巻き込んで、
皆を集めてみたりをやっています。

今は「付箋の人」という感じに変わってきました。
UXデザインとは何ですか?
現状を把握し、自分自身の定義をする。

1. その活動によって、改善される組織課題とは何か?
2. 賛同してくれる人はいるか?
3. 手をとりあえる相手はいるか?
4. 自分自身の役割を定義できるか?
5. 活動に計画性と拡張性があるか?

今やっていることを延々と続けるのは簡単なのですが、
拡張が何年後になるのかを組織にアピールしないと、
「君のチームなんにもやっていないね」と言われてしまう。

エンドユーザーから、ステークホルダーまで周りにいる人の全員がユーザー。
そのデザイン活動によって実現したいことは何なのか?
いいものが作り続けられる仕組みと、良いものが作り続けられる文化に寄与する。

だからこそ、求められている責任と求めている現実のギャップ。
理論ではなく、実践に根をおろす。

「何かを深く信じれば、誰でも自分の中に
大きな力を見つけ出し自分を乗り越えることができる。」本田宗一郎

「僕の前に道はない僕の後ろに道は出来る」高村光太郎

[&] #uxnama - UX first step



#uxnama UX導入はじめの一歩/井上 誠

東京デザイン部マネージャー
HCD-net 認定専門家。

事業背景/ビジネス要件の重要性/UX事情
スムーズな導入のために。

●UX導入は会社の背景ごとに違います。
他の会社ではうまくいかないこともあるかもしれません。
体系化できないのは、そのこと自体が問題。
どうしていいのかわからないという悩みにつながっている。

●DMM.com はどんな会社?
超カオス
グローバルナビ部分が超カオス。
いろいろやっているな〜というかんじはありつつも、
自分たちが良くわからない。

DMM って UX すごいんでしょ?と言われますが、
正直に言うと、UXよりも、ビジネス要件の方が強いです。
UXよりも、スピードの方が重要です。
ユーザーは大事だと解っていますが、
いろいろおさえられてなかなか出来ないのが現状です。

荒波にのまれて、間に合わせないと〜
なんとか乗り越えていっています。

●ビジネス要件はユーザーの敵なのか?
お金儲けではなく、ユーザーを見て欲しい。
UX導入で悩んでいる人にとって、
ユーザーは満足して対価を支払う。
それを円滑にすることが UX。

競合においつきたい。
XX億円達成したい。
社長の意向....

市場調査、競合調査、
プロセス設計、
ユーザー調査、
社長のご意向はどうしようもないですが、
すべては UX につながる。

限られた中でできることからコツコツと。
ビジネス側の信頼をえられるように。

●DMMはUXやっているの?
UXやる人、実は 2人。HCD-net 認定専門家。

仕事風景は..... いちゃいちゃやっています。

二人でやるとなると、辛いので、
チーム化しようと考えています。
どういうことをやろうか?

組織化はトップダウンで会社方針として導入しますが、
会社は変化がはげしいので、
会社方針が変わってなくなるリスクもあったり、
トップダウンでやらされ仕事になるのはどうかな?と

ボトムアップで導入しました。
デザイン部のトップの承認は得ています。

会社方針にとらわれない。
UXで会社に貢献していくのを重要視しています。

導入計画。

1年目:種まき:社内勉強会実施。外部から講師を呼んでワークショップ
話しのわかる人を増やしていく。
2年目:導入事例の増加
3年目:成功事例の増加
4年目:フローとして定着

小さな成果、それにたいして満足した人が信頼してくれる。
それをもとに小さな成果がえられて、大きな信頼に。
どんどんできることが増えて大きくなっていく。
自分たちも、最初は小さな勉強会から始まって。
ユーザーテストを始めたことから、できることが増えていって。

サービス立ち上げ時に UX プロセスを立ち上げることもできました。
小さな成果から始めるのも重要。

●スムーズな導入のために
こういう風にすすめていけばうまくいくんじゃないかな。

●1. 現行のフローからスムーズにつながるように。
「使いにくいな〜」「ちょっとテストしてみませんか?」
UXナンパ?

最初から言ってしまうと、反発をくらう。
初対面な人に結婚しましょうといっても、キモい。
信頼とタイミングは重要。
ひとと人のやりとりなので、基本的。

いっかいキモいと、キモい人認定。
反発が生まれると、挽回するのが難しい。

気が熟するのを待つのも重要。
問題がおこったときに UX がビジネスに貢献する。

開発期間があって、改修期間がありますが、
導入しやすいのは、
要件定義の段階と、改修期間。
開発中は無理しないところ。

ビジョン提案、
改善アプローチ
開発期間はプロトタイピングができて、せいぜい。

●2. いきなり成果を求めない。
UX導入して、ユーザーに受け入れられるサービスができる。
開発者が納得のいく根拠ができる。
自分たちとしては、まず開発者の納得いく根拠ができる。

ユーザーに受け入れられるかどうかは、リリースしないとわからない。
納得いく根拠は、開発中に実感できる。
手戻りが少ないとか、実感ができる。
開発中に実感がえられるのは、信頼されるということ。

●3. 手法にふりまわされない。
いろんな手法が出ています。
いろいろ Web のプロセスに無かったものとかもあって、
これをやること自身が UX かな?とか。
去年一年勉強会をやってきて思ったのは、
手法をやったのに、スムーズにいかない。
やったのによくわからない。
勘違いしていると思っているのは、
回避策が自動的に出てくるものじゃない。

調査 x 分析 = 解決案
こう思っている人がいるが、
実際は、そこに議論を掛け合わさないと解決案がでてこない。

議論がでやすくするためのツールで、
主体は議論そのものにある。
手法を導入することで、声の大きい人にひっぱられるとか、
一度やった議論しなおすこともない。

議論のために必要なこと
手法の勉強
人間に対する洞察力
問いかける姿勢

●まとめ
導入できる信頼をえる
ビジネスに共感する
小さな成果から始める
学習することをやめない

[&] #uxnama - UX survival



#uxnama UXデザイナーの生存確認と最新事情/大塚さん

UX という言葉は定着していて、いろいろな手法が載っていたり、
学習する機会もあると思いますが、
本当はどうやっているのか?
やるのは難しいねという声もあり、
失敗談を共有したり、そういう風にできればと企画した会です。

●UXデザイナーの生存確認と最新事情
ネタバレなんですが、生存確認と言っているのは、
前半自己紹介をしながら、どうやって UX デザイナーになったのかを
紹介しながらお話しします。

HCD-net 人点、
モノテックラボ所属。
なぜ UX デザイナーになったのか?
CD-ROM, 印刷、広告。アートディレクター、
プロマネ、ディレクション。
最終的に UX だなと思って、UXデザイナーになりました。

サイバーエージェントの 10年を並べてみました。
その中で、いろんなサービスを開発していく中で、
サービスの開発は出してみないとわからいな。
ユーザーに受けるのかどうかは、暗闇のなかの跳躍。

ユーザーにとってのゴールとは何か?
開発者にとってのゴールは何か?

これからは UX デザインしかない。JJギャレット。
人間中心設計の資格をとったり、
講師をよんだり、啓蒙活動を続けて、
プロトタイプを作って、アジャイルUCDをやろうとしていました。

初期はうまくいかずに、
開発メンバーに負担、
機能がまとまらない
役割の曖昧さ
などを経験しています。

その結果、
プロセスの導入は火が消えてしまった。
しばらく休眠状態。
じっさいそんなに出来ていなくて、
肩書きも重くて、止めてもいいかな〜と思ったら、

社外の人と話すようになって、
社内の今まで関わっていなかった人と話したり。

諦めていたのは自分だけ、
見渡したらいろいろ変わっていた。

他にも HCDの手法を話す部活。
他にも人間中心設計認定の人が居た。

社内でユーザーテストをどうやっているのか?
案外、普通にやっている。
社員でやるのが普通。
プロジェクトによっては社外からも。
過激なものは 109で声をかけてインタビューする場合も。

横断的な UX チームみたいなのは無くて、
各プロジェクトでやれる人がやっている。

オレもまだまだ行けるのじゃないか。
新しい手法にアップデート

最近取り組みは、

●デザインスプリント
Google ベンチャーズが提唱している、スタートアップ向けの
短期集中型の手法。
5日間でアイデアをまとめ、五日目にテストしてしまう。
背景を話すと、
企画があって、作って、ローンチして改善するのですが、
そもそもの企画が間違っていること、
開発が伸びていってしまうとか、
ローンチする時には疲れてしまって、
失敗したら、改善するのではなく、別のことをやってしまう。
アイデアを検証できる手法。
時間の制限がアイデアにドライブをかけたり、
チームを前進させる力になる。

DAY1: 課題を理解し
DAY2: アイデアをできるだけ出し
DAY3 ベストなアイデアをきめる
DAY4 プロトタイプを作る
DAY5 利用者にみせる

一日に6時間ぐらいみっちり。
マイクロソフトベンチャーズの馬田さんが、Slideshare に上げています。

デザインスプリントをやってみて、良かったこと。
みんなで UI を考える。
チームのシンクロが良くなる。
手法として、ブレストはあまりしない。
アイデアをそれぞれが、いきなり書き始めて、
書いたアウトプットでどうするのか書くので、
意見の強い人、面白い発言に寄ることがなく、
全員の意見が検討される。

サイレントクリティーク、
丸いシールで、投票していく。
この時、しゃべらずに、意見に影響をうけずに、投票していく。
そこから話しをして、最終的にどれにするか。
アイデアをしゃべると時間がかかる。
話したいと思っているところにはなせる。
自分のアイデアを通したい。
取捨選択をフラットに出来る。

もう一つ、プロダクトオーナーに入ってもらうのが重要。
あとでひっくり返されることが無い。
そのプロセスをやることで、皆のマインドをシンクロさせることができる。

早い段階で試して学習する
仮説検証プロセス。
早い段階で失敗できる。失敗から学べる。
このサイクルを何回もやっていかないと、いいものができない。
ブラッシュアップを何回かやっていくうえで、製品化していく。

デザインスプリント、これをユーザーテストとセットでやらないと、
こんな簡単にきめてもいいのか?という不安がありますが、
仮のテストだとして、どんどん前進してけます。

●プロトタイピングプロセス
プロトツールがいっぱいでてきています。
今日 Goodpatch さんがきていますが、Prott のようなツールを使っています。

以前はペーパープロトでしたが、
ゲームだと画面数が多くて大変でした。
僕しかやらなくて、
めんどくさくて大変でした。

プロトツールだと、実機で確認しやすいですし、
簡単なので、開発の流れをかえたかなと思っています。

アイデアの検証を素早く、
チームの認識もあわせることができました。

●UXは計測する。
「ユーザーエクスペリエンスの測定」
やっている事はけっこう簡単で、
調査票を作って、数値入力しているだけなのですが、
アンケートを作っています。

やる前とやった後でどうだったか記入してもらっています。
数値化したり、グラフにできるので
それを持ってチームに反映する。

テスト結果の表現は、その後のチームの行動をかえる。

50%の人が失敗しました。
事前、事後と乖離があるとレポートした法が
チームの気持ちをかえる。

臨機応変に。
あきらめず、継続する。

UXは複雑かもしれないが、
単純な環境と仕組みがその複雑なことを反映できるのではないか?
ハーバートサイモン

仮説検証をできる環境で
体験を「指向」できるチームをつくること

[&] Books for Founders (Japanese version)


Product Hunt が薦める、スタートアップが読むべき16冊
http://www.producthunt.com/e/books-for-founders

■日本語化されている本■をリストにしてみました。
●日本語訳がまだの本●は狙い目ですよ!(→出版社の方々)

Founders at Work 33のスタートアップストーリー
イノベーションのジレンマ―技術革新が巨大企業を滅ぼすとき
話す技術・聞く技術―交渉で最高の成果を引き出す「3つの会話」
荒野へ (集英社文庫)
Venture Deals: Be Smarter Than Your Lawyer and Venture Capitalist
→日本向け 起業のファイナンス 増補改訂版 ベンチャーにとって一番大切なこと
Not Fade Away: A Short Life Well Lived
まぐれ―投資家はなぜ、運を実力と勘違いするのか
パックス・モンゴリカ―チンギス・ハンがつくった新世界
人はだれでもエンジニア―失敗はいかにして成功のもとになるか
ビジョナリーカンパニー4 自分の意志で偉大になる
インナーテニス―こころで打つ!!
インテル経営の秘密―世界最強企業を創ったマネジメント哲学
The Score Takes Care of Itself: My Philosophy of Leadership
限界を突破する5つのセオリー: 人生の大逆転を生むスマート思考術
ダイアネティックス 心の健康のための現代科学
破天荒な経営者たち ──8人の型破りなCEOが実現した桁外れの成功







2/24/2015

[&] 1000 books #70 - MOE Magazine






「安藤日記の千冊紹介」70冊目は『雑誌MOE (モエ) 2015年3月号エドワード・ゴーリー特集』

全世界の一部、ゴーリーファンにはたまらない本です。特集は少しだけですけど。
マサチューセッツ州にある亡くなる前に住んでいた自宅は「ゴーリーハウス」として公開されていて、
特集の中でもとりあげられています。絵本の世界観そのまま!

なんかこの独特な感覚から、イギリス人だと思い込んでいたけれど、
この特集読んでアメリカの人だったことを知った!
ゴーリーの目には、僕らが見えているものと違うものが見えていたような気がしてならない。

[&] 1000 books #69 - Notes on Teaching




「安藤日記の千冊紹介」69冊目は『教えることの覚え書き』

いろんな覚え書き本を出しているラッセル・ライシと、
教師のシェリー・ヘンドリックスが組んで書かれた本。

184のアドバイスが載っています。
何かを教えるための心構えと、
現場で役立つ手法がいろいろと載っています。

● 教師の役割/すべての問題に答えを出す必要はない
● 計画と準備/本質的な問いを見極めよ
● はじめての授業/生徒がすでに知っていることから始める/達成感を味わわせよう
● 生徒に期待する/失敗を肯定せよ
● 教室でのルール/悪いところを、悪く言わずに教えてあげる
● 教室という舞台を演出する/教室全体を使いなさい
● 基本的なスキルを授ける/言葉のルールと美しさを教えなさい
● クラスをリードする/「失望」を「発見」に変えよ
● 「問い」を使って学ばせる/多様性を大事にしなさい
● 悩みの種/意表をつくやり方で、寛容さを示そう
● 生徒への接し方/生徒が気づいてほしいことに気づきなさい
● 保護者への接し方/まずは質問しよう。言いたいことを言うのはそのあとだ
● フィードバック(講評)の伝え方/知的好奇心を高く評価しよう
● 成果を称える/「賞」を設けよう
● 職場での心得/80%解決したら、それで満足しなさい


2/23/2015

[&] 1000 books #68 - BRAND sense



「安藤日記の千冊紹介」68冊目は『五感刺激のブランド戦略』

ブランド戦略の重鎮マーチン・リンストローム氏の著作。
10年前の本なのだが、この分野ではいまだこれ以上の本が無い気もする。

各種有名ブランドは、ブランド構築のために、五感をいかに刺激しているかという解説。

例えば、
●既存の感覚のタッチポイントを活用する:ディズニー
●感覚タッチポイント間のシナジー:シンガポール航空
●競合他社より先を行く感覚の革新:アップル
●感覚の一貫性:シャネル
●感覚の真性さ:ロレックス
●ボジティブな感覚所有:ノキア
●感覚タッチポイントすべてにおける継続的進歩:ナイキ
●ブランドを破壊する:コカコーラ

後から当てはめたように思えるけれど、実際は綿密な戦略が練られていることがわかる。
なんでもかんでもやれば良いというわけではなく、
有名ブランドほど、軸がぶれずに、ブランドイメージを構築していることが良くわかる本。



2/22/2015

[&] Tokyo Demo Fest 2015 - Implementing a practical rendering system using GLSL



Implementing a practical rendering system using GLSL
Toshiya Hachisuka
http://www.ci.i.u-tokyo.ac.jp/~hachisuka

17年前から、CGを勉強していますが、
デモシーンに出会ったのがきっかけです。
ソフトウェアラスタライザを書いていました。。
なので、この場で発表するのはとても光栄です。

GLSL で実践的なレンダリングソフトウェアを書くとどうなるか?
GLSL はレイマーチングによって、RayTracing があたりまえになりました。
映画のレンダリングにも使われて初めています。
GPU デモの簡単なレイトレーシングはものは沢山のサンプルがあります。

映画のような物理的に正しいレンダリングをする知識はあまり共有されていない。
レンダリングの複雑性があがるにつれて、共有される知識が少ない。
この領域を考えると、実用的なレンダリングシステムを書くには重要な事柄が共有されていない。

こういうシーン、物理的に正しいシーンを三角形メッシュでテクスチャをはったようなものを 1分でレンダリングするには?

●まず、なんで GLSL なのか?
CUDA とか OpenCLの方がいいのじゃないか?

クロスプラットフォームであること、
Battle tested, 古いものなので、ドライバが良く成熟している。
簡単にシェーダーが書ける。
複数の GPU を使うおうとすると、結構面倒。でも GLSL を使うと、SLI, 複数のGPUでも高速化される。
でももっとも重要なのは「楽しい」から。

●二つの重要な機能
Bounding Vlume heierarchy (BVH)
CPUを使ったレンダリングシステムで使われているもの。
物理的に正しい計算をするために、光の計算をする必要がある。

●Bounding Volume Hierarchy
実用的なシーンをレンダリングするとなると 100M とかあるので、
ひとつ一つやっていると、実質レンダリング終わらない。
アイデアとしては、4つ三角形があったとすると、
2つのペアに対してバウンディングボックスを用意して、
その二つを囲むようなバウンディングボックスを作る。
そうすると階層構造ができる。
普通なら4つの三角形に対して衝突判定しなければいけませんが、
簡単にできるようになる。

●Stochastic PPM
蜂須賀手法;
3つの方法で光のシミュレーションをします。
フォトントレーシングという、光源から乱数を使ってレイトレーシングします。
フォトンという点群のが使いとして、格納します。
カメラからレイトレーシングして、どこに交差したのかみつけ、
交差した点で、密度推定します。
3つのステップで計算します。
全体として、CPUとして、BVH を使って、
それを使って高速なレイトレーシングを行います。
Photon Tracingy , Eye ray tracing, Density estimation
フォトンを累積して累積して計算します。

●Design Principles
並列な処理ができるような処理にすること
ひとつひとつの並列な処理を均質な処理になるようにすること。
ローカルメモリ, GPU のタスクごとに使われるメモリをなるべく使わない。

ここで使われるのは、趣味で書いたレベルなので、
実際の映画の製作に使うには無理があるかもしれません。
こういう風に作っていけばプロダクションレベルのレンダラーが作れるのではないか。

●挑戦
CPU を使ったレイトレーシングは、再帰を使う、スタックを使う、メモリが消費される。

スタックを使わない構造。
最近の GPU だとスタックが使えるし速い場合もある。
しかし、スタックのサイズで、どれくらい並列化されるか決まってしまう。
32kb/512 くらい、最高でも 64個のレイしか計算できない。
今後並列度があがっていった時に足りなくなるかもしれない。

スタックを使わない方が未来があると考える。
どうやってスタックを使わないで、木構造を探索するのか?

Threaded BVH
あらかじめ計算しておいてそれを利用する。
木構造の Hit link を計算しておく。
ヒットリンクは、トラバーサルする時にヒットすると、たどるリンク。
ミスリンクは、ヒットしなかったら辿るリンク。
最終的に、ターミナルに行き着いたら探索を終了。

木構造を計算してしまえば、木構造を保存しなくても、
探索ができます。

ヒットリンクの場合は、隣りにいき、
ミスリンクの場合も3つのルールにしたがって、自動的に計算できる。
変換するのは比較的簡単。
探索が非常に簡単になる。
バウンディングボックスに当たっているのか、当たっていないのかだけを判断するもの。
すごい簡単なループで探索計算ができます。

ヒットリンクとミスリンクは、トラバーサルの順番が固定になっています。
ヒットリンクとミスリンクで計算して、たまたま、トラバーサルすると、
最初のトライアングルにヒットすると、後ろにあるトライアングルは計算しない。
なるべく近いバウンディングボックスからトラバーサルしたいという基本。

+X,-X, +Y, -Y, +Z, -Z 6つの方向に対して、ヒットリンクとミスリンクを作る。

+X、Xがポジティブ方向にすすんで居るとして、
X = 6.0 と、X = 2.5 だと、順序を交換してあげて、
ヒットリンクとミスリンクを作る。
最終的にはデータは、バウンディングボックスのデータと、6つのヒットリンク、ミスリンクの構造になります。

ヒットリンク、ミスリンクは、
vec4 に格納できて、
小さくコンパクトにまとめられます。

トラバース自体のコードはほとんど変わらない。
レイの方向によって、どこからスタートするかを決める。
あとは全部同じ。
スタックは使わないし、まったく同じように動く。

レイトレをする時は、レイと三角形との交差判定を行います。
面白いことに、CPU でやる既存の方法は、CPUの SIMDとかで作られていて、
CPU上で速いとされているものが GPU で速いとは限りません。
CPU上で速い方法をやると、逆に遅くなったりします。
最終的に、おちついたのは、このコードです。

レイトレを書くと、レイと三角形の交差を書くと、分岐がたくさんありますが、
分岐を最後にまとめて、一回だけやると早くなります。
CPUだと分岐を早めにやるのが良い。
GPUだと実際はスキップされないので最後にやるのがいい。

前計算でやっておく方がいいと言われているが、効率が悪いので、
GPU の場合は、前計算しない方がいい。

位置を3つストアして、法線ベクトルが正規化されている前提でZは+-だけ。

NVIDIA の人がチューニングした方法とくらべて半分以上の値が出ている。
通常のBVH よりも3倍くらい速い。

Aila 09 は NVIDIA の GPU 用にチューニングされているものの半分くらいなら結構良いのではないか?

●もともとの6つのリンクを持つのでオーバーヘッドが多いのではないか?
他に比べて、実際リンクを持っても 1.5倍程度しか増えない。実験より。
そんなに悪くないんじゃないか。

この方法が唯一の方法ではなく、研究ではいろいろな方法があるのですが、
ほぼ全て実装して比較したところ、今回の方法が速いことがわかった。

ビット操作でトラバーサルする方法や結構遅い。

●ダイナミックなシーンは?
頑張れば GPU でも動く。

レイトレを高速化できたら、フォトントレーシングをどうするか?
それぞれのピクセルについて、光源からランダムにレイトレーシングしながら進める。
ここで難しいのは、それぞれのピクセルに対してランダムな光の経路がわりあてられるので、
反射回数がすごく多い場合と、凄く少ない場合があり、
計算負荷が一様でない。

乱数を使って計算するのですが、デモとかで使っている乱数を使うと酷いことになる。
統計的にいい乱数をつかわないといけない。

光源からレイを飛ばして、次にどうなるかを決めるとなると、
一つのピクセルについて、次にバウンスさせないという決定をしたときに、
他のピクセルの計算が終わるのを待たなければいけないので、計算効率が落ちる。
フォトンというのはヒットした点について生成するので、
フォトンが複数個生成されていまうと、
GPU でリストを作らなければならず、面倒なことになる。

最初の問題については、非同期にフォトンの計算をすることによって効率を上げることができる。
反射回数をピクセルで持って、0回反射している場合は、新しく光源から。
0の数を数えると新しくフォトンが発生したものがわかる。
計算が終わったピクセルは、他のピクセルを待たないで、新しい計算ができるように。

比較すると、反射回数を非同期にすると、反射回数をあげてもパフォーマンスが落ちない。

乱数について、Fract(sign(...)) は高速だが、乱数としての性質はあまり良くない。
本当にランダムな結果が欲しい。
結構難しい話しで、二つ問題があって、
ひとつは乱数の性質がいいものをつくらないといけない。
GLSL の整数演算をサポートしていない環境でできないといけない。
大抵の乱数発生アルゴリズムは整数前提。



GPGPUフォーラムがあって、そこに誰かが匿名でポストした方法があったのを
GPU に書いたもの。なぜこれがうまくいくのか全く解っていない。
基本的な演算は5行で、fract sig よりもかなりいい。
でも、なんで動いているのかわからないので、気持ち悪い気もする。

GPUを使った乱数生成はけっこう研究されていて、
複数の方法があるのですが、

LCG というスタンダードな方法、
実はあまりうまくいかないので、おすすめしない。
暗号化ハッシュを使う方法があって、それは結構うまくいく。
GPU Mersenne Twister は高品質なのですが、かなり遅い。
xorshift など。

●Eye ray tracing
フォトントレーシングを同じ、最後にヒットしたら、そこで計算がストップするので、
そこで計算をストップできる。どこに交点があるのかを見つけるだけ。
実際交点が見つかったあとは、密度推定を行う必要がある。

交点のまわりに球をつくり、その中に何個フォトンがあるのかを計算して、
密度計算をします。CPU上でやるのは簡単なのですが、
GPU 上でやると、問題がある。
フォトンはランダムに生成されるので、CPU上で作ってやればいいのか?
毎回転送すると、遅すぎて使えない。
GPU上でデータ構造を作りたい。

たまたまフォトンが大量に合った場合、計算がヘビーになる。

空間ハッシュを使うという方法。
フォトンが沢山あった場合、グリッドに切って、
グリッドの点に対して、それよりも少ないハッシュテーブルを作り、それを使う。
GPU 上でハッシュを作る方法はいろいろありますが、
1pixel ごとにテクスチャなどに格納する。

球に対して重なるグリッドにたいして、それぞれのグリッドに対してハッシュを計算して、
球の中にフォトンがあるかどうか計算してみつける。
これはすごく高速に動作します。

二つ問題があって、
ハッシュを作った時にリストを作らなければいけない。
ハッシュを使うので、リストが長くなったり、短くなったり、
長い場合に計算時間が長くなってしまう。

●Stochastic spatial hashing
蜂須賀手法。ランダムに一個のフォトンをキープする。
統計的に正しい結果が得られる。
普通だとリストを作らないといけないが、この方法では、どれが書き込まれたのは無視して、
最後に書き込まれたものをキープしている。
一応何個書き込まれたかというカウンターはあるが、
その分だけフォトンの明るさをスケールする。
これをやると実際のフォトンを探すのではなく、ハッシュテーブルに対して、一回だけ読み込めば良くなる。

実装が簡単で、
ハッシュを計算して、書き込んで、カウンターで数えるだけ。
実際に GPU を使って比較すると、
構築時間も速い。読む時間はほぼ同じか、若干速いくらい。

木構造で高速化する方法もありますが、
それと比べても 3倍から10倍。
CPU との比較。

密度推定、二つの問題を完璧に解決できる。
パーティクルの密度を計算する時などに使える。

テクスチャを持つ時に、なんとなく1つのテクスチャとして作りたくなりますが、
テクスチャの数が限られている。
違うテクスチャにアクセスすると条件分岐しなければならなくなる。

ボリュームテクスチャに全部突っ込んでおく。
アホな方法に見えますが、非常に速く動きます。

デモの人は CPU の利用率を気にしないかもしれませんが、
普通に GPU を使い切ると、CPU も 100%になってしまう。
これを回避する方法は、GPU上で処理が終わったか?をピクセル数を数える関数があって、
それを使うと、CPU 負荷が減ります。

面白い方法として、
普通 32bit の浮動小数点で計算する。
実は 16bit だけ持っていれば、結構なシーンが格納できて、速い。

GLSL はクロスプラットフォームですが、
これは理想的な話しで、OpenCL と比べるとかなりマシ。
NVIDIA, Intel, AMDどれでもちゃんと動く。

GLSL の mod はあるバージョンの NVIDIA ドライバでは変に動く場合がある。
Intel のドライバーの方がいい場合がある。
while ループを使うと NVIDIAのドライバでは動かない場合がある。
break を使うと動くようになる。

まとめ:
Multiple threaded BVH
Asynchronous path generation
PRNG usning only floating point numbers
Stochastic hashing

[&] 1000 books #67 - 100 Graphic Designers of the World



「安藤日記の千冊紹介」67冊目は『世界のグラフィックデザイナー100』

1994年の本なので、約20年前の本なので、印刷の質とか古い感じは否めないですが、
内容自体は全然古びない、資料としても大切な本。
もちろん最近活躍しているデザイナーは載ってないのはあたりまえなんだけど、
SAUL BASS とか、Siegfried Odermatt とか、すごい好きなデザイナーがいっぱい。
グラフィックデザインという職種が無かった頃から、この領域を切り開いてきた先人達だから、全然古びない。
もしかしたら、20年後の「世界のグラフィックデザイナー」本(電子書籍かも)があったとしても、
ほとんど変わらないような気がする。
ここに載っているデザイナーに教わったり、一緒に仕事できた人たちも幸せだと思った。