【書評】DevRel エンジニアフレンドリーになるための3C
読書感想文です。いつもより流し読みです。（本を速く読む実験です）
DevRel とは、自分たちのプロダクトをサービス利用者である開発者に使ってもらう、浸透させるための取り組み全般と理解しています。
グッときたところ
- DevRel に必要な 3C (code: 技術力, contents: 技術以外も含めた発信, community: ユーザコミュニティ) の言語化
- デベロッパージャーニー（ユーザが自分たちのプロダクトを通してどのような経験をしていくのか）の重要性
- そもそも DevRel という仕事に求められる能力（技術力、発信力、信頼性、速さ、アクティブさ）、プロとしての手腕の定義
雑感
自分は SDK 開発の中で DevRel と言われるような取り組みをしてきましたが、その中での曖昧とした部分を言語化してくれている本でした。書かれているとおりですが、発信には技術への理解が必要になります。技術と発信を両立するには、作業の速さやユーザに対するアクティブさも必要になる仕事です。
個人的には、3C の中でも contents が特に重要と思っています。 技術に限らず、ユーザ目線でどんなものが必要かを自分たちが理解し、それに応えられる発信を続けていくことが重要だからです。
2019年の振り返り
まとめている人が多いので、自分も今年を振り返ってみる。
お仕事
今のチームに入ったのが2019年1月なので、ちょうど1年になる。 以前と比べると、次の点は自分にとって新鮮だった。
- Unity
- 非ゲーム
- 新規開発（検証 & 実装）
活動として大きかったのは、社外へのアウトプットを強く意識して動いたこと。（このブログもそう） 自分としてもやりたかったことだし、チームからもそういう動きを期待されていたのでちょうど良かったと思う。
具体的な内容と振り返りは会社のブログに書いている。
下期に入って Unity 以外の技術に触れることも増えてきた。 自分はどちらかというと「とりあえず作ってみる」というフットワークが良くない方だと思うので、新しい技術でもさっと調べてサクッと作る、みたいなふるまいをもっと身につけていければと思っている。
まぁまたゲームにも関わりたいので Unity は引き続きやっていくつもり。
マネージメント
以前は30歳くらいになったらマネージャーやるんだろうなぁとか思っていて、まぁ現状やってはいるのだが、思ったほど振り切ってはいない。 少人数チームなので全員実装が必要なこともあるし、やはり自分で手を動かしてものを作るのは楽しい。 会社的にもプレイングマネージャーが多い印象なので、参考にできる人も多い。
とは言え、社外カンファレンスでマネージャーについて学んだことは非常に良かったと思う。 業界全体で様々な課題、それに対する挑戦が存在していると認識できたことや、これまでの知見がどんどん言語化、フレーム化されていっているということも興味深かった。
実装がやりたくない、上手くいかないから仕方なく、などのネガティブな動機ではなく、チームの力を最大化したい、プロダクトを成功させたい、というポジティブなモチベーションを知ることができて本当に良かったと思う。
とは言え言語化が進んでいるというのはマネージメントに関して学ぶことが多いという話でもあるので、ここは技術面とバランス良くやっていきたい。
それ以外
CEDEC などの発表を通して、新しく AI 技術に興味を持った。 以前よりも AI を手段として活用している事例も増えており、社内で使われた言葉だが「AI の民主化」が進んでいると思う。
まだ本を読んでみただけなので、年始はそのあたりでなにか実装を試してみたいと思う。（と宣言してやる気を出す）
技術以外
あんまり人に言っていないが（隠してもいないが）アルトサックスをやっている。 最近はアドリブ（曲に合わせて自由に吹く）がどうにかできるようになってきたので楽しい。 基礎練が終わり、もっと自由に吹くために改めて基礎を学ぶというフェーズになってきた。 元々ゲーム曲がやりたいという理由で始めた楽器だが、実際どうにか吹けているので非常に良い。
来年
1番は趣味と勉強のバランスをとる、というか勉強をもっと趣味に寄せたいと思う。 勉強と思っていると捗らないし身につかないので、何が楽しいのか、何ならより自然に取り組めるのか、を見極めて面白くやれればいいなと思う。
csc で Unity 用 DLL を作る
表題の通り、csc で DLL を作成するにあたって調べた内容を備忘録として残します。
以前書いた記事の続編的な内容です。
検証した環境は次の通りです。
はじまりはじまり
事の起こりは、mcs による DLL 作成時に下記のエラーが起きたことです。
error CS1644: Feature `default literal' cannot be used because it is not part of the C# 7.0 language specification
原因になったのは次のような書き方です。
public void Hoge(Vector3 position = default)
原因はエラーで指摘されているように、default リテラルが C# 7.1 以降でないと利用できないことです。
どうやら、mcs はデフォルトだと C# 7.0 以前のものを利用しているようです。
エラーの解消
この現象の解決策は二つあります。 一つは型推論に頼らず、スクリプトで型を記述することです。
public void Hoge(Vector3 position = default(Vector3))
もう一つは、mcs 実行時に言語バージョンをオプションで指定することです。
csc への乗り換え
前記事で検証したとおり、Unity 2018 ではコンパイラとして csc が利用されています。
せっかく DLL 作成コマンドを修正するのであれば、そのまま Unity と挙動を合わせたいと考えました。
まず、Unity 内部で利用されている csc は次のものです。（ファイルをリネームするとエラーになります）
/Applications/Unity/Hub/Editor/2018.4.9f1/Unity.app/Contents/Tools/Roslyn/csc
試しに現在使っている mcs と入れ替えると、次のエラーが大量に発生します。
error CS0518: 定義済みの型 'System.Void' は定義、またはインポートされていません error CS0518: 定義済みの型 'System.ValueType' は定義、またはインポートされていません error CS0518: 定義済みの型 'System.Object' は定義、またはインポートされていません
Visual Studio のオプションを流用
対処としては、必要な DLL を参照するオプションをつける必要があります。 具体的な内容は、前回の記事で Visual Studio を用いて DLL を作成した際の処理を参考にします。
- mscorlib.dll
- System.dll
- SystemCore.dll
これら三つを参照することで先ほどのエラーは起きなくなります。
その他の気になるオプション
そのほかの参照に関連するオプションとして次のものがあります。
結論から言うと、今回の検証の中ではこれらがあってもなくても挙動は変わりませんでした。
まず、noconfig は csc.rsp という参照を記述するファイルの設定を無視するものです。
ただし、利用している csc と同じディレクトリには同ファイルは存在していませんでした。
nostdlib+ は mscorlib を参照しなくなるオプションです。
Visual Studiio の例では mscorlib を明示的に指定しているため、いずれにせよ参照は必要だと思われます。
今回の場合、意図せぬ参照が発生するよりは必要最低限に絞った方が良いと判断し、これらも付与したコマンドにしていきました。
参照するべき DLL の見極め
Unity 内部で System.dll を検索すると、複数のファイルが存在します。
./Tools/Roslyn/System.dll ./NetStandard/compat/2.0.0/shims/netfx/System.dll ./MonoBleedingEdge/lib/mono/4.5.2-api/System.dll ./MonoBleedingEdge/lib/mono/unity/System.dll ./MonoBleedingEdge/lib/mono/4.7.1-api/System.dll ./MonoBleedingEdge/lib/mono/4.5.1-api/System.dll ./MonoBleedingEdge/lib/mono/4.5-api/System.dll ./MonoBleedingEdge/lib/mono/4.6.2-api/System.dll ./MonoBleedingEdge/lib/mono/2.0-api/System.dll ./MonoBleedingEdge/lib/mono/4.6-api/System.dll ./MonoBleedingEdge/lib/mono/4.6.1-api/System.dll ./MonoBleedingEdge/lib/mono/4.5/System.dll ./MonoBleedingEdge/lib/mono/4.0-api/System.dll ./MonoBleedingEdge/lib/mono/unityjit/System.dll ./MonoBleedingEdge/lib/mono/unity_web/System.dll ./MonoBleedingEdge/lib/mono/unityaot/System.dll ./Mono/lib/mono/unity/System.dll ./Mono/lib/mono/2.0/System.dll ./Mono/lib/mono/unity_web/System.dll
いくつかそれっぽい DLL で検証したところ、次のような結果となりました。
| DLL | 成否 | メモ |
|---|---|---|
| ./MonoBleedingEdge/lib/mono/4.7.1-api/System.dll | 成功 | Visual Studio が使っていたものに近いバージョン |
| ./Tools/Roslyn/System.dll | 失敗 | System 関連でエラーのまま |
| ./MonoBleedingEdge/lib/mono/unity/System.dll | 失敗 | Task 関連のエラー、C# 7.0 未満？ |
Roslyn のものなら上手くいくのではと思っていたので、ここは少し予想外でした。 ただし、上手くいったファイルと比べてみると Roslyn のものはファイルサイズがかなり小さいです。（結果は一部割愛です）
$ ls -a /Applications/Unity/Hub/Editor/2018.4.9f1/Unity.app/Contents/MonoBleedingEdge/lib/mono/4.7.1-api/System.dll admin 500224 $ ls /Applications/Unity/Hub/Editor/2018.4.9f1/Unity.app/Contents/Tools/Roslyn/System.dll admin 41472
どちらのファイルも、リネームして参照できない状態にすると Unity でエラーが発生します。 また、Roslyn の System.dll をリネームする（参照できない状態にする）と、4.7.1-api/System.dll を使おうとした時でもエラーが発生します。
このことから、標準的な System の実装は 4.7.1-api/System.dll に定義されており、Roslyn 用の実装が Roslyn/System.dll に定義されていると推測されます。
（これらを示すドキュメントを確認できた訳ではないので、あくまで推測です）
結論
ここまでの検証結果を考慮し、次のようなコマンドを用意しました。
Mono := $(UnityDirectory)/Contents/MonoBleedingEdge/lib/mono/4.7.1-api Csc := $(UnityDirectory)/Contents/Tools/Roslyn/csc LangVersion := 7.3 make_dll: $(Csc) \ -r:$(UnityDirectory)/Contents/Managed/UnityEngine.dll \ -r:$(Mono)/mscorlib.dll \ -r:$(Mono)/System.Core.dll \ -r:$(Mono)/System.dll \ -noconfig \ -nostdlib+ \ -target:library \ -recurse:'Assets/Scripts/*.cs' \ -out:AROW.dll \ -langversion:$(LangVersion)
このコマンドで DLL を作成できること、普段行っているテストに関して不備がないこと、は一通り確認できました。 もし何か不備が見つかれば対応と合わせて追記します。
ポエム
Unity で行われているコンパイル部分が公開されればありがたいなと思いつつ、一般的に Unity で扱うアセットは Asset Store かオープンソースでの公開が主流な印象があるため、DLL 作成はそこまで強く想定されていないのかなと感じた年末です。
【書評】レガシーコード改善ガイド
読書感想文です。
概要
導入は既存のコードを修正するにはどうするかという流れですが、内容の8割近くはテストの話です。 斬新な内容という感じではありませんが、普段何気なくやっている様々なリファクタリング手法を定義し、名前付けてくれる本です。 例えば大きめな既存メソッドに新規処理を追加する場合、既存メソッドには新規メソッドだけを追加し、新規メソッドの内部に新しい処理をまとめる。こうすることで変更箇所を一つにまとめてしまう、このやり方をスプラウトメソッドと呼ぶ、などです。
グッときたところ
- 処理同士がつながる「接合部」を意識することでテストのための構造が見えてくる
- private メソッドをテストしたいのなら、そもそも public であるべきものかもしれない
- リフレクションは便利だが、テスタビリティを考慮した実装を保つという観点は満たされない
- sealed や final は控えることを推奨する、テスト用に継承クラスを作れなくなる
- 状態を変更するコマンド、状態を変更せず値を返すクエリ、この二つの役割分担を意識する
- システムのストーリーを話す：アーキテクチャや相互作用を誰かに話しながら整理することで、設計の本質部分を見いだしていく
- メソッド抽出においては int → double のような型変換は特に気をつける
- あまりにも巨大なメソッドなら、それだけで一つのクラスに抽出するという手段がある
雑感
自分が private メソッドをテストするときはよくリフレクションを使っているため、テストのためのリファクタリングを通して構造を見直すべきという話は耳が痛いところです。 とは言え、例えば sealed によって不用意な継承クラスを作って欲しくないという意図を宣言し、長期で見て実装が複雑にならないようにするという運用も当然あり得るわけで、どの程度テストのためのアーキテクチャにすべきかは常に考えていきたいところです。
【書評】INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント
読書感想文です。
前書き
先日参加したイベントで紹介されていた本です。 ryu-rand.hatenablog.com
自分はいま少人数チームでリードエンジニアを務めているので、実装以外にもいろいろとやります。 その中でも、自分たちの製品はどんな課題を解決するのか、自分たちはチームとしてどこを目指していくのか、などの見定めや定義づけはまだまだ試行錯誤中です。 そのあたりの参考になればと思ったのがこの本を読んだきっかけです。
雑感
プロダクトマネージャーの考え方、やるべきことがやや抽象的に書かれています。 技術的な視点では書かれていないので、非エンジニアでも問題なく読めると思います。 ポイントポイントで参考になる点がありましたが、同じ内容の繰り返しもあり、記述はやや冗長かなという印象です。 チャプター名が具体的に書かれているので、気になる箇所をピックアップして読むのがおすすめです。
グッときたところ
プロダクトマネージャーカンファレンス 2019 に参加してきた
こんちは、じぬ（@reximology）です。
プロダクトマネージャーカンファレンス 2019 というイベントに参加してきました。
参加の動機
現在は少人数チームで開発を行っているため、エンジニアでもこういったプロジェクト開発を推し進める知見を持っていた方がスムーズに進めていけるのでは、というところから参加を決めました。 余談ですが、プロダクトマネージャーは PdM と略す場合が多いようです。（PM と記載してる例もありましたが
参加したセッション
day1
- 作り手の想いとユーザーをつなぐための悪戦苦闘
- ピクシブのプロダクトマネージャー、自己組織化されたチーム、チームを支える組織
- “失敗事例で学ぶ” 失敗しないプロダクトマネジメント- PMの必須スキルと、自走する組織のつくりかた -
- テクニカルアドバイザー 及川卓也 × エン・ジャパン 公開トーク- PMの必須スキルと、自走する組織の裏側 -
- 企業が求めるプロダクトマネージャーとその人材戦略
- 異動、転社・転職などを活用したプロダクトマネージャーのキャリア戦略
day2
- 変化の激しいプロジェクトを成功に導くには － 会議ドリブンなプロジェクトマネジメントメソッド
- 打席に立ち続けられるプロダクトチームを作ろう
- プロダクトアウトな新規事業立ち上げのリアル
- PMはどのようにバリューを出していくのか
- プロダクトマネージャーが知っておくべき、「OKR」を通じたこれからのチームマネジメント
- シリコンバレーPMのキャリアと働き方
作り手の想いとユーザーをつなぐための悪戦苦闘
要約
- 去年はリリース前後の話をした、今年はリリース後の課題
- 市場が伸びるとともに自分たちの想像できていないユーザが現れ始めた
- 自分たちがユーザを理解できているという過信があった
- ユーザと向き合う対話を徹底した
- 各メンバーにもその視点を浸透させた
グッときたところ
- 例えばライフサイクルの異なる地方ユーザなど、具体的に開発者が想像できていなかったユーザの登場
- ユーザ属性をカテゴライズし、確実に見分ける質問を必ずアンケートで実施
- ギルドワークス社のワークショップなど、チーム全員でユーザと対話する訓練
- Monthly Release Sharing という社内知見共有の定例化、マネージャーではなく現場のメンバーが話すことを徹底
ピクシブのプロダクトマネージャー、自己組織化されたチーム、チームを支える組織
要約
- pixiv で PdM が持つべきスキルとスタンスをまとめた PM コンピテンシーを整備
- プロダクトマネジメントトライアングルを実際の PdM でどうまとめるか
- 複数の PdM を抱えるチームという事例
- 既存のエンジニア組織を参考に、PdM を組織化
- ドメイン知識を高いレベルで獲得し、メンバーお互いを尊重し合える文化
グッときたところ
- 企業によっても異なる PdM の定義を言語化した
- 参考にしたエンジニアギルドが pixiv 内で10年近く続いた組織である
- プロダクトのあるべき姿を定義、チーム力を最大化、という二つの PdM のミッション
- PdM の育成に再現性を持たせるための試行錯誤
“失敗事例で学ぶ” 失敗しないプロダクトマネジメント- PMの必須スキルと、自走する組織のつくりかた -
要約
- 相次ぐ退職、属人化によって新規プロジェクトに取り組めないなどの重い課題
- PdM を明確に定義できていない
- Inspired 読んだ、社外のスペシャリスト（及川さん）に相談した、GAFA などの事例を調査した
- PdM の役割、持つべきスキルを明確化した
グッときたところ
- 役割：製品価値を最大化し、それに向けてチームをつないでいく
- 価値とチームという2軸は上述の pixiv と近い（おそらく PdM に期待される共通項
- 期待されるスキル：創る能力、広める能力（製品のグロースや、ドメイン知識の理解など
- 能力値をレベルで表現することで各 PdM の強み弱みを明確化した
テクニカルアドバイザー 及川卓也 × エン・ジャパン 公開トーク- PMの必須スキルと、自走する組織の裏側 -
要約
- 正直各社の取り組みは似ている
- PdM トライアングルは難しい、それぞれかみ砕いていく必要がある
- その上でメンバーが自分たちの物である、という認識を持つように促していく
- PdM は全体に精通する必要がある
グッときたところ
- レベルごとの期待値をリスト化するのは大変だったが、ネット情報をはじめとして洗った上でかみ砕いていった
- 非エンジニアの PdM は SQL とかとっつきやすい、構文がわかりやすく結果も見える、そういうところから全体に精通する必要がある
- スキル表はまだ評価に組み込めてはいない、それよりもキャリア相談などに活かしている
- PdM は最終的に全てに責任がある、自分でやるのは一つの手段だが、できるメンバーに頼るのも必要なスキル
企業が求めるプロダクトマネージャーとその人材戦略
要約
- PdM 人材の需要
- オンボーディング
- 価値観醸成
グッときたところ
- PdM のタイプは様々、多様性が企業の強みになる
- 会社の文化を理解すること、創業者との信頼関係があることが求められる
- メンバーは権限では動かない、信頼関係の構築が必要になる
- 新しい PdM に丸投げは絶対ダメ
- 最初は花を持たせて成功させる、そこまでやってようやく採用が成功と言える
- 会社からの期待値をきちんと伝える
- ミニ CEO とも呼ばれる、視野視座はきちんと会社と揃えていく必要がある
- 既存の PdM と 1on1 などを通して併走させ、きちんと会社になじませる
異動、転社・転職などを活用したプロダクトマネージャーのキャリア戦略
要約
- PdM に必要なスキル
- PdM の採用
- 年収の相場
- PdM を目指した転職
グッときたところ
- PdM に必要なのは、大雑把に言えば「なんとかする力」「突破力」
- 足りない力があればそれをどうやって乗り越えるのか、を考え実行できる人
- PdM は統合スキルが求められる
- 鳴り物入りで入社した人でもダメなことはある、むしろ新卒上がりの方が強かったりする
- 中途の人にはいきなりポジションを与えず、補佐みたいなところから周りの信頼を得て成果を出せるか見る
- 期待値を下げて、きちんと動ける環境を用意してあげる
- 最初から役職にこだわる人は難しい
- News Picks だとトップクラスは年収2000万くらい
- 一つのプロダクトを完全に任せられる人材なら1000万くらい
- PdM を目指すには、とにかくユーザ満足度を考え、それを科学する（トライ＆エラー、デザイン思考
- ユーザリサーチのスキル（インタビュー力、ユーザの思いを察する力
- 業界リサーチ（ヒットの規模を見る
ネットワーキング
初日の夜はネットワーキングがありました。 自分は OKR のテーブルで話をしたのと、pixiv ブースでセッションの詳細を話してきました。
OKR
- OKR は仮説検証の手法、達成できなければ方法が悪い
- 達成しても O が満たせないなら KR が悪い、ならば何を持って成果を評価できるか再検討する
- 組織規模によっては OKR 自体を PdM が定める（組織の OKR に沿った内容を見定める
- 個人レベルの OKR まで定めても、組織のコピペになるのであまり効率が良くない、という印象がある
pixiv
- エンジニアギルドは10年以上続いた取り組みに最近名前がついた
- 組織自体に拡張性を持たせ、属人化せずに取り組みが回っていくように考えた結果いまの構造になった
- エンジニア、デザイナーとしての良い取り組みが回り回って評価にも繋がっていく
- やってダメなら見直す、というアジャイル的思考で進めた
- 仕組み化にこだわることで続いてきた
変化の激しいプロジェクトを成功に導くには － 会議ドリブンなプロジェクトマネジメントメソッド
要約
- プロジェクトマネジメントは「仕事を動かす仕事」
- 会議をどう活用できるか
- メンバー全員でアジェンダを作る（みんなで決めること決めないことを話す
- 課題を持ち帰らず必ず次のタスクを決める（みんなで納得して次に進む
グッときたところ
- 会議が悪いわけではないが、今ままでの会議形態は変化が激しい、アジャイル、などの時代に合ってはいない
- 話す内容からして全員できちんと話す、他人事にしない
- 会議で話すのは前回からの進捗、プロジェクト全体の方向性、次回までの予定
- タイマーとかアジェンダを表示する2台目のモニターがあるとはかどる
打席に立ち続けられるプロダクトチームを作ろう
要約
- MOV というサービスだけでもいろんな取り組みがある
- 変化が激しい中でも高い打率を保つ
- DeNA における PdM の役割を定義（フィロソフィー
- 専門職として評価・育成するための組織化
- 失敗できる環境の提供
グッときたところ
- PdM は作る物を決める仕事だが、UX リサーチャーやデータサイエンティストとの連携が不可欠
- プロダクト価値を明確化し、狙った市場に届けられる人材が必要
- エンジニアやデザイナーと専門用語で会話できる知識
- 社内のスペシャリストとともに働くことでいち早く PdM としての経験を積める
- 完璧な人はいない、PdM としての得意な部分を伸ばしていく
プロダクトアウトな新規事業立ち上げのリアル
要約
- PdM のやるべきことは会社のフェーズによって異なる
- CPO のポエムから生まれた機能開発
- 時期によっては属人化を許容したり、徹底的に仕組み化したり
- PdM は最も価値がある（レバレッジが効く）ことをやる
グッときたところ
- PdM の仕事は多様、ベースとなるフレームはあってもそれだけでは解決できない
- いかに多くの事例を知っているか、が強みになる
- プロダクトアウトで生まれた機能をいかにビジネスにするか、も PdM が対応した
- プロダクトで解決するのか運用で解決するのか、俯瞰的に決めていく
- ローンチ直後は強いメンバーで乗り切った、あえて属人化した
- 規模が拡大してそれではまわらなくなった時にようやく仕組み化した
- 仕組み化は得意なメンバーをアサインして徹底的に対応
- クライアントの初期導入が悪かったので、まずは Onboarding から整えた
- PdM の仕事はプロダクト開発、セールス、CS の仕組み化、チームビルディング、と多岐にわたる
- 価値の最大化のための仕事を選ぶ
- 自ら解決しつつ、別の手段も常に考えておく
PMはどのようにバリューを出していくのか
要約
- PdM が必要になるのは迷いが生まれやすい新規開発や、ビジネス要件の強いプロジェクト
- ユースケースに精通するのは CS、だからこそ開発と CS は密に連携が必要
- PdM はマーケットやクライアント課題を特に理解しておく、なるべく第一情報に触れていく
- 無理なことはできるメンバーに頼る
グッときたところ
- 開発と CS 連携の重要性
- タスクは共有や管理のためすぐに issue 化する、ただしやらないなら閉じる（必要な過大ならいずれまた上がってくる
- 深い知見を無理に追うのではなくメンバーに頼る（これは他社でも述べられている
- チームビルディングに必要なのは権限譲渡、そして長期目線を共有すること
- メンバーが給料を気にせず働けるのが理想、そのためには希望の少し上を払い続けられれば理想（まだ試行錯誤中
- 小さいチームの時は特にミッションを意識し、みんなでどこを目指しているのかを認識合わせする
プロダクトマネージャーが知っておくべき、「OKR」を通じたこれからのチームマネジメント
要約
- Google の基本はボトムアップ
- 近年：プロダクトではなくプラットフォームを作る、オープン主義、エンプロイーエクスペリエンス、走りながら考える学習主義
- OKR は途中で変えてもいい、ただし日々の観測が重要
- 組織から社員まで一貫性を持たせる
- 内容を開示し、1on1 を通して習慣化する
グッときたところ
- OKR は目標から逆算する、ストレッチな目標にすることで挑戦する文化を創る
- OKR は個人の夢でもいい、それを組織に紐付けていく
- 導入目的が曖昧、経営陣の足並みが揃ってない、マネージャーが組織 OKR を理解してない、などが失敗あるある
- OKR は最大のインパクトを与える物に絞る
- 仕事を通した自己実現を是非考えてほしい
シリコンバレーPMのキャリアと働き方
要約
- シリコンバレーの方がデータドリブンは強い
- 会社がトレーニングを提供したり、横のコミュニティも強い
- PdM から先のキャリアパスは結構なんでもある
- PdM をやるなら何が得意か、何が好きかはきちんと整理しておく
グッときたところ
- シリコンバレーだと PdM 採用で SQL 書いたりする。それくらいデータに触れるのは日常
- アルムナイ組織と呼ばれる企業の卒業生コミュニティもつながりが強い
- 改善案を効果は別にしてもたくさん思いつける能力が必要
- 自分が使うアプリの改善案を出せる、またそれの否定案も出せる能力
- 企業によって PdM の出自は違う（Airbnb だとデザイナー系が多い
- 日本だとまだまだ逆境も多いが、小さく成功して実績を作るのが良いと思う
- 常にカスタマーという存在を意識する
感想
共通内容として感じたこと、まず PdM のミッション。
- 製品価値を上げること
- それを完成させるチームを作ること
その上で、以下の特性がある。
- PdM はプロダクトの最終責任を担う
- マーケット、ドメイン知識、チームメンバーのこと、企業文化、など関わる全てを知る必要がある
- できないことはメンバーに頼ることも必要になる
- あらゆる手段を講じて課題を解決することが期待される
各社で PdM に求める役割やスキル、育成、評価、採用の方法は手探りな状態という印象だった。 それでもデータドリブンや現場の知識など、エンジニアから PdM の働きをするとっかかりが多いということを知れたのは収穫だった。
その他の発表
こちらのブログでまとめてくださっています。 takaking22.com
【書評】エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド
読書感想文です。
雑感
メンターから技術戦略担当まで、マネジメントに関わる仕事のノウハウが管理対象の規模に応じて段階ごとに書かれている。 著者の体験に基づいているため事例がイメージしやすく、翻訳が良いこともあってかなり読みやすかった。
グッときたところ
コミュニケーションについて
- 一度で伝わると思わない。分かってくれると思わない。本当に伝えたいことは粘り強く分かるように何度でも伝える。
- 業務外の内容も含め、お互いにコミュニケーションをするのが当たり前な空気感を日頃から醸成していく。
- メンティー相手の場合など、自分が目上の場合は特に自分からコンタクトを心がける。
- 評価を伝える際にはきちんと長所も時間をとって伝える。
チーム作りについて
- ルール化や仕組み化も手段の一つ、こだわりすぎない。何を解決したいのかを常に意識する。
- コードレビューや技術選定の基準などを明確に言語化することで、チームでのやりとりや将来の引き継ぎもやりやすくなる。
- チームが見積もりや開発をできるような土台は自ら作り上げる。
- 部下に対して定期的継続的にフィードバックを行う。それを実現するために常に部下を観察し長所や短所を理解する。