Bash on Ubuntu on Windowsにおけるpyenv経由でのPythonインストール
Bash on Ubuntu on Windowsにおいてpyenv経由でPythonを入れようとしたら軽くハマったのでメモ。
pyenv自体のインストールはドキュメント通りで問題無くできます。
さてさくっと入れるか。
[~] pyenv install 3.6.1 Downloading Python-3.6.1.tar.xz... -> https://www.python.org/ftp/python/3.6.1/Python-3.6.1.tar.xz Installing Python-3.6.1... BUILD FAILED (Ubuntu 14.04 using python-build 1.0.10-2-geef042a) Inspect or clean up the working tree at /tmp/python-build.20170401003019.1617 Results logged to /tmp/python-build.20170401003019.1617.log Last 10 log lines: checking for --with-universal-archs... no checking MACHDEP... linux checking for --without-gcc... no checking for --with-icc... no checking for gcc... no checking for cc... no checking for cl.exe... no configure: error: in `/tmp/python-build.20170401003019.1617/Python-3.6.1': configure: error: no acceptable C compiler found in $PATH See `config.log' for more details
C compilerがないっぽい。gcc入れる。
[~] sudo apt-get install gcc
再トライ。
[~] pyenv install 3.6.1 Downloading Python-3.6.1.tar.xz... -> https://www.python.org/ftp/python/3.6.1/Python-3.6.1.tar.xz Installing Python-3.6.1... BUILD FAILED (Ubuntu 14.04 using python-build 1.0.10-2-geef042a) Inspect or clean up the working tree at /tmp/python-build.20170401004019.6758 Results logged to /tmp/python-build.20170401004019.6758.log Last 10 log lines: creating Modules/Setup creating Modules/Setup.local creating Makefile If you want a release build with all optimizations active (LTO, PGO, etc), please run ./configure --enable-optimizations /home/braitom/.pyenv/plugins/python-build/bin/python-build: 行 746: make: コマンドが見つかりません
今度はmakeがない。ですよね。ごめんなさい入れます。
[~] sudo apt-get install make
今度こそ。
[~] pyenv install 3.6.1 Downloading Python-3.6.1.tar.xz... -> https://www.python.org/ftp/python/3.6.1/Python-3.6.1.tar.xz Installing Python-3.6.1... BUILD FAILED (Ubuntu 14.04 using python-build 1.0.10-2-geef042a) Inspect or clean up the working tree at /tmp/python-build.20170401004228.15164 Results logged to /tmp/python-build.20170401004228.15164.log Last 10 log lines: File "/tmp/python-build.20170401004228.15164/Python-3.6.1/Lib/ensurepip/__main__.py", line 4, in <module> ensurepip._main() File "/tmp/python-build.20170401004228.15164/Python-3.6.1/Lib/ensurepip/__init__.py", line 189, in _main default_pip=args.default_pip, File "/tmp/python-build.20170401004228.15164/Python-3.6.1/Lib/ensurepip/__init__.py", line 102, in bootstrap _run_pip(args + [p[0] for p in _PROJECTS], additional_paths) File "/tmp/python-build.20170401004228.15164/Python-3.6.1/Lib/ensurepip/__init__.py", line 27, in _run_pip import pip zipimport.ZipImportError: can't decompress data; zlib not available make: *** [install] エラー 1
zlibがないっぽい。すいません入れます。
[~] sudo apt-get install zlib1g-dev
4度目の正直。
[~] pyenv install 3.6.1 Downloading Python-3.6.1.tar.xz... -> https://www.python.org/ftp/python/3.6.1/Python-3.6.1.tar.xz Installing Python-3.6.1... WARNING: The Python bz2 extension was not compiled. Missing the bzip2 lib? WARNING: The Python readline extension was not compiled. Missing the GNU readline lib? ERROR: The Python ssl extension was not compiled. Missing the OpenSSL lib? Please consult to the Wiki page to fix the problem. https://github.com/pyenv/pyenv/wiki/Common-build-problems BUILD FAILED (Ubuntu 14.04 using python-build 1.0.10-2-geef042a) Inspect or clean up the working tree at /tmp/python-build.20170401005207.30873 Results logged to /tmp/python-build.20170401005207.30873.log Last 10 log lines: upgrade) ensurepip="--upgrade" ;; \ install|*) ensurepip="" ;; \ esac; \ ./python -E -m ensurepip \ $ensurepip --root=/ ; \ fi Collecting setuptools Collecting pip Installing collected packages: setuptools, pip Successfully installed pip-9.0.1 setuptools-28.8.0
あれ？ ここで気づきました。そうだこれはUbuntuだった。
結論
ということで最初にまるっといれておけばOKです。
[~] sudo apt-get install git gcc make openssl libssl-dev libbz2-dev libreadline-dev libsqlite3-dev
教訓
Visual Studio 2017のテーマを変更する
Visual Studio 2017のテーマを変更する方法です。
正直、Visual Studioを真面目に使うのはVisual Studio 2012以来です。 実に5年ぶりです。 デフォルトダークなテーマがあったりとだいぶイケてる感じになっていて満足しています。
しかし、なんかコードが見づらい感じがしたので変更することにしました。
設定方法は特に難しいとことはありません。 以下のサイトでいろいろなテーマが公開されているので好きなものを選んで入れればOKです。
設定方法
具体的な手順に入っていきます。
テーマの選定とダウンロード
こちらから好きなテーマを探します。
私は定番のMonokaiを使うことにしました。
注意点としては「Visual Studio 2015」を選択した上でダウンロードすることです。今回Visual Studio 2017に適用しますが2015のものでも問題なく適用できることを確認しています。
テーマをVisual Studioにインポートする
[ツール]＞[設定のインポートとエクスポート]と進んで[設定のインポートとエクスポート ウィザード]を開く
[選択された環境設定をインポート]を選択して[次へ]
現在の設定の保存画面になるので、現在の設定を保存するか上書きするかを選択して[次へ]
インポートする設定コレクションの追加画面になるので、左下の[参照]から先ほどダウンロードしたテーマ(xxxxx.vssettings)を選択してインポートする
たったこれだけです！
おまけ
フォントも変更するとさらにいい感じになります。
[ツール] > [オプション] > [環境] > [フォントおよび色] > [フォント]から変更できます。
お勧めは、「Consolas」です。
さいごに
Before、Afterを見てみましょう。
Before
After
いい感じですね。
Windows 10の開発環境作り（2017年春編）
もう3月も半ばですね。気分はもう春です。
春ということで気分を切り替えるために、久々にまじめにWindowsを使ってみることにしました。 そのため環境構築まわりで何をやったのかをメモがてら残しておくことにします。
ちなみにこのマシンを買いました。
HoloLensアプリの開発もしたいのでGPUが欲しかったのでどうせならとGTX 1080積みました。とりあえずメモリも32GBに盛っておきました。
開発系
Chocolatey
Windowsのパッケージマネージャーです。 MacでもHomebrewに依存しまくっていたのでパッケージマネージャーがないとツラいので。
GUIで管理できるものもあるので入れたい人は入れておくとよいと思います。
Bash on Ubuntu on Windows
導入方法は以下の記事が分かりやすいと思います。
簡単にいうと、機能の有効化でWindows Subsystem for Linuxを有効にして開発者モードをオンにすればOKです。
$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もそのまま使えました。
Macのzshrcをそのまま使えるので楽ちん。
cmder
シェルです。
昔はConEmu - Handy Windows Terminalを使っていたが今の時代はこのcmderの方がイケてるらしいのでこっちを入れました。
複数タブを開ける、開くシェルの種類を選べる、テーマとフォントも色々と設定できるのでこれで問題無さそう。
設定したBash on Windowsを簡単に使えるよう設定しておきます。
- 「メニュー」＞「setting」を選択
- 左サイドバーの「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
これでcmderから簡単にbash.exeが起動できます。
JavaScript関係
nvm
nodeはバージョンを切り替えてがちゃがちゃと試したいことが多いのでChocolaty経由で入れずにnvmを使います。 最近はWindows用のnvmとかあるんですね。
- coreybutler/nvm-windows: A node.js version management utility for Windows. Ironically written in Go.
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
ブルーライトカット効果のあるツールです。 時間毎に画面の明るさを調整できます。これがないと目が疲れてしょうがないのでいれます。
アプリランチャー
MacのAlfredのようなランチャーが欲しかったのですがあまりしっくりくるものがありませんでした。
いろいろ試したのですが、「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に魂を売っていく感じでいきたいと思います。
でも、新しいiPhoneやiPadが出たら買います。
音声認識や音声コントロール系ニュースまとめサイト始めました
Voice-Recognition-Tech.infoという音声認識、音声操作に関するTech系ニュースまとめサイトを始めることにしました。
イケている名前が思いつかず安直な名前となってます…
去年から始めたGater-Tech.infoの音声認識特化版というイメージです。
更新頻度やコンセプトに関してはこちらに書きました。
週1か隔週くらいでの配信を目指しますがネタの集まり次第って感じです。
今後どんどんと伸びてくるだろう分野だと思うのにこういったまとめサイトがないようなのでとりあえず始めてみようという考えです。
ということで、 第1回を書きました。
ちょっとどんなものか興味があったので、MediumのPublication機能使ってみています。
一緒にやりたい、何か記事を投稿してみたいという方はぜひCollaborationして下さい。
ということで、よろしくお願いします。
Swift Teetsに参加してみた
Swift Tweetsに参加しました。
Swift TweetsとはTwitter上で行われるバーチャルな勉強会となっており非常に面白い試みです。
Qiitaがスポンサーになっているようで発表者の方のつぶやきはQiitaでまとめられています。
Twitterのハッシュタグはこちら。 twitter.com
Togetterはこちら。 togetter.com
個人的に非常に良いイベントの在り方だと思ったので簡単にまとめておきます。
良かった点
- 家で参加できる！
- 途中参加でも追いつける
- 運営が柔軟に行えていた
- Twitterのアンケート機能をうまく使い、休憩が必要かどうかなどをリアルタイムで集計して反映させていた。すばらしい
気になった点
- 発表者の方の準備大変そう
- ハッシュタグ込みで140文字におさまるように発表内容を分割しないといけないのですよね…大変そう
- 発表途中で気になって出てきた内容やライブラリをついつい調べてしまうと流れに追いつけなくなる、しまいにはもう発表が終わっていた！なんてこともあった
- 事前に見ておくべき資料や参考ページをもっと用意しておいた方がよいのかなあ
- 休憩時間はかなり短かめでもよさそう
- トイレに並ぶ、飲み物買いに行くとかないので問題無さそう
さいごに
本当に有意義なイベントでした。家で子供を寝かせた後にこういうものに参加できるというのは私にとってはまさにブレイクスルー。 こういう形式でのイベントがもっと広まればいいですね！
運営者の@koherさんお疲れ様でした！ありがとうございました！
追記
もう次の開催が決まっているみたいです！
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達にインタビューして出てきた意見
- 長い期間での成功をきちんと考える
ゼロから始める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
- Business Group
- 何をやるにも客観的なデータの提示が必要
- 売り上げ状況の説明、ステークホルダーへの説明などデータを提示することが重要
- そこでPowerBI
- PMはレポート作成をPower BIに任せて他の業務に集中しよう
大規模システム開発におけるプロダクトマネージメントについて
- 株式会社ディー・エヌ・エー 小林 篤
過去多数のプラットフォームを開発指揮してきた経験から、組織・チームを破綻させること無くプラットフォーム開発を成し遂げられたヒントとその中で感じた課題をお話します。
内容
- プラットフォーム開発の特徴
- エンドユーザーが直接利用することが少ない
- サービス開発と違いユーザーの利便性などが直接分かるわけではないのでマーケティングしにくい
- プラットフォーム開発でのPMの役割
- バラバラの機能がどこの何に活きてきているのかをきちんと伝える
- その機能が事業にどのように貢献しているかをきちんと伝える
- 各チームがそれぞれ意味があるということをしっかりと周りに伝えることが大事
- 特にマイクロサービス毎にチームを分けている場合は
- 事業をなぜやっているかという疑問が生じたら徹底的に説明する
- なぜ、何のためにやるのか、ミッションは何なのか
- チームで目指しているものを一致させる
- 思いを言語化して相手に伝えないとほとんど伝わらない
- 迷いがなくなると人は強くなれる
絶対失敗すると言われたプロダクトを成功させること
- freee株式会社 佐々木 大輔
内容
- freeeで最初苦労したこと
- 新しい会計ソフトとか覚えたくない
- クラウドである必要を感じない
- 自動で入力するとかいらない。早く入力できるようにしてほしい
- 強みをつくる
- 機械学習による勘定科目の自動振り分け （特許取得済み）
- キャズムを作る
- 狙っているセグメントの人にどんどん使ってもらう
- 夕刊紙に「freeeの登場により日本から税理士が消える」という記事がのる
- これで一気に問い合わせがきた
- ユーザーが増えてくると全部の要望を聞き入れることが難しくなってくる
- 最初の内は一般的な要望が多いがそうではなくなってくる
- なぜその要望が必要なのかを徹底的に掘り下げていく必要がある
現役23名のPM：タイプ別マネジメントパターン
- 株式会社ジャストシステム 三木 雅之
社内では現役23名もの開発責任者（プロダクトマネージャー）が切磋琢磨しつつ、さまざまな課題に立ち向かっています。23人23色のやり方の中から見えてきた、タイプ別マネジメントパターンをいくつか紹介します。
内容
- 資料：現役23名のPM：タイプ別マネジメントパターン
- ジャストシステムには23名のプロダクトマネージャーがいる
- プロダクト開発の要素
- 価値創造力
- 技術力
- 考える人と、創り出す人の組織や役割をあえて分けすぎない
毎日の料理のためのプロダクト開発
- クックパッド株式会社 池田 拓司
日々変わり続けるクックパッドのプロダクト開発。今、私たちが食や料理というジャンルの中でユーザーにどのような価値を提供しようと考え、それをどう開発で実践しようとしているか。PCからスマートフォン、ウェブとアプリの役割などプラットフォームの考え方、エンジニアやデザイナー、ディレクターなど各職種のスタッフがどう関わり意思決定しているかなど含め、これまでの変遷や具体的な開発の事例を交えて話します。
内容
- デザイナーを全社横断組織にしたり、ひとつの組織にしたりいろいろ試している
- 今は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の開発体制
- Pokemon GOを支えるPM
- PMが業務を回していくコツは？
- 仕組みを作るのが大事
- 今のクオーターと次のクオーターで同じ事をやっていたら負け
- 変化の仕掛けを作るのが大事
- PMが定常的な仕事をしていたら負け
- 他のメンバーで回るようになったら次に行く
- Pokemon Goはテスト時のネガティブな状態からどうたち直したのか？
- フィールドテストの評価はひどいものだった
- でも出して試してもらわないといけないので出した
- 叩かれても貴重な意見に変わりない。エンジニアにどう伝えるかは考える必要がある。ただの文句なのか、大事な意見なのかはPMが切り分けて伝えている
- PMの立ち回り
- 技術の会話が出来てエンジニアからもリスペクトされた方がよい
- 知ったかぶりを貫き通すのも技術。もちろん基本的な知識は身につける必要がある
- メンバーの好みを知る。モチベーションを上げる方法を知っているか
- 焼き肉に行く
- PMとエンジニアの関係性
- PMとしての能力開発
- チームの信用を得ることが大事
- きちんと製品、サービスを世に出すというのが実績/評価につながる
- 力を付けるのは自分でやってみるしかない、OSSでも小さな社内プロジェクトでもなんでもよい。座学だけでは力はつかない
メルカリ流グローバルなプロダクトマネジメント
- 株式会社メルカリ 伊豫 健夫
JP／US／UKと三カ国にサービスを展開するメルカリの、グローバルなモノづくりの実態について公開。プロダクトマネジャーの役割は？多国間のコミュニケーションと意思決定は？メルカリ流の創意工夫についてのお話です。
内容
- 今はプロダクトチーム全体の90％をUSに割いている
- 大量の機能追加、改修案件が可能
- 組織として、個々人の行動レベルにおいても迷いがなくなりUSに集中できる
- 達成目標にはOKRを採用
- シンプルに目標を立てるようにする
- チーム全員が全社で目指しているものを同じ言葉で話せることが大事
- PMがチームメンバーのKRに対しての全責任を負う
- メルカリのPM
- リーダー的なこともやるし、自分で手を動かすこともある
- 課題は全てRedmineで管理
- チケットがないとリリースできない
- リリース後の分析
- チームをコーディネートする時のポイント
- オープンコミュニケーションを心がける
- メルカリでは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の事例
- Albumの事例
- Xperiaにプリインされている写真閲覧アプリ
- チームビルディングで山登りした
- 性格が把握できる（先に行っちゃう人とか）
- チームビルディングで原宿へ
- 若者の文化を知る
- ワークショップしてメンバーの想いを一つにする
感想
最近何かと話題になるプロダクトマネージャーについていろいろと知ることができました。一般的な話から、登壇者の方々が実際にどのような取り組みをしているかを知ることができ自分の幅をかなり広げることができそうです。
今の会社でプロダクトマネージャーという職種になれるかというとそういうわけにはいかないので、自分の持っているいくつかの小さなプロジェクトに今回学んだノウハウをいくつか取り入れて実践していきたいですね。
プロダクトマネージャーを担当する上でのベストプラクティスはないので自分のチームにあった方法を模索していくしかないという大前提があるのですが、登壇者の方々の話を聞いているとプロダクトマネージャーとして大事なポイントはだいたい以下に集約されると感じました。
- メンバーそれぞれが自走できるようにする
- なぜそれをするのか？何のためにするのか？をきちんとメンバーが考え続けることができるように
- チームの想いを統一する
- 会社の目標、チームの目標、個人の目標をきちんと結びつける
- 言語化
- 考えていることはきちんと文字にしてメンバーに共有する
- できる限りオープンにして議論する
- ユーザーのことをきちんと理解する
- 開発者もペルソナ作成、カスタマーインタビューを行うなど
- 自分もユーザー視点になる
- 信頼を得る
- 最低限の実績は必要
- 小さいプロジェクトでもよいので経験を重ねていく
- 焼き肉行く
- 担当プロダクトへのアツい情熱
全体的に最高なイベントでした。普段なかなか時間をとってこのような内容を考える機会がないので本当にいい刺激になりました。
運営の皆様ありがとうございました！
12/15 追記
公式ページに資料まとめページができています。
Vagrant上のUbuntuにRabbitMQをたててMQTTをお試し
MQTTがだいぶ流行ってきている感がある今日この頃。 仕事上でもちょっと触る必要がでてきたのでちょっとメモっておきます。 MQTTについてはこちらの素晴らしい記事で確認して下さい。
今回はとりあえずちょっと試したいのでブローカーサーバーとしてRabbitMQを使うことにしました。
Vagrantの準備
Vagrantのインストールとか使い方は至る所に記事が転がっているのでそちらを参照して下さい。
とりあえず今回はHashicorpが提供しているubuntu/trusty64を使っています。
あと、同一ネットワーク内の様々な機器からアクセスしたいのでVagrantのネットワーク設定はPublic Networkにしておきます。
私はMacをWi-Fiで接続しているので以下のような設定をVagrantfileに追加しておきます。
config.vm.network "public_network", :bridge => "en0: Wi-Fi (AirPort)"
あとはいつもどおり、vagrant up、vagrant 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インターフェイスにアクセスしてみましょう。
繋がりますね。
初期アカウントはguest/guestとなります。
コンソールに入れました。
これでインストールは完了です。
ブローカーサーバーに繋いでみる
さて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
コードはこんな感じになります。サンプルなのでただコンソールに出力するだけです。
ポイントとしてはsubscribeするTopic名(今回は、"test/iOS")をPublish側と合わせることくらいですかね。
実行
まずSubscribe側を実行しておきましょう。
$ python subscribe_mqtt.py Connected with result code 0
これでブローカーサーバーに繋がりSubscribeの準備はできています。
次に、Publish側を起動しましょう。
これで気圧情報をガンガンPublishし始めます。
Subscribe側を見ると情報が届いているのを確認できるかと思います。
まとめ
このように比較的簡単にMQTTをお試しすることができました。 MQTTを実際に使うには、切断検知や再接続方法、セキュリティ等を使用用途によって考えなければなりませんが、なかなかシンプルで良いプロトコルだと思います。 今後も情報集めていきたいですねー。
