プログラミング教育が低学年化している時代であり、重要な取り組みです。課題解決方針を視覚的に検討させるというアプローチに対しては、査読者から好意的な意見が寄せられました。 一方で、それぞれの査読結果では採否判定コメントにも記載した問題点に加え、提案手法の適用範囲が限定的に思えること、どのレベルの初学者にとって有用な手法なのかが曖昧なことが指摘されました。 今後、例えば Github Copilot のような生成AIを利用しながら、高機能なエディタの支援を受けてコーディングすることが前提となっていくと考えられます。文法に関する正確性よりは、全体の処理手順を組み立てることや、AIが提案したコードを検証しつつ適宜修正する能力が求められると思われますので、今後もぜひ研究を発展させていただきたいと思います。
3: どちらかと言えば不採録
3: 自身の専門分野とマッチしている
プログラミングの初学者に対して、与えられた課題の処理手順を自然言語で検討・試行錯誤させるツールの提案と、予備実験を通じて得られた知見が報告されています。 ・新規性 手順的思考力の評価として、具体的なコードではなく処理の意味を表す日本語を並べ替える手法は提案されています[吉田2017]]が、試行錯誤が可能なシステムとしては実装されていません。プログラムコードの順序を検討させてその内容にアドバイスを表示する先行研究[久野2020]はありますが、syntacticなレベルでのアドバイスを扱っています。類似の先行研究はありますが、本研究の提案には新規性があると思います。 ・有用性、正確性 予備実験で用いた graphical な出力に対しては有用性が高いと思われますが、その他の課題、例えばある条件を満たす数値の組み合わせを求めよ、のようなものに対しても有用なのか、判断できませんでした。 手動で用意された選択肢には、繰り返しの使用を明示（誘導）する記述や、順序性の制約を暗示する記述が巧みに含まれています。特に後者は副作用のある手続きが影響する範囲をよく把握した上で、課題ごとに丁寧に準備する必要があると感じました。これは入門教育の経験を持つ教員が慎重に作成する教材と同等のように思え、LLMによる自動生成を行っても教授者による精密な確認は必要と考えられます。この部分をどのようにカバーするのか、もう少し丁寧な検討が必要です。 ・論文の記述 方針選択とアルゴリズム選択の各フェーズで選択を高速に試行錯誤する、と説明されていますが、具体的にどの表示を見て誤りと判断し、選択し直すのかがうまく読み取れませんでした。図3のような、具体的なコードまで表示されたもので考えるのか、あるいは実際にコードを実行して表示結果まで確認するのでしょうか。 予備実験では、被験者が解決方針を日本語で記述するとの説明がありますが、タップ操作のログ分析ではシステム上で選択肢をタップしているとあります。前者は類題の3問を解く場合、後者は課題の3問を解く場合に対応していると推定しますが、記述が不十分です。
・参考文献
吉田典弘, 堀田龍也, 篠澤和久: "プログラミング教育における手順的思考力に関する評価方法の分析", 情報処理学会研究報告, Vol.2017-CE-141 No.4, pp.1--8, 2017. 久野 靖: "短冊型問題を用いたプログラミング学習アドバイスツール", 情報処理学会 プログラミングシンポジウム 報告集, pp.129--139, 2020.
具体的なコーディングを行う前に、課題解決の方針を自然言語で考えさせるというアプローチは有効であり、重要と考えます。 graphicalな表示を伴う課題以外では自然言語で問題の条件が説明されます。問題文を読み取る部分は、関連研究の章で述べられている「問題を分析するスキル」に関連します。問題文のどの部分から何を読み取り、どのような方針とコーディングに繋げるのかを表示する仕組みがあれば、graphicalな表示を伴わない課題にも対応できるかもしれません。ご検討ください。
3: どちらかと言えば不採録
2: やや専門からは外れる
著者はプログラミング初学者を対象とした、課題の解決方針を立案する能力を高めることを目的とした選択肢タップ式の学習支援システムを提案しています。 プログラミングのコーディングの能力向上ではなく、初学者が学習時に困難としているプログラミングを設計するにあたって脳内で考えているであろう課題解決方針を視覚化しているという点は新規性であり有用であると考えます。 一方で、試行錯誤の高速化を提案事項のひとつに述べているが、予備実験の内容や実験結果と議論の節で記述されている内容のみでは、高速化していることが判断できません。 また、3.1節で述べている設計指針についてはすべて共感できる一方で、学習支援システムとしての提案であれば、システムを用いた後の結果ではなく、システムを用いている間の過程に焦点を当てて、評価すべきと考えます。
採否理由に記述したように、課題解決方針を視覚化しているという点は新規性であり有用であると考えます。 予備実験の結果として、「タップ操作のログ」で記述している内容が学習支援としてはとても重要ではないかと考えます。 学習支援システムであるため、提案システムを利用している過程でユーザはどのような試行錯誤をしていたのかをより詳しく、丁寧に分析をされ、実験結果としてまとめられると有用な論文になるのではないかと思います。
3: どちらかと言えば不採録
1: 専門外である
本論文はプログラミング学習において、プログラミング的思考のみに注目し、コーディングを論文の対象外として支援を行おうとしています。このようにプログラムをどのように組み立てていくかという部分に注目して支援を行おうという試みは大変興味深く、新規性があるように感じました。 ただし、有用性・正確性に問題があると考えています。著者が「初学者」として一括りにしていますが、このシステムが対象とする初学者のレベルが読み取れませんでした。例えば、予備実験で用意しているタスク（絵を描くようなタスク）は初めてプログラミングに触れ合う人に対して与えるようなレベルの物だと感じました。しかし、実験の参加者は1人を除いて授業などでプログラミングを習っています。 そもそも4.1にかかれている「独学や授業での学習経験あり」と「変数や繰り返しなどの?プログラムが実装できる」は排反ではないため、参加者のレベルの記載も分かりづらく感じます。独学と授業も一緒くたに議論されているのも気になります。被験者の情報をよりわかりやすくするために、アンケートで取った内容（のうち公開可能なもの）を表などにして追加してあげると良いように感じました。 このような問題レベルと対象とする初学者レベルの不一致（そもそも対象ユーザが明記されていない）のため、予備実験で行った課題内容が適切であったかに疑問があります。 論文の記述の質について、脱字が認められました。概要の最後の行において「ユーザがをりようすることで」と文字が抜けている場面がありました。 このように、提案手法自体やアプローチについては大変興味深いですが、有用性・正確性には疑問が残るためこのような評価としました。
実験用類題については被験者の回答内容が記述されていますが、プロトタイプで用意した課題に関しては実験結果の記述がなく、不親切に感じます。実験用類題の正答誤答についても議論されていません。例えば4.2の解決方針例2は手続きプログラミング的には間違っている（線を描画する前に色を指定する必要がある）が、この誤答について、論文中で一切触れられていないため、この誤答はシステムによって対応できたはずなのか、それとも別の要因のせいなのかなどの情報を判断することができず、知見としては弱く感じます。 これらの「被験者が課題でどうだったのが類題でどうなったのか」「方針の立案という目線から課題・類題の正答・誤答についてどのような意味を持つのか」などを議論できると良い論文になると思います。すべての被験者でどうだったかを全部書くと紙面が足りなくなると思いますので、提案手法によって救われた1人、2人に絞ってでも上記のような情報があればとてもよい論文になると思いました。
4: どちらかと言えば採録
2: やや専門からは外れる
この能力が育まれることで、言語に依存しないメタな開発実装能力が身につくことが 期待できる。ChatGPTなどの生成AIは出てきていることを踏まえれば、コーディングそのものより課題の解決方針を立案する能力が求められる可能性がある。（これからの）プログラミング能力とは何かを考えるきっかけにもなる可能性がありWISSとして議論してよさそうであると思いました。
具体的なプログラミング言語でのコーディングより前に、自然言語で解決方針・手順を立案することが重要であり、少ない選択肢から選び、誤りに気づいたらすぐ手戻りするという試行錯誤を行う、というアイデアは興味深く、新規性も認められます。 しかしながら、試行錯誤の高速化がどのように達成されているのか、学習者がどのような気づきを得て選択肢を修正するのかが不明瞭なことと、最初に自然言語で検討することをかえって難しく感じてしまう初学者もいるのではないかといったことが査読者間および判定会議で議論となりました。 結果として、本論文は議論枠での採録となりました。発表に当たっては、学習者がどのように選択肢を操作し、どのような表示を見て誤りに気づいて修正するのか、具体的な操作が分かるようにご留意ください。