学科内のある文書で「学生はプログラムが書けない」という記述を見かけまして，それに対してプログラミング科目を3つ受け持っている自分として，何らかの回答をしないといけないかなと，一時期，考えてみたものの，どうやらその必要はなくなったようで，それでも考えたことを，ここに残しておきます．
まず，どんなシチュエーションで「学生はプログラムが書けない」という発言が出たのか，思い出しますと…それは研究室に配属された，学生のプログラミング能力についてでした．
ところで私自身は，その主張には大反対です．研究室で行うコーディングやシステム構築は，期末試験や演習の課題と異なり，あらかじめ教員が決めておいた仕様に合ったプログラムを一人で書くものではない，という信念があるからです．技術力の確認や，これから何を学習していくべきかの把握・共有のため*1，「プログラムを作ってみてくれるか」と課題を与えることはあってもいいのですが，解くための技法などの調査*2や，実行環境のセットアップの時間は，とりたいものです．課題の本質でないところの相談は，先輩に聞くことを含め，学生間で交わしても，差し支えないでしょう．ともあれ…
冷静になって，学生対策を文字にしていきますか．学生にとって，「プログラムが書けない」典型的な状況を，いくつか挙げてみます．
- 入学直後
- 授業中
- 長期休暇後
- 研究室配属時
一つ一つ，見ていきます．「入学直後」は，それこそ高校時代からプログラミング*3に親しんでいた学生も少ないながらいますが，大半は入学してから学びます．
“プログラミングとは何か”を学習する科目が1年前期に2科目あり，一つは情報リテラシーの科目で，シラバスを読んでみると，HTMLとLaTeXが入っています．もう一つはCの科目で，「計算の原理」「手続き設計」が，シラバスに盛り込まれています．両先生ともこれまでのご指導の蓄積がありますので，新入生の不安はそれらの授業で，解消されているのでしょう．
次に，「授業中」というのは，特定のプログラミング課題に手も足も出ず，それ以降の課題に進めずそこでドロップアウト，の流れを念頭に置いています．
これに関して，学科内でこれまで実施しているのは「スタッフの増強」「面談の導入」「課題の細分化」です．
スタッフにはティーチングアシスタントも含まれますが，科目によっては担当教員を増やしているところもあります．しかしスタッフが演習室をくまなく巡回しても，質問しない学生がいるのは事実でして，中間チェックに面談を入れることで，ドロップアウトの可能性を減らせますし，副作用として，課題の難しさを授業終了後ではなくその途中に知ることができます．
課題そのものを安易に易化してしまうと，終了までに身につけるべき能力が低下してしまってよくありませんので，代わりに，大きな課題の中に小さな課題を入れる試みがなされています（私も実施しています）．ただし，課題が進むにつれて学生の裁量といいますか自主性の度合いを大きくすべきでしょうね．
授業中は力作を作っていたのに，「長期休暇後」にその技術やノウハウを忘れてしまうということは，たしか『Cプログラミング入門以前』にも記述があったはずです．
対策は立てにくいのですが，「前のセメスターの学習内容を思い出させる」ことと「これまでの学習がなかったとしても，解いていけるよう，課題を組み立てる」という，正反対の2つをうまく組み合わせることかなと思っています．
2年後期の自分の担当では，最初の課題で「通信プログラム」としているのですが，コンパイルと実行の方法を実演しているのは，この2点の折り合いともいえます．ちなみに遅刻者や初回欠席者のため，その手順は文書化しています．
最後，「研究室配属時」に判明する“書けない”ですが…研究室で独自の学習ルートを作るのが最善解のように思います．
プログラミング以外の要素も取り入れ，卒業研究に入るまでに身につけておくべきとして，研究室内学習カリキュラムを策定している研究室があると聞きます．
私の研究室では，3年ゼミ（DBゼミ）で，まず設計，そして実装とし，設計のゼミ発表時には，「それで出来上がりはどんなになるんだろう?」「これこれを取得するSQL文は書けそうですか?」といった質問を投げかけるようにしています．
昔書いたこと：
