Gemini Canvasから出力・ダウンロードできるファイル形式一覧 Gemini Canvasの強みは、資料やWebページ用のビジュアルを出力し、多様なファイル形式へ変換できる点にあります。

株式会社スタンバイでフロントエンドエンジニアをしている藤澤です。 スタンバイでは27卒から新卒採用を実施しており、その一環として、来年度4月入社予定の内定者（学生）の方を対象に、任意で「内定者バイト」（本記事では以下「内定者エンジニア」と呼びます）を実施しています。 入社前に実際の現場業務を体験してもらうことで、入社後のスタートダッシュを円滑にすることが狙いです。 このたび、その内定者エンジニアの方をトレーナーとして約5カ月間受け入れるという経験をしました。 最初は「自分が誰かの成長に伴走するなんて、うまくできるだろうか」と正直ドキドキしていたのですが、振り返ってみると、受け入れる側の自分にとっても学びだらけの5カ月でした。 この記事のポイント 受け入れ前に「放置」「レベル」「質問」の3つの不安を先回りして解消する仕掛けを用意した 月を追うごとに任せる範囲を段階的に広げ、5ヶ月目には仕様策定から主導してもらうまでになった コーディング以外にも、スクラム活動や他職能との交流など幅広い経験を用意した トレーナーとして学んだのは「伴走」と「任せる」のバランス、少しずつ手を離していく設計の大切さ 1. はじめに：ドキドキで始まったトレーナー業務は、学びだらけの5カ月になった はじめにお伝えしておくと、スタンバイでは今年度だけで5名以上の内定者エンジニアを受け入れており、さらにトレーナー同士が毎月集まって受け入れ状況を共有する報告会も行っています。 つまり「個人がたまたま頑張る」のではなく、組織として内定者を迎える仕組みがあります。 この記事はそのうちの、私が担当した一事例です。 これから内定者エンジニアとして参加する方や検討している方に、「受け入れる側はここまで考えているんだ」という安心感が伝わり、入社前の不安が少しでも軽くなれば嬉しいです。 まず、この記事に登場する人たちの立ち位置を整理しておきます。 ▲ 内定者エンジニアに関わる人たちの相関図 稼働は基本的に週2日で、最初の1〜2ヶ月目は1日4時間、3ヶ月目以降は1日8時間に増えました。 曜日や時間帯は固定ではなく、内定者本人の大学の授業や他のアルバイトの予定に合わせて調整しています。 2. 受け入れる前にやったこと：「放置」「レベル」「質問」の不安を先回りして解消する3つの仕掛け 参加する側にとって、最初の不安は主に以下の3つに集約されるのではないかと思っています。 放置されないだろうか 分からないことを気軽に聞けるだろうか 自分のレベルで通用するだろうか そこで、受け入れ前〜序盤にかけて、この3つの不安を先回りして取り除く仕掛けを用意しました。 不安 用意した仕掛け ねらい 放置されないだろうか ①役割分担を明確にした受け入れ体制 誰か一人が忙しくても必ずフォローが入る状態にする 分からないことを気軽に聞けるだろうか ②進捗を毎日拾うミーティング設計 課題を次の出社日まで溜め込ませない 自分のレベルで通用するだろうか ③段階設計したオンボーディングタスク スモールスタートで実務フローに慣れてもらう ① 役割分担を明確にした受け入れ体制（＝放置しない） 私（トレーナー）一人だけで抱えるのではなく、3つの役割で受け入れ体制を組みました。 役割 主な担当 トレーナー タスクのアサイン、ペアプロ・コードレビューなど日々の伴走 PO（プロダクトオーナー） ビジネス観点のインプット レビュアー（TL） 目標設定や成果のレビュー、トレーナーの指導方法・環境についての評価と相談 レビュアーは、私が所属するチームのTL（テックリード）が担当してくれました。 トレーナーとしての自分の指導方法や、内定者にどんな環境を用意すべきかについて、相談に乗ってもらいました。 これに加えて、人事から現場とは異なる部署のメンターが1名つき、月1回、業務とは別の目線で近況や悩みごとを相談できる機会も用意されています。 ② 進捗を毎日拾うミーティング設計（＝つまずきを溜めない） 1日4時間という限られた稼働時間なので、出社日の朝と夕に15〜30分の進捗共有を設定しました。 さらに週次でのチーム定例、隔週でのPOとの1on1も用意しました。 「分からないことを次の出社日まで溜め込ませない」ためのコミュニケーションの仕組みです。 ▲ 朝会・夕会での振り返りボードのイメージ（実際の内容を再構成したものです） ③ 段階設計したオンボーディングタスク（＝スモールスタート） いきなり難しいタスクは渡さず、修正範囲が1〜2ファイルの軽微なスタイル修正やJavaScriptの記述修正から始めてもらいました。 狙いは実装スキルそのものより、「PR（プルリクエスト）作成 → レビュー → マージ」という一連の実務フローに慣れてもらうことです。 この軽量タスクを5件ほどこなしてもらううちに、Jiraでのチケット管理、影響範囲の動作確認、Preview環境の立ち上げ、CIやユニットテストの扱い、コードレビューでのやり取りまで、ひととおりのプロセスが自然と身についていきました。 また、受け入れ初週には関係メンバーで歓迎の懇親会も開催しました。 技術的なインプット以上に、まずは「歓迎されている」と感じてもらう心理的安全性を大切にしました。 内定者さんのコメント①｜受け入れ序盤の振り返り 配属した当初は不安でしたが、疑問点をすぐに相談できる環境だったので、安心して取り組むことができました。 3. 5カ月の成長の軌跡：できることが毎月一段ずつ広がったステップ設計 ここからは、月を追うごとに任せられる範囲がどう広がっていったかを紹介します。 受け入れ側として見ていて、毎月「一段上がったな」と感じる頼もしい瞬間がありました。 期間 主なタスク できるようになったこと 1〜2ヶ月目 環境構築、軽微なスタイル修正・JavaScript修正 デザイントークンの利用、影響範囲の特定、DevToolsでの確認 3〜4ヶ月目 ABテストの「お掃除」「100%反映」 本番リリース、スマホ実機での確認、難易度の高いバグ対応 5ヶ月目 仕様が未確定のバグ対応タスク トレーナー・POとの仕様すり合わせ、Jiraチケット作成、周囲を巻き込む提案 【1〜2ヶ月目】開発フローの習得と、実務ならではの「お作法」 環境構築やgit-flowは大きくつまずくことなくクリア。 CSSやJavaScriptの基礎知識を持っていたため、軽微な修正は問題なく実装できていました。 一方で、実務ならではの観点は、この時期、じっくり身につけてもらいました。 CSSに固定値を直書きせず、デザインシステムのデザイントークンを使う ファイルを直す前に使用箇所（import先）を調べて影響範囲を特定する DevToolsでスタイルの適用やログ送信を確認する 特に印象的だったのは、報連相の丁寧さです。 1日4時間という短い稼働の中で、退勤前には作業途中のコードであっても自主的にコミットして「進捗の見える状態」にしてくれていました。 課題を翌営業日に持ち越さない工夫は、受け入れるトレーナーとしても非常に助かりました。 【3〜4ヶ月目】本番リリースと「ABテスト」への挑戦 3ヶ月目からは、フロントエンドのメイン業務の1つであるABテストにチャレンジしてもらいました。 まずは過去のテストの「お掃除（後片付け）」タスクで全体の流れを掴み、慣れてきたところで、ABテストの「100%反映」も1件担当してもらいました。 この時期には計7件のリリースを経験しました。 オフィス出社日には、スマホ実機での動作確認作業や、難易度の高いバグ対応もこなせるようになっていました。 【ミニコラム】ABテストの「100%反映」の面白さと難しさ ABテストは、新しいパターン（B）が既存（A）より良い結果かを一部のユーザーで検証する仕組みです。 用語 意味 お掃除（後片付け） 終了したABテストの分岐コードを片付ける作業 100%反映 検証で採用が決まったパターンを全ユーザーへ正式展開する作業 本番の全ユーザーに直接影響し、かつリリース期限のプレッシャーもあるため、一段と責任の重い仕事です。 ここを任せられるようになったことは、実務の主戦力に近づいた大きな節目でした。 内定者さんのコメント②｜ABテスト挑戦時の振り返り リリースのときは緊張しましたが、その分「自分がやったことへの責任感」と「実装したコードが実際に動くやりがい」を強く感じました。 【5ヶ月目】仕様が未確定のタスクへ。上流から主導する「自走」への変化 直近の5ヶ月目には、仕様がまだ固まりきっていないバグ対応タスクに挑戦してもらいました。 これまでは「決まった仕様を実装する」のが中心でしたが、今回は以下のように上流から主導してもらいました。 トレーナーやPOと自ら仕様を擦り合わせる 自分でJiraチケットを作成する 実装する 受け入れ当初に課題だと感じていた「トレーナー以外への能動的なコミュニケーション」が見違えるように改善し、周囲を巻き込む動きが出てきたのが大きな変化です。 この頃には1on1の回数を減らし、チームの日常的なやり取りの中で自然に報連相が回るようになっていました。 内定者さんのコメント③｜能動性が出てきた頃の振り返り 当事者意識を持って取り組むことと報連相の大切さを学びました。 今後は、その施策が何のためにあるのかを見据えて、自分から改善案を提案しながら業務に取り組んでいきたいです。 4. 内定者エンジニアが体験したこと：コーディングタスク以外の学びの機会 ここまではトレーナーとして任せたタスクの話が中心でしたが、内定者エンジニアの方が体験したのはコーディングだけではありません。 体験 内容 チームのスクラム活動への参加 朝会やスプリントレビュー、レトロスペクティブなど、チームの各セレモニーに参加してもらいました 部署のイベントへの参加 月1の部会で、事業状況や会社全体の動きをインプットする機会を用意しました 他の職能との交流 エンジニア以外の職能のメンバーとも接点を持ち、視野を広げてもらいました 目標設定とフィードバック 受け入れ開始時に本人と目標をすり合わせ、月次で振り返り・フィードバックを行いました コードを書く力だけでなく、チームの一員としての動き方や会社全体への理解も、この5カ月間で少しずつ身についていきました。 5. トレーナーとして学んだこと：「面倒を見る」から「徐々に手を離す」へのフェードアウト設計 受け入れ側の私自身にとっても、大きな学びがありました。 一番考えさせられたのは「伴走」と「任せる」のバランスです。 ▲ トレーナーの伴走スタイルは、時間の経過とともに複数の観点で変化していきました 観点 最初（1〜2ヶ月目） 中期（3〜4ヶ月目） 終盤（5ヶ月目） 体制 ①の体制のもと、2時間おきに簡単な会話で進捗を確認 チームの活動に合流し、チーム全体の動き方に慣れていく チームの活動に混ざり、自分から進捗報告・作業連携をする タスクの位置づけ 内定者エンジニア用に用意したタスク 通常のエンジニアも担当する業務の中の、軽微な改善タスク 自ら提案した機能修正案が中心。仕様策定から関わる レビュー体制 トレーナーが担当 トレーナー以外のエンジニアメンバーも担当 チーム全体で担当 コミュニケーション トレーナーとのやり取りが中心 チーム内のSlackなどでオープンに相談できる 自分から報告・連携を働きかける 朝夕のMTG 30分。タスクの説明や困りごとの確認 30分。技術的な学びを深掘る時間に 15分に短縮。学びの定着の場として継続 最初は、トレーナーが近くで手厚くフォローすることが本人の安心につながります。 一方で、距離が近すぎると「自分で情報を取りにいく力（自走力）」が育ちにくいという側面もあります。 だからこそ中期以降は、あえて仕様の擦り合わせから任せたり、1on1を減らしてチームの中に溶け込んでもらったりと、少しずつ手を離していく設計を意識しました。 受け入れるということは、単に「面倒を見る」ことではなく、「自分で立てるように環境を整え、徐々に引いていく」ことなのだと身をもって学びました。 6. 最後に：不安は仕組みでカバーできます。安心して飛び込んできてください！ 最初は不安で当たり前です。 しかしスタンバイには、あなたのつまずきを毎日拾うコミュニケーションの仕組みがあります。 さらに、軽いタスクから本番のABテスト、上流の仕様策定まで、一段ずつステップアップして任せていく設計もあります。 ぜひ、安心して飛び込んできてください！ スタンバイのプロダクトや組織について詳しく知りたい方は、お気軽にご相談ください。 www.wantedly.com 新卒採用についてはこちらをご覧ください。 newgrads.stanby.co.jp

はじめまして。2026年度新卒として入社し、この夏からITディベロップメント1部 開発チーム 開発2課に配属されますF.Tです。 4月に入社してから約4か月間、みっちりと研修を受けてきました。振り返ると本当にあっという間で、それでいて濃密な期間でした。 そこでこの記事では、受講した新卒の一人として、この4か月で何を経験し、何を得たのかを率直にお伝えします。 研修の雰囲気が少しでも伝われば幸いです。 研修全体の流れ 研修は大きく次のステップで進んでいきました。 時期 研修内容 ～4月中旬 人事研修・デジ戦研修 ～5月末 IT/Web研修 ～6月上旬 デジ戦研修 ～6月中旬 職種別研修 6月中旬～7月末 開発演習（4スプリント＋成果発表会） ※デジ戦 : デジタルテクノロジー戦略本部 人事研修・デジ戦研修 最初に受けたのは、職種を問わず新卒共通の人事研修・デジ戦研修です。 人事研修 人事研修では、ビジネスマナーやビジネスマインド、文書作成の基本など、社会人として当然身につけておくべきことを学びました。グループワークが多く、入社したてで緊張していましたが、同期と話すうちに自然と打ち解けていったのを覚えています。 なかでも、相談などの時間を取ってもらいたいときに使用する「お時間よろしいでしょうか」というクッション言葉は今となっては自然と口から出るほど身に付きました。 デジ戦研修 続くデジ戦研修では、講義やパネルディスカッション、座談会などを通してデジ戦の組織構造や各職種について説明を受け、組織と業務への理解を深めました。 また、相手に伝わるスライドを作成するためのデザイン研修や、顧客のニーズを捉えて価値を届けるマーケティングの研修を通じて、実践的な知識や考え方も学びました。 さらに、日々売上を生み出している営業社員が、商談において何を考え、どのようにお客さまと向き合っているのかを学ぶ機会もありました。実際の商談動画を視聴したほか、営業社員との座談会も開催していただき、営業という仕事への理解も深めることができました。 デジ戦研修の中で特に印象に残っているのがパネルディスカッションと2年目社員との座談会です。これらの研修を通して「配属後に自分がどんな仕事をするのか」の解像度がぐっと上がりました。 また、業務内容だけでなく私たち新卒へのメッセージもたくさんいただきました。 なかでも、「どんな仕事も伝わらないと意味がない」というメッセージはエンジニア職の私には強く印象に残りました。 どんなにたくさんコードを書こうと、すごい機能を実装しようと使う人にとっての使い方、メリットが伝わらないと意味がありません。 生成AIが普及しアウトプットが簡単に得られる時代に、伝えるという仕事はより一層大切になっていると感じました。 IT/Web研修 ここからはエンジニアとしての土台づくりです。と言いつつも、デジ戦ではエンジニア職であるかに関わらず全員がこの研修を受講します。全社横断のIT部門という特徴が表れた研修だという風に感じています。 研修では、セキュリティ、データベース、ネットワークといった基礎知識から、Python、SQL、HTML/CSS、JavaScript、そしてバックエンド開発（Python / Django）まで、幅広く学びました。 この研修の特徴は、まったくの初心者がいるということだと思います。経験者は初心者の方に教える中で自分の理解度を再認識し復習するという光景が周囲でたくさん見られました。一方初心者の方は、はじめて触れる概念に苦戦しつつもわからないことは周囲に質問し、すさまじいスピードで知識を身に付けていく姿が印象的でした。 職種別研修 職種別研修では、エンジニア・デザイナー・データサイエンティスト・マーケター・ガバナンスの5職種に分かれ、5日間の研修を受けました。 私が受けたエンジニア職研修では、ウォーターフォール開発を要件定義から総合テストまで一通り体験しました。クラスやオブジェクトの概念、UMLの作成には苦戦する場面もありましたが、チームで協力し一連の成果物を作り上げることができたときは達成感がありました。 短期間で上流から下流まで駆け抜けるのは大変でしたが、開発全体の流れを肌で理解できた貴重な機会でした。 開発演習 そして、研修の最後は約1か月にわたる開発演習を行いました。開発演習では、マイナビ転職・マイナビクリニックナビの2つのサービスで各2チームの計4チームに分かれ開発を行いました。 どのチームにも均等に各職種のメンバーが割り振られ各職種の強みを発揮し、協力しながらチーム開発を進めました。 また、今年度はデジ戦先輩社員のフィードバックに加え、各サービスを運営する事業部の方々からも定期的にフィードバックをいただく機会を用意していただきました。 各チーム、フィードバックの機会を有効に活用し、最終成果発表時には初期のものと比べ物にならないサービスを開発していました。 なお、開発演習の具体的な取り組み内容については、 こちらの記事 で詳しくご紹介しています。 振り返り 約4か月の研修を通して私が得たものは、大きく3つあります。 1つ目は私は伝えたではなく、伝わったと相手に言ってもらうことの大切さ、2つ目はエンジニアとしての基礎知識、そして最後がチームで開発をやり抜いた経験です。 特に開発演習では、技術力だけでなく、チームで議論し、フィードバックを受け止め、次に活かすという一連の流れを実体験をもとに覚えることができました。同期との仲もぐっと深まり、配属後も相談し合える心強い仲間ができたことは、何より大きな財産です。 ここでお伝えしたのはあくまで私自身の視点ですが、新卒一人ひとりがそれぞれ異なる学びを得ています。配属後は研修で得た学びを生かし、一日でも早く一人前になれるよう精進します。 最後に、新卒研修に関わってくださった皆さま、研修担当の方々、そして事業部・先輩社員の皆さまに、心より御礼申し上げます。研修で得たすべてを糧に、配属後も挑戦を続けていきます。