エンジニアとマネージャーは、いつも勝負をしているのだと思う

by gree_tech

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Copyright © GREE, Inc. All Rights Reserved. Confidential なぜこのテーマで話そうと思ったか ● メンバーの成長が重要トピックというのは合意できる。だけど、どのくらいフォーカスすべきか、わからない ● 特に、事業との関係性はどう捉えておけばいいのか ● 会社として中期経営計画があり年度予算があるなかで、「成長にコミット」はどう接続するのかよくある悩み

Slide 8

Slide 8 text

Copyright © GREE, Inc. All Rights Reserved. Confidential なぜこのテーマで話そうと思ったか ● 成長：事業成果に還流される変化 ● 「失敗を許容するために、能力不足は許容できない」 ● 「不確実な環境では知識は動く標的になるが、そんな環境で新たなスキルを学ぶことが、およそどの業界でも競争するうえで不可欠になっている」成長は事業にとって良いことだ

Slide 9

Slide 9 text

Copyright © GREE, Inc. All Rights Reserved. Confidential なぜこのテーマで話そうと思ったか ● WILL = 本人の望む成長 ● MUST = 組織がメンバーに望む成長 ● 不確実な事業・業界にいる場合、重なりを大きくする事にコミットする人が必要（それがマネージャー？）成長とWILL / CAN / MUST CAN WILL MUST 発表時「NEED」と記載してた部分を「 MUST」に変更しました

Slide 10

Slide 10 text

Copyright © GREE, Inc. All Rights Reserved. Confidential なぜこのテーマで話そうと思ったか重ならないMUSTへの対応 ● 組織構造で対応 ○ 重なるメンバーを探す ○ 専門職集団として組織化 ● MUST自体を動かす ○ 極端に言えばBizDev的な重ならないWILLへの対応 ● 良いビジョン、良い先輩、良いコード ● 本人の気づきを見逃さない成長とWILL / CAN / MUST CAN WILL MUST

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Copyright © GREE, Inc. All Rights Reserved. Confidential なぜこのテーマで話そうと思ったか ● 一人のメンバーが全てのMUSTに対応できるわけが無いので、すべての、エンジニア以外も当然含めた、メンバーが成長できる体制を整える必要があると思っています ● が、今回は、資料の都合上もあって、エンジニアの成長にフォーカスした内容になっています補足：チームとして成長していく

Slide 13

Slide 13 text

Copyright © GREE, Inc. All Rights Reserved. Confidential なぜこのテーマで話そうと思ったか ● 多分、一番、頭が痛い問題：事業成果との兼ね合い ● 事業成果を、最大化すべき目的変数ではなく、遵守すべき制約条件と割り切って捉える ● 目的変数ではない＝予算を更に超えて利益貢献することを、自身の仕事の目的化しない ● 制約条件である＝予算を遵守する事は自身の仕事の必須条件事業成果は制約条件と割り切る

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Copyright © GREE, Inc. All Rights Reserved. Confidential 「戦場」を定義するマネージャーの弱み(Weaknesses) ● 技術力 ● 「自分より優秀な人材を採用する」ゆえのジレンマ ● 「マネージャーの成長のためにメンバーがいるのではない」マネージャーの脅威(Threats) ● （もちろん人によりますが）ライフイベント。育児と介護 ● 自分の場合、数ヶ月単位の育休を２回取っている My SWOT分析

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Copyright © GREE, Inc. All Rights Reserved. Confidential エンジニアの成長と組織構造の関係キャッチアップフェーズ ● １エンジニアとしてバリューを発揮できるようになるまで ● 学習すべき事柄に関して、自分より強いチームメンバーがいる開拓フェーズ ● キャッチアップの次というか ● 学習すべき事柄に関し、自分より強いチームメンバーがいないマネジメントスキル等は置いておくはじめに：成長フェーズの分類

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Copyright © GREE, Inc. All Rights Reserved. Confidential 組織構造によるキャッチアップサポート ● メンター制度等色々あると思いますが、１つだけ ● 大切だと思っているのは、成長スピードについて認識を合わせるというか、心理的安全性を与えるようにすること ● キャッチアップに3ヶ月かけてよいのか、１年かけてよいのか、3年かけてよいのか、最初は本人は全然わからないと思う。 ● 直属の上司とも当然認識を合わせる必要があるが、職位がより上位の人も同じ認識であるということが、本人の落ち着きに繋がるという感想上司の上司と1on1できる

Slide 30

Slide 30 text

Copyright © GREE, Inc. All Rights Reserved. Confidential 組織構造による開拓フェーズのサポート ● 新サービスの開発リーダー。王道の成長パターンだと思いますが。 ● 肌感として、リーダーを任されたメンバーは会社に残りやすく、サポートをお願いしたメンバーは（リリースをしっかり見守った上で）転職していくことが多い ● とはいえリーダーを一人に絞るのは大原則新規開発案件のリーダーポジション

Slide 31

Slide 31 text

Copyright © GREE, Inc. All Rights Reserved. Confidential 組織構造による開拓フェーズのサポート研究開発の一側面 ● 重要だけど（眼の前の事業オーダーに比べると）緊急でない ● 取り扱うチームを分けるのがセオリー？ ● 各メンバーの「成長」に対する波及効果を考慮して、現状はセオリーに従わない ● ネガティブな面も勿論ある ○ 一人一人にコンテキストスイッチの切り替えやマルチタスク管理といったオーバーヘッドが入るので、負荷の総量があがる研究開発案件は兼任体制で

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Copyright © GREE, Inc. All Rights Reserved. Confidential 相互学習しやすい組織 ● 基本的に発動条件厳しすぎると思いますが、僕らの場合、効果としては非常に強かった。外から観測していて ● まず雑談しやすい ● 情報共有とか勉強会とか発生しやすい ● マウントを取るメンバーが発生しづらい ● 一般化すると、社内のソーシャルグラフを利用するということか新卒同期を集める

Slide 36

Slide 36 text

Copyright © GREE, Inc. All Rights Reserved. Confidential 指示系統ラインが強くなりすぎないようにする ● （たぶん）いわゆるスクラムマスター ● マネージャーではなく、１メンバーが仕切るのが、というか仕切ってくれるメンバーがいるのが、非常に助かっている ● マネージャーが仕切るのと、メンバーが仕切るのでは、おそらく他メンバーのやり易さに違いが生じるファシリテーター

Slide 37

Slide 37 text

Copyright © GREE, Inc. All Rights Reserved. Confidential 指示系統ラインが強くなりすぎないようにする ● ファシリテーターが入ることで、要件定義と開発が「発注と受注」の関係に陥らないですむ ● ファシリテーターがいない場合、よっぽど気をつけないと情報格差が生まれやすい（個人の主観です） ● 発注と受注だけでなく、強いメンバーがファシリテーターをしてくれれば、マネージャーとメンバーの間の情報格差も取り除きやすい ● チームで開発してる感が出るファシリテーター

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Copyright © GREE, Inc. All Rights Reserved. Confidential キャッチアップフェーズに適したシステム ● ぼくらの場合、内製BIツールのフロントエンドの改善 ● 緊急性が低い => 「あったら便利」程度のチケットにする ● 障害に繋がりにくい => 何もしなければ障害が起こりづらい ● コードをたくさん読める => それなりにデカイ ● 成果が見えやすい => フロントエンドなのでわかりやすい　入社メンバーが最初にやるチケットがある

Slide 42

Slide 42 text

Copyright © GREE, Inc. All Rights Reserved. Confidential キャッチアップフェーズに適したシステム僕らの場合 ● 以前、TreasureData社には大変お世話になりました ● 今ならAWSやGCPにお世話になっております ● 中の人とコミュニケーション取れるレベルの規模の企業の製品を利用していれば、非常に色々な事が勉強できる ● OSSの利用も似たような感じだと思う技術的に強いベンダーのサービスを使っている

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Copyright © GREE, Inc. All Rights Reserved. Confidential 開拓フェーズに適したシステム ● 何より（そんなにたくさん）仕様を切らなくていいところ ○ チーム全体としてコミュニケーションコストが少なくなる ● モダンな技術を試す事ができるマイグレーションの嫌なところ ● 泥臭い仕事がたくさんある ● 既存システムがブラックボックス化してると本当に大変 ○ いつでもマイグレーションできるような状態をキープするのが大切（言うのは簡単、、）マイグレーションの良いところ

Slide 45

Slide 45 text

Copyright © GREE, Inc. All Rights Reserved. Confidential Engineer vs Manager ● 感情からスタートして、「成長」にフォーカスして良い理由を後付けしました ○ 不確実な事業においてはWILL / CAN / MUSTが重なるようそれぞれを動かさなければいけない。その際、事業成果は制約条件として割り切る ● そのあと、特にCANを動かす（成長支援する）のに向いていると思われる組織構造やシステム構造の事例を列挙しました本資料のサマリ

Slide 46

Slide 46 text