昨日のつづき。今日も博多〜小倉の移動でした。
今日の講演で面白かった（失礼！興味深かった）のはデンソーの佐藤様のご講演「車載システム開発における品質向上のための取り組みと技術」。カーエレクトロニクスに関わる組み込みソフトウェア開発の現状を垣間みることができました。
組み込みソフトウェアの大規模化・複雑化に対応するためのAUTOSARという取り組みがあること。VBF(Virtual Functional Bus)と呼ばれる共通バスでECUを接続することによりECUをプラグインと見なせるようになるとか＞Androidと同じ思想。
ADLやその一種であるEAST-ADL2による品質向上の取り組み。
次はHAYST法の開発者であるゼロックスの秋山さんによる講演と演習。ExcelVBAで直交表作成ツールを作ろうという演習がありました。なるほど作ってみると考え方を理解できました。ちなみに、HAYST法や直交表に関係するリンク集を公開してくれている方がいましたのでご紹介（Link）。メインページは現在閉鎖されているようですがリンク集はアクセスできるようです。資料の多くはJaSSTのページにあるようです。
こちらの文献によると直交表とは、
直交表は、実験計画法とともに 1940 年代より日本 でも使われはじめ、1957 年に田口玄一氏により「実験計画法」[1]が出版されたことを契機とし、広く使われるようになった。
とあります。ブラックボックステストの一種です。入力因子が増えると爆発的に増える組み合わせを少なくするための方法のようです。
以下、メモをまとめようと書き始めたのですが基本的なことがわかっていないことに気づきました。きちんと勉強しましょう＞自分
前職では直交表は特に使われていませんでした。日本の他の企業でも同様のところがあるのでは？と思います。直交表が使われていない理由を少し考えてみました。ちなみに辞めて６年経ちます。随分と前の状況ですので。
前職では、単体試験では主要な値、境界値を主体的に検査していました。UnitTestなどツールなどを利用するのではなく、昔ながらの手動（開発者がテスト仕様書を書いてテストする）でやっていました。場合によってはチームやメンタとレビューすることがあったと思います。組合せテストでは、プロジェクト内のサブチーム単位で、代表値、境界値、あとは経験的に技術者が認識しているレベルでのフールプルーフテスト？をやっていたように思います。後は機能テスト（前職では総合テストと呼ばれていましたが）では、正常／異常ケースでシナリオベースで試験していました。
ううん。。。テストケースの作り込みには（品質を確保するためには）確かに経験が必要ですが、これで何とかなる業界のように感じます。事実これで数十年やってきているわけですから。もちろん直交表を採用することでテスト工数を減らせるのであれば検討が必要なはずです。
直交表に真面目に取り組んでいる業界はやはりそれなりの必然性があるのだと考えます。必然性のある業界といえばやはり組み込み機器。ソフトウェアの品質が悪いと人命に関わる業界（車、航空、医療機器）もありますし、そうでない業界でも機器回収という事態が考えられます。製品リリース前に最大限、品質を確保することに務めなければなりません。品質確保のためにあらゆる（できれば全ての）入力条件、内部状態の組み合わせを試しておきたいところでしょう。
前職のシステムでは画面入力の因子数はそれほど多くありませんでしたから、極端な話、全数検査してもそれほど時間がかかりません。外部入力（シーケンサやDCSとのI/F）についても、プロトコルが決まっているのでかなりの異常ケースが取り除かれます。直交表を利用できないことはないけど。。。その効果が薄い、というのが結論のようです。
同じソフトウェア産業でもいろいろあるよな。。。と思いますね。（長々書いたわりに情報がない。。。）
とりあえず一週間、終了！ 来週末（２０〜２２日）は試験監督で岡山出張。。。休みがあるようでない不思議な職業。
