1960年代後半、出張先での生活を振り返って、
この間、コンピュ－タと言うものについて自分なりに理解することが出来たような感じがする。
シミュレーションプログラムの仕事を通じて、コンピュ－タの本質を理解したように思う。
ここでのシミュレーションプログラムは、電子交換器というコンピュ－タのシミュレ－ションをするプログラムの事を言う。
従って、ハードウェアの擬似を行うため、ハ－ドの動作をよく理解することが出来た。
仕事の目処が立ち、今度は作る側からソフトウェアの検査をすることになった。
ここでは、ソフトウェアの検査の弱体さについて身を持って体験させられた。
主な点は、
・設計の指示のままテストを行ってしまった。
・内容的に不合格のものが合格として納入されてしまった。
検査は、品質の悪いものは悪いとして不合格とすべきである。
設計、検査、工程管理と部署を分離した基本原則はなにか。
勿論３権分立である。
その一つが検査であり、職務を全うしていないではないかと反省。
検査すべきチェック項目の組合せは膨大に在るものである。
故に、人が考えられる項目の全てはパスして当然な事であり、パスしたから合格という考えは間違っている。
即ち、パスしたと言うことは合格にすることとは別で、ただ合格の対象により近くなったと言えるだけの事である。
上長の言い訳としては、
・顧客担当分のバグが８０％を占めている。
・遅延金が絡む。
の２点が大きな要因という。
ソフトウェアも「製品」だと言う事を取り違えて考えているのではないだろうか。
ソフトウェアとはすばらしい夢の有る将来性のある“モノ”である。
これが私の品質保証（この当時は検査と言う）に関わった最初であり、その後もいろいろなことを体験し、品質保証部門で落ち着いた。
