この会に参加してきた。この直後にオフ会なるものがあったけど、そっちは参加せずに直帰した。

この会でのPMはプロダクトマネージャーであって、プロジェクトマネージャーではないということに注意してほしい。プロジェクト管理じゃなくてプロダクト、製品・サービスを管理する人に関するお話をしている。
今会の概要については上のリンクからたどってもらうこととして以下メモ書きをちょこっと整理したものを書く。

エンジニアからPMになるきっかけ

ビジネスサイドが売ってくれないから、自分で売ることにした。お客さんと実際に話してみて、そっちのほうが良いと思った
上司が辞めるタイミングでやらざるをえなくなった
作るものを自分で決めたかった
- 自分で企画、プランニング、実装まで全部やる人が周りにも多かった
- KPIのベストプラクティスに乗っかればよかったから、特に苦労もなかった
3年くらいエンジニアをやってた。同じプロダクトのマネージャに流れでそのままなった。

マインドセットについて

信頼関係を築くには?
- おかし配る
請負系のエンジニアを過去にやってた
- 請負のマインドからまだ変わってない。評価が工数とスケジュールに縛られがち
- サービスの仕様ではなく、工数と評価の納品に急いでしまいがち
  - でも請負系のエンジニアから自社サービス開発に進んだエンジニアに「どういう仕様が良いか」を質問してみると結構話してくれたりする
実装のことをわかりすぎて、仕様に妥協をしがち?
- どう作るかまで考えちゃう
- 頭に浮かんだやり方で実装できる場合もできない場合も説得が大変
意志決定のフローを見る

非エンジニア系PMがエンジニアとコミュニケーションするために困っていること・コツ

フロー状態のエンジニアに話しかけるタイミングがわからない
- 慣れが必要
- おかしで懐柔する
口頭で話しかけられるのが嫌な人がいる
- slackとかで話しかけないとイライラされることがある。でもslackでは伝わらなさそうな時は口頭でいく(これはエンジニアに限らないのでは)
- みんなに見えるところ(publicチャンネル)でやって欲しいという希望がある
  - そもそもDMが良くない
- オフィスがうるさいのが嫌な人が多い
  - 営業が席でテレアポしないように気をつけてるらしい
    - でも逆にエンジニアとしても営業の人と話が伝わらないのが困るから、直接営業に会いに行くこともあった
  - イヤホンしてる人多い
    - それを見ると話しかけちゃいけないように見える
    - Oculusしてるヤバい人もいたらしい。仕事してるのか全く見た目でわからない。
    - 本当に集中していそうな時は他のチームメンバーに「話しかけないように」と注意することもある
  - 極端に口頭を避けるのも良くなさそう
  - 集中する時間に関するコンセンサスを取る
- 時間にやたら厳しい人がいたりする
  - 10分で話すと言って過ぎたら「10分過ぎましたけど」と言われたことがあるらしい。(その職場殺伐としすぎ)
- エンジニアの「できません」にひるんでしまう
  - エンジニアとしては相談して欲しいだけ。他のやり方で解決できることもある
    - エンジニアだけに見える解決方法も時にあるので、「他の解決方法ありますか?」と一言欲しい
  - エンジニアからすると解決したい課題の内容をちゃんと話して欲しい
    - もうちょっと考えてから持ってこいよって思うこともある
    - 案件シート(?)ほしい(案件シートって聞こえたが違う言葉だったかも　)
      - テンプレが欲しい
  - 制限シートほしい。何ができないかを先に見せておく
    - その一方で細かく提案し過ぎても困る。それだったら口頭で話してくれってこともある
  - 「技術的には可能だが、それにかかる時間とかは別」とはっきり宣言する
  - 不満だけ溜めて無理に実装するのをやめて欲しい

エンジニアが苦手そうなこと

広報
プロモーション
アライアンス
メルマガの文章考えるのとか
そもそもコミュニケーションが苦手なのでは??
- エンジニア界隈以外の人と言葉が違って苦戦する(これは文化の違い)
- 感覚的な言葉を使われると苦手なのでは
お取引先からかかってきた電話を取るの苦手そう
- それはコード書いてて、普段電話に出る機会があまりないからだと思う
精神論が苦手そう。気合いで乗り切ろうというのは嫌い
- その割には徹夜とかやってる
  - 徹夜をする明確な理由があるなら良いというエンジニア独自の精神論がありそう
- 頑張るに値する良い理由が欲しい
  - ごめんを乱発するのは困る
  - コンテキストをちゃんと話すのが大事
  - 「部長が言ったからやる」みたいな言い方は良くない
  - エンジニアにとっては納得感が大事
客先に出すことにためらいが出るような人がたまにいる

エンジニアのキャリアパス・傾向

プロダクトマネージャー
- 見積もりの妥当性がエンジニアを離れてくるとわからなくなってくる
  - そもそもエンジニアであっても苦手な分野の見積もりは外れることがある
    - 非エンジニアの人は特に直でエンジニアとやりとりするのは難しそう
  - 自分一人で見積もるのが問題。チームでの見積もりを考えられるようにした方が育つ
エンジニアリング・マネージャー
- エンジニアを管理するマネージャー
- PMとの間を取り持てる。見積もりの(というかその技術を使って作ることの意味とか時間とかの)妥当性を見ることができる。
スペシャリスト
グロースハッカー
- ABテストとかパフォーマンス見るとかエンジニアのが得意そう
  - 自分で作れるし
  - でも細かい数字ばかり追うのはやだという人もいる
セールスマーケティングとか
- その専門の人を呼ぶのがいいのでは。結局得意な人に任せるのが良い
- アドネットワークの出し方について詳しくなっても仕方ない。効果的な出し方は既に知ってる人に聞くのでも良い。
- 規約とか法務に聞くしかないじゃん
エンジニア採用で志望者の話を聞いてると技術軸の人とプロダクト軸の人がいたりする
- サービスを運営していた人と受託しか経験したことのない人とで違う気がする
  - だからといって、PMをやるのにどっちかに偏ると困る

ユーザーの意見を聞くことについて

使う人のやり方を知りたい
使ってる人の後ろにいてもらって「困ってることをサポートしてあげてください」とだけエンジニアに言ってる
- 使う人の気持ちは実際に使ってみないとわからない
ユーザーの声聞きにいく
- エンジニア向け製品だと聞きやすい
- 主婦の方にヒアリングしに行ったこともある。使い方とかも実際に見た
- 卸売市場の人に使ってもらってるサービスとかだと簡単に使う人の気持ちを知るために現場に行くということができなかったりする
ユーザーストーリー

PMがまずやること

現場を見に行け
- 何が求められているのか情報を取りに行く力は必要
  - ただし自分で手を上げられる人じゃないと難しいと思う
- すべてのことができる必要はない
  - では何に特化すればいいの?
プロダクトマネージャーとはプロダクトの戦略を決める人ではない(?)
いろんな人との通訳

ざっとこんな感じだった。
評価制度・評価基準というものが知りたかったが、それはどうもプロダクトマネージャーの評価制度・評価基準を考える会#1 - connpassで話された模様。いろいろ漁ってたところ、#1で話された内容についてまとまってる資料を見つけた。

プロダクトマネージャーの評価制度・評価基準を考える会#1.pdf - Google ドライブ

ここに載ってる当日配られたらしい資料は見つけられてない。ぐぬぬ。。もうちょい漁ってみる。

個人的な感想としては面白かったし、なるほどなと思うところもあったんだけど、結局PM is 何って思った。
あの会場にいた人たちの中で思い浮かべているPM像がそれぞれ微妙に違ってそうだなぁと思いながら話を聞いてた。そりゃ現場によって変わるものと言ってしまえば確かにそうだけど、もうちょい広い概念がなぁと。でもそのへんは上のpdfにしれっと書かれてたりするので、これを前提に話をしてるのかな、でもみんながみんなこのpdf読んでないよねとも思う、なんだか若干もやった感じだった。

とはいえ現にPMやってる人の話を聞くのは面白い。私はPMじゃないです。

以下がハッシュタグ
 https://twitter.com/hashtag/pmjp?src=hash