開発チームの新メンバーの立ち上がりにAIを使う｜コードの理解と受け入れ準備

開発チームに新しいメンバーが加わると、最初のうちはコードベースの全体像をつかむことに多くの時間を使います。どこに何が書かれているのか、なぜこの構成になっているのか。こうしたことを知るには、既存のメンバーに聞くのが一般的でした。

AIコーディングツールを使うと、新メンバーが自分でコードの説明を求めたり、処理の流れを調べたりできます。既存メンバーへの質問が減れば、教える側の負担も軽くなるかもしれません。一方で、AIの説明が正しいとは限らないため、使い方を決めておく必要があります。

この記事では、新メンバーの立ち上がりにAIを使うときの進め方と、受け入れる側が準備しておきたいことを説明します。

AIに任せやすいのは説明と探索

新メンバーがAIを使いやすいのは、コードの説明と探索です。たとえば「このディレクトリの役割を説明して」「この関数がどこから呼ばれているか教えて」といった質問が考えられます。

知らない用語やライブラリを調べるのにも使えます。社内でしか使われていない略語は分からないこともあるでしょう。それでも一般的なフレームワークの書き方であれば、説明を受けながら読み進められます。

質問の仕方も、最初に伝えておきたいことの一つです。対象のファイルや関数を指定し、知りたいことを一つずつ聞くと、答えを確かめやすくなります。「このプロジェクトについて全部教えて」のような広い質問は、要点のぼやけた説明になりやすいでしょう。

ただし、AIの説明はあくまで手がかりです。古いコメントや使われなくなったコードを根拠に、事実と違う説明をすることがあります。説明を受けたら、実際のコードやテストで確かめる習慣をつけてもらいましょう。

どのツールでどこまでのことができるかは、製品や設定によって異なります。機能や料金は変わるため、導入時は公式情報を確認してください。

受け入れる側が準備しておくこと

AIを使った立ち上がりを進めるには、受け入れる側の準備が欠かせません。AIはリポジトリにある情報をもとに説明するため、情報が少なければ説明も不正確になりがちです。

まず、プロジェクトの目的とディレクトリの構成、開発環境の起動方法やテストの実行方法を文書にしておきます。これは新メンバーが読むためにも、AIが参照するためにも役立つはずです。リポジトリにAI向けの指示書を置く方法は、リポジトリにAI向けの指示書を置くときの書き方で説明しています。

設計の背景も、できる範囲で残しておきましょう。コードからは「何をしているか」は読み取れても、「なぜこうしたか」は分からないことが多いものです。過去の判断の理由が文書に残っていれば、新メンバーもAIも、変えてよい部分と変えてはいけない部分を区別しやすくなります。

AIツールを使うときのルールも、最初に伝えます。秘密情報の扱いや使ってよいアカウント、任せてよい作業の範囲などは、新メンバーが自分で判断するのは難しいからです。ルールを文書にまとめ、開発環境を整える段階で一緒に読んでもらうと伝え漏れを防げます。

受け入れの担当者を一人決めておくのも有効です。AIで調べても分からないことを誰に聞けばよいかがはっきりしていれば、新メンバーは質問をためこまずに済みます。担当者も、新メンバーのメモやAIへの質問の内容から、つまずいている部分を早めに把握しやすくなるはずです。

最初の数週間の進め方の例

立ち上がりの進め方は、チームによって違います。ここでは一例として、AIを使う場合の流れを紹介しましょう。

最初の数日は、開発環境を整え、リポジトリの全体像をつかむことに使います。新メンバーはAIにディレクトリの役割や主要な処理の流れを説明してもらい、分かったことを自分の言葉でメモにまとめます。そのメモを既存メンバーが読み、間違いや補足を伝えてください。

次に、小さな課題に取り組んでもらいます。表示文言の修正や、小さな不具合の修正など、影響範囲が限られる作業が向いています。AIで変更の下書きを作ってもよいことにし、変更の理由を本人が説明できるかをレビューで確かめましょう。

レビューは、コードの良し悪しを伝えるだけの場ではありません。チームの判断の基準を伝える機会にもなります。「この書き方を避けているのは、過去にこういう問題があったから」といった話は、AIからは得にくい情報です。

慣れてきたら、少しずつ課題の範囲を広げます。複数のファイルにまたがる変更や、既存の機能の改修などです。範囲を広げるときも、AIの出力をどう確かめたかを説明してもらう流れは続けます。

AIに頼りすぎないための注意点

AIを使うと、コードを深く理解しないまま変更が作れてしまうことがあります。立ち上がりの時期にこれが続くと、時間がたってもコードベースを自分で説明できない状態になりかねません。

AIに説明してもらった内容を、自分の言葉で書き直してもらうのは一つの方法です。書き直そうとすると、分かっていない部分がはっきりします。分からない部分は、既存メンバーに質問するきっかけになるでしょう。

既存メンバーとの会話も減らしすぎないようにしましょう。AIで調べられることが増えても、チームの事情や過去の経緯は人に聞かないと分からない場合が少なくありません。定期的に話す時間を設け、AIで調べたことと人から聞いたことを組み合わせてもらいます。

新メンバーが書いたメモは、次に加わるメンバーのための資料にもなります。AIの説明で間違っていた点や分かりにくかった点をリポジトリの文書に反映していくと、受け入れの準備が少しずつ整っていくはずです。

受注アプリの処理を調べる想定例

架空の受注管理アプリに、新しい開発者が参加したとします。最初の課題は、注文一覧に表示する説明文の変更です。AIにアプリ全体の設計を説明させる前に、「一覧画面を開いてから注文データが表示されるまで」を調べる範囲として決めます。

質問は「注文一覧の画面からデータ取得までの呼び出し順を、根拠となるファイル名と関数名付きで説明してください。コードで確認できないことは未確認としてください」と書けます。これは指示の記入例です。実際のファイル名や機能名は、配属先のリポジトリに置き換えます。

回答を受けたら、新メンバーが各ファイルを開いて呼び出し先をたどります。関数名が存在するだけでは十分ではありません。現在の画面から使われているか、別の条件では異なる処理を通るかも確認します。AIが昔の画面を説明していた場合は、今の画面の入口を指定して聞き直してください。

調べた内容は根拠と未確認事項を分けて残す

調査メモを、AIの説明のコピーで終わらせないようにします。次の表は記入欄の例です。ファイル名などの具体値は、調査して見つかったものだけを書きます。

受け入れ担当者は、未確認欄から会話を始めると効率的です。「なぜ注文をこの順番で表示するのか」は業務上の判断かもしれません。AIに推測を重ねさせず、仕様の担当者や過去の判断記録へ案内します。回答が確認できたら、正式な文書にも反映します。

質問回数が減ったことだけで、立ち上がりが順調だと判断しないようにしましょう。分からないことを聞けず、AIの回答で納得している可能性もあります。未確認事項を出せているか、根拠を開いて説明できるかを見るほうが、支援すべき箇所を把握できます。

最初の修正課題に合格条件を付ける

説明文の変更なら、表示される条件と対象外の画面を課題に書きます。新メンバーには、変更箇所を選んだ理由、変更後の画面、確認したテストを説明してもらいます。AIが共通部品まで変更した場合は、他の画面へ影響しないかを一緒に調べます。

レビューで「この変数は何ですか」と細部だけを問うより、「注文が一件もないときは、どの表示になりますか」と動作を尋ねると、理解している範囲を確認しやすくなります。答えられない場合は、該当する分岐とテストを読み直す課題に戻します。AIの利用を禁止してやり直す必要はありませんが、最終的な説明は本人の言葉で行います。

修正が難しかった理由も区別してください。環境を起動できない、業務用語が分からない、テストデータがないという問題は、本人のコード理解だけでは解決できません。設定資料やサンプルデータを受け入れ側が整える必要があります。

次のメンバーのために文書を更新する

最初の課題が終わったら、迷った箇所を一つ選んで文書を直します。起動手順が古かったなら実際に動いた手順を、用語の説明がなかったなら確認済みの意味を追記します。設計意図の推測を事実として残さず、担当者の確認が済んだ内容だけを正式な資料へ移してください。

新メンバーが文書を更新する変更にも、通常のレビューを付けます。その記録があれば、次に同じ疑問が出たときに判断の経緯をたどれます。古いコードを読む場面が多いチームでは、既存システムの調査にAIを使う進め方も受け入れ資料に添えると役立ちます。

まとめ

新メンバーの立ち上がりにAIを使うと、コードの説明や探索を自分で進めやすくなります。AIの説明は手がかりとして扱い、実際のコードや既存メンバーとの会話で確かめる流れを作りましょう。受け入れる側は、プロジェクトの前提や設計の背景を文書にしておくことで、人にもAIにも伝わる環境を整えられます。

e-Grantsでは、Codex・Claude Code・GitHub Copilotの導入と運用ルールの整備を支援しています。チームでの使い方を整えたい場合は、AI開発環境の導入・整備をご覧ください。