概要
OJT研修の一環として、業務アプリを題材にしたAndroidアプリ開発教材をAIで生成し、新人に実際にコードを書いてもらいました。
その結果、新人が実際の業務ソースコードを開いた際に、構造や実装意図をスムーズに理解できる状態を作ることができました。
この取り組みで最も重要だったのは、「何を揃え、何を学ばせるのか」を人が先に明確に定義し、それをAIに渡すことです。AIは教材生成を効率化してくれますが、学習のゴールや習得させたい内容の設計は人が担う必要があります。
教材作成の目的
結論、業務に入るときの「段差」をなくしたかった、が教材を作成した主な目的です。
OJT対象の新人はこういう人でした。
- 新卒入社
- インターンでWeb開発の経験あり。Git や実装の進め方など、開発そのものの雰囲気は知っている
- Androidは未経験。Activity・ライフサイクル・MVVM などはこれから
現場はAndroidアプリ開発なので、業務に入ったときにスムーズに手が動く状態にしておきたい、と考えたことが教材を作成するきっかけでした。
ここで問題になったのが、業務で使っているアーキテクチャ・ライブラリに合った教材が無い ことでした。世の中の教材はだいたい次のどちらかに寄っています。
- 「Androidアプリの作り方」を広く学ぶ、機能重視の構成
- 特定のライブラリを学ぶための、そのライブラリに寄せた構成
どちらも教材としては正しいのですが、業務コードベースとは書き方が揃いません。座学でMVVMを説明しても、教材で別の型を身につけてしまうと、業務リポジトリに入ったところでもう一度学び直しになります。研修で減らしたかったのは、まさにこの学び直しの段差でした。
探すのをやめて業務アプリから逆算する
教材が見つからないなら作ればいい！
そして、教材を作る上で「作るコストが高い」問題は、AIで解決できそうと考えました。
仕様書とサンプルコードをゼロから人が書くと重いですが、下書きはAIに任せられます。
ただし、AIに丸投げしても業務コードに合う教材は出てきません。放っておくとAIは「一般的にきれいな構成」に寄っていきます。そこで、人とAIの役割分担を先に決めました。
人とAIの役割分担
教材づくりの分担は以下となります。
| 人がやる（判断が必要） | AIがやる |
|---|---|
| ・業務アプリの解析 | ・仕様書の起草 |
| ・学習観点の設計 | ・サンプルコードの生成 |
| ・使う/使わないの線引き | ・言い回し・体裁の整形 |
| ・生成物のレビューと修正 | - |
判断の軸はシンプルで、「業務コードベースと揃っているか」を判定できるのは、業務アプリを触っている人だけ ということです。ここは委譲できません。逆に「解析メモと制約を渡されたら、その形で仕様書を書く」「その仕様に沿ってサンプルコードを書く」は、量は多いが判断は少ないので、AIに任せて構いません。
つまり 教材の中身は人が決め、文章とコードの下書きはAIが書く という切り方になります。
教材アプリの設計 — 2本のアプリで何を分担させたか
教材アプリは2本にしました。機能で選んだのではなく、学習観点で分けた結果として2本になった、というのが正確な言い方です。
| アプリ | 学習観点 | 位置づけ |
|---|---|---|
| BMI値計算 | 画面・状態・入力検証 | View / ViewModel の責務、状態の持ち方。画面まわりの基本形 |
| 天気情報取得 | 非同期・API・エラー処理 | データ層、失敗時の扱い。業務で頻出の「取得して表示する」の縮小版 |
順番にも意味を持たせました。先に同期的な画面で状態管理を安定させ、そのあとに非同期と失敗ケースを足す 流れにしています。いきなり通信から入ると、詰まったときに状態管理の問題なのか通信の問題なのか切り分けにくくなります。
全体の流れは次のとおりです。
[座学・予習]
Activity / ライフサイクル / 画面遷移 / MVVMの責務
│
│ ※ 教材が「初見の単語の塊」にならないよう、
│ 先に地図だけ渡しておく
▼
[教材アプリ①] BMI値計算
画面・状態・入力検証 ← 通信が無いので、責務の置き場所に集中できる
│
▼
[教材アプリ②] 天気情報取得
非同期・API・エラー処理 ← ①で状態管理が固まった前提で、通信と失敗を足す
│
▼
[業務リポジトリ]
座学と教材で見た型が、そのまま並んでいる状態
実際にやったこと
実際の流れは5ステップです。人が挟むのは最初（解析・制約設計）と最後（レビュー）で、真ん中の生成をAIに任せる形になっています。
[Step1] 業務アプリを解析（人）
│ 出力：解析メモ（構成・ライブラリ・データフロー）
▼
[Step2] 制約を決める（人）
│ 出力：教材の設計制約（学習観点、使う/使わないライブラリ 等）
▼
[Step3] 仕様書を作らせる（AI）
│ 入力：解析メモ + 制約
│ 出力：教材アプリの仕様書
▼
[Step4] 模範サンプルコードを出させる（AI）
│ 入力：仕様書（※ Step3 とは別セッションで実行）
│ 出力：仕様書に沿ったサンプル実装
▼
[Step5] 人がレビューして直す（人）
観点：学習観点が残っているか、業務とズレていないか、
新卒に考える余地が残っているか
以下、各ステップでやったことを具体的に書きます。
Step1. 業務アプリを解析する（人）
ここが教材の品質をほぼ決めます。 AIに何を渡すかがここで確定するので、雑にやると以降がすべてぶれます。
実際に見たのは次のあたりです。
-
モジュール構成とディレクトリ構成：
app/,data/,domain/の切り方、機能ごとのパッケージの並べ方 - 使用ライブラリと使われ方：DI、非同期処理、HTTPクライアント、UI構築などが、どのライブラリで、どういう呼び出し規約で使われているか
- 画面からデータ取得までの流れ：View がイベントを受けてから、ViewModel を通り、Repository を経由してAPIに到達し、状態として返ってくるまでの一本道
- エラー・ローディングの扱い：失敗時にどこで例外を捕まえ、どう画面状態に反映しているか
これを「解析メモ」として1枚にまとめ、以降の入力にしました。
Step2. 制約を決める（人）
AIに渡す前に、次の4点を確定させました。
- 予習で扱った範囲：教材で再登場させたい概念（Activity・ライフサイクル・画面遷移・MVVMの責務）
- 各アプリの学習観点：BMI=画面・状態・入力検証、天気=非同期・API・エラー処理
- 使ってよいライブラリと、使わないもの：業務と同じライブラリに揃え、教材のために別物を持ち込まない
- 業務固有で落とすもの：認証基盤や独自ドメインなど、教材では扱わない部分を明示
「使わないもの」と「落とすもの」を先に書いた のが効きました。AIは何もないと「一般的にきれいな構成」を足しに来るので、禁止事項を明示しないと構成が業務からずれてしまいます。
Step3. 仕様書を作らせる（AI）
Copilotに解析メモと制約を渡し、次を含む仕様書を出させました。
- アプリの概要と画面一覧
- 画面ごとの入力・出力・状態
- クラス構成と責務（どのレイヤーに何を置くか）
- エラー時の挙動
- 完成条件
新卒に最終的に渡すのは、この仕様書です。
Step4. 模範サンプルコードも出させる（AI）
仕様書に沿ったサンプルコードもAIに出させました。使い道は写経ではなく次の3つです。
- レビュー時の答え合わせ
- 詰まったときに構造を確認するための地図
- 座学で覚えた単語が、実際のコードのどこに現れるかの対応付け
仕様書とサンプルは分けて出力した のもポイントです。同時に出すと、仕様がコードの都合に引っ張られて、学習観点（入力検証やエラー処理）が薄くなります。仕様は仕様、コードはコード、で分けています。
Step5. 人がレビューして直す（人）
最後は必ず人が通します。見たのは次の3点です。
- 学習観点から外れていないか：BMIで入力検証が省かれていないか、天気で失敗系が消えていないか
- 業務とズレていないか：ライブラリの使い方、ディレクトリ構成、命名が業務コードと揃っているか
- 考える余地が残っているか：新卒がサンプルをそのまま写して終わる形になっていないか
AIは学習観点より完成度を優先しがちで、たとえば天気アプリでは「取得できた前提」で書かれ、失敗系がさらっと省かれることがありました。そこは戻して書き直させました。
結果と学び
目的3つに対して何が起きたか
冒頭で挙げた教材の目的は次の3つでした。それぞれの結果を書きます。
| 目的 | 結果 |
|---|---|
| ① アプリ開発の雰囲気を掴む | 座学の単語（ViewModel, Repository 等）が、教材のコードにそのまま登場したので、「言葉と実物が繋がる」状態を作れた |
| ② 座学で教えた構成の理解を深める | 責務の置き場所（BMI）と、非同期・エラー（天気）に分けたことで、1本のアプリで両方をやるより論点が絞れ、迷子になりにくかった |
| ③ 業務にすんなり入れるようにする | 教材で書いた型と業務リポジトリの型が揃っているので、業務コードを開いたときに「見たことがある構造」として読める状態になった |
コスト面でも、既存教材を探して比較する時間で、解析からレビューまで一周できました。教材が無いという問題は、作るコストの問題ではなくなった、というのが実感です。
一方で残った課題もあります。業務プロダクトのドメイン知識は教材では扱っていない ので、そこは業務中などの別機会で補う必要があります。教材はあくまで「型に慣れる」ためのもので、ドメインまで載せると論点が増えすぎて学習観点がぼやけると判断し、割り切りました。
なぜ人／なぜAI、の線引き
やってみて明確になった、人とAIの線引きは次のとおりです。
- 人がやる必要があるところは、「業務コードベースと揃っているかの判定」を要求する工程です。解析、制約決め、レビューがこれに当たります。ここは業務アプリを触っている人しかできません。委譲するとAIが世間一般のベストプラクティスに寄せ、教材と業務の間に段差が戻ってしまいます。
- AIに任せてよいところは、「制約が明確なら、あとは量産するだけ」の工程です。仕様書の文章化、サンプルコードの実装、体裁の整形などが当たります。ここは人がやると単純に時間がかかります。
言い換えると、教材づくりの価値は「制約の設計」に集中していて、そこ以外は生成でよい、ということになります。
まとめ
- 業務にスムーズに入るための教材がネット上に無いなら、業務アプリを解析して、その結果を制約にAIへ作らせるのが早いです
- ただし 「何を揃えて、何を学ばせるか」は人が先に決めきる 必要があります。ここを飛ばすと、AIは業務ではなく世間一般に寄せてしまいます
- 今回は座学で地図を渡したうえで、BMI値計算（画面・状態・入力検証）と天気情報取得（非同期・API・エラー処理）の2本でそれを実施しました
- 結果、教材で書いた型と業務リポジトリの型が揃い、新人が業務コードを「見たことがある構造」として読める状態を作れました
OJT教材は探すものではなく、現場の型から生成するもの でよかった、というのが今回の結論です。同じように「うちの構成に合う教材が無い」と困っている人がいれば、業務アプリの解析からはじめてみるとよいと思います。