こんにちは。おうちハッカー@リッテルラボラトリーの石田です。 2016/3/13～3/16まで、アメリカ・テキサス州オースティンで開催された SXSW 2016 Trade Show （サウス・バイ・サウスウェスト トレードショー）に、弊社から製品化が発表されたばかりの GRID VRICK を出展してきました。 SXSWとは？ SXSWとは、テキサス州オースティンで毎年3月に開催される、音楽、インタラクティブ、映画を組み合わせた世界最大級のイベントで、今年で30周年を迎えました。特にインタラクティブ部門におけるアワードは、スタートアップ企業の登竜門とも呼ばれていて、過去にはTwitterやFoursquare、SiriやSpotify等が世間に広がるきっかけを作ったとも言われています。 30周年を迎えた今年は、 オバマ大統領 夫妻が 基調講演 を行いました。 画像は CBSNEWSより SXSW中の街の様子 SXSWの期間中は、オースティンの街中がお祭り状態です。 こんな観覧車が街中に出現したり 楽しい恰好をして歩いていたり 期間中は、メインの通りは歩行者天国となり 夜はあちこちのバーでライブが行われ、活気にあふれています。 Trade Showの様子 今回私たちが出展したのは、 Trade Show と呼ばれる展示会で、世界各国から勢いのある様々な会社・団体が出展しています。日本からの出展も近年増加しており、今年はソニーや富士通、博報堂、東京大学などの団体が50弱のブースを展示していました。 Trade Showは、オースティン市街にある、オースティンコンベンションセンターで行われました。 入口はこんな感じです。 会場内は人がごった返し、活気にあふれています。 こちらはNASAのブース。宇宙飛行士と話して握手できるみたいです。 こちらはみんな大好きスターウォーズのホログラム展示。 こんな恰好の人や ところどころでブース内でライブ演奏が行われていました。 他にも、マッサージしてくれるブースがあったり 卓球台が置いてあるだけのブースがあったりで、本当になんでもありです。 ITサービス系の出展が多く、直接見せるハードウェアがないせいか、お客さんと密なコミュニケーションをとり、自サービスを知ってもらうために様々な趣向を取り入れていました。本当にインタラクティブな展示が多いです。 一方で 日本周辺のブース は、圧倒的に ハードウェア のある展示が多かったです。 イヤホンがたくさんついたウィッグや 天気を知らせてくれるIoTデバイスだったり iPadとOculus Liftを装着して、アニメキャラになりきる人がいたり 一方の日本ブースは控えめに言って、ぶっ飛んでる展示が多かったです。展示を見に来ている人たちも 「 どうしてこっち3列はこんなにクレイジーなものばかりなの？！ 」 　※端っこ3列は日本を含むアジアブースでした。 と話していました。 こちらの記事で、もう少し日本ブースについてまとめてくださっています。 blog.innovationcenter.jp 弊社のブースの様子 ここからは、弊社のブースの様子をお伝えします。 私たちは、ブロックで家の間取りを作るだけで、すぐに3Dの家作ってシミュレーションできる「GRID VRICK」を展示しました。 www.gridvrick.homes.co.jp 展示が始まる直前のメンバー各員。やる気満々！ 私たちはこんな帽子を被って展示を行っていました。これは BRICK BRICK という帽子で、ブロックを使って自分で帽子をデザインできるというものです。これがなかなか好評で、街や会場で被っているだけで、その帽子いいねって言ってくれる人がたくさんいらっしゃいました。 とてもたくさんの方にGRID VRICKを体験していただきました。 作った部屋をOculus Liftでウォークスルーして喜んでくださったかた 反応もとてもよく、 Awesome! Amazing! Crazy! Genius! Good Job! Pretty cool! Most excited! という最高の褒め言葉をたくさん聞くことができて、こちらもテンション高く説明ができました。 アメリカでも子供に大人気！ もう行くよ！ってお父さんに手を引っ張られてるのに、まだ遊び足りない兄弟 慣れない英語での説明でしたが、新しい刺激がとても多く、4日間とても楽しく展示をすることができました。 アメリカやその他の国の人たちからもとても好評でしたので、また海外での展示会に持っていきたいところです。

はろーはろー！チバです。 今回は、「 ネクスト大学 」制度を用いて開講された「はじめての外注ゼミ」の内容をお送りします。 全4回の題目 第1回 - 目的にあった外注パートナーの探し方 第2回 - PMBOKの基礎と外注制作の体験談 第3回 - TiDD（チケット駆動開発）の手法、思想とプランニングポーカー 第4回 - ツールの選定眼を鍛えよう ゼミの中で使った、2015年6月〜9月期間の全4回に渡るスライドも公開したので、是非ご覧ください╭( ・ㅂ・)و ̑̑ ｸﾞｯ ネクスト大学とは… 従業員一人ひとりの能力開発を目的に、「必須プログラム」「選択プログラム」「選抜プログラム」からなるネクスト大学（社内大学）を開校しています。 「選択プログラム」では、社長が主催する経営塾、プロジェクトマネジメント、レコメンデーション技術、ロジカルシンキング、英会話等、社員は自身が受講したいゼミを選択して受講できます。ほとんどのゼミで社員が講師を務め、職種や部門を越えてお互いに教え合う文化の醸成に繋がっています。 「選抜プログラム」は、次世代リーダー育成プログラムです。トップセールス、クリエイティブアワード、ベストマネジャー、役員推薦等、次世代経営者候補を選抜した海外研修等を実施しています。 はじめての外注ゼミとは… はじめての外注でプロジェクトに取り組む人が何を準備し、どんなものを使い、どのように外部リソースを活用していくかを会得するゼミ。 ネクストの案件に取り組んだ社外の人にも「いい案件だった」と思ってもらえるような良質なプロジェクトを運用し、顧客・ユーザーの満足へとプロダクトで応えることを当ゼミの目的とします！ 昨年の4月、今期ゼミの募集をしていたときにこのゼミをやりたい！と思い、趣旨の提案と共にゼミ長に立候補しました。 当時はネクストに転職して半年、常に隣に制作者や開発者のいる環境に慣れてしまっている組織を目の当たりにし、（全部が全部ではないですよ ^O^）組織規模の拡大に合わせて案件進行がずさんになっていく未来が予測できました。 「 100社の子会社、100人の社長を 」のスローガンを掲げる以上、リソースが流動的になることを目先に見据えていなければならないと思ったのです。 そう考えたとき、私たちはもっといろんな人たちと働くことを視野に入れなければならず、チーム構成はアウトソーシングでという手段もあるでよってことを社内に広めたいと考えて取り組みました。 このゼミで幸せにしたい人 その1、ネクスト社員の皆さんです！外注への抵抗感を無くし、リソース増強の際に役に立 つ知識を身につけてもらうことが狙いです。 その2、外部パートナーの皆さんです！一緒につくり上げるパートナーとしてジョイン してもらい、「ネクストさんといい仕事ができた！」 を体験してもらうことが狙いです。 以上、2つをステークホルダーとして見据え、このゼミをスタートさせました！ 第1回 - 目的にあった外注パートナーの探し方 外注先の選定はどうするべきか、オフショア開発で気をつけることは何か、見積もりってどうやって詰めていけばいいのか、プロジェクトチャーターに書くことは？等々をお話しました。 はじめての外注ゼミ01 - 目的にあった外注パートナーの探し方 from NEXT Co.,Ltd. 第2回 - PMBOKの基礎と外注制作の体験談 第1回でもらった質問を元に、「こういう時はこうしたら好ましかったよね」を受講者と意見交わしながらまとめました。 そこから、言った言わないの水掛け論を防止するために掴んでおくこととして、 プロジェクトマネジメント知識体系ガイドPMBOK の紹介をしました。 プロジェクトマネージャーという職種にかぎらず、ものづくりに関わる全ての人が理解すべきガイドだと思っています( ˘ω˘) はじめての外注ゼミ02 - PMBOKの基礎と外注制作の体験談 from NEXT Co.,Ltd. 第3回 - TiDD（チケット駆動開発）の手法、思想とプランニングポーカー Ticket Driven Developmentの手法と思想を話し、タスクをどのように扱うことが良いのかを話しました。 チャットで話題とされたり、MTGで発生するような情報を上手く振り分けることで、 管理が容易い というものです。 情報が流しっぱなしになる「フロー情報」 タスク発行として分別保持する「ストック情報」 以上に振り分けるルールが定着するだけで、コミュニケーションコストはぐっと減ります。 また、発生タスクの 規模を見積もる ことで、チーム無いでの稼働率が一気に可視化され、リソースの振分けがうまくいきます。 そこで紹介した手法が プランニングポーカー ！ 当日は皆で和気あいあい楽しく、見積もりワークショップをしました✌(>ω・)✌ はじめての外注ゼミ03 - TiDD（チケット駆動開発）の手法、思想とプランニングポーカー from NEXT Co.,Ltd. 第4回 - ツールの選定眼を鍛えよう 最終回は、私の信念なんですが 「道具に任せられることは道具に任せて、人間は人間の仕事に集中しよう」 という趣旨のお話をしました。 私たちの業務の中には、思った以上の庶務作業やオペレーション的な作業の時間が存在しています。 それらを 今以上に効率よく片付けて、チームとのコミュニケーション時間を増やしたり、ユーザー研究の時間を増やしたり、1ケースでも多くのテストをクリアするだけでプロダクトはグッとよくなる と思いませんか…！(๑•̀ㅂ•́)و✧ はじめての外注ゼミ04 - ツールの選定眼を鍛えよう from NEXT Co.,Ltd. 当ゼミをやってみて… 受講者や周りの皆さんの反応から、「やってよかった」の一言に尽きる、良いゼミでした。 まさにプロジェクトが走りだそうとしている、という人も何人かおり、時期的にもとても良いタイミングに出逢えたと思っています。 また、他の方の「過去にこんなプロジェクトがあり…」などの話も聞けたり、過去に、社内でプロジェクトマネジメントの知識を広めようとした人の存在を知れたり、自分の知らない過去のナレッジも知ることができてこちらも学ばせてもらえました。 （組織にいる以上、時代背景とか出来事の伝承がされるっていいことだと思うんすよ…温故知新ってあるよね…） 自分が「これやってます！」を大きな声で言うことは、やはり大事なことなんですね。 このゼミがあったことが受け継がれて、どんどんアップデートしたい！再演しよう！って人が出てきたりとかもして、「ネクストさん！一緒に働きましょう！」って言ってくれる人が増えたらいいなと思っています。 そして、「あーこのプロジェクトやってよかったわー！さいこー！ビールが旨い！」って言う人も増えたらいいなと思っています。増やしましょう！ 最後に… 2016年4月で、ようやくディレクター6年目になるんですが、受託会社／事業会社両方で培うことのできた経験はたくさんあり、それが全て詰まっているような気がします。 最近は、所属部署柄ディレクション／プランニング／アナリスト／リサーチャーを反復横跳びしてる感じの業務内容ですが、ディレクターであった経験を振りかざさずに、その都度強みを活かして、プロジェクトに見合った振る舞いをしていきたいです。 使う人、作る人がどっちも幸せになるものづくりのあり方を推進して、今後もバンバンでしゃばりたいでーす！ ＊スライド公開にあたり、機密情報・リーガルチェック・それら手配をしてくださった皆さん、ありがとうございましたm(__)m

みなさん。テストしてますか? こんにちは。HOME'SでQAをしている池之上と申します。 私が所属しているQAグループでは、テストに関する海外の出版物を積極的に読むように心がけています。 その中でもとても良い書籍に出会ったので、ご紹介したいと思います。 書籍概要 Jon D. Hagar著 : Software Test Attacks to Break Mobile and Embedded Devices Software Test Attacks to Break Mobile and Embedded Devices (Chapman & Hall/CRC Innovations in Software Engineering and Software Development Series) 作者: Jon Duncan Hagar 出版社/メーカー: Chapman and Hall/CRC 発売日: 2013/09/18 メディア: ペーパーバック この商品を含むブログを見る 著者サイト : https://breakingembeddedsoftware.wordpress.com/ 組み込みデバイスのテストに関する著者の30年以上にわたる経験の集大成。携帯・組み込み端末のテストに関わる人々のための書籍です。 バグやエラーを見つけるための攻め口(Attack)が30以上紹介されています。 扱うテストは、ホワイトボックステストからブラックボックステスト、さらには非機能要件(UX・パフォーマンス・セキュリティ等)に関わる部分まで多岐に渡り、 携帯・組み込み端末に必要なテストが幅広く網羅されています。 各Attack毎に、概要、何を、いつ、どこで、誰が、どうやってテストすればいいのかについて一つ一つ丁寧に説明され、 加えて、テストラボの構成や有用なツールについても豊富に紹介されています。 設計から実施まで必要な情報をカバーし、丁寧に説明した、携帯・組み込み端末のテストの教科書的位置づけの書籍です。 書評 いままで長らくHOME'SのPCサイト、スマートフォン最適化サイトのQAをしていたのですが、 昨年夏にスマホアプリのQA担当することになり、ちょっと予習しておこうと思ったのが読み始めたきっかけでした。 携帯・組み込み端末に関わるテストが網羅的に載っているので、業務でのテスト設計や実施の際に本書はとても役立ちました。 　また、携帯・組み込み端末は従来のシステムとどう異なるのかについても触れられており、 今までやってきたテストと何が違うのか、どう注意すればいいのかについても知ることができます。 例えば次のような部分です。 remember that mobile app users have historic expectations of performance based on their IT, PC, and web use. Embedded devices may have less raw performance power (e.g., CPU speed) than IT systems, and users in part understand this situation, but programs should not rely on the lessened expectations of the mobile or smart user for project success. (Software Test Attacks to Break Mobile and Embedded Devices p.127) --以下要約-- ユーザーはモバイルアプリにもPCとかwebサイトくらいのパフォーマンスを期待していることを覚えておいてください。 組込みデバイスはITシステムよりパフォーマンス(CPUスピードなど)は劣っているし、このことを理解していないユーザーもいるかもしれません。 しかしながら、(非力なデバイスだからといって)プログラム側がそれに甘えるべきではありません。 言われてみれば当たり前なことなんですが、改めて言われるとハッとする内容です。 内容に加えて、この本で個人的にすばらしいと思ったのは下記の２点 各Attackが体系的にまとまっている リファレンスが驚くほど多い 体系的な文章構成 書籍概要でも触れましたが、各Attackには、概要と、何を、いつ、どこで、誰が、どうやってテストすればいいのかが書かれています。 これらはセクションに分けられて書かれており、知りたいことを拾い読みしやすい構成なのではないかなと思います。 書籍によっては説明の途中で、著者の経験を長々と語られてわかりにくかった。なんてことがあったりしますが、この本では感じませんでした。 一方、著者の生々しい経験談は載っていないのかというと、そうではありません。文中にside barという別セクションで書かれています。 このside barというセクション、著者の経験だけでなく、ソフトウェア史に残るバグなども紹介されており、大変興味深い部分です。 戦闘機やミサイルのバグなんてのもありました。絶対遭遇したくないですが、読む分には興味深いで済みますからね！ side barだけの拾い読みも楽しいかもしれません。 そして、文章の書き方だけでなく読まれ方にも工夫が。 この本、届いてびっくり。枕にできそうな厚みで、ちょっとたじろぐ見た目なのですが、 安心してください。全部は読まなくていいんです。 巻末でテスト対象のデバイスや分野ごとに、実施したほうがいいAttackをチョイスしてくれています。 とりあえず、自分がテストしたいプロダクトに関わるAttackだけを読んでいけばいいのです。すばらしい優しさですね。 リファレンスが多い この書籍では、文書中のいたるところに、ここに書いていることはほんの触りだ、序章だ、はじめの一歩なんだ！とでてきます。 序文にもこんな厳しいお言葉が。 No single book is a complete work on software or testing. (Software Test Attacks to Break Mobile and Embedded Devices p.XV) しかしそこで突き放さないのが著者の優しさ。各章末にはこれでもか！と参考文献が書かれています。 そしてAttack中でも、これだけは読んどけ、このAttackを読んだら次に読むのはこれと、著者が書籍をすすめてくることがあります。 知識を深めるための道しるべにもなってくれる書籍です。 最後に 厚みのせいでだいぶ心理的な壁はあるのですが、私のようにスマホアプリのテストをはじめられる方が教科書として使うのはとてもオススメです。 また、熟練者の方は基本を確認しつつ、豊富なリファレンスでさらに知識を深めることができる書籍なのではないかなと思います。 さらに、テストに関わる方だけでなく、開発者の方、ディレクターの方などにもおすすめです。品質を作り上げていく過程がよくわかります。 スマホアプリの開発に関わるなら、来期のプロダクトをさらにより良い品質にするために、ぜひご一読ください。 著者が来日します 来る、3月8,9日に開催されるソフトウェアテストシンポジウム JaSST'16 Tokyoで 著者John Hagar氏が下記のテーマで講演されます。 「Software Test Challenges in IoT devices　IoTデバイスにおけるソフトウェアテストの課題」 日本でお話しをうかがえる貴重な機会ですので、参加を検討してみてはいかがでしょうか。 JaSST'16 Tokyoでは、わたくし池之上も弊社で運用している画像を使った自動テストについて発表いたします(詳しくは こちら )。 さらに、 Web.JaSST セッションには、弊社品質管理の長が登壇し、web業界のテスト戦略について激論を交すようです。 当日券の販売も決定したそうです。たくさんのご来場をお待ちしております。 イベント詳細 JaSST'16 Tokyo　ソフトウェアテストシンポジウム 2016 東京 日程 : 2016年3月8日(火)～9日(水) 場所 : 日本大学理工学部 駿河台校舎１号館 （東京都 千代田区）

こんにちは。おうちハッカー@リッテルラボラトリーの石田です。 今日は、HOME'Sで大量に保持している間取り画像を使って、ディープラーニングの手法の一つであるDCGANを使い、あり得そうな間取りを生成させてみました。 DCGANとは？ Deep Convolutional Generative Adversial Networkの略で、画像を生成する手法です。 データセットを元に画像を生成する生成器と、生成された画像かデータセット画像かを見分ける判別機の2つのニューラルネットワークを交互に学習させることで、 データセットのような画像を生成します。 論文は こちら です。 またNextremerさま主催の 機械学習勉強会 で、発表されていた方の資料もあります。 Deep Convolutional Generative Adversarial Networks - Nextremer勉強会資料 昨年末のディープラーニング界隈では、DCGANを用いた顔イラスト生成が話題となっていました。 qiita.com 今回は こちら のChainerでの実装を使わせていただきました。 間取り画像のデータセット 間取り画像を生成しようかと考えたのは、弊社の日本最大の物件数を誇るHOME'Sのデータセットがあるからです。 今回使用した、画像を含むHOME'Sデータセットは、国立情報学研究所を通して、研究者の方に無償で提供させていただいています。 nextdeveloper.hatenablog.com 最近、高精度な間取り画像を追加させていただきましたので、ぜひご利用ください。 nextdeveloper.hatenablog.com こちらの間取り画像から、サイズを96×96に縮小してデータセットを作成します。 データセットには、 約500万枚 の間取り画像があり、さすがに多すぎるので約50万枚を使用します。 学習経過 30分後 　間取りの線がなんとなく見えてきました。 2時間後 　間取りの形と色がそれっぽくなってきました。 24時間後 　遠目で見る分には、かなり間取りっぽいです。 32時間を超えたあたりで、誤差が発散してしまい、こんなのになってしまいました。 学習経過を動画にしてみました。１画像で10分程度、約32時間分です。 www.youtube.com どんどん間取りっぽくなっていくのが分かると思います。 ただ間取りに書いてある文字まではさすがに再現されません。文字っぽい模様が見えるだけです。 シード値の操作 画像を生成するジェネレーターは、今回の場合、値域[-1,1]の100次元のシード値zを入力として画像を生成します。 このzを、画像Aを生成したシード値zaから、画像Bを生成したシード値zbに連続的に変化させることで、間取りも連続的に変化するのではないかと思い、やってみます。 すると、このように、1Kぽい部屋が、4LDKっぽい部屋に連続的に変わる様子が見られました。徐々に部屋が増えていきます。なんだか不思議な感覚です。 こっちはワンルームから3LDK やってみての感想 先人のイラストや景色などは、手書き感があったり、雰囲気が再現できていれば成功しているように見えるけれど、間取り画像はそうはいきません。 生成した間取りでは、 間取り上入れない部屋 が生成されたり、 よく分からない文字らしきもの が生成されたりで、間取り図としての機能を果たせていません。 また現状で生成できる解像度も小さいので、なかなか見ずらいです。 DCGANは、こうした精密な画像生成には向いていないと思われます。もう少し人の感性に左右される画像をデータセットにすると面白いかもしれません。 参考 Chainerで顔イラストの自動生成 - Qiita Chainerを使ってコンピュータにイラストを描かせる - Qiita [1511.06434] Unsupervised Representation Learning with Deep Convolutional Generative Adversarial Networks Deep Convolutional Generative Adversarial Networks - Nextremer勉強会資料 from tm_2648 www.slideshare.net

こんにちは。HOME'Sブランドチームの田中です。 2015年12月15日を皮切りに、HOME'Sの各サービス上でひっそりと差し変わったものがあります。HOME'Sロゴです。 HOME'Sロゴは、これまでもレッドからオレンジになったり、線が微妙に変わったりとマイナーチェンジはありましたが、今回の変更でロゴの見栄えはがらりと変わりました。 ポイントは「小判が取れた」ことと「文字が変わった」ことです。 今日はそんな新しい HOME ' S ロゴの経緯についてお話させていただきます。       HOME'Sの歩みとロゴ   「HOME'S」の名を冠するサービス・コンテンツは、HOME'Sの20年ほどの歩みの中でたくさん生まれてきました。   2015年12月にリニューアルを遂げた「 HOME'Sリノベーション 」。 高齢者向けの住まいを探せる「 HOME'S介護 」。 収益物件検索や、不動産投資のサポートを提供する「 HOME'S不動産投資 」。 トランクルーム専用サイト「 HOME'Sトランクルーム 」。 不動産業務をより円滑にするプロ向けサービス「HOME'S PRO」。   まだまだ他にも沢山あり、これからも増えていくでしょう。 そして、それら全ての接点上でハンコのように刻印され、ブランドイメージをつなぐ最も重要な役割を果たすのがロゴです。 文字を囲う「小判（社内での呼び名です）」から黄色い楕円がポンと閃いたような形のロゴになったのは 2006年1月 ですので、旧「小判型ロゴ」は使われ始めてから10年ほどが経ちます。 しかし10年という年月でサービス規模も運用体制も変わっていき、ロゴもその歩みとともにルールや形態の調整を重ねていました。そして今回、サービスの拡大に合わせ、微調整だけでは解消できない課題に対処するため、現状に合わせた新しいロゴ形態の模索が必要でした。 ですので今回のロゴの変更は「リニューアル」ではなく「アップデート」という言葉を使っています。シンボル自体のコンセプトはそのままに、もともとのロゴが孕んでいた問題点を洗い出して抽出し、解消することが狙いでした。     旧ロゴが持つ問題点とその解消について 問題点は、大きく分けると「可読性」「汎用性」「拡張性」という3点に分けられました。   ①「可読性」の問題 旧ロゴは、小判とアポストロフィーが合体している形状のクセ、メッセージやシグネイチャーの影響で、線や要素が多くなり肝心のHOME'Sの文字が読みづらくなっていました。 これらを解消するために、要素をそぎ落とし、文字の周囲の空間を整理して読みやすくする必要がありました。     以下は、2015年10月～12月の一時期だけ使われていたロゴマークです。 旧ロゴをver1.0、新ロゴをver2.0とすると、ver.1.1というべきバージョンでしょうか。 「可読性」の解消にのみフォーカスしたもので、小判を広げ、開発中のロゴタイプを実験的に利用しています。HOME'Sをある程度認知されている方で無ければ、パッと見では違いを意識する事のない程度の差です。   放映中だったCMの最後の「止め」部分と、PC版トップページでのみ差替えたところ、ロゴ認知は前月比昨対比ともに向上が見られました。 ロゴ認知はあらゆる接点から影響を受ける指標なので一概には言えませんが、数値が大きく変動する理由として他に考えられるものがなかった事もあり、胸をなでおろす結果でした。文字としての読みやすさと、シンボルとしての認知には関係があると言えそうです。         ②「汎用性」の問題 旧ロゴはその形状のクセから、レイアウトで困る場面がよくありました。 まず、オレンジベタ面に配置できない点。色を反転してヌキにすると印象が変わりすぎてしまう事が理由です。そういう時は白い背景を敷かないとロゴが配置できませんでした。形状が複雑なので、矮小スペースも苦手だったりします。 しかし「小判」を取るとこれが解消されます。   そもそもHOME'Sロゴのコンセプトは、アポストロフィー部分の黄色いマークに宿っていました。ポンと生まれる黄色の楕円が、住まいにおける「発見」、つまりHOME'Sをご利用いただく方々に提供すべき価値を象徴しています。   小判はそのコンセプトを強調するためのもので、言ってみれば無くても成立します。 ただ小判を取ってしまうと印象も運用感覚もがらりと変わるため、長年使ってきた蓄積を考えると当然リスクもありました。それでも今後も拡大するサービスや、web、マス、イベントなど利用シーンがいっそう多岐にわたっていく事を考慮し、外すことを選びました。         ③「拡張性」の問題 これも小判に関わる話です。 以下は旧ロゴの時に使用されていたパターンと新ロゴを比較する図です。 旧ロゴは文字を並べると読みづらく、続く言葉によってはロゴの後にまたHOME'Sと書かざるを得なかったりします。「HOME'S○○」という名称と相性が悪かったことがわかります。 これはHOME'Sの文字が白ヌキになっている事が最大の要因でしたので、小判をなくすことで解消されます。こうして今後生まれていくサービスにも対応できるようになります。           制作プロセス   ロゴの制作プロセスですが、まず旧ロゴをひたすら研究するところから始めました。 上げるとキリがありませんが、上記はその研究の残骸の寄せ集めです。のちにver.1.1に繋がる小判研究の足跡も見られます。   文字を調整する作業は計算と目視の繰り返しで進行しました。 肝であるアポストロフィーを強調するため文字自体のクセは抑え、でもちょっとだけ引っかかる。そして何より「読みやすく、使いやすい」こと。 「発見」を別の方法で表現するような案も初期にはありましたが、プロジェクトの主旨からしてそういった案は消えていきました。主役は馴染んだあのアポストロフィー。文字は引き立て役。そうして旧ロゴのイメージをベースに調整を重ねました。 香水を選ぶとき、コーヒー豆を嗅ぐことで鼻をリセットしながら試用するという話がありますが、もしも目に効くコーヒー豆があったら1kgくらい欲しかった時期です。   以下はFIXに向けて最後に比率を揃えて固めようとした段階です。しかしまだアポストロフィーが相対的に大きかったり、いくつかFIX版との違いが見られます。「綺麗なモノには法則がある」という精神で整理していたもののうまくハマらず、ああ、最後は目視しか無いんだな、と悟った瞬間でもありました。 この後、もう何度か目視の最終調整を回して完成します。       ただし、この小判無しの新ロゴだと動画や写真を背にした時「視認性・可読性」が損なわれたり、オレンジ以外の濃色背景時にブランドカラーを保持できません。 なので実は、こういうパターンも存在します。       運用ルール   ロゴの利用ルールも整理しました。 これまでは禁止事項によって成り立っていた"ロゴレギュレーション"を、禁止ではなく考え方を簡潔にまとめる方針で"ロゴガイドライン"として刷新しました。「こう使っちゃダメなんだな」より「こう使ってみたいな」と思ってもらえるようにまとめるイメージです。 上記は余白ルールのページ例です。新ガイドラインは、とにかく「説明しない」ことを重視しています。ルール自体もシンプルにし、またグループ社員はもちろん社外の方にも読みやすく分かりやすい表現に終始することで、より自由に利用できるようになりました。 ただしガイドラインは運用していく上で必ずチューニングが必要になります。旧ロゴのレギュレーションも、運用する中で生まれた課題に対して都度ルールを新設しながら肥大していった背景があります。 そのため初版において平易な表現で、考え方の明示に徹することはガイドラインの土台としての意味もあります。     最後に 長々と書きましたが、要はアップデートであり「小判が取れた」ことと「文字が変わった」ことが今回の顛末です。しかしロゴは影響範囲が非常に広く、一つの調整がサービス全体の印象形成に関わります。 当然、差替え作業は多くの仲間の協力がなくてはできませんでした。ただ幸いなことにHOME'Sの開発/制作ワークフローはかなりの割合で社内完結しているため、差替の進行はおそらく一般のケースよりスムーズだったのはないでしょうか。手前味噌ですが、こういう所はHOME'Sの良いところだと思います。 今後HOME'Sロゴを利用して「HOME'Sらしい」画をつくる際に、イメージを膨らませる一助になって欲しいです。そうして、たくさんの人に親しまれるシンボルになったら良いなと願っています。    

こんにちは。 Apple Watchの代わりに チープカシオ を買ったWebデザイナーのアズマです。 今は職場でMacBook Proを使っていますが、去年はWindowsマシンで仕事をしていました。学生時代からMacを使っていた身としては、MacとWindowsの微妙な挙動や設定の違いに戸惑うこともありました。 1年かけてWindowsをできるだけ便利に使えるようソフト・環境設定をカスタムしていきましたが、 最初にMacからWindowsに乗り換える場合の記事を探そうと思って検索しても、 WindowsからMacへの乗り換えについての記事ばかり 出てきて困った覚えがあります。 そこで今回は、Mac派の僕がWindowsでもなるべく違和感なく、快適にお仕事ができるように導入したソフト・環境設定を紹介しようと思います。 (今回紹介するソフトは全てWindows7 64bitで使用していました) Macは、Apple Inc.の商標です。 Windows は、米国 Microsoft Corporation の、米国およびその他の国における登録商標または商標です。   ■アクティブでないウインドウのスクロール⇔WizMouse WindowsとMacの挙動の違いで一番地味にイラッとするのがこれです。 Windowsでは、アクティブになっていないウインドウにカーソルを置いてスクロールすることができません。今アクティブになっているウインドウがスクロールされるばかりです。 WizMouse はそんなイライラを解消してくれます。起動すればアクティブでないウインドウもスクロールできる、単機能でシンプルなソフトです。 www.forest.impress.co.jp ■かな・英数キー⇔IMEの設定 普段親指でローマ字と英数を切り替えているMacに慣れると、入力を切り替えるたびにキーボードの左上隅の 「半角/全角」 キーまで小指を伸ばさないといけないのはかなりのストレスです。 即座にIMEの設定を変えて、JISキーボードなら「無変換」「変換」あたりのキーでローマ字と英数の入力を切り替えられるようにしてしまいましょう。 vdeep.net ■Emacsキーバインド⇔XKeymacs Macでは文字入力の際、Controlキーとの組み合わせによるいわゆる 「Emacsキーバインド」 で上下左右移動や改行までできてしまうので、慣れてしまえば右手をエンターキーや矢印キーにほとんど動かすことなく文章を書いたりコーディングすることができます。 残念ながらWindowsではデフォルトでそういう機能はないので、キーリマップソフトを入れて対応することになります。 いくつか方法がありますが、僕が使っていたのはその目的に特化したリマップソフト、 XKeymacs です。 CapsキーをEmacsキーバインド用のキーに割り当てることで、通常のCtrl+●みたいなショートカットを潰すことなくEmacsキーバインドを使うことができます。しかも設定が豊富で、Macでもできないような高度なこともできるようになります。 d.hatena.ne.jp   ■Spotlight・Alfred⇔Launchy Macの便利なところは、Control+スペースなどのショートカットでSpotlightや Alfred を開いて、 サクッとアプリを起動したり、フォルダを開いたり、検索したり、辞書を引いたり、ちょっとした計算をしたり、 大抵のことができちゃう ことですね。 WindowsではWinキーで開くスタートメニューの検索窓がそれにあたりますが、機能がちょっと足りない上に見た目も地味でテンションが上がらない。 Launchy は元々ランチャーソフトですが、かなり細かいカスタマイズが可能です。 拡張機能プラグイン や 見た目を変えるスキン なども豊富にあるので、試してみてください。 www.lifehacker.jp   ■プレビュー・Quicklook ⇔ Massigra デザイン作業においては、「これ何の画像だっけ」とファイルの中身を確認したくなることが頻繁にありますよね。Macでは軽い挙動のQuicklookや「プレビュー」アプリで様々な形式の画像を流れるようにチラ見できます。 一方で、Windowsデフォルトの「Windows フォト ビューアー」ではPSDなどの画像形式を開くことができず、 ちょっと確認するためにわざわざPhotoshopを起動することになります。 また、 等倍表示されているのかどうかも確認できないズーム機能 など、控えめに言っても使い勝手が良いとはいえません。 Massigra なら、起動や終了も非常に速く、(Escキーで閉じられるところがお気に入り) キーボードショートカットも細かく設定でき、 さらにプラグインを導入することによって、PSDなどでもバッチリ、Photoshopよりも早くサクサクッ！と開くことができるようになります。 この手のソフトで昔から有名なのは IrfanView ですが、IrfanViewと比べてMassigraの良いところは、商用利用可能なところと、アイコンがかわいいところです。 (IrfanViewのアイコンのモチーフは「轢かれた猫」です。) hanamaru.hatenablog.com   ■HyperSwitch⇔VistaSwitcher Macのタスク切り替え(Command+Tab)は、基本的な機能として困ることはないんですが、ウインドウごとに選べないとか、かゆいところに届かないところがありますね。それを解消するためにMacではHyperSwitchを入れていますが、これのWindows版といえるのが VistaSwitcher です。 VistaSwitcher は大きなサムネイルでウインドウを選択できるほか、サブディスプレイに接続した際の挙動などを細かく設定することができる、まさにかゆいところに手が届くソフトです。 gigazine.net   ■Mission Control⇔Dexpot Macのデフォルト機能、Mission Controlでは開いているウインドウを並べて俯瞰したり、複数デスクトップを切り替えることができますが、Windowsではデフォルトではそもそもマルチデスクトップに対応していません。 Dexpot を使えば、Macのような複数デスクトップ環境を作ってショートカットで切り替えたり、開いているウインドウが一望できたりします。 （※個人用に限り無料ですが、商用利用の場合24.9ユーロ(約3,300円)です。） kkblogs.com   ■Finderのタブ機能⇔Clover MacではMavericks(10.9)から公式でFinderにタブ機能が搭載されましたが、WindowsのExplorerではまだタブ機能がありません。そこで使えるのがCloverです。 Clover はExplorerにChromeのタブ機能がついたシンプルなファイラーで、Chromeのタブまわりで使えるショートカット(Ctrl+Shit+Tで閉じたタブを復活…など)が使えます。 2ペイン型のTablacusや複雑なレイアウトの行えるQ-Dirなど、ファイラーの世界は奥が深いですが、シンプルで最低限タブが使えればいいや、という方はCloverがおすすめです。 hep.eiz.jp いかがでしたか？別にWeb制作者じゃなくても使うものが大半でしたね。デザイナーズブログに書く意味あったんでしょうか。反省してます。 迷えるMac派Windowsユーザーのためにも、「俺は他にもこんなのを使ってるぜ！」という方はコメントなどで教えてください！

こんにちは、リッテルラボラトリーの清田です。 2015年11月に提供開始した「HOME'Sデータセット」 には、おかげさまで多くの研究者の方々からお申し込みをいただいており、すでに20以上の大学の研究室・研究機関にご提供しております。 このたび、「HOME'Sデータセット」に高精細度版の間取り図画像データ（約515万点）を追加しました。間取り図は、物件スペックデータ（面積、部屋数など）だけではわからない住まいの使い勝手の判断材料の一つとして、多くの住まい探しユーザーに利用されています。住まい探しに新たなイノベーションをもたらすような研究に活用されることを期待しています！ 「HOME'Sデータセット」への期待・要望 「HOME'Sデータセット」には多くの方々からお申し込みやお問い合わせをいただいておりますが、なかでも約8300万点の物件画像データには、deep learningなど最先端の画像処理アルゴリズムの研究資源として関心をお寄せいただいています。 一方で、以下のようなデータもあると嬉しいというご意見も多々頂戴しております。 物件データの時系列変化（経済動向の把握など） ユーザーの行動ログデータ（物件検索、問い合わせなど） 物件の正確な位置情報（緯度・経度） より高解像度の画像データ これらのデータに関しては、プライバシー保護の問題やデータセット作成のコストの課題はあるものの、課題のクリアに向けて取り組んでいきたいと考えております。 物件画像データに関しては、物体認識タスクを主な用途として想定していたことから、まずは画像数を優先して120×120ピクセルのサイズとしていましたが、とくに物件に関する情報をたくさん含んでいる間取り図画像の解析については解像度が足りないというご意見をいただいておりました。 CiNII や Google Scholar を検索すると、間取り図にフォーカスした研究はこれまでも多数行われていることがわかります。間取り図に関する研究が盛んになることは、中長期的に住まい探しユーザーの利便性向上につながると考えられることから、まずは高精細度の間取り図画像データをご提供することとなりました。 高精細度版間取り図画像について 今回「HOME'Sデータセット」に追加された「高精細度版間取り図画像データ」は、すでに提供済みの約533万件の賃貸物件データ（2015年9月時点でのスナップショット）のうち、約515万件の物件に紐付けられた間取り図です。 約515万点の間取り図画像ファイル うち、約48万点にはフリーテキストがメタデータとして付与 JPEG形式、最大1280×1280ピクセル（不動産会社による提供画像サイズに依存） 間取り図画像からは、以下のような情報を読み取ることができます。 部屋、設備のレイアウト どの部屋どうしがつながっているか？ 玄関とリビングの位置関係は？（来訪者から部屋の中が丸見えになってしまうかどうか？） 収納スペースの位置、広さ たとえば、 子ども部屋の位置は玄関からの動線（いったんリビングを通ってから子ども部屋に行けるようにする）が大事だと言われています が、現在の住まい探しサイトでは、このようなニーズには十分応えられていません。住まいに関する多様なニーズに応えられるようなイノベーションが、データセットの共有を通じて生まれてくることを強く期待しております。 データの入手方法 「HOME'Sデータセット」本体と同様、国立情報学研究所（NII）の 情報学研究データリポジトリ（IDR） を通じてご提供します。手続き方法については 「HOME'Sデータセット」のページ をご覧ください。 ※公的機関に所属する研究者の方以外からのお問い合わせは、弊社問い合わせ窓口（corp-info アットマーク next-group.jp）までお願いいたします。

こんにちは。ウェッブデザイナーのアズマです。 皆さん、会社で昼寝してますか？僕は毎日してます。 待ってください。会社のお問い合わせフォームに苦情を書き込む前にちょっと聞いてください。昼寝といっても10〜15分程度のものです。 でも、その昼寝に踏み切れず、眠気にひたすら耐えてつらい思いをしている人もいるのではないでしょうか。 そんな人のために、HOME'Sの 「昼寝大使」 として、今回は職場での昼寝のメリットと、それを可能にする方法をお伝えしたいと思います。 ==== 会社で昼寝をするべき理由 1. 頭をリセットすることで創造性が回復する デザイナーのみならず、およそ机について働く人の仕事は「考えること」です。ボタンの見た目を考えるにしても、サービスの構造を考えるにしても、思考や判断には精神的なエネルギーが必要不可欠です。 「タバコを吸う」「散歩に行く」「座禅を組む」「踊る」など、人によって様々な回復方法がありますが、中でも最も手軽で即効性の高いのが「昼寝」と言えるのではないでしょうか。 ちなみにクリエイティブなアイデアと高いクオリティでお馴染み、 面白法人カヤック の柳澤代表は眠くなったら 即座に床で寝ている そうです。この昼寝に対する貪欲な姿勢、スピード感がクリエイティビティの源泉なのかもしれません。 2. 眠気を我慢しても効率は下がる一方 襲い来る眠気を我慢して作業を続けようとして、手元が狂って同じところを何度もアンドゥして、作業は進んでないのに時間だけが過ぎていた、ということはありませんか？ その分昼寝していればよかったのではないでしょうか。 デザインは緻密な作業です。エネルギーの大半を「頑張って起きておくこと」に費やすような状況で仕事ができるでしょうか。 睡魔に襲われて最悪のコンディションで1時間頑張るか、10分昼寝して全回復してから50分頑張るか。答えは自ずと明らかです。 極論すれば 「起きてる時間が無駄」 です。 3. 厚生労働省とNASAも認めている 厚生労働省による 「健康づくりのための睡眠指針2014」 でも、「午後の早い時刻に 30 分以内の短い昼寝をすることが、眠気による作業能率の改善に効果的」とあります。 そりゃしょうがない。国が認めてるんじゃしょうがないですよ。国には逆らえない。 また、コーネル大学の社会心理学者であったジェームス・マースにより提唱された 「パワーナップ」 (15〜30分の短い昼寝)はアメリカの企業で広まっており、高度な思考や判断を要するエグゼクティブ層を中心に浸透しているそうです。 NASAでも昼寝の効果は 研究 されており、26分の眠りがパフォーマンスを34%向上させるとしています。 NASAならしょうがない。NASAが認めてるんじゃしょうがないですよ。 会社で昼寝をするための心得 1. 堂々と、かつさりげなく 昼寝に対して罪悪感を感じる必要はありません。自分が正しいと信じたことを実行するのみです。弊社のガイドラインにも「自ら動く、自ら変える」とあります。昼寝に対する社内の認識を自ら変えてやるぐらいの気持ちで寝ましょう。 とはいえ口に出して 「それじゃ僕寝ますんで！」 と言われると「なんだこいつ」となることは必定。ここではさりげなさが大事です。 トイレに行くときのようにさりげなく席を立ち、お気に入りの休憩スペースに向かいましょう。 猫は死に際になるとフッと姿を消す といいますが、イメージとしてはアレです。 そして昼寝後は何事もなかったかのように席に戻り、仕事の続きに取りかかりましょう。僕クラスのヒルニスト(昼寝をする人)になれば息を吸うように昼寝できますが、最初のうちは踏ん切りがつかないと思いますので、心の中で 「寝るのも仕事のうち」 とつぶやくのが効果的です。 ちなみに弊社では最近、休憩スペースをオシャレにDIYしたので、オシャレな気持ちで昼寝をすることができます。 www.homes.co.jp   2. 「10分で起きる」と周囲に明示する 人によって回復できる時間が違うのかもしれませんが、慣れれば10分でもしっかり目が覚めます。 30分以上の昼寝は逆効果 という研究もあるので、くれぐれも昼寝は 10〜20分 程度に抑えておきましょう。 そうなればスマホのタイマーなどを仕掛けて確実に10分で起きるのはもちろんのこと、周囲に対するさりげないアピール&エクスキューズも重要です。そこで僕はこんな物を作りました。 この紙を印刷して社員証の後ろなどに挟み、机にうつぶせて寝るときには背中に回します。これで通りがかりの人に「こいつ、いつから寝てるんだろう…」と思われずに済みます。 また、昼寝のことをPower Napと呼ぶことでなんとなく 公認っぽさ を出し、後ろめたさを払拭する効果があります。皆さんも印刷してお使いください。 (印刷用ファイルはこちら) 3. アイマスク・耳栓は常備 これは10分間の眠りの質に関わる重要なことです。貴重な眠りの質を蛍光灯の光や周囲の声で下げるわけにはいきません。100均のペラペラのものじゃなく、多少高くても良い物を使いましょう。昼寝に対する意識が高まります。 僕のおすすめはDream Essentialsの 立体型アイマスク と、軍用でも使われるMOLDEXの CAMO PLUGS です。 耳栓に関しては人によって好みの差があるので、最初に お試しパック を買ってみて一番しっくりくる耳栓を見つけましょう。 より快適な昼寝環境を構築するため、僕はポータブルの枕を持ち込んで使っています。無印の「人がダメになるソファ」のミニバージョン、ネッククッションがおすすめです。 http://sleep.muji.net/ja/ 4. 眠る前にコーヒーを一口飲む 「コーヒーなんて飲んだら眠れなくなっちゃうじゃないか！」とお思いかもしれませんが、カフェインが効果を発揮し始めるのは、 摂取後30分経ってから とされています。 昼寝の前に飲むとちょうど起きた頃にカフェインが効いてきて、頭がスッキリする効果が高まります。 いかがでしたでしょうか？あんまりデザイナー関係なかったですね。反省してます。 そろそろ「昼寝したい！毎日したい！」という気持ちになってきたのではないでしょうか？ 働くときは全力で働き、寝るときは全力で寝る。そんな真のプロフェッショナルを目指して、レッツ昼寝！ (本記事の内容に基づいて被ったいかなる被害についても、当方は責任を負いかねます)

こんにちわ、フォースを信じてる鈴木です。 ネクストでは、業績目標を達成したご褒美に全従業員参加の社員旅行をします。 会社の成長とともに参加者が増え、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でコードを書いていないので、本質的な使いやすさはまだ分からないのですが、ディープラーニングがより一般的になっていく未来を感じました。