## Profile -  吉田 浩一 (AI事業本部 AIクリエイティブディビジョン) 2014年サイバーエージェントに入社。広告プロダクトやオペレーションシステムなどの開発責任者として携わり、現在はAIプロダクト「 [極予測TD](https://www.cyberagent.co.jp/way/list/detail/news/detail/id=24670) 」の開発責任者を務める。 [CAゼミ制度](https://www.cyberagent.co.jp/techinfo/info/detail/id=25611) 「Make People Awesomeゼミ」のゼミ長として長く運営に関わる。 ## 開発組織を強くするエンジニアリングマネージャーの役割とは **── エンジニアリングマネージャーとしてのバックグラウンドを教えてください** 前職でのコードを書きつつマネジメントも担うプレイングマネージャーを経て、2014年にサイバーエージェントに中途入社し、AI事業本部の広告プロダクトにサーバーサイドエンジニアとして配属されました。AI事業本部に配属されて約3ヶ月後に、広告プロダクトの開発責任者を任されました。 当時のAI事業本部は立ち上げ初期でもあり、決まった開発プロセスがまだ存在しておらず、それぞれのプロダクトで自由な裁量権のもと開発をしていました。様々な新技術が選定されるなど、技術的に価値の高い試みもありましたがその一方、タイトなスケジューリングや稼働などで、組織に負担がかかった時期でもありました。 開発責任者になった当初は、エンジニアにとって開発しやすい環境を作りたいと考え、メンバーとの1on1に注力しました。そこから、スクラムやアジャイルを中心にした開発手法について勉強し始めました。この時期、社内で開催していたピープルマネジメントの勉強会も定期的に開催されていました。その活動は現在、 [CAゼミ制度](https://www.cyberagent.co.jp/techinfo/info/detail/id=25611) で私がゼミ長を務める「Make People Awesomeゼミ」にも引き継がれています。 **── エンジニアリングマネージャーの仕事において、1on1が重要な要素とされます。その上で、マネージャーとして成果を上げるためには、他にどんな事をすれば良いでしょうか？** サイバーエージェントにおけるマネージャーの役割は「チームを率いて成果を出すこと」が大前提です。1on1も確かに重要ですが、あくまでピープルマネジメントにおける手段に過ぎません。 私も最初は、1on1でメンバー個々の趣向を理解し、仕事をスムーズに進めることやお互いの信頼関係を築くことに注力していました。1on1を定期的に実施し、声を聞いているとマネジメントしている気になってしまうのが難しいところですが、マネージャーの目的は「チームを率いて成果を出すこと」であって、1on1は重要でありつつも、やはり手段の1つなんですよね。 **── 事業成果とピープルマネジメントのバランスは、多くのエンジニアリングマネージャーが悩みがちな気がします。吉田さんは過去を振り返ってどう思いますか？** 私も最初は何から手をつけて良いかよく分からず、1on1でメンバーの課題解決に注力し、良くも悪くも空回りした時期がありました。 エンジニアリングマネージャーになった当初、1on1でメンバーの課題や悩みをヒアリングし、それを解決すべく具体的なアクションを起こしていました。しかし、やればやるほど「何かあれば吉田が解決してくれる」という組織の暗黙裡になってしまいました。つまり、1on1をすればするほど、メンバーの主体性が奪われていくという状況と言えます。メンバー自身が課題を解決し成長する機会を、私が奪ってしまっていたとも言えます。 エンジニアリングマネージャーとしてあるべきスタンスは、メンバーがその課題に対して自力で解決できない障害に限り取り除いてあげたり、社内外で力になってくれそうなメンバーとつなげてあげる事でした。そして何より重要なのは、その課題を解決する事で、プロダクトにとってどんな効果があるのかに注力する事です。 やはり軸とするのはプロダクトの成功のために、課題の本質をとらえる事です。そこを間違えてしまうと、1on1という手段が目的になってしまうからです。  ── エンジニアリングマネージャーとしてのバックグラウンドを教えてください 前職でのコードを書きつつマネジメントも担うプレイングマネージャーを経て、2014年にサイバーエージェントに中途入社し、AI事業本部の広告プロダクトにサーバーサイドエンジニアとして配属されました。AI事業本部に配属されて約3ヶ月後に、広告プロダクトの開発責任者を任されました。 当時のAI事業本部は立ち上げ初期でもあり、決まった開発プロセスがまだ存在しておらず、それぞれのプロダクトで自由な裁量権のもと開発をしていました。様々な新技術が選定されるなど、技術的に価値の高い試みもありましたがその一方、タイトなスケジューリングや稼働などで、組織に負担がかかった時期でもありました。 開発責任者になった当初は、エンジニアにとって開発しやすい環境を作りたいと考え、メンバーとの1on1に注力しました。そこから、スクラムやアジャイルを中心にした開発手法について勉強し始めました。この時期、社内で開催していたピープルマネジメントの勉強会も定期的に開催されていました。その活動は現在、 CAゼミ制度 で私がゼミ長を務める「Make People Awesomeゼミ」にも引き継がれています。 ── エンジニアリングマネージャーの仕事において、1on1が重要な要素とされます。その上で、マネージャーとして成果を上げるためには、他にどんな事をすれば良いでしょうか？ サイバーエージェントにおけるマネージャーの役割は「チームを率いて成果を出すこと」が大前提です。1on1も確かに重要ですが、あくまでピープルマネジメントにおける手段に過ぎません。 私も最初は、1on1でメンバー個々の趣向を理解し、仕事をスムーズに進めることやお互いの信頼関係を築くことに注力していました。1on1を定期的に実施し、声を聞いているとマネジメントしている気になってしまうのが難しいところですが、マネージャーの目的は「チームを率いて成果を出すこと」であって、1on1は重要でありつつも、やはり手段の1つなんですよね。 ── 事業成果とピープルマネジメントのバランスは、多くのエンジニアリングマネージャーが悩みがちな気がします。吉田さんは過去を振り返ってどう思いますか？ 私も最初は何から手をつけて良いかよく分からず、1on1でメンバーの課題解決に注力し、良くも悪くも空回りした時期がありました。 エンジニアリングマネージャーになった当初、1on1でメンバーの課題や悩みをヒアリングし、それを解決すべく具体的なアクションを起こしていました。しかし、やればやるほど「何かあれば吉田が解決してくれる」という組織の暗黙裡になってしまいました。つまり、1on1をすればするほど、メンバーの主体性が奪われていくという状況と言えます。メンバー自身が課題を解決し成長する機会を、私が奪ってしまっていたとも言えます。 エンジニアリングマネージャーとしてあるべきスタンスは、メンバーがその課題に対して自力で解決できない障害に限り取り除いてあげたり、社内外で力になってくれそうなメンバーとつなげてあげる事でした。そして何より重要なのは、その課題を解決する事で、プロダクトにとってどんな効果があるのかに注力する事です。 やはり軸とするのはプロダクトの成功のために、課題の本質をとらえる事です。そこを間違えてしまうと、1on1という手段が目的になってしまうからです。 ## ビジネス目線とエンジニアリング目線のバランスのありかた **── 部下やトレーニーを持つと「その人の成長のために何ができるか？」を考えてしまいがちですが、思わぬ落とし穴ですね。** その考え方に私はハマってしまいましたが、大きな学びとなりました。株式会社ディー・エヌ・エー創業者の南場智子さんが著書「 [不格好経営](https://www.amazon.co.jp/dp/4532318955) 」で「人に向かうのではなくコトに向かう」と書いていますが、人に向かうのは本当にアンチパターンですね。 そんな失敗から、現在はプロダクトの事業成果をまず最優先に考えるようにしています。メンバーにも、プロダクトや組織に軸を置き、それに対してどうコミットしてもらうかを考える方が、個人の成長角度も高いと感じます。 「プロダクトが成長するためには、エンジニアリングマネージャーとして何をすべきか？」をしっかりと自問自答する事を心がけています。その上で「プロダクトの成長」に必要なことをメンバーにも一緒に考えてもらい、主体性を持って取り組んでもらうようにしています。 「プロダクトの価値を高めたり、マーケットで成功するために、エンジニアリングで何ができるか？」の問いを繰り返す事は、マネージャーだけでなく開発組織にとっても効果的だと思っています。 それを前提として、1on1を実施すると、より大きな効果があると実感します。1on1でメンバーのやりたいことや成長ビジョンを聞き、チーム内の課題にあわせて適材適所と目標設定をしています。 メンバーの目標設定について意識しているのは自主性で、各メンバーが主体性を持つことができれば、そのチームは強くなると考えています。 **── プロダクトの成功にコミットする場合、売上などの経営レイヤーに関わっていく必要があります。組織で昇進することは喜ばしい事ですが、開発現場から遠ざかることを懸念する人もいます。** むしろ、閉ざされた数字を見ようとするのではなく、開示された数字からプロダクトの成功を想像することが重要だと思います。株式会社であれば事業ドメイン毎に決算が開示されていますよね。 例えばAI事業本部では、チームのサイズもコンパクトで、プロダクトの現状など情報が手に入りやすいです。昇進しないと数字が手に入らないということは全くなく、興味があれば数字を教えてくれる環境です。メンバーであっても見ることができるため、透明性があります。 **── 職種やポジションを問わず、誰でもアクセスできる情報を参考にしながら、状況を理解する必要があると。その上で、エンジニアならではの観点を教えてください。** 数字や組織状況をできるだけ俯瞰し、システム的にアプローチできる箇所を探すことが重要だと思います。なぜなら、ビジネス的な局面や組織のバランス、適材適所の人材配置などを見ずしてソフトウェア設計をすると、エンジニアの思い込みでニーズと異なる開発に進みがちだからです。 開発した機能がビジネスに与えた経営インパクト、オペレーションのボトルネックや、ビジネス的なコスト増を意識して見る事で、エンジニアリングで解決できるビジネス課題にフォーカスする事で、開発した機能の精度が上がるのを実感しています。  ── 部下やトレーニーを持つと「その人の成長のために何ができるか？」を考えてしまいがちですが、思わぬ落とし穴ですね。 その考え方に私はハマってしまいましたが、大きな学びとなりました。株式会社ディー・エヌ・エー創業者の南場智子さんが著書「 不格好経営 」で「人に向かうのではなくコトに向かう」と書いていますが、人に向かうのは本当にアンチパターンですね。 そんな失敗から、現在はプロダクトの事業成果をまず最優先に考えるようにしています。メンバーにも、プロダクトや組織に軸を置き、それに対してどうコミットしてもらうかを考える方が、個人の成長角度も高いと感じます。 「プロダクトが成長するためには、エンジニアリングマネージャーとして何をすべきか？」をしっかりと自問自答する事を心がけています。その上で「プロダクトの成長」に必要なことをメンバーにも一緒に考えてもらい、主体性を持って取り組んでもらうようにしています。 「プロダクトの価値を高めたり、マーケットで成功するために、エンジニアリングで何ができるか？」の問いを繰り返す事は、マネージャーだけでなく開発組織にとっても効果的だと思っています。 それを前提として、1on1を実施すると、より大きな効果があると実感します。1on1でメンバーのやりたいことや成長ビジョンを聞き、チーム内の課題にあわせて適材適所と目標設定をしています。 メンバーの目標設定について意識しているのは自主性で、各メンバーが主体性を持つことができれば、そのチームは強くなると考えています。 ── プロダクトの成功にコミットする場合、売上などの経営レイヤーに関わっていく必要があります。組織で昇進することは喜ばしい事ですが、開発現場から遠ざかることを懸念する人もいます。 むしろ、閉ざされた数字を見ようとするのではなく、開示された数字からプロダクトの成功を想像することが重要だと思います。株式会社であれば事業ドメイン毎に決算が開示されていますよね。 例えばAI事業本部では、チームのサイズもコンパクトで、プロダクトの現状など情報が手に入りやすいです。昇進しないと数字が手に入らないということは全くなく、興味があれば数字を教えてくれる環境です。メンバーであっても見ることができるため、透明性があります。 ── 職種やポジションを問わず、誰でもアクセスできる情報を参考にしながら、状況を理解する必要があると。その上で、エンジニアならではの観点を教えてください。 数字や組織状況をできるだけ俯瞰し、システム的にアプローチできる箇所を探すことが重要だと思います。なぜなら、ビジネス的な局面や組織のバランス、適材適所の人材配置などを見ずしてソフトウェア設計をすると、エンジニアの思い込みでニーズと異なる開発に進みがちだからです。 開発した機能がビジネスに与えた経営インパクト、オペレーションのボトルネックや、ビジネス的なコスト増を意識して見る事で、エンジニアリングで解決できるビジネス課題にフォーカスする事で、開発した機能の精度が上がるのを実感しています。 ## 生成AI時代が求めるエンジニアリングマネージャーの役割 **── 最近、エンジニアリングマネージャーやプロダクトマネージャーといった職種の需要が増えてきています。その一方、任せられる人材不足や、一人が複数の役割をこなすケースもあります。現状をどのように見ていますか？** 技術とは、突出した人材が未知の領域を開拓し、やがて時代に応じてコモディティ化し、マーケットに広く普及するというサイクルを繰り返していると考えています。クラウドやAIも同様であり、フルマネージドのパブリッククラウドサービスや、生成AIを活用したクリエイティブ制作が一般化していると言えます。その結果、以前は突出した人材だけができたことが、比較的多くの人にもできるようになりました。 現在においても突出した人材の創出する価値は変わりませんが、それをいかに早く応用し、ビジネス的に活用するかが重要になっています。クラウドや生成AIの登場により、ビジネス化へのスピードと提供できる価値が問われています。エンジニアリングマネージャーのニーズが増えているのはこのためです。 気をつけたいこととしては「これはプロダクトマネージャーの仕事。これはエンジニアリングマネージャーの仕事」のように切り分けすぎないことです。スピードと価値を最大化するためには関係者の知恵と力を合わせることに尽きます。「何をマネージメントするか?」を見誤ると空回りする可能性が高いといえます。 **── 吉田さんの感覚では、何年くらいで周期が変わっていると思いますか？** 例えばChatGPTで使われているTransformerという技術が発表された2017年当時は限られた研究者や技術者しか扱うことができませんでしたが、現在はそれを意識することなくChatGPTのサービスを誰でも活用することができます。 サイバーエージェントでも先日「 [賞金総額1,000万円！生成AI徹底活用コンテスト](https://www.cyberagent.co.jp/way/list/detail/id=29503) 」と「 [全社的なAI人材育成に向けての生成AI徹底理解リスキリング](https://www.cyberagent.co.jp/news/detail/id=29485) 」を開催しました。全ての事業部、全ての職種で、生成AIについて活発に議論しているのは本当に印象的です。 誰でもAIを活用する時代において、それを活用して何をするのかが問われる時代になりました。 **── 先端技術がコモディティ化した時代において、エンジニアリングをマネジメントするとは、何を指すのでしょうか？** エンジニアリングマネージャーとは、エンジニアをマネジメントする職業ではありません。 古くは製造業の時代からエンジニアリングという言葉が使われていたと思いますが、当時はQCD(Quality, Cost, Delivery)を改善し、品質を向上させるといった表現に「エンジニアリング」が使われていました。 IT/Web業界においても価値を高めるために様々な手法が用いられますが、事象を観察し、得られたデータを分析することで得た知見を次の行動や戦略に反映させる、という意味で本質は変わりません。 私は、プロダクト開発を通じたイノベーションを起こす事が、エンジニアリングの役割だと考えています。広く解釈すれば、イノベーションを促進するための仕組みがエンジニアリングであって、それを最大化するのがエンジニアリングマネージャーの役割だと考えています。 全体のワークフローを分析し、オペレーションのどこにボトルネックが発生していて、AIを活用するとどう改善するのか。生成AIを導入するのであれば、どういったモデルを採用するべきか、GPUサーバーの調達やランニングコストをどう確保するか、MLエンジニアをどうアサインするか。技術的な投資に対する、事業的なプロフィットのバランスはどうなったか？ これら全てを網羅するのが「エンジニアリング」だと思います。このサイクルがかっちりハマると [「極シリーズ」のような既存マーケットに対するイノベーション](https://www.cyberagent.co.jp/news/detail/id=28830) を誘発します。エンジニアリングマネージャーの腕の見せ所でもあり、一番楽しいところでもあります。 エンジニアリングマネージャーはある意味、組織やプロダクトのパフォーマンスを向上させるために、組織やワークフローをハックするのが仕事の1つとも言えます。  ── 最近、エンジニアリングマネージャーやプロダクトマネージャーといった職種の需要が増えてきています。その一方、任せられる人材不足や、一人が複数の役割をこなすケースもあります。現状をどのように見ていますか？ 技術とは、突出した人材が未知の領域を開拓し、やがて時代に応じてコモディティ化し、マーケットに広く普及するというサイクルを繰り返していると考えています。クラウドやAIも同様であり、フルマネージドのパブリッククラウドサービスや、生成AIを活用したクリエイティブ制作が一般化していると言えます。その結果、以前は突出した人材だけができたことが、比較的多くの人にもできるようになりました。 現在においても突出した人材の創出する価値は変わりませんが、それをいかに早く応用し、ビジネス的に活用するかが重要になっています。クラウドや生成AIの登場により、ビジネス化へのスピードと提供できる価値が問われています。エンジニアリングマネージャーのニーズが増えているのはこのためです。 気をつけたいこととしては「これはプロダクトマネージャーの仕事。これはエンジニアリングマネージャーの仕事」のように切り分けすぎないことです。スピードと価値を最大化するためには関係者の知恵と力を合わせることに尽きます。「何をマネージメントするか?」を見誤ると空回りする可能性が高いといえます。 ── 吉田さんの感覚では、何年くらいで周期が変わっていると思いますか？ 例えばChatGPTで使われているTransformerという技術が発表された2017年当時は限られた研究者や技術者しか扱うことができませんでしたが、現在はそれを意識することなくChatGPTのサービスを誰でも活用することができます。 サイバーエージェントでも先日「 賞金総額1,000万円！生成AI徹底活用コンテスト 」と「 全社的なAI人材育成に向けての生成AI徹底理解リスキリング 」を開催しました。全ての事業部、全ての職種で、生成AIについて活発に議論しているのは本当に印象的です。 誰でもAIを活用する時代において、それを活用して何をするのかが問われる時代になりました。 ── 先端技術がコモディティ化した時代において、エンジニアリングをマネジメントするとは、何を指すのでしょうか？ エンジニアリングマネージャーとは、エンジニアをマネジメントする職業ではありません。 古くは製造業の時代からエンジニアリングという言葉が使われていたと思いますが、当時はQCD(Quality, Cost, Delivery)を改善し、品質を向上させるといった表現に「エンジニアリング」が使われていました。 IT/Web業界においても価値を高めるために様々な手法が用いられますが、事象を観察し、得られたデータを分析することで得た知見を次の行動や戦略に反映させる、という意味で本質は変わりません。 私は、プロダクト開発を通じたイノベーションを起こす事が、エンジニアリングの役割だと考えています。広く解釈すれば、イノベーションを促進するための仕組みがエンジニアリングであって、それを最大化するのがエンジニアリングマネージャーの役割だと考えています。 全体のワークフローを分析し、オペレーションのどこにボトルネックが発生していて、AIを活用するとどう改善するのか。生成AIを導入するのであれば、どういったモデルを採用するべきか、GPUサーバーの調達やランニングコストをどう確保するか、MLエンジニアをどうアサインするか。技術的な投資に対する、事業的なプロフィットのバランスはどうなったか？ これら全てを網羅するのが「エンジニアリング」だと思います。このサイクルがかっちりハマると 「極シリーズ」のような既存マーケットに対するイノベーション を誘発します。エンジニアリングマネージャーの腕の見せ所でもあり、一番楽しいところでもあります。 エンジニアリングマネージャーはある意味、組織やプロダクトのパフォーマンスを向上させるために、組織やワークフローをハックするのが仕事の1つとも言えます。 ## これからエンジニアリングマネージャーを目指す人へ **── サイバーエージェントには、開発経験が豊富な若手エンジニアや研究者が毎年入社します。新メンバーのパフォーマンスを最大化しながら、事業も人も成長してもらうために、ベテランとしてどんな姿勢が求められると思いますか？** 私は、当社の新卒や若手の方々を心から尊敬しています。私が持っていない多くの素晴らしい資質を持っているだけでなく、人としても優れていると思っています。 私の方が年齢や実務経験は重ねていますが、それでも私は彼ら、彼女らを先生のように見ていて、教えていただくことも多く感謝していますし、その成長をいつも喜ばしく思っています。毎年、チームに迎え入れられる事に感謝していますし、その上で価値を提供できることがあれば喜んで協力します。 私の所属する「 [極予測TD](https://www.cyberagent.co.jp/news/detail/id=24670) チーム」には同年代のベテラン層のメンバーが多いですが、口を揃えて「若いメンバーと接することは本当に楽しいし、お互いに学び高めあえるのが嬉しい。」と言っているのが印象的です。 昨今、 [ベテランのリスキリング](https://www.nikkei.com/article/DGXZQOUC300EP0Q3A031C2000000/) という言葉を聞く事が多く、一見すると講義を受けるか自己学習するイメージがあります。サイバーエージェントにおいては、新卒や若手と同じ目線で一緒に働く事こそ、ベテランにとってのリスキリングなのではと思っています。 **── そんな若手の中から「エンジニアマネージャーをやりたい」と希望する人が増えていたりもします。その一方、 [生成AIや技術のコモディティ化によって、開発組織のありかたが変わる可能性](https://www.cyberagent.co.jp/way/list/detail/id=29513) もまたあります。生成AIが一般化した時代において、エンジニアリングマネージャーのあり方についてアドバイスをください。** 「言葉や役割などの型にはまらない」事です。エンジニアリングマネージャーやプロダクトオーナーも、単なる役割と名称に過ぎません。ましてや、エンジニアリングマネージャーは資格ではなく、個々の能力に基づいた役割です。「この人は、組織を率いて成果を出す能力を持っているので、エンジニアリングマネージャーに足りうる」と会社が裁量権を与えているのです。 だから、エンジニアリングマネージャーという立場や役割を目指すのではなく「組織を率いて成果を出す能力」をあげる事に注力してほしいと思います。自分のスキルや精神性を常にアップデートすることが重要だと考えています。 生成AIがコモディティ化した時代と言いましたが、だからこそ生成AIをフル活用する若手の仕事に学ぶのもありですし、ChatGPTを活用しながら他のメンバーが未着手の技術検証を進めるのもありです。コーディングも手掛けるプレイングマネージャーにとって、生成AIは強力なツールになると思います。 エンジニアリングマネージャーを目指す若手に向けるメッセージとありますが、その生存戦略の解は、多感な10代20代に生成AIの勃興をむかえる若手にあるかもしれません。 サイバーエージェントには毎年、型にはまらない [「素直でいいやつ」が入社してきます](https://www.cyberagent.co.jp/way/list/detail/id=25850) 。そんな若手の中で、エンジニアリングマネージャー志望の方と一緒に働けることを楽しみにしています。