概要
若手エンジニアの育成とは、実務経験の浅いエンジニアがサポートなしでできることの水準を引き上げる取り組みです。若手エンジニアは、自分のコードの良し悪しを判断するための基礎と経験の量をまだ積み上げていないため、何をどの順で学ぶかをチームが設計する必要があります。 若手エンジニアは、新しく加わったメンバーとは限りません。若手の育成は、オンボーディングとは別の課題です。新しいメンバーがチームになじむまでの支え方はオンボーディングで扱います。 このページでは、学ぶ側ではなく教える側、つまりチームの視点から育成を扱います。目標設定・フィードバック・段階的な学習による育成の進め方、チームで学ぶ仕組み、AIエージェントが日常の開発に入ったときにメンターが担い続けることを順に説明します。育成の進め方
目標を一緒に決める
始める前に目標を合意します。マネージャーとメンバーで、メンバーが目指す水準、その水準に組織が期待すること、到達までの期間の3点を共有します。 目標の水準は、観察できる言葉で書きます。「仕様が決まった機能を、テストを含めてサポートなしで実装できる」は確認できますが、「フロントエンドをよく理解している」は確認できません。職種と水準ごとに求める知識を一覧にしたスキルマップがあると、チーム内でこの書き方を揃えられます。現状を事実で伝える
現在の水準と目標の水準の差を、実際の変更やレビューに基づいて具体的に伝えます。曖昧な評価では、メンバーは何を変えればよいのか判断できません。 あわせて2つのことを伝えます。差があること自体は問題ではないこと、そして差を埋めるのは一緒に取り組む課題であることです。率直なフィードバックを上手に伝えるのは1つの技能であり、伝える側にも練習が必要です。1on1でフィードバックする
1on1とは、メンバーとメンターやマネージャーが1対1で定期的に話す場です。進捗報告ではなく、メンバーのための時間として使います。直近の仕事のふりかえり、詰まっていること、キャリアなどの話題をメンバーが持ち込み、聞き手はそれを引き出すことに重きを置きます。 若手エンジニアとの1on1は、最初は頻繁に行い、成長に合わせて頻度を落とします。初期は小さな疑問や詰まりをその日のうちに解消できる頻度にし、1人で進められる範囲が広がったら間隔を空けます。 1on1はタスクの計画ではなく、ふりかえりとフィードバックに使います。タスクの相談や調整は、関係する人を集めた別の場で行います。 1on1では、直近のプルリクエストを一緒に見て反省会をします。うまくいった点、改善できる点、レビューの指摘の背景を掘り下げます。 フィードバックや指示は具体的にします。「このタスクは、ここをこう変えて、次にここを変える」と伝えればメンバーは行動に移せますが、励ましや心構えだけでは動けません。進め方を実際に見せる方法としては、ペアプログラミングも効果的です。段階を踏んで学ぶ
いろいろなことを一度に叩き込むのではなく、身につけることを次の3つの観点に分け、観点ごとに確実に覚えてもらいます。
質より先に手数を求めるのは、プルリクエストの1つひとつがフィードバックの機会になるからです。1週間かけて大きな変更を実装して一度に何件も指摘を受けるより、1日ごとに小さな変更をして少しずつ指摘をもらうほうが早く身につきます。
AIエージェントがコードを書く時代だからこそ、基礎はより重要になります。基礎の土台がないと、AIが出したコードや説明が正しいかを判定するのが難しく、誤りに気づかないまま取り込んでしまいます。
防げるミスと、つまずくべき難所を分ける
タイプミス、Lintエラー、消し忘れたデバッグ用のコードなど、セルフレビューで防げるミスは技術力や経験に左右されません。そのため早い段階でなくなることを期待します。一方、テスト、型の設計、非同期処理のように難しく重要なテーマは、つまずいて当然の領域です。 見るべきは、メンバーがつまずくべきところでつまずいているかです。難しいテーマでのつまずきが増えるのは、成長しているサインです。対処が必要なのは、同じミスを繰り返している場合です。速さより正しい方法を優先する
正しい手順を毎回守るよう求めます。既存のコードを変更する前に、そのコードがテストで守られているかを確認し、なければ先にテストを追加します。調べものをするときは、公式ドキュメントなどの一次情報を読みます。 初期は速さを目標にしません。正しい手順を何度も繰り返せば速くなりますが、速くても誤った手順は後から直さなければなりません。 結果ではなく進捗を求めます。毎日小さなプルリクエストを出し、数週間かけて大きなタスクを終えるメンバーは順調です。何日も考え込んで何も出さないメンバーは順調ではありません。フィードバックが届かないためです。集中できる時間を守る
育成の初期は、メンバーの注意を割り当てたタスクに向けます。問い合わせ対応、障害調査、チームをまたぐ調整は、メンバーがサポートなしで変更を届けられるようになるまで、経験のあるメンバーが担います。やることがないときは一緒に探します。コードを並んで読めば、小さなリファクタリングや足りないテストがほぼ必ず見つかります。 外に向けたアウトプットより、コードを読み書きするインプットを優先します。記事の執筆やイベントでの登壇にも価値はありますが、育成の土台となるインプットの時間を削ってまで取り組むものではありません。チームで学ぶ
短い勉強会
勉強会とは、メンバーが学んだことを互いに発表する定期的な時間です。1回を短くしておくと、通常の業務と並行して続けられます。チーム内で、5分の発表と5分の質疑で構成する形式がよく使われます。 続けるために、発表の負担を下げます。- スライドを必須にしない。画面共有や文章のメモで十分とする。
- 開催前に伝えれば、発表をスキップできるようにする。
- 「開発でのAI活用」のようなテーマを決めつつ、テーマ外の発表も認める。
ファインディでは、生成AIのキャッチアップを目的に、チーム内で短い勉強会を開き、メンバー全員が順番に発表しているチームもあります。
育成の資料を誰でも更新できるようにする
オンボーディングの資料、スキルマップ、開発のガイドラインは、Gitリポジトリのように全メンバーが変更を提案できる場所で管理します。作成者しか更新できない資料は、チームの実際のやり方から遅れていきます。AI時代のメンターの役割
人が担い続けること
書かれていないことはAIにも補えません。アーキテクチャの経緯やドメイン知識は、オンボーディングで説明したように文書にして、人とAIの両方が参照できるようにします。それでも、トレードオフの判断や開発の進め方に関するチームの価値観は、主に人と一緒に働く中で身につきます。仕様が曖昧なとき、AIエージェントは疑問を投げかけずに仮定を置いて進めることがあり、そのずれは後から手戻りとして表面化します。 メンターの役割は、コードの書き方を教えることから、プロダクトとユーザーを理解する機会をつくることへ移ります。図を使ったドメインの説明、仕様の読み合わせ、設計の議論やユーザーとの打ち合わせへの同席がその例です。AIの出力を判断する力を育てる
AIを使うこと自体は問題ではありません。育成で身につけるべきなのは、AIの出力が正しいかを見抜く力です。コードとテストを自力で書き切れず、誤った答えに気づけないメンバーは、AIエージェントが出したものを検証できません。 見抜く力の土台になるのが基礎力です。データ構造とアルゴリズム、ネットワークとHTTP、データベース、セキュリティ、OSといった基礎があれば、AIの出力のどこが誤りうるかに当たりをつけ、公式ドキュメントなどの一次情報で確かめられます。基礎がないまま出力を受け入れると、もっともらしい誤りをそのまま本番に持ち込みます。ファインディでは、基礎力を身につける手段として、基本情報技術者試験などの資格の取得を奨励しています。
- 最初はAIを自由に使ってもらい、出てきたプルリクエストの質を一緒に確認する。
- 質に課題が見えたら、まだ自力で解けない問題にはAIを使わずに取り組んでもらい、その理由を説明する。
- 調べものや、すでにほかの箇所で正しく実施できている変更から、制限を段階的に外していく。
関連ページ
オンボーディング
若手か経験者かを問わず、新しいメンバーが組織の中で自律して動けるようになるまでを支える方法を扱います。
コードレビュー
毎日のフィードバックを支える、セルフレビューとレビューコメントの書き方です。
DevRelの役割
チームの勉強会が実践している、学習と共有の文化を扱います。