こんにちは。クロスイノベーション本部、AIトランスフォーメーションセンターに所属している村本です。 今回は、電通総研が取り組む「OJTリーダー制度」の一環で、私がOJTリーダーとして新人の方（杉江さん）とどのように過ごしてきたかを紹介したいと思います。 なおこの記事は、OJTリーダーから見た振り返りであり、新人の杉江さんから見ると全く状況が違うかもしれません。そこで対となる記事として、新人の杉江さん目線での振り返りも投稿していただく予定です。 前提：電通総研の新人教育制度とAITCについて 新人教育の流れ 受け入れ先のAITCについて 受け入れるにあたって大事にしたこと 「新人さん」ではなく「新しいメンバー」をチームで受け入れる 新メンバーの疑問はチームにとって有意義だから、気軽に質問してね 日々のコミュニケーション：OJTリーダー以外との接点も作る 新人専用のTeamsチャネルを作り情報を集約 日報を投稿していただき、部全体からリアクションをもらえるように Teams開発部屋：リアルタイムコミュニケーションの場 開発チームメンバーとの1on1ラッシュ ゼロから機能リリースまで：半年間の実践振り返り 10月～11月：簡易生成AIアプリ開発を通じて基礎とチームの「お作法」を学ぶ 11月～1月：開発プロセスの様々なタスクを担って開発に慣れる 2月～3月：主要機能の開発リードとリリース体験 OJTリーダーとしての半年を振り返ってみて 新メンバーにとって働きやすいチームであることが大事 OJT期間はチームのプロセスをアップデートする期間 OJTリーダー1人で頑張りすぎない まとめ 前提：電通総研の新人教育制度とAITCについて まず初めに、前提として電通総研の新人教育制度について軽く触れます。 （実際に何をしたか気になる方はこの章を飛ばして読んでください） 新人教育の流れ www.dentsusoken.com 技術職で入社された方々は、入社後4～9月まで集合研修が行われます。そして、10月以降各部署に配属され、そこから半年間のOJT期間となります。この期間は、OJTリーダー（今回は私）と配属先部署（AITC）と人事部門が協力して新入社員をサポートします。（営業職で入社された方は7月時点で配属され、別の研修を受けます） 集合研修で基礎的なITスキルをじっくり学んでもらい、OJT期間で配属先に合わせたスキルを実践を通じて身につけていくイメージですね。 受け入れ先のAITCについて 私が所属しているAIトランスフォーメーションセンター（AITC）は、電通総研の中でもAIに特化したプロジェクトチームです。 aitc.dentsusoken.com AITCの中でもいくつかグループがあり、私と杉江さんはAIコアソリューショングループに所属しています。 ここでは、エンタープライズ向け生成AIソリューション「Know Narrator」の開発やAIにかかわる技術検証に取り組んでいます。 Know Narratorは自社開発のプロダクトなので、杉江さんは開発チームの一員として、プロダクト開発のスキルを身につけながら、製品の魅力向上に貢献していくことが大きな目標になります。 受け入れるにあたって大事にしたこと OJTリーダーとして、一番大事にしたのは「新人さん」じゃなくて「新しいメンバー」として受け入れることでした。 「新人さん」ではなく「新しいメンバー」をチームで受け入れる OJT期間において、最も大事なこと・目標は、新入社員の方が「チームの一員」として、「社会人」として、「開発者」として様々な経験を積むことです。 一方で、受け入れるチーム目線で見たときの目標はどうでしょうか？ 「新入社員が戦力化すること」になりがち ではないでしょうか？ しかし、この目標がすべてになったとき、 「戦力化するまでは負担なのか？」 という話になってしまいます。OJTリーダーとしても焦りますし、新人目線でもなんだか嫌ですよね。自分が負担と言われているようで。 これは非常にもったいないです。 もちろん戦力化は大きな目標の1つです。しかし、私は 「チームの暗黙知が通じないフレッシュな新メンバーが来た」と捉えて、チームのプロセスを見直すチャンス だと思うようにしました。 例えば： 新人が環境構築に時間がかかる → 環境構築するための情報が足りていない 新人がチームの動きをわかっていない→ コミュニケーションパスや担当が見えづらい 新人が開発に貢献できていない → アーキテクチャや開発プロセスが複雑すぎる こんな風に捉えるようにしました。 チーム開発は、時間が経つと暗黙知の塊になっていきます。定期的にプロセスの見直しやドキュメント整備はしますが、気づけばチームメンバー間の阿吽の呼吸に依存していることが多いんじゃないでしょうか？ 新しく来た人には、この暗黙知や阿吽の呼吸は通用しません。そしてこれは、なにも“新入社員”だからではないんです。ベテランでも同じです。 ベテランの方の戦力化が早いのは、過去の経験や自分なりのやり方を持っていて、チームにフィットする能力が高いからかと。つまり、新入社員だろうがベテランだろうが、チームに慣れるまでに多かれ少なかれ時間はかかります。 だからこそ、「戦力化する＝チームに慣れる」前に、チームとして新メンバーが働きやすい環境に変わっていけるよう、一緒に改善していく意識を大事にしました。 新メンバーの疑問はチームにとって有意義だから、気軽に質問してね この考え方は杉江さんにも伝えていました。 「あなたがOJT期間で『わからない』『コミュニケーションがとりづらい』と思うことは、チームの課題です。今後チームに入ってくるメンバーも思うことなので、気軽に言ってください。一緒に改善していきましょう」 （こんな綺麗な言い方をしたか定かではないですが、ニュアンスは伝えたはず…） こういった意識づけをすることで、少しでも質問のハードルを下げられたのならうれしいと考えていました。新人の頃は「気軽に質問してね」と言われてもなかなか気をつかうものですから。これも新人に限った話ではないとは思いますが。 「質問しやすい」環境というのは、結局「自分がチームに受け入れられている」と感じることが大事 だと思いますので、日々のコミュニケーションからチームに馴染んでいただけるよう意識しました。 日々のコミュニケーション：OJTリーダー以外との接点も作る 日々のコミュニケーションをどのようにとっていたかをまず紹介します。ここで大事にしたのは、OJTリーダーと新人の1対1の関係ではなく、「チーム全体がサポートできるよう新人と様々なメンバーとの接点を増やす」ことです。 新人専用のTeamsチャネルを作り情報を集約 【狙い】 新人に関する情報を一元化し、「ここを見ればわかる」状態にする 新人が気軽に質問でき、チームメンバーが気軽にサポートできる空間を作る 来期以降の新人もここを見れば参考にできる まず初めに、AITCに配属された新人にかかわるトピックを扱う専用Teamsチャネルを作成しました。このチャネルはAITCメンバーであればだれでも閲覧・コメント可能です。 実際に、「初めての顔合わせ時の服装」という新人にとってはハードルの高いトピックも、気軽にやり取りされていました。 以下のような形で、新人の方へ宣伝するメンバーも。 日報を投稿していただき、部全体からリアクションをもらえるように 【狙い】 新人が日報を通じて文章を書く力、取り組んだことを整理・アウトプットする力を身に着ける AITC全体で新人が取り組んでいることや困っていることを把握し、サポートできるようにする 配属後2か月間、上記の新人専用Teamsチャネル内での専用スレッド上に、YWTP形式（やったこと・わかったこと・できたこと・問題）の日報を書いていただきました。 日報はOJTリーダーが、新人の方が自分のこなしているタスクを理解できているか？問題や悩み事はなにか？を把握する1つの手段になります。またTeamsですので他のAITCメンバーも見ることができます。 下図は一例ですが、「オフィスのプリンタ設定がうまくいかない」というコメントに対して、OJTリーダーではないAITCのメンバーの方からマニュアルリンクが連携される様子です なお、日報自体は開発チームとしても導入している仕組みで、開発チームに入る杉江さんには1月以降も継続して日報を書いていただいています。 Teams開発部屋：リアルタイムコミュニケーションの場 【狙い】 開発チームの日常的なコミュニケーション環境に新人を組み込む わからないことがあったときにOJTリーダーだけでなく、その場にいるメンバーがサポートできる環境を作る こちらは以前別記事でも紹介した取り組みになります。 tech.dentsusoken.com 開発チームでは、「開発部屋」としてTeamsの会議ルームを作業時間中立ち上げっぱなしにしています（通常時マイクとカメラはオフで、自由に離席してよいです。詳細は上記記事にて）。 杉江さんにもこの開発部屋に参加していただき、質問や聞きたいことがあればここで聞いていただくようにしました。 こうすることで、私以外のメンバーも何をしているか認知しやすくなりますし、私が不在のときも、ほかのメンバーにサポートしていただくことができます。また、杉江さんにとっても周りがどういうことに取り組んでいるか知る機会につながったのではないかな？と思います。 実際、私が1週間ほど海外出張でサポートできない期間がありましたが、ほかの開発メンバーとコミュニケーションをとりながら作業を進めてくれていました。 開発チームメンバーとの1on1ラッシュ 【狙い】 開発チームのメンバーと新人の関係性を構築する スケジュール調整などの実務を経験していただく 電通総研では1on1文化があり、とくに開発チームでは毎回新メンバーに開発チーム全員との1on1ラッシュを行ってもらっています。 何度も言いますが、新人さんを受け入れるというのは何もOJTリーダーだけが行うのではありません。チーム全体で受け入れるのです。そのためにも相互に理解をしていくのは必要で、ざっくばらんに会話する機会を用意しています。 また、1on1のスケジュール調整を新人さんにリードしてもらい、社内のツールにも慣れつつスケジュール調整の練習をしていただきました。 ゼロから機能リリースまで：半年間の実践振り返り 半年間で具体的にどのようなことに取り組んできたか、ざっくりとした時系列で紹介します。 10月～11月：簡易生成AIアプリ開発を通じて基礎とチームの「お作法」を学ぶ 【主に取り組んだこと】 Know Narratorをユーザーとして触ってみて、リバースエンジニアリング的な手法で理解を深める 既存コードには触れず、1からリポジトリを作成して環境構築・実装・テストを行う 製品へ導入予定の技術領域の検証を進める 開発プロセスは本番チームを踏襲（タスク分解→実装→テスト→コードレビュー） 【狙い、身に着けてほしいスキル】 完全に0から自力で簡易な生成AIアプリを作り「動くものができた」という体験を積み重ねる。 Know Narrator開発のお作法をこちらでも採用して、お作法に慣れていただく タスクの進め方や困ったときの相談など、OJTリーダーとの会話を通して慣れていただく 未知の技術を自分で調べて実装する経験をしていただく 【成果】 Pythonプロジェクトの環境構築（自動テスト・フォーマット含む）から生成AIアプリ作成までを完遂した 上記の過程で学んだ知見を、本番プロダクト（Know Narrator）のCI/CD改善にも還元した 検証過程で得られた技術情報をチームへ共有し、後の顧客向け機能開発の基礎となった 最初の2か月は1on1やチームの動きに慣れていただきながら、Know Narratorのコードベースとは別の場所で、0から簡単な生成AIアプリを作っていただきました。 Know Narratorのコードベースはすでに大規模になっており、製品開発未経験の方がいきなり触れるにはハードルが高いです。また、 既に開発が進んでいる製品側は環境周りやCI/CDが整備されすぎているため、「自分で環境を作り上げる経験」が積みにくい という懸念もありました。 そこで、私から以下のようなタスクをステップごとに渡しつつ、杉江さん自身でいろいろ調べながら実装していただきました。 StepをこなすたびにPRを上げてもらい、Teamsの専用スレッドで連絡をしていただく。そしてそのPRを私がレビューするという流れで進めていきました。これは開発チームの普段の開発スタイルそのものです。 AIツールの利用も任せていましたが、PRの内容や報告内容について私が質問したときに自分の言葉で答えられるようにはしてもらいました。「AIに聞いたら○○だったので...」ではなく、AIツールを利用して得られた知見を基に、自分の理解・言葉で話してもらう練習をしていただく形です。 一方、OJTリーダー目線・開発チーム目線でもこの進め方はメリットがありました。 杉江さんが出したPRを見るなかで新たな発見があり、その知見をそのまま製品のCI/CDに組み込みました。やはり既に環境（CI/CD）などが整っている製品側だと、改めて調べなおして改善する機会がなく、改善の優先度はどうしても落ちますからね 。そういう意味でも0から調べながら進めてもらえたのはよかったと思います。 最終的には、画像生成などができる簡単なチャットアプリを実装し、そこで調べていただいた内容や作ったアプリを開発チームに共有していただきました。また、共有していただいた技術要素の一部はその後、Know Narratorの機能開発に活かされ、実際にお客さまの手元に届いています。 11月～1月：開発プロセスの様々なタスクを担って開発に慣れる 【主に取り組んだこと】 Know Narratorの開発環境を構築、環境構築手順書の改善を行う リリース前のシナリオテスト実施と、バグ修正・リファクタリング 社内で開催されていたAI Coding学習会への参加 【狙い、身に着けてほしいスキル】 環境構築を通じて、手順書の「初見でわかりにくい点」を洗い出し改善する 実際の開発タスク（テスト・バグ修正）をこなし、チーム開発のフローに慣れる 既存コードのリファクタリングを通じて、コードベースの構造を理解する 【成果】 改善された環境構築手順書により、後に参画したパートナー企業のオンボーディング工数が削減された シナリオテストを通じてリリース前のバグを発見・修正し、品質担保に貢献した 既存メンバーが着手できていなかったコードのリファクタリングを完遂し、可読性と保守性を向上させた 開発のキャッチアップを終え、11月中旬からは実際のKnow Narrator開発に参加していただきました。 まずは環境構築からスタートです。 手順書はある程度整備されていましたが、それでも「初めて触る人」にしかわからないつまづきポイントはあるもの です。そこで、環境構築と並行して手順書の改善も依頼しました。 結果、ブラッシュアップされた手順書は、その後チームに参画した新メンバーの方にも共有され、環境構築のフォローをする時間を削減できました。「新メンバーの『わからない』はチームの資産になる」という良い実例だったと思います。 環境構築後は、シナリオテストを通じて製品理解を深めていただきました。テスト中に発見したバグは、起票から修正まで一貫して杉江さんに担当していただきました。 ソリューションの品質に、配属後2か月で貢献 できたのは素晴らしいです。 その後、機能開発へ進む予定でしたが、対象コードが複雑化していたため、まずはリファクタリングに取り組んでいただくことにしました。「最初の大きな実装タスクがリファクタリングで良いのか？」という迷いはありましたが、結果として 「コードの構造理解にとても役立った」 という感想を杉江さんからいただきました。（本音だったと思っています） このリファクタリングでは、既存メンバーが手を付けられていなかった技術的負債を解消できたため、チームとしても非常に助かる成果となりました。 2月～3月：主要機能の開発リードとリリース体験 【主に取り組んだこと】 継続してシナリオテストや様々な開発タスクに取り組んでいただく 主要機能の実装・テストをリードし、月次リリースにて顧客へ提供する 【狙い、身に着けてほしいスキル】 自分が実装した機能が製品として世に出る喜びと、そのためにすべきことを経験していただく 大きな機能開発を通して、設計や実装、テストはもちろん、自身のタスク整理や周辺とのコミュニケーションの経験を積む プロダクトオーナーやビジネスオーナーに対して、機能の開発状況や仕様について説明する経験をしていただく 【成果】 杉江さんが検証や仕様整理から取り組んだ機能が3月末のリリースに含まれた 開発チームの一員として様々なタスクをこなしチームに貢献した チーム外のステークホルダーに対し、実装された機能の紹介やデモなどを行った 2月からは、完全に1人の開発メンバーとして、様々な実装タスクに取り組んでいただくようになりました。OJTリーダーとして、杉江さんのタスクの調整や設計の指針を出すことはあっても、基本的には自律的に動いてもらえたと思います。 技術的にも、既存のコードのアーキテクチャを理解しての質問ができるようになっていた印象でした。また、「わからないことを聞く」ということも積極的に取り組めていたと思います。 そして、3月アップデート（Know Narratorは月次で機能追加などのアップデートを行っています）にて、 主要機能の1つを杉江さんの実装により提供 することができました。 「目標に対して何が足りないか？」「どこを修正すべきか？」といったタスク整理や、関係者とのコミュニケーションに取り組んでもらえたかと思います。 OJTリーダーとしての半年を振り返ってみて まずは、杉江さんが本当によく頑張ってくれたと感じています。 配属されて半年以内に顧客提供される機能の開発の実装を自律的に進めていただけたのは素晴らしい成果だと思います。進化の激しい生成AIにおいて、生成AIの理解を進めながらソフトウェア開発のスキルも着実に積んでいただけたのかなと。これからの活躍にも大いに期待しています。 新メンバーにとって働きやすいチームであることが大事 あらためて振り返ってみても、 「“新人”ではなく“新メンバー”として受け入れる」 というスタンスを大事にしたのはよかったなと思います。 杉江さんが感じた「疑問」や「やりづらさ」を共有してもらい、それをチームの課題として一緒に改善できたことは、私にとっても大きな収穫でした。 実際に杉江さんがどう感じていたかは彼自身の記事に譲りますが、少なくとも「やりづらいのは個人の責任ではなく、基本的にチームのプロセスの問題」というスタンスで接することは、心理的安全性の高いチーム作りにおいて大事であると私は思います。 もちろん個人の努力で解決すべきことがあるのはわかっています。お互いに指摘することも大事でしょう。しかし、信頼関係やリスペクトがなければ、新人・ベテラン問わず働きにくい職場になってしまいます。 私自身が「働きやすい」と思えるチームであり続けるためにも、このマインドはこれからも大事にしていきたいなと思っています。 OJT期間はチームのプロセスをアップデートする期間 今回のやり方がすべてのプロジェクトで通用するわけではありませんが、どんな状況であれ「今、新メンバーが来たらどう受け入れるか？」を常に意識しておくことは重要です。あくまで今回の私たちのやり方は、 2025年10月時点でのKnow NarratorチームとしてのOJT だったと思います。次のOJTでは、おそらく違うことに取り組んでもらうことになるでしょう。 このような環境だからと言って、OJTを「新人の育成＝コストがかかるもの」と捉えるのは非常にもったいないですし、新人にとってはやりづらさを生む要因でしょう。 人の入れ替わりは起きるものだし、新人が来てくれるのはありがたいこと なのです。せっかく迎え入れるなら「チームのプロセスを見直す絶好の機会」と捉えて、チーム全体で成長していければと考えています。 OJTリーダー1人で頑張りすぎない OJTリーダーを担当すると、どうしても個人の業務負荷は増えます。だからこそ、「チーム全体で受け入れる」という文化・スタンスが重要です。 実際に、私もOJTリーダーとして研修などに参加しないといけないときは、ほかの方に自分のタスクを巻き取ってもらうなどサポートをいただきました。前述の通り、最初の2か月間は個別で演習課題のやり取りをしていたので、開発タスクはなるべく軽いものやレビューのみにするなど動き方も調整していました。このように、新人だけでなく、OJTリーダー側のサポートがあることは想像以上に大きかったなと感じています。 ただ、「チームのサポートが大事！」と思っていても、実際問題すぐにサポートをもらえる環境になっているのか？と言われると難しいものでしょう。人事部門からも各部署に対する説明などはしていただいていますが、現場レベルにその意識が落ちているか？は難しい課題だと思います。 OJTリーダーになったからには、自分が1人で抱え込まないためにも、周囲を巻き込むアクションが必要なのだろうと思いました。新人とチームの方々のコミュニケーションを促すこと、チームの方にOJTでどのようなことをしているかアピールすること。私はこのようなアクションをとりやすいチーム文化があったのが幸いしましたが、自分がチーム側の立場になったときもOJTペアの様子は意識していきたいですね。 上位者やチームがOJTに対して理解を深める。OJTリーダーはしっかり周りを巻き込みながら、新人も自分も働きやすい環境を整備する。このような心がけをこれからも積み重ねていきたいです。 まとめ 半年間のOJTを、OJTリーダー目線で振り返ってみました。 新人の方がめきめきと成長し、チームの戦力になっていく姿を間近で見られるのは、OJTリーダーならではの楽しさです。実際、前職でも1度OJTリーダーを担当しましたが、2回目の今回も非常に楽しかったです。 OJTリーダーの負担は確かにありますが、新人の方にはまったく関係のない話ですし、チームにとっても「新しい風」を取り込む重要なプロセスです。 自分がOJTリーダーになるにしろならないにしろ、チームに新メンバーがやってくる際は、「入ってきた方をどう受け入れ、どうトモに成長するか」に集中し、双方にとって有意義な期間にできるよう前向きにとらえていきたいですね。 最後までお読みいただきありがとうございました。杉江さん視点の記事も公開されますので、ぜひ併せてご覧ください！もしかしたら、全然違う感じ方をしているかもしれません！！！ 私たちは共に働いていただける仲間を募集しています！ みなさまのご応募、お待ちしています！ 株式会社電通総研 新卒採用サイト 株式会社電通総研 キャリア採用サイト 執筆： @naoki.muramoto レビュー： @miyazawa.hibiki （ Shodo で執筆されました ）

はじめに アジャイル開発では、短いサイクルで実装と検証を回し、できるだけ早く価値を届け続けることが求められます。 その際に課題になりやすいのが、コードをどこで統合し、どの状態を基準とし、いつリリース可能とみなすかという運用です。 その運用を支える仕組みがブランチ戦略です。 ブランチ戦略は、プロジェクト特性に応じて適切に選択する必要があります。 さらに最近は、生成 AI の活用も現場の前提になりつつあります。より高速な開発・リリースサイクルに耐えうるブランチ戦略の策定は、ますます重要になっています。 本記事では、アジャイル開発におけるブランチ戦略の全体像と考え方を、初心者向けに分かりや

2026年3月24日、サポーターズ主催のオンライン勉強会「全エンジニアEM化説」が開催され、JAPAN AI株式会社（ジーニーグループ）Product Dev Group 部長 Leon Xuが登壇しました。 生成AIやコーディングエージェントの進化により、エンジニアの役割はこれまでにないスピードで変化しています。実際、ソフトウェア開発の現場では「AIがコードを書く時代に、人間のエンジニアの価値はどこに残るのか」「本当に全員にマネジメント視点が求められるようになるのか」といった疑問や不安に向き合うことが増えてきました。 今回のセッションでは、そうした変化の実態を紐解き、これからのエンジ