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

Copyright © GREE, Inc. All Rights Reserved.Confidential
[公開版]エンジニアとマネージャーは、
いつも勝負をしているのだと思う
グリー株式会社開発本部
森田想平

Engineer vs Manager
● 感情からスタートして、「成長」にフォーカスして良い理由を後付けする
● 「成長」に影響を与える組織構造やシステム構造の事例を列挙する
● 成否がはっきりしない事例が多いですが、皆さまの思考の刺激になれば幸
いです
本資料のサマリ

Engineer vs Manager
● なぜこのテーマで話そうと思ったか
● 「戦場」を定義する
● 成長と組織構造の関係について
● 成長とシステム構造の関係について
目次

このテーマで話そうと思った
きっかけ

最近優秀なメンバーが他社に転職し、
自分にちょっと腹がたった
タイミングで登壇の話が来た

なぜこのテーマで話そうと思ったか
● 優秀なエンジニアが更なる成長を求めて旅立ってしまう
● 中途採用候補者の判断基準が「自分が成長できる環境か」
● 競合他社より成長にコミットできる環境を用意できていない事に対する自
分への危機感
よくある悩み

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

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

● WILL = 本人の望む成長
● MUST = 組織がメンバーに望む成長
● 不確実な事業・業界にいる場合、重なり
を大きくする事にコミットする人が必要
（それがマネージャー？）
成長とWILL / CAN / MUST
CAN
WILL MUST
発表時「NEED」と記載してた部分を「 MUST」に変更しました

重ならないMUSTへの対応
● 組織構造で対応
○ 重なるメンバーを探す
○ 専門職集団として組織化
● MUST自体を動かす
○ 極端に言えばBizDev的な
重ならないWILLへの対応
● 良いビジョン、良い先輩、良いコード
● 本人の気づきを見逃さない
CAN
WILL MUST

重ならないCANへの対応
● 成長してもらう必要がある
● 本資料で紹介する事例はだいたいココ
に含まれる
CAN
WILL MUST

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

● 多分、一番、頭が痛い問題：事業成果との兼ね合い
● 事業成果を、最大化すべき目的変数ではなく、遵守すべき制約条件と割り
切って捉える
● 目的変数ではない＝予算を更に超えて利益貢献することを、自身の仕事
の目的化しない
● 制約条件である＝予算を遵守する事は自身の仕事の必須条件
事業成果は制約条件と割り切る

● メンバーの成長にもっとコミットできないかという課題意識
● 事業成果を制約と割り切り、その中でいかにメンバー個々人の
WILL/CAN/MUSTを重ねるか、という事により意識的に取り組みたい、と
いう自分の気持ちに気づきました
まとめ

「戦場」を定義する
● 完全に気分の問題ですが
● 太古の昔からプロフェッショナルなエンジニアは、甘くない
● 喰うか喰われるか、くらいの気持ちで取り組まないと死んでしまう
「戦い」だと認識する事の効用
● 戦いだと思えば、闘争本能が打ち手を考えてくれる
そもそも、なぜ「戦い」なのか

● 「戦い」に際しては、勝算の見える戦場を決定したい
● 「技術力勝負」
● 自分がなんでも知ってれば、なんでも教えれるはず
● あこがれるが自分の場合は厳しい
● 一般的にも厳しいのでは
戦場の決定

● 技術的に優秀なメンバー vs 技術的に平凡なマネージャー
● SWOT分析してみる
お互いの状況を比較してみる

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

マネージャーの強み(Strength)
● 組織構造の決定権限
● システム構造の決定権限
● 評価基準の決定権限
● 予算を取りに行く力
マネージャーの機会(Opportunities)
● 上司がえらい人
● 部下が優秀な人
My SWOT分析

● 本講演の主旨からは外れますが、お金で成長を支援する（というか、その
ための予算を確保する）のも、マネジメント層の大切な仕事だと思います
お金で解決できる事がある

● 「強み」と「機会」を最大限活用して、成長環境を整備しよう
● 塔の積み上げ勝負より、積み上げた塔の重量に耐える勝負
● この設定なら多少は勝負になるかもしれない
「勝ち筋」を整理する

ここからは事例を
列挙する形になります

すべて個人の感想です

エンジニアの成長と組織構造の関係
話の枕：現在の組織構造
もりた 
アナリストT プロマネT  エンジニアT  リサーチャーT

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

各フェーズのサポート
● キャッチアップフェーズのサポート
● 開拓フェーズのサポート
両フェーズ共通
● 相互学習しやすい組織
● 指示系統ラインが強くなりすぎないようにする
事例の分類

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

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

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

● 中に専門家がいないので、外の専門家に面倒を見てもらう
● 本人の能力依存だが、良いフィードバックループが回り始めている
出向

● 中に専門家がいないので、外の専門家に面倒を見てもらう
● 始めたばかりで、試行錯誤中
技術顧問制度

● 「チームで一番強いからマネージャー」というのはアンチパターン
● もちろん本人のWILL次第で、本人が望めば問題ない
早くからマネージャーにしない

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

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

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

エンジニアの成長とシステム構造の関係
● キャッチアップフェーズに適したシステム構造
● 開拓フェーズに適したシステム構造
事例の分類

キャッチアップフェーズに適したシステム
要件
● 緊急性が低い
● 障害に繋がりにくい
● コードをたくさん読める
● 成果が見えやすい
入社メンバーが最初にやるチケットがある

● ぼくらの場合、内製BIツールのフロントエンドの改善
● 緊急性が低い => 「あったら便利」程度のチケットにする
● 障害に繋がりにくい => 何もしなければ障害が起こりづらい
● コードをたくさん読める => それなりにデカイ
● 成果が見えやすい => フロントエンドなのでわかりやすい
　
入社メンバーが最初にやるチケットがある

僕らの場合
● 以前、TreasureData社には大変お世話になりました
● 今ならAWSやGCPにお世話になっております
● 中の人とコミュニケーション取れるレベルの規模の企業の製品を利用して
いれば、非常に色々な事が勉強できる
● OSSの利用も似たような感じだと思う
技術的に強いベンダーのサービスを使っている

開拓フェーズに適したシステム
● ここ最近は、クラウド化という大きな流れ
● 「コスト削減」という錦のみはた
● オンプレからAWSへの移行、またGCPの新規活用を通して、たくさんの成
長機会を得ました
マイグレーションのチャンスがある

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

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

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

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

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

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

Plus de gree_tech

Plus de gree_tech (20)

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