こんにちわ、フォースを信じてる鈴木です。 ネクストでは、業績目標を達成したご褒美に全従業員参加の社員旅行をします。 会社の成長とともに参加者が増え、4回目の2015年は海外子会社も含めて500人超が参加をしました。今回は、そんなネクストの一大行事の裏側で活躍したクリエイターの日と開発チーム「teamぼんじり」についてお話ししたいと思います。 課題がたくさんある社員旅行 さて、500人が参加する社員旅行。もちろん旅行代理店の方にお願いはしていますが、旅行の企画や運営は社内の12名の実行委員が主体的に行っています。 参加者の方には集合時間や旅行行程、座席や部屋の番号、アクティビティの案内などをお知らせする必要があります。 昨年まではそれをパワポで作成、名簿含めて実に39ページという大作の旅のしおりを配布するという運用をしていました。 このかさばる紙のしおり、旅行のときには荷物になる、必要な情報が探しにくい、情報の更新や修正ができないと、参加者にも運営にも大きな負担となっていました。 Teamぼんじり結成 そこで、登場するのがクリエイターの日です。 ネクストの クリエイターの日 とは、希望するクリエイターが業務時間の10％（1Qで最大7日間）を使って、特設プロジェクトの提案を行い開発をすることができるクリエイターにはうれしい制度です。 今回はそのクリエイターの日の実行委員に相談をし、開発をしてくれるメンバーを募ることにしました。 募集をかけたところ、自ら手を上げてくれたのがエンジニア2名、デザイナー1名。 そこにディレクターの私、 プロダクトオーナーのチバちゃん が加わり、さらにインターン1名が追加されて、teamぼんじりが結成！ （インターンは2016年入社予定のエンジニアで、今回は特別にいっしょに開発体験をということで参加をしてもらいました。） ここから、ふだん仕事では関わったことない「はじめまして」のメンバーでの活動がはじまります。 ユーザーの課題はなにかを考える クリエイターの日で活動できる時間は限られているので、活動期間前にはランチの時間などを活用してチームビルディングとプランニングを行いました。 途中でプロダクトオーナーからのチーズケーキの差し入れなんかもあり、即席チームいい感じ。 私の方からは最低要件を伝え、みんなでつくるものを考えていきます。 ここでは、インセプションデッキをつかったりしました。 チームでなにをどうつくるか、私はせっかくクリエイターの日を活用するし、ふだんの仕事ではできない遊び的要素を組み込んでもいいかなと思っていました。 しかし、そんななかで「社員旅行の間にたくさんの人が使うものだから問題解決型のプロダクトにしたい」と声を上げてくれたのがデザイナーでした。 なんたる、あっついデザイナー魂！！！そう、私たちはユーザーのためにプロダクトを考えなくては！ この意見にTeam全員が合意、今回のプロダクトでは過去の体験談をもとに、どんな課題をどうやって解決するかをしっかり考えて開発することになりました。 開発したWebしおりとは？ ここでは開発したプロダクト「Webしおり」について、 小屋横に住まう エンジニアの横山より紹介をしたいと思います。 静的なページではなく動的ページを 「私の部屋は何号室？ 誰と一緒だろう？」「帰りのバスは何号車だったけ？」 紙のしおりだった頃は500名分のマトリックス表の中から自分に該当する項目を探しだすのは、一苦労。。。 おそらく、数分はかかっていたでしょう。そんな悩みを解決したのが今回の目玉である”マイページ機能”でした。 単にしおりをWeb上に載せるのではなく、旅行中の閲覧に最適なスマートフォン用に開発し、動的なページとしてローンチさせました。 マイページ機能の他には、英訳切り替え機能、ログイン機能を作成いたしました。 スクラップアンドビルドしていた紙媒体ではなく、インフラ構築さえしておけば、また来年にも再利用でき、製作コストを下げられます(`ω´)ｷﾘｯ （といっても、限られた期間内では最低限の機能しか作りこめませんでしたので、あまりここでは触れないこととします。） 予算は1万円 今回インフラからの構築というわけで、AWS EC2を使ってWebサーバを構築いたしました。 インフラ構築及びサーバーサイドの実装担当に1名、フロントエンドの実装に1名という体制で進めました。 このPJ、開発期間、人数も限られておりますが、予算も限られております。 開発期間中、夜中はインスタンスを落としたり、ディスクI/Oを発生させないためキャッシュさせたり等、可能な限り予算内に収まるよう設計いたしました。 開発期間：1週間、ローンチ後運用期間：2週間　で以下のような結果となりました。 使用インスタンス：t2.micro 平均CPU使用率：0.5% CPU使用率ピーク時：5.5% 開発及び運用期間でのインスタンス稼働時間：816時間 総費用：$26.04 AWSを利用することでよりお金のことを意識させられたり、運用面のトラフィックやCPUをウォッチしたり等、分業化された普段の業務では中々味わえない経験ができたかと思います。 活動限界までブラッシュアップしました Teamぼんじりの活動期間の最終日にちょうど 第1回 創民祭 がありました。 ネクストの創民祭はクリエイターの日や個人での活動などの成果報告をみんなで楽しもうという社内イベントです。 活動時間だけではなく、プロダクト発表の場も用意されているなんてなんたる機運。もう、これはエントリーするしかないじゃない！と実は開発開始より前のめりにエントリーしていました。 クリエイターの日とはいえ、やらなければならない通常業務。社内用とはいえテストに手心は加えないエンジニア、活動終了1時間前にメインビジュアルにスライダーを開発しちゃうデザイナー。 エントリーまでは、まさかここまでの怒涛の開発をするとは思ってもいませんでした。 どこまでもどこまでもきっちりやりきるのがTeamぼんじりです。 そんなわけで発表準備もままならないまま持ち込んだ創民祭でしたが、なんと優勝いただいちゃいました！ 派手さや、技術的な真新しさなどはないプロダクトでしたが、ユーザーの課題をしっかり捉えた点がきちんと評価されたのではないかと思っています。 Fin そうして社員旅行も無事に終えたTeamぼんじりは、創民祭の優勝賞金で打ち上げ費用をきっちりゲット！おいしく焼き鳥を食べましたとさ。 めでたしめでたし。 （Teamぼんじりの名前はメンバーの好きな焼き鳥からつけました） 企画から開発、打ち上げまで自発的に行動を起こし、実行できる。 ネクストにはそんなクリエイターがそろっています。

こんにちは、ウェッブデザイナーのアズマです。 みなさん、Sassは好きですか。僕は好きです。 そして、寿司は好きですか。僕は好きです。 Sassがあれば何でもできる！ Sassがあれば、回転寿司も回せる！ というわけで、今日はSass(CSS)を使って回転寿司のように要素を無限ループさせてみましょう。 何ができるか こうです。寿司が無限ループしています。(本当はもっとなめらかに動きます) 僕の圧倒的な画力についての感想はここでは本質ではないのでご遠慮願います。ここで大事なのは寿司が無限ループすることです。 「画像が流れればそれでよい」ということであれば、 1枚の横長背景画像にしてbackground-positionを動かす という手法や、いっそのこと 全部Gifアニメにしちゃう (寿司ゆき超かわいい)という手法もありますが、 例えば「今後要素の数がちょくちょく増える予感がある」とか「できるだけセマンティックに作りたい」とか「なんか負けた気がする」などといった理由で背景画像にはしたくない、そんな夜もあるはずです。 ただ寿司が回ればいいのか？ 否、回すなら美しく回さなければならない。そうでしょう？ 回しましょう、今宵、美しい寿司を。 ==== 完成形のコード というわけでSassの出番です。 寿司の個数に合わせて数値を計算したり、CSSで要素ごとにアニメーションを設定しようとすると日が暮れてしまうので、Sassで一気に作っちゃいましょう。 まずHTMLはこうです。何の変哲もないリストですね。ちなみに回転寿司は英語でsushi-go-roundです。本当です。 < ul class = "sushiGoRound" > < li >< img src = "img/ebi.jpg" alt = "えび" ></ li > < li >< img src = "img/ikura.jpg" alt = "いくら" ></ li > < li >< img src = "img/maguro.jpg" alt = "まぐろ" ></ li > < li >< img src = "img/shimesaba.jpg" alt = "しめさば" ></ li > < li >< img src = "img/tako.jpg" alt = "たこ" ></ li > < li >< img src = "img/tamago.jpg" alt = "たまご" ></ li > </ ul > そしてSassはこうです。 // 寿司を回すための変数を設定 $itemTotal : 6 ; // 寿司の総数 $speed : 50 ; // 寿司の速度 $duration : ( $itemTotal * 100 ) / $speed ; . sushiGoRound { position : relative ; overflow : hidden ; width : 500px ; height : 100px ; padding : 0 ; background : url( 'img/bg.jpg' ) ; border : 1px solid #333 ; li { position : absolute ; width : 100px ; height : 100px ; list-style : none ; animation: slide #{ $duration } s linear 0s infinite; } li img { width : 94px ; height : 94px ; border : 3px solid #fff ; border -radius: 50% ; box-shadow: 0 3px 6px rgba ( 0 , 0 , 0 , 0.1 ); } // 寿司の動き $offset : $itemTotal * 100% ; @keyframes slide { 0% { transform: translateX( 0 ) } 50% { transform: translateX(- $offset ); visibility : hidden ; } 51% { transform: translateX( $offset ); visibility : hidden ; } 52% { transform: translateX( $offset ); visibility : visible ; } } // 寿司ごとのずらし @for $i from 1 through ( $itemTotal ) { li:nth-of-type( #{ $i } ) { $delay : #{ ( $i - 1 - $itemTotal ) * ( $duration / $itemTotal ) } s; animation-delay: $delay ; } } } $itemTotal(寿司の総数)はお手元の寿司の数に合わせて各々入れてください。 $speed(速度)は50〜100ぐらいが適当です。あまりに遅いといわゆる「寿司が止まって見える」状態になります。 へへっ…俺には寿司が止まって見えるぜ… 何をしているのか 大まかな流れとしては、 寿司を全部同じ位置に配置する 寿司をループさせて動かす 寿司の動きにズレを加える となります。だんだん寿司とは何か、わからなくなってきましたね。哲学的な問いです。 1. 寿司を全部同じ位置に配置する 今回はul.sushiGoRoundが寿司のレーン、その中のli要素がそれぞれの皿にあたります。 まずはみんなお馴染みposition: absoluteで、li要素を全部重ねてul要素の端に配置してしまいます。 . sushiGoRound { position : relative ; overflow : hidden ; width : 500px ; height : 100px ; padding : 0 ; background : url( 'img/bg.jpg' ) ; border : 1px solid #333 ; li { position : absolute ; width : 100px ; height : 100px ; list-style : none ; } li img { width : 94px ; height : 94px ; border : 3px solid #fff ; border -radius: 50% ; box-shadow: 0 3px 6px rgba ( 0 , 0 , 0 , 0.1 ); } } 2. 寿司をループさせて動かす 準備は整いました。さっそく寿司を回しましょう。 …と、その前に、寿司の総数と速度を設定する変数をそこら辺に入れておきます。 // 寿司を回すための変数を設定 $itemTotal : 6 ; // 寿司の総数 $speed : 50 ; // 寿司の速度 $duration : ( $itemTotal * 100 ) / $speed ; li要素に animation: slide #{ $duration } s linear 0s infinite; を指定し、適当なところに以下を追記しましょう。 // 寿司の動き $offset : $itemTotal * 100% ; @keyframes slide { 0% { transform: translateX( 0 ) } 49% { transform: translateX(- $offset ); visibility : hidden ; } 50% { transform: translateX( $offset ); visibility : hidden ; } 51% { transform: translateX( $offset ); visibility : visible ; } } ここで何をしているのかというと、こういうことです。 要は、6つの寿司をぶつからないように、かつ変な間が空かないようにぴったりループさせるには、 1 寿司を初期地点から6つ分左に動かす(0%〜49%) 2 寿司を初期地点から6つ分右に瞬間移動させる(49%〜50%) 3 寿司を初期地点に戻す(51%〜100%(0%)) というアニメーションを絶え間なく続ける必要があります。これを行うためのコードです。 ここでのポイントは、1の動きと3の動きが同じ距離であることです。 これによって回転寿司のレーンのような美しい等速直線運動が生み出されます。 3. 寿司の動きにズレを加える // 寿司ごとのずらし @for $i from 1 through ( $itemTotal ) { li:nth-of-type( #{ $i } ) { $delay : #{ ( $i - 1 - $itemTotal ) * ( $duration / $itemTotal ) } s; animation-delay: $delay ; } } 以上のコードでは寿司ごとにアニメーション開始タイミングのズレを発生させています。 ここでのポイントは、delayにマイナスの値を入れていることです。 animation-delayがプラスの値だと寿司が動き出すまでに時間がかかりますが、マイナスの値を入れることによって、「既にx秒動いた状態」から開始されることになります。 これによって、結果的に各寿司があるべき場所に配置され、なめらかに動き出すというわけです。 何の役に立つのか いかがでしたでしょうか？ 「Sassで寿司なんて回して一体何の役に立つんだ、働け」という声が聞こえてくるようですが、 先日HOME'Sからリリースされた新サービス 「暮らし図鑑」(スマホ用) のトップ画面では、かわいいキャラクターをこの回転寿司メソッドでくるくる動かしてディスプレイしています。(残念ながらイラストを書いたのは僕ではありません。) 「狭い画面で、たくさんの要素を、邪魔にならないように見てもらう」という目的に対して使える手法ではないでしょうか。 ちなみにこの「暮らし図鑑」、 約200人 から集めたライフスタイルやリアルな生活事情をもとに人々をタイプ分けして、自分と似たタイプの人の引っ越しを見られることで、 ユーザーがじゃぶじゃぶ引っ越したくなるような住み替え心を煽るサービス となっておりますので、ぜひお試しください。そして引っ越したくなってください。 www.homes.co.jp   弱点 「たった一つの」とか言っておいてアレなんですが、この回転寿司メソッドにはまだ「寿司の間隔調整が難しい」「寿司の数が変わるたびに変数を手で差し替えないといけない」などの弱点があります。 「俺ならもっと美しく寿司を回してみせるぜ！」という方はコメント欄などからアドバイスいただけると嬉しいです！それでは、よき寿司を！

Apple原理主義者の大坪です。 前回 は「tvOS上でアプリを作ろうと思ったらFocusのパワーを身につけなくちゃね」と言ったところでおしまい。今回書くのはそのFocusのパワーがアプリのデザインに与える影響について。 ちょっとまて、貴様のような生活に疲れたエンジニアがデザインについて何を語るというのだ、という声がどこからか聞こえますが気にしません。いや、最近耳が遠いもので... 「題材」にするのは、Youtube 上の動画をだらだら眺めるのが目的のアプリです。 iPad版はこんな感じで動きます。あれやこれやと機能がありますが今回対象とするのは、動画の下に流れている関連動画リスト。 ずらずら並んでいる関連動画を好きなだけ左右にスクロールして興味をひく動画のサムネイルを探す。サムネイルを上にスワイプすれば再生される。表示を「お気に入り」とか「履歴」とかにしたければ画面右下に並んでいるボタンを押す。 こうしたやり方自体そう変わったものではありません。しかし同じ機能を「さてtvOS上で実現しよう」と考えると最初の一歩からつまづくことになります。「左右に自由にスクロール」というのがまずtvOSではできない。もちろんスクロールはできますが、それはフォーカス移動にともなってポチポチと移動するだけ。 さらに リストを切り替える際の「ボタン操作」も困る。iPad版では切り替えのためのボタンがあちこちに存在していますが、tvOS上のアプリで操作できるのはフォーカスが存在するところだけ。つまり「タップに反応する領域」をあちこちに配置すると「何をするにも山ほどカーソルを移動させなくてはならない」ことになる。じゃあどうするか？どうもtvOSで発生するエラー（APIが微妙に違うので）を治すだけではなく、デザインに立ち戻って考える必要がありそうです。 こういう時は、３０分ほど現実逃避した後に、ぐっと画面を眺めて考えましょう。 そもそもここの操作とか表示はどうあるべきなのか？tvOS上のアプリの特性を考えながら以下にずらずらと書きます。 *1 iPad版では全ての画像に文字が重ねて表示されている。なぜならばユーザはどの画像でも瞬時にアクセスできるので。ところがtvOSではフォーカスが当たっているものしか選択できない。ならば全部の画像に常に文字を表示しておかなくてもよいかもしれない。 そもそもTV画面上に文字がやたら表示されていると鬱陶しく感じる。 フォーカスがどの画像にあたっているかは何かの手段でユーザに教えてあげる必要がある。 リストの切り替えをボタンでやっている限り、ユーザの負担は減らない。ここは上下左右のカーソル移動でなんとかできないか こういった事情をあれこれ考えた末、tvOS版の動きはこうなっています。 リストの中で文字を表示するのは、フォーカスがあたったものだけにしました。これによりフォーカスがあることをフィードバックするとともに画面上がごちゃごちゃするのを防いでいます。 さらに リストを「お気に入り」とか「履歴」とかに切り替えるのにはフォーカス移動を利用します。リストにフォーカスがあたった状態からさらに下にフォーカスを移動させようとした時、リストの内容を順繰りに変化させる。こうした方法をとると、直接「履歴がみたい」とかはできなくなるわけですが、あれですよ。昔テレビってそういうものだったじゃないですか。今では死語になった「チャンネル」を回すと順繰りに番組が変わる。ここで操作しているのは「テレビ」なんだからあれでいいだろう、と力強く納得するわけです。納得しますよね？ね？ね？（焦点の合わない血走った目で延々と繰り返す） とかなんとか書いてきて 最初に「聞こえないフリ」をした問いに戻ります。なぜ私が生活に疲れたエンジニアの身でありながらtvOSアプリのデザインについて書こうとしたか。tvOSはその機能こそiOSと似通っていますが、その上で動くアプリケーションの体験はiOS版（iPhone or iPad）のそれとは異なるものであるべきです。なぜならばデバイスが異なり、操作方法が異なり、それを使うユーザの姿勢が異なるから。 そう考えれば、tvOSと新しいApple TVの登場はまたまた起こった「よーいドン！」ではないかと考えることもできる。つまり誰も正解を知らない世界の扉がまた開いたのです。 iOS上で初めてアプリ開発が可能になった時、今ではほとんど使われなくなったいろいろな手法が試みられたことを覚えています。今同じようなことが（小規模に）起こっているのではないか。であれば、いろいろなことをトライし「なんだこれは」「おっと、この手があったか」と喜んだり悔しがったりできる。今回私が使った方法も数年後には「笑い話」になっているかもしれません。しかし今ならドサクサに紛れてあれこれ語っても怒られないかもしれない。いや、楽しい。 *1 : 以下にあげたものの他に、動画の画像は勝手に動いていくので画面からフォーカスが消えてしまっても困る。画面の端にきたら自動的にフォーカスを移動させなくてはならない、という厄介な問題がありますがここでは省略しています。

こんにちは。HOME'SのiOSアプリチームの新卒1年目の塙です。 新卒入社して早9ヶ月、時間が過ぎるのは早いですね。 Swiftを導入するまで タイトルからお察し頂けるかと思いますが、つい最近まで弊社のiOSアプリは全てObjective-Cという"最先端の言語"で書かれていました。 しかし昨年Swiftが公に発表され、今年にはメジャーアップデート、さらにはオープンソース化されました。 swift.org 私はこの波に乗っている新しい言語で書きたい気持ちが一杯でした。 ただ、4年間に渡ってユーザの皆様のご要望に基づいて様々な機能を追加していった秘伝のタレに、アップデートの激しい新言語を取り入れるのは、メンテナンスの手間を考えるとGOサインを出しにくかったと思います。 そんな中、我々のリーダーが勇気ある決断をしてくれました。 「塙君、次の機能なんだけど、新しい機能だからSwiftで書いてみない？」 この言葉を聞いた時に、NOという選択肢は頭の中にありませんでした。 Objective-Cとの共存 まず、既存のプロジェクトにSwiftを共存させる上での必要な作業をざっと調べました。 SwiftからObjective-Cを使用する場合 ① $(PRODUCT_MODULE_NAME)-Bridging-Header.h を作成 ② 上記ファイルにSwiftで使用するObjective-Cのヘッダファイルをimport #import <GameFeatKit/GFController.h> #import "NSObject+Empty.h" ③ ターゲットの[Build Settings] → [Objective-C Bridging Header]に上記ファイルを指定 ※ 初めてSwiftファイルを追加する際には、上記1〜3の設定が全て自動で行われます Objective-CからSwiftを使用する場合 ① $(PRODUCT_MODULE_NAME)-Swift.h を対象の .m ファイルにimport(ヘッダファイルにインポートするとコンパイルエラーになる) #import "YourProduct-Swift.h" $(PRODUCT_MODULE_NAME) はデフォルトで $(PRODUCT_NAME) $(PRODUCT_NAME) のデフォルト値は $(TARGET_NAME) もし $(PRODUCT_NAME) に . や - がある場合は _ にリプレイス ※ $(PRODUCT_MODULE_NAME)-Swift.h はXcodeが自動生成し、ファイル内の変更は一切必要ありません 互換を保つために気をつけること サブクラスと属性の付与 Objective-CからSwiftクラスを呼び出す場合 Objective-Cクラスのサブクラスとして定義 上記以外の場合は @objc属性を付与すれば名前の変更も可能 これらを行うことで自動的に $(PRODUCT_MODULE_NAME)-Swift.h に追加される class MySwiftClass: NSObject { // implementation } @objc(MySwiftClass) class 私のスイフトクラス: NSObject { // implementation } ※ パフォーマンスとSwift移行の為にも必要な場合以外はネイティブベースを使用する方が良いです コンバージョン Objective-Cの変数を型変換してSwiftで使用する場合 // CGFloat型をFloat型に代入するにはコンバージョンが必要 myFloat = Float(cgfloat) ダウンキャスト Objective-Cの変数を型変換してSwiftで使用する場合(派生クラス) // NSDictionary型をDictionary型に代入するにはas演算子でダウンキャストが必要 myDictionary = nsdictionary as Dictionary<String , AnyObject> Enum Objective-C側で NS_ENUM を使用すれば、Swiftからenumとして呼び出せる typedef NS_ENUM(NSInteger, Fruit) { FruitApple, FruitOrange, FruitGrapes }; Swiftで呼び出す際には以下の内容に変換されます enum Fruit: Int { case .Apple case .Orange case .Grapes } ※ メンバの接頭語はSwiftで使用する際に自動で省略されます 互換性のないもの Swiftで定義したジェネリクス タプル Int以外のrawValueを使用したEnum Swiftで定義した構造体 Swiftでトップレベルで宣言された関数 Swiftで定義したグローバル変数 タイプエイリアス Swiftで定義した可変引数(var) ネストされた型 カリー化関数 ユニットテスト Objective-Cで書かれたユニットテストは $(PRODUCT_MODULE_NAME)-Swift.h をインポート不可(ターゲット内で使用可能の為) SwiftコードのユニットテストはSwift(別ファイル)で記述(Objective-Cのフレームワークを使用する場合はインポート可能) 上記を頭に入れ、Swiftでプログラミングを行うのは特に労力のいるものではなく、案外すんなり動いてくれたので拍子抜けでした。 ※ 実際のプログラミングではSwiftで書く時間よりも、既存のObjective-Cで書かれた箇所の改修に時間がかかりました(泣) Swiftの恩恵 現在では、基本的に新しい機能の追加をする際にはSwiftで書くようになっています。Swiftを使用することで下記のような恩恵を受けることができます。 型安全なコードによってnilが入るなどのよくあるクラッシュをコンパイル時に防止 記述方法がシンプルになったことでコード量の削減 Swiftネイティブ(enum、struct)の型を使用することで柔軟なプログラミングが可能 実際の実装の中で感じたのは、enumにprotocolを準拠させたり、getterでパターンマッチさせる方法はとても便利でした。 protocol Color { var color: String { get } } enum Fruit: String, Color { case Apple = "apple" case Orange = "orange" var color: String { switch self { case .Apple: return "Red" case .Orange: return "Orange" } } } 最後に 書き方に慣れない、コンパイル時間が長いなど少なからず不満はあるとは思いますが、それ以上にSwiftという新しい言語に挑戦できる環境というものはエンジニアにとってこの上なく嬉しいものだと思います。 是非、この記事を読んだiOSアプリエンジニアの皆さんは自社のプロジェクトがObjective-Cで進んでいた場合、とりあえず新しい機能や、書き直せるものからSwiftを導入してみることをお勧めします。 参考文献 Using Swift with Cocoa and Objective-C (Swift 2.1): Swift and Objective-C in the Same Project Using Swift with Cocoa and Objective-C (Swift 2.1): Writing Swift Classes with Objective-C Behavior SwiftのENUM - Qiita SwiftとObjective-Cの相互利用する際の注意 - Qiita

あけましておめでとうございます。 おうちハッカー@リッテルラボラトリーの石田です。 画像から何かを検出したい、ユーザーの動きに連動して何か作りたい、なんて思うことがあると思います。 そんなときに、どんな技術を使えばよいのか迷うと思うのですが、そんなときに検討すべきライブラリ、API、デバイスを紹介したいと思います。 画像処理といったらlennaさん オープンライブラリ系 こちらはソースが公開されている画像処理ライブラリで、自分で組み合わせて適切な処理を作成します。 ライブラリによって得手不得手があるので、単独というより、組み合わせて使うことが多いと思います。言語はC++, Pythonがメインになります。 OpenCV OpenCV | OpenCV 画像処理といったらこれ！という定番ライブラリです。 動かせるプラットフォームも、windows,mac,Linux,Android, iOSと幅広いです。PCではC++,Pythonで書くことができます。 基本的に商用利用可能ですが、一部アルゴリズムは非商用のものがありますので、お気をつけてください。(SIFT, SURFなど) どんなことができるのかは、こちらの動画を見たほうが早いかと思います。 www.youtube.com dlib dlib C++ Library 最近注目され始めているライブラリです。 特定の物体の検出器の作成の簡単さや精度がOpenCVのそれよりもよいとの評判です。 使い方に関する情報が少ないので、やや苦戦するかもしれません。 OpenCVとdlibの、顔検出のサンプルコードの比較動画です。 青がOpenCV, 赤がdlibのようです。OpenCVのほうは誤検出が多いですね *1 www.youtube.com 各種機械学習フレームワーク 写真に写っているものが何なのか、クラス分類を行うのに近年、いわゆるディープラーニングの手法であるCNN(Convolutional Neural Network)を用いた判別機が成果を上げています。 こちらを簡単に実装できるライブラリに、以下があります。どれも基本はPythonです。 名前 特徴 Pyleran2 初期のディープラニングライブラリ Caffe 画像に強い Chainer 国産ライブラリ TensorFlow Google製でGoogleサービスで使われてる CNNを用いることで、 おそ松さんのような見分けづらいものの判別機 を作ることもできます。 有償API系 こちらは主に、機能は限定されますが実装いらずで画像認識を行うことができるAPIです。 コールごとにお金がかかります。 Google Cloud Vision API Google Cloud Platform Blog: Google Cloud Vision API changes the way applications understand images 最近発表されたばかりのAPIです。現時点ではLimited Previewなので、登録者のみお試しで使えます。 お試し版の情報を公開することができないので、現状では公式の動画およびGoogleの人が書いたこちらの記事で性能を伺うことができます。 www.youtube.com qiita.com Orbeus ReKognition API 画像を送信すると、人の顔の認識から、動物、景観、建物などの情報を返してくれるWEB APIです。 「オブジェクト認識」と「顔認識」の2つがあるようです。SDKも充実しており、PHP,Ruby,Objective-C, C++などに対応しています。 デモはこちらで見られます。 www.rekognition.com IBM Watson Visual Recognition IBM Bluemixで使うことができる機能で、画像のクラス分類を行うことができます。 用意されている分類機のほかに、自分で画像を用意して任意の分類機を作成することができます。 www.youtube.com デモがこちらで閲覧できます。 Visual Recognition Demo その他API そのほかにも、多くのAPIがあります。 一般画像認識API List of 14+ Image Recognition APIs - Mashape Blog 顔検出系API List of 10+ Face Detection / Recognition APIs, libraries, and software - Mashape Blog デバイス系 カメラとセットになった画像処理デバイスです。 デバイス内で大方の画像処理を行ってくれてその結果を簡単に利用することができます。人の動きのリアルタイムの処理に向いており、インタラクティブなコンテンツの作成を簡単にできるものが多いです。 Microsoft Kinect マイクロソフトが出しているセンサデバイスです。通常のカメラのほかに、赤外線カメラ、深度センサを搭載しています。主に人体部位の3次元位置情報や深度、ジェスチャーを計測するのに適しています。 現行のものは、Xbox one用のKinectにアダプターを介して、WindowsPCに接続することができます。 www.xbox.com どういったことができるのかは、こちらによくまとめられています。 www.naturalsoftware.jp Intel RealSense インテルが出しているセンサデバイスです。Kinectと同様のセンサ類を搭載していますが、Kinectよりも近距離での顔の状態やジェスチャーに優れています。 主にPCへの組み込みを想定されており、組み込まれたPCでのイメージはこんな感じです。 www.youtube.com また組み込みだけでなく、個別のデバイスとして、WindowsPCで利用可能です。 こちらに主要機能がまとめられています。 www.buildinsider.net オムロン OKAO Vision HVCシリーズ OKAO Vision｜技術紹介｜オムロン人画像センシングサイト：＋SENSING オムロンが出している、顔や人の認識に特化したカメラです。RealSenseよりもさらに顔に特化しており、 顔検出、顔認証、性別・年令推定、笑顔度推定、表情推定、顔向き・視線推定などができます。 BlueTooth接続でスマホからも簡単に使えるタイプ(HVC-C)と、 組み込みの基盤タイプ(HVC-P)があります。 公式ページより、使える機能が確認できます。 plus-sensing.omron.co.jp 最後に 画像処理には様々な手法がありますが、それぞれメリットデメリットがありますので、仕様用途に適した手法を選択することが重要です。 画像処理系は、成果が見えやすくやってて楽しいので、ぜひお試しください。 *1 : この点はOpenCVの検出器のパラメータ次第で改善できるとは思いますが。

こんにちは、おうちハッカー@リッテルラボラトリーの石田です。 先日より弊社は、 「HOME'S」の物件・画像データセットを研究者に提供開始しました。 情報学研究データリポジトリ(IDR) より申請頂けます。 こちらのデータセットを用いた研究を支援させていただくため、ディープラーニングによる画像分類器の学習と、テキストマイニングをお試しいただけるツールキットを提供いたします。 GitHub 本記事では主に、画像解析ツールで行うことができる、ディープラーニングを用いた部屋画像の分類を紹介します。 ディープラーニングで物件画像の分類 公開されたデータの中には、約8,300万枚の物件画像データが含まれています。それらの画像には、間取り、外観、玄関、居間、キッチン、トイレなどの画像種別が設定されています。 こちらの画像を教師データとして学習を行い、部屋画像を入力として与えると、どの種類の部屋なのか判定する分類器をディープラーニングのフレームワークのChainerを用いて作成しました。 ツールキットを用いることで、簡単に研究を始めることができると思います。以下にその手順を示します。 動作環境 Linux (推奨: Ubuntu 14.04 LTS 64bit または CentOS 7 64bit) Chainer 1.5.1 (推奨) GPU利用環境 (CUDA 6.5, 7.0, 7.5) HOME'Sデータセットの利用申請 HOME'Sデータセットは国立情報学研究所(NII)のご協力を得て研究資源として提供させていただいております。研究の用途に限定させていただいているため、 情報学研究データリポジトリ(IDR) より申請をお願いいたします。1～2週間でデータセット提供用ページよりダウンロードしていただけます。 Chainerのインストール Linux環境での Chainer v1.5のインストールをお願いします。画像枚数が大変多いため、GPUの利用を強くお勧めします。 Chainer自体のインストールは容易ですが、GPU演算のためのCUDAのインストールは、多くの方がよくつまづかれる部分です。 公式ドキュメント 通りにしていただければよいかと思いますが、よろしければ こちら も参考にしてください。 Chainerのインストールが終わったら、MNISTのチュートリアルを実行することをお勧めします。 ツールキットの入手 HOME'Sデータセットから、Chainerに含まれるImageNet用の分類サンプルソースを用いて分類器を学習できるよう、ツールキットを用意しています。下記の通り、GitHubリポジトリからcloneまたはダウンロードしてください。場所はどこでもよいのですが、本文書では、データセットディレクトリ配下にcloneする前提で進めます。 (cloneする場合) cd /path/to/dataset/directory git clone https://github.com/Littel-Laboratory/homes-dataset-tools.git (ダウンロードする場合) https://github.com/Littel-Laboratory/homes-dataset-tools/archive/master.zip データセットの展開 本データセットに含まれる物件画像データファイル (photo-rent-NN.tar.bz2) は、tar.bz2形式で圧縮されているので、展開作業が必要です。展開用のツールを用意していますのでご利用ください。 cd /path/to/dataset/directory ./homes-dataset-tools/imageKit/extract_photo.py ./ 物件画像の展開にはかなり長い時間がかかります 全画像ファイルを展開する場合は、概ね1TBytes以上のディスク領域が必要となります。 画像のファイル数がかなり多い (約8300万枚) ため、ディスクの容量とともにinode数をかなり消費します。inode数を多めに確保してフォーマットしてください。 上記を実行すると、データセットディレクトリ内のphotoディレクトリ (/path/to/dataset/directory/photo) に物件画像ファイルが展開されます。 物件画像ファイルは物件と対応づけられています。物件IDは16進数32桁の数字です。物件IDを元に画像ディレクトリが生成されます。画像は0001.jpgから順に番号が振られています。 例: 物件IDが0123456789abcdef0123456789abcdef の場合、この物件IDの画像は photo/01/23/456789abcdef0123456789abcdef に格納されています。 画像は、 0001.jpg 0004.jpg 0007.jpg 0010.jpg 0014.jpg 0017.jpg 0002.jpg 0005.jpg 0008.jpg 0011.jpg 0015.jpg 0018.jpg 0003.jpg 0006.jpg 0009.jpg 0013.jpg 0016.jpg といった形です。 また、本ツールキットでは物件画像のメタデータ (画像種類タグ) を学習に用います。 photo_rent.tsv.bz2を展開してください。 cd /path/to/dataset/directory bunzip2 photo_rent.tsv.bz2 訓練データの準備 ImageNetのソースを利用して学習させるために、データセットを加工します。 具体的には、 画像のパスとタグ（種類）のリストの作成 画像のリサイズ 平均画像生成 を行います。 画像パスとタグのリスト作成 リストは、以下のようにスペース区切りで画像パスとタグを記述したものです。今回使用するタグは、画像に付けられた画像タイプです。 (例: 1=間取り, 11=居間, 12=キッチン) 00/00/03d67c168129876425c22a106dae/0003.jpg 1 00/00/180a3c6848b723749e1dc9cd4b12/0030.jpg 3 00/00/11fe05aa3585e929b34d887b2dbe/0007.jpg 10 00/00/081549d99cf1e3f5be593e560799/0004.jpg 11 00/00/081549d99cf1e3f5be593e560799/0005.jpg 12 00/00/081549d99cf1e3f5be593e560799/0006.jpg 15 00/00/11fe05aa3585e929b34d887b2dbe/0009.jpg 16 00/00/11fe05aa3585e929b34d887b2dbe/0010.jpg 17 00/00/11fe05aa3585e929b34d887b2dbe/0011.jpg 18 00/00/03d67c168129876425c22a106dae/0014.jpg 19 学習には、以下の２つの独立したリストファイルが必要となります。 train.txt: 訓練用データ test.txt: テスト用データ これを作成するには、ツールキットのmake_train_lists.pyを実行します cd /path/to/dataset/directory/homes-dataset-tools/imageKit ./make_train_lists.py ../../photo_rent.tsv すると、各タグの写真のパスがtrain.txt, test.txtにそれぞれ10,000枚、1,000枚づつ含まれたリストが生成されます。また同時にリサイズすべき画像リストresize.txtが生成されます。 make_train_lists.py のオプションで枚数を変更したり、写真をピックアップする際のオフセットやインターバルを変えて、異なる訓練セットを生成することもできます。この枚数で大きく学習時間が変わってきますので、もう少し早く結果を見たい方は、--trainphotos, --testphotosオプションで枚数を減らしてください。詳しくは、 ./make_train_lists.py --help でヘルプを参照してください。 画像のリサイズ ImageNetのインプット画像サイズは256*256であるので、先ほどリストに追加された画像のリサイズを行います。 ./resize_photo.py resize.txt ../../resized_photo/ 平均画像生成 最後に、訓練データから平均画像を生成します。 ./compute_mean.py train.txt --root ../../resized_photo/ こちらを実行すると、 mean.npy というファイルが生成されます。 これでImageNetでの学習に必要なデータ一式の準備は終了です。 ImageNetで学習 学習 ツールキットの train_imagenet.py で学習を始めます。 Chainer附属のImageNetと少しだけコードを変えてあります。変更点としては、保存する形式をCPUでも読み込めるようにしているだけです。 ./train_imagenet.py train.txt test.txt -g 0 --batchsize 32 --val_batchsize 100 --epoch 300 --root ../../resized_photo/ | tee log こちらを実行すると学習が始まります。 *1 {"iteration":100,"loss":2.735,"type":"train","error": 0.846875} {"iteration":200,"loss":2.167,"type":"train","error": 0.7709375} {"iteration":300,"loss":1.963,"type":"train","error": 0.719062499} {"iteration":400,"loss":1.898,"type":"train","error": 0.6765625} {"iteration":500,"loss":1.880,"type":"train","error": 0.664374999} {"iteration":600,"loss":1.814,"type":"train","error": 0.6396875} {"iteration":700,"loss":1.770,"type":"train","error": 0.61687500} {"iteration":800,"loss":1.781,"type":"train","error": 0.620937499} {"iteration":900,"loss":1.754,"type":"train","error": 0.60375} {"iteration":1000,"loss":1.740,"type":"train","error": 0.60187499} ・ ・ 枚数が多いので、AWSのGPUインスタンスを利用した場合でも、初期設定の13万枚の学習データで300epochの学習で丸2日かかります。 結果を早く試したい場合は、epochを減らすか、学習データ枚数を減らしてください。 300epoch学習させると、エラーレートはこのように下がっていきました。 なおグラフ作成には、Hi-kingさんが公開している補助スクリプトを利用させていただきました。 chainerで画像分類するための補助スクリプト · GitHub 訓練データでのエラーレート テストデータでのエラーレート 訓練ではずっと下がり続けていますが、テストデータでは、50000イテレーション以降で16%前後で変わらない結果となりました。 学習済みモデルでテスト 学習が終わった後は、modelというファイルが生成されています。use_model.pyを用いて作成したモデルにてクラス分類を行います。 ./use_model.py /path/to/bukken/photo ちゃんと居間として認識されています。 タグ スコア 居間 99.972% 設備 0.028% 風呂 0.000% トイレ 0.000% 100%キッチンの結果に。 タグ スコア キッチン 100.000% 地図 0.000% 設備 0.000% バルコニー 0.000% こちらは玄関の靴を入れる収納スペースなのですが、どちらとも言えない画像なので両方のスコアが高くなっています。 タグ スコア 収納 41.396% 玄関 37.067% 設備 21.536% キッチン 0.000% 考察 学習させたモデルの精度が85%程度であることの原因は、画像に対して適切なタグつけが行われていない、また重複するタグを持つ画像の扱いにあると考えられます。先の玄関の靴箱の写真の例では、訓練データ内の同様の写真の正解データは、玄関であったり収納であったり設備であったりします。この訓練データを使ったことにより、複数のスコアが高く出てしまうようです。 ですので、数字としての精度を高める場合には、例えば「玄関収納」など、写真のタグの分類をより細かく行い、複数のタグにまたがる状況を減らす方法が考えられます。 最後に このように、簡単に分類器を作成できます。ツールキット自体は申請せずとも使うことができますが、ディープラーニング関連研究をお考えの方は、ぜひ申請してお試しください。 *1 : 見やすくするためにログを多少加工しています。

Apple原理主義者の大坪です。未だにスターウォーズのForceと聞くと「理力」という訳語が頭に浮かぶ私はかなり年をとっています。 いきなり何を言い出したかといえば、あれですよ、新しいApple TV。素敵ですよね。日本にいながらアトランタやノースカロライナのローカルニュースを見られるなんて...（以下Apple TV礼賛が数千行続くが省略） しかしながら 「わーいApple TVたのしいぞー」と喜んでいる場合ではない。iOSでコードを書く身であれば、その上で動くアプリケーションを作らなければならない。（断言） Apple TVでアプリを作るには主に 二つ方法がある ようです。しかしマークアップランゲージが苦手で、WPFでプログラムを書くときですらXAMLを避けるような私にとって選択肢は"Traditional App"しかないでしょう。iOSと同じ 「ような」 フレームワークを使ってごりごり書くのです。 しかし 書き始めると上の行で「ような」が巨大になっている理由を理解することになる。似て非なるものとまではいいませんが、tvOS上でのアプリ開発はiOS上でのそれとはかなり異なっている点がある。今回はその中で一番大きなものの一つである"Force"じゃなくて"Focus"について書きます。 iOSでアプリを作っていると忘れてしまいますが「画面の任意の場所をユーザが直接操作できる」というのは偉大なことです。これはタッチパネルなしにはありえない。 ではiPhoneが登場する前はどうしていたか？ガラケー上でアプリを作っていた時のことを思い出しましょう。十字キーでもって画面上のハイライトしている部分を動かし、決定キーを押す。何かが実行される。つまりユーザが意図している場所はどこなのか？ということをハイライトで示していたわけです。 さて、あたりまえですがApple TVを接続したTVの画面をタッチしても何も起こりません。操作するためにはSiri Remoteなるリモコンを使う必要がある。そこにはTouch Surfaceがついていますが、ここで直接画面上のボタン等を指定できるわけではない。ガラケーでのハイライトに相当するものは、tvOSではフォーカスと呼ばれています。Touch surfaceをすいすいやることでフォーカス移動し、しかるのちにポンと押す。あたかもガラケー時代に先祖返りしたかのような感覚が味わえます。 つまり tvOSでアプリを作るということは、このフォーカスと付き合うことでもある。さて、ここで問題です。Touch Surface上であれこれ操作した時フォーカスはどう移動するのでしょうか？ 答え：Focus Engineの御心のままに Focus Engineとは、tvOSでフォーカスの移動を全て司っているUIKitの中のシステムです。我々プログラマーにできることは 「ここにフォーカスを移動させてもらえませんかねえ？」 とお願いすることであり、その結果何が起こるかは Focus Engineの心次第。もちろんFocus Engineは乱数に従ってフォーカスを移動させているわけでは（多分）なく、画面上に配置された部品から「当然考えられるように」移動させるわけです。しかし Appleの開発者向けページ に"Debugging Focus Issues"なる項目があるのは故のないことではない。tvOS上でアプリを作ると、ここに書いてあるデバッグ方法を何度も実行することになります。ええい、なぜフォーカスがこの部品に移動しない！と呪いの言葉を吐きながら。 というわけでtvOS上でのアプリ開発第一歩として、「とにかくフォーカス移動させてみる」というのをやります。サンプルプログラムを Github に置きました。機能はほとんどないのですけど、最初の一歩はこういうシンプルなものがいいですよね？ね？ね？（血走った目で懇願） ダウンロードして実行してみましょう。Apple TVのアプリといえば、画面の上からにょろっと出てきたり引っ込んだりするタブバー。というわけで無駄にUITabBarControllerを使ったUIViewControllerの切り替えも実装しています。 さてここで問題です。このタブバーの出し入れはどうやっているでしょう？ 答え：Focus Engineの御心のままに 細かいことは 省略します が、とにかくコードの方では何もやっていません。タブバーにフォーカスが移動すればバーがにょろっと出る。Viewにフォーカスが移動すれば引っ込む。わーい自分で何もしなくても動いてくれてうれしいな、と言っていられる期間はそう長くないかもしれません。 さて、次の問題です。First Tabと書かれたタブの項目を選ぶと赤い画面が表示され、Firstと書かれたボタンにフォーカスが当たる。位置関係からして「まあ当然だな」と思うわけですが、場合によってはSecondと書かれたボタンに最初にフォーカスが当たって欲しいこともあるでしょう。どうすればそれができるか？ 答え：Focus Engineにお願いする 大事なことなので２度書きますが、ここでできるのは「お願いする」ことであり「命令する」ことではない。その結果何が起こるかを決定するのはFocus Engineなのですが、とにかく「お願い」してみましょう。FirstViewController.swiftをみると16行目からこんな部分があります。 // override weak var preferredFocusedView: UIView? { // return secondButton // } わざとらしいコメントアウトを外し、再度実行するとこんな風に動きます。（First Tabという項目上でタップしています） タブバーが引っ込んだ時、Secondと書かれたボタンにフォーカスがあたっています。 ここで何が起こっているか？Focus EngineがFirstViewControllerにpreferredFocusedView（フォーカスを当てて欲しいView）は？と聞き、それに対してsecondButtonと答えているわけです。これによりめでたくタブから"Second"と書かれたボタンにフォーカスが移動する。 ちなみに、ここでFirst Tabにフォーカスがあたった状態から下にスワイプすると、前と同じようにタブバーが消え、Firstボタンにフォーカスが移ります。なんだこれは？と問うてはいけません。 *1 これは 仕様 です。First Tab上でタップされた時は「そもそもどっちの方向に行こうとしているかわからない」のでpreferredFocusedViewを尋ねてくれるわけですが、スワイプだと「ああ、下に行きたいわけね」とそのすぐ下にあるViewにフォーカスを移す。preferredFocusedViewに何を書いておこうと、聞く耳持たないわけです。いや、ちょっと待て、それは困る、というのならばFirstボタン自体がフォーカスを受け取れないようにしておいて、一旦Secondボタンにフォーカスが移った後にフォーカス可能にする...とかやりだす。ふと気がつけば足元にフォー"カ"スの暗黒面が大きな口を開けていることに気がつく。 かくのごとく tvOS上でアプリを作ろうとすれば、どこかでFocusの使い方-お願いの仕方-と向き合う必要がある。Star Wars Episode Vで、フォースを身につけるためルークはヨーダを背負ってあちこち走り回っていました。同じような厳しいトレーニングをするのは自由ですが、そうしてもApple TVのフォーカスを思うように動かすことはできない。 素直にボタンを格子状に並べておけばフォーカスについて悩むこともないのかもしれませんが、それでは面白くない。ではtvOSでの「面白い」とはなんなのか。iOSのアプリとどう違うべきであるのか、については以下次号（続くのか？） *1 : ちなみに私はここで丸一日つぶしました。

初めまして、こんにちは。 いきなりですが「 HOME'S 」は社名ではなく「 ネクスト 」という会社のサービスだということをご存知でしょうか？。 そのネクストですが「 Lifull 」といった新しいサービス群や、スペインを拠点に世界各国でWebサービスを展開する「 Trovit 」の母体でもあり、住まい探しだけでなく様々なジャンルに新たな価値を提供し続けている、実は結構クリエイティブな会社なんですよ。   あ、申し遅れましたが、ネクストの統括部門でクリエイティブとブランドマネジメントを担当しているYouthといいます。よろしくです。 2015年も残りわずかになり、ネクストの今年とこれまでを振り返る意味も込め、創業から20年の足跡をイラストで綴った動画のメイキングを紹介させていただきたく、飛び入りで本記事を書くことになりました。   まずはこちらの動画をご覧ください。(※音出ます) 大きな白紙にどんどん描かれていくイラスト。これを描いているのは、、、 プロのイラストレーター…… ではなく、弊社デザイナーの松木友希さんになります。(以後"松木さん") デザイナー 松木 友希｜株式会社ネクスト NEXT RECRUITING-SITE   松木さんは、ネクスト内に数十人いるデザイナーの中心的メンバーの一人で、 社内大学のイラストゼミを主催する絵の達人でもあります。 ↓こちらは松木さんが同僚の結婚式のために描いたWelcomeボード(ジョジョ風)   創業20周年にあたる今年、これまでの歩みを「なんとかネクストらしい方法で表現したい！」 そう考えたプロジェクトチームが、松木さん(とその上司や関係者)にお願いして、 企画のキモであるイラスト制作を引き受けてもらいました。   20年のエピソードを抽出し、絵にしていく まず初めに行ったのは、会社の歴史の中でターニングポイントになった出来事や、 画期的なプロジェクト、心に残るエピソードなどを、プロジェクトメンバー全員で (回想にふけつつ脱線しながら）洗い出してシナリオをつくりました。 これがないと何もはじまらないけど、記憶や記録も曖昧だったりするので、慎重に裏を取りながらの作業になり意外と大変でした。   そのシナリオを元に、松木さんが個々のイラストの要素や構図を考えつつ、全体のイメージを練っていきます。   シナリオを預けて待つこと数日、あがってきたのがこのドラフトです！ 「本当に絵で表現できるのかな…」と不安だったエピソードも全てうまい具合にイラストになっていて、 これをみたチームメンバーは「こっこれは、、いける！」と手ごたえを感じました。   たとえばこの辺とか。 これは、HOME'Sに掲載されている物件の中に、 間違った情報やいわゆる「おとり物件」などがないかを調べて是正する 「 情報審査 」と呼ぶ活動の様子を描いているんですが、 問い詰められてしょんぼりする家の様子がいかにもですよね。     本番に向けての下準備 上のドラフトをもとに、構図や細かな調整を加えて 本番で描くための下版がついに完成！！     それをこんな感じで大きな紙に投影して、キーとなる部分だけうすく下描きして撮影までの準備がほぼ整いましたよ。     そしていよいよ本番。ライブドローイング！ 撮影当日は社内の会議室を終日確保して 「松木さんがライブドローイングやるからみんな来てねー」と社内に誘いをかけました。   そして緊張の一瞬ー！　筆入れ！！ ちょっと間を置いて気をためるかな？と思いきや「スッ」と流れるように描き始めました。一片の迷いなし！   ペンを片手に、B1用紙4枚を繋なぎ合わせた紙に向かい、一瞬のミスも許されないペンさばきでサクサクと絵を描いていく松木さんと、まわりでそれを見守るメンバー。その様子を撮影するカメラ。 もう手に汗握りっぱなしです！ 今回の撮影は現場の音録りナシの映像のみにしたので、 徐々に仕上がっていくイラストに感心する声や「この絵はあの時のコトだよねー」などと盛り上がり 現場は終始和気藹々としたムードでした。   が、描いている松木さんだけはずっと集中してほとんど言葉もなく、、、 モクモクと20年の歴史が浮かび上がってきます。   ちなみに使用したペンと紙は、松木さんが世界堂さんへ通いつめてセレクトしたもので、ペンはCOPICの「コピックスケッチ」というマーカーを主に使用。 プロのイラストレーターや漫画家にも愛され、現在も新色が追加されている逸品です。 紙は「サンフラワー」という種類のもので、マーカーや不透明水彩のノリがすごく良いです。     午前中から描きはじめたイラストも午後4時頃には仕上がり、 撮影も無事終了しました。   その後、映像の編集やナレーション録りをして、ついに完成！ それが、冒頭にご紹介した動画です。     今回作成した原画は、額装して品川本社のエントランスに飾ってあるので、 ご来社された際はぜひ実物をじっくりご覧くださいね。 （A1サイズ程度に縮小プリントした絵も各支店のエントランスに飾ってあります）     終わりに 今回の絵の中心にある「Designing Delightful Encounters」というのは、ネクストのブランドコンセプト「あなたの『出逢えてよかった』をつくる」の英語版です。 これを実現するために、一つひとつの取り組みを続けて、それら"一コマ一コマ"がらせん状に大きく広がっていく…というのがこの絵のコンセプトになります。   そして2年後の2017年、ネクストは"創立"20年をむかえます。「あれ?今年じゃないの??」って声がきこえてきそうですが、今年は「創業」、2年後が「創立」となります。（なんだか混乱しますね！詳しくは コチラ→(沿革 | 株式会社ネクスト) をご覧下さい）   これまでの20年に満足せず、このらせんを更に広げていくため次の"一コマ"になる、大小さまざまなビックリ計画を多数企てていますので、今後も是非ネクストとHOME'Sにご期待下さい！   PS そして、ビジョン実現に向けて一緒に「一コマ」をつくる仲間も随時募集中です！まずはお気軽にご連絡ください！ 株式会社ネクスト NEXT RECRUITING-SITE      

おはようございます。 エンジニア兼クリエイターの日運営委員の瀧川です。 10/02（金）に、創民祭を開催しました！(だいぶ前ですが・・・) といっても、意味がわからないと思いますので簡単に説明しますと クリエイターの日 という社内制度がある IoTやモバイルファーストな時代に弊社も時代の波に乗り、幅広いプロダクトが作成されつつある せっかくだしその成果報告を、みんなで楽しもう みたいなコンセプトの社内イベントです。 今回はその記念すべき第一回目ということで、ちょっとだけ内容をお伝えしたいと思います。 少しでも当日の雰囲気が伝わればと思います。 開始！ 何はともあれ、開始です！ お酒もまじえつつ乾杯です。 乾杯後は自由に見て回ります。 すごいですね。まるでIT企業のようです。 そして、そうめんです。 太いですね。今回のそうめんは 半田そうめん を使用しており、 そうめんとひやむぎとの中間ぐらいある、独特の太さが特徴となっているそうめんです。 参加チーム 今回は合計8作品がエントリーしてくれました！ 参加チームの紹介をしたいと思います。 一部、社外秘のプロダクトもあるので全てのプロダクトを公開することはできませんが・・・ こちらの彼は、弊社のKPIを可視化してくれてます。 グラフがピコンピコン動く様子はとってもクール。 こういう、ちょっとした普段のモチベーションに繋がるツールの開発なんかにもクリエイターの日制度は利用されています。 ラズパイを使ってピタゴラスイッチ！ こちらもKPI達成に向けたモチベーションUPツールですね。 「ピタゴラ、スイッチ♪」と初めて流れた瞬間には拍手が巻き起こった記憶があります。 開発の様子が気になる方は こちら もどうぞ。 こちらは、今年の新卒研修で作成されたエンジニアとマッチングできるWEBサイトです。 研修は一週間と短い期間でしたが、デザインも洗練されていてかっこよく、 しかもインフラ側までしっかり考えられていて、 末恐ろしい人材が出てきたなと戦々恐々としております。 なにやらギークな様子を感じさせるこちらでは、golangを使用してSlackボットのフレームワークを作成してくれました。 ラズパイなどのIoTチックな製品や、golangという新しい技術を積極的に試してくれています。 ちょっとわかりづらい写真しかなくてすみません・・・ こちらは個人で開発したiOSアプリをエントリーしてくれました！ 写真を「撮った後」ではなく、 「リアルタイム」でエフェクトをかけられるアプリです。 シンプルながら、インターフェースもかっこよく、 ぜひぜひ使ってみたいアプリです。 しかも、 App Storeで「ベスト新着App」に選ばれた 実績のあるアプリです。 この方は見に来てくれた人にそうめんを提供してますね。 そうめんは、めんつゆに浸して食すのが日本では一般的なようです。 そして投票タイム 創民祭では、発表者のモチベーションUPも兼ねて、 投票システムを導入しました。 見に来てくれた人は3票まで投票権を持ち、 とにかくココロが震えた作品に投票できます。 そして、1位・2位のチームには豪華景品を贈呈するというシステムになっています。 斬新で画期的なシステムですね。 イノベーションとはこういうことを言うのかもしれません。 投票が終了したあとの集計中は歓談タイム。 みんないい笑顔ですね。 きっとそうめんがおいしかったに違いありません。 結果発表 そして気になる投票結果は・・・ 2位は、Androidチームのなにがしか！ (こちらは残念ながら社外秘のプロダクトということで、受賞したという結果だけの報告になります・・・) 創民祭では、投票とは別に弊社役員からの特別賞も用意したのですが、 そちらも獲得するという素晴らしい結果となりました。 ※特別賞の商品として、後日3D VRビューワー(プラスチック製)が贈呈されました そして気になる1位は 社員旅行しおりWEB版でした！ 弊社で開催される社員旅行の、旅のしおりです。 弊社の今までの社員旅行では、紙媒体のしおりを500-600人規模分用意したりしてたので、 これがあることでかなり運用がしやすくなっております。 新しかったり、流行ってたりの技術だけが人の役にたつわけではないという証明ですね。 新卒1年目のエンジニアとデザイナーを含む有志が頑張ってくれたのも心を震わせる一因だったのかもしれません。 お疲れ様でした 第1回創民祭、探り探りの開催でしたが、 結果として関係者みんな、とても楽しんでくれたんじゃないかなと思います。 これからも半年に1回のペースで開催していく予定ですので、 その際には、またこの場をお借りしてご紹介できればと思います。 それでは！

こんにちは。おうちハッカー@リッテルラボラトリーの石田です。 今日は、先日開催されました、 WebDB Forum2015 で行われた特別セッション　「産学間のデータセット共有の意義、課題と将来の展望」のレポートをします。 国立情報学研究所（NII）の 情報学研究データリポジトリ（IDR） を通じて、Yahoo!や楽天、クックパッド、リクルートなど多くのWeb・IT企業が研究用途にデータセットを提供しています。このセッションでは、これまでのデータセット共同利用の取り組みが研究コミュニティに与えてきた影響や、現時点で直面している課題などについて議論を深めるものでした。 企業の方でアカデミックとの繋がりを深めて共同研究したい、研究機関の方でWEBサービスのデータを使いたい、企業と共同研究したいと考えている人に必見の内容でしたので、ここで共有したいと思います。 情報学研究データリポジトリについて さまざまな企業が、NIIのデータリポジトリを利用して、研究用にデータを提供しています。例えばYahooが運営するYahoo知恵袋のデータ、楽天市場の商品とレビューデータ、ホットペッパービューティーの登録店舗データなど様々です。弊社も先日、 HOME'Sデータセットの提供を開始 いたしました。こうした背景から、弊社の清田がセッションで登壇させていただきました。 NIIに登録されているデータセットは、研究機関の方であれば申請していただければ利用可能となります。 特別セッションについて こうしたデータ提供の流れが広まるなか、データリポジトリに深くかかわる５人の登壇者によるセッションがおおなわれました。前半にデータセットの利用側、提供企業側、国立情報学研究所の、各関係者の方々がそれぞれ話されたあと、議論に移りました。座長は、関西大学の松下光範先生でした。 それぞれ登壇された方および内容はこのような形でした。 データセット利用側 筑波大学 佐藤哲司　先生 まずはデータ利用側の視点からということで、筑波大学の佐藤先生からプレゼンでした。 佐藤先生は、既に公開されている楽天、Yahoo知恵袋、クックパッドのデータセットを利用して研究をされており、データセットを用いた研究の第一人者です。 データセット共有のメリット 近年さまざまなWEBサービスが使われており、サービスによってデータも異なり、その分析手法も様々です。新しいデータがでれば、新たな分析手法が必要になります。 佐藤先生は、データセットとして提供される前段階で企業からデータを貰い共同研究しされていたこともあるのですが、誰もがアクセスできるデータではないこと、研究者によってもらうデータが異なることから、 その手法を比較、優劣をつけることが難しかったようです。 NIIがデータセット提供を始め、多くの研究者が同じデータセットを用いて研究することで、純粋に手法の優劣がつけやすくなったとのことです。 課題 手法の優劣をつける際に、正解データがはっきりしないと比較し辛いものがあります。 例えば「ユーザーに興味のある商品を推薦する」といった情報推薦のタスクにおいて、推薦された商品に対してユーザーが興味をもっていたかどうかが一つの正解データとなります。 興味があったかどうかは、その後の閲覧時間やクリック履歴、購買履歴から推定することはできますが、こういった情報はあまり提供されていません。 そこで、データ公開企業には 全体のデータはそのままNIIで公開 し、個人情報がかかわる提供しづらいデータについては、 個別でNDAを締結して提供 して欲しいということです。 こうすることで、研究の透明性が担保され、正解データとの比較で手法に優劣をつけやすくなるとのことでした。 提供企業側 クックパッド株式会社　原島純　さん 次に、データ公開側の１社目として、クックパッドの原島さんからクックパッドのデータ提供の裏側のお話しでした。 多くのデータ提供要望と課題 クックパッドはユーザー投稿の非常に多くのレシピデータを保持しており、研究に使いたいという要望が多く寄せられていました。 要望があるたび都度提供していたそうですが、 毎回準備が大変 で、効率がよろしくなかったそうです。 ユーザー側にとっても、データが使えるまで時間かかる、提供データが個々で異なるので、 先行研究と比較しづらい などの問題がありました。 提供 公開することで、これらの問題が解決し、料理の研究広がり、ユーザに価値をもたらすことができるのではないかと考え、 NIIのデータリポジトリに登録・公開を開始しました。 NIIとの契約や、データセットのクレンジング処理等、非常に苦労されたそうです。 公開から９ヶ月で73研究室から申請、提供 しているそうです。また企業からも問い合わせがあり、共同研究も進めているようです。 少しずつ研究発表の場で発表されており、今後学会シーズンでさらに発表が増えることを期待しているそうです。 スライドが公開されていました。 speakerdeck.com 提供企業側 株式会社リクルートテクノロジーズ 櫻井一貴　さん データ公開側の2社目として、リクルートテクノロジーズの櫻井さんより、リクルートのデータ公開についてのお話しでした。 リクルートならではの課題 リクルートは、進学から就職、結婚、住まい、転職、お店探しなど非常に多くのWEBサービスを扱っておられます。それぞれのサービスは、各事業会社が運営しており、櫻井さんの所属しているリクルートテクノロジーズは、ITやネットマーケティングの技術基盤整備やR&Dをサービス横断的に行う会社です。 こちらが窓口となり、各事業会社からデータを貰い、NIIにデータを提供しているとのことです。 あくまで データの所有権は各事業会社にあり 、データ提供を行うためには、各事業会社に納得してもらう必要があります。 データ公開のリスクとメリット 説得するためには、データ公開のリスクとメリットを伝える必要があります。 USB置き忘れ、利用者が商用利用といったシナリオを列挙、説明したうえで得られるメリットを述べたそうです。 メリットとしては CSRに繋がる 研究を通じて新たな技術・知見が得られる 人材獲得につながる があるそうです。 特に 人材獲得が大きい そうです。データセットを研究に使ってもらうことで、学生への認知度の向上が大きいようです。 「リクルートデータセット」 ～公開までの道のりとこれから～ from Recruit Technologies www.slideshare.net 提供企業側 株式会社ネクスト　清田陽司 データ公開側の3社目として、弊社清田が、産学連携の課題について話しました。 今の世の中、一企業では所有データを活用できないのは明白です。そこでデータを研究機関と共有して価値ある情報に変える共同研究の必要性があります。 産学連携に携わる担当者との議論で得られた、共同研究が成功するノウハウをまとめました。 データの保持の形式 共同研究がうまくいった事例を見ると、大規模データが研究に利用できる形で蓄積されていることが大事なようです。 また研究で社外持ち出すことが多いと思われますが、プライバシー保護に問題のない形で保持しておくことも重要です。 ビジネス背景の共有 データセットだけを提供しても、ビジネスとして価値のあるものが得られることは少ないです。 現場の課題や背景を事前に共有 しておくことで、価値の高い研究となりやすくなります。 また研究者と企業のR&D部門だけではなく、実際にサービス運用に携わるマーケティング部門との連携が取れていることも重要です。 リアルタイム性のあるデータ 研究において、ある時間で切り取られたデータセットに対して最適化しても、ユーザーの行動が変化してしまい、コンテストの成果をサービスに応用できなかったという事例があります。 現状のデータセットは、ある瞬間におけるデータを切り取ったものがほとんどであるため、こうした問題は起きる可能性があります。 いずれはリアルタイムなデータの共有も求められるでしょう。 スライドはこちらとなります。 「HOME'Sデータセット」提供開始の背景　〜産学間データ共有の課題〜 from Yoji Kiyota www.slideshare.net 国立情報学研究所 大山敬三 先生 最後に、これらのデータリポジトリの責任者である大山先生に、NIIデータリポジトリのお話しをしていただきました。 データリポジトリの背景 情報技術分野では、 研究と実用のギャップ が大きな問題でした。研究者にとっては、研究の実用化のプレッシャーがかかる一方で、実際に用いられているサービスのデータで研究しないと実用化は難しいです。 自然科学分野のデータはオープン化が進んでいる一方で、 人間相手のサービスのデータはプライバシーに関わるものが多く、オープン化には向いていません。 そこで、研究者に向けた実サービスのデータを提供する場として、NIIのデータリポジトリが始まりました。 先日、国立情報学研究所内に、データセット共同利用研究開発センターという専門の部署が立ち上がりました。 こちらで、データを提供・配布のほか、ライセンス締結やデータセット形式などのノウハウの共有を行っています。 提供状況とニーズ 2015/11/24発表時点で、 439研究室 にデータを提供し、そのデータを用いて 350論文 が発表されています。 また個人を対象としたニコニコデータセットは、1293人に提供されています。 データ提供のニーズとしては、情報学以外にも経済学や環境学の分野の研究に使いたい、教育用やデータサイエンティスト育成に使いたいというものがあるようです。 ディスカッション 松下先生をファシリテーターに、主に「データ形式やクレンジングについて」「研究成果について」の２点が話し合われました。 データ形式・クレンジングについて データを提供する際に、外に出さないデータをクレンジングしたり、形式を整えますが、ユーザーにとっては必ずしも使いやすい形になっていないことがあるようです。 どのようにすればこうした問題を解決できるかということですが、githubなどを通じてユーザーにもクレンジングに関与してもらう、NDA締結して生データを渡す、といった解決策が出されました。 企業の都合だけでデータ形式を決めるのではなく、ユーザーからの声を取り入れていく姿勢が、より多くのユーザーに使ってもらえるコツかと思いました。 研究成果について 企業としてコストをかけ、リスクを取ってデータを提供する以上、研究成果を自社のサービスに取り入れることを視野に入れていると思います。 まだ直接研究成果をサービスに取り込めているところはおそらくなく、どうしたら直接的な成果につながる研究を生み出せるかが話し合われました。 ほとんどの登壇者の方々で共有していたのは、 現場の課題を共有する場が非常に大事 であるということです。何かしら企業側と研究側が話し合える場所を作ることで、直接企業の課題を取り組むまではいかなくとも、より有益な新しい視点・課題が発見できたり、研究の方向性を揃えることができるのではないかとのことでした。 ただ大学側としては、お役所的な部分もあり、どのように共有の場に関わっていけばよいのか分からないという意見がありました。 そこで一つの形として、 ハッカソン型 で課題を共有した後に短期間で成果を出す方法が良いのではないかということでした。 通常の研究と異なり、結果に対してのFBが早く方向性の修正がしやすい、短期間で集中してできるというメリットがあります。 本データだと容量が大きすぎて時間がかかるため、少な目のデータを提供して成果を出してもらう形がよいとの意見がありました。 また、一日のハッカソンでは実用的成果は得られないが、課題の共有ができ、楽しんでもらうことができるので採用に繋がりやすいとの声もありました。 最後に NIIのデータ提供で提供側、利用側がお互いによい効果を生むためには、まずはお互いの事情を共有していくことがとても大事だと感じました。共同研究において、企業側は研究者に発表の機会を妨げない、研究しやすいデータ形式を心掛ける、利用者側は企業の背景の理解を試みる、など相手の立場に立って進めることが必要です。 私も、HOME'Sデータセットを使って簡単に研究を始められるツールを開発したり、データセットの整備に関わっているので、ユーザーが使いやすいものにできるように頑張りたいと思います。

こんにちは、リッテルラボラトリーの清田です。 このたび、 国立情報学研究所(NII) のご協力を得て、 HOME'S に掲載されている日本全国の賃貸物件データ(約533万件)と、それに紐付く物件画像データ(約8300万件)を 研究資源として無償提供することになりました 。あわせて、画像処理分野などで注目を集めているdeep learningなどの機械学習アルゴリズムや、テキストマイニング処理などを簡単に試していただけるツールキット群も年内に公開予定です。 2015年11月24日より、 NII情報学研究データリポジトリ を通じて HOME'Sデータセット として提供開始しました。ぜひ多くの研究者の方にデータセットを研究利用していただき、住まい探しを変革するようなイノベーションにつなげていただけると嬉しいです！ 詳しい内容については、以下のイベントでお話しさせていただきました。 スライドファイルを公開しておりますので、ご覧ください。 不動産物件データセットを用いた研究開発事例と、大学との共同研究の取り組みの紹介 from Yoji Kiyota www.slideshare.net WebDB Forum 2015 (芝浦工業大学豊洲キャンパス 11月24〜25日) C-6技術報告セッション 「不動産物件データセットを用いた研究開発事例と、大学との共同研究の取り組みの紹介」(11/25 13:30-14:00 C会場) ARG 第7回Webインテリジェンスとインタラクション研究会 (WI2研究会、リクルート本社グラントウキョウサウスタワー41F 11月28〜29日) セッション8(技術報告) 「不動産物件データを用いた研究開発事例、および産学連携強化の取り組みの紹介」 (11/29 16:10-16:40) また、WebDB Forum 2015特別セッション「産学間データセット共有の意義、課題と将来の展望」に登壇し、データセット提供開始の背景について話しました。石田が参加報告を書いておりますので、こちらもぜひご覧ください。 nextdeveloper.hatenablog.com どんなデータが使えるの？ 株式会社ネクストが運営する物件数No. 1 *1 の不動産・住宅情報サイト HOME’S に2015年9月時点で掲載されていた日本全国の賃貸物件データ(約533万件)、および物件画像データ(約8300万件)が利用できます。 とくに物件画像データは、deep learningなどの最先端の機械学習アルゴリズムの適用を想定し、画像の種類(間取り図、外観、居間、キッチンなど)やフリーテキストなどのメタデータとのセットで提供します。 データセットの中身は？ データセットはTSVファイル形式(ただし画像データはJPEG形式ファイル)で提供します。概要は以下の通りです。 日本全国の賃貸物件データ (2015年9月時点で全国約12,000の加盟不動産店舗から寄せられた全データ、のべ約533万件) 物件種別 (マンション、アパート、一戸建てなど) 費用 (賃料、管理費、敷金、礼金など) 部屋面積、間取り、築年数、建物構造など 立地 (市区町村・郵便番号、最寄り駅・徒歩分、最寄り小学校・中学校・コンビニ・病院までの距離など) 諸条件 (オートロック、システムキッチン、バス・トイレ別、エレベーター、駐車場、etc.) 物件特徴 (フリーテキスト) 賃貸物件の画像データ (約8300万枚) JPEG形式、最大120×120ピクセル 画像種別がメタデータとして付与（間取り図、外観、内装、玄関、居間、キッチン、寝室、風呂、etc.） 写真説明(フリーテキスト)も一部付与 高精細度版の間取り図画像を追加データセットとして提供開始しました (2016.2.1 updated!) 。 なお、物件を直接特定可能な情報（緯度経度、詳細な住所など）は含まれません。 簡単に使えるの？ NIIのご協力を得て、 情報学研究データリポジトリ(IDR) を通じてデータセット一式を提供いたします。NIIへの簡単な利用申請手続きを経て、申請から1〜2週間後にNIIから案内されるダウンロードページを通じてデータセット一式を入手できます。 また、より手軽にデータ利用をお試しいただけるように、GitHubにて ツールキット を公開しました。 nextdeveloper.hatenablog.com ツールキットの利用により、以下のような処理を簡単に実行することができます。 物件画像データへのdeep learningの適用 フリーテキスト情報中の頻出キーワード抽出（地域別、最寄り駅別など） 誰が利用できるの？ 利用申請していただいた研究者です。ただし、公的機関(大学などの教育機関、独立行政法人などの研究組織、etc.)の研究者が対象となります。 学生の方は、研究指導教員による手続きで利用できます。 国立情報学研究所およびネクストによる簡単な審査があります。 公的機関に所属しない研究者の方が利用を希望される場合は、弊社窓口（corp-info アットマーク next-group.jp）を通じてご相談ください。 何のために提供するの？ HOME'Sデータセットの共有をひとつのきっかけとして、住まい探しに関連するさまざまな研究課題に多くの方々と協力して取り組むことによって、住まい探しのマーケットそのものを変革するようなイノベーションを起こすことを目指しています。 不動産・住まい探し分野の研究活性化 国内最大規模の物件情報データの提供によって不動産・住まい探しに関する研究が活発になることで、今までにない住まいの探し方など、新たなイノベーションが生まれてくることを期待しています。 産学連携の機会創出 共通のデータセットを産学間で共有することによって、共同研究の取り組みを加速するとともに、産学の垣根を越えて不動産・住まい探し分野にフォーカスする研究コミュニティの創出を目指しています。 人材育成への貢献 本データセットを用いたハッカソンやインターンシッププログラムを実施することで、学生の方々が実世界のニーズに触れる機会を提供し、イノベーションに携わる次世代の人材育成に貢献していきます。 おわりに 今回の取り組みにあたっては、多くの研究者の方々からのヒアリングを事前に行わせていただき、研究コミュニティ内の潜在的なニーズにできるかぎり合致するようにデータセットの設計を行いました。また、データセット提供の枠組みの構築にあたって、 アカデミック・リソース・ガイド株式会社 (ARG社、代表: 岡本真氏)からのご協力を得ました。ご協力をいただいたみなさまにこの場を借りて深くお礼申し上げます。 問い合わせ先 情報学研究データリポジトリ(IDR) Webサイト: http://www.nii.ac.jp/dsc/idr/ NII IDR事務局: idr アットマーク nii.ac.jp ※公的機関に所属する研究者の方以外からのお問い合わせは、弊社問い合わせ窓口（homes-dataset アットマーク lifull.com）までお願いいたします。 *1 : リサーチ・アンド・ディベロプメント調べ(2015.3.16発表) でナンバーワン「at home、CHINTAI、HOME'S、O-uccino、SUUMOで掲載する賃貸物件、売買物件数を各都道府県別に調査期間内における2日間での平均を数表化したもの」

こんにちは。おうちハッカーの石田です。 いつもはおうちハックネタばかりですが、今日は人工知能関連の話題です。 今日2015/11/10、Googleが自社サービスで使っているDeepLearningを始めとする機械学習技術のライブラリを公開しました。 TensorFlow という名前で、おそらくテンソルフローと呼びます。 テンソルは、数学の線形の量を表す概念で、ベクトルの親戚みたいなものです。それにフローをつけるということは、そういった複雑な多次元ベクトル量を流れるように処理できる、という意味が込められているのだと思います。 こちらをさっそく触ってみたので、紹介したいと思います。 TensorFlowの特徴 公式紹介ページから特徴をいくつかピックアップします。 Deep Flexibility ~深い柔軟性~ 要望に応じて、柔軟にニューラルネットワークを構築できます。ニューラルネットワークのモデルをツールで組み立てる、Pythonで自分の思う通りに書く、C++で低レベル処理を書くことなど、柔軟に記述できます。 True Portability ~真の携帯性~ ディープラーニングは計算量が多いため、グラフィックボードの計算能力を使った演算が一般的です。CPU演算、GPU演算でコードが異なるフレームワークがある中、TensorFlowではCPU,GPU用とコードを分けなくても大丈夫です。CPUで試しにやってみて、うまくいきそうならGPUに切り替えることが容易にできます。またモバイルの移植性にも優れています。 Connect Research and Production ~研究と製品の接続~ かつては研究成果を製品にする際には、大量にコードを書き直す必要があったのですが、Googleでは研究者もエンジニアも同じくTensorFlowを用いているようです。こうすることで、素晴らしい研究成果をすぐに製品に生かすことが可能になりました。 実際に使ってみる ということで触ってみないと分からないことも多いので、実際にインストールしてみます。 インストール 今回はUbuntu14.04にインストールします。Python2.7の開発環境が初めからあるはずなので、実質インストールは１行で終わります。 $ pip install https://storage.googleapis.com/tensorflow/linux/cpu/tensorflow-0.5.0-cp27-none-linux_x86_64.whl はい、これでCPU演算のみですが、TensorFlowを使うことができます。とても簡単ですね。 MNISTを試す それでは、定番のMNISTを試してみたいと思います。 MNISTとは？ MNISTとは、手書きの数字を学習して判別するものです。プログラミングの世界でHello, World!が初心者の第一歩とされるように、MNISTは各種機械学習フレームワークの第一歩となります。 MNISTのデータセットはこのようなものです。 MNISTを学習させる MNISTはチュートリアルに含まれているため、すぐに実行することができます。 fully_connected_feed.pyを実行すると、データセットの取得から訓練、ログの記録をやってくれます。 # ソースを取得 $ git clone --recurse-submodules https://github.com/tensorflow/tensorflow ### 実行 $ python tensorflow/g3doc/tutorials/mnist/fully_connected_feed.py これを行うと、訓練の経過が流れ始めます。 Step 0: loss = 2.30 (0.021 sec) Step 100: loss = 2.15 (0.005 sec) Step 200: loss = 1.84 (0.005 sec) Step 300: loss = 1.49 (0.005 sec) Step 400: loss = 1.22 (0.005 sec) Step 500: loss = 0.82 (0.005 sec) Step 600: loss = 0.72 (0.005 sec) Step 700: loss = 0.72 (0.005 sec) Step 800: loss = 0.79 (0.005 sec) Step 900: loss = 0.61 (0.005 sec) Training Data Eval: Num examples: 55000 Num correct: 47371 Precision @ 1: 0.8613 Validation Data Eval: Num examples: 5000 Num correct: 4350 Precision @ 1: 0.8700 Test Data Eval: Num examples: 10000 Num correct: 8663 Precision @ 1: 0.8663 Step 1000: loss = 0.46 (0.013 sec) Step 1100: loss = 0.40 (0.106 sec) ........................ ........................ lossは予測と正解の一致が多くなると小さくなる値で、学習が進むにつれて小さくなっていきます。 Precisionは精度にことで、定期的に学習したモデルで精度を計測します。 精度の計測には、３種類のデータによって行われ、それぞれ ①訓練データでの精度 ②バリデーションデータでの精度 ③テストデータでの精度 となります。①②は訓練に使うデータ、③はテストにのみ使うデータです。 どんどん精度が上がっていく様を眺めましょう。 しばらくすると学習が終わります。最終的な精度は、96.3%となりました。 Training Data Eval: Num examples: 55000 Num correct: 53231 Precision @ 1: 0.9678 Validation Data Eval: Num examples: 5000 Num correct: 4830 Precision @ 1: 0.9660 Test Data Eval: Num examples: 10000 Num correct: 9629 Precision @ 1: 0.9629 学習結果をグラフ化する このように数字で羅列されても分かりづらいので、グラフにします。 学習が終わると、先ほどの実行したファイルの場所(tensorflow/g3doc/tutorials/mnist/)に、dataというディレクトリができています。 こちらに学習経過がログとして記録されています。 TensorFlowでこれをグラフ化するには、TensorBoardを使います。TesorBoardとは、WEBインターフェイスで学習の状況やニューラルネットワークを可視化したり、操作したりできるものです。 今回の学習結果をもとにTensorBoardを起動する場合は、以下のコマンドを打ちます。 $ tensorboard --logdir=/home/ec2-user/work/tensorflow/tensorflow/g3doc/tutorials/mnist/data すると、TensorBoardが立ち上がり、WEBブラウザでアクセスできるようになります。アドレスは、 http://localhost:6006 となります。これをWEBブラウザに入力すると、このようなインターフェイスが現れます。 メインの画面には、zentropy_meanという文字が表示されています。複数のログを取っている場合、選択して表示できるようです。今回はデフォルトで生成したログしかないので、zentropy_meanを選択します。 すると、メイン画面には、このような学習回数とlossのグラフが表示されます。 これなら一目で学習状況が分かりますね！！　始めにガーンとlossが減り、それからは少しづつlossが減っていることが分かります。 ニューラルネットワークのグラフ化 さらにはこの画面で、モデルのグラフ化したものも見ることができます。 上のタブのGRAHPをクリックすると、このようなグラフの画面が現れます。 全体像が見えますが、思ったより大きなグラフで、詳細がよく見えません。 なのでGoogleMapの要領で拡大するとこんな感じに見えます。 ここは入力から隠れ層に出力し、勾配法で誤差を小さくしていく部分のようです。 隠れ層のhiddenのボタンにマウスオーバーすると、「+」のマークが出てくるので押してみると、隠れ層の詳細をさらにみることができます。 実際の使用感は、このようになっています。 youtu.be この画面からさらにモデルを変更することもできるようなのですが、まだ触って間もないので把握できていません。 ただ、こんなに簡単にモデルをグラフ化してみることができるのは感動ものです！ 使ってみての感想 WEBインターフェイスのTensorBoardがやはりスゴイです。Chainerでも学習過程のグラフ化は可能ですが、WEBインターフェイスが用意されているわけではなく、コマンドラインからplotなどを使用する形でした。しかしこの方法では、AWSのインスタンスといった画面がない端末での結果表示ができませんでした。WEBインターフェイスを介せば、立ち上げて接続元の端末のWEBブラウザから閲覧することができるので便利です。 またコードだけでは分かりづらいモデルのグラフ化ができることにより、研究者と開発者が議論する際にやりやすくなると思いました。また、ネットワークの構成がわかってないけどとりあえずサンプルを動かしてみたという初心者にとっては、グラフをみることでソースの理解がしやすくなるのではないかと思います。 まだTensorFlowでコードを書いていないので、本質的な使いやすさはまだ分からないのですが、ディープラーニングがより一般的になっていく未来を感じました。

  こんにちは、 HOME'S アプリのデザインを担当している、こばやしです。   現在、Android版アプリ「HOME'S(ホームズ)」をマテリアルデザインに向けて絶賛リニューアル中で、第1弾が8月30日にリリースされました。この記事ではアプリをマテリアルデザイン対応するにあたり、デザイナー視点で考えたことや実際の変更点について書いてみようと思います。   はじめに、「 そもそもマテリアルデザインとは？ 」「 なぜマテリアルデザインにするの？ 」などの前提部分の考え方についてを説明します。   HOME'S（ホームズとは） 住まい探し検索アプリです！ 「Android版 HOME'Sアプリ」DLは こちら   マテリアルデザイン対応とは マテリアルデザインのガイドライン に沿ったデザインをすることです。   マテリアルデザインとは GoogleがモバイルOS「Android 5.0 Lollipop」から採用しているデザインコンセプトを「Material design」といいます。直訳すると「物質的なデザイン」ですが、要約すると大きく以下の２点が特長のUI・UXにおけるガイドラインになっています。 重なり（Z軸）を意識する 出展元: Material Design Guidlines 画面（2D）のなかで、立体（3D）を意識した重なり・表現をします。そのため、高さがあるものは陰がつき、Z軸の値が大きいと、影もより大きくぼかされて表示されます。   要素はインクと紙でできている 出展元: Material Design Guidlines ヘッダーやカードUI、FABボタンなど、要素のベースとなる部分は「紙（のメタファー）」と捉え、それに乗っている要素は「インク（のメタファー）」と捉えて、配置・動きにする必要があります。それぞれが単体の紙なので、重なり合います。また、画面上では紙自体も拡縮します。この辺りまどろっこしいですが…。 他にも、カラー、グリッド、タッチフィードバック、意味を持つアニメーションの定義などが記されています。 詳しくは Material Design Guidlines   なんでマテリアルデザイン対応するのか 極端なところ、しなくても大丈夫です。 マテリアルデザイン対応も手段であって、アプリにおける使い勝手がよければ必須ではないのかなというのが持論です。なので、HOME'S（ホームズ）アプリでも必ずしも完全にガイドラインに則っているわけではありません。ブランディング、ビジネスとしての優先順位、他デバイスとの親和性、それらの影響範囲の中でバランスのよいトコロを目指しています。   検討した結果、HOME'S（ホームズ）ではマテリアルデザインを採用しました。主な理由はこちらです。 ルールに揃えることでユーザーのUI学習コストを減らす ライブラリを使用することで実装の工数を削減できる   ぜひガイドラインを読んでいただきたいのですが、とても実践的で考えられているルールです。Googleアプリはもちろんこれに則ってつくられていますし、今後のスタンダードになっていくと思います。 またアプリのトレンドは特に日進月歩で次々に新しい技術や定義が生まれています。それについていくためにも効率のよいつくり、汎用性を意識した設計が必要です。それらを実現するためにはマテリアルデザインを採用するのが効果的だと判断しました。   HOME'S（ホームズ）のマテリアルデザイン対応の進め方 既存アプリのマテリアル対応、どうやって進める？ まずはここを考えます。 すでにマテリアルデザインを取り入れてリニューアルされているアプリがたくさんあります。多くはフルリニューアルで刷新していますが、HOME'S（ホームズ）では段階リニューアルをしています。どちらも メリットとリスク があるとおもうので、サービス内容や規模に合わせて選ぶのがよいと思います。   フルリニューアル アプリ全体で統一されたUIを提供できる 初回リリースまでの工数が大きい UXがリセットされ、レビューへの影響が大きい など   段階リニューアル 段階中はマテリアルUIと旧UIが混在する 折衷的なUIになるので、その調整分のコストが掛かる 小出しにリリースすることでユーザーの反応をみれる 他の施策と平行して動きやすい など   HOME'S（ホームズ）アプリは多機能で画面が多く、一度にマテリアル化をしてしまうと、使っていただいているユーザーのUXをリセットしてしまう恐れがあります。マテリアル化以前のUIはまだ「Androidらしいルール」がなかったので、webとの親和性を大事にして設計したため、マテリアルデザイン化することでのUIの大きは変更はユーザーに結構なフラストレーションを与えると考え、段階リニューアルを選びました。 そのため、マテリアルデザインUIと既存UIが混在する時期もでてきてしまいますが、「ユーザーも一緒にマテリアルデザインに慣れさせて、使ってもらう」ことも１つの目標と捉えて、マテリアルデザイン化を進めています。     マテリアルデザイン対応の初手はページ共通部分から どこから手をつければいい？ 次にここを考えました。 段階リリースなので、リリースされるタイミングでマテリアルデザインUIと既存UIが混在します。そのため、「混在しても違和感が少ない箇所」から着手しています。   ツールバー API level 21以降、NAVIGATION_MODE_LISTやNAVIGATION_MODE_TABSといったActionBarと連動したナビゲーション要素が非推奨となりました。HOME'S（ホームズ）でも物件の一覧画面の並び替え機能をツールバー（旧アクションバー）設置していたため、実装の変更が必要になりました。あくまで実装の仕方での非推奨なので、Spinner(with Toolbar) で置き換えることで、元と同じAdapterをセットしてやるだけでほぼ同じ見た目のまま置き換えることができます。   そのため見た目の変更なく対応できる部分ではあるのですが、マテリアルデザインではツールバーにタイトルを置くことが推奨されているため、旧アクションバーに設置していたスピナーはツールバーからはずし、ページに配置しました。   スマートデバイスでは、PCよりスクロールするという行動にストレスを感じないとされてますが、それでもファーストビューは大事なので、ただページに配置するのではなく、ユーザーのスクロールの動きに合わせて「コンテンツに重なるようにして表示されるナビゲーション（フィルターUI）」を実装しました。   検索結果一覧でもっとも見たいのは検索した物件なので、それ以外の要素は非表示にして、ユーザーがそのページで一番したいことに集中してもらえるようにしています。   ナビゲーションドロワー マテリアルデザインガイドラインの登場により、ナビゲーションドロワーのあり方が定義されました。アクションや通知を配置さているアプリを見かけますが、あくまでアプリ全体のコンテンツへのナビゲーションと捉えてHOME'S（ホームズ）では全機能への導線を追加しました。   UI設計は、誤タップをなくすために余白をしっかり確保したり、罫線での分割は控えめにして面の騒がしさを抑えて視認性を担保しています。カバー画像を用いることで画面の大きい端末でもタップしやすくしています。 と、この辺りの設計もマテリアルデザインガイドラインに推奨される設計があるので、それに揃えることで一定の使いやすさとなります。ガイドラインって大事ですね。   遊び心として、ログインすると月替りのホームズくんが登場します。ぜひチェックしてみてください。     続く。（更新は後日）

はろーはろー！チバです。 今回は、2015年9月17日（木）に行われた「NEXT×pixiv 交流祭 - Webディレクターの向こう側へ！」の開催レポートをお送りします！ 「NEXT×pixiv 交流祭 - Webディレクターの向こう側へ！」とは 株式会社ネクストで働くディレクター職の従業員と、ピクシブ株式会社で働くディレクター職の従業員同士が集まり、 「ディレクター」という職業のあり方を考えるイベント です。 プライベートで ピクシブ株式会社 さんへ遊びに行った際、 「ディレクターってひとつのプロジェクトに同時にアサインされることがほぼ無いから、孤独ですね…」 の話題になりました。 ディレクターの先のキャリアって何があるんだろう 今の自分のディレクションのやり方が不安、むしろ正解があるのだろうか 他所のディレクターも同じような悩みを持つことはあるのだろうか などなど、書ききれないほどディレクターの未来について話し合い、 「いっそ、2社のディレクター集めて交流会やりません？」 といった経緯があり開催に至りました。 「ワールドカフェ」ではじめるファシリテーションプロセス ワールドカフェとは、大勢の参加者の中で4,5人のグループを作り、メンバーを入れ替えながら話し合うディスカッションのスタイルです。 今回のように、異なるテーマについてメンバー間で話し合ってもらいたいときに用いる方法として活用できるため採用しました！ 今回は、前述した「ディレクターの悩み」にフォーカスしたテーマを3つ用意し、それについてワールドカフェ形式で話し合う進行のかたちにしました。 1. ディレクターがやるべき業務工程を考える。 「進行管理」にはいったいどこまで含まれているのか、ディレクターがいなくてもいい工程／いなくてはならない工程とはどのようなプロジェクトか。 2. ディレクションスキルというものは、一体どうやって磨けばよいかを考える。 ディレクターはどうやって技術勉強をすればいいのか、どのように進行管理の術を学べばよいのか。 3. 「ディレクター」という職種の先、または平行にあるキャリアを考える。 ディレクターはキャリアパスをどのように引けばよいのか。また、どのようなキャリアのあり方が世の中に求められるようになるか。 上記のお題をLT（Lightning Talk）形式で代表者に発表（所要時間5分）してもらい、LT終了と共に各テーブルで話し合って（所要時間15分）もらいました！ 自己紹介をサッとおこない、その後お題について 自身の体験談や考え、思想を混じえてお話 します。 ワールドカフェには議事録係はいません。自分で話しながら内容を広げられた模造紙に書きなぐります。こうすることで頭のなかが整理でき、いつもよりも話しやすくなる効果も！ 70分間、休憩無しで3つのテーマについてディスカッションするため、スイーツとコーヒーを用意してブレイク 懇親会用のアルコールも、3回目のテーマで解禁！です╭( ・ㅂ・)و ̑̑ ｸﾞｯ ＼Beer Driven!／＼Beer Driven!／＼Beer Driven!／ 1テーマ終わるごとに、2テーブルから話した内容を発表してもらいます。 他テーブルが自分たちと全く違った目線で話を進めていることを知り、話しているテーマが多様な形に広がることが発見できました。 テーマ別に見る「ディレクターの悩み」 各テーブルで話し合っていた内容をテーマ別にまとめました。 1. ディレクターがやるべき業務工程を考える。 「 手を動かす業務よりも、人として誰かの間に入って橋渡しをする業務のほうが主な仕事。 」といったような意見が多く出ました。 「下手に出る」、「嫌われ役になる」など、一見、損な役回りのように聞こえるポジションですが、相手のフィールドに立って考えるためには様々な役になる必要があります。そのために、ディレクターは体感的にコミュニケーション効果の測定をおこない、 信頼関係を築くためのフローを確立すること が会話の最終地点になることが多かったようです。 2. ディレクションスキルというものは、一体どうやって磨けばよいかを考える。 最近のディレクターは、技術職を得ての職種ではなくなってきました。 技術的な知識はコミュニケーションを円滑に推し進めるための手段 でしかなく、モノにしたければ積極的（を通り越して貪欲にｗ）に知識幅を広めていくことが「ディレクションスキル」を磨くに適した振る舞いだという話への着地が目立ちました。 たくさんの信頼を得るために、まずは〆切に厳しくなるところから！その先に、スキルを磨ける道が用意されているのかと思います。 3. 「ディレクター」という職種の先、または平行にあるキャリアを考える。 いくつかの選択がある中で、マネジメントへ進む人が多いことが挙げられました。プロジェクトマネジメント経験のあるディレクターが重宝されるように、そちらへ進む道を切り開くことで今以上に挑戦し甲斐のあるプロジェクト担当への野望は叶えやすいキャリアパスなのかもしれません。 また、ゼネラリストやスペシャリストのように、「この人がいないとムリ！」なポジションも挙げられました。 やはりディレクターの次なるキャリアはより上位の玄人ポジションなのでしょうか！ 2つ目のテーマの延長線上から、「育てる側へ回る」の意見も出ました。ディレクターの長ポジションや人事など、 次の世代へバトンをつなぐ役割もディレクター経験者は進みやすいキャリアなのかも しれませんね。 主催者目線での総括 まずは参加された皆さん、お疲れ様でした！ 自分たちと違う環境で、違うサービスを企画・運用しているディレクターと交流し、また新しい視野の開拓ができました、ねっ！ ご協力・ご足労いただいたピクシブ株式会社さんありがとうございましたーー！ 先日、運営陣で振り返りをしてきました。「今回は考えをシェアする場を作れたので、次回は発言する回ですね」というアイディアも出て、回数を重ねてもっといろんな機会を企ててきっかけ作りができたらなと思います。 なかなかにビジョナリーな会社なので、思想がマッチすると楽しいお話ができる自信があります！ 社外スクランブル企画を一緒に企んでくださる方は賃貸事業部のチバまで^^ 「井の中の蛙大海を知らず」と言うように、 他の世界を知ったうえで自身のすべきことへ目線を変えると、違ったモノの見方ができる と思っています。 やり方も考え方も変わる日進月歩な毎日について行けるよう、日頃の取り組み方も大切にしていきたいです。 イベントが紹介されているブログ inside.pixiv.net

こんにちは。HOME'SのiOSアプリ開発チームの高橋です。 ネクストでは毎月末に、もくもくiOS勉強会を開催しております。 弊社のiOSエンジニアも参加し、お菓子などをつまみながら、それぞれ持ち寄った課題をもくもくと取り組む形式です。 もちろん参加者同士で情報交換も可能です。 次回は 10/27(火) になります。 mokumoku-ios-at-next.connpass.com iOSをバリバリ開発されている皆さん、これから始める皆さん、ネットワークを広げたい皆さん、一緒に勉強してみませんか？ 前回は1周年記念LT大会！ 弊社のiOSもくもく勉強会は先月で1周年を迎えました。 それを記念して、前回だけ特別にLT大会を開催しました。 登壇いただいた方の発表をご紹介したいと思います。 Xcode効率化 成田元輝 Xcode tips from Motoki Narita www.slideshare.net 弊社の成田の発表です。Xcodeの便利なショートカットやプラグインをご紹介。 こういったことって知るきっかけが意外と無いんですよね。 自分が知らなかったショートカットもチラホラ。 これで開発が捗りそうです。 Swiftでの関数型プログラミングについて考えていること @akio0911 Swiftでの関数型プログラミングについて考えていること from Shingo Sato www.slideshare.net 関数型プログラミングの導入的な話から、Swiftで書く際のポイント・テクニックについてご紹介いただきました。 各関数を部品として扱えるように定義できれば、様々な拡張ができることがわかりました。ライブラリを作成する際に参考になりそうです。 Mix and Match Swift and Objective-C @gooichi Mix and Match / Swift and Objective-C from Goichi Hirakawa www.slideshare.net SwiftとObjective-Cのコードを混ぜて書く際のノウハウをご紹介いただきました。 SwiftのコードをObjective-Cから呼び出す際、Objective-Cで非互換の機能は使えません。つまりSwiftの設計がObjective-Cに引きずられるため、Swiftの良さが十分に発揮できない可能性があります。 Objective-CからSwiftへの移行を考えている人は多いと思いますが、段取りに注意した方がよさそうです。 自作アプリを watchOS 2 対応した話 〜FastCheckin編〜 @koogawa 自作アプリを watchOS 2 対応した話 〜FastCheckin編〜 from Kosuke Ogawa www.slideshare.net watchOS 2対応時の問題を共有していただきました。 watchOS 2のアップデートはかなり大きい変更で、弊社のエンジニアも苦労していました。いろいろ共感できる内容でした...お互い苦労しましたね。 以上、前回のLT大会のご紹介でした。 次回はもくもく会に戻ります！ 次回は10/27（火）で、 もくもく会形式に戻ります！ mokumoku-ios-at-next.connpass.com ぜひ一緒にもくもく勉強しましょう！！

こんにちは、HOME'Sでマークアップをメインに最近は担当サービス全体の改善などいろいろやっている、オガワです。   突然ですが、みなさんは「テスト」って言葉にどのような印象を持っていますか？ 私はこの言葉を聞いただけで気分が沈みます。学生時代の苦手な教科の問題用紙を思い出します。そのせいなのか「ユーザビリティテスト」という言葉があまり好きではありません。 「ユーザビリティテストのテスト対象はサービスだ」ということがわかっていても、「テスト」という言葉をきくと、なんとなくテストしている人の能力を試されているような気分になってしまうのです。 なので、自分がユーザビリティテストを行うときはなるべくこの言葉を使わないようにしています。   さて、どういう言葉を使うようにしているか？とのまえに、私が行っている業務についてお伝えしたいと思います。   ユーザビリティテストを行う事になった経緯 私はクライアント向けのサービスを開発しており、開発したサービスの利用者はクライアントになります。 開発したサービスは直接クライアントにご利用いただいていますが、そのサービスをクライアントに説明したりサポートをしている営業メンバーやカスタマーサポートのメンバーがいます。 「提供するサービスは利用者に優しいことはもちろん、関わる社内メンバーにも優しいサービスにしたい。そのためにメンバーの業務を知ろう。（あわよくば営業メンバーとクライアントの橋渡しとなるようなサービスにしよう）」と思い、営業メンバーへのヒアリングを行ったことがあります。 なぜヒアリングを行おうと思ったかというと、私が所属している部署はものづくり職種で構成されており、営業職種は異なる部署なので、お互いの業務のことを理解しあっているとは言いがたい状況です。 私は特に、、、ということかもしれませんが、今まで営業職を経験したことがないので、営業メンバーがどうクライアントと関わっているか、どういった思いで営業をしているのかを想像してもよくわからないというのが本音でした。   幸い開発中のサービスがプロトタイプとして動かせるような状況になったこともあり、利用者のことをよく知る 営業メンバーへヒアリングを行いがてら、開発中サービスのユーザビリティテスト を行うことにしました。   期間中の全体的なスケジュール 当初からできるだけ多くの営業メンバーに参加してもらおうと思っていたので、継続的に行えるスケジュールをたてる必要がありました。 そのため、営業メンバーの通常業務サイクルになるべく影響が出ないようにヒアリングする日程を決め、その日に2~3名のメンバー個別にヒアリング＆ユーザビリティテストを行うことにしました。   そのとき計画したユーザビリティテストのざっくりした流れはこちらになります。 テスト設計をし、2~3名のメンバーにその内容をテスト、そのテスト結果を分析、の流れを一週間とし、このパターンを数ヶ月続ける計画をたてました。   実際、数回テストを続けると、次のような流れができてきました。 テスト設計からテストを行い、その結果をうけ、改善が必要な箇所に改善案を仮実装、次週に同じ内容でもう一度テストを行う。そして改善されたか確認し、改善された内容を本実装していく流れです。   実際には継続的にテストを続けていったので、このような流れになりました。  仮実装したものを本実装する期間と、次のテストの設計期間を同時並行ですすめ、その週はテストを行わない。次の週に設計したテストを行い、、、、というサイクルです。   テストを行わない週をつくった理由は、次のテスト設計をするためでもありますが、仮実装で結果が良かったものを本実装する際にリファクタリングする期間を設けたかったからです。 仮実装したものをそのまま本実装していくと、バグが発生しやすかったり理解や修正が難しいものになってしまうことは今までマークアップをやってきた経験上明らかでした。 あとでリファクタリングできる期間があるとわかっていれば、仮実装の段階ではスピードを優先して開発ができます。 次のユーザビリティテストへ向けた結果分析と改善案仮実装の時期と重なった期間ですが、本実装へのリファクタリング期間を設けたことは、仮実装のスピードを速める結果となりました。   このようなパターンで数ヶ月、途中スケジュール的にきつめな時もありましたが、できる限りこのスケジュールを続けていきました。 継続的にユーザビリティテストを続けてみてよかったところはかなり多くありましたが、今回の本題からは外れてしまうので、またの機会があれば紹介したいと思います。   ユーザビリティテストの内容 今回の目的が「営業メンバーへヒアリングを行いがてら、開発中サービスのユーザビリティテストを行う」といったものだったので、営業メンバー1人1人別々に時間を用意し、じっくりとお話をうかがうことにしました。   1人に対して60分。内訳は業務のヒアリングを20分、開発途中のプロトタイプを触ってもらうのに15分、プロトタイプの感想とともにヒアリングを20分というのが主な流れでした。 15分のユーザビリティテストでは行えることがかなり限られてきます。 そのため、テストをする機能をひとつに絞り、その機能を使う利用者の状況をシナリオに起こすといったテスト設計を行っていました。範囲を小さいテストに設計したことが、何度もテストを行うことを可能にしていたと思います。 また、時間の比重をご覧いただくとわかる通り、 ユーザビリティテストというよりも、業務内容のヒアリング中心 の時間配分になっています。 ということもあり（やっとタイトルに関係した内容になってくるのですが）「ユーザビリティテスト」という言葉を営業メンバーに伝えることに非常に抵抗を覚えました。かといって「ヒアリング」という言葉では営業メンバーに『何のためのミーティングなのか』が伝わらないなと思い、なんとか一言で簡潔に伝わる言葉はないかと考えました。   「ユーザビリティテスト」のかわりに使った言葉 前にも書いたように、 今回の目的は「営業メンバーへヒアリングを行いがてら、ついでに開発中サービスのユーザビリティテストを行う」こと でした。 もう少し詳しく営業メンバーに開発中サービスをつかってもらう目的を整理すると 開発中サービスを肴にしてクライアントや営業メンバーの業務について気軽に話してもらいたい 開発中サービスの基本的なユーザビリティーの問題点もみつけたい です。 ユーザビリティテストではない、単なるヒアリングでもない、どういう言葉がしっくりくるだろう？と考えた結果、この時は 「開発中サービスのトライアル」 という言葉を使うことにしました。   さいごに 様々な目的で様々な手法が紹介され、社内でも多くの手法が広く使われるようになってきたなと感じています。手法のやり方を知ると、その手法を行う目的が曖昧になったり、その手法を使う目的を共有できているつもりになってしまうことがあると思います。 「ユーザビリティテスト」という言葉ひとつとっても目的は多種多様です。   今回紹介したプロジェクトではかなり大掛かりに社内ヒアリングを行いましたが、この案件以降もプロトタイプを使っての社内ヒアリングを気軽に行うことは多くあります。 その際も「ユーザビリティテスト」という言葉は使わず、「こういう目的（課題）のためにプロトタイプを使ってみてほしい」と目的を伝えるようにしています。   「何のためにこの手法を使うのか」 、それを自覚し、チームメンバーに共有する意味でも、あえてその手法名を使わず 『目的にふさわしい言葉を使ってみる』 というのも良いのではないのかな、と思っています。

こんにちは、HOME'Sアプリのデザインをしている、こいずみです。 HOME'Sはこの度、watchOS2発表に伴いWatchアプリをリニューアルいたしました！ Apple WatchのUI/UXデザインの経験を通して、学んだことや感じたことなどをご紹介しようと思います。   「IOS版 HOME'Sアプリ」DLはこちら   Apple Watchだからこその機能     watchOS2対応アプリでできることは主に3つです。 ・新着物件の通知を受け取る ・物件を確認する ・気になる物件をお気に入りに追加する iPhoneで希望の条件を保存しておけば、その条件に合った新着物件通知を受け取ることができ、物件の概要を確認できます。 気になる物件をお気に入りに追加すると、iPhone側にその情報が引き継がれます。 さらに Handoff機能 (※)によって、iPhoneアプリ側で物件一覧やお気に入り一覧に自動的に遷移して、Watchで見た物件の詳細情報を見ることが出来ます。 (※)Handoff-ハンドオフとは、Apple製のデバイス間で途中までやっていた作業を簡単に引き継げる機能です。   ちなみにリニューアル前のwatchOS1対応アプリは、iPhoneアプリの機能である「家賃相場」をキーワードに、引越しを考えている人がふと「この街いいな」と思った時、家賃相場を手元でパッと見てもらい、「住めそう！」と思うキッカケになればという想いで作りました。 お楽しみコンテンツとして家賃相場クイズがあり、クイズに正解するとホームズくんから素敵な称号がもらえます。まだOS1だよって方は、ぜひ遊んでからアップデートしてみてくださいね♪     Apple WatchはミニマムiPhoneではない デザインをするにあたってWWDCの配信映像をはじめとした色々なドキュメントを見ていくうちに分かったことは「WatchはミニマムiPhoneではない」ということです。 WatchはiPhoneアプリのサブという立ち位置が理想であり、画面はとっても小さいので「操作が簡単」で「ひと目見れば分かる」のが望ましいようです。 大量の文書や画像を見たり複雑な操作をするのは、やっぱりiPhoneが向いていると思います。   Apple Watchを使うユーザーメリットってなに？ watchOS1では、どちらかと言えばお楽しみコンテンツとしての役割を主に考えていましたが、watchOS2ではアプリ本来の目的である「住まい探し」にフォーカスをした形になりました。 賃貸・売買に関わらず住まい探しをする人が欲しい情報は 「希望条件に合う物件情報」 だと思います。 忙しい日常の中で、日々変化する物件情報を毎日チェックするのはとても大変だけど、良い物件を逃したくはない！そんなとき、HOME'SのiPhoneアプリにある「条件保存」の機能を使えば、 あらかじめ保存しておいた希望条件に合う物件の新着お知らせを受け取る ことができます。 これがWatchに向いていると思いました。Watchでタイムリーに新着物件の情報を受け取ることができれば、良い物件をより逃しづらくなります。 iPhoneとApple Watch、それぞれの役割をはっきりさせる 通知を受け取れるだけでは結局iPhoneを取り出さなければならず、ユーザーメリットはあまり向上しません。そこで、通知を受け取ったらそのまま物件を確認して、気になる物件をお気に入りに追加するところまでWatchで出来るようにしました。 物件に関する情報は、とても細かくて量があるので、Watchの小さい画面でその全てを確認するのはかなりツライです。とはいえ詳細を見ずに問合せはできないので、そこはiPhoneにお願いすることにしました。 あとは、この一連の流れを如何に簡単に完了できるかを考える必要がありました。   情報をApple Watchに最適化する 繰り返しになりますが、Watchの画面はとても小さいです。Watchで受け取る新着物件は保存した条件を元に配信しているため、 ユーザー自身が予め決めておける条件は極力表示せず、画面をシンプルに することに努めました。 では、ユーザーは何を見ればお気に入りに追加するかどうか判断できるのでしょうか？ iPhoneの物件詳細画面をパーツごとに分けて、Watchに表示するか否かを選別していきました。   それぞれについて考えたことは以下です。 A お気に入りボタン Watch Appの大事な機能 Bの物件種別 ユーザーが条件を保存する段階で、賃貸か売買かは決まっていることが多い C 物件名 物件名で住み替えを左右されることはあまり無い D 物件写真 大事な判断材料ではあるが、大量の画像は読み込みが遅くなる問題もある E 問合せボタン Watch Appから問合せはしないのでカット F 詳細情報 全ては細かすぎるが、価格など最低限はないと判断できない G 所在地図 駅徒歩分数で条件を絞っているユーザーも、駅のどちら側なのかなど、大まかな所在地が分かるとより判断しやすい 住所や路線情報などを文字で載せるより、小さい画面では地図のほうが直感的でわかりやすい H こだわりの設備・条件 ユーザーが条件を保存する段階で、ある程度絞っているはず   結果、Watchに実装・表示するのは ・画像１枚 ・価格（家賃） ・所在地図 ・フォースタッチでお気に入り追加 の４つとなりました。   複雑な操作はホントに向いてない 画面はやっぱり小さく感じます。女性の指でもミスタップしそうです。 WWDCのセッションビデオでも以下のことが繰り返し言われていました。 タップエリアは分かりやすく大きく、というのがWatchでは大事なポイントになっています。   腕をあげっぱなしは結構疲れる 小さい画面で長いこと操作をするのはとっても疲れますし、操作を完了するまでが長いと腕が痛くなってきます。そのようなコンテンツでは、結果的にユーザーは離れていってしまうので、作り手側がWatchというデバイスの特性をしっかりと理解して、見せるものと見せないものを的確に判断することが大事だと感じました。   通知はiPhoneよりも割りと気づく iPhoneの通知は気づいたら溜まっていることがよくあるのですが（私だけでしょうか？）Watchは手首にピッタリくっついているため、通知はiPhoneより圧倒的に気づきやすいのではないかと思います。   まとめ Watch Appの開発はエンジニアさん泣かせの様々な制約があります。 デザイナーとしても、iPhoneでできるから大丈夫と思っていたことができなかったり、小さな画面のなかの情報設計など、なかなか苦労するポイントが多いと思います。 でも、新しいことにどんどん取り組めるのがこの世界の楽しみです。 今はまだ持ってる人の方がめずらしいAppleWatchも、あっという間にみんなが当たり前に持っているものになるかもしれません。 そんな発展の過程に参加できるのはとてもワクワクしますよね。 大事なのは、デバイスを理解することと、ユーザーを理解すること。 これを繰り返し繰り返し続けていくことで、プロダクトをどんどん良い方向に育てて行きたいですね。

みなさんこんにちは！エンジニアの島村です。 8/22、23の2日間で行われた、音楽をテーマにしたハッカソン、MUSIC HACKDAY TOKYO 2015に参加してきましたので、その様子を少しレポートしてみたいと思います。 Music Hack Day Tokyo 2015 www.musichackday-tokyo.org あ、音楽と言えば弊社子会社から先日リリースされた音楽のサービスがありますね！！！ その名もLifull LiveMatch！ ライブの同行者を探すアプリ「Lifull LiveMatch(ライフルライブマッチ) www.lifull-livematch.com ライブの同行者を探せるiOSアプリですので、ライブ・フェス好きの人必見です！是非ダウンロードしてみてください。 MUSIC HACKDAY TOKYO 2015 宣伝はこれくらいにして、さっそく本題です。 会場は六本木のヒルズでした。 会場はこんな感じ↓ www.flickr.com www.flickr.com ハッカソンにあたっては数々の企業からAPI提供がありました。 Spotify、gracenote、YAMAHA等の音楽系のAPIから、JINSのメガネやomronの画像認識センサからpepperまで、直接は音楽と関係ないものの組み合わせることで面白いことができそうなものまで様々です。 つくったもの その中で我々のチームはJINS様ご提供のJINS MEMEとSpotify様ご提供の音楽ストリーミングAPIを組み合わせた、DJ MEGANEというサービスを開発しました。 サービス概要はこちら↓ http://hacklog.jp/works/3384 JINS MEMEで検出できる首を傾けたときの加速度を利用して、JINS MEMEをかけた利用者のノリを検出 利用者のノリによってSpotifyAPIで再生している楽曲のテンポや音量をコントロール 利用者のノリがいい楽曲であれば、気に入った曲であると判定し、次の曲も同じアーティストの楽曲を再生する こういった機能を搭載した、ただただDJがかけた曲にノルだけでなく、オーディエンスのノリ次第でクラブハウスをコントロールできる！ オーディエンスがクラブハウスをHackする未来を想定したサービスとなっております！！！！！ ハッキングの様子 では、当日のハッキングの様子を振り返ります。 我々全然 余裕がなくて 写真を撮ってなかったので、運営のみなさまが撮ってくださった写真をふんだんに利用させていただいております。ありがとうございます！ www.flickr.com www.flickr.com アイスブレイクやAPI紹介タイムが終わり、アイデアソン & ハッキングタイムに入ります。 www.flickr.com 実は始まる前からJINS MEMEと光るシューズOrpheを利用したサービスの開発を考えていたわけですが、当然台数には制限があり、ジャンケンによる壮絶な争奪戦に・・・。 結果Orpheは敗れたものの、JINS MEMEは見事勝ち取りました！さすがLifull LiveMatch社長！つしま！ 開発する我々↓ www.flickr.com ごはん↓ www.flickr.com 夜中のレッドブル↓ www.flickr.com 24時間ハッカソンなので、会場も24時間オープン！、、なのに続々と帰る他のチームの人々・・。 JINS MEME使うとか言ったのに、アプリの開発経験がほとんどないメンバーが集まってしまった我々は当然帰る余裕があるはずもなく、夜通し開発開発。。 ソース？見せられません。 夜明けのわれわれ。真ん中の間抜け顔が私です↓ www.flickr.com 開発もラストスパート！ www.flickr.com 成果発表会 そして15時ハッキングタイム終了！成果発表会に入ります。 成果発表会は自分たちの発表の順番待ちにドキドキしつつ、他チームのプロダクトに驚いたり、プレゼンに爆笑させられたり、まさかの丸被り事件に絶望したり、、とても楽しい時間でした。 発表会の会場の様子↓ www.flickr.com www.flickr.com 審査員のみなさま↓ www.flickr.com 発表する我々↓ www.flickr.com www.flickr.com 発表の様子を撮影したおどるおじさんの動画があるんですが、おじさんNG出たので割愛します＞＜ 発表会後の我々↓ また来年 と、楽しかったのはここまで。 この後我々は審査発表会で見事に現実を叩きつけられ、すごすごと会場を後にするのであるが、その様子はとても企業ブログには載せられないよ！ 最後に。このようなエキサイティングなイベントを開催してくださった運営の皆様、API提供企業の皆様、本当にありがとうございました！また来年リベンジします！

こんにちは。おうちハッカーの石田です。 8/8・9につくばで開かれた、ニコニコ学会βのサマーキャンプに行ってきました。 今回はそのレポートをお送りします。 きっかけ 今年初めて、ニコニコ超会議に参加したのですが(そういえば こんなの 出展してました。)、そのときに ニコニコ超学会β なるブースをふらっと覗いたところ NHKだけが受信できないアンテナや、女子大生のにおいの香水、スマホゲームの自動化、眼鏡によって違うものが映るテレビなど、それぞれが所属している機関では研究できないだろうけど、みんなが興味のありそうなことを、持ち合わせた技術や知識で研究した成果がポスター発表されていました。 高い技術力でバカなことを全力でやるのが好きな僕は、 「なにこれ、すごく楽しいんだけれど！！ 」 と興味を持ち続けていました。 いまいちニコニコ学会βの実態をつかめていなかったのですが、とある知り合いからFacebookで サマーキャンプ のお誘いが来ていたので ニコニコ学会に迫るチャンスだと思い、参加を決めた次第です。 開催まで 場所は、筑波研修センターで行われました。秋葉原までいき、つくばエクスプレスで初つくばです。 参加者は40人ほど。こんな感じの部屋で、開会のあいさつが行われました。 開始～テーマ決め 開会のあいさつ、全員の自己紹介をしたあと、議論をより活発にするため、いろんな分野の権威の研究者からのインプットセミナーがありました。 粒子加速器の話 シュタインズゲートを見たことのある人はおなじみの、大型円型加速器です。 次の日に見学に行く、高エネルギー加速器研究機構の岡田さんがお話ししてくださいました。 加速器といったらロマンです！もうワクワクがとまりません！ つくばにある全周3kmの加速器。デカい・・・ みんなのナノテク 僕はナノテクというと、攻殻機動隊のナノマシンが浮かんできてしまいます。 こちらも翌日に見学に伺う、物質材料研究機構の有賀さんから。 分子を手でつかんで操作できるような研究をしてらっしゃるそうです。スゴイ！ 難しいことを難しい方法でやるのではなく、誰でもできるやり方で難しいことをやることに意義があるとのこと。カッコよかったです！ 曼荼羅を描くこと 系統と分類を研究されている、進化学者の三中さんから！　世界中の系統図を調べて本を書かれています。 「万物は蒐集の対象である」　「人は生得的に分類者」とのことで、古来より人は集めて分類するのが好きみたい！ 食パンを止めるクリップのコレクターが作った系統樹。生物じゃなくとも系統が存在し、系統図が作れてしまう。 こちらは、醤油の入った鯛の入れ物のコレクターが作った、醤油鯛の解剖図。詳しすぎてスゴイ・・・ 最近、醤油鯛を見かけないですね。絶滅危惧種らしいです。 人は古来から物を系統・分類して、図にまとめてきた。昔からインフォグラフィックスは盛んだったみたい。むしろ生物学は途中から系統樹を使い始めた新参者らしい。 リクルートテクノロジーさんのテーマ案 このニコニコ学会βのスポンサーをしているリクルートテクノロジーさんから、会社概要とアンカンファレンスで話すテーマ案の提示。 リクルートとIngressが組んだとしたら？　テクノロジーでエロを追及したらどうなるか　リモートワークはなぜ普及しないか、就職活動などの案を提示くださり、結果的にいくつか採用となりました。 *1 アンカンファレンスで話すテーマの案だし インプットが終わったところで、アンカンファレンスで話し合うテーマを決めます。 アンカンファレンスについては、こちらを参考にしてもらえればイメージをつかんでもらいやすいかと思います。 会議じゃない会議？：アンカンファレンス in ニコニコ学会β合宿 | アイデアキャンプ アンカンファレンスについて - 高専カンファレンス Wiki インプットセミナーを受けて、自分が話したいことをポストイットに書いて、ホワイトボードにペタペタと貼っていきます。 各自が張ったものを、近いものをまとめて、整理します。 結果、初日に話し合うテーマの一部はこのようになりました。 アンカンファレンス ここから部屋を３つに分け、自分が話したいテーマの部屋に行って議論に参加します。途中で別のところに移ってもOKだそうです。 25分を1セッションとして、初日に5×3セッション+ナイトセッション、2日目に2×3セッション行われました。 どこも議論が白熱して、25分経っても終わらず、どんどん予定が後ろ倒しに・・・ こちらはナイトセッションで熱く議論してる様子。何を議論したのかは内緒です笑 ここでは、僕が参加したセッション、その他気になったものについてざっくりまとめたいと思います。 リモートワークはなぜ広まらないか 業務内容的にできないものがある セキュリティの関係で持ち出せない 関係者が多い複雑な仕事 接待など、人と人とのつながりが大事な仕事 内容的にできるものは、なぜできない？ 情報の伝達が遅い 情報量が少ない 上記二つは、技術の進歩で解決しそう 会ったことがない人だと、意図したことが伝わりづらい 海外とリモートで仕事してる人の実感 文化が違うと伝わりづらい 顔を合わせて話すと、表情や手振りから伝えやすい 完全に初めからリモートだと厳しいが、一定期間は一緒に仕事し、リモート移行するのが現実的 ニコニコ学会の今後 5年間で終了すると決めていたが、今後どうするか 運営の負担が大きく、今の形で続けるのは厳しい 期間が決まってるから頑張れた、という感じ ニコニコ生放送の準備大変 ビジネスモデルが作れず、厳しい 各地で展開するモデルも難しかった 予定通り5年で終了する 派生でできた分科会は継続する 同窓会という別の形でやるかも イングレス×リクルート イングレスを初めとした、ゲーミフィケーションを用いてリクルートのサービスと連携できないか イングレスの面白さは、地図情報とコミュニケーション イングレス自警団 イングレスしながら夜道歩いてると、警察に職質される イングレスしながら地域の見回りしたら、犯罪防止にいいのでは？ 災害時の避難場所を回るミッションを作って、防災に役立てないか 商業色が強くなってくると、ユーザーには抵抗感が生まれる 伊藤園、ローソンなどがイングレスと提携。店舗や自販機がポータルに 商品の2個に1個にシール、イングレスのアイテムに ソーシャルゲームのガチャみたいで、嫌な感じ 社会問題を解決できるものがよい 徘徊老人を移動ポータルにして、みんなで探せばよいのでは コミュニケーションに目的意識がある、社会性を持ったゲーミフィケーションのサービスがよさそう 哲学と科学 情報技術が発達してきて、最終的にはプライバシーとして何を守るべきなのか 保険料の違い 地域ごとに事故率違うから保険料違う 遺伝的特性で保険料変えるのはなぜダメか？ 自分では変えられない、生得的なもので区別するのはNG。住所は変えられる 哲学は現代で役に立つのか 哲学とは？ *知の探究の方法 昔に確立された論理学が、今のコンピュータの基礎になってる 議論をするうえでの共通認識を作るのに重要 恋愛事情 結婚精度必要か 男性、養わなければいけないという責任感で後ろ向きに 女性、養ってもらえる人を選ぶ 自由に子づくりできる社会？ 少子化対策 子育てをどうするか 暇になったおじいさんおばあさんに子育てしてもらえないか ライフハック エスカレータの片開け問題 片側歩行を設計で想定していない 社会的弱者が不利益を被る エスカレータの設計変更で片側開けができない設計にできないか JRで実験してほしい エアコンの温度調整 大人数の場所で何度に設定するか 暑がりの人、寒がりの人、いろいろ 空気を読みあってしまう 椅子を冷やしたり、ウェアラブル端末で状況を把握できないか 見えない何かのために空気を読むより、見える誰かのために考えて行動しよう 見学 アンカンファレンスが終わった後は、みんなで高エネルギー加速器研究機構と物質材料研究機構へ施設見学へ！ 高エネルギー加速器研究機構 憧れの加速器見学へ！ 加速させる部分の長さが約3kmあり、これだけ大型のものは、スイスにあるCernのLHC(大型ハドロン衝突型加速器)に次いで２番目だそうです。 こちらの加速器を用いた研究で、CP対称性の破れを証明し、2008年に小林誠先生、益川敏英先生がノーベル賞を受賞しました。 こちらが光速の99.999%以上に加速した粒子を衝突させる場所。とても高い設置の精度が求められるようで、地震がおきたら設置しなおすのに2年くらいかかるとか。もう規模がロマンすぎる！ そしてこちらが衝突した粒子が分裂して飛んでいくのを観測する部分。これを先ほどの衝突部に移動させて観測します。 もう2,3ヶ月で設置し終わり、閉じられてしまうので、内部をここまで見られてラッキーでした。 物質材料研究機構 物質材料研究機構では、世界最先端のナノテク研究を行っています。 研究や施設の説明を伺った後で、施設見学をさせていただきました。 分子を操作する設備や The 研究室 気になった看板。ビジネスでも会話データを取ってみると、コミュニケーションの多い人が成果を残してるというデータもありますね。研究といったら一人で黙々としてるイメージがありますが、周りの人とコミュニケーションをとることが大事なのですね。 行ってみての感想 アンカンファレンスをやる前は、どんなお題が出てくるのか、その場で土台もなく議論を始めて成り立つものなのか、と不安に思っていました。 しかしいざやってみると、さすがは議論することになれている研究者たちだけあって、ちゃんと議論が進んでいきます。 様々な分野の研究をしている人が集まって議論をするので、自分が思っても見なかった考えが飛び出してきて、とても刺激になりました。 社会人になってからは、普段はIT系の人たちとの交流が多く、その最先端の情報ばかりを追い求めていたのですが、今回いろんな分野の人とお話しすることができて、自分の世界や考え方がどんどん小さく、狭くなってきてることに気付かされました。 ナノテクノロジーや理論物理学の最先端、科学哲学といった研究寄りのところから、空気の読み方、Ingressの活用法、恋愛事情といった身近な話題まで、みんな真剣に議論するのはとても楽しかったです。学生時代に持っていた知的好奇心が戻ってきた気がしました。 ある分野について上達するには、そこに資源を集中させることが大事ですが、視野が狭くなりがちなので、気を付けていきたいものです。 またこのような自由で多様性のある人たちとの議論から、柔軟な発想で面白いテーマが生まれ、ニコニコ超学会のような面白い研究成果に繋がっているのだと思います。学会は今年で終わってしまうようですが、なんらかの形で続けていってもらいたいものです。 *1 : その数日後、リクルートが在宅勤務が可能になる報道がありました。素晴らしい。

こんにちは。おうちハッカーの石田です。 最近、IoTが流行っており、様々なデバイスが発表されています。今年のMaker Faireでは、去年と比べて圧倒的にIoTデバイスが多く、これからクラウドファンディングに出そうとしているチームも多々ありました。 それらIoTデバイスを制御するためのプラットフォームが次々と発表されています。 最近発表されたスマートホーム・IoTプラットフォーム Yahooが発表したMyThingsや Yahoo! JAPAN、IoT時代に向けた事業者向けプラットフォーム構想を発表 新たな体験を提供するユーザー向けスマホアプリ「myThings」も公開 pr.yahoo.co.jp Nestを買収していよいよ発表されたGoogleのWorks with Nest Google、スマートサーモスタットNestをハブとするホームオートメーション・プラットフォームを発表 | TechCrunch Japan jp.techcrunch.com ネット接続型デバイスの企画開発を行うStroboのIoTプラットフォーム 普通のベッドやクッションをスマートに変える「IoTプラットフォーム」Strobo IoT Suiteを公開 thebridge.jp など、私が知る限り３つのプラットフォームが発表されました。 多すぎるプラットフォーム もともと私がよく使っている IFTTT や、iOSの HomeKit , 日本の家電メーカーなどが推進している ECHONET Lite などがあり、かなり混沌としてきました。 プラットフォームがたくさんでることは、スマートホームやIoTが賑わい、認知度向上の観点からは良いかもしれませんが、ディベロッパー、ユーザーにとっては好ましくありません。 IoTデバイスのディベロッパーにとっては、どのプラットフォームに入ればいいのか悩みのタネになります。そのデバイスが売れるかどうかは属したプラットフォームの成長に大きく関わってきます。複数のプラットフォームに対応することもありますが、その分開発コストやライセンス料がかさむでしょう。 ユーザーにとっては、複数のプラットフォームを使うのは面倒なので、どれかに統一したいと考えるでしょうから、どれを選べばいいのか分からなくなります。先細りのプラットフォームのものを揃えてしまうと後々大変です。 そこで、そんなディベロッパーとユーザーのために、それぞれのプラットフォームの勢力図と、特性をまとめてみました。かなり私の独断と偏見が混ざっていますので、お気をつけください。 勢力図 それぞれの特徴 プラットフォーム コアデバイス アシスタント 自作デバイス対応 会社 IFTTT スマートフォン なし Makaer Channel IFTTT HomeKit iOSデバイス Siri なし Apple Works with Nest Nest/Android Google Now IFTTT経由 Google Amazon Echo Amazon Echo Alexa API / IFTTT Amazon SmartThings スマートフォン なし おそらくなし Samsung MyThings スマートフォン なし IDCFチャンネル Yahoo! Japan ECHONET Lite スマートフォン 無し なし 日本の家電・通信メーカー Strobo IoT Suite スマートフォン なし なし Strobo それぞれのプラットフォームを比較するうえで重要な軸が３つあります。 1つ目は、家に置くコアデバイスがあるかどうか、です。中心となるデバイスがいつも起動しており、家や人の状況を把握できることは、より賢いオートメーションを実現するうえで重要です。 また、中心的なデバイスが普及すれば、それと連携するプラットフォームのものを揃えようということになりやすいです。 2つ目は、アシスタントの有無です。最近バズってる「人工知能」とも言えるでしょう。ユーザーが自分でアクションを設定するのではなく、アシスタントが推薦してくれたアクションで使えるのであれば、一般ユーザーにも受け入れやすいと思います。 3つ目は、自作デバイスに対応しているか、です。おうちハッカーに限らず、ArduinoやEdisonを用いてデバイスを作り、連携させたい人は少なくないと思います。こういった自作デバイスを製品化するものもあるため、将来の対応機種の広がりが期待できます。 それぞれをおうちハッカーの視点から IFTTT 現状ではIFTTTが最も使えます。既存デバイス・サービスとの連携の多さもさることながら、Web APIが公開されているデバイスであればMaker Channelで使えるのがとても便利です。またAmazon EchoとGoogleと連携していくそうで、かなり信頼感があります。 唯一の不満は、条件設定がシンプルすぎることです。IFTTTの名前の由来の、"If This then that" のThis(トリガー)とThat(アクション)を選ぶだけというシンプルさが売りなのですが、トリガーをもう少し複雑に設定したくなります。例えば、「午後７時以降に自宅の半径300mに入ったら」などです。 MyThings 先日発表されたMyThingsはIFTTTとほぼ同様のサービスと見受けられますが、IDCFチャンネルという独自のクラウドでサーバー構築を支援してくれる仕組みがあり、自作のデバイスを連携させたいユーザ向けに伸びてくることが期待されます。IDCFチャンネルを始めるときには3000円分のクーポンが付いており、月500円から始めることができるそうです。しかしながらMakerFaireTokyoでYahooの人に話を伺ったところ、きちんとIoTデバイスを運用するには500円のサーバーだと厳しいとのことです。 Amazon Echo Amazon Echoは既にアメリカで販売されている音声認識アシスタント付きスピーカで、正確にはプラットフォームではありません。しかしSiriのようなアシスタント機能があり、これを中心に音声認識をトリガーとして他のデバイスと連携できることから、表に追加しました。APIを公開しており、他のデバイスとの連携を強化していこうとしています。Amazonは1億ドルの支援ファンドでAmazon Echoのエコシステムを築いていく予定です。まだ日本では発売されていませんが、かなり期待しています。 HomeKit 1年前に発表されたiOSの規格ですが、まだほとんど対応製品が発売されておらず、これからのプラットフォームです。自作デバイスの連携はAppleの性質的にまだまだ先になり、当面はAppleの認証を受けた会社のデバイスのみになりそうな印象です。 またSiriと連動して、家電の操作ができることが強みになりそうです。iPhoneの使用ログからユーザーの行動を予測して、IFTTTのように自分で設定せずとも、心地よい家電操作を行うことが考えられます。しかしAppleはユーザーのプライバシーに対して最大限配慮してアシスタント機能を作っていく方針なので、ユーザーを特定するような情報は使いません。従って真反対の方針のGoogleのそれよりも利便性が落ちるかと思われます。 Work with Nest Nestを買収 したときから、そのうち出すだろうと思っていましたが、ようやく発表されました。まだ発表されたばかりですが、既にNestと連携するデバイスが多々あり、さらに海外の有力メーカーが名乗りを上げています。 最も便利であろう機能が、GoogleNowとの連携です。メールや位置情報、検索履歴などの大量の情報を用いて、設定いらずの強力なオートメーション化が可能になると思います。 またIFTTTと連携しているので、自作デバイス連携も可能です。 強力なコアデバイス、GoogleNowとNestの人工知能、IFTTT経由での自作デバイス連携と、非常に優れており、プラットフォームの中ではWork with Nestが抜きんでていると感じます。 懸念点として、欧米ではサーモスタットは一般的ですが、日本ではそうではなく、Nestの普及に時間がかかりそうなことです。家の室温を一括管理するものなので、家を建て替えたりリフォームしないと付ける機会がありません。 日本の家のエネルギー管理系は、政府が HEMS を普及させようとしているため、今後どうなっていくのでしょうか。 ECHONET Lite HEMS と連携する日本の規格ですが、電力可視化システムや給湯器、エアコン、冷蔵庫といった、なかなか買い換えないが暮らしの中心の家電との連携が中心です。 現在のところ、ユーザー、ディベロッパーに自由はなく、経産省・メーカー主体で進められているので、家電の買い替えや家を建てるスパンでゆっくりと浸透していきそうです。 Strobo IoT Suit 最近発表されたばかりのプラットフォームで、IoTデバイスの開発を容易に行える開発キットやSDKの色が強いです。今後は他社製品との連携を強め、プラットフォームとして展開していく模様です。 正直なところ、他の強力なプラットフォームと比較してメリットが小さく感じます。一部の新しいIoTデバイス専用となる気がします。 まとめ ポテンシャルとしては、Google-IFTTT組が最も高いと思いますが、調べてみて、それぞれ特色があり、将来的には棲み分けして共存する可能性もあると感じました。 最後に おうちハッカーとしてディベロッパーに求めるのは、最低限IFTTTで操作できるWebAPIを公開することです。そうすれば、他のプラットフォームでもIFTTTを介して使えるようになります。 そして、これ以上プラットフォームを増やさないで欲しいです。プラットフォームは勝てば莫大な儲けに繋がるのは分かりますが、それよりも既存のプラットフォームでより簡単に設定し連携できるデバイスを作ってくださると嬉しいです。