あけましておめでとうございます。 おうちハッカー@リッテルラボラトリーの石田です。 画像から何かを検出したい、ユーザーの動きに連動して何か作りたい、なんて思うことがあると思います。 そんなときに、どんな技術を使えばよいのか迷うと思うのですが、そんなときに検討すべきライブラリ、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を介して使えるようになります。 そして、これ以上プラットフォームを増やさないで欲しいです。プラットフォームは勝てば莫大な儲けに繋がるのは分かりますが、それよりも既存のプラットフォームでより簡単に設定し連携できるデバイスを作ってくださると嬉しいです。

　こんにちは！この春から新卒としてAndroidグループにジョインしたねぎこと野村です！2015年7月20日に行われたAndroidのお祭り、 ABC 2015 Summer に参加(とLT大会に登壇)してきたので、今回はバザールブースのレポートをお送りいたします！ Android Bazaar and Conferenceとは ABC 2015 Summer abc.android-group.jp 日本Androidの会が主催するAndroid Bazaar and Conference(ABC)は、最新技術を一緒に聞いてワクワク感を共有するConferenceと、体験するBazaarによって仲間を見つけるためのイベントとしてこれまで開催してきました。今回のABC2015Sでは、これまで以上に参加者同士がその場で技術を「共感」し、次の瞬間には「共創」してしまうようなイベントにしたいと考えています ( ABC 2015 Summer より引用) 　簡単に言うと、Android好きが集まる講演会とバザールとハンズオンのお祭りとなっています。 その中でも今回はバザールブースについてまとめていこうと思います。 講演会の内容が気になる方は暫定的ですが発表資料をまとめましたのでこちらをお願いします。 ABC2015Summer 全会場発表資料まとめ(暫定版) - AcroRabbit shunxnegi.hateblo.jp バザール会場レポート 　バザール会場にはAndroidの最新技術からAndroidには全然関係ないものまでさまざまなブースが出展していました。また、 Smart Plate を用いたスタンプラリーも用意されていました。 豪華なスタンプラリーの景品 　すべてのブースにお邪魔させていただくことは出来ませんでしたが、お邪魔させていただいたブースの中からいくつかをピックアップして紹介させていただきます！ 株式会社セラク 　ハウス内の環境を測定するセンサ、みどりクラウドをAndroid端末から確認や操作を行うことで、農業をもっとIT化して楽に！ということでした。農業がもっと楽になれば、農業に従事する方の人口も増えるかもしれませんね！ みどりクラウド midori-cloud.net IoT ALGYAN(あるじゃん) 　舞子さんのマイコンボードカバーを展示していました。IoTを明るく楽しく世界に広める活動を行っているようです。むき出しのマイコンボードだととっつきにくいけど、こんなきれいなパッケージならつい気になっちゃいますよね。 IoTあるじゃん | 技術との戯れ yseosoft.wordpress.com TechBooster出張所 　既刊の同人誌を販売していました。また、今回もライフサイクルポスター無料配布！弊社に持ち帰って壁に貼って活用させていただいております！ Techbooster | How To Android, WP7, HTML5, Web techbooster.org ロボット部（日本Androidの会 秋葉原支部） 　AndroidでLEDやArduinoを操作したり、SOM(自己組織化マップ)の動画化を行っていました。SOMについての話が弾んだのですが、「ロボットにどうやって実装するんですか！？」ときいたら「考え中です」とのこと。 日本Androidの会　秋葉原支部 android-akihabara.info 株式会社たゆたう 　人と人との関係をより楽しく、より深いものにするサービスの提供を目指して、誰でも簡単に遊べるスマートフォンアプリの展示を行っていました。Android２台とテレビをつないで大戦を行う「対戦型居合切り」はテレビの表示に合わせてすばやくAndroid端末を振るゲームなのですが、簡単操作ですごい楽しかったです。 写真とってもらった 株式会社たゆたう 株式会社ネクスト(弊社) 　ネクストではHOME'SのスマートフォンアプリやWearアプリの展示に加え、今回一番の目玉であるAndroidTVアプリの展示を行いました。AndroidTVアプリはテレビならではの大画面を使った簡単操作で大人気でした(個人の感想)。 不動産・賃貸・住宅情報（マンション・一戸建て）ならHOME'S【ホームズ】 www.homes.co.jp 日本Androidの会 学生部 　活動記録を紹介して、部員の募集を行っていました。そしてなんと、前々から今回のABC2015Summerのために準備していたアプリの紹介を行っていました。今回のABCの情報が全部詰まったアプリで、地図を表示したり、講演リストを表示して、見たい講演をお気に入り登録したりできるものすごい便利なアプリでした！学生のときに出会いたかった！ ABC2015Summer - Google Play の Android アプリ 日本Androidの会 学生部 Pepperコミュニティ 　Pepperコミュニティではペッパーにボクシングさせたり、Pepperにお茶入れさせたりなど、割とハードにPepperを酷使していました。ボクシングはコントローラで対戦できるようになっていて、殴ったりよけたり、すごい楽しそうでした！ つくる女 　つくる女さんたちは女性だけのクリエイター集団！自主制作アニメの放送やフィギュア展示、ステッカーやクリアファイルの配布などを行っていました。技術系が少ないのでエンジニア募集中だそうです。 つくる女オフィシャルサイト【TOP】 南島原市 　南島原市ブースではそうめんの販売や、フシ麺のつかみ取りグランプリなどが！優勝者には豪華景品が！？もはやどこら辺がAndroidなのか！？という感じのブースですごい楽しい時間を提供してくれました！ 南島原市ホームページ www.city.minamishimabara.lg.jp さいごに 　このように、ABCではAndroidにおける最新技術から、Androidに一見関係ないものまでいろいろなブースが所狭しとひしめいていました。Android開発を業務でやっている人から、ほんのちょっと興味がある人、おとなもこどもも、おねーさんも楽しめるイベントなので、次回開催時には今回参加できなかった皆さんも参加してみてはいかがでしょうか！ おまけ ぼくもLTで登壇してきたのでそちらの資料です。 【MIT AppInventor2】続・小学生でもできるAndroidアプリ開発 - AcroRabbit shunxnegi.hateblo.jp

こんにちは、 HOME'S アプリのデザインを担当している、こばやしです。 2015年7月20日(月)に川崎市産業振興会館で行われた、「 Android Bazaar and Conference 2015 Summer 」に参加・出展してきました。 当日はAndroid TV・Android Wearをメインに展示させていただき、沢山の方と触れ合うことができました。お立ち寄り頂けたみなさま、ありがとうございました！ 「Androidを介したテクノロジーの共感からの共創へ」 を今回のテーマとして、各出展ブースではAndroidを用いた色々なコンテンツに触れられ、実装について直接伺うことができました。 今回のテーマにもあるように「テクノロジー」が主題なので、出展・参加者の9割は（おそらく）エンジニア。デザイナーは一握りでしたが 「Androidを使って今こんなことができる」 を知ることは、新しいサービスの発想・想像に繋がり、創作意欲に良い刺激を受けました。 出展だけでなく、一日を通して基調講演やハンズオンも行われており、その中でもGoogleの発表がとても興味深かったので、その中で気になったものを幾つかピックアップします。 「Android と Google Play の最新アプリ開発技法」 グーグル株式会社 デベロッパーリレーションズ デベロッパーアドボケイト 松内 良介 様   アプリパーミッションチェックの変更 Android M以降、アプリのインストール時パーミッション権限についてのユーザーの承認がなくなります。アプリ使用中に必要なタイミングでパーミッションチェックがはいります。ダウンロードだけでなくアップデートも同様なので、それ毎にアプリのバージョンを置き去りにしてしまうユーザーは減ることを期待しているとのこと。ただし、アプリ使用中に都度パーミッションチェックが入ると、ユーザーがコンテンツに集中するのを邪魔してしまう気もしました。 Androidのそもそもの考え方として「1アプリ1機能とし、1つのアプリでユーザーに複雑なことはさせるべきではない」という考え方がありますが、同時に1つの機能を充実させるためにいくつかのパーミッションが必要になってくるケースもあるかなと思いました。バランスが難しいところではありますが、アプリ使用中（その機能を使う初回に限って）は、現状よりユーザーのアクションが増えるのは事実なので、そこの影響がどうでるかを見ていかないといけないなと感じました。 Direct shareによる友人への情報共有が標準化 アプリ内のコンテンツを共有する時、共有アプリを指定できる（制限）できるというもの。最適な共有の仕方をある程度誘導できるのはユーザーの使い勝手向上にもつながると思うのでよい機能ですね！共有アプリが位置取りリストアップされると、それだけで圧倒されてしまうので、沢山の選択肢を用意するのと導いてあげるのとでは全然ユーザー体験が変わってくると思います。そういった思想で現在弊社のHOME'Sアプリでも同様の実装をしている部分があるので、標準として用意されたのはありがたいですね！ Smart Lockによるログインの煩わしさ解消 Googleアカウントを利用していて、同環境で他のアカウントでもログインしている場合、デバイスを横断しての各種ログイン手続きが不要になる機能です。ユーザー心理に配慮したほうがよいセンシティブな部分かなと思いつつも、ユーザー体験は高まる機能ではあると思うので、今後色々なサービスで利用されると思います。やっぱり誰しも手間がかかるのは面倒に感じると思うので。 design support libraryにドロワー追加 ありそうでなかった、ドロワーの標準ライブラリーがようやく登場しました。ドロワーはアプリが提供するコンテンツへのナビゲーションとして機能させるべきなので、扱うサービスによっては少しカスタマイズすることでユーザーにより良い体験を提供できるかなと考えることがあると思うのですが、ライブラリーを使うと細かいカスタマイズが難しいので悩みどころ。実装・メンテナンス工数と相談だが、ライブラリーがある1つの理由として 「UIを整えUXを迷わせないために機能すること」 が目的だと思うので、そこがしっかり守られていれば独自実装でも問題はないのかなと思いました。 Nearby APIによる今後のアプリ展開に期待 自分の近くにいて同じアプリを使っている人を探し、コンテンツなどを共有できる。Google Play Services 7.8が必要ですが、Googleアカウントは不要。個人的にとても興味深い機能で、サービスへの面白い展開ができるのではないかと思います。これを利用した鬼◯っこアプリとか面白そう…。   おわりに 以上ざっくりとですが、気になったトピックスです。 Android×Googleどんどん面白くなってきていますね。今まで実装したかったけど難しい面白いアイデアやサービスが今後どんどんでてきそうですね。Googleの基調講演で松内さんもおっしゃっていましたが、利用シーンを横断してのユーザー体験がどんどん高まり、一般化していきそうです。 ユーザーの気がつかない領域で。 弊社ブースの様子

はろーはろー！チバです。 今回は、2015年5月31日（日）に行われた「DIREXON　ディレクターズハッカソン」の開催レポートをお送りします！ 「DIREXON　ディレクターズハッカソン」とは 株式会社イノセンティブ さんとディレ協こと 日本ディレクション協会 さんが仕掛けるイベント、 ディレクター対象のハッカソン 、その名も「ディレクソン - DIREXON」です…！ www.direkyo.com 今回のお題 今回は、弊社サービス 不動産・住宅情報サイトHOME’S からのお題を2つ提供させていただきました！ HOME'Sサービス開発部門責任者、および現職ディレクターから、オリエンテーションを通じて現状の課題を共有してのスタートです。 お題1. 資料請求数を最大化すべし！ 売買シェアが賃貸に比べると低い現状を課題に、資料請求数を増やす方法を提案してください。 お題2. リアル訪問を最大化すべし！ HOME’Sを見た人による来店を可視化できていない現状を課題に、不動産会社への来店を可視化し、最大化する方法を提案してください。 参加者は2つのお題から好きな方を選び、5人前後のグループ毎にディスカッションしてもらい、最後に課題解決案をプレゼンテーションしてもらう！といった流れでした。 グループディスカッションの様子 この日は5月末とは思えぬ暑さ、それに皆さんの熱気も相まって会場は盛り上がっていました！ （ディスカッションの時間を15分伸ばしたほど） ホームズくんも応援に来てくれてました。 グループ毎に課題解決提案！ グループでディスカッションしてもらった課題解決策をプレゼンテーションしてもらいました。 審査員となる事業責任者の目が光ります。 まとめ 最後の結果発表では、「 どのような点を課題として捉えて広げられたか 」を主な審査ポイントとして最優秀賞を1チーム選ばせていただきました。 常に新しい課題を見つけ、改善・提案していくサイクルを回すことを忘れずに邁進していきたいですね！ また引き続き、このようなミートアップ系のイベントを開催できたら良いな、と考えています。 会社を会場として開催できる可能性、イベント集客できる可能性、さらに業界が活気付く期待の楽しさ！ を知れたので、課題提供側としても学びたっぷり、発見たっぷりで楽しませていただきました。 当イベントへ応募してくださった皆様、主催をして進行を整えてくださった株式会社イノセンティブ様、ファシリテーターや記録を務めて下さった日本ディレクション協会の皆様、参加して会場を大いに盛り上げてくださった皆様、この度は本当にありがとうございました！！

こんにちは、HOME'SのAndroidアプリ開発チームの寒川です。 このたび、総掲載物件数No.1(※1)の不動産・住宅情報サイト【HOME'S】のAndroidアプリを Android Bazaar and Conference - 2015 Summer に出展することになりました！ WearとTVで実現する新しい住まい探し と題しまして、「Android Wearを使ったお部屋の内見」や「Android TVを使っての物件探し」など、今までにない新しい住まい探しを展示しておりますので、ぜひ体験しに遊びに来てください。 出展場所は【4F No.39】になります。 当日会場では、先着でホームズくんステッカーを配布しております。 また、実際に開発しているエンジニアやデザイナーも合わせておりますので、ぜひ Android Bazaar and Conference にお越しの際は、HOME'Sのブースまでお立ち寄りください。 開催場所 川崎市産業振興会館 開催日時 2015年7月20日(月・祝)　海の日 10:00 〜 18:00 Android Bazaar and Conference - 2015 Summer について ABC 2015 Summer abc.android-group.jp ※1 リサーチ・アンド・ディベロプメント調べ(2015.3.16発表)