バグのないプログラム。
プログラマーにとっては、聖杯であろうと思います。
元増田は、「バグのないプログラムを書く方法」や「バグのないプログラムを書くことができるか？」ではなく、「バクのないプログラムを書くことができると思っている門外漢の上司を簡単に説得する方法はあるか？」という問だと思いますので、その点について書きたいと思います。
回答: ない
身も蓋もない話ですが、「問題の解決はその問題を回避すること」が一番手っ取り早いので、この上司を無視するのが適切です。
相手にする必要はありません。
もし、あなたに十分な優しさが備わっているのであれば「流石部長！痛いところを突きますねぇ。でも、これが難しいんですよねぇ。えへへ」と適当な答えをしてお茶を濁すのが正解です。
そして、そんな上司のいる会社はとっとと辞めて別のもっと良い会社を探しましょう。
それが最も有効なソーシャルハックです。
バグのないプログラムは作れるのか？
ということで、一つ問題が解決したので、次の問題に移ります。
では、もう一段問題の範囲を狭めて、「バクのないプログラムを作れるのか？」ということについて考えてみたいと思います。
この問題の回答は、「そんなこと考えている暇があったら、バグ入りでもプロダクトをとっととリリースしてしまえ」です。
これは、今となっては２０年前には既にマイクロソフトが導入している方法です。
Linuxの哲学で言えば、「十分な目ん玉があれば、全てのバグは洗い出される」です。
考えるだけ無駄なことにアレコレ思いを巡らせてしまうのは、プログラマの美徳の一つですが、杞憂だったみたいです。
素早く高品質なソフトウェアを書いて、リリースする事に全精力を注ぎ込んだほうが、結果的にうまくいきます。
ソフトウェアと言うのは、人が利用するものです。バックヤードで稼働するソフトウェアでも最終的に何らかの形で人とのインターフェースを持ちます。
つまり、ソフトウェアとは、人間社会に溶け込んだ人間社会の一部であり、もっとも重要な機能は「社会性」です。社会の中で役に立つか？と言う問題に対して価値を提供しなければ存在する意味はありません。
そう考えると、やるべきことは「バグを潰す」ことではなく「役に立つプログラムを書く」ことです。
世界中の先進的なソフトウェア開発者たちは、とっくの昔にそのことに気づいています。
20年以上前から、マイクロソフトやリーナスは、バグがあっても人の役に立つプログラムの価値に気づき、バグなんて取るに足りないものだという価値観を持っています。
GoogleだってFacebookだってバグだらけですよね？
日本人だけが(言い過ぎた)、21世紀にもなって、2017年にもなって、「バグのないプログラムは書けるのか？」なんてくだらない価値観の下、ソフトウェアを書いているわけです。
やめましょう。そんなこと。時間の無駄です。
バグとは？
もう一つ、細かい話題ですが「バグ」っていうのは、一体何なんでしょう？
世界最古のバグというのは、コンピュータのリレーに入り込んだ虫(bug)だったそうです。
それから70年。人類は未だバグとの戦いに勝利していません。
上記のはジョーダンかもしれませんが、色々な種類のバグが有り、日々プログラマを絶望の縁に叩き込むバグの正体について、我々はあまりにも知らなすぎるのではないでしょうか？
そこで、ちょっとだけ「バグ」の定義について考えてみたいと思います。
こちらも回答を先に書くと「バグの厳密な定義はできない」となります。
例えば、「仕様どおりに動くプログラム」だったとした時に、これは上手く行きません。
簡単に例を挙げると「私は嘘しか言いません」という事を言う人が言った時に、「この人が嘘をついているかいないか？」を判定するプログラムは書けるでしょうか？
これは簡単なパラドックスですが、正しい仕様を定義することができるでしょうか？
現実社会では、もっと曖昧な仕様が大量にありますし、会社が社長派と会長派に分かれて泥沼の権力闘争中している状況で、社長が「メニューは右にしろ」といって、会長が「メニューは左にしろ」と言われた時、メニューはどう表示するのが正しいのでしょうか？
もっと細かいところでも、プログラマであれば「プログラミング」という行為が日々トレードオフの連続だということは、理解できると思います。
ArrayかListかを選択するだけでも、パフォーマンスやスペース効率などのトレードオフが発生します。
どちらが正解なのでしょうか？
厳密なバグの定義は、厳密な仕様の定義と結びついており、厳密な仕様の定義は、社会生活と結びついています。
ソフトウェアは、私達の社会を反映させる鏡の役割を担っていますので、私達の社会の正しさを厳密に定義できない限り、バグの厳密な定義はおぼつかないということになります。
そして残念ながら、それはできないでしょう。
つまり、厳密なバグの定義もできないということになります。
まとめ
上司の説得、バグのないプログラム、バグの定義と三段階に掘り進め、全てに「No」と答えてみました。
中々良い問題提起だったともいます。
とっくの昔に我々は間違っていたということです。
