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までマネジメントスキル向上ガイド
読書感想文です。
雑感
メンターから技術戦略担当まで、マネジメントに関わる仕事のノウハウが管理対象の規模に応じて段階ごとに書かれている。 著者の体験に基づいているため事例がイメージしやすく、翻訳が良いこともあってかなり読みやすかった。
グッときたところ
コミュニケーションについて
- 一度で伝わると思わない。分かってくれると思わない。本当に伝えたいことは粘り強く分かるように何度でも伝える。
- 業務外の内容も含め、お互いにコミュニケーションをするのが当たり前な空気感を日頃から醸成していく。
- メンティー相手の場合など、自分が目上の場合は特に自分からコンタクトを心がける。
- 評価を伝える際にはきちんと長所も時間をとって伝える。
チーム作りについて
- ルール化や仕組み化も手段の一つ、こだわりすぎない。何を解決したいのかを常に意識する。
- コードレビューや技術選定の基準などを明確に言語化することで、チームでのやりとりや将来の引き継ぎもやりやすくなる。
- チームが見積もりや開発をできるような土台は自ら作り上げる。
- 部下に対して定期的継続的にフィードバックを行う。それを実現するために常に部下を観察し長所や短所を理解する。
リーダーの仕事について
EOF2019 に参加してきた
こんにちは、じぬ（@reximology）です。
EOF 2019 というイベントに参加してきました。これはエンジニアリングマネジメントを主題としたカンファレンスです。 eof.connpass.com
ここでは参加したセッションと、特に印象深かった点をまとめます。
はじめに
参加したセッションは次の通りです。（タイムスケジュール）
- Opening Session 私たちの現在地点、向かうべきところ。
- 正しいものを正しくともにつくる
- 筋肉質なエンジニア組織を目指して ~失敗と成功から学ぶエンジニア組織の作り方~
- 社員100人規模のWebサービスにおけるエンジニアリングマネジメント
- エンジニア採用どうしてる？ 〜エンジニアのトップが語る、2019年の採用活動の本音〜
- 持続可能なエンジニア組織のデザインに必要な事とは
- 学習する組織の作り方
- DMM改革の1年、その実際と反省
Opening Session 私たちの現在地点、向かうべきところ。
本イベントの概要説明などです。カンファレンスの価値は廊下にある（セッション後に参加者同士でコミュニケーションがとれる場があること）という話をしてました。そこに繋がる流れで隣の人となんかしゃべってくださいはびっくりしましたが、どうにか自己紹介して交流できました。
正しいものを正しくともにつくる
カイゼン・ジャーニーの著者である市谷 聡啓さんのセッション。
www.slideshare.net
https://www.amazon.co.jp/dp/B078HZKLMBwww.amazon.co.jp
要約
- 不確実性の多い序盤は選択肢を広くとり、仮説検証を繰り返してモデル化することで選択肢を狭めていく
- 検証をすべて PO に任せるのは間違い、チーム全体（の各個人）で取り組むべき
- 仮説検証に応じた思考を可視化し、みんなで意見を言い合える環境にする
- 検証に応じて可変性のある、スプリントと機能完成の中間となるマイル（ジャーニー）の提案
グッときたところ
- 不確実性があるのは当然、それへの対処を明確に言語化されているのは非常に参考になる
- スプリントという決まった大きさの物を仮説検証に合わせて柔軟に対応するため、ジャーニーという新しい単位の提案
筋肉質なエンジニア組織を目指して ~失敗と成功から学ぶエンジニア組織の作り方~
要約
- 表題の通り、自らの失敗を交えた取り組みの紹介
- Cheif EM になったが、現場エンジニアのマインドのままだったことが失敗の大きな原因
- 変化を恐れず、これまでの積み上げに頼らず、常に自分をアップデートするという覚悟
- 部長との対話を増やし、事業部の要望に応えつつ組織の成長を担うのが EM の仕事
グッときたところ
- 1on1 にてもうあとがないですよ、と言われてしまうほどに自分の強烈な失敗の話をしてくれたのは衝撃だった
- エンジニアと EM ではマインドから違うという点、それを認識してきちんと自身を対応させたのは見習うべき
- 組織はリーダーの器以上にはならない、だからこそ自分を伸ばす必要がある、という金言
社員100人規模のWebサービスにおけるエンジニアリングマネジメント
要約
- スタートアップ初期、10人〜30人、それ以上、というフェーズごとに CTO として何をしてきたのか
- スピード優先で開発してきたことによる負債や、人数増加によって手が回らなくなる、など正に成長する企業がぶつかる壁の話
- 30人を超えると CEO から権限を委譲させた、スケールのために自分も CTO を交代した
- マネージメントとはいろんな課題を整理してなんとかする、そもそもが曖昧な仕事である
- 他人の給料が上げられるのならその人は配分をもらう資格がある、というのがマネージャーの給料が高いことに対する解釈
グッときたところ
- 情シスの設置や企業の社会的責任など、企業が大きくなるにつれて現れる課題の話は新鮮だった
- マネージャー育成の話は、自分がいま読んでいる本と通じる箇所も多く参考になった
- 技術力が高いとは限らないマネージャーの価値とは何か、が給料面の解釈含めてきちんと言語化されていた
エンジニア採用どうしてる？ 〜エンジニアのトップが語る、2019年の採用活動の本音〜
要約
- Classi, Repro という二社での採用に繋がる取り組みの話
- 優れたエンジニアは面白い課題を求める、会社としてそれを提供するためには数年先を見据えた取り組みをきちんと検討しておくことが必要
- 採用に関してはとにかくタッチポイントを増やしている、社内イベントに呼んだり技術相談の場を作ってみたり
- 採用面接やリファラルに向けて社内への取り組みも重要、面接に出られるようにするための研修をする会社もある。Repro では毎週役員レベルの会議に関して議事録公開や質問受付の時間を設けている
- 採用がうまくいかなかった場合、行った会社の人とコンタクトできるなら答え合わせ（なぜ採用できなかったか）をすることもある
グッときたところ
- 自身もリファラルを考えたときにいまいちうまくイメージできなかった経験がある。なのでそれに向けて社内への呼びかけや情報伝達を行う取り組みは良いと感じた。
- カンファレンスのスポンサーになるなど、採用に対して効果はあるが測定できない、そのため予算を確定しにくい、というのはたしかにと思った。
持続可能なエンジニア組織のデザインに必要な事とは
要約
- 創業から5年間の取り組み（エンジニアが0人から40人になるまで）
- 初期は知名度皆無、なのでエージェントを訪問してその場で一緒に書類審査するなど、泥臭く信頼関係を構築していった
- 運営を引き継ぐという事業の特性上、開発者の暗黙知は消滅を避けられない
- どんなに人手不足でも新規入場者をすぐ高負荷なチームには入れることはしないという決断
- ビジネスが安定してくることによるチャレンジの不足、それによるシニア技術者の不満
グッときたところ
- エージェントとの信頼関係、と言う観点
- チャレンジ不足と言う不満は現場からは「でも事業的に仕方が無いですよね」、という形で現れていた
- 実際に不満があるかどうかよりも、事業が成功した結果チャレンジが不要な物であると捉えられていることこそが大きな問題
- 成長した先には光があるべき、シニアが憧れを受ける組織であるべき
- 事業貢献と技術的チャレンジは双方が必須、前者がなければそもそも価値を満たせないが、後者がなければエンジニアの時間を切り売りしているだけ
学習する組織の作り方
要約
- フロント技術だけで見ても学習するべきことはどんどん増えている、時間は無限に必要
- 書籍「学習する組織」から学んだ五つの観点：自己マスタリー、共有ビジョン、システム思考、メンタルモデル、チーム学習
- 毎週作った物を見せ合う場を用意し、アウトプットとそのためのインプットの仕組み化
- 社内 ISUCON やハッカソンによる体感を通した学習
- 自分がエンジニアコミュニティで経験してきたことを社内で再現した
グッときたところ
- 製品版にはセキュリティなど様々な制約が必要
- それを外した状態でどこまで速度が出るのか、どんな品質で動くのか、という体感を通して理想を得る
- 自身がエンジニアコミュニティで得た体験を社内で再現するという観点は新鮮だった
DMM改革の1年、その実際と反省
要約
- エンジニア/デザイナーだけで1000人近い組織をテックカンパニー化することが与えられたミッション
- マネジメント観点以外にも様々な視点（売り上げを元に並べてみたりやサークルやチャット上の交流など横のつながり）で組織構造を眺め、その結果からまんべんなくヒアリングを実施して現状を把握した
- 課題、その課題に対する現場がどんなフィルターを通して解釈しているか、そこから逆算して現場の状況や目的はどうか、を理解していく
- ミッションやビジョンを通して現場における行動までを説明できる一貫したストーリーを整える、それが企業における文化
- 情報公開の場所やタイミングを統一してアクセスを容易にし、自分からの発信とインタビューなど外部を通した発信を重ねることで情報に浸透圧をかけていく
グッときたところ
- 正しく組織をハックするといった内容
- 様々な視点を通した組織の俯瞰、偏りのないヒアリング対象の選定
- トップにあるミッションからそれを具現化していく戦術までの一貫したストーリー
- 自分からの発信をどうやって現場に浸透させるかまでの具体的な見通し
- ヒアリングを通して見えた課題の解消をパッケージ化し、少しずつ現場に浸透させてその成功を認めることで各メンバーに理想的振る舞いのメンタルモデルができていく、それこそが企業の文化
- 何気ない会話の中にミッションが混ざる、例えば slack のスタンプにそれが垣間見える、それこそが文化の浸透
振り返り
イベントに関して
弊社も含めてやはり課題は似たようなものが多いんだなと言う印象です。組織規模の拡大によって無視できなくなる技術負債、エンジニア採用、継続的なチャレンジ課題、文化醸成、などなど。 マネジメントやチーム作りは新卒やよほどの技術スペシャリストでなければ一度はぶつかる課題かと思うので、エンジニアならたいていの人にとって身近な話題だと思います。 それだけに講演を聴くだけでもいろいろと学んだ気になることが多いです。ですがそこでとどめず、自分の振る舞いや自分のチームにおいてどう活かすか、まで踏み込めると正しく血肉にできるのかな、と感じます（自戒）。
その他の講演
聞けなかった講演の資料をまとめようと思ってましたが、こちらでまとめてくださってたので貼っておきます。 medium.com
