メンテのたびに不具合が出て問題起こすのを横目で見てそのたびに思うことがある。
何がいいプログラマの仕事であるかみたいなこと。

いいプログラマっていうのは組織的に作られるものだと思うんよね。
個人的な見解ですが。

自分が元は職業SEだったのでそういう意識でいるのだけど。
私がいたところっていわゆる冠（かんむり）の付く総合大企業のSE部門として機能する子会社だった。
これは自慢とかではなく、そういう会社の体質の説明の一部。
そういう大手っていうのは個人の技量よりも組織力による問題解決意識が高いわけ。
どういうことかっていうと、凡人がものを作る前提で、じゃあどう物事を解決していくかのほうに頭を使う体質ってこと。

そういう会社に入る人って基本的には国立大学出が多くて（ごめん私は違うけどたまたま）、専門知識レベルは低いけどわりと地頭がいい人が多いの。もちろん当然本物のぼんくらも多いけど。
で、専門知識レベルが低くてもポテンシャルは高い人が多いのね。
でもスーパーマン的な人は少ない。（母数が大きいからチラホラいるけどね）
で、突出して優秀な人に頼らない仕事の回し方のほうを大切にする。
要は、突出して優秀な人が突然事故死しても会社に影響がないようにレールを敷くわけ。

要するに凡人がいかにして生産管理するか、どうやって品質を維持するか、というマニュアル作り、指標づくりが上手いのね。

やっと本題。

才能があるプログラマが一人で大活躍するんじゃなくて、凡人がいかにすれば手堅いプログラムを作れるか、どうすれば品質を確保してリリースできるか研究することに時間とお金と歴史を費やしてきている。
そういう手法がマニュアル化されてて指標がある。
人を入れ替えても会社がびくともしないようにね。
それはそれで一日の長があって評価できると思ったものですよ。

そこではプログラム作った後のテストのフェーズで一定％以上のバグが出なかった場合にそれをどう評価するかというと・・・
それプログラマが優秀なんじゃなくて、テストがダメって言われる。
テスト計画・テスト設計（テスト項目などの設計）がまずいか、テスト自体が不十分とみなされる。
そしてリリースできない。
テスト項目の見直しからやり直させられる。
これなー。
これ本当に優秀な人泣かせなんだけど、凡人を基準に指標ができている。
それでどれだけ泣いたことか・・・。

でもこれくらいやるのがハードの世界では普通なんだよね。
乗用車の部品の耐久性とかではね。

そういうことを思い出さずにはいられない。

なんかなー
世の中にソフトウェアをリリースしてアップデートしていく仕事の人ってもっと厳しく仕事してほしいと思うのよね。