Integrating AI into Requirements Quality Learning in Software Engineering Education: A TPACK-Guided Empirical Study

あなたは、巨大で複雑なレゴのお城を作っているところだと想像してください。最初のブロックを組み立てる前に、そのお城がどのような見た目になり、どのように機能し、何のためのものなのかを正確に書き留めなければなりません。ソフトウェアの世界では、この執筆フェーズは**要件工学（Requirements Engineering）**と呼ばれます。これは、エンジニアがプログラムに何をさせる必要があるのかを解明するための、設計図の段階です。もし設計図が曖ラスであったり間違っていたりすれば、後でお城全体が崩壊してしまいます。

さて、この設計図をあなたの代わりに即座に書いてくれる、超スマートなロボット助手（生成AI）を想像してみてください。それは速くて創造的ですが、一つ落とし穴があります。もしあなたがロボットにすべての仕事を任せてしまうと、自分自身でお城を建てる「方法」を学ぶことができなくなったり、ロボットの設計図に隠れた欠陥があることに気づけなくなったりするかもしれません。これが、今日の教師たちが直面している大きな問いです。「学生が単なるコピペ野郎にならず、ルールを理解した上で、これらの強力なロボットを活用して学ぶためにはどうすればよいか？」

この問いに答えるために、研究者たちはTPACKという教育用の地図を使います。TPACKを、3つの材料を混ぜ合わせた完璧なレッスンのレシピだと考えてください。それは、コンテンツ（実際の構築ルール）、ペダゴジー（知識を定着させるための教授法）、そしてテクノロジー（ロボットツール）です。目標は、ロボットがあなたの代わりに考えるのではなく、あなたが考えるのを助けるように、これらを混ぜ合わせることです。

---

実験：ロボットのボスになるための学生への指導

タンペレ大学の修士レベルのソフトウェア工学のクラスで、研究者たちはAIを使った新しい方法を試みました。彼らは単に「ここにロボットがいるから、要件を書いて」と言ったのではありません。代わりに、TPACKのレシピに基づいた、学生とAIが従うべき特定の「ダンス」を設計しました。

課題はユーザーストーリー（ユーザーがソフトウェアの機能をどのように使いたいかを記述した短い文章）についてでした。これらのストーリーの品質を確保するために、クラスではINVEST（Independent/独立している、Negotiable/交渉可能である、Valuable/価値がある、Estimable/見積もれる、Small/小さい、Testable/テスト可能である の略）と呼ばれるチェックリストを使用しました。

この「ダンス」は以下のように進みました：

1. 人間が先： 学生は、古い、乱雑な要件を、INVESTチェックリストを用いて優れたユーザーストーリーへと手動で書き換えなければなりませんでした。まだロボットの使用は禁止されています。
2. ロボットが次： 次に、マルチエージェントAIツール（顧客や開発者など、異なる役割を演じる異なる「性格」を持つロボット）を使用して、AI自身のバージョンのストーリーを生成させました。
3. 対決： 学生は、自分たちが書いたストーリーと、ロボットが書いたストーリーを比較しなければなりませんでした。どちらのストーリーがより優れているかを判断し、ロボットの成果物を編集し、その理由を説明する必要がありました。
4. ピアレビュー： 最後に、学生は作成したものをクラスメートと交換し、同じチェックリストを使って互いに採点しました。

分かったこと：ロボットは代行者ではなく、助手である

研究は、参加した72人の学生を対象に行われました。彼らがAIとパートナーシップを組んだとき、何が起きたのでしょうか。

1. 学生は単に「すべて承認」ボタンを押さなかった
もしロボットが単なる魔法のボタンであれば、学生はそれが書いたものをすべて受け入れていたでしょう。しかし、そうはなりませんでした。学生は非常に選り好みをしました。平均して、ロボットは学生一人につき約16.5個のユーザーストーリーを生成しましたが、学生はそれらのうち約9.5個しか承認しませんでした。承認率は**56%**でした。

• 比喩： これは、ロボットシェフにピザを注文するようなものです。ロボットは16枚のピザを作りますが、チーズが多すぎたりトッピングが間違っていたりするため、あなたは9枚しか受け取りません。あなたはロボットではなく、味のテスターなのです。
• 行動： 約**24%**の学生が、明示的にロボットの出力内容を編集しており、ほとんどの学生が少なくとも一回はストーリーを洗練させるプロセスを経ました。彼らはAIを最終的な解決策としてではなく、ドラフト（下書き）生成器として扱いました。

2. ロボットは得意なこともあるが、苦手なこともある
研究者が、AIを使用する前と後で、学生が品質ルール（INVESTチェックリスト）をどの程度理解していたかを調査したところ、分かれた結果が出ました。

• 勝利： 学生は、テスト可能（テストで確認できること）および価値がある（実際に有用であること）というストーリーを見抜く能力が向上しました。ロボットはこれらの部分をより明確にする助けとなりました。
• 微妙な結果： 交渉可能（議論を通じて変更できること）という品質については、奇妙な結果が出ました。学生は、ロボットがこの理解を助けてくれたと「感じて」はいましたが、彼らの回答を教師の「正解」と照らし合わせたところ、スコアは実際にはわずかに低下していました。
• 教訓： ロボットは、構造化したり明確にしたりすること（文法の修正など）には優れていますが、人間が何を求めているかを推測しなければならない、ソフトウェア設計における「曖昧で人間的な部分」には苦戦します。

3. 信じる、しかし検証する
ツールについての感想を聞くと、学生たちは慎重ながらも楽観的でした。

• 有用性： ほとんどの学生が、ロボットがアイデアを生み出し、詳細を追加するのに役立ったと同意しました。ある学生は、ロボットが「構造化された言語」と「より明確な受け入れ条件」を与えてくれたと述べています。
• 信頼： 彼らは盲目的に信頼することはありませんでした。約14人の学生が、ルールに基づいて積極的にロボットの仕事をチェックしたと答え、10人が明確にロボットのアイデアを拒否または異議を唱えました。
• 難点： 一部の学生は、ロボットのインターフェースが少し使いにくいと感じ、また、ロボットが（例えばプロジェクトがドローン配送に関するものなのにドローン配送の機能を提案するなど）具体的でない回答や、プロジェクトに適合しない回答を出すことがあったと指摘しました。

大きな教訓

この研究は、教育におけるAIの使い方の秘訣は、単にクールなツールを持つことではなく、「どのように使うか」にあることを示唆しています。

もし学生にAIを最初に使わせれば、彼らは答えをコピーするだけになってしまうかもしれません。しかし、もし彼らに先に「難しい思考」を強制し、その後にAIを「セカンドオピニオン」として比較・洗練のために使わせれば、AIは強力な学習パートナーになります。この研究の学生たちは、怠惰になったのではなく、**エディター（編集者）**になったのです。彼らはロボットのミスを見つけ、その強みを利用して自分の成果物を改善する方法を学びました。

ただし、研究者たちはこれが魔法の解決策ではないと警告しています。ロボットは依然として、ソフトウェア要件の「曖昧な」部分に対して混乱することがあります。したがって、教師は注意深くある必要があります。明確で構造的な学習の部分にはAIを活用すべきですが、難解で解釈が必要な部分については、人間の教師が介入して導く必要があります。

要するに、ロボットは素晴らしい副操縦士ですが、学生はしっかりとハンドルを握っていなければならないのです。