バグや障害のないシステムが作れない理由を証明/説明しているサイトを教えてください。

システムに人の手が入る部分が存在する限り、絶対にバグや障害はなくならないといえます。

過去のはてなから。

こういう話題を求めているのかな? と思いましたので。

アラン・チューリング

彼の論文で

「同様にプログラムにバグがあるかどうかを完璧に判定するプログラムも作れない。」

とされています。

１番目の回答の人は、以前、「自分はパソコンのプロである」と自称していた人でしたね。

この人は、「システムに人の手が入る部分が存在する限り、絶対にバグや障害はなくならないといえます。」と、無根拠に適当なことを言っていますが、これは原発事故などの際に言われた「人間系を含むシステムでは、ヒューマンエラーがシステムの要因となるため、事故をなくすことはできない」あたりを適当に聞きかじって似たようなことを喋ってみたくなったということではないかと推測しています。

（ご質問の件は、システムの動作で「人手の介在しない部分」においてすら、「バグ」を完全に無くすことができない問題についてですから、あまりに関係の無い話なのですが、私は「また適当なことを書きやがって」と少し腹を立てています。尚、リンク先に罪は無いです）

さて、「バグや障害のないシステムが作れない」という一言は、次の大雑把な流れ：

1. ソフトウェアの動作の正当性を完全に保証することは数学的に無理

　 → 2番目の方の回答が示すURL

2. このため、ソフトウェアのテスト技法によるテストが行われる

　 (ゼロにすることを保証するのではないが、ゼロに近くすることを行う)

3. 一方、ソフトウェアの複雑度に対して、検証必要なテストケースは、指数的に増大する

4. ソフトウェアテストの不足

（→ 現実の事例と結びついたWebでの説明が比較的良く見受けられる）

になる訳ですが、1.は正しいものの、だからといって品質について諦めても仕方が無いわけで、あまりまとまったWebがない感じです。

4.の部分に関するURLをつけておきます(URL1, URL2)。

「バグや障害のないシステムが作れない理由」のうち、「現実的な事柄」について説明しています。

２番目の回答の方がつけているはてな質問が、本質的に質問の興味を満たすもの（ゼロであることを保証することが困難であることの説明）であるものの、数学的な記述が多く、ピンと来づらい印象をうけるかもしれませんね。

あと、はてなと類似したサイトでの似た質問があり、面白いなと思いましたのでつけておきます。

2.の回答をした者です。また同じ過去質問のURLなんですが、解説無しにURLだけ挙げてしまったのが悪かったかと思い再回答(ポイント不要です)。

この質問と回答が指している内容は(ちょっと強引に意訳して言いますが)、ある「プログラム」が正しく動くことを証明するためのテストの系(つまりテストケース表,テストシナリオ,テストプログラム)は「そのプログラム」が真に記述可能な全ての状態空間と「同じかそれよりも大きい」系でなければならない、ということです。

そしてその「テスト系」が正しくプログラムをテストできるかどうかを証明するためには「テスト系」と「同じかそれよりも大きい」系でテストしなければならない、そしてその,,,,。

という様に無限に続くはしごになってしまいます。

もちろん「テストをしても無駄」という意味ではなく、プログラムテストはそもそも「実用にあたって十分に正しいらしいが完全であるとは証明できない」宿命を背負わされていると読んでいただければ。

ということから、「人為的なのを機械的にカバーする方法までつっこんで」しまうと、その「機械的にカバーする方法」が正しいかどうかのテストは、「元のシステム」のテストよりも(おそらくは遙かに)大きなものになる、という問題が浮かび上がります。

「機械的にカバーする方法」が正しいかどうかはある程度の運用実績から判断するしかなくて、保証可能なものではないのですね。

ポイント不要です。

絶対にミスをしない人間と、絶対に壊れないハードウェアと、一切のバグの無い実行環境を用意できれば、バグや障害のないシステムがつくれます。

上記の1つでも欠けると、バグや障害のあるシステムになってしまいます。

＞　またごねるようですが、「ソフトウェアの複雑度」がそれほどでないシステムはどうでしょう？

とりあえず有限状態機械であれば、正当性の検証を完全に行うことが可能（※）なのですが、じゃあ何が出来るかというと、「自動販売機」ぐらいの複雑性になってしまうんですよ。

※……５番目の回答の方が述べていた「追いかけっこ」の最後（最初）の１回目ができます、ということです。

「複雑性が下がる」というわけではないのですが、検証容易性ということを考えると、手続き型プログラム言語を使うのを止めてしまう日が来るという可能性もあるんじゃないかと思います。

ただし、（私は関数型言語でのプログラミングなんて知らないんですが）関数型型言語が、万能薬<<銀の弾>>という訳ではないです。

「β変換は停止しない（無限ループに陥る）場合がある。

ある式の停止性を判断する事は決定不能であることが証明されている。」

っていう一文が、上記URLにありましたので、一応コピペしておきます。

＞　でも、これくらいのシステムなら問題起きないんじゃねぇの？とかこんなバグぐらいちゃんとやれば分かるでしょ、みたいなので起きる問題が多そうなので。

こういうのは、どちらかというと、世の中の問題ですよね。

ひどい連中もいるものだというURLを貼っておきます。

＞　要はユーザーの立場で納得できる説明はないですかねぇ。

怒ってしかるべきバグについては、ユーザーの立場で怒りをぶちまければいいと思います。

あと、松下電気の役員さんが、大変に立派なことをおっしゃっていらっしゃるページを見つけましたのでつけておきます。

（一方で、ソフトウェアへの無理解も指摘されているように思いますので、Justsystemとの訴訟に関する話題が書き込まれた掲示板のURLもつけておきます）

はてな回答は２回までですので、これで私の回答は終わりです。

URLはダミーです。

HPの紹介ではない＆愚痴ですので、ポイント不要です。

自論(愚痴)で申し訳ないですが。。。

【作れないのではなく、あえて作らない。】

根底には費用対効果というところで、バグのまったく無いシステムに対する対価と

ある程度のバグを許容する対価に雲泥の差がある事を認める顧客が居ないことがあると思う。

完璧なシステム

　・仕様する環境は限定される。

　・リリースは数年後～十数年後。

　・値段は数十億～数百億円。　もっとかも？

　　(個人購入するようなソフトで考えると数百万円～数億円)

一部？不具合があるシステム

(メイン業務には支障が無いレベル、使用方法により回避できる 等)

　・仕様する環境はある程度、汎用的にしようできる。

　・リリースは数ヶ月後。

　・値段は数百万～数千万円。

　　(個人購入するようなソフトで考えると数千円～数万円)

上記二つを比較した場合に、どちらを購入するか考えれば分かると思います。

#例は数字は極端かもしれませんが、概念的なものとお考え下さい。

#完璧なシステムを作る場合は、これだけしか機能が無いのに、こんなに費用が掛かるの！？

#という、驚きの値段になると思います。

当然、今までの回答の中にも含まれて居ますが、

やはり、開発には時間がかかりますが、現状の社会ではそれを許さないところが多々あります。

現在の一般的なソフトエウエアに対する評価と言うものはその程度の物だと

お考えいただけるとありがたいです。

当然、開発側としては出来る限りの努力はしているのですが、中々期日に優れた製品を間に合わせることが

出来ないで居ます。(言い訳かもしれませんが。。)

ちなみに、ソフト開発会社には、ピンからキリまでありますので、

同じ値段でも、性能・品質に差があるのも現状だと思っています。

(私もヘボなので。。。orz)

－１ヘボ開発者よりの愚痴でした　　　　　　　－

－ちょっと、見かけて投稿したくなったので。。－

－綺麗な数字とか根拠とか一切無く、　　　　　－

－気分を害してしまいましたら　　　　　　　　－

－　　　　大変申し訳ありません。　m(_ _)m 　－