フォルクスワーゲンのミステリー その１

フォルクスワーゲンの不正事件が世界中を駆け巡ったのは、先月の事でしたが、事象そのものが単純な割には、真相究明には手こずっているようです。
　筆者は、自動車業界にも疎く、ドイツ車とはまったく無縁の生活を送っていますが、ソフトウェアの品質問題や組織論にも関連する事から、いわば野次馬的な興味、あるいは推理小説的興味とも言えますが、そんなものを持っています。

＜ブラックボックス・テストの難しさ＞

システム製品のテストの難しさは業界でもよく話題にのぼります。
システムが大型化、複雑化した結果、テスト環境の構築が困難になり、テスト項目が膨大（天文学的数字に膨れ上がってきています）になって来ており、一方、実地でのテストに加え、シミュレーション等のテスト技術も進んできてはいますが、分野によっては使えなかったり、実地との乖離が問題になったりして、全体的には補完的、補助的な位置づけと言えます。
また、多くのシステム製品はソフトウェアが組み込まれており、問題をさらに複雑にしてゆきます。（自動車業界では、開発コストの約半分がソフトウェア開発にあてられている、と言われています。）
そして、そのソフトウェアの検査ですが、ソースコードを見ずに検査する方法　ー　すなわちブラックボックス・テスト　ー　は、 極めて難しく、確定的に見極める事が極めて困難です。（文字通り、ブラックボックスです。）
 このようなソフトウェアの性質から、外部のテスト機関が内部の不正を発見する事は極めて困難であり、今回、フォルクスワーゲン側に不正を認めさせるまでに相当の時間がかかった事でも、その事が窺わせられます。

< ホワイトボックス・テスト>

では、ソースコードを見たら、今回の不正が簡単に分かるか？という疑問が湧いてきますが、これは、『いくつか極めて現実的な仮説を置いて』という前提条件付きで、簡単、もしくは決して難しくはないと言えます。
と言うのも、数十年前のコンピュータの黎明期のような頃の、アクロバット的なスパゲッティ・プログラミングが横行し、誰も読めないようなコードが蔓延していた時代とは異なり、安全性などのソフトウェア品質を重視する分野などでは、昨今ではソフトウェアはシステムのおまけ的な位置から、システムのサービス品質（安全性も含む）などを担う中心的な役割に変わってきており、また製品の品質が企業の存亡を左右する重大な関心事となって来ており、品質の問題が、経営者の根幹的な関心となり、トップのマネージメント・チーム、ー　いわゆる CEOやCFOから構成されるCグループ内　ー　にも品質問題の責任者が置かれるようになってきました。
そして、品質をチェックする部門も、相当強化されてきています。
一方で、最近のシステム開発において、ソフトウェア開発の締める部分が増大し、宇宙航空分野では、総開発費の７０％はソフトウェア開発費に割り当てられ、当該自動車分野でも５０％はソフトウェアが占めると言われており、ソフトウェアは極めて重要な企業資産となってきており、その機密性も重大な問題となってきています。
すなわち、ソフトウェア品質は企業経営者にとって極めて重大な関心事であり、また同時に、莫大な投資先であり重要な企業資産でもある事から、その機密も厳重に守られており、ソースコードにアクセスできる人員も必要最小限に限定されています。

＜ソフトウェアの品質保証＞

通例、ソフトェアのソースコードにアクセスできるのは、開発者と品質保証の人間だけ限定されています。
品質を重要視する分野の企業では、品質担当の役員には、極めて強力な権限が与えられており、その代表的な例としては、品質に問題がある製品の出荷をストップする権限が揚げられます。
これは品質が不十分な製品が市場に出てしまうと、企業に取り返しのつかないほどの莫大な損失が発生する可能性があるためです。
また、仮にソースコードがスパゲッティ過ぎてロジックが読めないような場合、ソースコードの劣悪な品質のために品質保証が不可能であるとして、コードの書き直しを命ずる権限も保有しています。（ソースコードの書き方そのものが、品質評価の対象です。）
したがって、先に述べた『極めて現実的な仮説』とは、ソフトウェアが適切な高級言語で書かれ（通常、組み込み系ではAdaかCです）、ソフトウェアコードが品質保証の対象になっている事が重要な条件となります。

＜組織的なスキーム＞

品質保証スキーム図

品質部門と開発部門は、製品開発の初期から出荷後まで、協働して開発プロセスを続けていきます。
そして、品質部門の同意がない限り、開発は次にのステップに進めない、というのが一般的です。
この詳細な開発プロセスそのものは、組織や、開発分野によって大きく異なり、フォルクスワーゲンの開発プロセスそのものに関しては良く分かりませんが、スキームそのものは、大差ないでしょう。
左図は典型的なスキーム例ですが、開発部門と品質部門が、相互にコラボレーションを繰り返し、品質の問題に関し両者が相容れない場合は、上級マネジメントにエスカレーションして解決を求めます。
そして、最終的に品質担当部門の非同意の決定を覆す事ができるのは、組織のトップ、この図ではCEO、です。
 また、最近では、品質から安全性のみを取り出して別の縦軸を置き、エスカレーション・ラインを３本にするケースもみられます。
管見では、ヨーロッパ人は開発方法論など方法論の議論が大好きで（もちろん、個人ではなく組織のレベルで）、精緻な開発プロセスを設計する傾向がありますが、あくまで一般論であり、今回のフォルクスワーゲン社のプロセスがどのようになっているか、筆者は知る立場にありません。
しかしながら、品質管理スキーム同様、なんらかのしっかりとした詳細な開発プロセスが規定され実行されていただろうと推定する事が蓋然的でしょう。


次号に続く