G-gen の高宮です。当記事は、Google Cloud Next '26 in Las Vegas の 3 日目に行われたブレイクアウトセッション「 Accelerate CI/CD with coding agents 」のレポートです。 G-gen Tech Blog では、現地でイベントに参加したメンバーや、日本から情報をウォッチするメンバーが、Google Cloud Next '26 に関連する記事を発信します。 blog.g-gen.co.jp セッションの概要 ソフトウェア開発の加速と CI/CD の課題 Google CI/CD Extension の概要と特徴 Google CI/CD Extension を用いたデモ 1. Cloud Run への自動デプロイとシークレットスキャン 2. 複数ステージの CI/CD パイプライン設計 3. Terraform による Infrastructure as Code の生成 セッションの概要 本セッションでは、Google の Haroon Chaudhry 氏（Software Development Manager）と Yeshwanth Gunasekaran 氏（Software Engineer）が登壇しました。 セッションでは、生成 AI を用いてコードを記述した後、本番環境へデプロイするまでの CI/CD パイプライン構築に関する課題と、それを解決するための新しい拡張機能である Google CI/CD Extension が発表され、デモを交えて紹介されました。 ソフトウェア開発の加速と CI/CD の課題 2026年4月現在、生成 AI の普及により、開発者の 90% が日常的に AI を使用しています。しかし、AI によって生成されたアプリケーションを本番環境へデプロイする際、約 60% の開発者が課題に直面していると語られました。安全な CI/CD パイプラインを構築するには、単にスクリプトを生成するだけでなく、多様なツールが混在する複雑な環境全体を適切に制御する必要があるからです。 複数の CI/CD プラットフォームの利用、DevSecOps ツールの統合、インフラストラクチャとコードの連携などの課題により、AI の CI/CD 領域での採用率は 27% に留まっています。AI エージェントは単なるコード生成ツールから、インフラストラクチャ全体を統合するオーケストレーターへと進化する必要があることが強調されました。 Google CI/CD Extension の概要と特徴 この課題を解決するため、Gemini エージェントを統合オーケストレーターとして機能させる Google CI/CD Extension が発表されました。 この拡張機能は、 Gemini CLI の拡張機能および Claude Code プラグインとして利用可能であり、オープンソースとして提供されます。 Cloud Run や Google Kubernetes Engine （GKE）などのランタイムに対応しており、自然言語を用いて CI/CD パイプラインの設計、構築、デプロイを行うことができます。 参考 : Gemini CLIを解説 - G-gen Tech Blog 参考 : GitHub Repository : Gemini CLI Extension for CI/CD Google CI/CD Extension は、以下の 4 つのコンポーネントで構成されています。 コンポーネント 説明 Skills CI/CD パイプラインの設計やデプロイに関する事前定義されたワークフローと知識。 Local MCP Server ユーザーの認証情報で実行され、Google Cloud の CI/CD ツールを管理するローカルの Model Context Protocol サーバー。 Grounding through knowledge base CI/CD のベストプラクティスやデプロイメントパターンをパッケージ化したナレッジベース。 Offline Evals オープンソースや独自開発のプロジェクトにおける設計・デプロイパターンをテストする評価システム。 Google CI/CD Extension を用いたデモ 1. Cloud Run への自動デプロイとシークレットスキャン 最初のデモでは、Cloud Code を用いて Python の Flask アプリケーションを Cloud Run にデプロイする様子が示されました。エージェントはアプリケーションの構成を理解し、 Buildpacks を使用してコンテナイメージを構築します。 参考 : Google Cloud の Buildpack 注目すべき点として、コンテナイメージをクラウド上にプッシュする前に、ハードコードされた認証情報がないかを確認するシークレットスキャンが、拡張機能の組み込みチェックとして自動的に実行されました。安全性が確認された後、ユーザーがリージョンや公開設定を指定すると、Cloud Run へのデプロイが完了しました。 2. 複数ステージの CI/CD パイプライン設計 2 つ目のデモでは、Gemini CLI を使用して、 Cloud Build と Cloud Deploy を使用した複数ステージのパイプライン設計が行われました。 参考 : Cloud Build の概要 参考 : Cloud Deploy の概要 以下のプロンプトで指示すると、エージェントは自律的なパイプライン構築ステップを開始しました。 アプリケーション向けに、ステージング環境と本番環境を含む CI/CD パイプラインを設計してください。失敗時に自動ロールバックを行い、Cloud Build と Cloud Deploy を使用してください。 CI/CD パイプライン構築のステップは以下のとおりです。 No 概要 内容 1 要件定義と計画 専用の Skills（ google-cicd-pipeline-design 、 google-cicd-release-orchestration ）を使用し、Google のベストプラクティスに基づいた計画を立案。 2 デプロイパイプライン構成生成 各環境の Cloud Deploy 構成ファイルを生成。承認ゲートや自動ロールバックルールを自動で組み込み。 3 インフラセットアップ Developer Connect による GitHub 接続、 Artifact Registry 作成、最小権限の IAM ロールを付与したサービスアカウントを準備。 4 ビルド構成の実装 Cloud Build 構成ファイルを作成。リポジトリへのプッシュをトリガーとしたエンドツーエンドのフローを完成。 参考 : google-cicd-pipeline-design 参考 : google-cicd-release-orchestration 参考 : 構成スキーマ リファレンス 参考 : ビルド構成ファイルを作成する 3. Terraform による Infrastructure as Code の生成 最後のデモでは、設計された CI/CD パイプラインのインフラストラクチャを、 Terraform を用いたコードとして生成する様子が披露されました。元のプロンプトに 「Terraform を生成して。」 の1文を追加するだけで、エージェントは専用の Skills google-cicd-terraform を呼び出し、必要な設定ファイルを出力します。 参考 : google-cicd-terraform 生成されたファイルには、Artifact Registry、Cloud Build、Cloud Deploy の設定に加え、専用のサービスアカウントや厳格な IAM ロールの付与までがコード化されており、本番環境レベルのパイプライン構築が対話のみで完結することが示されました。 高宮 怜 (記事一覧) クラウドソリューション部クラウドエクスプローラ課 2025年6月より、G-genにジョイン。前職は四国のSIerで電力、製造業系のお客様に対して、PM／APエンジニアとして、要件定義から運用保守まで全工程を担当。現在はGoogle Cloudを学びながら、フルスタックエンジニアを目指してクラウドエンジニアとしてのスキルを習得中。 Follow @Ggen_RTakamiya

TechHarmonyエンジニアブログでは、 AWS・Oracle Cloud・Azure・Google Cloud 各分野の受賞者 にフォーカスし、インタビューを通してこれまでの経歴や他の受賞者に聞いてみたいことをつないでいく「 リレーインタビュー 」をお届けしています。 第7弾は、「2025 Japan AWS Ambassadors」 を受賞された広野 祐司（ひろの ゆうじ）さん。 Japan AWS Top Engineers は、特定の AWS 認定資格を持ち、AWS ビジネス拡大につながる技術力を発揮した活動を行っている方、または技術力を発揮した重要な活動や成果がある方が選出されるプログラムです。 日々どのようにAWSと向き合い、どんな経験を積み重ねてきたのか。 そして、受賞に至るまでの背景には、どのようなキャリアストーリーがあったのでしょうか。 本インタビューでは、広野さんのこれまでの経歴やAWSへの向き合い方、さらに「次の受賞者へ聞いてみたいこと」まで、じっくりとお話を伺いました。 プロフィール 2025 Japan AWS Ambassadors 所属：クラウド事業本部クラウドサービス第二部 氏名：広野 祐司   【自己紹介】 社内クラウド人材育成や、お客様向け内製化支援をしています。 AWS サーバーレスサービスと React を使用した当社独自教育アプリ開発とそのコンテンツ作成をしており、その過程で得た AWS 技術情報をさらにコンテンツに追加したり、お客様案件に活用したりするサイクルを回しています。 本編 AWSエンジニアになった背景を教えてください。 12年間のグループ会社出向から帰任することが決まったときにちょうど 当社 社員向けAWS教育を強化する会社方針が打ち出され、その 教育担当としてアサインされたこと がきっかけ です。 AWS未経験の教育担当という負い目を感じていたので、当初は必死でAWS資格取得を頑張りました。そのうち研修講師をすることが非効率だと感じるようになって e-Learningツール を開発したり、マネジメント層への研修成果報告に労力がかかっていたので 社員の受講状況・資格取得状況を可視化するツール を開発したり、と 自分のAWSの勉強も兼ねてアプリ開発をしていたら、それが得意分野になってしまいました。 今ではその経験からお客様にアドバイスする立場になっています。ようやくAWS教育ができるようになった、と胸を張って言えるようになったかな、とこれを書きながら改めて思いました。 エンジニアとして大切にしている価値観や信条はありますか？ 自分が手を動かして、 つくりたいものを自由につくれるエンジニアでありたい と 考えています。 自分が手を動かしているからこそ得られる洞察があり、他人へのアドバイスも現実的、実践的なものにできる と考えています。その代わり、広範囲をカバーすることができないデメリットはありますが、そこは割り切っています。 私は 「高くてうまいは当たり前、早くて安くてうまいを追求したい」 という考えを常に持っています。IT文脈において「うまい」を「品質が高い」という意味に置き換えると、それを前提に ITで何か目的を達成したいと考えたとき、クラウドの利用が不可欠で、かつマネージドサービス、サーバーレスアーキテクチャを優先的に採用して設計することが必然になります。 元々私がハードウェアが好きではなかったというのもあり、低レイヤーの技術から解放してくれる、ソフトウェアとしてITシステムを構築できるクラウドは私に合っていましたね。 この度は受賞おめでとうございます！ 受賞に至るまで特に重点を置いて取り組んできたこと・乗り越えたチャレンジを教えてください。 AWS領域で既に社内で先人達が活躍している中で、 自分が早期に勝負できる技術領域はどこになるのか 、 をまず考えました。 先人達と比べると数年のディスアドバンテージがあったので、 当時まだあまり使われていなかったサーバーレスであれば先駆者になれると思い、VPC、EC2、コンテナはすっ飛ばしてサーバーレス技術習得にチャレンジ しました。 結果的にその選択は良かったと思っていて、サーバーレス領域においてはすぐに社内から相談をもらえる存在になることができました。 受賞がご自身のキャリアやチームに与えた影響はありますか？ 私自身の プレゼンスが向上した と感じました。AWSが社内外で受賞者を称賛したことで知名度が上がり、登壇依頼が増えたことで実感しました。 社外の受賞者と会話したことで、自分の強み、弱みを知ることもでき、強みに関しては負けていない、と自信を持つこともできました。 言葉は悪いですがAWS未経験から数年での成り上がり人生は、笑い話にして毎年当社新入社員研修で講演させてもらっています。ただし、それまでのAWS以外のIT業務経験が大きな下支えになっていることは間違いなく、 これまでやってきたことは1つも無駄になっていない ことを新入社員に伝えています。そういう気持ちでこれからの長い社会人人生に取り組んで欲しいという思いです。 今後、個人として、挑戦してみたい新しい技術・分野や、目指している目標について教えてください。 私は 身に着けた技術力はどんどん捨てていくもの だと考えています。ITは特にそうだと思うのですが、日々新しい技術が開発されるので、古い技術に固執していては時代に取り残されてしまいます。過去の知識、経験は今の自分を育てるために必要だったと強く思いますし、必要あれば引き出しから取り出しますが、 他の新しい技術領域に鞍替えすることに迷いはない です。 今は サーバーレスとAI領域でまだまだやることがある と考えていますが、これは面白いな、と思ったことがあればまた転身すると思います。変な話、面白い、と思えることが私が挑戦する動機なのかもしれません。 私は野心家ではないので、何か大きなことを成し遂げたい！という野望はなく、 将来は個人で開発したスマホアプリで一儲けしたい な、 ぐらいのことを考えています。 前回のリレーインタビューでの安彦 洋樹さんから 広野さんへのご質問です。ご回答をお願いいたします 広野さんはAmbassadorとして、これまで主にクラウドネイティブ、DevOps、モダンWebアプリケーション開発等の第一人者として技術者育成に尽力されてきたかと思います。しかし近年AIの台頭により本領域についても変革期を迎えていると感じているのですが、広野さんはこの状況に対し、 今後はどのような取り組みを構想されていますでしょうか。 これまで提供してきたトレーニングで身に着けていただいたことは、既にAIが人に代わってできるようになってきています。そのため、例えば既存の実践トレーニングを開催するにしても、 AIを活用してトレーニングの目的を達成する方向に変えています。 また、AI-DLCに代表される、開発におけるAI活用では Git, IaC, CI/CD の相性が良く、それらがますます求められていると感じています。改めて、 その技術領域の教育もセットでAIを活用できる人材の育成 を考えたいです。 次のインタビューは AWS Top Engineers の「貝塚 広行」さんです！貝塚さんにお聞きしたいことはありますか？ 貝塚さんは長年ネットワークやLinux領域に従事された後、クラウド領域に活躍の幅を広げられたと思います。貝塚さんご自身はクラウドがない時代からIT業界にいたわけなので、その順で学習されてきたことは自明なのですが、今、 IT技術の学習をクラウドから始めた若手がネットワークなどの基盤技術を学習しようと思ったら、どうしたらよいと思いますか？ 広野 祐司さん、ありがとうございました！ 最後に、読者の方へメッセージをお願いいたします！ 人間って、好きなことでないと続かないな、とすごく感じています。多くの人にとって、仕事を通して自分の技術力を大きく向上させられることは稀で、基本的にはプライベートな時間に勉強していくしかないと考えています。それが仕事で自分の立ち位置を確立することにつながります。でもそれって、好きでないとできないな、と。自分が何を好きなのか、何であれば頑張れるのか、を見つけることは今後のキャリアに大きく影響するので、そういうことも意識して仕事に取り組んでもらえたらと思います。     次回インタビューは、2025 Japan AWS Ambassadors を受賞された 貝塚 広行（かいづか ひろゆき） さんです。 次回の記事もお楽しみにお待ちください！

こんにちは。クロスイノベーション本部、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 で執筆されました ）