こんにちは、リッテルラボラトリーの清田です。 まもなく発刊予定の 人工知能学会誌 2015年5月号 に、「イノベーションとAI研究」と題した特集が掲載されます。 今回、人工知能学会編集委員として特集を企画・担当させていただきました。 企業のR&Dや新規事業、ベンチャー創業、産学連携など、イノベーション創出の最前線で活躍中の方々に、8編もの記事をご寄稿いただきました。 いずれの記事も、現場での豊富な経験に基づいてご執筆いただいており、人工知能（AI）技術をイノベーション創出に生かすためのヒントが満載の内容となっています。 人工知能学会にご入会いただくことで購読できるほか、Amazon.co.jpでも購入が可能です。 特集概要のスライドを公開しておりますので、こちらもご覧ください。 人工知能学会誌 2015年5月号 特集「イノベーションとAI研究」 from Yoji Kiyota 多くの方々に読んでいただき、イノベーションへの新たな視点を得るきっかけとしていただきたいと思います。 企画の意図 この特集を企画するにあたっては、 シナジーマーケティング株式会社 R&D の谷田泰郎さん、 株式会社ホットリンク R&D の榊剛史さんらと続けてきた議論がきっかけとなりました。 弊社も含め、多くの新興IT企業がイノベーション創出を目的として研究開発（R&D）組織を設立しています。以下に、日本国内でのAI関連分野での主な取り組み事例をまとめてみました。 企業名 創業 株式公開 R&D組織設立 設立の経緯 AI関連分野での主なR&Dテーマ (株)ホットリンク 2000 2013 2004 ブログ関連技術の産学連携組織として HottoLabo 設立 ソーシャルメディア解析、コミュニティ解析 サイボウズ(株) 1997 2000 2005 連結子会社として サイボウズ・ラボ(株) を新規に設立 機械学習、自然言語処理 楽天(株) 1997 2000 2005 楽天技術研究所 を新規に設立 自然言語処理、画像認識 ヤフー(株) 1996 1997 2007 Yahoo! JAPAN研究所 を新規に設立 機械学習、自然言語処理 (株)ネクスト 1995 2006 2011 東京大学発の産学連携企業であった(株)リッテルを買収し、 リッテルラボラトリー を設立 情報推薦、ビッグデータ解析、ユーザエクスペリエンス (株)サイバーエージェント 1998 2000 2011 秋葉原ラボ を新規に設立 ビッグデータ解析、機械学習、自然言語処理 (株)リクルートホールディングズ 1960 2014 2012 (株)リクルートテクノロジーズ内に，新技術開拓部門として Advanced Technology Lab を設置 ビッグデータ解析、機械学習、自然言語処理 シナジーマーケティング(株) 1997 2007 2012 R&Dグループ を新規に設置 マーケティングおよびコミュニケーション研究 (株)ドワンゴ 1997 2003 2014 ドワンゴ人工知能研究所 を新規に設立 人工知能、特に汎用人工知能や全脳アーキテクチャに関わる研究 サイジニア(株) 2005 2014 （独立したR&D組織の設置なし） ビッグデータ解析、機械学習 学会やイベントなどで他企業のR&Dの方々と交流する機会も多々あるのですが、AIをはじめとする研究シーズをビジネス上の価値創出（イノベーション）につなげる過程で直面する課題についても、しばしば話題になります（もちろん、私たちのグループもいくつかの課題を感じています）。 それぞれの現場で課題解決のためにできることもたくさんあります。PDCAのサイクルをできる限りたくさん回したり、マネジメントを強化したり、R&D部署と他部署のコミュニケーションを活性化したり、といった取り組みはきわめて重要であり、実際に多くの現場でも実践されています。谷田さん・榊さんとも、それぞれの現場で行っている取り組みについての情報交換を続けてきました。 しかしながら、議論を続けていく中で、 「それぞれの現場での取り組み」だけでは解決できない、より大きな課題が横たわっているのではないか 、という認識も生まれてきました。成功事例の手法を実践することも確かに大事ですが、 R&Dをビジネスのプロセス全体の中でどのように位置づけるか、という哲学を浸透させない限り、実践は長続きしないのではないでしょうか？ R&Dだけでなく、イノベーションにかかわる多くのステークホルダー（経営、企画、営業、エンジニア、大学・公的研究機関、コンシューマー、...）が議論を共有できる土台があって、はじめて取り組むことができる課題もあるのではないか、という一つの考えが浮かび上がってきました。 そこで、今回の特集担当の機会をいただくにあたって、イノベーションをとりまく大きな課題を浮き彫りにするために、以下の2つの軸を設定して、イノベーションの最前線で活躍中の方々に執筆いただくことで、議論を共有するための土台を創るというチャレンジを試みました。 イノベーション創出に関わる人々の「役割」 経営、企画、営業、エンジニア、アカデミアなど、それぞれの「役割」の視点から感じていらっしゃる課題を共有していただくとともに、「役割」の違いから生じる意見の食い違いを乗り越えて連携するためのヒントを探る。 シーズ主導とニーズ主導 イノベーションを生み出すために、「シーズ」と「ニーズ」という2つの要素をどのように扱ったか、ビジネスの成長プロセスのどの段階でシーズを取り入れたか、といった事例をカバーすることで、イノベーション創出プロセスを俯瞰する視点を得る。 浮かび上がってきたイノベーションの「課題」と「ヒント」 著者の方々に執筆いただいた内容をまとめていく過程で、イノベーションをとりまくさまざまな「課題」、そして課題に取り組むための「ヒント」が浮かび上がってきました。 詳しい内容は特集記事に譲りますが、ここではいくつかの興味深いポイントを紹介します。 マーケットと直結したR&D環境の必要性 サイジニア社 代表取締役の吉井様は、 Netflix Prize の事例を紹介されています。米国DVDレンタル大手のNetflixが開催したレコメンデーションアルゴリズムのコンテストは、100万ドルの賞金やプライバシー保護をめぐる問題で大いに注目を集めました。しかし、 優勝したアルゴリズムは実際にはサービスに採用されなかった ことが、 Netflixエンジニアのブログ で述べられています。 その理由として、「研究用に取り出されたデータのサブセットに対して最適化を図っても、サービス運用の過程でユーザー行動のパターンが変化すること」が挙げられています。「データの科学の」時代に研究が実世界のイノベーションにつながるためには，最初から実環境、つまりマーケットからのリアルタイムなフィードバックが得られる環境での研究開発が重要になるだろうという議論は、非常に興味深く感じました。 R&Dへの適切なフィードバックの必要性 ホットリンク社 は、2004年という非常に早い時期から HottoLabo という産学連携組織を設立し、大学の研究シーズの技術移転に取り組まれています。ホットリンク社 代表取締役の内山様は、榊さんとの共著で、過去の成功事例・非成功事例を通じて、技術移転を促進するための行動指針案を提案されています。 具体的には、「大規模データが社内ですぐに利用可能な形で蓄積されていること」とともに、「R&Dチームへの適切なフィードバックがなされること」の必要性が論じられています。非成功事例では、R&Dチームへのフィードバックが顧客および営業チームから行われていたものの、シーズへの期待が実態以上に大きく、ニーズ側が想定していた機能と実際に開発された機能に差異があったことが、一つの要因だとされています。また、成功した事例では、ニーズとシーズの両方を理解しているメンバーまたはコンサルチームが、研究シーズへの過剰な期待をかけすぎないように、ニーズをコントロールしながら適宜R&Dチームにフィードバックを行えていたという考察が示されています。 イノベーションを促進するための価値観の多様化 お茶の水女子大学の 伊藤貴之先生 は、産学連携研究や学生教育などにかかわってこられたご経験をもとに、価値観を多様化することでイノベーションを促進する、という方策をいくつか提案されています。 日本の大学の研究教育は圧倒的にシーズ重視の傾向が強いことを、海外の大学との比較に基づき論じられています。伊藤先生が在外研究されていたときに学生から見聞きしたこととして、 （企業との共同）研究プロジェクトで与えられる命題は、当初は一見学術的価値のないルーチンワークであるかのように見える。しかしその中から問題を発見して解決することは可能だし、その研究成果が就職活動時に高く評価される という意見を紹介されています。一方で、伊藤先生がかかわっておられるVisual Analyticsというニーズ指向で生まれた学術分野についての話を日本国内で紹介すると、 研究分野全体のフレームワークや実用事例に関心を持たず、機械学習やインタラクションなどの各要素技術の理論的新規性だけを執拗に質問してくる人が少なからず見受けられる という経験があったと述べられています。学術性新規性はいったんわきにおいて研究を始動し、新規性は後からついてくる、といった研究体制も認めるような価値観の多様化こそが、イノベーションの多様化につながるのではないか、という考察を示されています。 また、日本の大学には、「演習科目の充実度」「インターンシップの機会」「基礎教育の充実度」などで課題がいくつもあるものの、弱点を補うためにできる工夫についても論じられています。 - 産学連携の一環としてインターンシップをとらえる。日本のIT企業でも、正社員がメンターとして学生をきっちり指導し、学生の本質的スキルを高める業務を経験するケースを多々見聞きする。教員としても、短期的に学生が離れるのは痛いかもしれないが、学生がたくましくなって帰ってきてくれれば収穫になるはず。 - 基礎教育で得られる知識の重要性を体験させる機会を設ける。具体的には、数学的素養を必要とするプログラミング実習の実施や、IT基盤知識の重要性を実感できるインターンシップを勧めるなど。 女子大学に勤務されている先生ならではの視点として、女子学生が活躍できる環境をつくることによる価値観の多様化についても議論を展開されています。IT分野での女性の活躍は世界共通の課題認識となっており、 ACM などの主要学会でも女性の活躍に期待した多数の論文や記事が発表されているようです。伊藤先生は、女子学生を対象としたアンケートや見聞きしたことを通じて、 - 海外と比較して、高校での進路選択の際に「情報系学科への進学を薦められる機会が少ない」傾向がある - 学際的・融合的なテーマや、ニーズ指向に近い問題解決型の研究に興味を持つ傾向がある - IT分野について、報道や会話を通じて「理解」「共感」する機会が少ない といった考察を示されています。 一方で、IT企業が主催する女子学生限定のインターンシップやハッカソンなどのイベントに協力した際に感じられたことについても言及されています。参加した学生から、「いままで参加した他のセミナーよりもはるかによく理解できた」「こんなに自分のアイディアに共感してもらえる機会は初めてだった」といった感想が聞かれたことが印象的だったとのことです。こういった理解・共感を得る機会が一度あるだけでも、女子学生の自信・モチベーションを高める機会となり、独自性のあるイノベーション醸成につながる、という期待を述べられています。 おわりに 今回の特集では、非常に短い執筆期間にもかかわらず、いずれの著者の方々も非常に質の高い記事を執筆いただきました。また、単なる成功体験にとどまらず、イノベーションを生み出すために日々悩み、苦闘し、試行錯誤を続けられているプロセスをも披露していただいています。失敗体験や困難への直面など、書きづらいことがらについても率直に書いていただいた著者の方々に、厚く御礼申し上げます。 特集をとりまとめる経験を通じて、 多くの現場で共通する課題があること 、 多くのステークホルダーの人々と協力することでしか解決できない課題があること をあらためて感じました。得られた知見を私たちのR&D活動でも生かしていくとともに、議論を盛り上げる視点を提示することで研究コミュニティに貢献できればと思います。

こんにちは。リッテルラボの池田です。 いよいよ4月。新年度ですね。 そんな新年度の幕開けにふさわしい新たなプロダクト 「超★すごい天秤」を発表しました！ リッテルラボの渾身の最新作の詳細は、こちらからご覧ください。 ＜超★すごい天秤　プレスリリース： http://www.next-group.jp/wp-content/uploads/2015/04/20150401X.pdf ＞

池田です。 本日は、iOSの強力なアクセシビリティ機能「VoiceOver」について書いていきたいと思います。 この機能は、視覚障がい者向けのアクセシビリティ機能で、視覚障がいを持たれた方が、iOSを使いやすくする工夫、機能が様々含まれています。 ここでは、その機能をご紹介していこうと思います。 読み上げ VoiceOverを有効にしている環境下では、画面上に白い枠のカーソルが現れます。 そしてそのカーソルが当たってる画面上の項目が何なのか、どういった操作ができるのか、といった情報を音声で読み上げてくれます。 この機能により、画面を見ずともiOSのデバイスを操作し、画面の状況、情報を知ることができます。 具体的には、以下のようにカーソルが表示され、ここでは「戻る ボタン」と読み上げられます。 VoiceOver環境下では、このカーソルを操作して、iOSを操作していきます。 カーソルと選択項目の操作 VoiceOverを有効にしている環境では、タップ、フリック等の操作は画面上に表示されているカーソルの操作、または、カーソルで選択している項目に対する操作になります。 また、1本指、2本指など、画面に置いている指の数によって操作が異なります。 まとめますと、以下の表のようになります。 操作 1本指 2本指 3本指 4本指 タップ タップ位置の項目を選択 読み上げ停止/再開 ページ番号/行読み上げ (画面上部選択なら)最初の要素に移動/(画面下部選択なら)最後の要素に移動 ダブルタップ カーソル位置の項目を決定/実行 アクション開始/停止(電話をとる/きる等) 読み上げON/OFF VoiceOverヘルプを開始 トリプルタップ カーソル位置の項目を決定/実行 項目セレクタ(画面上の項目をアルファベット順に表示) スクリーンカーテンON/OFF -(操作なし) 上フリック 前の項目に移動 上からページ読み上げ 1ページ下にスクロール -(操作なし) 下フリック 次の項目に移動 選択項目から下にページ読み上げ 1ページ上にスクロール -(操作なし) 左フリック 前の項目に移動 -(操作なし) 1ページ右にスクロール -(操作なし) 右フリック 次の項目に移動 -(操作なし) 1ページ左にスクロール -(操作なし) この表にあるような操作で、カーソルを画面上で動かし、自分が操作したい、または情報を得たい項目に合わせ、項目の決定、実行などをすることで進めていきます。 最初は少し慣れが必要になってきますが、操作を繰り返して、慣れていけばスムーズに操作できるようになってきます。 特殊な操作 VoiceOverの操作の中には、VoiceOver独自の特殊な操作があります。 この操作は、VoiceOver環境下での利便性が考慮されている、素晴らしい機能が含まれています。 以下に特殊な操作を挙げていきます。 スプリットタップ 1本指で画面を触りながら、もう1本の指で画面をタップする操作です。 例えば、人差し指で画面を触りながら、中指で画面をタップします。 この操作では、画面上を触っている指(上記の例なら人差し指)で選択している項目を決定、実行するという操作ができます。 スプリットタップは、文字入力の際に便利で、「English(US)」キーボードであれば、1本目の指でアルファベットを探し、もう１本の指でタップすることで決定、また、「日本語かな」キーボードであれば、1本の指で行頭の文字を選択しながら、もう1本の指で画面をタップし、その行の次の文字を入力していくことができます。 「あ」行を選択しながら3度もう1本の指でタップすると「う」が入力できます。 エスケープ 画面上に2本指を置き、アルファベットのZ(ゼット)を書くような操作をすると、「エスケープ」と呼ばれる操作になり、「1つ前の画面に戻る」などの動作ができます。 例えば、間違って、次の画面に進む操作をしてしまった場合、次の画面で2本指でZを描けば、すぐ戻ることができます。 スクリーンカーテン 画面上を3本指でトリプルタップすると、画面の表示を消した状態でVoiceOverの操作をすることができます。 この機能があるおかげで、人に画面の情報を見られることなく、プライバシーを保ちながら操作、利用をすることができます。 まとめ VoiceOverは、視覚障がいを持たれた方にとって、iOSを操作しやすくする強力なアクセシビリティ機能です。 現在、このVoiceOverは、そこまで認知度が高くなく、視覚障がいを持たれた方がiOSを使えること、そして、それを支える強力な機能があることがあまり広くは知られていないのではないかと思います。 ただ、この機能は本当に素晴らしい機能で、もっと広く認知されるべきだと私は考えています。 もし、「今回初めて知った！」「すごい！」と思われる方がいらっしゃいましたら、ぜひ周りの方にもお伝え頂ければと思います！ VoiceOverをより多くの方に知って頂き、視覚障がいを持たれた方が更に便利になる環境が発展していけばと思います。

こんにちは。藤原です。 3月ももう終わりですね。 今期を締めくくるとともに、来期へのスタートダッシュに向けて、部署内で今期の振り返り会などを行われている方もいらっしゃると思います。ただ、振り返り会って結構難しくないですか？ 私達も今までは一般的なKPT法で振り返り会をしていましたが、様々な課題がありました。 日々の業務中だと、良くなかった面にばかり目が行ってしまい、結果Keepがでなくて、Problemが多くなり、成果物としてTryが増え、やることが増えてしまった。 日々の業務が多忙な中に付け加える形で、Tryの項目が増えてしまい、結局こなせなくなり、中途半端になった結果として、最終的には振り返りが意味を成さなくなっていた。 毎回の振り返りが「Problem」ばかりで不毛な会になってしまい、気分的にも決して良いものにはならなかった。 本来はプロジェクトが終わる毎に振り返り会をしていましたが、 今回はプロジェクトというよりもチームとしての振り返りを意識して、 今までとは少し違った「 褒め会 」というやり方を試してみました。 今回行った褒め会の進め方 この1年を振り返って自分が試してみたこと、意識してやってきたことを共有する。 他のメンバーがこの1年実践していたことで、評価したいことや真似したいと思ったこと、つまり褒めたいと思ったことを共有する。 これをそれぞれメンバー分繰り返す。 最後に共有した内容から、グループ内で試してみたいことが出てきたら、試すための仕組みを作る。 褒め会から得られたこと 普段、良くない点に目が行きがちなので、お互い褒め合う、称えるということは難しい。 自分の思っている部分とは違う部分を褒められたりして、自分の中にも新たな発見があるし、他の人が褒めているポイントも新たな気付きの参考になる。 最終的には気分よく会を終えることが出来た。 やってみて気が付いたこと メンバーによって「褒められる方がいい」「厳しく指導される方がいい」の2つに別れ、それぞれの性格や考え方が垣間見えたこと。 欠点は嫌でも目についてしまいがちで、良い所、褒めるところに気がつくのはなかなか難しい。普段から注意して観察していないと中々発見出来ないので、普段から意識して周りを見ることが必要。 周囲を思いやる、気を向けるようにするという意味でも、やって見る価値はあると思いますし、結果やってみてよかった。 ということで、気持ち良く1年を振り返り、次へのスタートダッシュを決めるためにも「 褒め会 」オススメです。

こんにちは。藤原です。 スキルアップのために本をガッツリ読んだり、やりたいことの整理をしたいけど、なかなか普段は時間がとれなくて・・・、という方も多いと思います。また、それを家でやろうとすると、誘惑が多くてなかなか手を付けられないとか、環境を作ることが出来なくて自宅だと進まない！という方もいらっしゃるかと思います(私です)。 やりたい、やらなきゃいけないと思っていたことを積みに積んでいた中で、スケジュールがポッと空いてしまい、かつ残っている有給を有意義に消化したい、でも旅行に行く計画も急すぎて難しい・・・というところで試してみたのが「 一人合宿 」です。 で、その「一人合宿」をやるにあたって、自分が行った事前準備と、実際やってみてどうだったか、ということを書いてみたいと思います。 一人合宿の事前準備 目的とやりたいこと(タスク)の整理 何をどこまでやればゴールとするのか、ということを事前に決めて計画を立てておきましょう。 ターゲットを絞っておきましょう。 あれもこれもと手を出すと全部中途半端になるのと、途中で嫌になって何も進まなくなってしまう可能性があります。 スケジュール 出来れば2泊3日以上のスケジュールを組みましょう。 1泊だとすぐに終わってしまい、なかなか成果を出しにくいと思います。 また、睡眠時間をけずってやっても良いinput/outputが出にくいと思うので、あまり無理な予定を立てないことが大切かと思います。 初日にある程度軽いタスクを計画すると良いです。 これで行けるというペースを把握し、2日目以降に腰を据えてやるタスクを計画するとよいでしょう。 場所の選び方 個人の好みによりますが、和室よりも洋室を選んだほうが良いかと思います。 畳で寝転がってやったほうが進む！という方の場合は別ですが、いつでも机に向かえる、いつでもベットで休める環境の方が、メリハリは付けられやすいかな、と思います。 机が広い場所を選びましょう。 ノートPCを広げたら一杯になってしまい、本やノートを広げることが出来ないとちょっと厳しいです。 照明が明るいところを探しましょう。 ビジネスホテルは割合照明が暗いところのほうが多いです。 できれば加湿器が設置してあると良いです。 空調によって室内が乾燥することが多く、体調を崩すこともあります。 （濡らしたタオルを干しておくことでも乾燥を防ぐことが出来ます） ある程度交通の便が良い場所をおすすめします。 それなりに機材を持ち込むとなると荷物も自然と大きくなります。 荷物の持ち運びなどを考えた場合、駅から近いほうが楽かと思います。 （自分の場合は、ターミナル駅から徒歩2,3分程度の場所で試しました。） 近くにコンビニ等があるところを見つけましょう。 あまり観光地すぎるところに行くと、徒歩圏内にコンビニがないことがあって、ちょっとした買い出しなどに困ることもあるかもしれません・・・。 機材持ち込み インターネット回線(wi-fi) ホテルのLANは有線・無線ともにつながらないとか、速度が出ないことがありがちです。 またホテルから、無線LANとしてFree Wi-fiが提供されていることがありますが、気分的にもあまりよろしくないかなーという感じがします（あくまでも個人的な感想ですが）。 なお、持ち込む回線のキャリアが、サービス提供エリアであるかを忘れずに確認しておきましょう。 （地方だとサービスエリア外ということがあり得ます・・・） ヘッドフォン/イヤホン 音楽を聞きながら作業をする方はぜひイヤホン・ヘッドフォンを持ち込んでください。 集中するためというのもありますが、周囲に迷惑を掛けないという理由もあります。 ブックスタンド 本を開きながらPCに向かうのであれば必要かと思います。 amazonで1000円前後で売っているので、そのくらいで十分かと思います。 （荷物もあまり大きくならないほうがいいでしょうから） その他準備したもの 個人的に準備したものとして、軽くつまめるお菓子類や、水やお茶を事前に買って持ち込んだり、 作業着としてリラックスできる普段着を持参しました。（ホテルの浴衣だと作業しづらいですし・・・) やってみた感想 当初の見積もりよりも、「タスクごと」の進捗が出やすいです。普段の業務効率で計算すると、差し込みがない分集中度合いが増し、結果として予定より早く終えられたりしました。 ただし疲労もいつも以上にでます。2日目の夕方以降は姿勢が悪かったせいか、肩こりなどで体調を若干崩してしまい、その後の進捗を出すことが出来ませんでした・・・。 手を動かせば進捗が明らかなもののほうが良さそうです。 ドハマりしそうなタスクは避けたほうが良いです。 アプリでいろいろ試そうとしたものの、やり方が分からず調査に時間をかけたら、半日過ぎてしまったということがありました。お金かけたのに成果でなくて何やってんだろう・・・って感じを避けることも必要かと思います（苦笑）。 結果的には最低限やりたいことは一通り着手でき、形にも残すことが出来たので、良い「一人合宿」を過ごすことが出来たかと思いました。 ちなみに具体的な成果として「既存のアプリのデザイン改修案作成」「プレゼン資料の下書き」「ブログの下書き」というタスクはおおよそ予定通り出来たのですが、「アプリのモックを作る」のがまさにドハマりタスクで、進捗があまり進められず・・・。「読めなかった本に手を付ける」ことがおざなりになってしまいましたが、優先順位が高いものは何とか出来た！という感じでした。 普段時間が無い人にこそ、オススメな方法かと思いますので、良ければぜひ試してもらえれば、と思います。

こんにちは、上津原です。 タイトル通りですが、Unity5が出たので早速移植をしてみました。 機能実装はしてないんですが、見た目がどれくらい変わるのか気になったのです。 ビフォー Unity4で作ったときのが以下です。 いやー、恥ずかしい！当時全力で作ったのですが、今の自分から見ると「あ～ららｗ」という感じにしか見えません。まあでも今もそれほど腕は進化してないんですけどね…。 さて、これらのモデルをまるっとUnity5に持ってきて、デフォルトマテリアルにちょっと色を付けた程度のもので作ってみたのが… アフター じゃーん！こちらです。 かなり柔らかな光表現になっています。シェーダーは一切使っていません。 Unity5になって大きく変わった点は、光の反射表現がとっても手軽になっていたので、天井の日当たりが自然になったというのが感動的でした。同じモデルなのに、光の表現だけで結構それなりに見えてくるのが不思議です。 これらには、ノーマルマップもないしシェーダーも使ってないので、きちんと揃えてゆけばもっと幅広くて素敵な映像表現ができそうですね。 これがまさか無料になるとは UE4が先日無料になったので「あー、これはUE4一択だわー」みたいに思っていたのですが、まさかUnity Freeに全機能が入ってくるとは思ってもみませんでした。 個人的に比較してみると、手軽にリアルな映像表現という点ではUE4に軍配が上がりますが、汎用性や軽さという点ではUnityに軍配が上がります。 モバイルので利用は圧倒的にUnityなんだろうな、ノウハウもあるし。 UE4とUnity、それぞれこれからの展開が楽しみですね。

こんにちは、上津原です。 まだ寒いですが、こたつを片付けてしまいました。後悔しています。 さて、今回もまたpepperの話題です。 題名の通り、他のアプリケーションをコントロールする方法です。 あるビヘイビアを実行中に、別のビヘイビアのあの機能が使いたいのに！という時ありますよね。だけどそれってどうすれば？という時に、ALMemory使えばいけるんじゃないか？ってことで試してみたら動いたのでご紹介します。 RunBehaviorして、ALMemoryのraiseEventしてやればOK はい、上記のとおりです。開発環境があればChoregrapheで並列実行してやればいいですが、スタンドアロンで動いて貰う場合そうは行かないので、さくっと実装してやります。 ChoregrapheでRunBehaviorをやると並列してビヘイビアが実行されるので、ALMemoryを利用した連携が可能になる 、ということになります。 では実際に見てみましょう。 それぞれの構成はこんなかんじ。 メインビヘイビア サブビヘイビア この時点ではメモリイベントは抜いてあります。 メインビヘイビアが実行されたら、ちょっと喋ってサブビヘイビアが立ち上がるようになっています。 それをここからメモリイベントを追加していきます。 サブビヘイビアにメモリイベントを作成 サブビヘイビアのここにある「＋」を押して、メモリイベントの一覧を出します。 そして、下の方にある「新しいキーの追加」を押して独自キーを作成します。 今回は「subBehavior/event1」としました。 そうしたら、左隅に「〜」みたいなマークが出来ます。 これがメモリイベントのスタートポイントになります。 とりあえずSayをくっつけて「メモリイベントだよ」と喋るようにしておきました。 メインビヘイビアにRaiseEventを作成 呼び出されるイベントの作成は完了したので、後はそれを実行するだけです。メインビヘイビアに実行部分を作っていきます。 とりあえず今回はお手軽な「Tactile Head」を使いました。pepperの頭のタッチセンサーですね。 シミュレータの人は動かないと思うのでSpeechRecoなど、インプットがこちらから任意に出来るものを利用すればいいと思います。 そしてRaiseEventノードをつないで、先ほど設定した「subBehavior/event1」を入力します。 コレで出来上がりです！簡単ですね！ メインビヘイビアを実行 メインビヘイビアを実行すると、サブビヘイビアが立ち上がり、その後頭を触ると先ほど設定した「メモリイベントだよ」を喋ってくれます。 RaiseEventは、インプットタイプが「ダイナミック」に設定してあります。つまり、ここにイベントに渡したい情報（文字列、数字など）を渡してやれば、 変数の受け渡しも可能になります。 わ～ベンリ！ まとめ Choregparheを利用してロジックを組む場合、クラスやインスタンスを呼び出したりという行為が出来ないっぽいので、ALMemoryを利用したテクニックは必須になると思います。 そして一旦使い方がわかると一気に可能性の幅が広がります。前回紹介したQiMessaging.jsもALMemoryにアクセスできるので、JSでペッパーと相互でデータのやり取りも可能になったりもします。 今回のプロジェクトもGithubにアップしておきますので、もし良かったら自由に使ってください（とっても簡単なものですけど…） kuetsuhara/pepper_almemory_heiretsu kuetsuhara/pepper_almemory_heiretsu · GitHub それでは。

こんばんは、Androidグループの中村です。 先日、テスト自動化のセミナーに参加してきました。 自動化する時の観点について、 テスト自動化研究会 のコミッターとしても活躍されている浦山さつきさんから、興味深い話があったので共有したいと思います。 自動化対象選びのポイント「手順が決まっていて実行頻度の高いもの」 繰り返し行われること 面倒くさいと思っていること ミスが起こりやすいところ 手順が決まっているところ 変更が少ないところ 以上が自動化対象選びのポイントとのことです。 面倒くさいと思っているから作業者の集中力が切れてミスする、見誤ってミスする、これってせっかく作業しているのに本末転倒… でも意外とこういうことってありますよね。 あと、プロセスを見直すことで手順を定め、自動化も可能になるかもしれないということは 通常業務の見直しもでき、お得感がありますね。 またまた、変更が少ない箇所を自動化するっていうのは私がこれまで行ってきた業務からもそうだなと感じます。 頻繁に変更されている画面のテストなどを自動化してしまうと、メンテナンスのコストがかかってしょうがないです。 自動化だけが策ではない! 手順が決まっていないと自動化できない 一見すると、自動化に向いた作業でも実はやらなくてもいい作業かもしれない 情報伝達ができていないだけであれば自動化することはない 役に立たないテストや作業を自動化しても意味がない この観点は、仕事の中で忘れがちではないかなと思います! なんでもかんでも自動化すればよいのではなく、対象をきちんと選別し、効果のある作業を自動化する! これでよりいっそうの仕事効率化がはかれますね。 自動化導入時の3ステップ 「計画 -> 試す -> 広める」 自動化を新たに導入するときには、3ステップ踏むとよいとのことです。 【計画】 関係者を決める 「推進役」「変革の請負人」「組織上層部の支援者」 道具を選ぶ 身近にあるツールや技術を使う、関係者の知見経験を使う 試算する 一時的な生産性の低下は避けられない、どこで巻き返せるのか試算する 試算する要素としては道具にかかるコスト、自動化にかかる時間とコスト、失敗したテストを確認するコスト(なにが原因なのか解析する時間) メンテナンスにかかるコスト、教育にかかるコスト、期待できる効果等があるとのことです。 【試す】 パイロットプロジェクトを立ち上げる 自動化した仕組みがうまく適用できるか検証する 実現可能か見極める ここでの数値が広める時の根拠になる パイロットプロジェクトの効果を見ることで、既存プロセスへの影響を再確認ができ、新しいツールや手順について学習ができるとというメリットがあるとのことです。 【広める】 共有する 成功の根拠を提示して同意をえる 内部からの反発に注意 支援する 最初はパイロットプロジェクトを実行した人が一緒にやる 他の人への教育も行う 見守る 効果を監視する フィードバックをもらい、計画の見直しを行う ここで注意しないといけないのが「内部からの反発」とのこと… プロジェクトの目的、役割を考えさせたり、そして…組織上層部の支援者からのトップダウンも効果的とのことです。 Androidグループ ちなみに、私たちのグループでは Jenkinsを導入しています。 ユニットテストを一定間隔で実行したり、 ビルドを自動化し、 デプロイゲート というツールをつかって 企画、制作、開発メンバーがapkをWebからダウンロードし、テストをみんなで行える環境を構築する等を行っています。 まだまだ自動化して効率化できる箇所もあると思います。 浦山さんの話にもあったようにプロセスの見直しをはかり、開発効率をあげて、よりよりアプリを提供していきたいと思っています。 おわり

はろーはろー！チバと申します。 2014年9月にジョインしたばかりの新参者でして、当ブログへの投稿も初めてとなります。 今回は弊社を会場にしてTech系イベントを開催したので、そのときのレポートをお送りします！ 「タスク管理ツールNight!」とは 実際に組織・個人で使用しているタスク管理ツールの使い心地、使い方の工夫を熱く語ってもらうイベント です。 今回は6ツールにフューチャーして、それぞれを使用しているユーザーの方々に登壇していただきました！ 「ツールの導入検討をしている方」 、 「ツールをうまく活用できていない気がする」 などを課題としている方をターゲットに告知し、開催へ至りました。 弊社内でも最近Atlassian社のJIRAを導入した部署があります。 しかし、「よく出来たツールだと思う！使いやすい！でも、もっと活用できるのではないか」と疑問を抱いていたため、 タスク駆動を考えなおす機会 として主催に踏み切りました。 紹介されたツール Trello Chatwork Github Issue JIRA Pivotal Traker esa 募集をかけた際に驚いたのですが、かつて一世を風靡していたRedmine http://redmine.jp/ やBacklog http://www.backlog.jp/ などが出てこないんですね…！ もう彼らは過去のモノなのか、はたまた今回集まった人たちには刺さらないニーズなのか… 当日の様子 イベントはスピーカー6人を中心に、 LT（Lightning Tark）と座談会の二部制 でお送りしました。 LT…ツールの概要や導入経緯、目的の話をしてもらう。 座談会…設けた2つのテーマに沿ってフリートークしてもらう。 1. LT 1. slackとtrelloで幸せになる　張ヶ谷 拓実さん タスクカンバンツールのTrelloと、チャットツールslackを使って、情報をうまくフロー型とストック型に分けて運用している よ、というお話です。 Trelloのいいところ、としてUIとFilterを挙げられており、確かに「 ツールを使う気にさせる」の設計 にはTrelloは非常に優れているなあ、と感じました。 ステータスも随時サクサクっとアップデートできるため、現場感高めなチームにはとても向いてると思います。 2. 仕事がデキる障害者は皆使っている？ITが苦手な方にこそオススメしたいタスク管理ツール　白井 祥剛さん 初期の営業成果が実り、今では誰もが知ってるツールになったChatwork！そんなChatworkを用いて、遠隔コミュニケーションに支障が出ないようにこんなタスクの運用ルールを設けているよ、ってお話です。 プロジェクトごとにグループを作成し、 乱雑にグループが作られないようにルール化 し、 完了基準を明確 にしてタスクとするなど、チームに最適化された使い方でとても羨ましいと思えました。 3. お金の無いプロジェクトでgithub issueで円滑に開発を進める方法 (仮)　joker1007さん タスク発行時の入力項目が多いと、タスクを捌くことがおざなりになってしまった ことから使い始めたってお話です。 外部サービスであることから メンテナンス要員が必要なく 、さらに コードとも連携できる ため、タスクに基づいた開発ができるいい感じの運用をされています。 Githubの弱点を補なうサービスとして紹介されていたWaffle https://waffle.io/ がよさ気なので、試してみたいなぁと思いました。 ★スライド公開されてます。 4. 経営者が唸る！JIRAによるタスク稼働管理 　佐藤 卓也さん 経営と開発と事業をつなぐことが可能であるため、JIRAをチョイスしたよ、というお話です。 個人的に、タスクは未来を作るものだと思っていまして、 Doneしたデータが予算決めや経営会議の材料として活用されている ってのはめちゃくちゃ熱かったです。 また、 月初までにEpicやStoryを用意して、月に入ったと同時にタスクが動き始めるルール はとてもいいなあと思いました。 ★スライド公開されてます。 タスク管理Night　JIRA推し from Takuya Sato 5. PivotalのWorkspaceを有効活用する方法　小島 泰洋さん もともと紙付箋で管理していたが、デジタルにして 優先度順にタスクを俯瞰できるように したよってお話。 タスクのVelocityをちゃんと見積もれて いて、且つ それの精度が開発期間と＝にして活用しきれている のが素晴らしいですね。 物理カンバンでの限界を感じたときには、まずPivotal Trackerに手を出してみるといいのかもと思いました。 ★スライド公開されてます。 PivotalTrackerでシンプルなタスク管理のススメ from Taiyo Kojima 6. ポエムで支える月間38億PVメディア開発(仮) こしば としあきさん 今回はタスク管理の“それ以前”、「終わった」、「終わっていない」を管理する前である 「タスク管理になにを載せるかを見つけるため」 に使っているツールのお話。 「タスク」に成り得る前である定義されていない「これやってみたいんだよね」などを共有するには、ポエムを推奨したいとのことでした。 誰かが思いつきで言った一言を、皆で育ててタスクへ昇華させるようなフローで運用 されており、ブレストっぽさを感じました。 近々、esaのMeetUpがあるとのことです。（キャンセル待ち！） (\\( ⁰⊖⁰)/)会 - esa | Doorkeeper 2. 座談会 1. タスク管理ツール利用遍歴 タスクを残す奴は許せない論 が出ました。 期限切れ放置タスクの問題、そもそもは「とりあえずタスクにしておこう」が動機であることが多いため、 まずは「タスク」にすることの定義など、明確な運用ルールを設ける必要がある よね、と落ち着きました。 それと、今回はタスク管理ツール × チャットツールのお話も多めだったことから、会話の流れにタスクを関わらせることの話にも触れられていたかと思います。 通知としてチャットツールを活用したり と、 なにかと併用することでの利便性向上 の未来が見えました！ 2. タスク管理で尊重する流儀 運用上でのルールのお話がところどころであったことから、触れておきたいなと思ったテーマです。 「これは譲れない」、「これは守るべきものだと思う」なルールについて 話していただきました。 そこで出たのが「なるはやで！」の文化ｗ 優先度をすべて高にしてしまうことの無いように、 明確に緊急度を設けておく必要性 を説いてもらいました。 また、現在は 「ToDo」として定義されるタスクが「やりたいこと」、「やるべきこと」が分かれていないから乱雑になる ！との指摘も。 この「やりたいこと」、「やるべきこと」をわけることで、運用改善の兆しが見える気がしました。 最後に、 それぞれのチームやプロジェクト（案件）によってツールを使い分けるのも手じゃないか という話。 メンバーや状況が変わるのであれば、勿論その都度の「最適」も変わるはず。 必ず同じ手法やモノでうまくいくとは限らない のでは、と話してもらいました。 RedmineやBacklogの話題が薄れたように、 今回紹介されたツールもいずれ消えていくかもしれません 。 それは、開発手法やプロジェクトの特徴が時代と共に変化していくことからしようがないことだと思っています。 そのためには 今後の未来を見据えた柔軟さ（選定基準となる明確な目的、エクスポート可否の確認）が必要 なのかもしれません。 ドラ娘 タイムキーパー兼ドラ娘を、弊社のpepperくんが務めてくれました！ この大役を強引な進行っぷりで進めてくれて、おかげでロスタイムなくイベントが進行されました。ありがと〜〜 受付嬢も兼ねてくれました。優秀だ！きっと私より仕事してる！！ 事後アンケート ご来場くださった皆さんのおかげで、なんと 脅威の回答率91％ ！ありがとうございます！ やはり開催時間短かったですよね…、申し訳ない…。いつか拡大版として、リベンジを狙います！ 改善すべき課題が見つかった、素敵な回答でした。この結果は、今後のイベント開催・運営に役立てていきたいと思います。 まとめ 今回は6名のスピーカーの皆さんにお話していただきましたが、LT・座談会を通すと会場にも熱気がこもってきて、 「この会場のどこかに、今、マイクを持ちたいと思っている人がいる…！」 と確信できましたｗ アンケートにも「質疑応答時間が欲しかった」といくつもご意見いただいていたので、ビアバッシュのような機会で会場まるごとディスカッションできたらいいなぁ、と考えたりしました。 また、私事なのですが、今回のイベントで久しぶりに主催者ができました。 いつもと勝手の違った会場でしたが、周りの方のサポートがありなんとか開催まで至りました！本当にありがとうございます。 言い出しっぺの日から1ヶ月ちょっとでの開催、成功と言える結果となれて嬉しいです。 またいつか、今回のように制作現場を取り巻く環境を良くしたい！な目的路線でイベントを主催したいと思います。 すべてのものづくりに関わる人が幸せになれる環境模索をしていきたいですね！ イベントが紹介されているブログ、まとめメディア タスク管理ツールNight! #TaskToolNight - Togetter タスク管理ツールNight! タスク管理ツールの宴 リンク集 #TaskToolNight - Qiita タスク管理ツールNight! に参加してきた - kakakakakku blog 「タスク管理ツールNight」頼む、お前の推しツールを教えてくれ！に登壇してチャットワークについて語りました - gorian91@電子書籍セレクト タスク管理ツールNight行ってきた #tasktoolnight - 帰ってきたHolyGrailとHoryGrailの区別がつかない日記 タスク管理ツールNight!に参加した - reizist's blog

こんにちは、上津原です。 前回はpepperくんをソケット通信を利用して遠隔で動かしました。今回はQimessaging.jsを利用して、ブラウザから動かせるようにしてみました。 Qimessaging.jsの最新版は こちら で入手する事ができます。 作るにあたって、 こちらのQiita記事 を参考にさせてもらいつつ、個人的に欲しいなって思っていた、オートノマスモードのON/OFFや、スリープのON/OFF、ビヘイビアの実行などを実装してみました。 作ったものは以下です。初めてBootstrapとか触ったので、すごくごちゃごちゃしてますが、ちゃんと動きます。 ペッパーコントロール： http://kuetsuhara.github.io/pepperConnect.html pepperと同じLANにつなぎ、pepperのIPアドレスを入力して「接続」を押せば動くはずです。 ※「ハイタッチ」ボタンは、うちのペッパーの独自ビヘイビアなので他の人のペッパーでは動きません。 qimessaging.jsってなんじゃ？ qimessaging.jsは、平たく言えばJavaScriptからNaoqiのAPIを操作することが出来るものです。 なのでコレを使えば、pepperを歩かせたり喋らせたり動かしたりと好き勝手できちゃうわけですね。 pythonでももちろんNaoqiにアクセスすることが出来ますが、ブラウザから動かせるということは、ウェブサービスとのつながりなども想定に入れられたり、スマホから操作ができたりと色々と夢の広がる感じになります。 qimessaging.jsを使えばUI作成が楽！ 動作に多少のラグがありますが、手軽にコントロール画面が作れるのは魅力的です。 pythonで作ろうもんなら、実装して〜、Qtいれて〜、その後exeにして〜とか考えてるとうざったくてしょうがないです。 そこをささっと「取りあえず動く状態」を作ることが出来るというのは大きな魅力だと思います。 最初はとりあえずってことでベタのHTMLで書いてましたが、途中からBootstrapを入れて多少見た目を作りつつスマホ対応をしつつ〜と、だんだんUIこだわっていけるのも魅力的なところですね。 JavaScript使いの人も「JSでロボット操作ができる」と聞けばとりあえずはワクワクっとするのではないでしょうか。 結構手軽にpepper乗っ取りできちゃうよねコレ JSだからなのか、複数人同時におなじpepperにつないだり、同時に操作ができたりします。 例えば、ある人が喋らせてる時に、他の人が動き回らせたりできちゃうわけです。 そして、IPアドレスとネットワークさえわかってしまえばとってもお手軽にpepperに接続できちゃうわけなんですね。 ということは、pepperが複数いるところのネットワークにつなぎ、そのpepperのIPを掴んでしまえばpepperを横から操作できてしまう、ということにもつながります。 なので、もしpepperを使ったイベントなどでWifiネットワークをゲストに提供することなどがあるならば、pepperとゲスト用のWifiは別々にしておくのが良いと思います。 知ってる人がいれば、さくっと乗っ取られちゃう可能性があるわけですからね。うーん怖い。 ソースコードご自由にどうぞ んで、この作ったコードですが、どうぞご自由に使ってもらえればと思います。 数年ぶりにhtmlやJSを書いているので汚なかったり、なんかルール無視してるのはご了承ください。 kuetsuhara/kuetsuhara.github.io kuetsuhara/kuetsuhara.github.io · GitHub

こんにちは、ネクスト　リッテルラボラトリーの清田です。 最近、pepperくんにコンシェルジュ的なことをやらせてみたい、と思って触り始めています。 ただ、pepperくんにデフォルトで搭載されている音声認識エンジンですが、 まだまだ精度がいまいち といったところで、pepper開発者の皆さんも苦労されているかと思います。 もちろん、Speech Reco.ボックスで認識させたいことばをすべて登録しておけば精度は出せますが、やはり地名や駅名なども認識させたいところです。 そこで、今回は rospeex というライブラリを使って、クラウド音声認識サービスを使う方法を試してみました。 ROS (Robot Operating System) を利用しています。 詳しい利用方法についてはQiitaに書いていますので、そちらをご覧ください。 Qiita: pepperでクラウド音声認識サービスを使う (ROS Indigo, rospeex) クラウド音声認識サービスとは？ 認識したい音声を含む信号データをAPI経由でサーバーに送ると、認識結果をテキストで返してくれるサービスです。 SiriやAndroidの音声認識機能でも、認識処理はサーバー側で行われているようです。 Google Web Speech API Demonstration のページでは、Google Speech APIによる音声認識を試してみることができます。 とくに固有名詞（地名や会社名など）の認識精度には驚く方も多いのではないでしょうか？ 噂では、 深層学習 (Deep Learning) が使われているのではないかといわれています。 また、 情報通信研究機構 (NICT) も、rospeexを通して利用できる音声認識サービスを公開しています。 こちらは、日本語・英語・中国語・韓国語の4カ国語に対応しています。 pepperくんのマイク信号をネットワーク経由でキャプチャする NAOqiのライブラリに入っている ALAudioDevice を使うと、ネットワーク経由でpepperくんのマイク信号を取得したり、pepperくんのスピーカーに出力したりできます。 APIドキュメント によれば、マイク信号には「front, rear, left, right」の4チャンネルが含まれていて、サンプリング周波数はそれぞれ16000Hzになっているようです。 今回は、ROSのパッケージ naoqi_sensors に含まれているmicrophone.py を利用してマイク信号をドライブします。 「話しているところ」だけをどうやって抽出するか？ マイクで取得した音声信号をすべてクラウド側に送ってしまうと、あっという間に接続制限を食らってしまいます。 そこで、音声信号の中から「話しているところだけ」を抽出する処理が必要になります。 今回は、とりあえずマイク信号の 二乗平均平方根 をとって、エネルギー値が閾値を上回る箇所を抽出する方法を利用しました。 Python SpeechRecognitionモジュール の処理を参考にして、 audioopモジュール を用いています。 Pythonのソースコードはこちら どれくらいの精度で認識できるか？ きちんと実験できているわけではありませんが、認識エンジンにGoogleのものを使うと、Androidの音声認識機能とほぼ同じ結果が得られるようです。 NICTのエンジンについても、pepperくん搭載のエンジンよりはかなりよい結果を得られる感じです。 TODO というわけで、クラウド音声認識サービスで「pepperくんの耳を良くする」方法を紹介しました。 ただ、実用的に使うにはまだいくつかの課題があります。 APIの利用制限 Google Speech APIは非常に良い精度で認識してくれるのですが、利用回数の制限（公式には1日50回まで）が設けられているため、実験用途以外の利用は厳しそうです。ビジネス向けの有償サービスの開始を期待しましょう。 NICTのAPIは、利用回数の制限こそないものの、無償利用は 学術研究目的 に限定されています。有償ライセンスを購入すると、商用利用が可能です。 「話しているところ」の抽出にもう一工夫が必要 今回は、とりあえずの実装として二乗平均平方根によるエネルギー値の計算を使いましたが、人間の声以外の物音も拾ってしまうため、うるさい場所では無駄なAPIコールが多数発生してしまいます。 人間の声だけを抽出するためには、 Voice activity detection なども試した方がよさそうです。 話しおわってから認識結果を得るまでに時間がかかる 今回の実装では、話しおわった箇所を検出し、音声信号のデータを全部作成してからAPIに送っているため、認識結果を得るまでに数秒のタイムラグが発生しています。 話しはじめたことを検出した時点からサーバーに音声信号データを送り始めることで、認識結果を得るまでの時間を短縮できると思います。

こんにちは。Android衛藤です。 2月6日にGoogle Japanで行われた"Google Design Sprint #2"に参加してきました。 ネクストからはデザイナー・エンジニア含めて3名での参加となります。 今回、初めての参加でしたが、非常に面白い内容でしたので、そちらの参加レポートとして紹介したいと思います。 Design Sprintについて Design Sprintの概要 以下、 Google Design Sprint のサイトからの引用です。 The sprint is a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers. Developed at Google Ventures, it’s a “greatest hits” of business strategy, innovation, behavior science, design thinking, and more — packaged into a battle-tested process that any team can use. http://www.gv.com/sprint/ Google VenturesというGoogleのベンチャー向け投資部門で開発されたもので、アイデアの設計からプロトタイプまでの落とし込みを、短期間で仕上げるためのワークショップのことです。 通常、Idea → Build → Launch → Learnと開発サイクルが回っていくところ、Design SprintではIdea → Leanと、ショートカットする事で超短期間でプロトタイプまでの落とし込みが可能になります。 今年、日本に上陸したBlue Bottle CoffeeのWebサイトもDesign Sprintによって生み出されたそうで、詳しくは こちら にありますが、この内容と同じようなことを今回行いました。 Design Sprintの手法とプロセス 対象となるユーザ像(ペルソナ)を一人に決め、そのユーザが求めているサービスについてひたすらアイデア出し→絞り込み、というSprintを繰り返していきます。 プロセスは大きく3つに分かれ、それに沿って作業を行っていくことでプロトタイプを完成させていきます。 Desing Sprintの3つのプロセス 1）理解と定義（Understand/Define）: 対象ユーザー（ペルソナ）を理解し、求められているサービスを考える 、「ユーザー分析」を行います。 2）発散と決定（Diverge/Decide）: ユーザー分析を元にサービスに必要な機能を洗い出し、そのうちユーザーに最も必要とされている機能を選択する「意思決定」を行います。 3）プロトタイプの作成と検証（Prototype/Validate）: ユーザーに見せることができる UI のペーパーモックアップの「作成と検証」を行います。 http://googledevjp.blogspot.jp/2014/11/design-sprint-for-android-wear.html 活動内容 通常は上述の通り5日間で仕上げるようなのですが(2日間というのもある)、今回はさらに短く3時間で全てのサイクルを回し、最終的にペーパーモックまで作成するというものを行いました。 対象のサービスとしては、Android Wearアプリです。 3−40人ほどのエンジニア・デザイナーが各社から集まっていましたが、最初にチームビルディングを行い5人でグループになったところで、実際にワークショップがスタートします。(エンジニア・デザイナー混在) 以下、実際の作業内容となりますが、個人ワーク→グループワークの繰り返しという流れになっています。各自間は個人ワークが5分程度、グループワークが10分程度、最終的なPrototypingが30分など、明確に時間を区切って進めていきます。出来る限り時間の延長は行わず、決められた時間内で終わらせることが大事です。 Understand(理解) / Define(定義) 架空のユーザー(ペルソナ)が記載されたシートが10枚程度配られ、まずはどんなユーザがいるかを理解します。 それぞれのシートには、下記のような情報が記されておりますが、かなりラフな情報しか記載されていません。 User Photo ゴルフをしていたり、キャンプをしていたり様々なシーンで撮影されている Name, Age Story 何の仕事を行っているか 趣味は何なのか Next adventure 次に予定していること。どこに旅をする予定、とか そして、最後がこのようになっています。 Biggest needs (define as a team) : [Name] needs a way to xxxxxxxxxxxxxxxxxx & wants the experience to be xxxxxxxxxxxxxxxxxx because they value xxxxxxxxxxxxxxxxxx. →この部分が一番重要で、そのユーザーが 何を求め 、 どんな体験がしたいか 、 その理由として、どんな価値が見いだせるから という部分をチームで決めます。 まずは、ペルソナを一人に絞り、Biggest needsを考えるところからスタートします。 この考える部分ですが、かなり想像力を働かせる必要があります。というのも、限られた情報しかないため、自分なりにそのペルソナがどんな人なのかを勝手に仮定して人物像を作り出していかないとなかなかアイデアが出てきません。 Diverge(発散) / Decide(決定) ユーザーとそのユーザーが求めているものが決まったら、今度は個人作業でアイデアを出します。出せるだけひたすら、時間内でポスト・イットに書いていきます。(1アイデア、1ポスト・イット) 最初のうちは結構出るのですが、時間が経つにつれペンが止まっていきます。しかし、この部分は「質より量」が大切。どんな些細なことでもよいので思いつく限りを記載するのが鉄則だそうです。 制限時間ギリギリまでアイデアを出した後は、チームでの作業に切り替わります。 出てきたアイデア、一つ一つ吟味しホワイトボードに貼付けていきます。 その時に、下記のように技術的に難しいか、ユーザにとっての価値は高いか、によって貼付ける場所を選んでいきます。 当日の様子↓ 作業が完了した段階で、絞り込みに入ります。 ここでの絞り込みの方法は、投票を行うというもので、1人2案やりたいものに投票を行い、投票結果の上位2案で決選投票。最終的に1つの案に絞り込みます。 Prototype(プロトタイプ) / Validate(検証) 8つのシーンを想像する どの機能を作るかが決定されれば、また個人作業に移ります。 やることは、 8個のシーンを考える ということです。 今回は、A4の白紙を8等分に折り、それぞれの1スペースにユーザーがどんなシーンでその機能を使っているかを書いていきます。 ここでは、文字ではなく実際にイラストで想像したシーンを書きました。 シーンを1つに絞る 個人作業が完了すると、チームでの作業に変わるのですが、ここでも一つに絞り込みます。チームが5人の場合、1人8シーン × 5人分 = 40シーンが作り出されるのですが、その中から、本当に実現したい 1シーンのみ に絞ります。 ペーパーモック：個人作業 シーンが決定すると、次は個人で実際にペーパーモックを作成します。 今回の場合はAndroid Wearが対象なので、Wearの画面に見立てた四角い枠に、どのような画面遷移になるかをこれもイラストで描いていきます。 Android Wearで大事な事は、 必要最低限な情報 シンプルなアクション(0 ～ 1アクションが理想) 自動起動(ユーザーが自ら起動するのではない) 入力インターフェースは音声かタップのみ といったようなことを重視してUIを作成します。 ペーパーモック：チーム作業 個人でのペーパーモックが出そろったら、そうです、 どれか一つの案 に絞ります。 その案に対して、チームで再討論しUIモックを清書して完了となります。 これまでの一連の流れを追っていくと分かりますが、アイデアの選択と集中を繰り返し、最終的に1つに絞っていくということが重要そうです。(ついでだからこの案も・・・というのは基本的にはありません) 1分間プレゼン 最後に、1チーム1分間で出来上がったモックを発表していきます。 通常の5日間のときは、ここで検証が入るようなのですが今回はプレゼンのみ。 数時間の作業でしたが、どのチームも洗練された機能ばかり出ていました。 終わりに 振り返って 3時間という極めて少ない時間の中、内容は非常に濃いものでした。 何かサービスを考える際、長時間終わらないブレストをやって、最初の目的とズレた結論が出る、ということは往々にしてありますが、Design Sprintを使うと短時間で結果が出せるということが、この体験をもって分かりました。 スタートアップ向きのワークショップとはいえ、一般的な企業でも役に立つ手法だと思います。ちなみに、人数はやはり5人(奇数)がいいらしく、それ以上増える場合はチーム分割を行うのがよいとのこと。 今回は数時間なのでペーパーモックまででしたが、5日間のSprintでは、Photoshop等を使って本格的なプロトタイプまで仕上げるようです。機会があれば5日間フルで参加してみたいと感じました。 一緒に参加したエンジニア・デザイナーの気づき 最後に、私と一緒に参加したエンジニアとデザイナーの感想もこちらで紹介させて頂きます。 デザイナーの気づき 【アイデアの出し方】 アイデアソンの手法として、自分の中で「できるできない」のフィルターを掛けるのはNGで、沢山アイデアをだして、そこから実現性を考慮して削ぎとっていったほうが効率的であり、その段階で他人のアイデアとぶつけあったりくっついたりして良いアイデアに昇華、新しいアイデアが生まれるので大事。 【意思共有に向いてる】 「誰のための何のサービスなのか」を常に意識しながら、頭から抜ける前に短時間で考えてアウトプット（ペーパープロト）まで持っていくので意思共有にも有効な手法かもしれない。 エンジニアの気づき 【質より量】 いいものを作るために短時間で様々な意見を出し合い、選びうる選択肢を増やせるだけ増やしていたのが意外だった。もちろんデザインスプリントの趣旨である１つにしぼる。利用イメージ（１シーン）にあうものを選ぶという制約があるからだろうなと思った。 【使い方をイメージさせる】 Wearのような細かいインターフェースで、色々なことをやってもユーザには伝わらない。であれば、あえてそれを押し出さずWearがあるとどういった時に便利になるよといったイメージをユーザに持たせる方が大事。さらに、そこで簡単な操作で色々できるのが理想。 【カテゴリに応じて答えが違う】 アプリのカテゴリに応じて、最適なインターフェース、利用シーンといったものが違うので、これぞ Wear というのはないのではないかと思った。Wearable である意味というのは日常の１シーンにあるといいことがあるよ、といったものなのかもしれない。 【Googleさんも悩んでいる】 Googleの中でもDesign Sprintなどで試行錯誤して開発を行っている。Google Glassなどもこういった中で作られていったようです。

こんにちは。サービス開発U 技術Gの島村と申します。 今回はクリエイターの日の制度を利用して、Raspberry Piを利用したピタゴラスイッチ的装置の開発を行いましたので、その概要を紹介させていただきます。 クリエイターの日の制度に関して気になる方は下記をご覧ください。 http://nextdeveloper.hatenablog.com/entry/2015/01/28/125100 Raspberry Piについて まず、Raspberry Piに関しては改めて説明するまでもなく、すでに様々なドキュメントがWeb上にも存在しますが、ざっくりいうとちっちゃいパソコンでした。 今回はModel B+を購入し、RapbianというDebian系のLinux OSを入れて使いました。 主にsshで接続し、ターミナル経由で開発を行いましたが、Raspberry Pi特有の何かに悩まされることはほとんどありませんでした。 ちょっと配線を間違えただけでショートして壊れてしまうのでは、、と心配もしていたのですが、全くそんなことはありませんでした。 さて、今回そのRaspberry Piを利用して開発したものですが、自部署で運営しているあるキャンペーンのKPI達成状況を、わかりやすくピラゴラスイッチ的装置で表現しようという試みになります。 キャンペーンについて そのキャンペーンに関して、ちょっと宣伝させてください。 今HOME'Sを使ってお部屋探しをすると、楽天スーパーポイントがもらえるキャンペーンを実施中です。 対象の店舗・モデルルームにチェックインするだけでポイントがもらえるので、住まい探し中の方は是非チェックしてみてください。 キャンペーンの詳細はこちら 開発した装置 で、早速今回開発した装置ですが、こちらになります！ ・・・。 まさにデジタルとアナログの融合、といった感じの風貌になりました。割り箸と輪ゴムでピタゴラ作ろうとしたのが正直甘かった。 システムの概要をざっくりと説明します。 まず、今回のキャンペーンKPI達成状況を社内の開発サーバーで定常監視し、それを別のフラグ管理サーバーに通知し、フラグを立てます。 Raspberry Pi側はそのフラグ管理サーバーを監視し、KPIの達成が確認できたら、ピタゴラ装置を作動させます。 今回はRaspberry Piをネットワーク的に開発サーバーとやりとりさせるのが難しかったため、このような冗長な構成をとりました。 それでは、装置が実際に動作する様子をごらんください。 今回は２人のエンジニアで開発に取り組みましたが、KPIの達成状況に対し、１人は音楽の再生、１人はサーボモーターの制御に取り組みました。 あまり格好のいい装置にはなりませんでしたが、一通りのシステムとして組み上げるところまではいけました。 このシステムに関する詳細や開発におけるTips等はまた別のエントリに書きたいと思います。

こんにちは、上津原です。 今度はUnity x Arduinoの話です。 Unityは様々な開発プラットフォームとして活用されますが、なんとArduinoとつながります。 Arduino と言うのは、いわゆるマイコンボードで、いろんなセンサーとかモーターとかを動かすことが出来るやつです。 そしてこれとUnityをつなぐ、「 Uniduino 」というUnityアセットがあります。コレは名前のとおりですがUnityでArduinoを動かすためのものです。 コレを使えば、Oculusのヘッドトラッキング情報を取得して、そのとおりに物を動かすことが出来るのでは！？となりました。 以前にちょっとUniduinoを触っていたこともあり、再びArduino熱が上がってきて、弊社のクリエイターの日を利用してそれを作ってみることにしました。 どうやってヘッド情報を取得するか？ コレはとても簡単でした。 OculusのOVRCameraRigのCenterEyeAnchorのRotationから取得することが出来ました。 さて、これらのデータをどのようにしてArduinoに伝えるか？というところでUniduinoの出番です。 Uniduinoの動かし方は、 こちらから見てもらえればOKです。 これのSERVOモードを利用すれば、角度情報をサーボモーターに与えてモーターを動かすことが出来ます！ サーボモーターとUnityの角度の回転が逆！ 結構さくっと動くので、順調だなーと思ってた矢先に問題が。Oculusで右を向くとサーボモーターは左を向く。 上を向くと下を向く、といったかんじであまのじゃくな動きに。 角度を調べてみるとこんな感じになっていました。 ０の起点がそもそも違うし、角度の増加方向も逆向き。 悲しい。 ということでコレの角度の補正ロジックを書くことにしました。 法則性を見つけて一つの公式を導き出して〜という方がかっこいいですが、面倒臭かったので360度を4つに区切って、それぞれの角度領域で角度補正をすることにしました。 // jouge // Seigen Kakudo int jougeSeigen = 35; if (270 < jouge && jouge <= 360) { // left servoJouge = 180 - (jouge - 270); } else if(0 <= jouge && jouge <= 90) { // right //// Kakudo Seigen//// if(jouge > jougeSeigen){ jouge = jougeSeigen; } ////////////////////// servoJouge = 90 - jouge; } else if (91 <= jouge && jouge <= 180) { // right over servoJouge = 0; } else { // left over servoJouge = 180; } うわー地味。 でも動くんだから気にしない。 サーボモータは180度のものを利用しているので、0度、180度を超えたものは0，180度以上に行かないようにしています。 コレを書いておかないとサーボモータが逆方向に動き始めて大変なことになります。 とりあえずコレを使うことでサーボの向きとOculusの向きを一緒にすることが出来るようになりました。 サーボを360度のものを使ったらさらなる罠が待っていた 首を左右に動かすのは360度のサーボのほうがいいのでは？という話題が出てきて、そうしてみた。 なんの考えもなしに180の値を渡すとなんと 2回転もするじゃないですか。 おいまて、誰が2回も回れといった。 360度角だから、Unityの値をまんま渡してやれば余裕っしょとか思ってた自分が馬鹿だった。 コレも動かしながら確かめてみると、どうやらサーボに90の値を渡すと1週するようになっているようだった。 それでいて0の起点ももちろん違う。また絵に書くとこんな感じ。 というわけで、Oculusの向きをサーボのものに変換してかつ、4で割ることで360度角を90度角にして利用することにした。 // sayuu // Sayuu Seigen int sayuuSeigen = 3; // Front left if (270 < sayuu && sayuu < 360) { // left servoSayuu = 270 - (sayuu - 270); } // Front right else if(0 <= sayuu && sayuu <= 90) { // right servoSayuu = 180 - sayuu; } // Back right else if (90 < sayuu && sayuu <= 180) { // right over servoSayuu = 90 - (sayuu - 90); // Seigen if(servoSayuu < 10){ servoSayuu = 10; } } else { // left over servoSayuu = 360 - (sayuu - 180); // Seigen if (servoSayuu > 350){ servoSayuu = 350; } } int Servo360Sayuu = (int)servoSayuu; Servo360Sayuu = (Servo360Sayuu / 4); とりあえずコレで360度回るようになった。 そしてなんやかんや接着して動かしてみたのがこちら OculusとArduinoをUniduinoで連携させてみた。 - YouTube キャタピラがついてますがそれはまた別の話で。 とりあえずはOculusとサーボを連携させることに成功しました！ 最終的にはサーボの先端にカメラを付けて、遠隔の位置に視点を持っていく、と言うものにしてみました。 電子工作楽しい ソフトウェアばっかりやってましたが、こんなふうに動くものを作れるっていうのはコレまた楽しいものです。 コレをきっかけに作って見たいものが出来たので、またなにか作ってみようと思います。

こんにちは、上津原です。 缶コーヒーのテレビCMでもPepperくんを見るようになって、なんだかPepperくん変なタレントみたいな立ち位置になってきてますね。 というわけでまたPepperの話題です。 遠隔で色々喋らせたい Pepperの開発をやっていると、インストールしておいたものしか動かせないのにやきもきしてきます。 なので、PepperとMacをつないで、こっちからテキストをを送ればそれを喋るようにしてみました。 pythonで書きます。 基本は普通のソケット通信のコードと同じです。サーバーサイドとクライアントサイドのスクリプトを書きます。 今回はMacをサーバーとして、Pepperをクライアントとして作りました。 サーバーサイド import os import sys import socket HOST = '' PORT = 50008 def main (): s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1 ) s.bind((HOST, PORT)) print 'waiting for client...' s.listen( 1 ) (conn, addr) = s.accept() print 'Connected by' , addr pid = os.fork() if pid == 0 : print "child process" while 1 : msg = raw_input ( ">> " ) conn.send( '%s' % msg ) if msg == "quit" : break ; sys.exit() else : print "parent process" while 1 : data = conn.recv( 1024 ) if not data: print 'End' break elif data == "" : print "Client is closed" os.kill(pid, 9 ) break print "pepper: " , data conn.close() sys.exit() if __name__ == '__main__' : main() クライアントサイド（Pepper） import os import sys from socket import * HOST = '192.168.XXX.XXX' #ここは設定に合わせて PORT = 50008 class MyClass (GeneratedClass): def __init__ (self): GeneratedClass.__init__(self) def onLoad (self): #put initialization code here pass def onUnload (self): #put clean-up code here pass def onInput_onStart (self): # ソケット接続 try : #接続処理 self.s = socket(AF_INET, SOCK_STREAM) self.s.connect((HOST, PORT)) except : #接続失敗したらソケットを閉じて終了へ self.s.close() self.onStopped() return # 子プロセスの作成 try : pid = os.fork() except : return # つながったらテキストの送受信を行う self.log( "pid :" + str (pid)) # 子プロセスの場合の処理 if pid == 0 : # 一旦未使用 pass # 親プロセスの場合 else : while 1 : self.log( "pid else" ) data = self.s.recv( 1024 ) if not data: break elif data == "quit" : os.kill(pid, 9 ) break self.log(data) # Stopの何かがないか確認 stop = self.stopVerification(data) if stop == False : self.outputStringFromServer(data) self.s.close() self.onStopped() pass def onInput_inputString (self, p): # PCからインプットされたテキストをmsgに入れて、喋らせる self.log( "Recieve String " + p) # Stopの何かがないか確認 stop = self.stopVerification(p) # Stopではなかったらメッセージをサーバに送る if stop == False : self.s.send(p) def onInput_onStop (self): self.onUnload() #it is recommended to reuse the clean-up as the box is stopped self.onStopped() #activate the output of the box def stopVerification (self,inputString): if inputString == "ストップ" : self.log( "stop!!" ) self.outputStopBehavior() return True else : return False 補足説明 outputStringFromServer()部分がサーバーから受け付けたテキストをノードからアウトプットするものになってます。 ここから先にAnimatedSayなどをつなげればそのとおりに喋ってくれます。 stopVerification()というのも作っていますが、これは「ストップ」という単語が届いたらアプリケーションを停止する挙動なども取り入れています。特定のテキストを送ればこの挙動をする、とかそういった物を簡単に設定することが出来るようになります。 forkを使って、好き勝手やりとりできるように作っているので、pepperのSpeechRecoを使って特定の言葉をサーバ側に送ったりもできます。onInput_inputString()はSpeechRecoから受け付けた単語を得てうごかしてます。 とりあえずコレを使えば、人力でPepperくんと人の会話ができるようになります！ 人力でやってどーする！と思うかもしれませんが、人力でもそれはそれで楽しいのでやってみてください。

こんにちは。iOS開発Gの石田です。 最近家電を操作して、自分の部屋をスマートハウス化しようといろいろやっているのですが、そこで考えたことをまとめてみました。 我が家の現状 我が家で最も活躍しているのは、ネットワーク対応学習型リモコンのIRKitです。家電が規格に対応していなくても赤外線リモコンさえあれば操作できるので、自作アプリに組み込んで赤外線対応家電を操作しています。 以前の記事 で紹介したとおり、Siriで音声認識を実現しています。 最近は、「帰ったよ」というアプリを作り、起動するとテレビ、エアコン、照明、BDプレイヤーが起動して、セットしておいたお気に入りのBDが流れるようにしています。 【ネクスト】iPhoneの「Siri」で家電を操作 - YouTube またスマホなどから操作できる電球であるPhilipsのHueや、室内・室外環境を計測するウェザーステーションのNetatmoを、カスタム条件トリガーを作れるIFTTTで制御し、湿度が低くなったりCO2濃度が高くなったときに部屋の色を変えたり、自宅から半径500mを出入りするたびに 照明が付いたり消えたりするようにしています。 こちらが簡単に自宅の制御系を表したものです。 IFTTTとは、If This Then Thatの略で、これをしたらあれをする、というWebサービスの組み合わせを自分で作ることができるサービスです。 最近はWebサービス感覚で使用できる家電が出されてきており、IFTTTに対応している家電であれば、トリガーと動作を設定するだけで制御できてしまうので非常に便利です。 トリガーとしても用いることができるものとしては、電話がかかってくる、メールが来る、Facebookの通知、GPSで指定の領域に入る、などがあります。 課題 しかしながら、IFTTTを用いて制御していると不満なことがでてきます。それはトリガーの条件が１つしか登録できないことです。 例えば、「IF 指定さえた領域に入る　Then 照明をつける」、という命令を設定しているのですが、時間の指定ができないので昼間でも電気がついてしまいます。 時間の範囲指定ができればよいのですが、シンプル故に使いやすいIFTTTでは設定することができません。 本来私が設定したい命令は、 『 暗い時間に家に帰ったら 』 であり、よりセンサ等が分かるようにより具体的に書くと 『 「現時刻」が「本日の日の入りの時刻」を過ぎているかつ、「スマートフォンの位置情報」が自宅の半径500mよりも外の位置から中の位置に変化した 』 となります。 このように、より快適に家電を制御するためには、複数の一次情報を組み合わせて、人の行動に合致した二次情報を作り、トリガーとする必要があります。 二次情報への加工 たとえば、「家に帰る20分前にエアコンをつける」ことを考えます。頭の中では「帰る」と思うだけですが、コンピュータはそれが分からないので工夫する必要があります。 仕事では基本的に外出がなく、いつも同じ駅から通勤・帰宅する私にとっては、「夜に品川駅に着く」ことが「家に帰る20分前」とほぼ同義です。よって 『　「現時刻」が19時から24時かつ、「スマートフォンの位置情報」が品川駅の半径200mよりも外の位置から中の位置に変化した　』 というトリガーを設定すればよいわけです。※1 しかしこのトリガーは私専用であり、同じ勤務地、最寄駅でも営業職の人では当てはまりません。同じ品川勤務でも営業の人は外出することが多く、直帰することもあるでしょう。そうすると、品川駅を通らずに自宅に帰る可能性もあり、私と同じ条件を設定したところでこのトリガーが引かれず、エアコンのついていない寒い部屋に帰る羽目になります。 このように同じ「家に帰る20分前」でも、人によってトリガーの条件が異なります。故に自分の行動パターンを把握したうえで各自トリガー設定する必要があります。 しかしこのような複雑なトリガーの設定を世間一般の人が皆やりたいわけではありません。（私は楽しいですが） 初めに複雑な設定が必要であるならば、スマートハウスはなかなか普及しないでしょう。 ユーザーが何もしなくても、気の利いた制御をしてくれるためには、ユーザーの行動を学習して適切なトリガーを自動で設定してくれることが必要になってきます。 これに近いことを既にやっているのが、GoogleNowです。 GoogleNowのレコメンド機能 GoogleNowは、膨大な個人情報を提供する代わりに、適切なタイミングでユーザーが興味のある情報を「カード」という形で提供してくれるアプリです。※2 行動を分析して、Android端末およびAndroid Wearにカードとして情報を表示するものなのですが、Googleは少し前からスマートハウスにも応用を始めました。 昨年人工知能が付いたサーモスタットであるNestを作っている企業を買収し、NestをGoogleNowと連携させるサービスが始まっています。 Google NowとNestの連係で音声命令や“帰宅時間を予測して室温設定”が可能に Nestは、家の温度をまとめて調整してくれる装置の一種で、もともと人工知能が入っており、帰宅時間を予測して勝手に室温を適切に保ってくれるようです。これ自体でスマートハウスのハブとしての役割を担う可能性があるのですが、GogoleNowと連携することによって、位置情報によるより正確な帰宅時間の予測と、「OK,Google」による音声認識による操作が可能になったようです。 グーグルが買収したNestって何がすごいの？ そもそもサーモスタットって？ : ギズモード・ジャパン GoogleNowとスマートハウスの連携はとても強力で、他の規格から一歩抜き出ていると思います。 そのうちAppleのHomeKitのようなスマートハウス規格を発表して、家電メーカーがそれを組み込み、スマホがスマートハウスのハブを担うことになるでしょう。 使っているスマホがiPhoneかAndroidかによって、家を決める時代が来るかもしれません。 最後に 個人が趣味でスマートハウス化している段階から、一般人が普及するスマートハウスを便利に利用する段階の間にあるのは、難しい設定や操作無しで快適な動作ができる人工知能ができるかどうかだと思います。 ですがスマートハウスの現状はまだ規格が出始めた段階で、家電自体がスマートハウスの規格に対応しないうちはまだまだ普及の段階ではありません。さらにスマート家電と呼ばれるものは最上位機種の付加機能として導入されると思われるので、価格が高いうちはなかなか普及しないでしょう。 よってしばらくは、自分の家の家電を自由に操作し、自分の行動パターンから適切なトリガーを設定して、一足先にスマートライフ生活を楽しんでいこうと思います。 自分が設定したとおりに家電が動くのはとても楽しいことです。 ※1 正確には、私が仕事終わりでどこか別のところに遊びにいこうとするときは、必ず品川駅を使う必要があるので、この条件だと「家に帰る」のか「遊びに行く」のか分かりません。確実に「家に帰る」方向に行ったと判断するためには、品川駅から出て通勤路線上の次の駅の範囲に入るという条件を足す必要があります。さらに家に帰る方向に行ったとしても、最寄駅を過ぎて別のところに行く可能性もあります。すると最寄駅を過ぎて次の駅に行った時点で「家に帰らない」という判断をして命令を取り消す必要があります。自分の行動パターンを元にプログラミングをしているようですね。 ※2 私は１年ほど前からNexus5でGoogleNowを使用し続けているのですが、既存のECサイト等にあるようなレコメンドの質とは大きく異なり、かなり私個人にあった情報をおススメしてきてくれます。 例としては、最寄駅についたら通勤に使える電車の時刻を教えてくれる、PCでGoogleMapを使っていきたい場所を調べると、行き方がカードで表示されている、普段行かないところに遊びに行くと周囲の情報を教えてくれる、興味のある分野の記事のおススメ、よくチェックしているページが更新されたら通知してくれる、1か月で歩いた距離を教えてくれるなどがあります。噂によると、設定しなくても1週間GoogleNowを使うだけで勤務地が設定されるらしいです。 それもそのはず、GoogleNowには、検索履歴、メールの中身、位置情報、GoogleMapの使用履歴など、かなり濃い個人情報を提供しています。これらをもとにビッグデータ分析や学習アルゴリズムを駆使して、私たちの興味のある情報を分析しています。

Apple原理主義者ですが、今日書く内容にその事実は関係ない大坪です。 「新しいアイディアを出そう！」（意訳） というときにブレーンストーミング-略称ブレストってよくやりますよね。真面目な誰かが「質より量」とか「他人の意見を批判しない」とか「ブレストの原則」を述べ出すと「そんなのもう聞いたよ」感が会議室に満ち溢れるくらい世の中に普及しているわけです。 個人的にこの「ブレスト」というのはよほど注意しないと有意義な結果を残せないといつも注意しています。私はバラエティ番組にでている能年某嬢くらい考えるテンポが遅いので、元気良い人が多いブレストでは発言できない。いや、それはお前がそもそも新しいアイディアを持っていないからだろう、という真っ当な指摘は無視してじゃあブレストで「すごいアイディア」がでてきたことがあるかというとあまりそういう記憶もない。 自分では「なぜそう考えるのか」説明できなかったのですが、最近見つけた記事がその理由になるかもしれない、と考え始めました。そもそもの問題意識から Meetings want to suck. Two of their favorite suckiness tactics are group brainstorming and group negotiation. 引用元： Note and vote: how to avoid groupthink in meetings | Google Ventures いいかげんな訳：会議は退屈さを欲している。会議が大好きな「退屈にする方法」はグループでのブレストとブループでの交渉だ なるほど。では彼らはどのような方法を提案しているのか？前述のページから少しはしょって引用すると (以下引用＆要約しつつ和訳) 1.Note ５分か１０分で個々人がアイディアを書き出す。その後２分かけて１個か２個の「これがいい」というアイディアを選ぶ。 2.Share and Capture 順番に自分がよいと思ったアイディアを発表する。「売り込み」はなし。それをホワイトボードに書き出す。 3.Vote ５分で、書き出されたアイディアのうちどれがよいと思うが決め、ノートに書く。そのあと順番に自分がよいと思ったものを発表する。（ノートに書いた内容を変えてはダメ）ホワイトボード上にどのアイディアが何票得たかを書いていく。 4.Decide 責任者がどのアイディアでいくか決定する。その際投票結果を尊重しても、尊重しなくてもよい。仮に投票結果と違う結果になっても「すべての人間の意見をちゃんと聞いた」ことになる。 以下この方法がうまく行く理由について述べられています。 個人に静かに考える時間が与えられる すべての人が並行して考えているので、「一度に一人しか発言できない」通常のブレストに比べて時間の効率がよい 投票する際に、他人の意見を聞く前に自分の意見を書き出している。つまり「他の人の意見に安易に同調する」ことがない。 最後の項目は「集合知がうまく働くための条件」とも合致している。すなわち集団での決断が「衆愚」に陥らないためには、他人に影響されない独立性を持っていないければならない、といわれています。ここで自分の判断を頭の中にだけ止めておくと 「Bがいいと思ってたけど、あの人がAと言ったからA」 的な判断に堕してしまう。あらかじめ自分の判断を書いておくことでそうした事態が防げるわけです。 また4.Decideを読んで「マキャベリ語録」のある一節を思い出しました。 あなたは、すべての事柄について質問しなければならない。そうしておいて彼らの自由率直な意見を求めるのだ。そしてそのあとで、あなた自身の判断で決定を下す マキアヴェッリ語録 P98　塩野七生著　新潮文庫　 グループの各員は自由に自分の意見を表明できなくてはならない。責任者は自らの責任において決断を下さなくてはならない。一見両立が難しいように思えるこの二つの命題は実はそれほど離れていないのかもしれません。 さて このNote & Voteが提起しているもう一つの問いは 「優れたアイディアは一人の頭での深い思考からしか生まれないのではないか」 という点。こちらのページ The Design Sprint — Google Ventures The Design Sprint — Google Ventures では、彼らが実行している一週間のデザインスプリントについて述べられています。このプロセスでは、火曜日（つまり二日目）がSKETCHに当てられており、 During Sketch day, your team will work individually to draw detailed solutions on paper. As you sketch, everyone works separately to ensure maximum detail and depth with minimum groupthink. 引用元： The Design Sprint — Google Ventures 訳：Sketchの日に、チームメンバーは個々に詳細な解決案を紙に書く。個人ごとに作業するのは、グループでの思考を最小限にし、かつ（アイディアの）詳しさと深さを最大にするためだ。 ここで提案されている方法も伝統的なブレストとは異なったものです。 ここでもう一つ引用します。先日紫綬褒章を受賞した佐藤雅彦氏のインタビューで、私の世代だと佐藤氏はすごいCMを作る人、というイメージなのですが最近では「ピタゴラスイッチ生みの親」と認識されているかもしれません。 でもジャンプっていうのは非常に難しくて、どこで見つけるかっていう質問だったんですけど、それはすごく難しくて、いろんなところに隠れているんですよ。 僕は「うまく待つ」って言っているんですけど、そういうものを見出す自分でいるように、うまく待っている。見過ごさないように。当たり前だと思っていることが実は当たり前じゃない、ということがとってもあるんですよね。 それと、これは鍛錬なのかもしれないですけど、いろんな場合の数、無数の場合の数を頭の中でやる訓練というか。全部「この場合、この場合、この場合……」全部「つまんない、つまんない、つまんない……」って頭の中でガシガシやっているうちに、セレンディピティというんですかね、たまたま何かのものが見えたりしたときに、それがガーンと来るジャンプの映像だったりしますね。 だからやっぱり「うまく待つ」ということと、「ものすごく追求する」ということだと思いますね。 引用元： 新しいものは"つくり方"から生まれる--「ピタゴラスイッチ」生みの親・佐藤雅彦氏インタビュー | ログミー[o_O] ここで佐藤氏が強調している「うまく待つ」と「ものすごく追求する」は「質より量」といったブレーンストーミングの原則とは相反している。会議室で決められた時間内にアイディアを出し合うのではなく、個人の頭の中で膨大な組み合わせ、評価サイクルを回すことを会議中でなくても延々と続ける。そうしていると思わぬときにアイディアがやってくる。会社から帰ろうと電車に乗ろうとした瞬間「おわっ」とアイディアが閃いた経験を持つのは私だけではないと信じたい。 あるいは私は「新しいアイディアといってもいろいろ程度がある」事実を無視した意見を書いているのかもしれません。仮にそうだとしても 「アイディア出し会議をしよう！さあ、ブレストだ」 と直結してしまうのは見直すべきではないかと最近考え始めています。

こんにちは、上津原です。 最近はpepperを触っています。少しずつpepperのアプリケーションを開発するにあたって気づいた点などを紹介していこうと思います。 pepperとは？ pepperは、ソフトバンクロボティクスから出ているロボットです。TVCMなどで見たことがある人も多いと思います。 pepperはChoregraphという統合環境を使ってアプリケーションの開発ができます。Choregraph内ではpythonを使ってより詳細なロジックの作成ができます。 pepperにおけるDialogとは？ Dialogと言うのは、pepperとの会話のやりとりを作成する部分です。 「こんにちは」と声をかけられたらpepperは何と返すか？などを記述するものです。 詳しいやり方は こちらのページ を見てもらうとわかりやすいと思います。 注意するべき点って？ コレは自分がハマったことなのですが Dialogが一番下まで完了すれば勝手に次の処理に進むと思っていたが、そうではないということ。 例えば、「はい」「いいえ」でそれぞれ違う回答をさせたい場合は u:(はい) そうですよね〜 u:(いいえ) まじですか というふうに書くわけですが、コレでは この受け答えをループしてしまうだけ になってしまいます。 これらを次のアクションへ繋げたい場合は、後ろにoutputの名前を記述し、1を代入します。 (ex:onStoppedを動かしたい場合） u:(はい) そうですよね〜 $onStopped=1 u:(いいえ) まじですか $onStopped=1 こうすることで、次の処理へつなぐことが出来ます。 任意でoutputを作成した場合は、同じようにその名前を書いてやればOKです。 ここでもう一つ注意なのですが、onStoppedを使わなかった場合、Dialogの聞き取りモードが継続して動き続けてしまう状態に陥ります。 そうなると、他の処理中に音声を拾ってしまい動作がおかしくなってしまうので、そういった場合は聞き取り後にonStopにもラインをつなげておくと安心です。 こんなかんじ pepperは意外と自分でいろんなことをしてくれない。 ロボットなんだから結構気が利いて、色々といい感じにやってくれるんだろうな〜とか最初思ってたんですが、全くそんなことはなく、きっちりこっちがロジックを書いてあげないと訳の分からない動きをしたりします。 ロボットだということで妙な期待を寄せていると、ロジック周りでいろんな落とし穴があるので色々と気をつけていきたいですね。

こんにちは。クリエイターの日運営委員の松尾です。第3四半期に実施してから年も明けてしまいましたが、今回も『 クリエイターの日 』について紹介します。 クリエイターの日制度 改めておさらいすると、ネクストでは「既存サービス・技術の枠組みを飛び越えた自由な発想からイノベーションの創造」と「各メンバーの興味あるサービス・技術へのチャレンジを通しての個人の成長とネクストの創出力向上」を目的として、四半期の最大7日間を研究・開発にあてることができます。 毎四半期の最後には各チームの成果報告会を行いますが、今回は趣向を変えて「デモセッション with ビアバッシュ」というかたちで実施しました。 デモセッションの風景 デモセッションでは、決められた時間の中で各チームが同時にシステムのデモンストレーションを行います。今回はクリエイターの日に活動した5チームと、有志として参加した1チームの計6チームが参加しました。 特に注目度が高かったのは、AndroidWearのデモを行っていたチーム。実装方法やデザインのこだわりなど、多くの質問が飛び交っていました。 HOMES(ホームズ)-住まい探し-賃貸・不動産賃貸検索 - Google Play の Android アプリ 参考： スマートウォッチで内覧時のチェックポイントを確認 こちらはSwiftで実装したアプリで社内システムの改善を目指すチーム。クリエイターの日を利用して勉強、実装をしたそうです。 参考： 手元のスマホで来客の受付ができるアプリ ソフトだけではなく、ハードを扱うチームもいます。こちらでは脳波を入力として、PCなどの操作をしてました。 こちらはSiriとIRKitを利用して家電の遠隔操作を実現したもの。しゃべるだけで家電が操作できます。 発表者だけではなく、聴講者としても多くの社員が参加しました。職種を問わず、最新技術に興味を示す社員が多数です。 ビアバッシュも兼ねているので、飲食物も準備。 今回は以前までの報告会とは違い、発表者と聴講者が話しやすい雰囲気を作ることに注力しました。発表と質疑応答のような形式に比べて、建設的な議論が盛り上がっていたようです。 結果発表 聴講者による投票で決定した優勝チームは「泡（Android Wear Appの頭文字らしい）」チーム。 本家Android Appのウェアラブルデバイス対応を業界初を目指して提案、実装したアプリです。まだまだこれからのデバイスですので、今後の発展も期待されます。 また、弊社役員からの特別賞には、有志として参加した新卒1年目の社員を選出。 IoTをテーマに出展していた彼には、その感性をさらに磨くべく、新しいガジェットが贈られたようです。 今後もネクストのものづくりを活性化し、発信して参ります。次回の記事にもご期待ください。

池田です。 今回は、iPhoneアプリの視覚障がい者向けユーザビリティ、アプリを使いやすくする3つのポイントについて書きたいと思います。 ユーザビリティのお話をする前に、視覚障がい者がどうやってiPhoneを使われているか、について少し触れます。 視覚障がい者の多くは、iOS付属のスクリーンリーダー「VoiceOver」を活用し、iPhoneの利用をされています。 初めて「スクリーンリーダー」という言葉を耳にした方もおられるかもしれませんので、少し解説しますと、スクリーンリーダーは、画面上の内容を、音声にして読み上げてくれるソフトウェアです。 画面上の項目にカーソルが当たり、そのカーソルが当たっている項目の内容を音声で読み上げてくれます。 カーソルが当たってるのがテキストなら、そのテキストの内容を。 リンクなら、リンクの文言と、それが「リンク」であるという情報を読み上げます。 視覚障がい者の多くはこのスクリーンリーダー、iPhoneではVoiceOverを活用して、音声で画面の情報を把握し、使われています。 それでは、VoiceOver利用時のユーザビリティ、アプリが使いやすくなる大切なポイントについて、書いていきたいと思います。 「HOME'Sアクセシビリティ対応版」で気をつけている大切なポイントは、大きく分けて3つです。 VoiceOverに合わせた操作性の考慮 画面操作時の迷いをできるだけ軽減する 必要な情報を漏れなく音声で伝える この3つについて、解説していきます。 VoiceOverに合わせた操作性の考慮 VoiceOverが有効の環境下では、無効の場合と大きく操作が異なってきます。 VoiceOver有効時には基本的な操作として、カーソルの移動と、項目の選択があります。 カーソルの移動は、画面上を上下左右にスワイプする、または、画面上の項目をタッチすることで行います。 項目の選択は、画面上をダブルタップすることで行います。 この操作性を考慮し、画面上の項目の配置、項目の読み上げ設定などをすることが大切です。 「HOME'Sアクセシビリティ対応版」の画面画像を示しながら、ご説明していきたいと思います。 VoiceOver利用環境下では、画像上の番号で示すように、まず画面の左上の要素が選択、そこから左から右、右端まで行ったら一つ下の行の左端の要素が選択。 のような動きで、カーソルを移動していきます。 つまり、左上から順々に一つ一つの要素の内容を音声で聞き、理解しながら画面操作を進めていきます。 こういった操作を考慮し、この画面では、画面の機能として配置されている「検索トップに戻る」ボタンの配置を画面上部にしています。 なぜ上部かと言いますと、画面上部にボタンを配置することで、画面の内容に入る前にボタンにカーソルが合うため、画面内にどんな機能があるか、事前に把握することができるためです。 また、画面上部にある方が、VoiceOver環境下の特殊な操作(二本指で上にスワイプすると最初の項目にフォーカスが合う)を用いることでアクセスしやすくなるという利点もあります。 画面操作時の迷いをできるだけ軽減する VoiceOver利用時の操作は、画面上を触ることにより触った位置にある項目が選択されることもあり、画面上の操作をしている際、ちょっと触れた位置にカーソルが行ってしまうなど、意図しない動作が起こる場合があります。 意図しない動作が起こると、画面上の理解に迷いが生じます。 そこで、迷いが生じないように、また、生じた場合の迷いの軽減をすることが大切です。 こちらの画面では、画面右上に画面の使い方を調べるボタンを設置しています。 こういったボタンを設置することで、今何をする画面にいるんだ？どんな操作をすればいいんだ？ といった迷いが生じた際、ここを見ることで少しでも迷いを軽減できるようになります。 必要な情報を漏れなく音声で伝える VoiceOver利用時には、画面上の音声読み上げが重要となってきます。 まずは画面上の各要素をテキスト情報で伝える必要がありますが、それだけではなく、「画面上の状態」を伝えることも大切です。 この画面は、データを取得中の読み込み画面です。 開かれたタイミングで読み込みが行われ、その後、読み込みが完了すると内容が表示されます。 画面の状態の変化は、ユーザの操作によって行われる訳ではなく、自動で行われます。 こうした自動的な画面の変化を音声で伝えていくことも大切です。 「HOME'Sアクセシビリティ対応版」では読み込みが開始したタイミング、読み込みが完了したタイミングで、音声で「読み込み中」「読み込み完了」と状況を伝えるようにしています。 このように、VoiceOverの操作性、ユーザの迷いの軽減、適切な音声フィードバックを行っていくとアプリは視覚障がいを持たれた方にとってとても使いやすいものとなります。 VoiceOverは視覚障がい者をサポートする素晴らしい機能ですし、VoiceOver利用を考慮したアプリが増えていくことで、視覚障がいを持たれた方の生活もどんどん便利になっていくと思います。 今回は、VoiceOverの詳細、実際の開発など、詳しい部分をお伝えできていませんが、今後より詳しい部分についてもお伝えしていこうと思います。