私は日ごろ、ソフトウェアの開発を行っています。
特に私の仕事のように、パソコン用のプログラムでなく、特定の商品に入っているＣＰＵのためのプログラムを、組込み(Embedded)のソフトウェアと言いますが、この世界は地味なわりに開発のスケジュールが厳しく、多くのエンジニアが悲惨な労働環境のもとで働いていることが予想できます。
プログラムを書く、という仕事はたしかにクリエイティブなものです。特にそれが製品仕様と関わってくる場合、ソフト開発する本人にかなりの仕様上の裁量を与えられることもあるでしょう。また、どのようにプログラムを書けば、コンパクトで高速で、なおかつあとあと再利用できるようなソフトになるか、と考えながら設計することは、エンジニアのクリエイティブな心を刺激することでしょう。
しかしその一方で、開発の後半になると、プログラマは仕上がりかかった自分のプログラムのバグと格闘することになります。バグとは、まさに自分自身がプログラムに仕込んだ間違いであり、誰がどう見てもバグを作った本人が責任を持って直すべきものです。
どんな仕事であっても、「間違い」を直すことは当然のことであり、またいかに「間違い」を起こさないか、というのがその人の能力を示すことにもなります。ですから、一般の人がソフトのバグを見つけても、同じことをプログラマに要求することはよくわかります。
しかし、「間違い」はあってはいけないものですが、間違いの個数によっては考え方を変えなければいけないことがあります。
一般的にプログラムを１０００行も書けば、誰でも数個のバグは出してしまいます。原稿用紙１０枚に書いた原稿に誤字脱字も、論理的な欠陥も一つもない、ということを想像してみてください。プログラムは誤字脱字をしただけでも、動作上大変なことを引き起こすこともあるのです。
プログラムの行数が２倍に増えたら、バグの数も２倍に増えるだけならいいのですが、どうも一般的には２倍では済まないことが多いように感じます。つまり、プログラムをたくさん書けば書くほど加速度的にバグの数が増えていくのです。
もし場当たり的に製品のテストをして、バグが出るたびにソフト担当者を怒るようなやり方で仕事をしていたらどうでしょうか。製品が大規模になるにつれ、バグの数は莫大になり管理者も怒る気が失せます。しかし、その次には、バグの集計を取り、原因を調べ、同様な原因によるバグを減らすための施策を行う、というようなことを行わなくてはいけないのです。さらに、自分が書いたソフトウェアが正しいことを調べる方法にも、工学的な手法が導入されていくべきです。
そして何より、私が言いたいのは、ソフト開発にバグはつきものであり、永遠にバグはなくならないことを肝に銘ずるべきです。これはどういうことかというと、バグを出したのはプログラマの怠慢によるものである、という考えを管理者が捨てることです。そうやって初めて、バグとか間違いを科学的に分析しようという態度が生まれてくるものだと私は思うのです。管理者がただ担当者を叱るだけでは、バグを出した担当者は、自分のバグを隠そうとするか、卑屈になって自分の低脳さを笑うか、責任を感じて深夜までバグ退治を行うか、しかなくなるでしょう。
工学的な世界で物事を考えようとするなら、そこに根性論とか倫理観とか持ち込むべきではないのですが、バグが結局はただの「間違い」であるがために、なかなかそうはいかないのが現状で、バグを出すたびに立場が弱くなるプログラマは、今日も深夜まで泣く泣く仕事をしているに違いありません。