freeeの開発情報ポータルサイト

AIチョットニガテなわたしが考える、AI時代のPdL・EMの在り方

昨日の yuria3 の記事はどうでしたか?ClickHouseのホスティング選定プロセスだけでなく、SaaS版導入時のPrivateLinkやDNS制約といったリアルな「ハマりポイント」まで詳しく共有されており、これから導入するエンジニアにとって転ばぬ先の杖となる非常に実践的な記事ですね😊

さて、今回はEMになった osso が最近悩んでいることを書いてみたいと思います。

わたし、正直AIがチョットニガテなんですよね。

2025年はAIエージェント元年と言われています。昨年の今頃はまだ Chat に質問して回答を得るという使い方が主流でしたが、現在はAI駆動開発は当たり前で、さらに常に新しく出てくるモデルの特徴やAIエディタ、コーディングエージェント、仕様駆動開発といった新しい手法などにキャッチアップしながら、日々の開発フローをアップデートし続ける必要があります。もはや、AIを"うまく使うこと"が目的のように感じてしまうほどです。

でも、わたしにとってはどうしてもAIは手段なんです...手段のために労力を使いたい気持ちが起きなくて。なので、楽しそうに情報交換している方々を見ていると、わたし結構AIニガテなのかもなあ...と思うわけです。

なので、AIニガテな私はこのAI時代にAIに負けない部分は何かを考えながら働いています。その中で得られた気づきを文章にしてみるのが、このアドベントカレンダー17日目です。

adventar.org

「AIニガテ」に共感していただけた方もそうでない方も、読んでいただけると嬉しいです。

自己紹介

改めて自己紹介をします。 おっそー( @_also )です。freeeに中途入社してから4年が経ちました。ずっと外部サービス連携を担当しています。しばらく PdL(プロダクトリードエンジニア)をやってきましたが、AI時代に焦りを感じ、エンジニアとしての生き方を広げるために10月からEM(エンジニアリングマネージャー)にも挑戦を始めました。

freee developers役割の一覧表。4つの開発専門スキル分類を説明。1. PdL(Product Lead):OKRの達成に向けて開発力を実現に導く、プロダクトPdLは価値向上と事業貢献に均等にマジ価値を最速で届ける、基盤PdLは基盤開発による価値向上とユーザー貢献に均等にマジ価値を届ける。インパクトはチームで創出する。2. EM(Engineering Manager):エンジニアがマジ価値を最速で届けるために個とチームの能力を最大限に引き出し成長を支援する、単発ではなく継続的にマジ価値を生み出すことができる組織やカルチャー、仕組みを作り上げる。インパクトは組織・人材領域を通じてチームで創出する。3. TL(Technical Lead):技術に対する深い知見を元にチームの技術的な意思決定に責任を持ち、必要な技術投資をリードする、担当領域における技術方針を定め技術課題の解決に必要なソリューションを立案・推進していく。インパクトは技術領域をリードしチームで創出する。4. IC(Individual Contributor):特定領域において圧倒的な技術力を持ち個人の能力でチームを凌ぐインパクトを創出する、freeeだけでなく社会的な影響に波及するような大きなインパクトを再現性を持って生み出す。期待されるインパクトは技術領域(※特定の技術領域での卓越した専門性)を個人で創出。
freee developers 役割定義の一覧

PdLもEMも、結局は freee のユーザー様に最速で最大の価値を届けることが大目的であることに変わりありません。しかし、アプローチが違うのだと理解しています。

PdLとEMの価値の届け方の違い

PdLは事業理解と高いユーザー解像度を持ち、チームやプロジェクトを推進する腕力を通じて価値を届けます。一般的に言われている言葉に置き換えると、「プロダクトエンジニア×グロースエンジニア×プロジェクトマネージャー」が freee の PdL だと思っています。

一方でEMはメンバーの強みと強みを掛け合わせて掛け算的にチームの成果を最大化させることで価値を届けます。仕組みづくりやメンバーの成長支援も求められるため、時には短期的なパフォーマンスを下げてでも、長期的に価値を出し続けられる施策を優先することもあるでしょう。

AIが代替できる仕事・できない仕事

『愚者は経験に学び、賢者は歴史に学ぶ』と言いますが、ここはわたしの経験から挙げている例です。エンジニアとしての一般的な仕事(コーディングやドキュメンテーションなど)は既知だと思うので除いています。

AIが代替できる仕事 AIが代替できない仕事
PdL ・データ分析やメトリクス集計
・競合調査や市場トレンド情報収集
・ユーザーフィードバックの分類整理や改善案の提案
・プロダクトビジョンの策定
・ステークホルダーとの調整や合意形成
・抽象的もしくは曖昧な課題への対応
・責任を持った最終的な意思決定
EM ・メンバーの定量評価の情報収集
・チームの課題を取り除くための壁打ち
・チーム文化の醸成
・チームメンバーの理解
・組織間の調整と関係構築

定型作業はすごく助かっている一方、「人と人との間で起こる複雑な相互作用」をAIになんとかしてもらおうというのはまだ難しいのかなという感触は一般的に言われていることと同じではないでしょうか。

(わたしは定型作業が得意だったというのも、好きな仕事取られちゃって AI がニガテって思う要素なのかも...)

AI時代のPdL、EMはどう在るべきか

当然といえばそうなんですが、AIが代替できない仕事を頑張らないといけませんね。

AIよりも最速で最大の価値を届けられるポイント(だと思っているもの)と、今取り組んでいる工夫を書いてみます。

PdLがAIに負けないためにできること

速く強い意思決定をすることです。正しい意思決定ができるに越したことはありませんが、正しいことよりも速いことが重要だと考えています。

なぜなら、PdLに求められる「チームやプロジェクトを推進する腕力」が AI では特に実現できない部分だからです(事業理解と高いユーザー解像度はAIのサポートが得られます)。

❌よくない例 ⭕️よい例
「意思決定は間違えたくないなあ...AIに頼んで情報を集めて、う〜んもうちょっと深掘りしておこう...これをAIにまとめてもらって...意見をもらおう...AIがこう言ってるし、これでヨシ!」 「とりあえず決めて走ったら新しく見えてくることがあるかもしれない!間違うかもしれないんだけど、今わかっている範囲だとこれが一番いいと思うから、これで進めてみない?」

AIができるのは情報を集めて"正しく見える提案をする"ことですし、そこに何十秒もかけるでしょう。あと、責任は取れません。

そもそも、AIよりも人間のほうが速く正しい意思決定ができると思っています。なぜなら、意思決定には AI にコンテキストで渡しきれない複雑な要素がいくつも絡むからです。

  • チームのリソースや体力
  • 社内外含むステークホルダーの意思や期待値
  • 目指すべきゴール(届けたいユーザー体験)
  • プロダクトの保守性 
  • メンバー個人やチームの指向
  • 他チーム・機能の開発状況 etc...

意思決定には責任が伴うため、心理的負荷がかかります。人間なので間違えや失敗は怖いです。そのため、先延ばしにしたり無意識に他の誰かのせいにできる余地を作りたくなったりするものです。しかし、決めないとプロジェクトは進みません。

「やってみないと分からないこともあるけど、これがマジ価値だと思うからやってみようよ」という、正しいよりも強い意思決定をして、チームやステークホルダーを動かすこと。これが AI 時代の PdL として最速で最大の価値を届けるために必要なことだと思っています。

また、意思決定によって得られたFBサイクルを回せることから、意思決定の精度を上げていくためにはAIに頼りすぎないほうが良いと考えています。

EMがAIに負けないためにできること

まだ3ヶ月目なのでEMを語るのは早い気もしていますが、「メンバーの強みと強みを掛け合わせて掛け算的にチームの成果を最大化させる」ことそのものが AI で代替しづらいものだと考えています。だからこそ EM に挑戦してみたい気持ちが芽生えたというのもあります。

"メンバー"と書くと"マネージャー"との関係性が強調されてしまうように感じてしまって性に合わないので、以降はチームメイトと記載します。

①最適なチームづくり

チームを造ることは AI にはできません。

わたしが意識しているのは、チームメイトがどの分野で成果を発揮しやすいか(発揮できるようになりたいか)を知り、プロジェクトでの役割を伝え全員で認識を合わせることです。

まず、チームには目的があります。その目的を達成するために人が集まっています。そして、人には得意・苦手・好き・嫌いなタスクがあります。しかしながら、本人の主観や言葉から見えるものだけ見ていると、見落としてしまうその人の良さがあります(私実装が遅いんですよね...と言う人が、定量化したら社内平均以上の早さだったみたいな)。そのため、プロジェクトの期間やインパクトのバランスを考えながらも、チームメイトの自己評価だけでなく、チームメイトの目標や、1on1や一緒に仕事をする中で得られた気づきも踏まえ、適切なアサインメントを考えています。

また、全員が揃っている場でプロジェクトにおける役割を伝えるようにもしました。役割と責任領域を明示し、なるべく私が意思決定のボトルネックにならないようにしつつ、その代わり伸び伸びと働いて自由に成功体験や失敗体験を積んでほしいという考えです。

今のところ自発的に考えて動ける良いチームが作れていると思っています。チームで一番コーディングエージェントを使いこなしているチームメイトはプロジェクトでより開発スピードを上げるためにAI開発合宿を開催してくれたり、複数人のメンバーがいるプロジェクトマネジメントに初めて挑戦したチームメイトは順調にプロジェクトを運びつつ問題を早めにエスカレーションし大きな障害になる前に取り除いてくれたりしました。

②チームの課題を認識し、チームの成果を最大化する仕組みづくり

仕組みを考えること自体は AI ができる(むしろ人より得意?)かもしれませんが、チームの課題を客観・俯瞰的に知ること、課題に対応するための仕組みをチームに浸透させることは AI にはできません。

特にAIの進化が激しい現在、最新の情報にキャッチアップしてアップデートし続けられる人とそうでない人がいて、その生産性の差は大きいということが一般的に言われています。冒頭でお伝えした通り、わたし自身はまさに後者です。ですが、この生産性の差やチームのAI活用の組織的な仕組み化といった課題は2026年の最初にほぼすべてのチーム・組織で最初に取り組むべき課題になっているはずです。

このためには「AIチョットニガテ...」なんてEMである私が言っている場合ではありません。そのため、最近はAIに関する技術イベントを視聴してまとめることを継続的に行なっています。得られた知見でチームの課題にフィットするものはすぐに取り入れていきたいと思っています。

また、AI時代に依らないEMのあるべき姿のインプットも行なっています。EMの先輩と一緒に最近読んでいるのは「エンジニアリングチームのリード術」です。この本には「効率性・効果性・生産性」という言葉が出てきます。ここまでAIによる生産性に重きを当てて話を進めてきましたが、自分たちのチームが届けられている価値(=効果性)と、アウトプットに対してどの程度のアウトカムを出せているか(=効率性)も可視化し、チームの状態を測ることも大切です。

生産性はもちろん重要ですが、生産性向上だけに捉われず、チームの目的から我々のやるべきことに向かっていけているかを常に振り返るようにしていくことも、EMの重要な役割だと考えています。

さいごに

わたしたちは結局、人と人との繋がりの中でお互いに助け合って生きてきています。ビジネスも「この課題を解決するよ!」「ありがとう!」が回り続けて成立するものです。チームも「これをやろう!」「そうしよう!」の繰り返しで成長していきます。今後もAIによって代替される仕事は増えていき、この記事の発信が古くなるのもすぐかもしれません(すでに古いと感じる方もいるでしょう)。それでもAI時代を生き抜くために「人の想いや気持ちを大事にできるか」は、ずっと変わらず大切であり続けるのではないかと思います。

明日はyokiさんがfreeeサインのEKS移行のお話をしてくれるので、お楽しみに♪