１．時間制限がある。
より早くプログラムを書く事が求められます。確かにビジネスにおいて「早い」事は重要かも知れません。仕事には必ず納期があり、いくら良いものが出来たとしても、期日に間に合わなければ無価値になってしまうのも事実ではあります。そして、多くのプログラマは納期までの期間が短いせいで、満足が行くものが作れていないと嘆く事は常でしょう。
しかし次の例を比べてみてください。
・プログラムは早く書き上げたけれども、コードは汚くて目も当てられない。
・プログラムを書くのに時間はかかったけれども、コードはきれいで読みやすい。
どちらのエンジニアが優秀だと思いますか。あるいは、あなたはどちらのエンジニアと一緒に仕事がしたいと思いますか。
２．提出は一度しか許されない（あるいは再提出はペナルティがある）
プログラミングに置いて昨今では、インクリメンタル開発、スパイラル型開発、アジャイル等、TDD型など呼び方はいろいろありますが、書いたコードが一発で合格するなどありえないのです。例えば TDD では最初は「すべてエラー」が出る状態から始まり、最終的に「すべてノーマル」になるまで何度も何度もテストをします。そもそもテストを最終的に一回しかしないのなら、TDD など無駄なのです。何度も何度も繰り返しテストするからこそ、TDD はその真価を発揮するわけです。また、Smalltalk 言語においてはコードが完成するまえにわざとエラーを起こしてデバッガーを起動し、デバッガー上でプログラムを書いていくというプログラミングスタイルをする人が大勢いたりします。確かに一発で完璧なコードを書き、すべてのテストケースを合格できる人は超がつくぐらい優秀かも知れません。しかし実際の現場では、そのようなスタイルでプログラミングする人はまず居ません。少しコードを書いてはテストし、また少しコードを書いてはテストしを繰り返してトライ＆エラーでプログラムを書く人がほとんどで、その方が結果的に開発期間を短縮できるのです。開発する規模が大きくなればなるほどその傾向は顕著になります。
３．デバッグができない
これは先の提出は一度きりにも通じるのですが、一度にすべてのコードを完璧に書ききる事ができる人なんてまず居ません。開発規模が大きくなればなおさらです。多くの競技プログラミングではテストデータは開示されませんし、そのプログラマーが実際の動作を見ながらプログラムを修正するスキルがどの程度なのか等を測る手段はありません。
早く解ければ本当に優秀か
というわけで、プログラミングというのは早く書ければ良いという、そんな簡単なモンじゃないですよって事を言いたいワケです。普段インクリメンタル開発*1をしている人は、一度に完全なコードを書ききるなんてまず無理なので、当然成績は悪くなります。で、そういう人は点数が悪くなるわけですが、優秀では無いと切り捨てるのでしょうか。ビジネス上、早さって重要なファクターなのでしょうが、もうちょっと SonarQube のような静的解析ツールとかソフトウェアメトリクスツール等を使って、提出コードを解析してもっと客観的な指標で評価するぐらいの事をすればもっと面白くなるのにと思います。
競技プログラミングで良い点を取るために自分のプログラミングスタイルを曲げるつもりはありません。実際の現場のやり方にも合わないですし意味がある事とは思えません。最後に自分が大好きな格言で締めくくりたいと思います。
デザインとは、フォルム（形）の実現にあるのではなく、ミスフィット（ぴったりしないもの）の排除にある。ーーChristopher Alexander（建築家）
*1:ちびちびコードを書いちゃテストを繰り返す
