わさっきhb

大学(教育研究)とか ,親馬鹿とか,和歌山とか,とか,とか.

プログラミング課題完了までの成長曲線

「本日で,この演習科目の前半,そして,私が用意した課題は終了となります.そこでこれまでの振り返りの一つとして,みなさんの課題実施の状況や,私自身のプログラミング経験などをもとに,図を作成してみました」

「『プログラミング課題完了までの成長曲線』です.横軸は時間の経過を表します.縦軸は成果物の品質です.プログラミング課題において成果物とは,プログラムコードのことです.縦軸は,答案に対して教員がつける点数,と思ってくれてもかまいません.
開始の時点では,原点のゼロ・ゼロです.活動を進めていくと,成果ができていくわけなので,右上がり,と言いたいのですが,単調な右上がりではありません.
2つ,変化のしかたが変わっている箇所があります.これについて,情報をつけ加えますと…」

「活動の期間を,大きく3つに分けることができます.まずは左の3分の1で,これは,課題が与えられて,どんなプログラムを作らないといけないか,関連情報を収集し,おおよそどんなコードを書いていけば完成できそうかなと,方針を決定する期間です.
課題が複雑になると,いきなりコーディングとはいきません.ですので,準備の期間も大事です.
この期間はコードがないので,『成果物の品質』はゼロと見なすことも,できますが,得た情報や設定した方針を文章化して提出すれば,教員側もそれなりに活動状況を判断できますので,緩やかながら右上がりの直線にしています.
とはいうものの,プログラミングで,一番『作っている』感があるのは,やはり,コーディングです.ここでは『実装』と書きましたが同じ意味です.実装のことを英語ではimplementation(インプリメンテーション)と言い,動詞はimplementです.この段階は,完成めがけて,がしがしコードを書いていくことになります.
実際の作業では,情報収集・方針決定の段階でも,実装の段階でも,途中で取捨選択だとか,不要な記述やコードの削除を,随時,行っていくわけですので,そこを考慮すると,線形に伸びていくとは限りませんが,概念図なので真っ直ぐ右上がりなんだ,と理解してください.
実装の段階が終わるというのは,プログラミング課題においては,『一応動くものができた』状態,と言うことができます.
なのですが,とりあえず動いたものの,出力の並べ方が不自然だったり,インデントや空行などソースの書き方が整理できていなかったり,少しコードを変えるだけで,実行時間をうんと短くできたり,といった状況のことがよくあります.
そこで手を加えて,完成度を高めます.これが『磨き上げ』です.ブラッシュアップとも呼ばれます.はじめのうちは,実装と同じ傾きで,かける時間に応じて品質も上がりますが,磨き上げの段階ではしばらくすると,傾きが小さくなり,生産性が上がらなくなるように見えます.頭打ち,というやつです.完璧なプログラムコードというのは,難しいのです.
このように,みんながみんな,この折れ線のとおりに作業を行い,タイムアップのところで答案を提出してくれればいいのですが,提出された答案を順に読みますと,そこまで至っていないなというのも,よく見かけます.その残念な典型例の1つは,『時間不足』です」

「情報収集に時間をかけすぎて,実装や磨き上げの時間もままならず,時間が来たから提出,というパターンです.しばしば,『一応動くものができた』状態になっていません.努力は認めるにしても,合格点に届かない可能性だってあります.
残念なパターンには,もう1つあります.『出来上がったので提出』です」

「情報収集と,方針決定は,しました.実装も,しました.『一応動くものができた』状態に,到達しました.そして…
その『一応動くものができた』段階の,プログラムを提出して,課題はおしまい,としてしまっているのです.
答案を見て,もうひと手間,加えてくれたらなあと思うこともよくあります.合格点には届いていますが,100点満点でいうと,70点くらいの水準,でしょうか.授業科目だと,答案を一つ一つ読んでそれぞれに点数をつけますが,何人,何十人と応募する中から選ぶという,コンテストなんかだったら,詰めが甘いとして予備審査で落とされるかもしれません*1
授業に話を戻しましょう.限られた授業時間で,効率良く作業を行い,単に『できた』『できなかった』ではなく,自分が納得でき,先生にも喜んで読んでもらえるような,答案すなわちプログラムコードの提出を,心がけてください.
ところで,今回紹介した『プログラミング課題完了までの成長曲線』は,私自身のプログラミング経験や演習実施の状況をもとに作成したもので,実証的というよりは概念的なものです.
ただ,まったく何もない状態から思いついた,というわけでもなく,ソフトウェア開発の分野では,横軸に時間,縦軸に累積バグ発見数などをとった,『信頼度成長曲線』が知られています.右上がりですが決してまっすぐではなく,時間をかければ傾きが小さくなるのも共通しています.ソフトウェア工学の授業で,きちんと学んでください」

*1:論文の査読や優秀賞の選考に携わる際にも,ここに配慮があれば,と感じることがあります.磨き上げは,論文の信頼性向上につながります.本記事のはじめに「私自身のプログラミング経験」と書きましたが,これは授業の学生向けの言い方であって,論文を書いたり,審査したりしたときの経験も,少なからず含まれている話(そういう観点からも,学生に知ってもらいたいこと)なのです.