【勉強会】VP of Engineering Meetup by CA #3 に参加しました
前回に引き続き参加してきました。
自分もプログラマなので、プログラマ関連の話はすぐに聞けますが
マネジメント周りの話はなかなかなく、他社の事例を聞けるため
勢い良く参加しました。
※メモはスライドに書かれている内容を書かず
なるべく登壇者が話した内容をメモするようにしています。
なので、飛び飛びなところもあります。
概要
内容
イベント趣旨説明
まず、参加者全員で「VPoEとはどういうものか？」というのを定義しました。
前回と同じ流れだったので特にメモはしていないのですが
個人で定義が曖昧なので、この説明は毎回必須だなと思いました。
スライドの内容は前回と同じだったはずなので
前回開催されたブログを一時的に掲載します。
『成果を出し続けるエンジニア組織を目指してやってること』
登壇者がやっている内容を共有していただきました。
以下、メモした内容です。
ウエパはエンジニア管轄とディレクター管轄があり エンジニア側のマネージャーにいる。 そして、各種特化したチームがあり、全体で20人強 CTO, VPoEの役職はない。 マネージャーがVPoE的役割 技術ボードがCTO的役割 VPoEの定義は 成果を出し続けられるエンジニア組織を作っていくこと じゃあ、何を目指してやるものか？ ビジネス的に動けるエンジニア組織となること マネージャー業務に関して一例をあげられた 特に時間を取っているのは「他部署のマネージャーや担当執行役との定期的な情報共有やMTG」 組織的に解決したいことがあった際に呼ばれる。 問題に当たったら先人の知恵を借りて物事を進めている。 1人で解決できなかったことがないくらい先人の知恵を借りている。 メンバーとの対話ポイント 1on1 No雑談、目標進捗を話すことは少ない 週ごとにテーマを決めての会話（10枚程度カードを用意していて、成果や不満、悩みが書かれており、1回につき2, 3枚ピックアップして話す） 雑談から話すよりもしっかりテーマが決まっているのでスムーズに進む。 やる側としてコーチング時間であることを意識している。 参考書籍は「ドラッガーさんに教わったIT技術者が変わる50の習慣」 技術スキルと人間スキルが成長のための両輪であることを参考にした。 内発的動機を1on1を通じて加速させるようにしている。 対話ポイント 権限委譲 マネージャーレベルだけでなく、メンバーレベルで意識してもらうことが大事。 若手ほど権限委譲で「伸びる！」マッチして掛け算レベルで成長する。 参考書籍は「経営者の条件」 仕事を「人」に合わせること 成果へのありがとう これは難しい。 感謝の「ありがとう」の言葉より、同調が大事。 メンバーからは一歩引かれた形に見られてしまう。 マネージャーは真摯な態度が大事。 個人ビジョンに沿う目標の設定 3ヶ月毎に実施。マネージングで会社の目標と個人目標をマッチングさせること。 コトに向かう コトを成すことに精一杯取り組む。 チーム作りで「カンバン方式」がオススメ。 仕事が見える化された。 タスクの流れが明確になった・・・などメリットがあった。 上記をやってから施策をやっていくのが良い。 経営層の考えをメンバーに伝達 経営層の端的な言葉を、まず自分で噛み砕くことをして下に伝えるようにする。
途中のスライドまでしかメモがないのは、時間がなくなったためです。
逆に時間がなくなるぐらいたくさんのことをやっていて共有したいことがあるという現れだと感じました。
『組織をシステム化するReactive Management』
www.slideshare.net
タイトルの発想がとてもユニークだと思いました。
また、内容も的を得ているなと思うものでした。
以下、メモした内容です。
VPoEはマネジメント？ 複雑な人間関係、自分でコントロールできないところもある。 Cyberでも定義が曖昧だが、必ず必要な役割である。 VPoEに必要なところをカテゴライズして、直列化することにより ビジネススピードを拡大させる必要がある。 リアクティブマネジメントとは？ 元はリアクティブ宣言 マネジメント対象の行動を常に観察し、行動に対してフィードバックを即座に返す マネージャーは「観察」が重要である。 マネージャー自身は多数の「仕事の定義」を持ち「観察」を行い、何か（イベント）があれば即応する。 半年前のことを言われても「今更その話」となってしまう。 参考書籍：パフォーマンス・マネジメント 採用・退職・ヒューマンマネジメント・開発プロセスをKPTを使った振り返りでカイゼンすることによりチームの耐障害性を高める。 スキルや経験は人に宿るため「その人」だからできることがある（Not その人にしかできない） どんな人がいるチームかによってフォーメーションは弾力的に変える。 開発責任者は結果論で決まるので、柔軟に決めていく。 自分がボトルネックになってはいけない。自分からpullしていたらもたない。 Evernoteに会話メモを残し、メモリスタックをどこでもロード可能にする。 外部にタスクスケジューリングを任せる。 マネージャーの評価はどうされるべきか？ そのまま評価指標・基準に利用することも可能 ・即応性 ・耐障害性 ・弾力性 ・メッセージ駆動 マネージャーとしての価値はその再現性（immutability）の高さ いつでも、どこでも、どんな状態でもReactivityを出す。 今プロダクトを作っているチームと同等のものを違う人、地域で作れるようにしないといけない。 組織というのは自分の思っているより3期ぐらい遅れてやってくる。（後追いで来る） 人は誘導できないから、後からついてくる形となる。 マネージャーは常に次のチャレンジをし続けるようにして「次も任さればいいチームを作る」という認識を持ってもらう。 VPoEは結局マネージャーである。 アイデンティティとして「自分はエンジニアである」と考えていることが重要 Web世代の人は技術をクリアした上でマネージャーとなっているため 一昔前のマネージャーとは違うもの。 名刺にもマネージャー、エンジニアとも書かれている。 エンジニアにアイデンティティを持っていて、いつでもどこでもどんな状況でもReactivityを再現できることに強みを持つ Webエンジニアが作るマネージャーの再定義 マネジメントは技術である エンジニアでやっていることをマネージャーになっても同じことをやればよい。
ガッツリなマネージャー論かと思いきや
エンジニアでもわかるような内容だったと思います。
『ゼロからのエンジニア組織作り（仮）』
スタートアップから携わっていて、会社の成長につれての話を聞くことができました。
以下、メモした内容です。
設立期は事業の立ち上げが最優先、安定した品質のゲームをいかに速くリリースできるか？にフォーカス 人数が少なかったので、1人1人の当事者意識が自然と高まった。 キーマンの採用が速いかった。 コミュが密。 採用担当者同士で採用基準、判断基準のすり合わせ 有識者にとにかく聞く、巻き込む 1人で判断しない 設立的には技術面の魅力が語りにくい（魅力的な技術よりも事業立ち上げが最優先だったため） 成長期 うまく行ったこと 新たなリーダーの抜擢、成長 若手の活躍、成長 月イチの1on1を開始 事前にシートを記入して面談する ただし工数が非常に重く感じていてカイゼンを考えていくところ 1年目限定新卒朝面談 読書会の開始 変革期 新たな技術の習得が必須になった。 既存コードを捨てて再設計（サーバサイド） 技術チャレンジを事業成果に 技術的負債の返済を積極的に VPoEとしてどの部分を意識してやってきたのか？を絡めて話してもらえれば もっとわかりやすいと思った。
具体的な業務内容を期ごとに書かれており
とてもわかりやすかったです。
LT
メモを取れる状態ではなかったので、スライドだけ共有します。
後1つスライドあったのですが、見つからなかったため
掲載され次第ここに追記します。
全体を通しての感想
今回も他社の事例を聞くことができて、とても参考となりました。
また参考書も豊富だったので読んでみようと思います。
後、自分の会社でやっていることを他社でもやっていてちょっとやり方が違うだけ
というのもいくつか見られたので、そろそろまとめられるのでは？と思いました。
VPoEだったら、これはやっとけ！みたいなものです。
そして、アンケートに書き忘れましたが
VPoEはエンジニア出身が多いと思うので、どのようにビジネスサイドに入っていって
ビジネス側とエンジニア側を円滑に回しているのか？というのも聞きたいと思いました。
また次回も参加します。
