趣味プログラマがプロで仕事するために足りないもの

ことプログラミングの世界においては、その実力は圧倒的に趣味プログラマのほうが、底辺から並にかけてのプロなんかよりも遥かに上と断言できます。もしあなたが、自分の実力は現場で通用するのかと悩めるプログラムが趣味の高校生であれば、断言してあげましょう。通用し過ぎます。

Note - 趣味プログラマが業界で生きて行くには

これは、ソフトウェア業界の相応の規模の部分集合*1の中において真と言える。

ただし、それはプログラミングという基礎的な点において、だ。プロとして必要な重要な事は他にもある。コミュニケーションだのスケジュールだのプロセスだの、についてはいろいろ言われるだろうが、あまり言われない点がある。

それは"品質"に対する姿勢だ。

コードの質ではない。システム(または製品)トラブルを発生させない事。それに対する姿勢が全然違う。趣味プログラマはプログラミングが目的だから、コンパイルが通って、機能をちょちょいっと確認して、（人によっては）コードが満足できれば、それで「完成」。

たしかに、とりあえず書き上げた時点のコードのバグ率は、一般のプログラマより圧倒的に低い。しかし、趣味プログラマで、機能が「動く」ことは確認しても、パラメタの取り得る値と条件の組み合わせを考え抜いてテストに取り組む人はあまり居ないだろう。バグ探しやリファクタリングのためならじっくりソースを読んでも、一応コンパイルが通って自分の意図した機能が出来たっぽいのに、本当の本当ににバグが潜んでいないのか穴の空くほどそのソースを見直すなんてしないだろう。

プロにとっては、最終的な結果が問題だ。顧客の業務が円滑に回る事がすべて。コードの質とかチャレンジとかそういう事自体は、結果への寄与が間接的すぎてなかなか認められない。いくら「よい」プログラムであっても、トラブル（プログラムの「バグ」とは限らない。他人との微妙な意識ズレなんてのはよくあるパターン）が発生したら、単に「×」。

とくに、デグレ*2だったら目も当てられない。顧客から見れば、追加機能(もっとも酷い場合はバグ修正)に金を払ったのに「関係ない」所を壊してくれた、としか見られない。間違っても「前のはダメコードだったのを良いコードに書き換えたからだ」なんて言ったら、言い訳どころか火に油を注ぐ事にしかならない。書き直すなら、ありとあらゆる条件において完全に以前と同じ動作にし、それでも差が出るところはその影響を受けるところを全て調べ尽くして対応させなくてはならない。

といっても、上記部分集合の中でも底辺ではそれほどでもないし、高品質・安定稼働よりなにより安さやスピードが求められる所もある。だが、その１行のせいで、大企業のグループ全体の業務が停止したり、ニュースで騒がれる事態になるようなプログラムを書かねばならないのもプロだということ。

なお、ここで念頭に置いている「趣味プログラマ」はWindows系の人達であって、*BSDのカーネルを書いてるような人達ではないので、念のため。

*1:essaさんのソフトウエア業界の「バカ世界地図」参照

*2:改訂時に、以前からある機能に新たなバグを入れてしまう事