コンピュータの学科に所属するからには，「プログラムが組めるようになりたい!」と思っているはずです．
しかし，2度，演習室で授業を実施してみましたが，こちらが用意したプログラムを打ち込むだけで果たして組めるようになるのか，と思っている人も，きっといることでしょう．
ということでこれから，プログラミング能力についての，ちょっとした心がまえについて，話してみたいと思います．
不安
プログラミング能力は，こうすれば必ずアップする…というものはどうもなさそうです．あれば教員がそれを学生に徹底すればいいのですが，なかなかそうはいきません．
そこで反対から考えてみます．「プログラミング能力の向上を阻害するものは何か?」です．一言でいうと，『不安』です．
できればここで，みなさんからアンケートをとって，集計するといいのですが，時間の都合で，こちらで，演習時間や研究室の中で見聞きしたことのある不安要素を，並べてみましょう．
- 思ったように，書けない
- 原因不明のバグのため，時間までに完了できない
- 試験に受かったからといって，思うように組めるわけではない
- C言語だけで，いいのか
- 研究室に入って，就職活動で，就職して，自分の能力で大丈夫だろうか
思い当たるところ，ありますか?
バグは，厄介ですね．演習室では，こちらで用意した，一字一句正しく打って正しいコマンドでコンパイルすればちゃんと動くというものでも，大量のコンパイルエラーだとか，予期しないセグメンテーション違反だとかで，私にヘルプを求めた学生が何人か，いました．自分でコードを書くとなったら，救助役がいない状態で，前進しなければなりませんからね*1．
できる人を観察する
では順に，対策を考えていきますか．
まず“思ったように，書けない”についてですが，ここも逆転の発想で，「思ったように，書いている」人を観察してみるのはどうでしょうか．学科にいますよね．と言っても私自身はどなたなのか，分かっていません．2年後期の演習を見ていると，ああこの人が，この学年の「目」，中心的存在なんだなと思うことがあります，そういう学生は，演習も，3年前期の私の講義も優をとり，そして十中八九，研究室配属では私のところにやってきませんけどね．
もしそんな人がいなければ，しょうがないので，教員，具体的には私がプログラミングに関して普段何を考えているんだろうと思ってください．
そんな「できる人」も，日常バグに悩まされているのです．真にできる人はともかくとして．
バグや正体不明のトラブルも多いけれど，「うまくいった」という成功経験も多いのです．だから「ん?」と思ったときには，「こうやったらいいかな」という方法をいろいろ試し，何らかの方法でうまくいったら「やったあ」となります．
成功経験の多さは，トラブルに直面したときに，「まあいけるやろ」という前向きな姿勢で現れます．「思ったように，書けない」という人は，トラブルに遭遇したら「あかん，やり直そう」という，勇気も根拠もない撤退路線をとって，時間と，トラブルにあったという経験を，無駄にしているのではないでしょうか．
あともう一つ，「できる人」は，自分の経験，自分の頭の中だけに頼りません．Webや書籍をよく参照します．とりわけプログラミングなど計算機を相手にする活動においては，記憶より記録のほうが的確なのです．ここでいう的確というのは，書かれていることが100%正しい，自分の記憶はあやふやだ，という意味ではなくですね…
ムダを減らして快適プログラミングを!
先ほど言った「試す」ときに，試してから結果が出るまでの時間を，より短くできるのです．迷い道くねくね*2よりも，まっすぐ走るほうが，時間が短くて済むのです．1個のトライアルに要する時間が短ければ，よりたくさんのトライアルを実施できるわけで，なので時間短縮につながります．
キーワードは「ムダを減らすこと」です．ムダなことをしていないか，普段の自分の行動を観察してみてください．朝起きて，ぼおっとして，我に返って洗面所に行き，歯を磨いて口をすすいで，顔を洗ってタオルで拭いて…なんてのでもいいのですが，とりあえずプログラミングに的を絞りましょう．
プログラミングのサイクルというのは，2段階に分かれます．一応コンパイルができる状態までコードを書き上げたのをスタート地点として，コンパイルする，エラーが出るのを知る，テキストエディタでバグを取り除く，というのが1段階目のサイクルですね．そしてコンパイルが通り，実行ファイルができたら，それを実行して，期待するのと違う挙動や出力なのに気づき，テキストエディタでその論理エラーを取り除く，という作業が，2段階目のサイクルとして入ってきます．論理エラーを取り除いたはずが，コンパイルするとエラーになるので，コードを再修正というのも，よくあることです．
この2つのサイクルそのものを取り除こう，というのではなく，サイクル1回に要する時間を減らして，より短時間で，プログラムが完成させましょうと言いたいのです．
コンパイルにせよコマンド実行にせよ，毎回1文字1文字打ち込んでいるのは，非効率です．シェルのヒストリ機能，代表的なのは上矢印キーを使えば，タイピング数が減ります．
また，テキストエディタでエラー箇所を発見するのにも，小さなノウハウを知っているのと知らないのとでは，効率が異なってきます．Emacsなら，特定の行番号に飛べますか? C-s（コントロール・エス）を使ってインクリメンタルサーチができますか? これらの機能，ではなく技能は，コンパイルエラーが発生したときに，そのメッセージの中の行番号や識別子から，バグのありそうな場所を特定するのに役立ちます．
論理エラーについては，具体的にどこが悪いと教えてくれませんが，gdbの利用や，デバッグライトといった手法によって，原因を絞り込む方法が知られています．
やみくもに，ソースファイルの最初から最後までを読み直すよりは，正解を見つけやすいと言えるでしょう．
ということで，“原因不明のバグのため，時間までに完了できない”の対策を，説明しました．
正解か不正解か，成功か不成功か
次に挙げたのは，“試験に受かったからといって，思うように組めるわけではない”でしたね．
そうですね，これは，試験で求めるものと，プログラミングで求めるものを，分けて考えることにしましょう．
試験は何のために受けますか? って聞くまでもなく，合格したいからですね．大学の科目では，試験その他で不合格になったら，次の年度も最初から受け直しとなります．大学入試もそうで，高校3年のときにセンター試験でいい点をとったけど入試は落ちた，次の年はそのいい点を使って2次試験を受けたい，という主張は通りません．
試験で合格するためには，一つ一つの問題で正解を答える必要があります．本日配布したおさらい問題を，ちょっと見てほしいのですが，いろいろな形式で設問を用意していますが，1問1点の2択問題にも，空欄適語問題にも，30点の論述問題にも，共通点があります．
それは，隠された「正解を引き出す」という作業をしてもらうことです．
試験は，限定された時間と場所で「正解」を見つける作業だと思うのがいいでしょう．その正解が十分に蓄積されているのが，答案から確認できれば，60点以上となって合格．そうでなければ不合格です．
さて，プログラミングは，どうでしょう?
…こちらは，正解・不正解よりも，成功・不成功で考えるのが，いいのではないでしょうか．
試験にちょっとだけ戻しますが，とくに選択式の問題は，一つだけが正解，残りは不正解で，それを見抜くことが要求されます．一方，プログラミングでは，これを選んでも成功，あれを選んでも成功，なのです．まあ，こちらを選べばどう頑張っても失敗，というのもあったりするのですが．
たくさんある「成功の道筋」の中で…といってもその道筋がまだプログラムコードとして形になっていない状態で…どれを選んでコードにするかが，問われているのです．
どれを選ぶかというのは，成功に至るまでの時間が短いものでもいいでしょうし，自分の力をつけるためにイバラの道を進むだとか，保守性に優れているだとかいった観点でも，選ぶことができます．ここで保守性とは，プログラムコードは1回書いたら終わりというものでは決してなく，バグが発生したときにソースファイルを見直さないといけないわけで，そういう見直し作業を効率良く行うための手法・作法・心がけだと思ってください．
学年が上がってくると，このように，正解・不正解で考えるよりも，成功・不成功で考える機会が，増えてきます．まず，失敗の道を選んではいけません．じゃあ何でもいいから一つ，成功の道を進めばいいのかというとそうではなく，一つの「成功」というゴールに向けられた，いくつも考えられる道筋の中から，一つを選び，自分が納得し，先生など周囲の人にも理解してもらえるように，していきたいものです．
成功・失敗について，知っておいてほしいことが，あと二つあります．「失敗してはいけないところで，失敗しないこと」と「失敗しても，ダメージを最小限に抑えること」です．理由はありません．でもこれらの人生訓，役に立つことがきっとあるでしょう．
なぜCを学ぶか
クエスチョンとソリューションを，進めましょうか．次は…“C言語だけで，いいのか”ですね．
研究室でCを使う可能性は，うんと少ないですね．うちの研究室で，何年かに一度，事情があって開発期間が短く，ツールを学ぶよりも自作する方が成功率が高いだという学生が，Cを選んでいることがあります．そういえば，学科内で一番進んでいる研究室の一つは，Visual C++，俗に言うブイシーが使えないと話にならないとおっしゃっていました．
C言語って，いろいろと不自由な言語です．一例を挙げると，文字列の扱いですね．文字列の中の一部を書き換えたいときに，書き換え前と後の字数が同じなら，まあ苦労も少ないのですが，長さが違っていたら，順繰りでコピーの処理をする必要に迫られます．Perlなど，Lightweight Languageと呼ばれる言語では，文字列の書き換えはもちろん，切断だとか連結だとかも，いとも簡単にやってくれます．
しかしそれでも，1年後期のプログラミングの授業で，Cの文法や，使う際のルールなどを学ぶ意義は，十分にあります．
プログラムというのは，「したいこと」と「その結果」の架け橋のようなものです．これこれこんな処理をしたいから，かくかくしかじかのコードを書いた，だとか．このコードは，こういう意味になるから，本当にしたいことと違うよね，だとか．
しかしこれは，十分にプログラミングに慣れた人だから言えることなのです．私たちは，そこにワンクッションを置きましょう．「どう書けば，どうなって，どうなる」の流れで考えるのです．
ここで「どうなって」のことを，動作原理といいます．
Cを通じて，「どう書けば，どうなって，どうなる」という形でプログラムコードの挙動を日本語で表す勉強・訓練は，2年以降になって，複雑なCのコードを…自分で書いたにせよ，先生かどなたかからもらうにせよですね…短時間で理解し，先生ほかにトラブル状況を説明するときの，下地になります．もちろんそのスキルは，他の言語を学ぶときにも，大いに役立ちます．
試験では，「どう書けば，どうなって，どうなる」の一つ以上を隠した状態で，それを解答してもらうような問題を出す予定です．少々難しいけれど，プログラミングにも研究にも応用できるのが，「どうなって」を見つける作業です．授業資料を，読み直してみてくださいね．
学ぼう 学ぼう 私は元気
いよいよ，最後の不安です．“研究室に入って，就職活動で，就職して，自分の能力で大丈夫だろうか”でしたね．
これは，「今の」自分の能力ではダメじゃないの，と突き放した答え方をするのが，いいのかもしれません．
「今の」じゃなくて，あなたが必要とされるときに，能力が遺憾なく発揮できるように，準備をしたいものです．
どんな能力がいるか，分からない，ですか? そうですね．
「能力」という言葉が悪かったのかもしれません．ちょっと学んで，2，3回練習でもすれば，身につくかのような，世の中で必要とされている技能とは，質的に異なるものを，大学生活を通じて身につけてほしいのですが，しかしこれも具体性に乏しいなあ…．
大学1年生のうちから，習慣づけてほしいことは，「常に学ぶ」ことです．学科の，高度で専門的なことばかりでなくてかまいません．まあ，専門的なことを一切理解しようとせずに，合格しようというのは，甘い考えですけどね．
授業の教科書でも，新聞でも，新刊の本でも，かまいません．読んで，その内容を自分の頭でよく考えることが，学ぶことの第一歩です．書かれたものというのは，作者や編集者が，どういう表現をとればより多くの人に理解してもらえるだろうと呻吟して，ゴーサインが出て，最終的に出版されたのです．他愛もないおしゃべりや，ネット上の情報とは，内容の信頼度，濃密度が違うのです．
そして，読んで考える習慣を「いつも」行うことが大事です．週1回では，少なすぎます．新聞なら朝刊ですね．本なら，短時間で集中して1冊を読み終えるよりは，1冊の本を，通学中だとか授業の休み時間だとかに細切れに読んでいき，数日で読み終えるスタイルのほうが，本から学ぶやり方としてはおすすめです．
資格をとろうと決意し，合格あるいは認定のために，勉強するというのも，いいことですね．
そうすると，新たな疑問が出てきますか．はい，本とか，人が書いたことばかり読んでいて，プログラミングできるのか，ですか?
授業以外でもプログラムを組んでみるのは，どうでしょうか．
まとめ
- 思ったように，書けない →→ 「思ったように，書いている」人を観察する
- 原因不明のバグのため，時間までに完了できない →→ ムダを減らす
- 試験に受かったからといって，思うように組めるわけではない →→ 正解・不正解ではなく，成功・不成功で考える
- C言語だけで，いいのか →→ 動作原理を学び，日本語で表す
- 研究室に入って，就職活動で，就職して，自分の能力で大丈夫だろうか →→ 常に学ぶ
これは何?
本日のエントリは，2010年2月1日の授業中に話した内容の再現を試みたものです．
基本的に講義室での座学ですが，一つ前の週の授業は，演習室で，用意しておいたプログラムを打ち込み，動作確認をして（人によっては打ち込みミスに起因するコンパイルエラーに対処し），こちらの解説ののち，どんなプログラムなのかを記述してもらいました．この形式は11月30日にも実施しており，その翌日にプログラミング授業にBRD - わさっきというのを書きました．
「おさらい問題」というのは，試験と同じ形式の練習問題です．前の年度ですが，レポート課題（文脈自由文法をCで） - わさっきで少し触れています．
（同日18時台に，エントリのタイトルを「プログラミング能力の心がまえ」から「プログラミング能力アップのために」に変更しました．本文も，あちこち変更しました．）
