こんにちは！クロスイノベーション本部 AIトランスフォーメーションセンターの杉江です。
今回は、電通総研の「OJTリーダー制度」における半年間のOJT期間で、私が配属先で経験したことを紹介したいと思います。
先に公開された、私のOJTリーダーを担当してくださった村本さんの記事とあわせて読んでいただくと、OJTリーダー目線と新人目線で、同じOJT期間をどう捉えていたのかの違いも見えてくるかもしれません。
配属先について
新人教育制度の詳細はOJTリーダー側の振り返り記事で説明されているので、ここでは私の配属先について軽く触れておきます。
私は新人研修後、AIトランスフォーメーションセンター（AITC）のAIコアソリューショングループに配属されました。概要は以下のとおりです。簡単にまとめると、生成AIソリューション「Know Narrator（以下、KN）」の開発メンバーとして配属されたということです！
AITCは電通総研の中にあるAIに特化したプロジェクトチームになります。さらにAITCの中でもソリューション系グループ（ソリューションコア・ソリューションアプリ）とコンサルティンググループに分かれており、私と新入社員の方はソリューションコアグループに所属しています。ソリューション系グループでは、エンタープライズ向け生成AIソリューション「Know Narrator」の開発、魅力向上に向けた技術検証等を行っています。
Know Narratorは自社開発を行っているプロダクトになりますので、ソリューション系グループが連携しながら開発をしています。つまり、新入社員の方は開発チームの一員となり、プロダクト開発における様々なスキルを身に着けながら、プロダクトの魅力向上に貢献していくことが大きな目標となっていきます。
配属当初の自分と、半年後の自分
半年で取り組んだことを紹介する前に、配属当初の自分がどのような状態だったのか、そしてOJT期間を半年過ごした後にどう変わったのかを先に紹介したいと思います。
配属当初の自分
まず、配属当初の自分の状態について紹介します。
経歴
- 情報工学専攻の大学院卒
- 基本情報技術者試験：合格
わかっていたこと
- プログラミング：大学の授業や研究を通じて、プログラミングの経験はある程度あった
不安だったこと
- クラウド： AWSやAzure等をほとんど触ったことがない
- AI: ChatGPTやGitHub Copilotを使ったことがある程度
- チーム開発： ちゃんと取り組んだのは新人研修が初めて
こうして振り返ると、配属当初の自分は開発チームのメンバーとして、戦力になれる状態では全くありませんでした。
ただ、これは特別なことではなく、多くの新卒社員が似たような状態で配属されるのではないかと思います。
配属半年後の自分
半年後には、配属当初に感じていた不安がすべてなくなったわけではありませんが、少なくとも「何もわからない状態」からはかなり前に進めたと思います。不安だったポイントも以下のように変わりました。
不安だった点が、半年後にはどう変わったか
- クラウド： Azureの資格を二つ取得し、業務の中でもAzureの画面の簡単な操作ができるようになった。
- AI: 生成AIソリューションの機能開発を担い、普段の開発でもAIを活用している。また、最新技術を調査してチームに共有する経験を通して、理解を深めた。
- チーム開発： 開発チームに本格的に入り、Know Narratorの主要機能の1つを仕様整理から実装、テストまで一貫して主担当としてかかわり、周囲と連携しながらリリースに貢献できるようになった。
配属当初の自分が抱えていた不安は、半年のOJT期間を通じて、実際に手を動かしながら少しずつ埋めていくことができました。
具体的な取り組みとその感想
ここから、どのような取り組みを通じて成長できたかについて時系列で振り返っていきます。
10月〜11月：まずは0から作って学ぶ
OJTリーダー側の振り返り記事では、この時期の取り組みが次のように整理されています。これを踏まえて、自分でも振り返りたいと思います。
【主に取り組んだこと】
Know Narratorを1ユーザーとしていろいろ触って機能の理解を深める
OJTリーダーが個別にタスクを指示し、新人はそのタスクを達成するための実装を行う
1からリポジトリを作り、環境を構築し、実装‧テストまで行う実装プロセスはKN開発を踏襲し、タスク分解→実装→テスト→コードレビューの流れで進める【狙い、身に着けてほしいスキル】
「できた」という感覚を味わっていただくために、完全に0から始めて自力で少しずつ実装し簡単な生成AIアプリを作る
KN開発でのお作法をこちらでも導入しながら進めることで、お作法になれるタスクの進め方や困ったときの相談など、OJTリーダーとの会話を通して慣れていただく実際に製品導入が予定されている機能の先駆け検証‧チーム共有を行うことで、チーム‧製品への貢献を感じていただく
共有時にどのように情報を整理すれば伝わるかなどをチーム内で経験する
10月〜11月は、製品開発に直接関わるというより、まずはKnow Narratorがどのような製品なのかを知ることと、Know Narratorの開発環境で使われている技術のキャッチアップを進めることに取り組みました。
まずKnow Narratorという製品を知るために、まずは実際にシステムを触ってみることから始めました。
ここでは、ユーザー目線で押せるボタンを一通り触り、何が起きるかを見たり、裏側でどう処理されているのか気になった点を日報に書いたりしながら進めました。当時は「新人に任せる仕事がないから、やっているのかな？」と思っていた部分もありました。しかし、開発に関わるシステムを理解するために非常に重要な時間だったと、今になって思います。
技術のキャッチアップでは、Gitのリポジトリを1から作り、簡単なAIチャットアプリを作りながら、開発で必要なAIや開発環境の知識、プログラミングのお作法などを学びます。
OJTリーダーから小さなタスクを一つずつもらい、対象の技術をキャッチアップしながら、実装、Pull Requestの作成、レビューという流れで進めました。
基本的にはまず自分なりに進め、その成果物に対してOJTリーダーの村本さんだけでなく、他の開発メンバーからもコメントやアドバイスをいただけたので、タスクを進めるたびに新しい気づきを得ることができました。
下図は実際に作っていたアプリです。
リポジトリを1から作ることのメリットは、リポジトリ内のすべてのコードを自分が把握している状態で進められることにあると感じました。既にプロジェクトとして時間が経っているチームに後から入ると、既存のコードを理解するのに大きな労力がかかります。また、開発環境の構築や設計のように、既に整備されている部分を自分で作る経験も得にくいと思います。
開発チームでは、コードフォーマッターやリンター、GitHubでPull Requestを出したときに動く自動テストやレビューなど、品質を保つための仕組みがいくつも整備されています。こうした仕組みについても、自分で1から構築したことで、のちに開発メンバーとして本格的に入ったときも、「なんか勝手にいい感じに動いている」ではなく、裏側でどのような仕組みが動いているのかをイメージしやすくなりました。
また、キャッチアップと同時に、製品に今後導入予定だった技術の調査と検証を実施しました。検証では上記チャットアプリに技術を組み込み、そのノウハウをドキュメント化。開発チームに連携しました。
公式ドキュメントの内容をそのまままとめるだけではなく、気になったところを追加で調べたり、実際に動かしたコードを載せたりすることで、初めてチーム内で価値のあるドキュメントにできたと感じています。このとき作成したドキュメントが、その後の開発で他のメンバーの参考になったのは、自分にとってもうれしい経験でした。
この時期にAzureの基礎的な資格も二つ取得しました。とはいえ、資格だけでは業務にほとんど応用できないことを後々感じることが多かったです。来年以降は、作成したチャットアプリをAzure上でデプロイしてみてもいいかなとも思います。
11月〜1月：KN開発に入って感じた壁と、慣れるまで
11月の後半から1月について取り組んだことは以下のとおりです。（OJTリーダー側の振り返り記事から引用）
【主に取り組んだこと】
Know Narratorの開発環境を構築、環境構築手順資料の改善を行う
Know Narratorでリリース前に行っているシナリオテスト行う軽微なバグの修正作業や、コードのリファクタリングを行う
社内で開催されていたAI Coding学習会に参加する
【狙い、身に着けてほしいスキル】
環境構築をしながら既存の環境構築資料をどう改善すればよりわかりやすくなるか考えていただく
Know Narrator開発におけるタスクをこなしながら、チーム開発‧チームメンバーとのコミュニケーションに慣れる
Know Narratorのコードベースに対する理解を深める
11月からは本格的に開発チームの一員として、タスクを進めることになりました。
まずはKnow Narratorを開発するための環境構築をしました。村本さんから、「わかりづらいドキュメントだなと不満に感じたら、次から入ってくる人も感じるところなのでガンガン直してくれたら嬉しい」みたいなことをよく言われていたので、実際にいくつか修正したり、自分で新しくドキュメントを作ったりもしました。
実際、二年目の先輩が昨年環境構築した際に残していたドキュメントに大変助けられたりしたので、ドキュメントを残すことの重要性や、足りなかったら自分で直すという意識づけがここで徹底できたかなと思います。
環境構築が終わった後に最初の大きなタスクとなったのが、リファクタリングでした。
実は最初に取り組むはずだった機能開発を進めるにあたり、コードベース上にいくつかの課題があったのです。この課題を解決しないことには実装作業が進められないと判断され、リファクタリングをやってみましょうという流れになりました。
初めて本格的にやるタスクがリファクタリングということで、進め方など村本さんにかなりサポートはしてもらったものの、ここでだいぶ苦戦しました。
リファクタリングは外から見た動作を変えずに内部のソースコードを整理することなので、リファクタリングの影響範囲のコードがどう動いていて、どこに依存関係があるかを理解しないと前に進めません。製品の既存コードを理解するところが特に大変でした。
最初はかなり時間がかかりましたが、タスクを進めるうちに次第に理解するスピードが速くなり、なんとか進めていけました。結局、量を読むことが鍵でした（笑）。加えて、既存のコードベースが開発・保守しやすいようにきれいな階層で分けられていたため、それぞれの役割を理解し、処理の流れをイメージできるようになったことも大きかったです。
コードベースの設計思想については村本さんと1on1の時間で一度しっかりコミュニケーションをとって、自分の認識のズレや既存の設計でモヤモヤしていた点を解消できたのが大きかったです。
この経験から、コードを読むだけでなく、人と話すことの重要性を学びました。
また、この時期からリリース前のシナリオテストも担当するようになりました。
シナリオテストはKnow Narratorの毎月のアップデート前に、意図する動作になっているかをチェックするために実際に触って確認するテストのことです。
シナリオテスト自体は特別面白い作業ではないですが、10月にKnow Narratorを触りまくったときと同じように、製品に対する理解が進みました。また、これまでのタスクではOJTリーダーの村本さんとのコミュニケーションが中心でしたが、テストを進める中で、テストを作成したメンバーや機能を開発したメンバーとやり取りする機会が増えました。パートナー会社の方や開発チームの他メンバーとも関わることができ、連携の幅を広げる良い機会になりました。
2月〜3月：自分が実装した機能のリリースを経験する
2-3月に取り組んだことは以下のとおりです。（OJTリーダー側の振り返り記事から引用）
【主に取り組んだこと】
継続してKnow Narrator開発の様々なタスクを担う
Know Narratorとして大きなアップデート要素となりえる主要機能を作り切る
【狙い、身に着けてほしいスキル】
自分が実装した機能が製品に乗る喜びを味わっていただく大きな機能開発を通して、設計や実装、テストはもちろん、自身のタスク整理やコミュニケーションのリードを経験してもらうプロダクトオーナーやビジネスオーナーに対して、機能の開発状況や仕様について説明する経験をしていただく
2月・3月で新しく開発タスクとして行ったことは大きく分けて2つです。
- Know Narratorで採用予定だった新技術のキャッチアップと動作確認
- 3月末のアップデートの機能の一つを仕様整理から開発・テストまでを一貫して行い、KNのアップデートに自分が作った機能を載せる
まず一つ目の技術調査についてです。
11月でもすでに技術調査を行いましたが、2月の技術調査では、単に調査して手元で動かすだけでなく、Know Narratorのプロジェクト上でテストコードを実装し、Know Narratorの環境でも実際に動作することを確認するまでをゴールとした検証を行いました。
手元で簡単に動かすのとは違って、既存のプロダクトコードを見ながら、使えるところは共通化して実装するところに、より難しさを感じました。また同時にIDEのデバッグモードを活用したデバッグについても学ぶことができました。
二つ目の機能開発についてです。
ここで感じたことは、二つあります。
一つ目は、機能の仕様を考えることは前提を考えるのとセットであることです。
最初に仕様を決める際に、仕様について開発チームの先輩に相談したところ、この機能が使われるときの前提条件があるはずだから、それを元に判断すれば良いというコメントをもらいました。
二つ目は、タスクを整理することの難しさです。
今までは割り当てられたタスクをこなす側であることがメインだった一方で、このタイミングでは、タスクを整理して作る側に回ることを経験しました。この点は村本さんにかなりサポートをしてもらって、タスクの切り分けの単位や、画面デザイン作成の依頼、一部実装のパートナー会社の方への依頼なども一緒に進めてもらえました。
一人では開発が進まず、先回りしてコミュニケーションを取りながら開発を進めることが重要だと感じました。
タスクの進め方には課題が多くありましたが、自分の開発した機能をOJT期間にリリースするところまで持っていけたので、自信にもつながりました。
チームとのコミュニケーション
ここでは、OJT期間中に感じたチームとのコミュニケーションについて振り返ってみます。
開発部屋
私が所属するAITCの開発チームは、リモートワークがメインで、基本的に一日中開発部屋と呼ばれるTeamsのオンライン会議に入って開発を進めています。配属直後は、メンバー全員がいる場で声を出して質問することに少しためらいがありました。
ただ、慣れてくると、開発部屋にいることでどのメンバーが会話できるかがすぐにわかったり、会話を聞いていた他の先輩がプラスアルファでコメントをくれたりして、とても仕事のしやすい環境だと感じるようになりました。
開発部屋については別記事でも紹介されているので、気になる方は見てみてください。
tech.dentsusoken.com
1on1
10月の配属直後には、開発チームのメンバーと基本的に対面で1on1をする機会をいただきました。オンライン中心だとコミュニケーションが少しドライに感じることもありましたが、対面で話すことで人となりがわかり、とてもよかったです。
また、OJTリーダーの村本さんとは隔週で1on1をしていて、日々の雑談から仕事の進め方で迷っているところの相談までしていただき、とても助かりました。
新人用Teamsチャネル
10月から12月は、新人が基本的にTeamsの一つのチャネルを見るだけで必要な情報を得られるように、新人用チャネルを用意してもらっていました。
ここには、業務でよく参照するサイトのリンクや事務的な連絡、TODOリスト、気になることを質問できるスレッドなどが一つのチャネルにまとまっていて、とりあえずこのチャネルを見れば大丈夫という状態になっていました。
よく「〇〇サイトの\~~というページを開いてください」的なことを指示されると、どこを見ればよいか迷うこともありますが、このチャネルのおかげで「どうやって行くんだっけ」と探す手間はほぼなかったです。
同チャネルで日報の作成も行っていました。日報はYWTP形式（やったこと・わかったこと・次やること・問題）で書いていましたが、自分のW（わかったこと）やP（問題）に対して、OJTリーダー以外の方もフィードバックとアドバイスをいただけて、非常に助かりました。
日報はOJT期間が終わった後も、開発チーム内で同じ形式で実施していて、日々メンバーが考えていることや発見がわかったり、アドバイスをいただけたりして大変ありがたいです。
OJTリーダーとのやり取り
村本さんは実は関西支社の方で、東京にいる私とはオンラインでのコミュニケーションがメインでした。最初は少し驚きましたが、オンラインでも日々のチャットや1on1等でしっかりコミュニケーションを取っていただいたので、不満は全くありませんでした。やり方次第でどうにでもなるんだなと感じました。
10月から12月までは毎日村本さんと朝会をしていて、日報をもとに進捗確認やフィードバック、つまずいているところの相談等をしていました。
タスクを進める中で出る質問は開発部屋で行う形にしていました。ただ、村本さんが忙しくて開発部屋にいらっしゃらないことが多い時期は、進め方に少し苦労しました。他のメンバーの方は私のタスクを詳細に把握していないケースがあったため、手が止まってしまう時間もありました。
今振り返ると、自分がもっと他の先輩にも頼るようにコミュニケーションを取ればよかったと感じます。そのうえで、特定の一人に頼りきりにならない体制や、気軽に相談できる相手を増やしておくことも、受け入れをやりやすくするうえで大事だと思いました。
半年を振り返ってみて
OJT期間半年を通して、開発チームのお荷物と勝手に感じてしまうような状態からは脱却できたかなと思っています。半年間で自分でも成長できたという実感があります。
OJT期間で私が恵まれていたと感じることは、とにかくゆっくり自分が納得するまでやっていいというスタンスで見守ってもらえたことです。特に今は生成AIが発達しているので、理解せずとも形にできてしまう部分はあるのですが、自分の成長を優先してもらえたことで、技術力の向上につながり、精神的にもいい意味で楽な状態で半年間過ごすことができました。
OJTリーダー側の視点を受けて
ここで、OJTリーダー側からはどう見えていたのかも振り返ります。
『「新人さん」ではなく「新しいメンバー」をチームで受け入れる』ことが、私のOJT期間のテーマになっていたようです。
特に配属後の2〜3か月は、このスタンスを強く感じていました。オンボーディング中は、暗黙知を知らない立場だからこそ気づける点を踏まえて、チーム内ドキュメントの整備をしっかり任せてもらったり、やりづらいところを丁寧に聞いていただいたりしました。
そうしたやり取りを通じて、新人・ベテランに関わらず、これから新しく開発チームに加わる人に向けたオンボーディングの改善につなげようという意識を感じました。自分自身も、オンボーディングの改善に貢献するという意味で責任感を持って取り組むことができたので、オンボーディング中に感じるやりづらさも前向きに捉えられたような気がします。
こういった環境や自分の成長につながるタスクを用意してくださった村本さんはじめAITCの先輩方に感謝し、今後新しく入ってくるメンバーに対しては、自分が直近でオンボーディングを経験したメンバーとして力になりたいと考えています。
執筆：@sugie.naoki
レビュー：@miyazawa.hibiki
（Shodoで執筆されました）
