はじめに
先日、なんでも Copilot のイベントで、大学で働いている方から、参加者に向けて問いが投げかけられました。
「AI が正しい答えを返せる時代に、人が学ぶことの価値は何か。大学は何を教え、何を評価するべきなのか」
この問いをきっかけに、自分の考えを整理してみたいと思います。
最初にお断りしておくと、私は教育の専門家ではありません。本記事で触れる内容は、すでに多くの大学や授業で取り組まれていることも含まれていると思います。その意味で、教育の現場に何かを提案するというよりも、あくまで一個人の経験からの考えとして読んでいただければ幸いです。
ただ、サポートエンジニア、講師、相談対応、メンタリング、現在の市民開発や生成 AI 活用の伴走支援を通じて、人が学び、仕事ができるようになっていく過程には、長く関わってきました。
その経験を振り返りながら、学生時代にどのような力を身につけ、どのような経験を積むことに意味があるのかを考えてみます。
レポートの水準と、本人が身につけた力
学生も、ChatGPT や Gemini などを通じて、さまざまなことを教えてもらえるようになっています。
大学でわかりやすいのは、レポートです。生成 AI を使うことで、本人が自力では書けなかったような水準のレポートが提出されるケースが出てきているのではないかと思います。
ただ、そのレポートを本人がどこまで考えて作ったのか、本当に自分の力で書けるものなのかは別です。もちろん人によりますが、成果物の出来栄えだけでは、本人が何を理解し、何を身につけたかを判断しにくくなっています。そのレポートに単位を与えることを考えたときに、果たしてそれでよいのか、という問題があります。
また、質問すればすぐに答えてくれるものがあるため、「AI に聞けばいいじゃん。学ぶ必要、覚える必要ある？」という考え方にもなります。今回の問いには、こうした背景もあるのだと思います。
社会人になってからも、同じことが起きている
大学を卒業した後も、似たことが起きているように感じています。
プレゼン資料、報告資料、図解資料などを作る際に、新人や若手の人も生成 AI を使うようになっています。仮に新人の力が 1 だったとすると、生成 AI を使うことで 3 点、4 点、5 点の成果物を出せる。そうしたケースが増えることで、平均の水準は上がっているように見えます。個人的には、これ自体は別に悪いことではないと思いますし、恐らく私が今新人だったら同じようなことをすると思います。
ただ、資料だけでビジネスが動かないこともあります。むしろ、動かないことの方がほとんどかと思います。
資料には、その前提となる目的や問い、仮説があります。資料は、それらを伝えたり、検討したりするために存在するものだと思います。その前提を自分で設定できるのか。出てきた資料を自分でレビューし、よりよくできるのか。ここが重要だと考えています。
例えば、生成 AI がなかったころ、新人が 5 年目の先輩の作った資料を十分にレビューできるかというと、難しいですよね。少なくとも私はできませんでした。生成 AI によって、自分の理解や経験を超えた成果物を手にしたときにも、似た状態が起きているのではないでしょうか。
個人的には、AI の進化に伴って成果物の点数が上がることと、本人の能力が上がることは、分けて考える必要があると思っています。
この観点については以前以下のような記事も書いております。
レポートと仕事の成果物では、提出した後が違う
大学のレポートと、社会人になってから作る資料には、提出した後の扱いに違いがあると思います。
もちろん、大学や授業によって異なるでしょう。提出後に丁寧なフィードバックや書き直しの機会を設けている授業も多くあると思います。ただ、レポートの場合、提出したものが評価され、単位を得るところで一区切りとなり、その後に内容を修正したり、実際に使った結果を踏まえて考え直したりする機会は、比較的少ないのではないかという印象があります。
一方、ビジネスにおける成果物は、何かしら仕事を前に進めるために存在します。目的を満たしていなければ、フィードバックを受けて修正することになります。その成果物を使って説明したり、報告・連絡・相談をしたりする中で、質問や指摘も受けます。結果としてどうだったのか、次に同じような状況があれば何を変えた方がよいのかを考える機会もあります。
この積み重ねによって、異なる場面でも応用できる力が、段階的に身についていくのだと思います。
フィードバックの機会があっても、学べるとは限らない
ただし、ビジネスにフィードバックの機会があるからといって、その過程で必ず本人が学べるとは限りません。
例えば、自力では作れなかった資料を生成 AI で作り、上司から指摘された内容を、そのまま AI に渡して直させるだけだったらどうでしょうか。
資料は修正されます。しかし、本人が「なぜその指摘を受けたのか」「何を考慮できていなかったのか」「条件が変わった場合にも同じ修正が必要なのか」を理解していなければ、別の場面で自分から適切に対応できる可能性は低くなってしまうと思います。
成果物が改善されたことと、その人が次の場面でも対応できるようになったことは、分けて見る必要があると考えています。
対話の場面では、理解の不足がその場で表れる
この隔たりが特に表れるのが、対話を伴う場面です。
仮に本人の力が 1 の段階で、生成 AI によって 7、8 の水準の資料を作れたとします。資料だけを見ればよくできていても、その資料を使って話す中で、少しイレギュラーな質問や指摘があったらどうでしょうか。前提を変えて考える必要が生じたときに、本人がその内容を理解していなければ、対応が難しくなってしまいます。対話のたびに立ち止まり、AI に確認する時間があるとも限りません。
自力ではできなかったことが生成 AI によってできるのは、階段を一足飛びに何段も登ったような状態だと思います。ただ、その段階に見合う力が本人に身についているとは限りません。
だからこそ、ビジネスでは、既存のフィードバックの過程を通じて、本人の理解や判断で抜けている部分まで補う必要があると考えています。上司の指摘を反映して資料が直ったところで終わらず、その指摘を本人が理解し、自力でも 5 点を出せるようになる。さらに、資料そのものだけでなく、目的や問いの設定も含めて、6 点、7 点を出せるようになる。生成 AI を使った人材育成では、そうした成長を支えることをより意識する必要があるのではないでしょうか。
AI を使ってよい成果物を出すことには価値があります。その上で、本人にどのような力が育っているのかも見ていきたい、ということです。
レポートを課していた目的に立ち返る
教育について考えるとき、まず立ち返りたいのは、何のためにレポートを書かせていたのか、ということです。
学生時代には、社会人になるまでの準備期間という側面もあります。その中で、どのような能力を身につける必要があるのか。そのための手段として、レポートの作成があったのではないでしょうか。
調べる、考える、整理する、自分の言葉で表現する。生成 AI に作成を頼ることで、こうした過程が抜けてしまうのであれば、目的に立ち返り、別の手段で補うことを考える必要があるのかなと思います。
また、レポートの課題やテーマは、大枠があらかじめ決まっていることも多いと思います。その場合、学生自身が「何を解決すべきか」「何をゴールにするか」を設定する経験は限られます。前述の通り、提出後に修正し、別の課題で使ってみる機会も限られているとすれば、目的を設定するところと、結果から学び直すところの両方が、十分には含まれていない可能性があります。
もちろん、そのレポートが何を学ぶための課題なのかによって、必要な過程は異なります。ただ、将来、自分で課題を捉え、他者と関わりながら物事を進める力まで育てたいのであれば、提出物を評価するだけで、その目的をどこまで満たせるのかは考える余地があると思います。
同時に、教育の目的自体を見直す必要もあるのかもしれません。ビジネスで求められる能力には、普遍的なものもあれば、時代によって変化するものもあります。AI があることを踏まえて、何を身につけるための教育なのかを考え直す余地があると思います。
大学には学問を深める役割もあります。すべてをビジネスの準備に置き換えるという話ではありません。学問を深める場合にも、社会に出て仕事をする場合にも、それぞれ必要な基礎と、その先に育てたい能力を考えることが重要なのだと思います。
基礎を学ぶ意味は残る。ただし、応用には橋渡しが必要
学生時代の学習には、暗記を中心としたテストや数学の問題など、ある程度答えが決まっているものが比較的多くあります。
一方、ビジネスでは、常に明確な正解があるわけではありません。個人の感情、人間関係、立場、時間や組織の制約など、多くの変数があります。対話の中で、新しい情報や条件が加わることもあります。そうした場面に向けて何を身につけておくべきかについては、AI が登場する前から、十分に扱えていなかった部分もあるのではないかと思います。
では、暗記や数学など、AI が得意とするものを学ぶ必要はなくなるのでしょうか。個人的には、そうは思いません。
知識を身につけ、問題を解き、なぜそうなるのかを考えることは、その後の学習や仕事の土台になります。考える習慣をつくる意味もあると思います。私が経験してきたシステムのトラブル調査にも、学業で身につける基礎スキルの延長線上にある部分が少なからずある認識です。
ただし、ある課題を繰り返せば、あらゆる場面で使える思考力が自動的に育つ、とまでは言えません。
学習研究でいう「転移」は、ある場面で学んだことを別の場面で使うことです。米国の National Research Council による『How People Learn』（2000 年）でも、十分な初期学習や意味の理解が重要であり、異なる場面での応用は自動的には起きないと整理されています。基礎を学ぶことと、それを異なる条件で使う経験の両方が必要だと考えられます。
※参考：How People Learn: Brain, Mind, Experience, and School（National Academies Press, 2000）
レポートや読書感想文についても、自分で考えて表現する過程には意味があります。以前から、インターネットで検索してコピーすることで、その過程を飛ばすことはありました。それが生成 AI によって、より顕著になっているのだと思います。そこで必要になるのは、本人が考える過程を、どのように確保するかという検討です。
私は、学生時代から明確な目標を持っていたわけではない
ここで、自分自身の話をします。
私は九州にある国立大学の工学部出身です。学生時代は特に明確な目標があったわけではなく、課題をこなし、そこそこの成績で満足していました。
IT 系ではありましたが、特別に IT が好きだったわけでもありません。就職活動でも、最初は文系の総合職のような職種を志望していました。ただ、結果的に全然受からず、しぶしぶ SE になりました。
つまり、学生時代から目標に向けて、特別に学習を積み重ねていたわけではありません。
その後、社会人として経験を積み、転職を経て、現在は独立して3期目を終えようとしています。会社員時代は、あくまでその会社、そのジョブレベルにおける評価基準ではありますが、最高評価を何度もいただき、大きな表彰を受けたこともありました。独立後も、幸いなことに業績は非常に良好で、ビジネスパーソンとしては、それなりにうまくいっていると言ってよいのかなと思っています。
その自分が、何を通じて力を身につけてきたのか。そこを振り返ることで、学生時代から積める経験や学んでおけることについても、何か見えてくるのではないかと思います。
社会人になってから、何を通じて力を身につけてきたのか
ここからは、自分が今の仕事で付加価値だと感じている力を一つずつ取り上げ、それがどのような経験から身についたのかを振り返ります。
相手に合わせて説明し、成長を支える
現在は、市民開発や生成 AI 活用の伴走支援などを主に行っています。その中で、自分の付加価値の一つになっていると感じるのが、相手に合わせて説明する力です。
IT を専門としない方に説明するときは、相手が理解できる言葉や単語を選ぶことに細心の注意を払っています。全体像を示したり、抽象化して相手になじみのある言葉で伝えたり、具体的な操作に戻ったりしながら説明します。
相談会やトレーニングの講師として評価をいただけている背景には、この部分もあるのではないかと思います。
これは、サポートエンジニア時代に磨いてきた力です。電話やメールを通じてお客様の問題を解決するには、説明を理解していただき、必要な対応につなげてもらうことが求められました。その目的に照らして、伝え方を工夫し続けてきたことが、今につながっていると思います。
一方、人の成長を支える場面では、分かりやすく説明することに加えて、相手が何を感じ、何を望んでいるのかを知ることも大切にしてきました。25歳頃にOJTトレーナーを担当して以来、15年以上取り組んできたメンタリングや人材育成でも、その人自身の思いや欲求を一緒に探していくことを意識していました。
例えば、前々職で新人のOJTを担当していたときは、出会った初日から、なぜこの会社に入ったのか、なぜSEになろうと思ったのか、配属先について今どう感じているのかを聞いていました。入社前とのギャップや不安、気になっていること、どのような学生時代を過ごしてきたのかなど、少しでもその人を知ろうと、対話を重ねていました。
もちろん、「実はあまり考えていませんでした」「特に目標があるわけではありません」という人もいました。そのようなときには、まずは1年間、がむしゃらに仕事に取り組み、いろいろなことに挑戦してみてほしいと伝えていました。同時に、本当にきついときは必ず助けること、こちらからもできるだけ気づくようにするけれど、気づけないときには伝えてほしいということも話していました。
そうして過ごした1年間を振り返る機会が、OJT発表会でした。上司や本部長などの前で、1年間の取り組みや2年目の目標を発表します。ただ、準備の過程で上司などからフィードバックを受けるうちに、本人の言葉ではなく、上司が喜びそうな目標や報告になってしまっていることもありました。それでは、本人が2年目以降も高いモチベーションを持って仕事に取り組めるのだろうかと感じていました。
そこで、この1年間で少しでも楽しいと思ったことや、それほど苦にならなかった作業がなかったかを振り返ってもらい、なぜそう感じたのかを一緒に考えていました。何度も問いかけ、対話を重ねながら、がむしゃらに取り組んだからこそ生まれた感情を掘り下げ、その奥にある本人の思いや欲求を一緒に探していく。その上で、2年目にはどのようなことに取り組めば、仕事の中で同じように楽しいと思える時間を増やせるのかを考えていました。
発表の準備には、こうした対話も含めて多くの時間をかけていました。当時は、ほかのどのOJTトレーナーよりも本人と話していたのではないかと思うほどです。
このような関わり方をしてきた背景には、仕事を一度も楽しいと思ったことがないという人や、心身をすり減らし、心の病を抱えてしまった人を数多く見てきたことがあります。新卒で入社した頃はあんなに元気だったのに、と感じることもありました。
生活のために働くという価値観も、もちろん尊重しています。ただ、働く時間は人生の中で大きな割合を占めます。その中に少しでも楽しいと思える時間があり、それを積み重ねていけた方が、本人にとってよいのではないかと考えてきました。
こうしたメンタリングと、現在の研修や業務の伴走支援では、関わる目的や場面は異なります。それでも、相手を知り、その人の状況に合わせて関わり方を考えるという姿勢は共通しています。
現在の研修や伴走支援でも、相手の理解度や進捗に応じて、支援の仕方を変えています。順調ならヒントを中心にして、自分で考えてもらう。行き詰まっていれば支援を厚くする。その場で成果を出すことと、本人が自立してできるようになることの両方を考えながら、関わり方を調整しています。
説明したことと、理解してもらったこと、実践できること、別の場面でも応用できることは、それぞれ異なります。相手との対話を通じて、その隔たりがどこにあるのかを確かめ、必要な支援を考えることも、育成の重要な部分だと思います。
専門性は、人から相談を受ける中で深まった
Microsoft のプロダクトや、セキュリティ、ガバナンスに関する専門性も、自分の付加価値の一つです。
この専門性を身につける上で大きかったのは、多くの人から相談を受けてきたことでした。
相談を受けると、「こういうところに困るのであれば、この知識が役に立つんだ」とわかります。「ここに疑問を持つのなら、こういう順序で説明した方がよいのではないか」と考えることもあります。
また、自分が理解したつもりになっていたことにも気づかされます。
理解が浅い部分や、基礎として身につけ直す必要がある部分を見つけ、参考書を買うなどして補っていました。サポートエンジニア時代には、こうしたことが非常に多くありました。
教材を読むだけでは気づけなかった、自分の学習課題があったということです。
誰かに教えることや相談に乗ることは、相手への貢献であると同時に、自分が何を理解していないかを知る機会にもなっていました。
この点について、以下の記事でも触れています。
関連する研究として、Nestojko ら（2014 年）は、後で他者に教えるつもりで文章を学んだ人は、テストに備えて学んだ人より、内容をよりよく整理して思い出せたと報告しています。実際の指導や相談対応まで検証した研究ではありませんが、教えることを意識して学ぶ意味を補強する結果だと思います。
生成 AI を使って効率よく学ぶことにも価値があります。その上で、学んだことを人に教え、実際に質問を受ける経験も持つことが重要だと考えています。
多くの事情が関わる課題について相談するときにも、生成 AI に質問して回答を得るだけより、人と関わることで学べる部分があると思います。
具体と抽象を行き来する力は、問題解決の中で育った
自分の強みとして、具体と抽象を行き来する力もあると思っています。
その力がどのような経験から身についたのかを考えると、大きかったのは、対話を通じて、人と関わりながらビジネスの問題を解決してきたことです。
相手が口にした質問に答えることや、求められた手段を提供することが、必ずしも問題解決につながるとは限りません。
そのため、相手が何を実現したいのか、何に困っているのか、なぜその手段が必要だと考えているのかを、対話を通じて確認してきました。
一段、二段上の視点から問題を捉え直す。その一方で、原因や前提を深掘りし、仮説を立てる。そして、解決すべき問題を明らかにした上で、具体的な対応に落とし込む。
この往復を繰り返してきた経験が、大きかったのではないかと思います。
これは、サポートのトラブルシューティングでも、伴走支援で相談に対応するときでも同じです。
メンタリングでも、能力向上、キャリア、関わっているプロジェクト上の課題など、さまざまな相談を受けます。今悩んでいることをどう捉えるべきなのか。本人が考えている手段で、本当にその問題が解決するのか。そもそも問題は何なのか。
それを相手と一緒に考える中で、具体と抽象を行き来してきました。
抽象化は、単に大きな言葉で言い換えることではありません。目的や構造を捉え直し、それを目の前の相手や状況に戻したときに、具体的な判断や行動につながることが重要だと考えています。
また、自分の捉え方が適切だったかは、相手の反応や、その後の結果から確かめることになります。説明が伝わらなかったり、提案した方法が相手の事情に合わなかったりすれば、前提や目的まで戻って考え直します。
そうした修正の繰り返しも、この力につながってきたのだと思います。
ゴールの設計は、重大トラブルの対策会議の中で鍛えられた
ゴールを対話の中で設計する力も、自分の強みの一つだと感じています。この力が最も鍛えられたのは、サポートエンジニア時代の重大トラブル対応でした。
サポートエンジニアとして、重大なシステムトラブルの対応を 100 回以上経験しました。夜中に緊急の電話を受け、20 代なりにその場で判断を迫られることもありました。
特に印象に残っているのが、お客様先での対策会議です。トラブルが起きると、お客様の部長・課長クラスの方々をはじめ、立場の異なる多くの関係者が一堂に会します。私はその中で最年少であることがほとんどでしたが、技術的な状況を最も把握している立場として、強いプレッシャーの中で報告と調整を担っていました。
こうした場では、最初から「何をゴールにするのか」が揃っているわけではありません。お客様は一刻も早い復旧を望み、同時に原因と再発防止策の説明を求めます。関係者ごとに見えている事象や責任範囲は異なります。自社としては、できることとできないことを正直に伝える必要があります。
そのため、会議の中で、今どの範囲の話をしているのか、誰のどの課題を解決しようとしているのか、それが参加者にとって共通のゴールになっているのかを、確かめながら進める必要がありました。まず暫定復旧を優先するのか、原因特定を優先するのか。今日の会議では何を決め、何を持ち帰るのか。そうしたことを、対話を通じて一つずつ揃えていきました。
また、ゴールは固定されたものではありませんでした。調査が進んで新しい事実が分かれば、前提が変わります。お客様の業務上の事情が分かれば、優先順位も変わります。そのたびに、ゴールを見直し、関係者と認識を合わせ直す必要がありました。
こうしたやり取りを何度も繰り返してきたことが、利害の異なる関係者と共通のゴールをつくり、状況に応じて見直していく力につながったのだと思います。
この経験は、現在の伴走支援でも生きています。お客様の個人、チーム、部門、組織のそれぞれに課題があり、最初から取り組むべき問題が明確になっているとは限りません。大枠のビジョンを踏まえ、自分たちが関わる範囲で課題を具体化し、手段に落とし込んで前に進める。試してみて想定した課題解決につながらなければ、レビューを通じて考え直す。この繰り返しが、条件が変わった場合や異なる場面にも対応できる力を育てるのではないかと思います。
多様な人との対話と、内省の習慣
コミュニケーション能力をどう定義するかは整理する必要がありますが、この面にも、自分の長所があると思っています。
学生時代の経験で何が社会人になってからプラスに働いたかを考えると、さまざまなタイプの人と付き合ってきたことは大きかったと思います。
社会人になってからは、さらに幅広い世代や、異なる組織、会社、部門、部署の人たちと関わるようになりました。その中で対話と試行を重ねてきました。もちろん、うまくいかないこともあります。
そこで大きかったのが、振り返りの習慣です。対応して終わりにせず、自分の問題の捉え方や関わり方は適切だったのかを考え、次の行動に反映してきました。
その土台には、他者と接するときの動機があります。相手の問題解決や成長に貢献したいという思いを持ち、書籍で学んだことも実践しながら、自分の振る舞いを振り返ってきました。
なぜ自分にそのような感情が湧いたのか。なぜその言葉を選んだのか。自分の考えを言語化することも、その一部です。
こうした部分は、関わる要素が多く、再現や代替がしにくい部分でもあると感じます。
多くの人と会う経験に、内省を重ねることで、自分のベースや基軸がつくられてきたのではないかと思います。経験の数に加えて、経験から自分の次の行動を変えてきたことが重要だったと考えています。
これまでの経験から、学びの要素を整理してみる
ここまで、自分がどのような経験を通じて力を身につけてきたのかを振り返ってきました。
振り返ってみて気づくのは、どの経験にも「相手がいる」という共通点があることです。サポートの問い合わせにも、対策会議にも、相談会にも、OJT にも、必ず目の前に相手がいて、その相手の反応によって、自分の理解や捉え方が正しかったのかどうかが分かりました。
あくまで私一人の経験からの整理ではありますが、教育の中で人が何を学ぶのかを考える上で、次の要素は共通して大切なのではないかと考えています。
相手のいる課題に取り組む
決められた問題を解くことと、相手のいる課題に取り組むことは、求められるものが違います。
サポートエンジニアの仕事では、お客様から最初に伝えられた内容が、必ずしも本当に解決すべき問題ではありませんでした。相談会でも同じです。聞かれたことに答えるだけでは、相手の仕事が前に進まないことが多くありました。
相手がいると、何を解決すべきかを確かめるところから始まります。そして、自分の考えが合っていたかどうかは、相手の反応で分かります。
学生時代の課題にも、相手を置くことはできると思います。誰かの困りごとを題材にする、答えを受け取る人を想定する、別の学生に説明して理解してもらう。相手が変わると、同じ知識でも伝え方や使い方を変える必要が出てきます。この経験が、条件の違う場面に対応する力につながるのではないかと思います。
説明して、反応を受け取る
専門性の節で書いた通り、私の知識が深まったのは、教材を読んだときではなく、人から相談を受けて説明したときでした。
説明してみると、自分がどこまで理解しているかが分かります。相手が首をかしげれば、自分の理解や伝え方に抜けがあったことになります。質問を受けて答えられなければ、そこが学び直す場所です。
生成 AI に質問して答えを得る学び方は、効率がよい反面、この「説明して反応を受け取る」過程が抜けやすいと感じています。AI に教えてもらったことを、今度は自分が人に説明してみる。その反応から、自分の理解を確かめる。この往復を、学習の中に組み込む意味は大きいのではないかと思います。
問いとゴールを自分で立てる
レポートの章でも触れましたが、課題の大枠があらかじめ決まっていると、何を解決すべきかを自分で決める経験は限られます。
対策会議の節で書いた通り、ビジネスでは、ゴールは最初から明確ではなく、対話の中で設計し、見直していくものでした。今どの範囲の話をしているのか、誰のどの課題を解決するのか、それが共通のゴールになっているのか。それを確かめながら進める経験が、自分の力になってきたと感じています。
学生時代にも、与えられたテーマの中で、自分なりの問いを立てる余地はあると思います。なぜその問いにしたのか、何が分かれば解決と言えるのかを、自分の言葉で説明する。問いを立てるところから本人が関わることで、提出物の出来栄えとは別のところに、学びの手応えが生まれるのではないかと思います。
具体と抽象を行き来し、別の条件で試す
具体と抽象の節で書いたことは、言い換えると「一つの経験を、次の経験で使えるようにする」ことです。
トラブル対応でも相談対応でも、目の前の事象をそのまま覚えるのではなく、なぜそうなったのか、どのような構造の問題なのかを捉え直してきました。そして、次に似た相談を受けたときに、以前の捉え方がどこまで使えて、何を変える必要があるのかを確かめてきました。
この往復は、一度の経験では身につきません。複数の経験を比較し、共通する構造と、結果を左右する条件の違いを考える機会が必要だと思います。
学生時代の学習に置き換えると、同じ考え方を別の条件の課題で使ってみる、二つの事例を比較して何が共通しているかを考える、といった機会がそれにあたります。後述する研究でも、事例を比較することで応用が促されると報告されています。
相手の思いや動機を知る
OJT の話で書いた通り、人の成長を支える上で、私が最も時間をかけてきたのは、相手が何を感じ、何を望んでいるのかを一緒に探すことでした。
少しでも楽しいと思えたことは何か、なぜそう感じたのか。それを掘り下げることで、本人が次に取り組みたいことが見えてきます。上司が喜びそうな目標ではなく、本人の言葉で語れる目標があるかどうかで、その後の取り組み方は変わると感じてきました。
教育の場でも、同じことが言えるのではないかと思います。何を学ぶかを決める前に、本人が何に興味を持ち、何に手応えを感じたのかを知る。それがあって初めて、本人にとって意味のある課題や目標を設定できるのだと思います。成果物の評価だけでは、この部分は見えてきません。
課題のゴールだけでなく、自分自身のゴールを振り返る
前述の「問いとゴールを自分で立てる」は、何らかの課題に対するものでした。もう一つ、学生時代から機会があればよかったと感じているのが、自分の人生や将来の目標そのものについて、振り返り、フィードバックを得る機会です。
私自身、学生時代は特に明確な目標を持っていませんでした。そして、こうした振り返りは、自分一人で自発的にできるものでもなかったように思います。何を考えればよいのかも分からず、考えるきっかけもなかった、というのが正直なところです。
OJT で新人と向き合うときに時間をかけてきたのは、まさにこの部分でした。課題のゴールではなく、本人自身のゴールに対するフィードバックです。何が楽しかったのか、なぜそう感じたのかを問いかけ、対話を重ねることで、本人も気づいていなかった思いが言葉になっていきます。
この経験から振り返ると、自分も学生のうちに、こうしたメンタリングを受ける機会があればよかったと感じています。目標を押し付けられるのではなく、自分が何に手応えを感じ、何を望んでいるのかを、誰かと一緒に掘り下げる機会です。それがあれば、その後の学びや経験の選び方も、少し違っていたかもしれません。
課題に対するフィードバックと、自分自身の目標に対するフィードバック。この二つは別のものですが、どちらも自分一人では回しにくいループだと思います。大学には、ゼミの先生やキャリア支援の担当者など、こうした対話の相手になりうる人がいます。すでにそうした関わりをされている方も多いと思いますが、学びの要素の一つとして、ここにも触れておきたいと思いました。
自己フィードバックと他者フィードバックの両方を回す
ここまで挙げた要素を、別の角度から見ると、フィードバックのループをどう回すか、という話でもあると思っています。
個人的には、このループには二種類あると考えています。一つは、自分で自分の行動を振り返る自己フィードバック。もう一つは、他者とのやり取りの中で生まれる他者フィードバックです。振り返ってみると、自分の場合はこの両方が、それぞれ違う役割を果たしてきました。
自己フィードバック。内省を通じて、次の行動を変える
多様な人との対話の節で書いた通り、経験の数だけでなく、経験から次の行動を変えてきたことが、自分の土台になったと考えています。
対応して終わりにせず、自分の捉え方や関わり方は適切だったのか、なぜその言葉を選んだのかを言語化する。この習慣があったからこそ、うまくいかなかった経験も、次に生かすことができました。
ただ、自己フィードバックには限界もあります。自分の理解の抜けや、自分では気づけない癖は、自分一人で振り返っても見つかりにくいものです。だからこそ、もう一つのループが必要になります。
他者フィードバック。受ける側と、する側の両方
他者フィードバックには、受ける側と、する側の二つの立場があります。
受ける側としては、サポートエンジニア時代の上司や先輩からのレビュー、お客様からの反応、相談会での参加者の質問など、さまざまな形でフィードバックを受けてきました。自分では気づけなかった理解の浅さや、伝え方の問題に気づけたのは、こうした他者からの反応があったからです。
一方で、する側としての経験も、自分にとっては大きなものでした。OJT やメンタリングで相手の成長に関わったり、相談対応やトラブルシューティングでお客様の問題解決に貢献したりする中で、相手に何をどう伝えれば次の行動につながるのかを考え続けてきました。
フィードバックをする側に立つと、相手の状況を理解し、問題を捉え直し、相手に伝わる言葉を選ぶ必要があります。これは、ここまで挙げてきた「相手のいる課題に取り組む」「説明して反応を受け取る」「具体と抽象を行き来する」を、全部まとめて実践する場でもあったと思います。そして、自分がしたフィードバックが相手の行動を変えたかどうかを見ることで、自分の捉え方や伝え方がまた一段と磨かれていきました。
フィードバックに限らず、質問、相談、説明にも「受ける側」と「する側」がある
振り返ってみると、自分の力になったのは、受ける側よりも、する側に回った経験の方が大きかったようにも感じています。相手の状況を理解し、何を伝えれば次の行動につながるのかを考え、伝わる言葉を選ぶ。この過程には、ここまで挙げた要素のほとんどが含まれています。
そして、これはフィードバックに限った話ではありません。質問も、相談も、説明も、同じ構造を持っていると思います。
質問される側に立つと、相手が何に困っているのかを考える必要があります。相談を受ける側に立つと、答えを出す前に背景や目的を確かめる必要があります。説明する側に立つと、相手の理解に合わせて言葉を選ぶ必要があります。いずれも、受ける側にいるだけでは身につきにくい力です。
サポートエンジニア時代の自分は、質問や相談を受ける側に立ち続けていました。講師やメンターとしての自分は、説明やフィードバックをする側に立ち続けています。どちらの立場でも、相手の反応から自分の理解や伝え方を確かめる、というループが回っていました。受ける側とする側の両方に立つことが、他者フィードバックを学びにつなげる上で大切な要素だと考えています。
段階的に負荷を上げる
最後に、これらの経験は、一度に全部を求めるものではないと思っています。
私自身も、最初から問いを立てたり、ゴールを設計したりできたわけではありません。まずは目の前の問い合わせに答えるところから始まり、相談を受ける中で説明する力がつき、やがて問題を捉え直すことや、相手の動機を知ることに時間をかけられるようになっていきました。
本人の力が 1 の段階で、いきなり 7、8 を求めても、本人にも周囲にも負担が大きくなります。まずは 1 から 2、2 から 3 と、本人が自分の力で登れる段階を一つずつ用意する。その積み重ねが、結果として応用の利く力につながるのだと考えています。
学生時代に、どのような経験を積み、何を学ぶとよいのか
ここまでを踏まえると、仮に私が学生に戻ったとした場合、学生時代に経験を積んでおきたいこと、学んでおきたいことは、相手のいる課題に取り組み、対話を通じて問題を定義する経験です。
あらかじめ決められた問題を解く経験に加えて、何を解決すべきなのかを相手と確かめ、方法を考え、取り組んだ結果を振り返る。その過程には、ここまで挙げた多くの力が関わります。
受ける側だけでなく、する側の経験を意識的に積む
学生の場合、フィードバックも、質問も、相談も、説明も、受ける側に立つことが多いと思います。先生から評価を受ける、指摘を受ける、授業で説明を聞く、という形です。
ただ、学びの要素の章で書いた通り、自分の力になったのは、する側に回った経験の方が大きかったと感じています。他の学生の課題にフィードバックをする、質問や相談を受ける、学んだことを誰かに説明する。こうした「する側」の経験を、学生時代から意識的に積んでおくことは、社会に出てからの大きな土台になるのではないかと考えています。
具体的に組み込める機会
例えば、ゼミや共同課題、学生同士の学習支援などでも、次のような機会を意識して組み込めるのではないかと思います。すでに実践されている大学や授業も多いと思いますので、あくまで一つの整理としてご覧ください。
| 経験 | 意識したいこと |
|---|---|
| 学んだことを他者に教える | 相手に伝わる説明を考え、質問から自分の理解不足にも気づく |
| 誰かの相談に乗る | すぐに答えを出す前に、背景、目的、制約を確かめる |
| 複数人で課題に取り組む | 何を解決するか、どこをゴールにするかを話し合う |
| 自分なりの問いを立てる | なぜその問いにしたのか、何が分かれば解決と言えるのかを説明する |
| 複数の経験や事例を比較する | 共通する構造と、結果を左右する条件の違いを考える |
| 条件の異なる場面で試す | 以前の考え方がどこまで使え、何を変える必要があるかを確かめる |
| 自分が手応えを感じたことを掘り下げる | 何が面白かったのか、なぜそう感じたのかを言葉にする |
| 自分自身の目標について対話する | 何に手応えを感じ、何を望んでいるのかを、誰かと一緒に掘り下げる |
| フィードバックを受けて振り返る | 受けた指摘を自分の言葉で捉え直し、次に変えることを決める |
| 他の学生の課題にフィードバックする | 相手の状況を理解し、次の行動につながる伝え方を考える |
具体と抽象の往復については、事例を比較する訓練にも研究上の裏づけがあります。
Gentner ら（2003 年）は、交渉の事例を使った実験で、二つの事例を別々に学ぶ場合よりも、比較して共通構造を見いだす場合に、新しい交渉場面への応用が促されることを示しました。比較を支援することの効果も報告されています。
この研究だけで、実際のビジネス能力全体を説明できるわけではありません。ただ、経験を積む際に、「以前の経験と何が共通し、どこが違うのか」を考える機会を設ける意味はあると思います。
教師やメンターには、そうした比較の観点を示したり、問題の捉え方にフィードバックしたりする役割があります。相談を受けて理解不足に気づいた後、何を学び直せばよいかを支援することもできるでしょう。
こうした学習の中でも、生成 AI を使うことはできます。ただ、AI から得た答えや修正案を受け取って終わるのではなく、なぜその考え方になるのか、自分なら別の場面でどう使うのかまで考える過程が必要だと思います。
大学は、何を評価するのか
ここまでの考えを評価に結びつけるなら、成果物そのものに加えて、その成果物に至る過程と、提出した後の過程を、本人がどう理解し、使えるのかを確かめることが考えられます。
学びの要素の章で整理した内容に沿って、例えば次のような観点です。
問いとゴールについて
- なぜその問いやゴールを設定したのかを説明できるか
- 何が分かれば解決と言えるのかを、自分の言葉で説明できるか
理解と応用について
- 結論に至る根拠や前提を、自分の言葉で説明できるか
- 想定外の質問を受けたときに、必要な確認や考え直しができるか
- 条件を変えた場合に、どこを修正する必要があるかわかるか
- 以前の課題と何が共通し、どこが違うのかを説明できるか
相手のいる場面について
- 相手の理解に合わせて説明を変えられるか
- 他の学生の課題に対して、背景や目的を確かめた上でフィードバックできるか
フィードバックループについて
- フィードバックを受けて、何をなぜ修正したかを説明できるか
- 自分で振り返り、次に何を変えるかを言語化できるか
これは、今回の経験の整理から考えられる評価の案です。口頭試問やゼミでの発表、ピアレビューなど、すでに近いことを行っている場面も多いと思います。科目や育てたい能力によって、適切な方法は変わるでしょう。
成果物の点数と、本人の理解を分けて見る
特に、修正後の成果物だけでは、指摘を AI に渡して直させたのか、本人が理解して修正したのかはわかりません。これは、社会人の資料について書いたことと同じです。
修正の理由を本人の言葉で説明してもらう、条件の違う課題で同じ考え方を使ってもらう、といった機会があれば、成果物の点数とは別に、本人の理解がどこまで進んだのかを確かめやすくなるのではないでしょうか。
受ける側だけでなく、する側も評価に含める
ここまで書いてきた通り、フィードバックや質問、相談、説明は、受ける側だけでなく、する側に立つことで身につく力があります。
評価の対象を、本人が提出した成果物だけに限らず、他の学生に対してどのようなフィードバックや説明をしたのかまで広げることも考えられます。相手の状況を確かめた上で伝えられていたか、相手の次の行動につながる内容だったか。こうした観点は、成果物の出来栄えだけでは見えない力を評価することにつながると思います。
評価を、成長の過程に組み込む
また、評価をつけて終わるだけでなく、その評価やフィードバックを受けて、もう一度取り組む機会を設けることにも意味があると思います。
何を理解していなかったのかに気づき、学び直し、実践してみる。そして、別の条件の課題で同じ考え方を使ってみる。評価も、その成長の過程に組み込めるのではないかと考えています。
一度の提出と一度の評価で完結させるのではなく、自己フィードバックと他者フィードバックの両方のループが回る中で、本人が段階的に力をつけていくことを確かめる。そのような評価の形も、選択肢の一つとしてあるのではないかと思います。
まとめ
今回は、イベントでいただいた「AI が正しい答えを返せる時代に、人が学ぶことの価値は何か」という問いをきっかけに、自分自身の経験を振り返りながら考えてみました。
生成 AI によって、成果物の水準は以前よりも簡単に引き上げられるようになりました。ただ、成果物が良くなったことと、本人が次の場面でも対応できるようになったことは、分けて見る必要があります。
自分の経験を振り返ると、力がついたのは、相手のいる課題に取り組み、説明し、問われ、指摘を受け、考え直す過程を繰り返したことでした。受ける側だけでなく、する側に立った経験も大きなものでした。そして、自分自身の目標についても、誰かと一緒に掘り下げる機会があればよかったと感じています。
何のためにその課題に取り組むのか。成果物を提出した後、何を確かめ、どう学び直すのか。そして、異なる場面でも使えるようになるには、どのような経験を重ねるのか。大学が何を教え、何を評価するかを考える際にも、レポートを作らせることの先にあった目的を確かめ、その力が実際に育つ経験を設計することが大切なのではないかと考えています。
繰り返しになりますが、本記事は教育の専門家ではない一個人の考えです。すでに取り組まれている内容も多いと思いますので、一つの見方として、何かの参考になれば幸いです。