RELEASE
2014.09.12

Qiita Meetup #8で弊社活用事例を発表しました


スマートデバイスグループの片渕(@hotchemi)です。

今回Open Network Space Daikanyamaで行われたQiita/Qiita:Team Meetup #8に参加し,「100人で使うQiita:Team」というタイトルで筆者の所属するスマートデバイスグループのQiita:Team活用事例を発表致しました。当日のハッシュタグは#qiita_meetupとなります。

解決すべき課題

どの様なジャンルであろうとツールとは問題解決の手段なので,そもそも解決すべき課題が定まっていなければ導入する意義は薄くなりがちです。

私の所属するスマートデバイスグループは100名を超える比較的大きな組織ですが,以下の様な課題感を抱えていました。

  • そもそもエンジニアが情報発信する文化が醸成されていない
  • 情報発信するプラットフォームが無いため,メールや会議中心のコミュニケーションとなっていた。技術情報なども全てメールでやり取りしていた
  • エンジニアが集まっているものの,コミュニケーションがチーム間で完結しておりチームを超えたナレッジ共有が成されていなかった

これらの課題を解決する為,「 気軽に情報を発信でき,インタラクティブなコミュニケーションが可能でエンジニアフレンドリーなプラットフォーム 」を導入する為に動き出しました。

導入までの道のり

ツール検討時にはQiita:Teamの他にも,株式会社ソニックガーデンSKIPAtlassianConfluenceを検討しましたが,最終的に投稿のしやすさや使い方・UIのシンプルさを重視しQiita:Teamを選択しました。

上記の2ツールも非常に有用なので,組織のコンテキストに応じてセレクトするのが良いと思います。

導入に当たって

1ヶ月のトライアル期間を経て採用に至ったわけですが,導入段階ではとにかく書く事の敷居を下げる事に注力しました。

具体的には,

  • よく使いそうなタグ「iOS,Android,ランチ,ポエム」等を予めピックアップしてあげる
  • 初めから全員を巻き込むのではなくアーリーアダプタ層に記事を書き溜めてもらい徐々に和を広げていく
  • 議事録や日報もQiita:Teamに書いて貰い,ツールに触れる時間を増やす
  • 初めて触る人用のプロジェクトページを作成し,ツールの意義や雰囲気を理解して貰う
  • 地道に啓蒙活動を続ける

などの施策を打つ事によって,徐々にメンバーが記事を書いてくれるようになりました。

いかに優れたツールであっても使って貰えなければ意味がないので,この辺りは地道な啓蒙活動が必要なのだというのが振り返ってみた率直な感想です。

組織の文化を醸成するという事は一朝一夕ではできないので,根気の良さが求められると思います。

導入成果

現在は1日平均20件(技術ネタ10,日報4,議事録6)程度の投稿があり,予想していたよりもタイムラインの流れが速いという嬉しい問題が起こっています。markdownというフォーマットが足かせになるかと思っていましたが,非エンジニアであってもmarkdownを覚えて投稿してくれています。

また,徐々にですが以下の成果が出始めています。

  • エンジニア-QAメンバー間でテストの観点や書籍に関する知見を共有するなど,これまでにないコラボレーションが生まれた
  • 社内で勉強会を気軽に開催しやすくなった
  • 細かい要望などメンバー一人一人の声を拾いやすくなった
  • 本家Qiitaに投稿してくれる人も出てきた

課題

勿論課題が無いわけではなく,想定していたよりもタイムラインの流れが速くなり一つ一つの投稿をしっかり見る時間がないという問題や,社内のユースケースだとどうしても特定メンバーのみで共有したい情報をどうするかという問題が出てきています。

Incrementsの人と話した所、上記の問題へのソリューションを検討しているとの事でしたので,楽しみに待ちたいと思っています。

まとめ

  • Qiita:Teamを活用する事でチームを超える交流が生まれた
  • 議事録や技術情報などグループ内ナレッジの一元化に成功
  • メールベースの情報発信からQiitaでのリアルタイムな情報共有へ
  • 100人規模のチームでも特に問題なく運用する事が可能!
  • 情報量が多くなると追い切れないという課題はある

リクルートテクノロジーズでは今後もエンジニアリングやチームビルディングの改善活動について,積極的に知見を共有していきたいと考えています。

RELEASE
2014.09.02

Google GlassはNexus 5で十分にプロトタイプできるか?


こんにちは、ATLでウェアラブルデバイスの研究をしている吉村です。ふとしたことからGoogle Glassに触れることになってここ3〜4回ほど記事を書かせていただいていたわけなのですが、このデバイスはなかなか面白いものです。ボイスコマンドで制御され、通知が入れば首を振るだけで視野の右上にぼんやりと画面が投影されて確認でき、終われば勝手に画面が消えている…といった形のUXは、通知→ポケットから取り出して起動→情報を確認→終了する、といったような一般的な携帯電話が提供するものとは全く違い、当然アプリにもこれまでとは全く違うUXが求められます。…この辺りはもう何回も書いているわけなのですが ;)


しかし、これの上で動作するアプリを作ろうにもエミュレータは公式にはなく、実機を用意しようにも入手経路や費用面でいろいろと苦労させられるのが現状です。いろいろ考えた末、Nexus 5を使用してGlasswareを(ギリギリ)プロトタイプできるような感触を得たので、今回はそれについて書かせてもらえたらと思います。ふわふわした話になってしまう可能性がありますが、その辺はなにとぞよろしくお願いいたします m(__)m


最初に断わっておきますが、これはあくまでも私が研究に携わった中で得た一つの知見としてとらえていただければ幸いです!

ここで挙げる方法が常に最善なはずはありませんし、そうでない場合を自分もいくつか経験しています。


Nexus 5?

素のAndroid 4.4(XE16以降がベースにしているバージョン)が動く、比較的手軽なデバイスだからです。今回はAndroidベースとはいえ違うシステムで動作させるものをプロトタイプしようとしているので「素の」というところがかなり重要になります。一方でハードウェアスペック的にはGoogle GlassはどちらかというとNexus Sに似ているので、ひょっとするとCyanogenMod 11をNexus Sで動かした方が適当な場合もあるかもしれません。


ワークフロー

基本的には適当なエミュレーションレイヤーを挟み込み、共通項の多いActivityを中心にモデリングを進め、そして一通り片付いたらGlassへポートする、という段階的なアプローチがある程度有効です。


モデリング

だいたい以下のような感じにGlass固有のAPIをモックするようなレイヤーを挿入します。


LiveCard→Ongoing Notification

GlasswareではServiceLiveCardを組み合わせるケースが一般的ですが、これはServiceNotification、あるいはWidgetRemoteViewsでエミュレートするのが良いのではないかと思います。


だいたいこのように書かれるところ:


これをAndroidのNotificationで動作させるためのエミュレーションレイヤーはこのような感じに:


Mirror API→GCM+Notification?

同様に、Mirror APIGoogle Nowで…としたいのですが、残念ながら今のところGoogle Nowに独自カードを提示させることはできません。そのため、現在のところはGoogle Cloud Messaging (GCM)などを使用してリモートでNotificationを飛ばせるようなサービスをどこかに立て、それを使うことでエミュレートするほかにはなさそうです。


このようなサービスの書き方ですが、とりあえずGoGoogle App Engineを使用してこのような形に書くことができます(注: 最新のGoogle Cloud SDKでは多少変わっているかもしれません。)


まずapp.yamlから。


ありがたいことにGoにもGCM関係をハンドリングしてくれる gcm というライブラリがあり、ここではそれを使用させてもらうことにします。普通に開発環境で動かすにはgoapp経由でインストールするだけで良いのですが、このままだとGoogle App Engineへ展開した際に漏れてしまうので適当に作業ディレクトリへコピーしておきます。



ロジックの実装ですが、reflector/reflector.goとして、以下のように書いておきます。GCM関連の処理はライブラリで行なうので、ここではデバイスの登録を受けつけてDatastoreに書いていたり拡散したいパラメータをライブラリに渡しているくらいなもので実にシンプルなものです。


これを、以下のようにまとめて適当にGoogle App Engineへ展開しておきます。



これでサーバ環境の準備は完了です。これでAndroid端末を http://your-application-id-goes-here.appspot.com/device へregid=…としてPOSTすることで登録ができ、その後適当に http://your-application-id-goes-here.appspot.com/ へmessage=….という形のデータをPOSTすることで外から通知を行なうことができるようになりました。


あとはこれを端末で適当に受けてNotificationなど出すことで、外部からnon-obtrusiveな通知を送るためにMirror APIを使用しているような場合についてはかなり手荒ながらエミュレートができたかな、と思います。


この例では通知対象を限定すらしていないので通知すると全端末に飛んでしまいます。とはいえテスト用途でとりわけ小規模な使い方をしている限りあまり問題にならないかと思いますが…



GestureDetector→エミュレート


次です。さて、GestureDetectorはAndroid SDKにもあるのですが、Glasswareの場合GDK特有のGestureDetectorを使用する必要があります(さもないと検出できない)。次のようなコードがあったとします。


Glass:


上のコードをAndroidで動作させるために必要なエミュレーションレイヤーはだいたい次のような形になります。実質的な検出ロジックにおいては実装を割愛していますが、こちらはAndroid SDKで普通に検出する場合とほぼ同等の実装になるのではないかと思います:



GDKのGestureクラスは単なるenumであり、こちらも当然Android SDKとは互換性がないのでこちらも定義しておきます。



最後にActivityレイヤーですべてのMotionEventを解析するようにします。



これで最初に挙げたGoogle Glass用のコードが動作するはずです。


GCM→Standalone GCM

GlassはGoogle Play Servicesを持っていないので、GCMを使用する場合にはStandalone版を使用することになります。Standalone版はAndroidでも特に問題なく使えるので、こちらを使用しておけばそのままGlassで動作させることができます。


Card→LayoutInflater

Cardはパラメータを受けとってGlass標準のレイアウトを作成するヘルパー的な役目をしていますので、簡単なものであればLayoutInflaterを使用して適当なカスタムレイアウトをロードさせるようにするのが適当でしょう。


Glass:


このようなコードがある場合、Androidでは以下のようにエミュレーションを行なうことになるでしょう。この例ではaddImageなどのメソッドは定義していませんが、もっと複雑な例では必要に応じて追加することになると思います。


メニュー

無理にカスタム設計するよりも、透明ActivityOption Menuによるシステム標準のエミュレーション機構に頼るのが最善です。ただ、これをそのままAndroidで動かすと見かけがかなり違ってきてしまいますが…


Glass:


メニューを起動するための透明Activityについては以下のようになります。



VoiceTrigger関連


メタデータはそのままでOKですが、クラス参照は次のような形でスタブ化しておく必要があります。



当然これだけではボイスコマンドを聞いてくれませんので、ボイスコマンドに対応するServiceをandroid.intent.action.MAIN/android.intent.category.LAUNCHERから別に起動できるようにするようにしておきます。


また、Tasker/AutoVoiceなどを併用することでボイスコマンドを使用して起動させることが可能になります。

※詳細な方法はlifehackerの記事によくまとまっているのでそちらをご参照ください :)


ポーティング

エミュレーションレイヤーを外して、非互換性があるようなら適当に直します。この際、アプリ自体が単純だったりレイヤーの設計がうまく行っていれば特にそれほど問題になることはないのですが、実際のポーティングでは以下のようなところが問題になりやすい感じがします。


OpenGL ES 2.0

Glassが搭載しているGPUはNexus Sと同じSGX540なので、Nexus 5とはかなり違います。このためシェーダーのコンパイルに失敗したりすることがあるので、このような場合はNexus S+CyanogenMod 11あたりで動作を確認するのが良いでしょう。


発熱

GlassのCPU自体はNexus Sと同等なのですが、フォームファクタが違いすぎるので無理をさせてしまうとすぐに高温になります。高温な状態になると”ok, glass”と交互に”Glass must cool down to run smoothly.”というメッセージが表示されてくるので注意しましょう。


image-0


まとめ

Google GlassとAndroid携帯端末はとても良く似ています。基本的にフロント面から遠くなればなるだけ共通項が増えてくるようなイメージを少しでも伝えられたでしょうか。ここに挙げた差分は自分で研究に参加している時にたまたま当たったものだけでありますが、大まかなところではこのくらいではないかと思います。懸念通りふわふわしたエントリになってしまいましたが、もしGoogle Glassで開発をしたくなったときこれが開発効率向上の役に立つことを祈ります。

TAGS: ,

RELEASE
2014.09.01

O2O/IoT/Wearable時代におけるWeb以外のネットワーク技術(MQTT/BluetoothLE)について、YAPC::Asia Tokyo 2014で発表してきました


7月からラボにジョインした加藤(lyokato)です。


YAPC::Asia Tokyo 2014 一日目(29日)にて 「O2O/IoT/Wearable時代におけるWeb以外のネットワーク技術」というタイトルで発表させていただきました。


IoTとO2O、それぞれの分野で最近注目を集めているMQTTとBluetooth LEについての内容になります。


まずMQTTについてですが、MQTTがどんなものか、近い機能の分野で名前をよく見かける他のプロトコルとどう違うのかという話を、

次に、Bluetooth LEとはどんなものか、iBeaconでどのように利用されているのか、WebやWearableとどう連動していくのかという話をさせて頂きました。



発表資料はこちらです。



自分自身、無線通信技術をずっとやってきたわけでもなければ、machine to machineのような業界でやってきたわけでもなく、つい最近になってこの分野に興味を持ち勉強しはじめたばかりの初学者にすぎません。

自分と同様に、この分野に興味を持ち始めたWebやネイティブアプリのエンジニアが手をつけるとっかかりになればよいなと思います。


スタッフを始めとする関係者の皆様、お疲れ様でした&ありがとうございました!

RELEASE
2014.09.01

ホットペッパービューティーのデータを研究用に公開しました


こんにちは。9月1日でリクルートに入社して、4年目を迎えるATLのtatakabaこと高林です。そのような記念日に、リクルートオープンデータ第一弾として、 国立情報学研究所(NII)のご協力のもと、ホットペッパービューティーのデータを研究者向けに公開することになりました。

リクルートオープンデータの第一弾の取り組みになります。

手続き方法については、こちらを参照下さい。

公開する7つのデータセットは、以下の様な項目が含まれております。

店舗マスタ

美容室店舗のマスターデータになっております。店舗マスタには、以下のデータが含まれます

  • 店舗ID(全てのデートセットとヒモ付が可能です。)
  • 店舗名
  • 店舗名読み
  • 住所
  • 緯度/経度
  • 営業時間/休日
  • 店舗代表名/肩書
  • 店舗コメント
  • 店舗URL

スタイリストマスタ

スタイリストマスタでは、店舗の美容師データの情報を抽出することができ、 得意な技術などのデータが含まれます。

  • 店舗ID
  • スタイリストID
  • スタイリストキャリア
  • スタイリストコメント
  • 得意技術
  • 性別

レビューマスタ

掲載されたレビューデータを抽出することができます。

  • 店舗ID
  • レビューID
  • スタイリストID
  • メンバーID
  • ニックネーム
  • 性別
  • 世代
  • レビュー内容
  • ムードポイント
  • サービスポイント
  • テクニックポイント
  • メニューポイント
  • 総合ポイント
  • 投稿日付

ブログマスタ

店舗が掲載したブログを抽出することができます。

  • 店舗ID。
  • ブログID
  • スタイリストID
  • ブログカテゴリコード
  • タイトル
  • コンテンツ
  • 投稿日

クーポンマスタ

クーポンマスタは、掲載されたクーポンデータを抽出することができます。

  • 店舗ID
  • クーポンID
  • 提示条件
  • 利用条件
  • クーポン説明
  • クーポン名
  • 有効期限
  • 施術時間(目安)
  • 料金

メニューマスタ

メニューマスタは、店舗が提供しているメニューリストを抽出することができます。

  • 店舗ID
  • メニューID
  • 価格
  • 時間

セットメニューマスタ

セットメニューマスタは、店舗が提供してるセットメニューリストを抽出することができます。

  • 店舗ID
  • セットメニューID
  • メニュー名
  • 価格
  • 時間

リクルートでは、これからもライフスタイルに関わる数多くのサービスのデータを 研究目的に活用していただこうと順次公開予定です。


NII

TAGS: ,

RELEASE
2014.08.29

Google Glassでポモドーロテクニック (3/3)


こんにちは、ATLでウェアラブルデバイスの研究をしている吉村です。今回は前回に引き続き、Androidで組み立てたプロトタイプをGoogle Glass実機へポーティングします。


エントリポイントの作成

これまでActivityを使用していたエントリポイントをServiceへ移動します。

Activityを削除し、Serviceから直接LiveCardの挿入/削除を行なうようにします。


src/main/java/com/gmail/altakey/myapplication/TimerService.java:


今度はLiveCardで表示するようになるのでActivityへBroadcastを飛ばしていたところをTimerCardの直接操作へ書き換えます。


最後にTimerServiceをAndroidManifest.xmlへ登録します。

src/main/AndroidManifest.xml:


タイムラインへの表示

先程さっさと使ってしまいましたがTimerViewで表示していたところをLiveCard化し、TimerCardとして切り出しておきましょう。

src/main/java/com/gmail/altakey/myapplication/TimerCard.java:


どうですか?TimerCardの実装とTimerViewの実装、似ていませんか?

TimerViewは削除します。


メニューの作成

Google Glassの場合、メニューを呼び出した際に下のActivityの動作を停止する必要があります。このようなことをするために、透明Activityを間に一枚入れてそこからオプションメニューを呼び出してやります。オプションメニューで良いんです。あとはGlassが標準の形で出してくれます。

src/main/java/com/gmail/altakey/myapplication/TimerMenuActivity.java:


こちらの定義もAndroidManifest.xmlへ加えておきましょう。

src/main/AndroidManifest.xml:


スタイルの定義はこんな感じに。

src/main/res/values/styles.xml:


ボイスコマンドの指定

あとはVoiceTrigger系のものをTimerServiceでハンドリングします。ここでは「START A WORKOUT」を使用します。

src/main/java/com/gmail/altakey/myapplication/TimerService.java:


voice.xmlにも指定します。

src/main/res/xml/voice.xml:


AndroidManifest.xmlにも指定します。

src/main/AndroidManifest.xml:


音の調整

GlassのMUSICチャンネルはヘッドフォン端子に向いているためそのままでは音が出ません。これでは困るので、NOTIFICATIONチャンネル(骨伝導トランスデューサ)を使うようにします。人に聞こえにくいという特徴を持つ骨伝導ですが、周波数が高いとかなり音漏れを起こします。クリック音が漏れると非常に耳障りなのでこちらの再生レートも落としてしまいましょう。カチッ、ではなくゴリッ、とした音になりますが格段に音漏れを低減することができます。


src/main/java/com/gmail/altakey/myapplication/TimerService.java:


完成!

ここまで来たらビルドして実機でテストしてみましょう。「Ok glass, start a workout」と言うとGlasswareが立ち上がりカウントダウンを始めたでしょうか。タップするとカウントダウンが一時停止してメニューが開いたでしょうか。そこからExitで終了できるでしょうか。


まとめ

以上、長かったですが簡単なポモドーロタイマーを作成してみました。環境構築から普通のAndroidでプロトタイピングして最後に一気にポーティングという進め方をして来ましたが、この方法はGlassが手元にない場合や触れる時間が少ない場合などにきっと役に立つのではないかと思います。ではまた。

TAGS: ,