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

九份　夜景

 前回、筆者の過去の経験をいささか長々と書きましたが、言いたいことは、要はフォルクスワーゲンの不正と言われるソフトウェアが、現代の通常の品質管理プロセスでは見逃されるレベルでは到底ないことです。
発見はいたって簡単なレベル、「お子様ランチ」のレベルどころか、「おめざ」程度、すなわち朝飯前の段階です。
 では、フォルクスワーゲン社の品質管理レベルが相当に低かったのだろうか？
 それも極めて考えにくいことです。
というのも、この程度のバグが見逃されるというレベルは、ほとんど実用のレベルに達していないと言えますが、この不正以外に特段の品質問題は起こしてないのだから、むしろバグだとみなされていなかった、すなわち、組織として意図的にこのコードを埋め込んでいたと推察されます。
傍証としては、

1.  この不正が何年にも渡って行われていて、相当の台数にコードが埋め込まれていたこと。バグとして認識していたら、こんなことはあり得ないでしょう。
   組織として、この不正コードを意図的に埋め込んでいたと推察されます。
    
2.  外部の関連会社がフォルクスワーゲン社に対し、過去にこの不正コードに関し警告を発していた、というニュースは、この不正にマネジメントの関与を強く疑わせます。というのも、マネジメントが、社内調査させれば、至って簡単に発見されるレベルだからです。

 などが、あげられます。


次回に続く、

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

九份(台湾）

筆者は自動車の開発現場の経験はありませんが、過去に組み込み系の大きなシステム開発に関与していた事があります。
　大規模なシステム開発では、日常的に問題が発生し、べらぼうな数に上る場合があります。
もっとも、筆者が現役で従事していた頃と比べ最近は開発手法が進歩していますし、また筆者が従事してた分野は自動車系とは異なります。
しかし、本質的な部分は、さほど変わってはいないでしょう。

　問題といっても様々であり、簡単なバグから、原因が不明でいついかなる時に起こるかわからず、最後に起きてから２〜３年経ち、もう自然治癒したもの（システムは日々変更されているので、こう言うことは間々あります）と思われたものがある日突然連続して現れたりするミステリアスなものまであります（我々は、そのバグの事を幽霊「ゴースト」と呼んでいました）。
中でも厄介なのが、タイミング関連のバグで、特定の状況下に特定のタイミングの下で発生し、実験室での再現が非常に難しいものです。
こう言ったバグは頻度が極めて低く、例えば、仮に100年に１度しか起こらないとすると、通常の実機テストでは検出はほぼお手上げです。
システムを１００年間使い続けようとするユーザーはまずいないので問題ないのではないか？と言えばさにあらず、仮にそのシステムを１００万台出荷したとすると、市場では年間１万回発生することになり　ー　（このようなタイミングのバグの影響はパフォーマンスの劣化以外はマイナーなことが多いのですが、それは別途検証する必要があります）ー　、もしそれが重大事故を誘引するような性質のものであれば大変な事になります。
こう言ったバグの検出はブラックボックス・テストでは絶望的で、ホワイトボックス・テストが必須となります。
また、システムの品質を上げるには、テスト等で潜在バグ率を下げる方法（限りなく０が望ましいのですが、残念ながら完全に０にできないのが、現在の技術水準です）だけでは不十分で、設計技法も重大な問題になります。
問題の影響を局所化するためにタイトなモジュラー設計を行う事はソースコードの品質を向上するためには必須であり、またこのおかげで重点管理が容易になります。
必ず問題は潜んでいるという前提からシステムの多重化をおこなう事もよく行われます。
例えば、平均故障間隔が１万年の独立したシステムを二重化し、同時に故障しなければ安全が確保されるとすると、平均故障間隔は１億年になります（非常にラフな計算で、前提など詳細は略）。
また、フェールセーフの設計も極めて有効で、故障する際は安全側に壊れるよう設計することで、安全性を確保します。
自動車の例では、止まらない車よりも動かない車の方が安全という考え方です。


次号に続く

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

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

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

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

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

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

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

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

＜組織的なスキーム＞

品質保証スキーム図

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


次号に続く

グローバル化と英語 その１

グローバル教育　図はFreepixより拝借

知り合いのフランス人によると、アメリカ嫌いで有名なフランスでさえも最近はグローバル化、ー　すなわち英語化　ー　の波に抗し難く、フランス系の国際企業を中心に社内共通語を仏語ではなく英語にする企業が増えてきたそうです。
　英語を蛇蝎の言葉として忌み嫌うフランスの企業でさえ、このような有様ですから、異文化に多少寛容で脇の甘い大学などは（グローバル化が）さらにひどい状況のようです（キャンパスは英語だらけ）。

なかんずくITやマネジメント・サイエンスなど近年急速に出てきた分野は重症で、例えば、ITは世界的には事実上英語で学ぶものとなって来ており、一説には、英語以外の母国語でITを学ぶ地球上に残る種族は日本人と韓国人だけ、とも言われています（絶滅危惧　CR級）。
　個人的には、このような傾向は最近は、さらに加速されて来ているように感じます。

さて、一つの言語が、国を超えた広範な地域で共通に話されるような事態は、世界史上たびたび見られます。
１９世紀は、大英帝国の景気が良かったせいもあって、英語が事実上の国際共通語でしたが、これは単に共通語として英語を喋っていただけであって、学問分野はそれぞれの母国語か、もしくはラテン語などの古典語で学んでいました。

また、イタリア人が最初に発見した新大陸のアメリカ合衆国のような国で、出身地域がバラバラな移民たちが最終的に英語を共通語にするということでまとまってしまった経緯も興味深いものがあります。
アメリカ合衆国もかつてはフランス語圏やスペイン語圏などもあり、また別の国だったところもあります。
例えば、テキサス州なんかは以前は独立国であり（テキサス共和国）、主にスペイン語を話す住民が多い地域でしたし（今でもそうかも知れません）、カリフォルニア州はかつてはメキシコの一部であり、スペイン語が公用語でした。

（次回に続く）