権限を手放して気づいた、チームへの貢献の仕方 — プロダクトチームに異動した半年間の記録

ADWAYS DEEEでリードアプリケーションエンジニアをしています、中村です。前回の記事ではUM（ユニットマネージャー：チームのマネジメント責任者）としてのチーム作りについて書きましたが、2025年10月にAppDriverプロダクトチームにプレイヤーとして異動しました。

技術改善ディビジョンのクラウドチーム（インフラメイン）に長くいて、UM経験もありました。アプリケーション開発をやりたかったのと、マネジメントキャリアを考えたときに異なる領域での経験が足りないと感じていたのが異動の動機です。メンバーの変動でアドテクノロジーディビジョンのAppDriverプロダクトチームに空きが出たタイミングで、自分からプッシュして異動しました。

UMからプレイヤーへ。この変化で手放したのは、「えいや」で動かせる権限でした。課題に気づいたらその場で判断して動かせていたものが、プレイヤーとしては同じやり方が通用しません。

この記事では、足元のキャッチアップからチームへの貢献まで、半年間で実践したことを書いていきます。

本記事の対象読者としては、チームをまとめている人（UM/テックリード/スクラムマスター）や、異動・役割変更を経験した・控えているエンジニアを想定しています。AI時代のエンジニアの立ち回りに関心がある方にも参考になれば幸いです。

まず足元を固める — ドメインキャッチアップで効いた「仕組み」

チームに貢献する前に、まず自分がドメインを理解しないと始まりません。異動先ではClaude Code（AIコーディングツール）が使える環境が整っていて、「AIがあればキャッチアップも早くなるだろう」とは聞いていました。しかし実際にやってみると、ドメイン知識のキャッチアップにおいてはそう単純ではありませんでした。

AIの限界に最初にぶつかった

AppDriverでは、同じ概念を指す用語が場所によって異なっている部分があります。いわゆるユビキタス言語（システム全体で統一すべき共通用語）が整備途上の状態です。この状況でAIに質問すると、もっともらしいが実態と合わない回答が返ってきます。

例えば以下のようなケースがありました。

管理画面上では「日予算機能」として提供されているが、実態として日時まで指定できるので期間予算と言った方が適切。
一般用語としてのSSP(Supply-Side Platform)は媒体（Supply側）のための広告の配信最適化プラットフォーム。しかし弊社は広告代理店という立ち位置のため、視点が変わると何がSSPになるかが変わる。
- こういう「一般用語の顔をしているが社内では意味が違う」用語に特に気をつけるようになりました
もう使われなくなった機能のデッドコードが残っており、使われているかどうか(アクセスログ)のコンテキストがないため「使われています」と回答される
DBカラムのコメントやメタデータには前に使われていた言い方で残っているためそれが回答として返ってくるが、現在では別の社内用語になっている。チームメンバーに確認すると「その用語はなんですか？」と言われる

AIはドキュメント間の用語の矛盾に気づかず、片方の定義を「正解」として返してきます。ドメイン知識がない状態で読むと正しく見えてしまうので、これは怖かったです。

人が設計した「学びの道筋」が効いた

AIの代わりに効いたのは、人が設計した学習の仕組みでした。

オンボーディング課題: 異動先のマネージャーが作ってくれたもので、答えではなく「観点」を示してくれる設計になっています。取り組む中でドメイン理解が自然と深まりました

トラッキングの課題

実際にコードを追ってどのような形式になっているかを調べることを通して、システムの流れも同時に掴める良い課題でした。

質問DB

新卒受け入れ時のオンボーディングで使われていた仕組みを参考に導入しました。分からないことをNotionに書くと、チームメンバーが回答を書き込んでくれます。遅くても翌日には回答が返ってきました。蓄積された質問と回答が次に入る人の資産にもなります。

具体例は社内用語やシステムに関するものが多いので載せづらいのですが、会議に出てきたものを中心に戦略の指標から具体的な用語まで幅広く質問できました。

翌日までに回答が返ってきたのは、UMが温かく迎え入れてくれたことと、メンバーに協力していただいたおかげです。この点はとても感謝しています！！

AI時代でも「正しい問いを持つ人」がキャッチアップの起点です。オンボーディング課題や質問DBといった仕組みがあることで、新メンバーが自走できる状態を作れます。AIが活きるのは、その土台ができた後からでした。

フロントエンドからバックエンドまで一気通貫の開発

異動後初めての開発タスクとして、フロントエンドからバックエンドまで一気通貫で触る案件を担当しました。たまたまこの時期にチームに運用タスクとして降ってきた案件で、期限も調整可能だったため自分に振ってもらいました。

APIフィールドの追加からフロント表示の分岐まで、段階リリースで進めました。シニアエンジニアにポイントで質問し、得た知識をドキュメント化してチームに共有しました。

モックでは動くのにテスト環境で動かない、という場面では管理画面でのデータ準備が必要でしたが、そもそも管理画面を触ったことがありませんでした。こうした「知らないことを知らない」壁は、人に聞かないと超えられません。

このデータ準備の経験は、その後の開発でも活きました。動作確認の際に「実装は正しいか？」だけでなく「データは正しいか？」という観点を持てるようになったのです。実装が正しくてもデータが正しくなければ動きませんし、データを整備する過程で実装時の考慮漏れが発覚することもありました。

振り返ると、オンボーディング課題でドメインの観点を掴み、一気通貫の開発タスクで手を動かし、その後メインプロジェクトに合流するという流れがありました。この段階を踏ませてもらえたことが、キャッチアップの質を大きく上げてくれました。

文化の輸入 — 背中を見せて「当たり前」を持ち込む

ドメイン理解が浅くても、チームに持ち込めるものがありました。前チーム（クラウドチーム）で当たり前だった「働き方」そのものです。

チームチャンネルでの作業ログの活発化

timesチャンネル（個人の作業ログ）は以前から自分で書いていましたが、AppDriverチームではチームチャンネルにおける作業ログが活発ではありませんでした。クラウドチームでは、チームのSlackチャンネルに作業スレッドを立てて思考過程や調査ログを残す文化があったので、自分が率先してチームチャンネルに書き始めました。

結果として、チームメンバーにも波及して作業ログを書く人が増えました。

これが効いたのは、情報の流れ方が変わったことです。

作業スレッドにその日のメイン開発の進捗がまとまるため、UMや他のチームメンバーがキャッチアップしやすくなりました。スレッドを見たUMやチームメンバーから「ここ参考になるかもしれないです」と同期的に情報が来るようになりました
チームメンバーから「中村さんがログ取ってくれるから、自分で追うよりtimes見た方がキャッチアップが早い」と言ってもらえたこともありました
以前はペアプロ中の会話レベルで「ここ直した方がいいね」で止まっていた改善点が、Slackに残るようになったことでissue化まで進むようになりました。AIの活用で実装コストも下がったので、気づいた改善をその日のうちにAIに投げて、一緒にマージまでいくことも珍しくなくなりました。いわゆるTidy First?（小さな改善を先にやる）的な動きが自然に回り始めています

情報の取りまとめを率先する — 負荷テストの事例

もう1つ意識していたのは、プロジェクト情報を一箇所に集約する動きです。具体的な事例として、負荷テストの取りまとめがあります。

新機能開発やクラウド移行（移行前後で動作が変わらないことを確認する）の際に負荷テストを行うことが多いのですが、まとまった手順やログが残っていない状態でした。自分が率先して今回の操作ログを残し、「なぜこのインスタンス台数にしたのか」の判断根拠もSlackのリンクを引用する形で後追いしやすくしました。

結果、その後先方の施策が複数回あった際に、毎回ゼロから負荷テストして判断するのではなく、「前回こう判断してこうだったから」と効率的かつ論理的に台数を決められるようになりました。負荷テストから実際の要求に対して何台増やせばいいかを判断するコストが大きく下がった実感があります。

文化を輸入するコツは、いきなり「こうすべき」と提案しないことです。まず自分が背中を見せる。自分が実践して機能するのを確認してから、自然に広がるのを待つ。このアプローチが結果的に一番効きました。

仕組みの設計 — 「えいや」の代わりに仕組みで動かす

UM時代は課題に気づいたら直接動かせました。プレイヤーとしては同じことができません。仕組みを作り、その仕組み経由でチームを動かすアプローチに切り替えました。

具体的には、working agreement（チームの約束事）の整備や、振り返りのファシリテーション改善などです。暗黙の了解を明文化してチーム全体で合意を取ったり、発散しやすかった振り返りに収束の仕組みを入れたりしました。

working agreementの例

Googleカレンダーで、チーム内での予定はチームカレンダーで予定を抑える
datadogで見るクエリを共有したい場合はviewsに残す
- 背景: とある施策の監視でDatadogをみんなで見ていたが、見ているものはバラバラだった

課題に気づいたとき、最初にやったのはUMとの1on1で背景を確認することでした。自分の中で「なぜこういう文化になっているのか」の情報が足りない感覚があり、まずそこを押さえてから適切な打ち手を考えたかったのです。結果としてUMに動いてもらうこともありましたが、それは手段の1つに過ぎません。背景を理解した上で、仕組みで解決できるものは仕組みにする、という判断ができるようになりました。

仕組みと合意で動かすことで、自分自身も働きやすくなりました。以前は「自分だけが率先してログを取っている」「毎回自分が議事録を書いている」といった状態になりがちでしたが、仕組みとして回り始めることでチーム全体に分散されるようになりました。一人で頑張り続けるのではなく、仕組みがチームを動かしてくれる状態を作れたのは大きかったです。

問題の早期発火 — 変化の激しい環境で「気づいて声を出す」

プロダクトチームは技術改善ディビジョンと比べて変化が激しいです。1か月ごとに方針が変わることもあります。検証とデリバリーのサイクルが重なり、前のサイクルが完了しないうちに次が始まる状態が続くこともありました。

この環境で身についたのは、認識ずれやブロッカーを早めに「発火」させる動きでした。

認識のずれにも種類がある

認識のずれにはいくつかの段階があると感じています。

そもそも把握していない: 情報が届いていない、または見落としている
把握しているが、重さの捉え方が違う: 同じ事実を見ているのに、優先度や緊急度の認識が異なる
把握して重さも一致しているが、良し悪しの判断が違う: 価値観やゴールの違いに起因する

自分が意識しているのは、2段階目まではなるべくなくすように力をかけることです。3段階目は価値観の問題なので議論が必要ですが、1・2段階目は情報共有と確認で解消できます。

具体例

社内管理画面の予算機能改善プロジェクト: プロジェクトのフェーズごとの完了の定義について、関係者間で認識のずれがあることに気づき、早めに指摘しました。放置していたら手戻りが大きくなっていたと思います
ディレクター承認者の育休: 承認が必要なフローで、承認者が育休に入ることを事前に把握し、代替フローの検討を提起しました。ブロッカーが顕在化する前に対処できました

なぜこの動きができたか

UM時代に培ったチームやプロセス全体を俯瞰する癖が活きました。違和感を覚えた時に、一言確認の声を上げるだけで大きな手戻りを防げる確率が上がります。ちなみに、仮に認識が合っていたとしたら「認識あってるよ、確認ありがとう」となって話が終わるだけなので、どちらに転んでもお得な行動だと思っています。

まとめ: 「穴を埋める側」として

半年間の動きを一言で表すなら、「穴を埋める側」です。

ドメインキャッチアップ: AIの限界を知り、人が設計した学びの道筋とチームの支えで足場を作りました
文化の輸入: 背中を見せて情報を残す文化を持ち込み、チームの情報の流れを変えました
仕組みの設計: 背景を理解した上で、属人的な頑張りを仕組みに変えました
問題の早期発火: 認識ずれの段階を見極め、早めに声を上げて手戻りを防ぎました

すべてに共通するのは、「チームに足りないものを見つけて埋める」動きでした。UM経験があったからこそ「何が足りないか」が見えました。ただし埋め方はUM時代とはまったく違います。権限ではなく、仕組みと合意と信頼で動かす。

振り返ってみると、自分がやっていたのはできることで信頼を積み、できないことややってみたかったことに意図的にリソースを集中させる、というサイクルでした。ドメインキャッチアップでは仕組みに助けられ、文化の輸入では前チームの経験を活かし、仕組みの設計ではUM経験が効きました。経験や学びをループさせることで、新しい環境でも足場を作れます。

正直、すべてが思い通りにいったわけではありません。チームの体制変化で構想していた改善が実行できなかったこともあったし、全部やろうとせず戦略的に自分の担当に集中した時期もありました。ただ、それも含めて権限がなくても、観察と仕組みでチームは良くなる。これは確信に変わりました。