はろーはろー！チバと申します。 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の詳細、実際の開発など、詳しい部分をお伝えできていませんが、今後より詳しい部分についてもお伝えしていこうと思います。

こんにちは、上津原です。 先日Pepperの購入者、または購入予定者が参加できるというPepper Pioneer Club Meetupに参加してきました。 会場は、FreakOutさんのイベントスペースでした。 私はエンジニアというところで、エンジニア目線での今回のイベントで感じたことをお伝えしたいと思います。 乾杯は主役のPepperが まず最初に、恒例らしい（？）Pepperによる乾杯の音頭で始まりました。ちなみに前回はPepperによる乾杯は失敗したとのことで、今回はうまくいき、乾杯の後に拍手がわきあがりました。乾杯ができただけで拍手を受けられるPepper。しかし妙に新鮮でした。 展示されていたPepperや話を聞いて感じた事 Pepperの基本としてはもちろん「会話」が中心になります。なので、会話をしながら記念撮影をしたり、ラジコンのように操縦するスマホアプリが展示されていたり、関西弁でしゃべるPepperなどがありました。 全体を眺めながら感じた点は、まだ柔軟な会話に対応できるPepperアプリケーションを作るノウハウはそりゃあるわけないよねー、という感じでした。「はい」「いいえ」を基本にした会話だったり、数字を選ばせたり、胸元のタブレットで操作したりというかんじで。 いわゆるソフトバンクの発表会で見たようなスムーズな会話を成り立たせるというよりは、Pepper側から選択肢を人間に用意をしてあげて、思った通りのフローを踏ませるといったものが基本だし、ロジックを作る以上はそうなってしまうのはしょうがないのかなと感じます。 CMなどのおかげで、Pepper君は話しかければ大体なんか返事してくれると思っている人が大多数なので、結構その辺で開発者とユーザの間でギャップが起きたりするのでその辺をどう埋めるかというのも課題になりそうです。 まあ、Pepperくんはかわいいので、できなくても大概許してもらえちゃうんですけどね笑 次は開発者イベントがあるといいなあ 今回は「こんな風に使ってます」「作ってみました」というものが多かったので、次開催あたりではもっと開発側に突っ込んだものなどの話があるとうれしいですね。 ロボットを喋らせて、人と会話をするというのは今までソフトウェア開発をしてきてやることはなかった身としては、どうしても普通のソフトウェアに考えが偏りがちで「どうやったら話したくなるか？」「スムーズに会話が進むか？」「違和感のない生きてる感を出せるか？」などいろんなところでつまづく場面があるので、その辺をみんなで共有しあえればもっといいPepper開発につながるんじゃないかなーと思います。 しかし、MeetUpはご飯もおいしく、会場も広く非常に楽しめました。 今後の展開が楽しみです。

こんにちはAndroid開発グループ橋本です。 今回はAndroidStudioで使うlintについて調査する機会があったので内容を記事にします。(lint自体の解説は省略します。) まずは実行をしてみる。 Androidのlintの実行について調べてみると、Android/sdk/tools/の下にあるlintが使用できるようです。 参考： http://developer.android.com/intl/ja/tools/help/lint.html この方法だといちからlintのオプション設定を行わなければいけないため、とても手軽に使えるとは言い難いものです。ではどうしたらいいのか？そもそも開発はAndroid Studioを使う事を前提としていたのでそちらで実行したいところです。 Android Studioから実行 AndroidStudioから実行する場合、実はとても簡単で、メニューからAnalyze→Inspection Scopeで実行できました。 gradleをコマンドラインから実行 Android Studioで作成したprojectフォルダの下にあるgradlewを使用して、以下のコマンドでlintを実行できます。 ./gradlew (モジュール名):lint こちらの方法で実行した場合デフォルトではhtmlとxmlで出力され、実行後に成功していれば出力パスが表示されます。 lintの設定をする。 設定と実行方法はAndroid StudioのGUIに任せるか、手動で行うかのパターンがありますが。GUI上からの設定方法は他文献でいくつかあるようなので、ここでは手動設定の方法を記述します。 build.gradleの設定 作成したprojectファイルにあるbuild.gradleにlintOptionsを追記し必要な項目のオプションを必要に応じて追加する形です。 以下公式から抜粋。 android { lintOptions { // set to true to turn off analysis progress reporting by lint quiet true // if true, stop the gradle build if errors are found abortOnError false // if true, only report errors ignoreWarnings true // if true, emit full/absolute paths to files with errors (true by default) //absolutePaths true // if true, check all issues, including those that are off by default checkAllWarnings true // if true, treat all warnings as errors warningsAsErrors true // turn off checking the given issue id's disable 'TypographyFractions','TypographyQuotes' // turn on the given issue id's enable 'RtlHardcoded','RtlCompat', 'RtlEnabled' // check *only* the given issue id's check 'NewApi', 'InlinedApi' // if true, don't include source code lines in the error output noLines true // if true, show all locations for an error, do not truncate lists, etc. showAll true // Fallback lint configuration (default severities, etc.) lintConfig file("default-lint.xml") // if true, generate a text report of issues (false by default) textReport true // location to write the output; can be a file or 'stdout' textOutput 'stdout' // if true, generate an XML report for use by for example Jenkins xmlReport false // file to write report to (if not specified, defaults to lint-results.xml) xmlOutput file("lint-report.xml") // if true, generate an HTML report (with issue explanations, sourcecode, etc) htmlReport true // optional path to report (default will be lint-results.html in the builddir) htmlOutput file("lint-report.html") // set to true to have all release builds run lint on issues with severity=fatal // and abort the build (controlled by abortOnError above) if fatal issues are found checkReleaseBuilds true // Set the severity of the given issues to fatal (which means they will be // checked during release builds (even if the lint target is not included) fatal 'NewApi', 'InlineApi' // Set the severity of the given issues to error error 'Wakelock', 'TextViewEdits' // Set the severity of the given issues to warning warning 'ResourceAsColor' // Set the severity of the given issues to ignore (same as disabling the check) ignore 'TypographyQuotes' } } 一部よく使うであろうオプションについて解説します。 abortOnError falseを設定することで、build中にlintのエラーが出てもbuild自体に影響を及ぼさない(途中で停止しない)設定に出来ます。コンパイルが通るはずのソースコードをbuild中に止められてしまう可能性があるのでfalseにする事が殆どになると思います。 disable issue IDを設定することで、設定したissue IDを無視できます。実行するモジュールによってはlintが過度の検出をしてしまう為、明示的に設定しlintの検知から除外します。 lintConfig lintの設定ファイルを指定できます。パス設定はgradlewのあるフォルダと同じところからみた相対パスになります。 lintの設定ファイルの記述 基本的には.gradleで設定できる内容と同じ内容が設定できますが、lintConfigで設定したフィアルでは詳細な設定も記述できます。 参考： http://tools.android.com/tips/lint/suppressing-lint-warnings 記述方法:ファイルの個別除外とフォルダ以下全て除外の例です。 <?xml version="1.0" encoding="UTF-8"?> <lint> <issue id="all">　① <ignore path="src/test/androidtest.java" />　② <ignore path="src/test/**/*" />　③ </issue> </lint> issue idを設定します。"all"を設定することで全issue idを対象に出来ます。 ignoreで除外とし、optionのpathで対象ファイルの条件を記述します。（絶対パスの記述例） 2.の相対パスの記述例 調査してみて 今回lintの調査をしてみて、まだまだ調べ切れていない感じがします。 実際に調べ設定してみて設定方法もGUIからがいいのか手動設定がいいのかの判断まではついていませんが、lintの設定だけ考えると個人的には手動がわかりやすかった印象です。 ただ、実際に運用するにあたっては、lintに検知と対応する事を考えるとAndroid StudioのGUI上から設定し修正・運用する方が良さそうでした。 おまけ Android/sdk/toolsのlintコマンドで、オプションに--listをつけ実行する事で検知できるissue idが全て見れます。予想はしていましたが種類が多いのでlint実行時に検知されたissue idの内容を調べ随時対応していくのが効率的だと思いました。

こんにちは。Android 衛藤です。 12/21(日)に Android Bazaar and Conference 2014 Winter に参加してきましたので、今回はその報告を書かせて頂きます。 私が見た講演は下記の通りです。 [開会宣言] Android Link to Next Generation! ～次なる世界を目指して～ [基調講演] 「Project Araと新しいものづくりエコシステム」 [招待講演] Android 5.0とAndroid Wearで広がる最新アプリ開発技法 [招待講演] Microsoft <3 Android [招待講演] ウェアラブルコンピューティングとAndroidの未来 loT時代における開発手法の提案～スマホの次を見据えて～ Material Designの勘所 日本から海外、そして海外から日本、アプリビジネスの海外展開の今後。 歴史は繰り返す+トレンド 裏読みで2015年のモバイルを予測する これらの中で、いくつかピックアップして内容を記したいと思います。 講演内容 Android 5.0とAndroid Wearで広がる最新アプリ開発技法 マテリアルデザイン マテリアルデザインとは異なるデバイス間で一貫した表現をするためのデザイン思想 elevation / ripple / interpolator等の効果により自然に見せる ToolBarを使用する(ActionBarよりも柔軟なカスタマイズが可能) Android Wear 新しくなったNotification。通知をスタックできたりする Watch Face API が公開された Wearアプリを公開する際はGoogle Playのアプリの [価格と販売 / 配布地域] ページで、Google Play の Android Wear コレクションに追加されるように設定することができる Notificationを出しすぎるとアンインストールされるので、本当に必要なときにのみ出すようにする これからアプリを開発するにあたって オレオレUIではなくAndroidらしいものを作る(NavigationDrawerとかActionBar/ToolBarなど) Webのコピーのようなアプリは必要ない サクサク動き、見た目が美しく、電池持ちが良いアプリを作る Android5.0についてなので、当然ながらマテリアルデザインやWearについての話題でした。 この後のマテリアルデザイン講演で詳しく聞いてきたので、詳細はそちらで記載したいと思います。 AndroidらしいUIというところも重要で、やろうと思えばいくらでもUIはカスタマイズ出来ますが、 凝りすぎると返って使いづらいものになる場合もあるので、ユーザが使い慣れたUIがよいですね。 Microsoft <3 Android タイトルの"<3"ですが、ハートを表しているようです。 内容としては Microsoftでは常に1〜3年先のものを開発している(エンジニアの部門) Researchの部門で3年以上先に出るようなものを開発している 開発体制の変更 いままではWindowsを3年単位で開発・リリースしてきたが、アジャイル開発に変えて日〜月単位での開発・リリースをするようにした Visual Studio Communityを発表。C#/C++でAndroid開発をすることができる エミュレータで加速度をエミュレート、バッテリー残量を意図的に減らしたりする事が可能 エミュレータで加速度やバッテリーをいじったりするのはgenymotionのプレミアム会員で出来るみたいですが、 無料で使えるのは魅力的かと思います。 ウェアラブルコンピューティングとAndroidの未来 神戸大学大学院 塚本昌彦教授による講演で、非常に興味深かったです。 Singularity(シンギュラリティ)についての話が冒頭に出てきており、このSingularityは日本語に訳すと特異点というらしいです。 宇宙に関する話でよく出てくるようですがICTの分野だと「技術的特異点」などと訳されます。 Singularityはすぐ近くに来る、と言われていますが、具体的には2045年問題とも呼ばれているようですね。 人工知能が人間の知能を超える時がくる・・・SFの世界のような話で少し怖いですがどうなるのでしょう。 ウェアラブルの未来はというと、 ウェアラブルは単なるバズワードでは終わらない。特に春以降大きく変化していくと思われる SmartWatch3ではWifiもハード的に搭載している スマホが大きくなりすぎたため、スマホに変わる常時身に付けているデバイスになり、単独利用が増える 企業のウェアラブル参入が増加 マルチウォッチ対応してほしい(そもそも二つもWearつける人がいるのか分からない・・・) 最初はどうしても使いづらいのが特徴だが、実世界サービスやビジネス用としてのポテンシャルを膨大に持っている 今のところは通知連携やスマホの補助的ツールとしての使い方がメインかと思いますが、 今後はWear単独での利用が予想されたり、便利なツールが出てきそうですね。 これからどの程度成長してくるかは分かりませんが、HOME'Sでいち早くWear対応出来たのは良かったかな、と思っています。 Material Designの勘所 先ほど少し触れましたが、マテリアルデザインについても聞いてみました。 マテリアルデザインは、ガイドラインというよりは異なるデバイス間でも統一した体験が出来るためのデザイン思想のことです。 少しまとめると Visual Language(視覚的言語)である 紙とインクをコンピュータの世界へ当てはめる あらゆる物体がLayer構造で表現される(Shadowなど) タッチ、ジェスチャーにおいても自然な表現を(Ripple効果など) 要するに、活版印刷の時代に築き上げられた古き良きものをデジタルの世界にも導入しようという思想のようです。 マテリアルデザインを導入するにあたっての3つの原則 1. メタファー 実際の素材のメタファーである 素材との関係を考える 紙やボタンが重なった時の影など 2. Bold, Graphic&Intentional 大胆に活き活きと、意図的に 大きめのボタン等にすることで、ユーザアクションを強調する 3. Motionで意味を提供 モーションに意味を持たせることで、ユーザ体験の継続性を持たせる また、マテリアルデザインを考える上での3つのキーワードは 1. 環境 Z軸を考える フラットデザインが主流になっているが、配置が分かりづらい そのため、光源や環境光などを取り入れ、情報同士の関係性、分かりやすさを強調する 2. 素材の属性 物質としての高さを考える 紙であれば実質的にフラットに見えるが物質として高さが0のものは存在しない 3. 3D空間でのObject配置 http://www.google.com/design/spec/what-is-material/objects-in-3d-space.html 高さが2dpの物体があり、その上に高さ6dpの物体があるなら全体で8dpの高さとなる ActionBar / Floating Action Button / Card UI全てに3D空間として配置する ここに記載したことは、全て Googleのデザインガイドライン に入っています。 とりあえず全部読んだ方が良さそうですね。(私もこれからですが・・・) 最近マテリアルデザインを導入したアプリが増えているようなので、HOME'Sでも導入してみたいです。 歴史は繰り返す+トレンド 裏読みで2015年のモバイルを予測する 携帯コレクター小暮さん＆アスキーの遠藤さんによるトークセッション。 タイトル通り、これまでの変遷をもとに今後のトレンドを予測する話でした。 歴史は繰り返す これまでを見る限り、5〜10年サイクルで課金体系が変わってきている 1989年：モバイルインターネットの試行錯誤の時期 ダイヤルQ2による課金が主流 1999年：iモードの出現により課金体系がほぼ確率 2008年：iPhone, Androidの出現によりアプリ内課金が主流に これからはIoTの時代になり、いろんなモノがつながるようになってくる スマホは安定期に入ったのか？ これまでもいろんな異形な端末(セッションでは変態端末と言われてました・・・)が出てはすぐに消えていった スマホも実は異形な端末の部類だが、爆発的に普及した異例かもしれない ウェアラブルの今後 ウェアラブル端末にsimが差せ、それだけで通話できるようになる。となるとガラケーの再来では？ 心拍数などの身体計測系の機能はこれから欠かせなくなる。ヘルスケア機能が充実し、医療に役立つようになる。 テレビについてはどうなるのか？ 現状と変わらず？ または最近出てきているスマートテレビにシフト？ それともただ表示するだけのモニターとなり、テレビそのものが衰退？ テレビなど家電系の今後は気になりますね。 韓国でAndroid冷蔵庫が前に出たらしいですが、1年でなくなったらしいです。結構便利そうですが・・・ 話を聞いていると確かに歴史が繰り返されていると言える部分があると感じました。 これからどうなるのかは誰にも分かりませんが、このような視点での予測も面白いですね。 バザール バザールにも多数出店されていました。 サーバサイドのサービス紹介やMicrosoftのVisual Studioの紹介、Googleの秘密本配布など多数ありましたが、 その中で一点気になったのが、スマホアプリ開発技術検定試験というものがありました。 https://spkentei.jp 受講費用無料でiOS, Android, html5 CSS3などに対応しているとのことです。 学校等でも採用されているらしく、力試し受けてみてもいいかもしれません。 また会社の開発チームで受けることで技術力計測/向上にも使えそうです。 全体的に 初めてABCに参加したのですが、インターネットでの最新ニュースだけでは仕入れられないような話も聞けて、参加した価値があったと思います。 今回は、Android5.0およびAndroid Wearが発表された後に開催されただけあって、 内容もそれに関することが多かったようですね。 Android HOME'Sでも先日 Android Wear対応版 をリリースしましたが、 ウェアラブルが盛り上がって行っているようで、安心しています。 今後も最先端の技術を取り入れつつ、使い勝手の良いアプリを作っていければと思います。 また、最後の懇談会では多数の方とお名刺交換させて頂き、ありがとうございました。 じゃんけん大会でもみごと景品ゲットできたので、大満足です。 次回のABCは、2015/7/20(月・祝) 川崎振興会館にて開催とのことなので、 これからも参加していきたいと思います。

Apple原理主義者であり、Paper原理主義者でもある大坪です。 FacebookのPaperを起動してまず気がつくのがトップ画面のアニメーションでしょう。↓のビデオで親指を下から上に動かすとそれに合わせて、長方形型の写真やら文章がが「ぶわっ」と大きくなるところです。 このように特徴的なUIをもったアプリの発表から、それを再現するコードの公開までの速さには驚かされます。CocoaControlsには同じアニメーションを再現しようとしているプログラムが二つ公開されています。 HAPaperViewController MMPaper 両方とも希望をあたえてくれると共に、Facebook Paperまでの距離の遠さを思い知らされることにもなる。なぜそう考えるのか、そして私の試みがどの程度進んだのかについて書きます。 最近発表されたMMPaperの方を実際に動かしてみましょう。Facebook paperに比べていくつかの部分が気になります。 ズームするときの動きがスムーズではない（To doにもあげられていますが） 指を離した後、自動的にズームしている間、およびそのあと少しの間はジェスチャを受け付けない。つまりジェスチャが時々空振りする。 （他にもありますが、ひとまずここまで） これらの問題を できるだけ 解消することを目指しました。 ーーー コードは GitHub に置きました。実行する前に"Podfile"のあるディレクトリで"pods install"とするのを忘れないでください。 アプリを起動するとこんな風に動きます 起動すると二つボタンが並んだ画面がでてきます。"Responsive"が今回あれこれ工夫した つもり のバージョン、"Standard"が「普通に」実装したバージョンです。"Responsive"のほうが何かとスムーズに動きますよね。ね？ね？（血走った目で懇願） このデモを見てもなお読み続けてくれる心の広い方がいると信じて細かい説明をします。 ーーー Paperトップ画面の動きをみると 「これはUICollectionViewを使ったCustom Transitionだ」 と思う。さて、どのような方式で実装するか？方法は私が思いつくところでは二つあり Layout-to-layout transition(例： taktamur/PAMTransitionSample ） UICollectionViewController-to-UICollectionViewController transition(例： timarnold/UICollectionView-Transition-Demo ） ちなみに先ほど挙げたMMPaperは後者の方式で実装されています。厳密に比較したわけではないのですが、普通に実装すると UICollectionViewController-to-UICollectionViewControllerのほうがスムーズに動くようです。 私も最初UICollectionViewController-to-UICollectionViewControllerで実装したのですが、後述する理由によりLayout-to-layout を使っています。とはいえ普通に実装したのでは"Standard"を選択した時のような動きにしかならない。ではどうするか。 デモプログラムの"Standard"と"Responsive"の違いは二つで "Standard"ではイメージ表示にUIImageViewを、"Responsive"ではASImageNode（in AsyncDisplayKit ）を使っている。 UIPanGestureRecognizerがUIGestureRecognizerState.Endedを返してきた後(つまりユーザがスワイプジェスチャを終了した後)"Standard"ではfinishInteractiveTransition()を呼んでいる。"Responsive"ではFacebook Popを使って終了位置までのアニメーションを制御し、その間に新たにタッチが始まった場合にはアニメーションを中断するようにしている。 他の処理は全て同一。ではどのような狙いでこのような「変更」を加えたか。 一点目、レスポンスをあげるため、ジェスチャに対応したセルの変形処理が少しでも軽くなるように、ASImageNodeを用いました。しかし正直に言えば今回のような使い方でどれだけ効果があるのかは今ひとつわかりません。触っていると、確かに少しレスポンスが良いような気がしますが、製作者の贔屓目からもしれません。 ASyncDisplayKitのページ に単にUIImageViewをASImageNodeに置き換えただけでも一部の処理がバックグラウンドで処理されるため効果がある、と記載されていますが... 二点目。"Standard"ではUIPanGestureRecognizerのコールバック関数で、UIGestureRecognizerのstateがUIGestureRecognizerState.Endedだった時にこんな処理を行っています。 if success { 　self.collectionView?.finishInteractiveTransition() 　self.toBeExpandedFlag = !self.toBeExpandedFlag } else{ 　self.collectionView?.cancelInteractiveTransition() } 遷移を完了させたければfinishInteractiveTransition()を呼び、キャンセルならばcancelInteractiveTransition()を呼ぶ。コードは簡単明瞭ですがここに問題がある。前掲のサンプルを解説しているページから引用します。 ここで注意するのは、ジェスチャーの終了からアニメーションの完了までに隙間時間(A)がある事です。progressが0.6等の半端な場合にfinishInteractiveTransitionやcancelInteractiveTransitionを呼び出すと、progress1.0になるまでアニメーションして（体感1秒程度かかるときがある）、その後にcompletionブロックが呼び出されます。 この隙間時間に次のtransitionを開始しようとするとクラッシュします。 引用元： UICollectionViewをジェスチャーで拡大縮小したい(iOS7〜) - Qiita このサンプルに習い、クラッシュを避けるため"Standard"ではジェスチャーの終了後UIGestureRecognizerを停止しています。こうすると確かにクラッシュしないのですが、その間ユーザの操作を受け付けることができない。そして時としてこのfinishInteractiveTransition()を呼んだことによるアニメーションは見かけより長くかかる。反応しない画面上をひたすらスワイプするのはどう考えても楽しくない。 というわけで"Responsive"では、ジェスチャーを終了した後のアニメーションを自前で実装しています。（参考にしたのは このサイト ） UIKitDynamicsを使っても いいとは思うのですが、ここは同じくFacebookから公開されているPopを使いました。 *1 今のプログラムは指を離してから拡大または縮小が確定するまでのわずかな時間に再度スワイプを始めた場合、進行中のアニメーションをキャンセルし、ユーザのタッチに反応します。 （わずかな例外を除いて） 正直に書きますが、まだ「不感帯」が残っておりswipeが空振りになることがある。しかし"Standard"より「マシ」になっている、というのはある程度の自信を持って言えます。いや、素直にUICollectionViewController-to-UICollectionViewControllerで実装したの(例えばMMPaper)に比べてどうなんだ、と問われると下を向いてしまいますが.. ーーー Facebook paperチームのエンジニアはプレゼンでこう述べています。 最初にiPhoneに触った時、まるで魔法のように感じた。Appleは表示するコンテンツとユーザの間にあるバリアを取り除き、ユーザが直接コンテンツを操作することを可能にしたからだ。しかしユーザのジェスチャが認識されなかったり、アニメーションが滑らかでないとそうした魔法は消え去ってしまう。 そうして作られたPaperではすべての動きが軽く、そして連続的に動く。それは初めてIPhoneの慣性スクロールに触った時と同じ驚きを与えてくれる。 今回の試みには「不感帯」の他にも大きな問題が存在しています。Paperでは縦方向の拡大ジェスチャと横方向のスクロールジェスチャを両方同時に行うことができる。今のところこれを実現させる方法がわかりません。未だ撲滅できない「不感帯」があることも考えると、ゴールははるか彼方に霞んでいるとしか思えない。 そもそもFacebookが公開したライブラリを使いながら、依然として存在しているこの距離は一体どういうことか、という根源的な問題からは目をそらし、もう少ししつこく 「魔法」 の再現に努力したいと思っています。 *1 : ちなみにUICollectionViewController-to-UICollectionViewControllerで実装すると、指を離した後のアニメーション時にUIGestureRecognizerがそもそも反応してくれません。クラッシュしないのはいいのですが、工夫のしようもない。というわけでLayout-to-layout を使っています。

大坪と申します。先日面白い記事を見つけたので紹介しつつ、つらつらと。 記事の題名は "Design Courage" 。さて、DesignといえばApple。（異論は認めません。私は視野の狭いApple原理主義者なのです）Appleが新しい製品を出すたび（あるいは出さないたび）聞こえてくる "Steve JobsがいなくなったからAppleはもうだめだ” "Steve Jobsが生きていればこんな製品は出さなかった” という声の多さには驚きます。 *1 さて、そうした人たちが言うようにSteve Jobsの存在自体がAppleを他の企業から際立たせていたものなのか？この記事の筆者は違う、と主張します。ではそれは何なのか。 The difference between Apple and many other companies comes down to one word: courage. Everyone thinks they have great ideas. Everyone thinks they’re smart. Everyone thinks they have great designers and engineers. So why is there so much difference between the best and the average? Courage. Not lip service courage, actual courage. It’s rare in software. 引用元： Design Courage — Medium 適当な訳：Appleと他の数多くの企業との違いは一語で表すことができる。「勇気」だ。誰もが自分たちはすごいアイディアを持っていると思っている。誰もが自分たちは賢いと思っている。誰もが自社にはすごいエンジニアとデザイナーがいると思っている。では「最高」と「凡庸」の差異はなんなのか。それは「勇気」だ。ただ口で言っているのではなく本当の「勇気」これはソフトウェア業界では稀なものだ。 では具体的にそれはどのような「行為」に現れてくるのか。例を考えました 未だにApple Watchの発売日は明らかにされません。例えば発売日を決めるにあたり、Appleはこんな考え方もできたはずです。 「他の企業がスマートウォッチを発売する前に売り出し、市場シェアをとってしまおう」 「今年のホリデーシーズンを逃すことはありえない。必ずその前に出荷するべきだ」 しかし彼らはそうしなかった。発売時期を遅らせても完成度を高めることを選択したのです *2 。企業に勤めている人であれば、↑のような声に逆らうことがどれだけ勇気が必要なことが想像できるのではないでしょうか。 とかなんとか考えていて別の記事を思い出しました。 Every aspect of the company's production cycle, from conception to ship date, is calculated. But--and this is a big "but"--what makes Apple different is that it is a company that is willing to move those deadlines. If a product in development isn't ready to be released, the deadline is pushed back. If an idea isn't perfect, or isn't considered truly magical and delightful internally, it's held back, revised, and the product given an entirely new launch date. 引用元： The Biggest Lesson I Learned as an Apple Designer | Inc.com 適当な訳：(Appleの）全ての製品開発サイクル-コンセプト作成から出荷まで-は計算されて設定される。しかし-この「しかし」が大きいのだが-Appleが他の企業と違うのは、そうして設定されたデッドラインを進んで変更することにある。開発中の製品がリリースされるだけの完成度になければ、期限は遅らされる。アイディアが完璧ではなかったり、真に魔法のようだったり楽しくないと考えられれば期限は伸ばされ、スケジュールは改定され、製品の発売日は全く新しく設定される。 なるほどなるほど。話しとしては面白いねえ。でも「期限を決めずに納得のいくまでがんばって！」などといっても怠けて結局何もでてこないのではないか？ こうした「当然の疑問」に対して本記事はこう述べます。 That doesn’t mean your design team is always right, or deserves unchecked power. A company needs balance across all disciplines. But the reality of software development today is we put design on a pedestal right up until the moment it threatens to affect our deadline. Then design turns into an unaffordable and unreasonable luxury 引用元： Design Courage — Medium 適ry)訳：これはデザインチームがいつも正しい、とか誰もチェックできないくらいの力を持つべきだ、という意味ではない。企業は全ての面に渡ってバランスを保たなければならない。しかし昨今のソフトウェア開発現場では、デザインをありがたく奉っておき、期限が迫ってきた途端「デザインは理不尽で度を越した贅沢」扱いする。 　 いやいや、ビジネスなんだから期限が第一。というわけで例えば、プロダクトの開発に関して 「設定したリリース日より１ヶ月前倒しで完成した！グリフィンドールに50点 *3 」 とか 「面白いプロダクトだけど、リリースが２週間おくれちゃったね。スリザリンに-30点」 といったような評価があっても驚きません。こうした「期日を守ったか守れなかったか」を元に判断することは確かに「わかりやすい」し「定量的」でもある。しかしそうした評価方法で「真に素晴らしい製品」を作りあげることができるのか？ 「リリースを２週間遅らせたことによる完成度の向上と、ビジネスへのインパクトを秤にかける」 のは難しいし、そのように考えることは確かに「勇気が要る」ことだなと考えたりします。 そんなのは自分でリリースデートを決められる立場にいるからできることだよ、という議論もあるでしょう *4 。 しかしながら、私見ではここで言われている「勇気」は開発における期限に限定されるものではない。 話が膨らみすぎたので、身の丈に戻しましょう。先日iPhone版「 へやくる！ 」をリリースしました。 物件一覧画面を見ていただくとナビゲーションバーがないことに気がつくと思います。ここから左右にスワイプすれば条件設定画面、あるいは物件詳細画面がでてくるのですが、果たしてユーザがそれに気がついてくれるか？（初回起動時にインストラクションを出してはいるのですが） ここは社内でも議論になりました *5 。あれやこれやの検討の末現在の形でリリースしたわけですが、リリース後しばらく 「最初の画面から誰も移動できず、アプリがろくに使われないのではないか」 という悪夢に悩まされ続けたのも事実。素直にナビゲーションバーをつけておけばよかったか、あるいは画面遷移を示すボタンだけでもあったほうがよかったのか、とかあれこれ考えました。アプリの利用状況を見てそうした結果になっていないことを知り、最近ようやく安眠できるようになったというのは嘘です（最後の部分だけ）。 これは「Apple Watchのリリースを翌年春まで伸ばす」ことに比べれば、測定限界以下の小さな「勇気」です。しかし製品やサービスのデザイン/設計はこうした「勇気」の積み重ねでもある。小さなステップであっても「勇気」の持ちようによって最終的に表にでてくる製品/サービスは大きく変わってくるのかもしれない、と最近考えています。 *1 : 私のような人間からすると、そうやって自分の頭の中にSteve Jobsを住まわせておくことができる、というのはとてもすごいことだなあと思うのですが *2 : 実際にでてきた製品がひどい出来で「発売伸ばした挙句にこの出来かよ」と思う危険性の存在は無視します *3 : 最近子供がハリーポッターを読む年頃になったのです *4 : 皮肉なことですが、Appleはサプライヤーに対して、 非常に過酷なDeadlineを課す契約 をしていることが明らかになっています *5 : ちなみに私が愛するFacebook Paperはもっと大胆で、最初の画面を上から下にスワイプしない限り設定はおろか新たな投稿も行えないデザインになっています

こんにちは、リッテルラボラトリーの清田です。 11月19日(水)、20日(木)の2日間にわたって芝浦工業大学豊洲キャンパスで開催される WebDB Forum 2014 にて、リッテルラボラトリーのプロダクトの展示・発表を行います！ WebDB Forumは、Webおよびデータベースに関する研究発表の場としては国内唯一の査読付き会議で、例年高いレベルの発表が多数行われます。 学生の方は1000円（聴講のみ）で参加できます ので、お近くの方はぜひお越しください。 常設展示ブースおよびポスターレセプションでは、リッテルラボラトリーが新たに開発した 部屋作りシミュレーション『GRID VRICK』 のデモを展示します。 LEGO(R)のブロックを組み替えるだけで、仮想3D空間内に自分好みの部屋を楽しみながら作れるというシステムです。 また、Oculus Riftを着用して、自分で作った部屋の中を自由に歩き回ることができます。ぜひ体験してみてください！ 20日(木)午前中の技術報告セッションでは、『不動産・住宅情報サイトHOME’Sにおけるユーザーの「理解」と「支援」の技術』と題して、 2014年5月にリリースした『ホームズくんのこれからシアター』 の運用で得られた知見について発表します。 多数の方のご参加をお待ちしています！

こんにちは。 池田と申します。 本日は、部屋作りシミュレーションシステム「GRID VRICK(グリッドブリック)」についてご紹介しようと思います。 このシステムは、楽しみながら部屋作りを体験できるシミュレーションシステムです。 お部屋を住み替える際には、費用の問題であったり、検討の時間の問題であったり、いろいろな問題があり、結構ハードルが高いものだと思います。 ですが、部屋を住み替えるということは、新しい環境に身を置き、新しい気持ちを持ち、新しい生活を築いていく、とても楽しく素晴らしいことだと思います。 この「GRID VRICK(グリッドブリック)」ではその「楽しい！」という気持ちをより多くの人に感じてもらいたく、作成するに至りました。 今回ここで紹介するのは、LEGO(R)のブロックと組み合わせた体験の例をお伝えしたいと思います。 実際できることは以下です。 ブロックを配置し、間取り作成、家具の配置 ブロックを組み替えることで、リアルタイムに間取り、家具の更新 PC画面上で、部屋の壁紙、扉、窓、家具の種類を変更 「Oculus Rift」を着用し、部屋のウォークスルー体験 実際その流れを実際の利用風景を交えながら、ご紹介していきたいと思います。 間取り作成、家具の配置 ここでは、壁は赤いブロック、扉は薄緑のブロック、窓は青のブロックという設定がされており、このブロックの位置、大きさにより、3Dの部屋空間がPC上に再現されます。 こちらがブロックを配置しているところ。 そしてそれで再現された、3Dの部屋空間。 家具を配置したところ。 間取り、家具の更新 作成した間取り、家具は、ブロックの付け替えにより、リアルタイムで更新ができます。 左下の部屋の窓を増やしてみました。 PC上の画面はこんな感じ。 壁紙、扉、窓、家具の変更 PCの画面上で操作することで、壁紙、扉、窓、家具などを変更できます。 壁紙を変えてみました。 家具(ソファ)を変えてみました。 ウォークスルー体験 「Oculus Rift」を着用することで、 自分が作成した部屋に実際入り込んで、ウォークスルーするような体験をすることができます。 部屋の入口から入るところ。 作ったリビングルーム。 作ったトイレ。 以上が、部屋作りの体験ができるシミュレーションシステム「GRID VRICK(グリッドブリック)」です。 動作している様子は以下の動画でご覧いただけます。 LEGO(R)のブロックで作った室内をOculus Riftでウォークスルー！「GRID VRICK ... 詳細は以下からご覧ください。 「GRID VRICK」(グリッドブリック)おもちゃのブロック等で楽しみながらお部屋作り 株式会社ネクスト リッテルラボラトリー 11月23日(日)、11月24日(月)で開催されるMaker Faireに出展（東京国際展示場・西３ホール　21-6）しますので、気になった方はぜひぜひ遊びに来てください！ Maker Faire Tokyo 2014 | Maker Faire Tokyo 2014 | Make: Japan Maker Faire Tokyo 2014 | Maker Faire Tokyo 2014 | Make: Japan

こんにちは。iOS開発Gの石田です。 iPhone6とiOS8が出てしばらく経ちますが、もうすでに入手されたかたも多いかと思います。 iOS8の新機能で僕が注目しているのが、Homekitです。家電をiOSデバイス経由で操作することができる機能で 寒い冬は家に帰る前にエアコンをつけておいてあったかくしておくとか、Siriに「電気消して！」と頼んだら消してくれるようになりそうです。 しかしこのHomeKitなのですが、家電がHomeKitに対応していないと使うことができません。 現状で対応している家電としては こんな室温調節器や http://lyric.honeywell.com/ こんな電球がありますが http://www2.meethue.com/ja-jp/ 海外メーカーしかなく、家電量販店などで我々が目にするメーカーはまだ対応していません。 今後対応機種が発表されていくと思いますが、現在はシミュレータで開発するしかない状況です。 そこでSiriとIRKitという赤外線学習を使えば、HomeKitなしで似たようなことができるのでは・・・と思い立ち 作ってみました。 IRKitについて IRKitとは、Wifi機能がついた赤外線リモコンで、外部からアプリを通してリモコンの信号を送ることができます。 このIRKitはAPIが公開されており、簡単に自分でアプリなどに組み込めるため、様々な方が開発を行っています。 http://getirkit.com/ これを用いれば、赤外線リモコンで操作ができる家電であれば遠隔操作することができます。また赤外線で操作できない家電でもこのようなキットをを使うことで、 家電を赤外線に対応することができます。 http://hitoriblog.com/?p=24191 iOS8でのSiriの新機能 iOS8の新機能として、「Hey! Siri」と呼びかけるとSiriが起動する機能が追加されました。 そこから質問を投げかければ、Siriが質問に答えてくれるようになっています。 ここで重要なのが、画面がロックされていても電源に繋がっている状態であればSiriが起動することです。 しかしながら現在、Siriからサードパーティ製のアプリを操作するといったことはできません。SiriのAPIは公開されていないので appleのアプリであるタイマー、アラーム、天気、メモなどの操作しかできません。 ただアプリ名を言うと、そのアプリを起動することができます。 つまり電源に繋がっているiPhoneに「Hey,Siri アプリ名」と呼びかければ、待機状態のiPhoneのアプリを起動することができるということです。 実現方法 iOS8のSiriとIRKitを組み合わせて、Siriに家電を操作してもらうようにします。 方法以下の通りです。 「電気つけて」など命令形の名前のアプリを作り、そのアプリが起動したらIRKit経由で家の電気がつくようにする。 そのアプリを「Hey Siri」で起動することにより、疑似的にSiriが家電を操作しているようになる！ つまり命令の数だけアプリを作り、Siriに命令しているかのように話すと、Siriはアプリを立ち上げるのです。 ここで注意点としては、命令文のアプリを作っても起動してくれないことがあります。 例えば「テレビつけて」という名前のアプリを作って、「Hey,Siri　テレビつけて」と言っても 「いいえ、それはできません」と断られてしまいます笑。これは、Siriが「テレビつけて」という言葉をちゃんと命令として 認識してしまうことが原因です。現状でこの現象が起きたのはテレビだけで、「電気つけて」や「電気消して」は大丈夫でした。 いわばSiriの認識の甘さを利用しているだけなので、Siriがもっと賢くなって命令として認識されてしまうとこの手法は使えません。 現状で命令と認識されてしまうものについては、別の言葉にするしかありません。例えば今回は、「テレビ電源」という言葉に置き換えています。 アプリについて Siriで起動して、家電を操作するアプリですが、非常にシンプルなものになります。 初回起動時のみ、家電の赤外線情報を登録する画面が出て、使いたい家電のリモコンをIRKitに向かって押し、登録します。 それ以降の起動では、Wifiに繋がっているIRKitを探し、登録されている赤外線信号を送信、その後すぐにアプリを終了します。 もちろん1アプリ1命令になるため、命令の数だけアプリを作ってiPhoneにインストールします。 IRKitの検索、信号の送信などの機能の組み込みは、SDKが公開されているので非常に簡単に行うことができました。 作って実際にやってみた https://www.youtube.com/watch?v=3df-6wTeDZY Siriで家電を操作してみた 動画では、間接照明のON・OFF、テレビON、チャンネルの変更を行っています。 割と正しく認識して、家電を操作してくれます。Siriの認識、アプリの起動、IRKitの検索、信号の受信という過程があるため、 命令してから実際に操作が完了するまでに少しラグがあります。 またテレビを付けたあとの命令の認識に特に時間がかかっています。 これはテレビの音声をSiriが拾ってしまうことが原因です。なのでチャンネル替えや音量調節といったテレビの操作は 現状では難しそうです。 最近では、テレビに音声認識機能がついたものが相次いで発売されています。リモコンに向かって、 ボタンを押している間だけ認識されるものが多いので、そういったものであれば認識は素早くできそうです。 （リモコンに向かって話しかけるくらいなら、リモコンのボタンを押した方が早いとは思いますが・・） 認識できる距離ですが、iPhoneにある程度の声量が届けば認識してくれるので、隣の部屋くらいであれば大丈夫そうです。 使い方としては、帰宅後に暗くて電気のスイッチがどこにあるのか分からないときに、暗闇に向かって命令すると 電気をつけてくれるのが便利です。 また家を出るときや帰宅後に着換えながら、テレビを消すといった使い方も便利です。手を使えない状況では重宝します。 最後に なんとか使えるレベルにはなりましたが、まだまだSiriが認識してくれるように意識して丁寧に話さないとうまくいきません。 今回作った似非HomeKitでは、「電気つけといて」「電気オン」「ライトつけて」という別名アプリをたくさん作らないと 別の言い回しには対応してくれません。 本物のHomeKitでは、もっと適当に話しても読み取ってくれる高い認識精度を期待します。 とりあえず似非HomeKitの次の機能追加としては、iBeaconを連携させることを考えています。 また本アプリは、名前だけ変えて同じアプリを複数インストールする必要があるため、iOS Developer Programの登録が必要です。 App Storeへの審査・配布は機能的に難しいと思いますので Homekitが待ち遠しい方は、ぜひIRKitを使って開発してみてください。