読者です 読者をやめる 読者になる 読者になる

Japan Product Manager Conference 2016に参加してきた。〜アウトラインメモ〜

Japan Product Manager Conference 2016に参加してきました。

家庭の都合上、最後まで参加できなかったのですが当日とったアウトラインメモを残しておきます。中途半端なメモのところもありますがそこはご愛敬ということで。

※一部、私個人の解釈でメモしているものもあり、発表者の方の本来の意図とズレているものがあるかもしれませんがご了承下さい

アウトラインメモ

世界を変えるプロダクトマネージャーになるために

  • グーグル株式会社 徳生 裕人

政府そして製造技術開発会社を経て2005年にGoogleにプロダクトマネージャーとして転職した経緯等を通して、日本のインターネットビジネスを担うPMの皆様にメッセージを送れればと思っています。

内容

  • スタートアップでも大きな企業でもPMの役割は以下となる
    • User Problem
    • Technology Product Opportunities
    • Resource
    • Deliver
  • 8年間Product ManagerやったけどいまだにPMが何なのか分からない。 by SlackのPM
  • ベストプラクティスはないので色々なPMの意見を聞いて自分たちのチームにあったやり方を考えていくのが大事
  • 以下GoogleのPM達にインタビューして出てきた意見
    • オーナーであれ。"The buck stops here."
    • チームのシナプスであれ
    • 自分の計画、考えをきちんと周りに伝える、聞かれたらきちんと答える
    • ステークホルダーとの調整も大事。大きな会社だとより重要になってくる
  • 長い期間での成功をきちんと考える

ゼロから始めるPM生活

本セッションでは、ゼロからプロダクトを作り始める場合のプロダクトマネジメントについて、スタートアップやアカデミアで得られている知見を紹介します。

内容

  • 資料:ゼロからはじめるプロダクトマネージャー生活
  • PM = mini-CEO
  • Y Combinatorの知見を活かす
  • よく見えるアイデアだけでは急成長できない
  • 誰しもが狙うので他社とかぶることが多い
  • 悪いように見えて実はよいものを探すのが大事
    • 悪く見えるアイデアのほとんどは本当に単に悪い
    • 見極めるのが難しい
  • 難しい課題のほうが実は簡単
    • 採用が増えたり応援してくる人が増える
    • 誰も挑戦しない苦行なので競合がいなくなる
  • 今はまだ小さいけれど自分たちで独占できそうなマーケットを狙う
  • プロダクトの成功を考える=プロダクトでやらなくてもよいことを考える
  • 一部の人が愛してくれるようなサービスを作るとよい
  • 後々口コミ等でスケールする可能性がある
  • 最初にリリースするものがひどいものでもよい。とにかく早くローンチした方がよい
    • 最初にローンチしたものがひどいものではないのならそのリリースは遅すぎる
  • スタートアップはモメンタム(勢い)を死守するべき
    • モメンタムが落ちてきたと感じたらもう遅い
    • 価値は実行から生まれる
  • PMはいろいろやらないといけない
    • チームのボトルネックになりがち
    • Slack(ゆとり)を作ることが非常に大事
    • Noと言わないといけないことが多いので多少嫌われる
    • メンタルを維持するために精神論ではなく運動するべき
  • 量は質を生む
    • あきらめずに数をこなすことが重量
  • PMに必要はスキルセットはACT SOLID
  • Analytics, Communications, Trust/safety, Support, Ops, Legal, International, Design
  • 力を付けるためにサイドプロジェクトを起こしてそこで学ぶというのも1つの手

Product Team Management

  • Increments株式会社 海野 弘成

この発表ではProduct Managerとしてチームをどう作り、改善していくべきかをテーマに、Qiita:Team開発のために行ってきた様々なチームの分析や研究ノウハウを紹介し、また弊社でそれらをどう実践してきたかについてお話します。

内容

  • 資料:Product Team Management // Speaker Deck
  • よいチームとは
    • 成果が出せることが大前提
    • 自律的なチーム
      • メンバーの裁量
      • チームの後期
      • 情報共有
  • Googleの研究から心理的安全が大事だと言われている
    • 考えの表明ではなく、具体的な行動が必要
      • 分からないことがあればいつでも聞いてといいながら目を見て話していないとかダメ
    • 思いを流さず伝える場所が必要
  • 情報共有はHowよりもWhat、Whyが重要
  • OKRで目標管理

マイクロソフトによる「見える化」の民主化(Power BI 活用術)

本セッションでは、Power BI を使った現実的な利用シーンを想定し、その可能性を紹介していきます。 もちろん、マイクロソフトのプロダクトマネージャーが、日々の業務の中でどのように Power BI を利用しており、なぜ今回皆様に紹介しようと思い至ったのかも簡単に紹介いたします。

内容

  • マイクロソフトのPMにあたると思われるロール
    • Business Group
      • Product Marketing Manager
      • Technical Product Manager
    • Engineering Group
      • Program Manager
  • 何をやるにも客観的なデータの提示が必要
    • 売り上げ状況の説明、ステークホルダーへの説明などデータを提示することが重要
    • そこでPowerBI
    • PMはレポート作成をPower BIに任せて他の業務に集中しよう

大規模システム開発におけるプロダクトマネージメントについて

過去多数のプラットフォームを開発指揮してきた経験から、組織・チームを破綻させること無くプラットフォーム開発を成し遂げられたヒントとその中で感じた課題をお話します。

内容

  • プラットフォーム開発の特徴
    • エンドユーザーが直接利用することが少ない
    • サービス開発と違いユーザーの利便性などが直接分かるわけではないのでマーケティングしにくい
  • プラットフォーム開発でのPMの役割
    • バラバラの機能がどこの何に活きてきているのかをきちんと伝える
    • その機能が事業にどのように貢献しているかをきちんと伝える
    • 各チームがそれぞれ意味があるということをしっかりと周りに伝えることが大事
      • 特にマイクロサービス毎にチームを分けている場合は
  • 事業をなぜやっているかという疑問が生じたら徹底的に説明する
    • なぜ、何のためにやるのか、ミッションは何なのか
    • チームで目指しているものを一致させる
    • 思いを言語化して相手に伝えないとほとんど伝わらない
    • 迷いがなくなると人は強くなれる

絶対失敗すると言われたプロダクトを成功させること

  • freee株式会社 佐々木 大輔

内容

  • freeeで最初苦労したこと
    • 新しい会計ソフトとか覚えたくない
    • クラウドである必要を感じない
    • 自動で入力するとかいらない。早く入力できるようにしてほしい
  • 強みをつくる
    • 機械学習による勘定科目の自動振り分け (特許取得済み)
  • キャズムを作る
    • 狙っているセグメントの人にどんどん使ってもらう
    • 夕刊紙に「freeeの登場により日本から税理士が消える」という記事がのる
      • これで一気に問い合わせがきた
  • ユーザーが増えてくると全部の要望を聞き入れることが難しくなってくる
    • 最初の内は一般的な要望が多いがそうではなくなってくる
    • なぜその要望が必要なのかを徹底的に掘り下げていく必要がある

現役23名のPM:タイプ別マネジメントパターン

社内では現役23名もの開発責任者(プロダクトマネージャー)が切磋琢磨しつつ、さまざまな課題に立ち向かっています。23人23色のやり方の中から見えてきた、タイプ別マネジメントパターンをいくつか紹介します。

内容


毎日の料理のためのプロダクト開発

日々変わり続けるクックパッドのプロダクト開発。今、私たちが食や料理というジャンルの中でユーザーにどのような価値を提供しようと考え、それをどう開発で実践しようとしているか。PCからスマートフォン、ウェブとアプリの役割などプラットフォームの考え方、エンジニアやデザイナー、ディレクターなど各職種のスタッフがどう関わり意思決定しているかなど含め、これまでの変遷や具体的な開発の事例を交えて話します。

内容

  • デザイナーを全社横断組織にしたり、ひとつの組織にしたりいろいろ試している
  • 今はiOSAndroidのアプリで主要機能を分けるという試みをしている
    • iOSはレシピの投稿機能が強い
    • Androidはレシピの閲覧に強い
  • 使っている思考のためのフレームワーク
    • EOGS
    • サービス企画シート
    • リーンキャンバス
  • エンジニアと非エンジニアがお互いを補完できるような体制
    • エンジニアのオーナーと非エンジニアのオーナーを作る
    • サブチームにはディレクターを置いてその下にエンジニアやデザイナーが入る
    • 各オーナーはディレクターと連携を密に、さらに全エンジニア、デザイナーもフォロー
  • 課題と仮説をきちんと言語化する
    • SlackのTopicに書いておいて常に目がつくようにしている
    • 議論が必要なものはGitHubでissueたてて行っている
  • 目標とKPI定義
    • 部目標とチーム目標、メンバー目標がサービスのKPIとずれないようにする
    • 個人の目標は業務目標とスキル目標の2つ
    • 月1の1on1
  • 価値観の共有を大切にする
    • プロトタイピング合宿
    • イデアを出しやすいようにする
  • 世界観や方向感はオーナーが責任を持つ
    • 具体的な計画は開発者に任せている
    • オーナーは問題が出た際に正しい判断をする
  • 年に1回は全員外に情報発信してもらっている
    • 会社ブログの更新
    • イベントへの登壇

Product Manager という仕事

  • 楽天株式会社 齊藤 満

日本の会社である楽天トラベルに、PM というシステムの導入を取り組んできて、感じたこと、学んだこと、面白いと思う事、これからのチャレンジなんかをお話しします。

内容

  • Product Managerのマネージャーをやっている
  • PMはCenter of Communications
  • PMはそれぞれの組織で違うので分かりにくい
  • どんなに小さいプロジェクトでも、みんなで共有できるドキュメントを書く
    • なぜこのプロジェクトをやるのか、なんのためにやるのかを明確に
    • チーム内の意思を統一する
    • 楽天トラベルではこれをすることで5年間でエンジニアの数は変わっていないのに生み出すサービスが5倍近く増えた
  • まずは一番高い理想を目指す
    • 最初から現実的なところを目指してしまいがち
      • PMなら工数とかリリース期間等を考えて妥協するのではなくまずは自分の考える最高のものを提示するべき
    • 一番高いところを目指して足りない部分を落としていくという考えを持つ
  • 世界をもっと考える
  • 日本だけで考えるのは視野を狭めてしまう
  • アメリカが強いのは世界中から人が集まっているから
  • 違う文化の人の考えを取り入れるように意識する

プロセスからプロダクトへ

  • David Hussman

内容

  • devjam studoisというのをやっている
  • プロダクトチームの3つパターン
    • 1プロダクト1チーム
    • 1プロダクト複数チーム
    • 複数プロダクト複数チーム
      • 大きな会社だとプロダクトとは言わず、システムと言うことが多い
  • プロダクトコミュニティを作るようにする
    • ディスカバリーとデリバリーを混ぜる
    • 開発者もペルソナ作成、カスタマーインタビューを行う
    • ソフトウエアエンジニアという名前をプロダクト開発者に変えてみた
  • インパクト駆動開発
    • コードの量産よりもプロダクトの検証
    • 開発を始める前に作るものがどう顧客にインパクトを与えるかを考える
  • プロセスよりもプロダクトを大切にする
    • プロセスをおろそかにするわけではない。プロセスはきちんと回しつつプロダクトのことをきちんと考える
  • この本を出すので読んでほしい

エンジニアがプロダクトマネージャーに進化すると何が起きるのか

サイバーエージェントのアドテクスタジオにおいて実際にプロダクトマネージャーとして働いている具体的な業務内容と求められている成果、もしくは狙いたい成果をお話します。 同時に現場におけるプロダクトマネージャー業務と自分自身が思うギャップやジレンマについてもお話します。

内容

  • チームマネジメントも技術
  • チームフォーメーションを強く意識している
    • 戦略的に配置換えなどを行っている
  • 依存関係を構造化し、優先度が高くクリティカルなものから取り組む
    • 作らなければいけないもの、作らなくてもよいもの
    • 社内、社外と交渉が必要なもの
  • 事業運営にも技術を
    • 報告用レポート生成を自動化
    • 事業報告(売り上げとか、ユーザー数の報告)もbotで行う

グローバル企業におけるプロダクトマネージメント

  • Niantic, Inc 河合 敬一
  • Increments株式会社 及川 卓也

パネルディスカッション形式でNianticプロダクトマネジメントにせまる

内容

  • Nianticの開発体制
    • 今は約70名、エンジニアがほとんど
    • 開発拠点はGoogle時代を引き継いで結構分散している
    • Googleの社内インフラは一切つかってない。顧客としてGCP使っている
  • Pokemon GOを支えるPM
    • 共通の価値観をチーム内でどう持つかが大事
    • 会社を作った人の想いをきちんと引き継いでメンバーに伝えていくのが大事
    • 発見は日常にたくさん埋まっていて、それをテクノロジの力で見つけられるようにしたい
    • Googleの時は、大きい組織/事業なので考えることが多かった、Nianticは目の前のプロダクトに集中できるのでPMはやりやすい
  • PMが業務を回していくコツは?
    • 仕組みを作るのが大事
    • 今のクオーターと次のクオーターで同じ事をやっていたら負け
    • 変化の仕掛けを作るのが大事
    • PMが定常的な仕事をしていたら負け
    • 他のメンバーで回るようになったら次に行く
  • Pokemon Goはテスト時のネガティブな状態からどうたち直したのか?
    • フィールドテストの評価はひどいものだった
    • でも出して試してもらわないといけないので出した
    • 叩かれても貴重な意見に変わりない。エンジニアにどう伝えるかは考える必要がある。ただの文句なのか、大事な意見なのかはPMが切り分けて伝えている
  • PMの立ち回り
    • 技術の会話が出来てエンジニアからもリスペクトされた方がよい
    • 知ったかぶりを貫き通すのも技術。もちろん基本的な知識は身につける必要がある
    • メンバーの好みを知る。モチベーションを上げる方法を知っているか
    • 焼き肉に行く
  • PMとエンジニアの関係性
    • ボトムアップでエンジニアがオーナーシップを持っているのが理想
    • エンジニアが作業に意味を見いだせないといけない、自ら問題提起ができないといけない
    • どうしてもエンジニアが決定できないことがあるときはPMが入って決める。No Dicisionは本当にダメ
    • ジョブズみたいな独裁的なパターンが出来る人はごく少数
  • PMとしての能力開発
    • チームの信用を得ることが大事
    • きちんと製品、サービスを世に出すというのが実績/評価につながる
    • 力を付けるのは自分でやってみるしかない、OSSでも小さな社内プロジェクトでもなんでもよい。座学だけでは力はつかない

メルカリ流グローバルなプロダクトマネジメント

  • 株式会社メルカリ 伊豫 健夫

JP/US/UKと三カ国にサービスを展開するメルカリの、グローバルなモノづくりの実態について公開。プロダクトマネジャーの役割は?多国間のコミュニケーションと意思決定は?メルカリ流の創意工夫についてのお話です。

内容

  • 今はプロダクトチーム全体の90%をUSに割いている
    • 大量の機能追加、改修案件が可能
    • 組織として、個々人の行動レベルにおいても迷いがなくなりUSに集中できる
  • 達成目標にはOKRを採用
    • シンプルに目標を立てるようにする
    • チーム全員が全社で目指しているものを同じ言葉で話せることが大事
    • PMがチームメンバーのKRに対しての全責任を負う
  • メルカリのPM
    • リーダー的なこともやるし、自分で手を動かすこともある
  • 課題は全てRedmineで管理
    • チケットがないとリリースできない
  • リリース後の分析
    • 自分でSQL叩くことが前提
    • Chartio使っている
  • チームをコーディネートする時のポイント
    • オープンコミュニケーションを心がける
      • メルカリではSlackのPrivateチャンネル禁止にしている
    • 必要な情報は自分から取りに行く
    • 自発性を重視
      • それぞれの得意分野を知り任せる
  • メルカリで活躍するPMの特徴
    • ものづくりへの理解
    • ユーザ理解と多くに引き出し(アンテナが高い)
    • 自走力(課題発見から解決まで自らの手を動かせる)
    • いくら優秀なPMがそろっていても、組織そのものがプロダクト中心の思考になっていないと意味がない
  • 阻害要因への対応方法
    • 余計な説得をなくす
      • 承認会議をなくす。打ち合わせは週に1.5時間程度。この中で意思決定を行う。
      • 全社マネージャー会議も無くした。現場のマネージャーに権限委譲
        • 社長には議事録をSlackで送るだけ  
    • 余計なツッコミをなくす
      • 他のチームが口を挟んできても担当チームの意見を優先
      • とはいえ、PMは状況をみて調整する必要がある

自分が見てきた Product Manager

  • クービック株式会社 倉岡 寛

Google -> GREE -> Coubic と、Product Manager としてのキャリアを通じて、プロダクトの企画・開発・マーケティング・営業・PR 等と横断的にプロダクトに携わってきている中、いかにユーザーに愛されるプロダクトを作ることができるのか、いかに周りを巻き込みながら進めることができるのか等など、日々感じていることを経験交えながらお話できればと思います。

内容

  • PMは権限はないけど責任はある
    • 権限があったとしてもそれを振りかざすことをしてはいけない
  • 顧客と話せ
    • 自分のやりたいことと顧客のやりたいことのバランスを考える
    • ただ聞くだけではなく顧客の痛みをちゃんと理解する
  • とりあえず行動する
    • 行動しないと何も起きないし、スケールしない

“Team in Center”のプロダクト開発

端末メーカーであるソニーバイルのXperiaにプリインされ、数多くのお客様に使っていただいているアプリケーション(プロダクト)の開発をご紹介させていただきます。 どのようにユーザに愛されるアプリを開発しているか、またその開発チームを、どのようにチームビルディングしているのか。プロダクトオーナーとしての工夫はなにか。いくつかのポイントや学びを共有させていただきます。

内容

  • Team in Center
    • 企画と設計が離れているのはよくない
    • プロダクトに皆が責任を持つようにと設置された
  • Movie Createrの事例
    • Xperia Z3からプリインされている
    • チーム全員(dev含む)でユーザーストーリーを考えた
      • 他アプリを使い倒したり、普段動画撮らない人も動画を撮ってユーザー視点になる
      • 使用するユーザーがどんな人かを常に意識する
    • イデアを出してみんなで投票
      • 全員が意思決定しているという雰囲気作り
    • プロトタイピングして社内ヒアリングして精度を高める
    • チームが主体的に動くようになっていることが大事
  • Albumの事例
    • Xperiaにプリインされている写真閲覧アプリ
    • チームビルディングで山登りした
      • 性格が把握できる(先に行っちゃう人とか)
    • チームビルディングで原宿へ
      • 若者の文化を知る
    • ワークショップしてメンバーの想いを一つにする

感想

最近何かと話題になるプロダクトマネージャーについていろいろと知ることができました。一般的な話から、登壇者の方々が実際にどのような取り組みをしているかを知ることができ自分の幅をかなり広げることができそうです。

今の会社でプロダクトマネージャーという職種になれるかというとそういうわけにはいかないので、自分の持っているいくつかの小さなプロジェクトに今回学んだノウハウをいくつか取り入れて実践していきたいですね。

プロダクトマネージャーを担当する上でのベストプラクティスはないので自分のチームにあった方法を模索していくしかないという大前提があるのですが、登壇者の方々の話を聞いているとプロダクトマネージャーとして大事なポイントはだいたい以下に集約されると感じました。

  • メンバーそれぞれが自走できるようにする
    • なぜそれをするのか?何のためにするのか?をきちんとメンバーが考え続けることができるように
    • チームの想いを統一する
    • 会社の目標、チームの目標、個人の目標をきちんと結びつける
  • 言語化
    • 考えていることはきちんと文字にしてメンバーに共有する
    • できる限りオープンにして議論する
  • ユーザーのことをきちんと理解する
    • 開発者もペルソナ作成、カスタマーインタビューを行うなど
    • 自分もユーザー視点になる 
  • 信頼を得る
    • 最低限の実績は必要
    • 小さいプロジェクトでもよいので経験を重ねていく
    • 焼き肉行く
  • 担当プロダクトへのアツい情熱

全体的に最高なイベントでした。普段なかなか時間をとってこのような内容を考える機会がないので本当にいい刺激になりました。

運営の皆様ありがとうございました!

12/15 追記

公式ページに資料まとめページができています。

公開資料まとめ | プロダクトマネージャ―カンファレンス 2016

Vagrant上のUbuntuにRabbitMQをたててMQTTをお試し

MQTTがだいぶ流行ってきている感がある今日この頃。 仕事上でもちょっと触る必要がでてきたのでちょっとメモっておきます。 MQTTについてはこちらの素晴らしい記事で確認して下さい。

今回はとりあえずちょっと試したいのでブローカーサーバーとしてRabbitMQを使うことにしました。

Vagrantの準備


Vagrantのインストールとか使い方は至る所に記事が転がっているのでそちらを参照して下さい。

とりあえず今回はHashicorpが提供しているubuntu/trusty64を使っています。

あと、同一ネットワーク内の様々な機器からアクセスしたいのでVagrantのネットワーク設定はPublic Networkにしておきます。

私はMacWi-Fiで接続しているので以下のような設定をVagrantfileに追加しておきます。

config.vm.network "public_network", :bridge => "en0: Wi-Fi (AirPort)"

あとはいつもどおり、vagrant upvagrant sshでサーバーに接続しましょう。

RabbitMQのインストール


細かいことは公式ページに書いてあるのでこちらを見ればいけるかと思います。

私の行った作業をメモがてら残しておきます。

まず、RabbitMQのインストール。

sudo apt-get install rabbitmq-server

次にMQTTの有効化。

sudo rabbitmq-plugins enable rabbitmq_mqtt

実行結果。

vagrant@vagrant-ubuntu-trusty-64:~$ sudo rabbitmq-plugins enable rabbitmq_mqtt
The following plugins have been enabled:
  amqp_client
  rabbitmq_mqtt
Plugin configuration has changed. Restart RabbitMQ for changes to take effect.

Webインターフェイスの有効化。

sudo rabbitmq-plugins enable rabbitmq_management

実行結果。

vagrant@vagrant-ubuntu-trusty-64:~$ sudo rabbitmq-plugins enable rabbitmq_management
The following plugins have been enabled:
  mochiweb
  webmachine
  rabbitmq_web_dispatch
  rabbitmq_management_agent
  rabbitmq_management
Plugin configuration has changed. Restart RabbitMQ for changes to take effect.

RabbitMQ Serverをリスタートします。

sudo /etc/init.d/rabbitmq-server restart

起動しているか確認しましょう。 Erlang/OTPのプロセスはbeamで動きます。

vagrant@vagrant-ubuntu-trusty-64:~$ sudo netstat -anp | grep beam
tcp        0      0 0.0.0.0:15672           0.0.0.0:*               LISTEN      2328/beam
tcp        0      0 0.0.0.0:55672           0.0.0.0:*               LISTEN      2328/beam
tcp        0      0 0.0.0.0:47761           0.0.0.0:*               LISTEN      2328/beam
tcp        0      0 127.0.0.1:34940         127.0.0.1:4369          ESTABLISHED 2328/beam
tcp6       0      0 :::1883                 :::*                    LISTEN      2328/beam
tcp6       0      0 :::5672                 :::*                    LISTEN      2328/beam

動いていますね。

1833ポートがMQTT、15672ポートがWebインターフェイスとなります。

ホスト側からWebインターフェイスにアクセスしてみましょう。

f:id:braitom:20150513145007p:plain

繋がりますね。

初期アカウントはguest/guestとなります。

f:id:braitom:20150513145011p:plain

コンソールに入れました。

これでインストールは完了です。

ブローカーサーバーに繋いでみる


さてRabbitMQが立ち上がったのでMQTTで接続してみましょう。

せっかくなのでiPhone6から使える気圧センサーの情報をPublishしてみることにします。 Subscribe側はどこでも動くように今回はPythonで書いてみます。

Publish側(iOS)

今の時代はSwiftなのでSwiftで実装します。 MQTTライブラリとして以下を使用します。

コードは以下にありますのでご確認下さい。

実際にPublishしているのはこの部分です。

self.mqttClient.publishString("\(currentTime): \(pressure)", topic: "test/iOS", qos: 0, retain: false)

Topic名は、”test/iOS"、QoSは0(最高1回。届くかは保証しない。)、Retain(メッセージをMQTTサーバーが保持)はfalseにしてあります。

Subscribe側(Python)

ライブラリは以下を使用します。有名なやつですね。

pipでサクッといれましょう。

pip install paho-mqtt

コードはこんな感じになります。サンプルなのでただコンソールに出力するだけです。

MQTT subscribe sample

ポイントとしてはsubscribeするTopic名(今回は、"test/iOS")をPublish側と合わせることくらいですかね。

実行

まずSubscribe側を実行しておきましょう。

$ python subscribe_mqtt.py
Connected with result code 0

これでブローカーサーバーに繋がりSubscribeの準備はできています。

次に、Publish側を起動しましょう。

これで気圧情報をガンガンPublishし始めます。

f:id:braitom:20150515170104p:plain

Subscribe側を見ると情報が届いているのを確認できるかと思います。

f:id:braitom:20150515165931p:plain

まとめ


このように比較的簡単にMQTTをお試しすることができました。 MQTTを実際に使うには、切断検知や再接続方法、セキュリティ等を使用用途によって考えなければなりませんが、なかなかシンプルで良いプロトコルだと思います。 今後も情報集めていきたいですねー。

疲れた時にBotに癒してもらおう

前置き

作業中ちょっと息抜きしたいときってありますよね。そんなときは何故か戸田恵梨香さんを見たくなるのは私だけではないはず。

疲れているときはキーボードで文字入力するのも面倒なので楽に戸田恵梨香さんを見たいものです。

そんな時に便利なのがRingです。

届いた時にちょっと試して精度とかが全然ダメだったので使えねーとしばらく眠らせていたのですが、久々に触ったらやっぱ結構面白いかも?と個人的に感じたので、ちょっとしたデモを作ってみました。

ちなみに新型ももうすぐ出るみたいですね。300%精度が向上したということなので試しに予約してみました。さてどうなることやら。

仕組み

仕組みはいたって簡単です。

  1. 画像を検索するWebサーバーを立てる
  2. Ringでのモーションに上記のサーバーのURLをOpen URLで指定
  3. ジェスチャーを実行するとSlackの特定のチャネルに戸田恵梨香さん画像を投稿

たったこれだけ。

使い方

  • SlackのTokenを取得します。取得方法ついては自分でググって下さい。
  • サーバー側はこちらに置きました。

    Ring2Slack

  • デプロイ方法等はREADMEを読んで下さい。Heroku Buttonを置いておいたのでそのままHeroku上へもデプロイできるようにしておきました。
  • あとはRingのアプリからOpen URIでデプロイしたURLを指定すればOKです。 こちらのRingのページを見れば分かると思います。
  • あとは指定したジェスチャーを行えばSlack上に画像が投稿されます。

所感

まあぶっちゃけ現行のRingは精度悪すぎワロタ状態なのでジェスチャーを認識させるのも一苦労で逆にストレスがたまります。これは新型に期待。あとつけ心地悪すぎ。デカすぎます。これを普段着けておくとか無いっすわ。

とは言え、簡単なジェスチャーでWeb APIと連携できるようになるのはやはり素敵。Hueとかと組み合わせれば電気の点灯、消灯もジェスチャーでできるし、IRKitとか使えばTVのオン、オフもできますよね。

自前スマートホームを作りたいと思っているので、簡単な操作を何で行うのが良いのか個人的に考えている中で、音声認識よりはジェスチャーによる操作の方が性にあっていると感じたのでRingで遊んでみました。

さいごに

いろいろ述べてきましたが、言いたかったことは次の2点です。

  • ウエアラブルなジェスチャーコントロール端末に期待
  • 戸田恵梨香かわいい

f:id:braitom:20150323172438p:plain

Slack×Hubot×GitLabでレビューを効率化しよう

この記事はSlack Advent Calendar 2014 - Qiitaの22日目の記事です。

内容

チーム内でのちょっとした開発にはGitLabを使っているのですが、MargeRequest(以下MR)を投げた時にレビューを効率化するためにの方法を説明したいと思います。

Slack導入以前

別にMRが発生したらメールを投げればいいのですが、メールだとすぐに見ないことも多いのも事実。 そこで、Slackを入れる前はMRが起こるたびにYoを送ってMRが飛んだよーということを気づかせるようにしていました。

ちょうどYoが無駄に流行っている時期でもあったし、Yo APIもあったのでしばらくこれでしのいでいました。

そのとき作ったのがこれです。

Flask-yo

しかし、最初のうちは楽しくてみんな反応していたのですがだんだんと反応しなくなりました。結局Push型でみんなにYoが行くので、誰かレビューするだろ?ってなっちゃうんですよね。

Slackの導入

チーム内のコニュニケーションを円滑にするためにSlackを導入しました。 Slackいいですよね。チーム内のコニュニケーションがかなり活性化されたと思います。 業務中はだいたいのメンバーはSlackに常駐しているのでGitLabのMRもこっちに流そうと思いました。

やりたいこととしては以下となります。

  • MRが飛んだらMRのタイトルと内容とリンクを特定のチャネルに通知
  • 合わせて、@でランダムでレビュワーを割り当てる
    Slackの通知をスマートフォンアプリでも

これによりMRがいつ飛んだのか、誰がレビューするべきかを明確にします。

導入準備

まず今回試しているGitLabのバージョンは「GitLab 7.4.3」となります。

  1. SlackにHubot Integration
    まずはこれが必要です。ちょうどちょっと前にSlack APIのアップデートがあり以前とちょっと方法が変わっています。 すばらしいことにSlack Advent Calendar 2014の4日目にKeitaMoromizatoさんがこの新しいIntegrationの導入方法の記事を書いてくれていますので詳細はこちらを参照して下さい。
    SlackのHubot Integrationが知らぬ間にアップデートされてた
    また、hubot-slackもバージョンアップされておりこれによりプライベートチャネルにもHunotが常駐できるようになりました!素晴らしい!これが出るまではXMPP経由でHubotの設定をしなくてはならず若干面倒くさかったのですよね。。。

  2. Hubotの用意
    様々な記事があるようにHerokuに立てるのが一番楽だと思います。これも参考になる記事がいくつもあるので以下をご参照下さい。他にもググれば参考になる情報がたくさんでてきます。
    slackにHubotを導入(Heroku経由)

  3. GitLabの設定
    スクリプトを作成する前にGitLab側の設定を行いましょう。GitLabにはWebHookの機能がありますのでこれを使用します。
    設定したいプロジェクトの「Setting」→「WebHook」を選択します。

f:id:braitom:20141222133302p:plain

ここを見てもらえると分かるのですが、GitLabでは以下のタイミングでWebHookを使うことができます。
・Push events
・Tag push events
・Issues events
・Merge Request event

今回はMRだけ取りたいので「Merge Request event」にチェックを入れます。そしてURLにはリクエストを送る先のURL(Hubotが動いているURL)を入力して「Add Web Hook」を押します。
もちろんMR以外のイベントもHookして取り回したいという場合はスクリプト側でハンドリングしてあげればOKです。

スクリプトの作成

まずスクリプトの全体は以下となります。これをHubotのscriptsフォルダにおけばOKです。

hubot-gitlab mearge request review

特に難しいことはしていません。ポイントを解説すると、

Slack APIを直接たたいている

hubot-slackを使えば楽ちんなのですがHubotからSlackへ投稿すると@(メンション)と#(チャネル)はデフォルトでリンクとなりません。 こんな感じにただのテキストとして扱われてしまいます。これだとメンション扱いにならないので気付かずにスルーしてしまいそうですよね。

f:id:braitom:20141222134330p:plain

この辺のSlackの仕様は以下のリンク先で確認して下さい。

Slack API Message Formatting

今回は@できちんとメンションとして通知したいという目的がありますのでこの方法でいきました。

4行目のBASE_URLでSlack API Tokenを設定しています。

BASE_URL = 'https://slack.com/api/chat.postMessage?token=xxxx-xxxxxxxxx-xxxxxxxxxx-xxxxxxxxx-xxxxxxx' #replace your Slack API key!

44行目のurlの一番最後に&link_names=1を付与しています。これにより@がきちんとメンションとして機能するようになります。

url = BASE_URL + 'channel=' + channel + '&text=' + encodeURIComponent(message) + '&link_names=1'

レビュアーのランダム化

Hubotのrandom関数を使うようにしています。

random = require('hubot').Response::random

使い方は簡単です。36行目です。

assignee = random members

これでassigneeに6行目のmembersで定義したメンバーがランダムに入ってきます。

GitLabからのHook先

hubotにはrouterの機能があるので指定したURLにPostが来たときの動作を書くことができます。14行目ですね。

robot.router.post '/hubot/gitlab', (req, res) ->

これでhttp://HubotのURL/hubot/gitlabにPostが来た時にこの関数が呼ばれます。 つまりこのURLを上で述べたGitLabのWebHook設定時のURLに指定するわけです。

GitLabからのHook内容をハンドリングする

これは21行目〜24行目で行っています。GitLabが実際にどのようなJsonを送ってくるかは以下を参照して下さい。

GitLab Web hooks

※このJsonの内容はGitLabのバージョンによって変わってきますのでお使いのGitLabのバージョンのドキュメントをきちんと確認して下さい。

Pushでも反応させたい、MRクローズ時も反応させたい等の機能はここを書き換えることになります。

まとめ

この状態でMRが飛ぶと以下のようにメンション付きでbotが教えてくれます。

f:id:braitom:20141222134853p:plain

この方法でMRをレビューすることで前より効率がよくなった気がします。あと、おみくじ的な感じでなかなか面白いです。(また俺が担当かよー!みたいなこともありますが。)

今後もいろいろ改善していきたいですね。よいSlackライフを!

iBeaconで濡れしらず

この記事はおうちハック Advent Calendar 2014 の18日目の記事です。

お題目

外出してから雨が降ってきて、「傘がない!」という経験がある方は多いと思います。 天気予報を見る習慣がある方はいいのですが無い方もそれなりの数いると思います。

こんな悩みを解消しよう!というのが今回の目的です。

ちなみにこのコンセプトのプロダクトは実はもう既に世の中には存在しております。

KickStarter案件だとairfy Beaconというプロジェクトが存在しています。 日本国内だと最近、そら用心というものがリリースされて一部の間でちょっとした話題となっております。

こういったものを自分でも比較的簡単に作れるよ!というのを知ってもらうのも目的であったりもします。

使用する技術要素

今回はAppleのiBeaconを使用します。私の知っている範囲だとiBeaconを決済のものと思い込んでいる方も世の中にはまだそれなりにいるようなので、こういう使い方をするものなのだよということを示したいのでiBeaconでやってみました。

iBeacon自体の詳細は今回は述べません。ググればたくさんヒットすると思いますのでそちらを参照して下さい。

一つだけお勧めするとしたら以下の書籍です。非常に良くまとまっているのでこれを読んどけば大体は分かるかと思います。

使用する機器

  • 以下のいずれかのiOS搭載デバイス
    ※なお今回のサンプルはiOS8以降での動作を確認しております。動作させるためには端末のBluetoothがONになっている必要があります。

  • Beacon
    Beaconを自分で用意する必要があります。昨今けっこういろいろと出てきているので、「iBeacon モジュール」とかで検索してみて自分の好きなモノを選んで下さい。電波強度が調整できるものを選択した方が良いです。以下にいくつか紹介しておきます。

実装

今回はObjective-Cで実装します。気が向いたらSwift版のサンプルも用意したいと思います。

天気情報の取得ですがいくつかのサービスがAPIを提供しています。有名どころで言うとlivedoorのお天気Webサービスでしょうか。 今回は傘を持っていくかどうかを知りたいので降水確率が欲しいです。しかしlivedoorAPIは降水確率が取得できません。他のサービスも調べてみると降水確率が取得できるものが全然ありません。

そんな中見つけたのがこれです。

1分間に10リクエスト、一日で500リクエストまでは無料とのことなのでこれを使うことにしました。

※予報の情報が正しいかは保証できません。ちょっと試している限り問題無いとは思うのですが。。。もっと降水確率の精度を求めるのならば気象庁の予報ページとかをスクレイピングして情報を取得するのも手かもしれません。

ソースコードの全体は以下に上げてありますのでこちらをご覧下さい。

UmbrellaNotifier

動作確認

  1. まずはBeaconを玄関の隅の方に置きます。
  2. アプリを端末にインストールして玄関に近づきます。
  3. 今日は傘を持っていくべきかどうかを通知してくれます。

f:id:braitom:20141218004910p:plain

f:id:braitom:20141218010024p:plain

さいごに

このように比較的簡単に目的のものが作成できました。iBeaconを使うと他にも、「家に帰ってきたらhueのスイッチをONして電気を付ける」とか、「IRKitを使ってTVとエアコンのスイッチをオン」とかも今回の応用でできます。

みなさんも是非いろいろなおうちハックをしてみてはいかがでしょうか?

補足

  • Beaconの設定とか細かいことは購入した製品の説明書をお読み下さい。
  • このサンプルはiBeaconによる降水確率の通知にのみ焦点を当てています。CoreDateのベースだけ作ってあるので通知情報を保存したい場合はそのように実装し直して下さい。(つまり細かい実装をサボりました。。。すいません。必要あれば言って下さい。)
  • サンプルだとBeaconのリージョンに入った時に情報を通知するようにしています。ですので、帰宅時も通知が来てしまいます。これを回避したい場合はリージョンの入出も管理して帰宅時は通知をしないように実装し直して下さい。

pod installでエラーが出るときの対応

pod installしたときに以下のようなエラーが出ることがある。

[!] The `master` repo requires CocoaPods 0.32.1 -

こんな時は、CocoaPodsをバージョンアップしてあげればOKです。

gem install cocoapods

無事アップデートされたら再度、pod installしてあげれば問題なく動くはずです。

Mac OSXのDockerを1.0にあげる

Docker1.0がリリースされましたね。

IT’S HERE: DOCKER 1.0

早速アップデートしたのでメモ。

古いBoot2Dockerをアンインストール

既に1.0より前のDockerを入れている人はbrew経由でDockerを入れているはずです。今回からインストーラーが提供されているようなので古いバージョンのものはアンインストールしておきましょう。

あれDocker入れてたっけな?という人は以下コマンドでBoot2Dockerが入っているかを brew ls コマンド確認しましょう。

入っていたらアンインストールしましょう。

$ brew uninstall boot2docker

Boot2Dockerのインストール

公式サイトからpkgをダウンロードしましょう。

boot2docker/osx-installer

あとはポチポチ押してインストールしていけばOK。

環境変数の設定

Docker1.0からDocker Serverのポート番号が「4243」から「2375」に変わっているようです。

各自の環境に合わせて、.zshrcなり.bash_profileなりを書き換えましょう。

export DOCKER_HOST=tcp://localhost:2375

動作確認

Boot2dockerのDocker VMをアップグレードします。 ターミナルで以下を実行すればOK。古いDocker VMの削除、新しいVMのダウンロード、init、立ち上げまで行っています。

$ boot2docker delete
$ boot2docker download
$ boot2docker init
$ boot2docker up

止めるときは、

$ boot2docker down

念のためdockerのバージョンを確認しておきましょう。

$ docker version
Client version: 1.0.0
Client API version: 1.12
Go version (client): go1.2.1
Git commit (client): 63fe64c
Server version: 1.0.0
Server API version: 1.12
Go version (server): go1.2.1
Git commit (server): 63fe64c

上がっていますね!

あとはDockerを今までどおり使いましょう。

さいごに

ついにDockerも1.0がでましたね。今後のコンテナ型の仮想化が流行っていくことを期待しましょう。

ちなみに、より詳しい手順は公式サイトを見てください。

Installing Docker on Mac OS X

このサイトでは、

$ boot2docker stop
$ boot2docker download
$ boot2docker start

と書いてありますが、boot2dockerのヘルプを見ると、「start」は「up」、「stop」は「down」が正式なのかな?と思いこの記事ではupとdownを使っています。