優秀なエンジニアがさらに成長できる場を目指して
本セッションに登壇した森田氏はグリーに入社して10年目。マネージャー歴7年、シニアマネージャー歴5年という中堅で、グリーの男性社員初の長期育児休暇を2回取るなど公私のバランスを取りながら働いてきた。所属部門は、インフラや情シス、データ、デザイン、セキュリティなど、事業部を横断的に見る開発本部で、森田氏が見ているアナリシス＆データエンジニアリンググループは3人のマネージャーに15人のメンバー、その半分がエンジニアといった構成だ。
森田氏は、高い技術力でカリスマ的に引っ張っていくタイプではなく、自分よりも優秀なメンバーもいる中で「マネジメント」に課題感を持ってチーム運営に取り組んできた。会場ではマネージャー職にある聴講者の3分の1ほどが「部門に自分よりも技術力の高いエンジニアがいる」と答えており、他の組織でも多い悩み・課題のようだ。
「一般的に、優秀なエンジニアがさらなる成長を求めて旅立ってしまうことは多いと思う。もちろん、個人的なキャリアを考えれば転職は悪いことではないが、マネージャーとしては優秀なメンバーには残ってほしいので、そのために組織として何ができるのかを考える必要があった。また、中途採用社員の入社の判断基準の多くが『自分が成長できる環境か』であることもあり、競合他社より成長を支援できる環境を用意できないかと考えた」
事業貢献は自分の職務に対する制約条件と割り切る
成長支援を考える上で大切なのが「WILL＝本人が望む成長」「CAN＝できること」「MUST=組織がメンバーに望む成長」のフレームワーク。マネージャーは、WILL / CAN / MUSTの重なりが大きくなるよう努力する必要がある。その中で本セッションで語られた成長支援は「CANを動かすこと」に該当し、後半に出てくる事例のほとんどはCANに相当する。
WILL / CAN / MUSTの重なりはどのようにして大きくできるのだろうか。まず、組織が求めながらも、そのスキルや意欲を持つ人がいない時、どうするのだろう。森田氏は、既存チームの外にいてWILLを持っている人を見つけだし、その人をチームに組み込み専門職集団として組織化していくことでMUSTへの対応を行っているという。また、事業ニーズのハックによってMUSTを動かすこともあるという。
また、WILLについては、「良い先輩、良いコード、良いビジョンが重要で、良いものが周りにあれば正しい方向にWILLが向くはず」と語った。
次に、マネージャーとして成長にコミットする事を目的とした場合、「事業貢献」をどう考えればいいのか。森田氏は「もうここはポジショントークでいいのでないか」と語り、「最適化には目的関数と制約条件があるが、事業貢献は自分の職務に対する目的条件でなく、制約条件であると割り切っていいのではないか」と言い切った。
「目標や予算はコミットするが、目標を超えた利益追及を求めることはしない。それよりも組織としての成長を最大化すべき目的としたい。もちろん利益追求を目的関数としているマネージャーもいるべきで、組織の中でのバランスを取れたらと考えている」
例えば既に事業目標の達成が見込めている場合、事業貢献効果が高くともWILLにマッチしないプロジェクトは寝かせるといった判断を、意識的に行うわけだ。
技術的に弱いマネージャーのSWOT分析から見えるもの
成長支援という仕事をなぜ「戦い」と捉えるのか。森田氏は「気分的な問題だが、プロフェッショナルなエンジニアは厳しい存在であり、マネージャーを冷静に値踏みしている。戦いだと認識すれば、闘争本能がさまざまな打ち手を考えてくれるのではないか」と語る。
「これは戦いである」と定義したので、次はどこを戦場にするかを検討する必要があると話す森田氏。そして、戦いの場を検討するにあたってSWOT分析を行ってみたという。
SWOT分析してみると、森田氏のマネージャーとしての「弱み（Weaknesses）」は「技術力」である。「脅威（Threats）」としては年代的なこともあり、ライフイベント（育児・介護）に時間を取られることがある。
逆に「強み（Strength）」としては、組織構造やシステム構造の決定権限を持ち、評価基準の決定権限も持つ。社内的に予算を取りに行く力も強い。そして、「機会（Opportunities）」としては、当然ながら部下よりも上司にえらい人を持ち、部下が優秀な人であることがある。つまり、部下が森田氏に頼むより、森田氏がその上司に頼む方が社内的な影響力が強く、部下は戦いの相手と言いながらもその優秀さが森田氏の武器になるともいうわけだ。
これらも踏まえつつ、いかに優秀なメンバーに対して「勝ち筋」を捉えていくのか。森田氏は「自身の『強み』と『機会』を最大限に活用して、成長環境を整備するのが良いだろう」と述べた。
そして「単純な技術力の積み上げによる戦いではなく、メンバーが積み上げた重量にいかに耐えるかの勝負だと思っている」と語り、「マネージャーは床」と表した。
フェーズ別、研究開発、外部教育の取り組みから得た気づき
こうしたスタンスのもと、森田氏がどのような取り組みを進め、どのような成果を得たのか。いくつかの事例が紹介された。いずれも「はじめから目的や効果を確信して取り組んだのではなく、結果としてそうなったものが多い」という。
はじめに、森田氏がマネージャーを務める組織を説明しておくと、プロダクトマネージャー、アナリスト、エンジニア、リサーチャーの各チームに分かれており、それぞれにチームマネージャーがいる。組織外に、インフラやデザインなどの専門チームがおり、連携して業務にあたる構造だ。
まずはフェーズについて。森田氏は、成長を考えるにあたり、エンジニアを「キャッチアップフェーズ」と「開拓フェーズ」の2種類に分類して考えているそうだ。「キャッチアップフェーズ」の定義は、自身が学習すべき事柄に関して本人より強いチームメンバーがいる状態を意味している。
「このフェーズは基本的にソリューションは潤沢であり、わりと順調に成長できると思う。本人も成長実感があり、優秀なメンバーがいればマネージャーがさほど何か手を貸さなくても問題が生じにくい。ポイントとしては、キャリアプランについて話す中で、成長スピードについて認識を合わせることが大事だ」
悩ましいのが「開拓フェーズ」で、学習すべき事柄に関し、本人より強いメンバーがいない場合だ。森田氏は、一般的には新規サービス、新規機能のリーダーポジションを経験してもらうのがよいと考えている。システムアーキテクチャを考え、アサインメンバーにタスクを振り分け、運用時には自身が手がけたアーキテクチャが本当に正しかったのか振り返りを行う。
森田氏は「同じレベルのエンジニアの中から選抜されることになり、リーダーを任されたメンバーは会社に残りやすく、サポート側に回ったメンバーは転職していくことが多いといった肌感覚がある。とはいえリーダーを1人に絞るのは大原則であり、逆に同じ力量のメンバーが複数いる場合の有効なソリューションを知りたい」と語る。
次に研究開発。「重要だが緊急ではない」タスクである研究開発は兼任体制で行うという。通常は「重要だが緊急でない」案件は専任体制にするのがセオリー。兼任になると、どうしても緊急案件に注力し、研究開発の方がどんどん後回しになってしまうからだ。しかし、森田氏がマネージャーを務めるチームではあえて兼任としており、その理由として、メンバーが相互学習しやすく波及効果が高いことなどが挙げられた。
最後に外部教育。社内に専門家がいない部分については、社外の専門家に見てもらうといった取り組みも行っている。現在はメンバーの1人が産業総合研究所に出向して、研究開発に取り組んでいる。出向の調整については、知財の問題も含め、人事にはやや負担をかけたという。しかし1年たって、ICML（International Conference on Machine Learning）などの国際会議において、ワークショップで発表するなど成果が出始めており、本人の能力次第とはいえ、現在はよいフィードバックループが回り始めているという。
逆に外の専門家を招いて技術顧問として見てもらう制度も開始し、現在試行錯誤を繰り返しているという。こうした成長支援策については、費用対効果を考慮すべきであり、マネージャーとして森田氏の重要な課題となっている。
「成長」を促進する組織とシステム構造に関する知見を共有
その他にも、「成長に寄与する組織づくり」について得られたさまざまな知見が紹介された。まずは、アンチパターンとして「本人が望まない限りマネージャーにしないこと」。マネージャーに抜擢したくなることもあるが、向き不向きや本人の意向も尊重し、マネージャーになる際も「WILL」が必要というわけだ。
そして、相互学習しやすい組織づくりとして「新卒同期を集めること」は大変効果的だったという。奇跡的に、新卒同期や年の近いメンバーが集まったことで、雑談も自発的に行われ、食事も一緒に行くようになった。情報共有や勉強会が発生しやすく、マウントを取るメンバーが発生しづらい。森田氏の経験をまねるには、一定の組織規模が必要であり、条件にも制約があるが、一般化すると「社内のソーシャルグラフを利用するということ」かもしれない。
さらに森田氏が意識しているのが「指示系統ラインが強くなりすぎないようにすること」だ。森田氏のチームでは、1人のメンバーがファシリテーターとして仕切っており、それによってエンジニアのやりやすさが向上した。つまり、組織はマネージャー、仕事はメンバーがファシリテーターとして仕切ることで、指示系統ラインが分散したことが幸いしたと考えられる。
「ファシリテーターが入ることで、要件定義と開発が『発注と受注』の対立関係にならずにすんでいる。さらにマネージャーはメンバーの把握にいそしむが、自身の情報を伝えることを怠りがち。そこにメンバー側からのファシリテーターが加わることで、マネージャー側の情報も伝えるルートができ、情報格差が生まれにくくなる。結果、チームの統一感が生まれてくる」
また、振り返りにおいてKPTについてもマネージャーが出して回収するのではなく、客観的な視点が加わり、業務として回しやすくなったという。
そして、最後に「成長を促す」システムについて、いくつかティップスが紹介された。
まずキャッチアップフェーズに適したシステムとして、入社メンバーが最初にやるチケットがあるという。それは、緊急性が低く、障害につながりにくく、かつコードをたくさん読めて成果が見えやすいもの。これらの要件を満たす例として「内製BIツールのフロントエンド改善」があるという。また、ベンダーのサービスを使うことで、中の人とコミュニケーションし、さまざまな知見を得ることができるという。オープンソースの利用も同様のことがいえる。
そして、開拓フェーズに適したシステムとして、マイグレーションを例に挙げた。基本的に仕様を切らなくてすみ、新しい技術潮流に乗ることができる。ただし、泥臭い仕事が多く、既存システムがブラックボックス化していると相当に大変であるため、マイグレーションしやすいシステム構造および運用体制になっていることが大切だ。
以上を振り返って、森田氏は改めて「不確実な事業環境においてはマネージャーが『成長』にフォーカスする正当な理由がある」と言い切り、さらに「特にCANを動かすのに向いていると思われる組織構造やシステム構造がある。その事例として紹介した中に、皆さまのコンテキストにマッチするものが1つでもあることを願いたい」と語り、セッションを終えた。
お問い合わせ
グリー株式会社
