元SEの車ネタ&毒吐き日記、時々仮想通貨

元SEが愚痴ってるだけの日記を記載しています。

【日記】【時事ネタ】【車ネタ】データ改ざん問題

車両を注文している身としては

やめてくれ、きにしないからさっさと作って納品してくれ

ってのが本音です。

工業製品ですからある程度のばらつきなんて仕方ないです。

 

というかEJ20*1は当初から個体差が激しかったじゃないですか(〃艸〃)ムフッ

これをどうこういったところでかわりゃしないって、、、

 

SE視点からみてみると

試験結果(エビデンスなど)を故意に改ざんすることは許されない行為ですが、

個人的に今回のケースは、例えば試験項目数が担当者や変更内容によって少なかった、多かったので平均がずれてしまった。

結果は変わらない問題ないけど、報告はさてどうしましょう。

って感じで、無理やり試験パターン追加や、弄ってない既存処理部分の一部をしてない事にして報告しちまえ!ってことは実はありました。

(※試験項目作成者は仕様書をもとに作ってくれるので担当者によっては改修ルートを絶対通らないパターンも丁寧に上げてくれたりします。)

 

分かりやすい例として、表示文言を数か所直しただけで、機能には全く影響してないモジュールがあったとします。*2*3

システム全体の平均を考えると、試験項目数を稼がないといけないパターンとか、もうアホかっていう試験をしないといけなくなります。

(※通常デグレチェックとは別にカウントされ含まれません)

大規模システムになるとこういう修正内容なんでこのモジュール(機能)部分の試験は修正コード数が少なく、バグ率下限を下回っております。

なーんて説明をしても、突っ込んでくる品質管理担当に対し詳細を説明する必要が出てくるんですね。

 

こういう時、現場内容を分かってる人が責任者やってると、ああこれなら分かったと言ってくれますが。

内容分からないやつがチェックするときほど大変になります。

数値でしか判断しないからです。

規定、規定、規定、また規定・・・バ〇の一つ覚えでうるさいわボ〇ナスが!!!!

って言いたくなります。というか言ったことあります。

じゃぁお前が試験項目つくってみやがれ!!!と。

 

しかしまぁ、第三者(担当外)が必ずチェックするいい環境ではありましたが、はずれ担当者を引くとえらい目にあってました。 

図解でわかる品質管理 いちばん最初に読む本

図解でわかる品質管理 いちばん最初に読む本

 

 

脱線しました

車の話でしたね、ハイ

車もエンジンは出荷最終検査でREVまで回して(回すらしいんですよね、、必ず)数値測定したり、重量バランスや車検的な事をチェックしていくわけですが、絶対ばらつきは出てきます。

今回の報告を全て鵜呑みして正しいと考えると、意味もない再チェックや、良すぎて説明がめんどくさい時改ざんしていたことになっています。

あと担当者の車両設定間違いにより変な値が出てしまった際再チェックしていない(これは問題だと思います)などなど、、、

 

一部問題はあれど、どうしてもNGなパターンを隠してるようではなさそうです。

明らかに強度不足や機能不全を隠しているならともかく、多少は多めに見てもよさそうなものが報告されています。

 

すなわち、品質管理規定側に問題があるんじゃないか?例外というかこういうケースは問題なしという規定がないから書き換えてるんじゃないか?

ってことになります。

 

品質管理は例外もちゃんと書いておくべき

例えば、〇×の場合の値は下限値(上限値)を超えても問題ないなど、SEだった時代もシステムに合わせて絶対にではなく柔軟に対応していました。

もちろんその根拠なりは必要ですけど、、、

 

問題が出ました、だからチェック項目を追加します。

っていって追加しまくってたプロジェクトとかだと、意味もないチェックが山ほどあって

なんじゃこのチェック項目マトリックスは!?みたいなプロジェクトもありました。

 

まとめ

品管は重要な職務ですが、頭が固い人がなると逆に品質落とします。

IT業界みたいに全くやってない会社もあるぐらいなんですからそれよりは大分まし、システムだってものによっては生命にかかわるケースだってあります。

なので柔軟に対応し、時代や現場にあった状態を保てる人がならないといけないんですけど、そういう体制ではなかったんでしょう。 

品質管理のための統計学 ~生きた実例で理解する~ (現場の統計学)

品質管理のための統計学 ~生きた実例で理解する~ (現場の統計学)

 

 

*1:メーカーばれる

*2:文言だけの場合コードを直すケースは少ないのですが例です例

*3:コンフィグ等設定値変更の場合の試験ももちろんしますよ