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

Visual Studio 2017のテーマを変更する

Visual Studio

Visual Studio 2017のテーマを変更する方法です。

正直、Visual Studioを真面目に使うのはVisual Studio 2012以来です。 実に5年ぶりです。 デフォルトダークなテーマがあったりとだいぶイケてる感じになっていて満足しています。

しかし、なんかコードが見づらい感じがしたので変更することにしました。

設定方法は特に難しいとことはありません。 以下のサイトでいろいろなテーマが公開されているので好きなものを選んで入れればOKです。

設定方法

具体的な手順に入っていきます。

テーマの選定とダウンロード

こちらから好きなテーマを探します。

私は定番のMonokaiを使うことにしました。

注意点としては「Visual Studio 2015」を選択した上でダウンロードすることです。今回Visual Studio 2017に適用しますが2015のものでも問題なく適用できることを確認しています。

f:id:braitom:20170316225850p:plain

テーマをVisual Studioにインポートする

  1. [ツール]>[設定のインポートとエクスポート]と進んで[設定のインポートとエクスポート ウィザード]を開く

  2. [選択された環境設定をインポート]を選択して[次へ]

  3. 現在の設定の保存画面になるので、現在の設定を保存するか上書きするかを選択して[次へ]

  4. インポートする設定コレクションの追加画面になるので、左下の[参照]から先ほどダウンロードしたテーマ(xxxxx.vssettings)を選択してインポートする

たったこれだけです!

おまけ

フォントも変更するとさらにいい感じになります。

[ツール] > [オプション] > [環境] > [フォントおよび色] > [フォント]から変更できます。

お勧めは、「Consolas」です。

さいごに

Before、Afterを見てみましょう。

Before f:id:braitom:20170316231625p:plain

After f:id:braitom:20170316231642p:plain

いい感じですね。

Windows 10の開発環境作り(2017年春編)

Windows

もう3月も半ばですね。気分はもう春です。

春ということで気分を切り替えるために、久々にまじめにWindowsを使ってみることにしました。 そのため環境構築まわりで何をやったのかをメモがてら残しておくことにします。

ちなみにこのマシンを買いました。

HoloLensアプリの開発もしたいのでGPUが欲しかったのでどうせならとGTX 1080積みました。とりあえずメモリも32GBに盛っておきました。

開発系

Chocolatey

Windowsのパッケージマネージャーです。 MacでもHomebrewに依存しまくっていたのでパッケージマネージャーがないとツラいので。

GUIで管理できるものもあるので入れたい人は入れておくとよいと思います。

Bash on Ubuntu on Windows

導入方法は以下の記事が分かりやすいと思います。 簡単にいうと、機能の有効化でWindows Subsystem for Linuxを有効にして開発者モードをオンにすればOKです。

Macと同様、zshを使いたかったので入れます。

$sudo apt-get install zsh

起動確認。

$zsh

デフォルトシェルをzshにするためchshコマンドで変更しようとしたのですがうまくいかないみたいです。 bash.exeを起動してもデフォルトzshになりませんでした。

しょうがないのでbashrcに以下を書いてbash起動時にzshを起動させます。

# Launch Zsh
if [ -t 1 ]; then
exec zsh
fi

これでbash.exeを起動したらデフォルトzshが使えるようになります。 Oh My Zshもそのまま使えました。

Maczshrcをそのまま使えるので楽ちん。

cmder

シェルです。 昔はConEmu - Handy Windows Terminalを使っていたが今の時代はこのcmderの方がイケてるらしいのでこっちを入れました。
複数タブを開ける、開くシェルの種類を選べる、テーマとフォントも色々と設定できるのでこれで問題無さそう。

設定したBash on Windowsを簡単に使えるよう設定しておきます。

  1. 「メニュー」>「setting」を選択
  2. 左サイドバーの「Startup」>「Tasks」

「+」を押して以下のように入力してます。

  • 名前: Bash::Bash on Ubuntu on Windows
  • Task parameters: -icon “%USERPROFILE%\AppData\Local\lxss\bash.ico”
  • commands: C:\Windows\System32\bash.exe ~ -cur_console:p

f:id:braitom:20170314234405p:plain

これでcmderから簡単にbash.exeが起動できます。

JavaScript関係

nvm

nodeはバージョンを切り替えてがちゃがちゃと試したいことが多いのでChocolaty経由で入れずにnvmを使います。 最近はWindows用のnvmとかあるんですね。

Macではnodebrewを使っていましたがnvmでも同じことができるので問題無いです。

Yarn

今の時代、特にデメリットも無いのでYarnを入れておいた方がよいので入れます。

インストーラーもありますがChocolaty経由でインストールできるので楽ちんです。

Python

PythonはChocolaty経由で入れました。

以下のコマンドで3系が入る。

choco install python

2系は以下で。

choco install python2

その他いろいろ

alt-ime-ahk

その名前とおりのツールです。左右のAltキーの空打ちでIMEの英数とかなを切り替えることができます。
英語キーボードを普段使っている、かつMacと同じ感覚で英数とかな入力を切り替えたいのでこれは必須。

OS起動時に勝手に起動して欲しいので忘れずにスタートアップフォルダへと置きます。

f.lux

ブルーライトカット効果のあるツールです。 時間毎に画面の明るさを調整できます。これがないと目が疲れてしょうがないのでいれます。

アプリランチャー

MacAlfredのようなランチャーが欲しかったのですがあまりしっくりくるものがありませんでした。

いろいろ試したのですが、「Win + S」の検索呼び出しで問題無さそうという結論に至りました。
アプリケーションランチャーとしてはこれで問題無いのですがファイルの検索がどうもいまいちイケていません。
なのでファイル検索はEverythingで補うことにしました。

Screenpresso

画面キャプチャツールです。指定した領域のキャプチャもできるし、編集ツールもいい感じです。
MacではSkitchを使っているのですがWindows版は開発中止になってしまっていたのでこれを使うことにしました。

Tower

GitのGUIクライアントです。 Mac版も最高でこれ以外のGitのGUIクライアントはもう使えない状態になっています。幸運にもちょっと前にWindows版がリリースされました。
使っている感じたまに不穏な動きをしますがMac版と同じ使い勝手なので課金しました。

その他

以下のような定番ツールは普通にインストーラー経由でインストールしました。

  • Chromeなどのブラウザ
  • VS Code、Unity、Visual Studioなどの開発ツール
  • その他もろもろ

TwitterクライアントとRSSリーダーアプリでいいものが見つかっていないというのが悩みです。
RSSリーダーのサービスはInoReader使っているのでそれに対応していると嬉しいのですが…
何かお勧めがあればぜひ知りたいです。

さいごに

ざっくりとこんな感じです。
メインマシンをWindowsへと久しぶりに切り替えましたが素晴らしいですね。というかWindows10が素晴らしい。特にBash on Ubuntu on Windowsは感動を覚えました。
Macのターミナル環境ほぼそのまま持ってくることができたのでいうことありません。
マシン性能がよいからなのかもしれませんが、VSやUnityでの開発もめちゃくちゃ快適です。

ただ、フォントがちょっとツラいです。目が悪くなったように感じます。そこだけが不満。

ということでHoloLensも買ったことですし、今年はMicrosoftに魂を売っていく感じでいきたいと思います。
でも、新しいiPhoneiPadが出たら買います。

音声認識や音声コントロール系ニュースまとめサイト始めました

音声認識

Voice-Recognition-Tech.infoという音声認識、音声操作に関するTech系ニュースまとめサイトを始めることにしました。
イケている名前が思いつかず安直な名前となってます…

voice-rek.gather-tech.info

去年から始めたGater-Tech.infoの音声認識特化版というイメージです。

gather-tech.info

更新頻度やコンセプトに関してはこちらに書きました。

voice-rek.gather-tech.info

週1か隔週くらいでの配信を目指しますがネタの集まり次第って感じです。

今後どんどんと伸びてくるだろう分野だと思うのにこういったまとめサイトがないようなのでとりあえず始めてみようという考えです。

ということで、 第1回を書きました。

voice-rek.gather-tech.info

ちょっとどんなものか興味があったので、MediumのPublication機能使ってみています。
一緒にやりたい、何か記事を投稿してみたいという方はぜひCollaborationして下さい。

ということで、よろしくお願いします。

Swift Teetsに参加してみた

event

Swift Tweetsに参加しました。

Swift TweetsとはTwitter上で行われるバーチャルな勉強会となっており非常に面白い試みです。

Qiitaがスポンサーになっているようで発表者の方のつぶやきはQiitaでまとめられています。

qiita.com

Twitterハッシュタグはこちら。 twitter.com

Togetterはこちら。 togetter.com

個人的に非常に良いイベントの在り方だと思ったので簡単にまとめておきます。

良かった点

  • 家で参加できる!
    • 子供が小さいので最近全く外の勉強会などに参加できていなかったのですが、こういう形式なら参加できるので非常にうれしかった
    • Twitterが見られるモノ(PC、iPhoneiPadAndroid etc)さえあれば参加できるというのは非常に便利
  • 途中参加でも追いつける
  • 運営が柔軟に行えていた
    • Twitterのアンケート機能をうまく使い、休憩が必要かどうかなどをリアルタイムで集計して反映させていた。すばらしい

気になった点

  • 発表者の方の準備大変そう
    • ハッシュタグ込みで140文字におさまるように発表内容を分割しないといけないのですよね…大変そう
  • 発表途中で気になって出てきた内容やライブラリをついつい調べてしまうと流れに追いつけなくなる、しまいにはもう発表が終わっていた!なんてこともあった
    • 事前に見ておくべき資料や参考ページをもっと用意しておいた方がよいのかなあ
  • 休憩時間はかなり短かめでもよさそう
    • トイレに並ぶ、飲み物買いに行くとかないので問題無さそう

さいごに

本当に有意義なイベントでした。家で子供を寝かせた後にこういうものに参加できるというのは私にとってはまさにブレイクスルー。 こういう形式でのイベントがもっと広まればいいですね!

運営者の@koherさんお疲れ様でした!ありがとうございました!

追記

もう次の開催が決まっているみたいです!

connpass.com

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

event

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をお試し

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に癒してもらおう

Slack

前置き

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

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

そんな時に便利なのが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