AIでジュニアの仕事が消えるのではなく、判断を学ぶ階段が消える - 構造で育てるプロダクト組織付録9
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生成物をジュニアにレビューさせる。
AI案の採用・棄却理由を書かせる。
小さな設計判断を任せる。
失敗してもよい範囲を明確にする。
レビュー観点を明示する。
先輩の判断理由を見せる。
差分レビューを育成材料にする。
AI出力と最終判断の違いを説明する。
低リスクな意思決定を持たせる。
つまり、ジュニアに必要なのは「作業量」ではなく「判断経験」です。
AIで作業を圧縮するなら、そのぶん判断経験を明示的に設計する必要があります。
これをしないと、組織は短期的には速くなります。
しかし、数年後に中堅が育っていないことに気づきます。
そのときになって、
強い人が足りない
自走できる人がいない
レビューできる人がいない
設計を任せられる人がいない
と言っても遅い。
それは、作業を削ったのではなく、育成経路を削っていたということです。
レビューは、正解を返す場ではなく判断基準を渡す場になる
AI時代には、レビューの意味も変わります。
単に成果物を直すだけなら、AIでもかなりできます。
誤字を直す。
表現を整える。
コードスタイルを合わせる。
単純なバグを見つける。
テスト漏れを指摘する。
ドキュメントの不足を補う。
これはAIが得意です。
では、人間レビューの価値はどこに残るのか。
それは、判断基準を渡すことです。
どこを危険と見たのか。
なぜこの設計では不十分なのか。
どの前提を確認すべきだったのか。
なぜこの実装は後で詰まるのか。
どの論点はEMやPdMに上げるべきなのか。
どこまでは自分で判断してよく、どこから相談すべきなのか。
こうした判断基準を渡すことが、人間レビューの重要な役割になります。
レビューは、正解を返す場ではありません。
次に本人が判断できるようにする場です。
AI時代のレビューでは、
ここを直してください
だけでは弱い。
なぜここを見るべきなのか
次に同じ状況ならどう判断するのか
どの基準を使えばよいのか
まで渡す必要があります。
そうしないと、ジュニアはAIで成果物を作れるようにはなっても、判断できるようにはなりません。
放置すると、中堅が育たない
AIでジュニアの作業を圧縮する。
短期的には、これはかなり魅力的です。
作業は速くなる。
資料は整う。
コードは増える。
テストも出る。
ドキュメントも作れる。
レビュー前の品質も上がる。
しかし、判断経験を積む階段がなければ、中堅が育ちません。
中堅とは、単にジュニアより作業が速い人ではありません。
中堅は、組織の中で次のような役割を担います。
ジュニアの成果物を見て、どこが危ないか判断する。
シニアやEMに上げるべき論点を切り分ける。
仕様の曖昧さを見つける。
小さな設計判断を引き受ける。
レビュー観点を日常運用に落とす。
過去の失敗や文脈を踏まえて止める。
ジュニアに判断基準を渡す。
組織の暗黙知を次の世代に橋渡しする。
これは、単なる作業能力ではありません。
組織の判断を中間層で支える機能です。
この層が育たないと、何が起きるか。
ジュニアはAIを使って成果物を出す。
しかし、その成果物を見られる人が少ない。
シニアやEMに判断が集中する。
レビューが詰まる。
小さな判断も上位者に上がる。
中間で止められるはずの問題が通過する。
組織全体の学習が遅くなる。
つまり、中堅が育たない組織は、AIで作業量を増やせても、判断能力は増えません。
むしろ、判断できる人が少ないまま生成物だけが増えるので、詰まりやすくなります。
AIで中堅の作業を圧縮することはできます。
しかし、中堅が担っていた判断の橋渡しと育成機能まで失うと、組織は単に学習できない組織になります。
「中堅が育たなくてもAIがあればよい」は、判断の担い手を見落としている
ここで、次のように考える人もいるかもしれません。
中堅が育たなくても、AIがあればよいのではないか。
これは一見、合理的に見えます。
AIが調査する。
AIが実装する。
AIがテストを書く。
AIがレビュー観点を出す。
AIがドキュメントを書く。
AIが過去ログを要約する。
ならば、これまで中堅が担っていた多くの作業はAIで代替できるように見える。
しかし、ここでも分ける必要があります。
中堅が担っているのは、単なる作業量ではありません。
中堅は、判断の受け皿です。
AIが出した実装案を、誰がレビューするのか。
AIが出した設計案を、誰が危険だと判断するのか。
AIが出したテスト案で足りるかを、誰が見るのか。
AIが見落とした仕様上の前提を、誰が拾うのか。
ジュニアがAI出力を鵜呑みにしているとき、誰が止めるのか。
シニアやEMに上げるべき論点を、誰が切り分けるのか。
中堅が育っていない組織では、この判断の受け皿が薄くなります。
その状態でAIを入れると、作業量は増やせます。
しかし、判断できる人が増えたわけではありません。
むしろ、AIによって増えた成果物を、少数のシニアや責任者が見ることになります。
その結果、レビューが詰まる。
判断が上位者に集中する。
ジュニアはAI出力を使うが、判断基準を学べない。
シニアはボトルネックになる。
組織は「AIを使っているのに、なぜか忙しい」状態になる。
つまり、「中堅が育たなくてもAIがあればよい」は、かなり危うい見方です。
AIは中堅の作業の一部を圧縮できます。
しかし、中堅が担っていた判断の受け皿、文脈の橋渡し、レビュー基準の移譲、ジュニア育成の機能までは、自動では埋めません。
中堅がいない組織にAIを入れると、仕事が消えるのではなく、判断の空洞が露出します。
必要なのは、中堅を不要にすることではありません。
AI時代の中堅の役割を再定義することです。
中堅は、AIより速く作業する人ではなくなります。
AI出力を検証し、ジュニアに判断基準を渡し、シニアに上げるべき論点を切り分け、組織の学習を日常運用に接続する人になります。
だから、AI時代にも中堅育成は消えません。
むしろ、作業を教える育成から、判断を育てる育成へ移る必要があります。
プロンプトやMCPは、判断の階段の代替にはならない
ここで、さらに別の反論もありそうです。
プロンプトエンジニアリングを整えればよい。
MCP でツール連携すればよい。
社内ナレッジをつなげばよい。
ワークフロー化すれば、中堅がいなくても回るのではないか。
これも、一部は正しいです。
プロンプトエンジニアリングや MCP のような仕組みは、AI活用をかなり強くします。
AIに渡す文脈を整える。
ツール呼び出しを標準化する。
社内データや業務システムに接続する。
出力フォーマットを揃える。
チェックリストを実行させる。
作業手順を半自動化する。
ログや履歴を参照させる。
これは重要です。
しかし、それでも残る問いがあります。
どの文脈を渡すべきか。
どのツールを呼ばせてよいか。
どの出力を採用してよいか。
どのリスクを人間に上げるべきか。
どの判断基準を更新すべきか。
誤ったときに誰が責任を持つか。
ジュニアが何を学習したことになるのか。
これらは、プロンプトや MCP そのものでは解決しません。
効率的に情報へアクセスできることは、判断できることを意味しません。
「多くを参照できるAI」は、そのまま「正しく判断できるAI」にはなりません。
ここで、「信頼できる情報だけをAIに読ませればよい」と考えるかもしれません。
しかし、それも判断問題を消しているわけではありません。
信頼できる情報を選ぶこと自体が、すでに判断です。
公式情報だから常に使えるとは限りません。
社内ナレッジだから常に正しいとも限りません。
過去の決定記録が、今の文脈にそのまま適用できるとも限りません。
情報には、鮮度、適用範囲、権限、例外条件、現在の運用とのずれがあります。
つまり、「信頼できる情報だけを読ませる」は、判断能力の代替ではありません。
判断問題を、入力選別の側に移しているだけです。
さらに、「AIに情報の信頼性をスコアリングさせればよい」と考えるかもしれません。
しかし、スコアリングも判断の代替ではありません。
何を信頼性とみなすのか。
どの情報源を重く見るのか。
鮮度と公式性のどちらを優先するのか。
現場運用とのずれをどう扱うのか。
どのスコア帯では人間レビューに回すのか。
スコアリングが誤ったときに、どう見直すのか。
これらを決めずにAIへ点数を出させても、判断基準ができたことにはなりません。
信頼度 82 点。
リスク 0.31。
適用可能性 74%。
こうした数値は、一見すると判断を助けるように見えます。
しかし、どの基準で算出され、どの閾値で止め、どの条件で人間に上げ、誤ったときに誰が責任を持つのかが決まっていなければ、それは判断ではありません。
単に、曖昧さに数字を付けただけです。
プロンプトを整えても、判断基準がなければ、きれいに曖昧な指示が流れるだけです。
MCPでツールをつないでも、責任境界がなければ、曖昧な判断をより遠くまで伝播できるだけです。
スコアリングを足しても、基準がなければ、判断しているように見える数字が増えるだけです。
技術で作業経路は整えられます。
しかし、判断基準・責任境界・育成の階段は、組織が設計しなければなりません。
プロンプトやMCPは、判断を代替するものではありません。
判断が通る経路を整えるものです。
したがって、中堅が担っていた判断の橋渡しを消したまま、プロンプトとツール接続だけを整えると、組織は作業の流れだけが洗練された、学習しない組織になります。
AI時代に必要なのは、プロンプトやツール連携だけではありません。
それらを通じて、誰が何を学び、どの判断を引き受け、どの基準を更新するのかを設計することです。
組織が設計すべきもの
AI時代に、組織が若手・中堅育成で設計すべきものは、単なる研修ではありません。
必要なのは、判断を学ぶための実務上の構造です。
たとえば、次のようなものです。
1. 小さな判断単位
いきなり大きな意思決定を任せるのではなく、低リスクな判断単位を渡す。
どのテストを追加するか。
どの案を採用するか。
どの仕様を確認するか。
どのリスクを上げるか。
どのAI出力を使わないか。
小さくてもよいので、自分で判断する場を作る。
2. 判断理由の記録
成果物だけではなく、判断理由を残す。
なぜこの実装にしたのか。
なぜこのAI案を捨てたのか。
どの前提を確認したのか。
レビューで何を学んだのか。
判断理由が残らないと、育成になりにくい。
3. レビュー観点の明示
レビューで何を見るのかを明示する。
正しさ。
安全性。
影響範囲。
保守性。
ユーザー影響。
事業上の制約。
将来の変更可能性。
観点が明示されると、ジュニアは何を見ればよいかを学べます。
4. AI案と人間判断の差分
AIの出した案と、人間が採用した判断の差分を学習材料にする。
AIは何を見落としたのか。
人間は何を危険と見たのか。
どの前提が違ったのか。
なぜ最終案は変わったのか。
ここには学習資源がかなりあります。
5. 失敗してよい範囲
判断経験には失敗が必要です。
しかし、失敗してはいけない場所で失敗させるのは危険です。
だから、失敗してよい範囲を設計する。
小さな機能。
内部ツール。
影響範囲の限定された修正。
レビュー前提の設計案。
実験的な検証環境。
失敗できる範囲を作らないと、判断経験は育ちません。
6. 中堅の役割再定義
中堅を「ジュニアより速く作業する人」として扱わない。
AI時代の中堅は、判断の橋渡しを担う人です。
ジュニアに判断基準を渡す。
シニアに上げる論点を切り分ける。
AI出力を検証する。
レビュー観点を日常運用に落とす。
チームの暗黙知を記録に変える。
この役割を明確にしないと、中堅はただの便利な作業者として消耗します。
個人が意識すべきこと
若手個人がAI時代に意識すべきこともあります。
まず、AIを使うこと自体は重要です。
使わないより、使った方がよい場面は多いでしょう。
しかし、AIで成果物を出すだけでは足りません。
意識すべきなのは、次のような問いです。
自分は何を判断したのか。
何をAIに任せたのか。
AI案のどこを採用したのか。
どこを棄却したのか。
人間レビューで何が変わったのか。
次回、同じ場面なら何を見るのか。
どの判断基準を獲得したのか。
これらを残しておく。
そうすると、AIを使うほど判断経験が積み上がります。
逆に、AIに出させて、そのまま提出して、直されて終わるだけなら、判断経験は残りにくい。
AIを使うな、ではありません。
AIを使ったうえで、判断差分を取る。
これが、AI時代の若手にとってかなり重要になります。
この記事から持ち帰れること
AI時代の若手育成を考えるなら、次の問いを見た方がよいです。
- ジュニアの作業を削ったとき、判断経験も一緒に削っていないか
- 低リスクな判断を任せる場はあるか
- AI案と人間レビューの差分を学習材料にしているか
- レビューは成果物修正だけで終わっていないか
- 判断基準を次に使える形で渡しているか
- 中堅を単なる作業者として扱っていないか
- AIによって増えた生成物を、誰が判断に変換しているか
- プロンプトやMCPを、判断の階段の代替だと誤解していないか
- 組織はAIで速くなったのか、それとも学習しなくなったのか
大事なのは、昔の作業をそのまま残すことではありません。
AIで作業が圧縮されるなら、その代わりに判断を学ぶ階段を作ることです。
まとめ
AIでジュニアの仕事が消える。
この言い方は、分かりやすいですが少し粗いです。
本当に問題なのは、ジュニアの作業が減ることではありません。
作業の中に埋まっていた、観測・判断・失敗・修正・レビューの学習経路が消えることです。
若手は、AIで成果物を出すだけでは足りません。
AI案と人間レビューの差分を取り、自分が何を判断したのかを残す必要があります。
組織は、ジュニアに昔の作業を戻すだけでは足りません。
AIで圧縮された作業の代わりに、判断を練習する階段を設計する必要があります。
中堅は、AIより速く作業する人ではなくなります。
AI出力を検証し、ジュニアに判断基準を渡し、シニアに上げる論点を切り分け、組織の学習を日常運用に接続する人になります。
プロンプトやMCPは重要です。
しかし、それらは判断の階段の代替ではありません。
作業経路を整える技術であり、判断基準・責任境界・育成構造そのものではありません。
AI時代に強い組織は、ジュニアの仕事を単にAIで置き換える組織ではありません。
AIで作業を圧縮しながら、若手が判断を学び、中堅が判断を橋渡しし、シニアの判断基準が組織に残るように設計できる組織です。
つまり、AI時代の若手育成とは、作業を守ることではありません。
判断を学ぶ階段を作り直すことです。
Discussion