プログラミングに「正解」はない

プログラミング研修の講師をやっていて、返答に困ってしまう質問のひとつに「このプログラム、これで合っていますか？」というものがあります。

テキストを見ながら演習問題のプログラムを書いてみた。実行したら一応演習問題で指定された結果が出たように見える。でもこの自分で書いたプログラムは回答例とぴったり一緒なワケでもないし本当に正解なのかどうか分からない。

きっとこの質問をされる多くの方はそんなことを考えての「このプログラム、これで合っていますか？」なのではないかと思います。（中には実行してみる前に質問される方もいらっしゃいますが、、）

ここで問題になるのが、そして困ってしまう原因となるのが、プログラムに「正解」なんてものは存在しない、ということです。講師はそのプログラムが合っているかどうかの質問に答える前に、まずこのことを質問者に理解していただく必要があります。

プログラムはいろんな観点で評価される

プログラムは最終的にそのシステムを利用するユーザーの要求を満たすための手段のひとつです。そのため、ユーザーが要望した通りに動いていさえすればそれはそれでひとつの「正解」と言えなくはないかもしれません。

しかし、プログラムは一度書いて終わりではなく、その後も機能追加や仕様変更による修正が入ることがほとんどです。もしかしたらその修正を入れるのは最初に作った人とは全く違う人たちかもしれません。プログラムには不具合がつきものですので、それを素早く見つけて素早く修正できることも大切です。

ということを踏まえると、「ユーザーの要求を満たしているかどうか」だけでなく修正のしやすさや理解のしやすさ、動作の軽快さなど、プログラムは様々な切り口で評価されるのが通常です。そしてその評価に上限はありません。

言い換えると、プログラムの評価は「正解」か「間違い」かのゼロイチではなく、10点か、30点か、100点か、400点か、それよりもっとか、という上限のない点数制のようなものなのです。さらにその点数の基準も時と場合によって様々です。

ここまで書けば、「このプログラム、これで合っていますか？」に対する答え方が難しい理由が見えてくるのではないでしょうか。

確かに演習問題としては結果が出ている以上これでOKと言えます。一方で研修としては拡張性や読みやすさ、バグの少なさなどにも言及したくなり、さらにそのどれに言及するかもその人がその観点をどれだけ意識できているかによって変わってきます。その質疑応答にどれだけの時間が使えるかにもよるでしょう。

他の書き方との違いに着目する

正解かどうかではなく、「こう考えてこう書いたら回答例とここが違っていたんですけど、どう違うんでしょうか？」というように他の書き方の違いに着目した質問はとても効果的です。

先述した通り、プログラムは読みやすさやバグの入りにくさ、処理効率など様々な観点で評価され、そのどれが重視されるかは要件によって様々です。

読みやすい書き方、効率的な書き方、一貫性など、どう書いたらどれが良くなってどれが悪くなるのか、それはなぜなのか、ということを考えながらプログラミングを学習することは研修が終わって仕事で書くプログラムの質を高めるためにとても重要です。

まずは変数名を変えるだけでも良いので、回答例とは違った書き方でも同じように動作するプログラムが書けることを身を以て体験し、その次の段階としてその違いがどの要素にどう影響を与えるのかを考えてみましょう。そしてチャンスがあれば講師や先輩に聞いてみましょう。そこまで考えた上での質問であれば「正しいですか？」という聞き方にはならないはずです。

まとめ

プログラミング初学者がハマりやすい罠として、「プログラムには正解があり、それ以外の記述をしたら完成とは言えない」と思い込んでしまうことが挙げられます。おそらく最初の「このプログラム、これで合っていますか？」という質問の背景にはそのような誤解があるのだと思います。

しかしこの記事に書いた通り、プログラムにはそもそも絶対的な「完成」はなく、そのために「正解」なんてものもありません。要件通りに動いた段階で一度リリースや納品をすることはできますが、その後も修正を入れることがほとんどであり、そのときの修正しやすさはプログラムの工夫次第です。

そしてその工夫に決まったやり方はありません。「プログラミング学習は「覚える」のではなく「アイデア」を増やそう」の記事でも書いたような「アイデアの引き出し」を増やして、「このアイデアを取り入れると読みやすくなる」「こっちのアイデアだとバグが減りそう」というのを日々試行錯誤するのが大切です。

「正解かどうか」を気にしてしまう方は、まずは「プログラムに正解なんてない」ことを理解し、その上で、「このプログラム、こう考えてこう書いてみたんですけど、この回答例と比べてどうでしょうか？」のように「考えて」「書いてみて」「比較する」ような考え方が習慣づけられると、学習した内容がそのまま実際の開発現場でも活きるようになるでしょう。