機能安全セミナー in ESEC2010
弊社は、自動車業界向けに開発支援ツールを作成させていただいています。これまでは、特別規制などなくやってこられましたが、今後はそうもいかなさそうです。
というのも、ISO26262が法律で義務化されそうな見通しだからです。複数のお客様から、ISO26262が義務化されると開発ツールにも規制が入るとの情報をいただいており、大変に気をもんでいました。
「いったい、ツールベンダーの立場からISO26262とどう関わっていけばいいのでしょうか？」
これが今回のテーマです。どうしたものか・・・と思っていた所に、ESEC2010にて機能安全セミナーが開催されるとの事で、喜んで行ってきました。
セミナー超ざっくり
詳しい内容を全部書くと怒られそうなので、それは講演テキスト要録というものに譲ります。（組み込みシステム開発技術展の専門セミナー全部ふくんで￥８０，０００だそうです）
ここでは、怒られそうにないくらいに、超いいかげんにまとめてみます。（あんまり信用しないでくださいね。）
まず、ISO26262では安全に関わるいろんな事象をランク分けします。
ASIL D： 超ヤバイ （人が死んじゃいそう、など）
ASIL C： ややヤバイ
ASIL B: まぁまぁヤバイ
ASIL A: ちょっとはヤバイ
という感じで、 ヤバさでA～Dにランク分けします。（具体的なランク分けの仕方は講演テキストに含まれていますので、ご興味のある方はどうぞ）
んで、ISO26262は、ASIL Dの超ヤバイ事象に関しては、こうこうこんな手厚さで開発しなさいね。Cならこれくらい、Bならこれくらい、Aならこれくらい頑張りましょうね、という事が延々と書いてあるそうです。セミナーでは、これらの詳しい話を色々とお聞かせいただきました。
そして問題はツールです。たとえば、自動車メーカーさんがASIL Dの事象についてものすごく頑張ってソフトを作りました。ところが、使ってるツールがヘボくて正しい結果が得られませんでした。結果として事故が起きちゃいました。こんなことになると何をやっているのか分かりません。だから、ツールそのものについてもキチンとしたものを使う必要があります。ツールベンダーからすれば、「うちの製品はキチンとしてますよー」という事を、何らかの形で示さないといけないという事です。
ツールベンダーはどうしたものかな？
セミナーの内容はほぼ自動車メーカーさん、部品メーカーさん目線のものでした。そこで、講師の先生に、迷惑を承知で突撃してきました。
「あのぅ、私、実はツールベンダーなんですけれども。ISO26262だとツールにも認定ってのが必要らしいのですが、どうしたもんでしょうか？」
先生は、イヤな顔ひとつせず色々と教えてくださいました。まとめますと、
- ISO26262には、「認証」と「認定」がある。「認証」は第三者機関に見てもらう必要があるが、「認定」は自分で宣言してもいい（オレオレ認定書？）
- ツールに関しては「認定」レベルでもよい
- オレオレ認定書を作るには、やはりそれなりの根拠は必要。たとえば、ツール自体がISO26262-6（ソフトウェア）に従って作られている、というのも根拠になりうるかも
とのことでした。なるほど！
注意：上記はあくまで私（吉武）の解釈です。もしも間違っている点があれば、それは１００％私の理解不足が原因です。
ISO26262導入してみます
もう既に、ISO26262のドラフトがネットで購入できるようになっています。そこで、ISO26262-6（ドラフト）を購入して、開発ツールプロセスに組み入れられないかやってみる事にします。どう考えてもムリという事になれば、業種替えも視野に入れないといけなさそうです。
それにしても、まじめにISO26262を導入するとなると開発支援ツールを作るにもものすごい追加工数が必要になります。その結果、ツールの値段がガンガン上がっていきそう（安価なツールが駆逐されそう）な気がするのですが、いいのかな…
吉武様
ひと月ほど前に静岡からお伺いしました者です．その節は有難うございました．
ISO26262について，かつての仕事仲間と話してみました．OEMさんの方に
動きが出てきているようです．
一方，この手のモノは本記事にも書かれていますように開発者（コードに触れる人）に
負担を強いるものです．でも主導するのは，コードなど今ではほとんど触る立場にない人だと
想像します．このギャップが，今までの経験では追加工数に対して実際の効果が上がらない
まま，なんとなく進んで行ってしまう原因ではないか，というような意見に一致しました．
ただでさえ納期に追われながらの作業に，形式としてのドキュメントを整備する時間が
加わり肝心のソフトの品質自身は低下する方向へのベクトルが加わってしまう，と言った
構図です．
今日たまたま目にした「中日春秋（中日新聞コラム）」に次の記述がありましたので
引用します．
「＜世間は活（い）きて居る。理屈は死んで居る＞と言ったのは、勝海舟だ（『氷川清話』）
▼時世は刻々移り変わるゆえ、小理屈でそれに対処しようとしてもダメ、という政治指南の
言だが・・・（後略）」
勝海舟の言いたかった事からは飛躍しますが，開発プロセスという理屈を持ち出す側
として自戒しなければと考えた次第です．ただ少し救われたのは同コラムの末尾に
「▼ただ、法理は法理である。硬直的ではいけないが、「世間」が強すぎて「理屈」が
引っ込むのも困る。どっちも＜活きて居る＞であってほしい。」
とあった事です．ひょっとして，追加工数を軽減するようなツールの開発に
ビジネスチャンスがあるのではないかと考えたりもします．
長文にて失礼しました．
先月は、貴重なお話を色々とありがとうございました。
また、コメントありがとうございます。開発者とプロセスを主導する人とに開きがあるとのご指摘は、今まで考えたことがありませんでした。言われてみると、確かにそうかも分かりません。
「ただでさえ納期に追われながらの作業に・・・」というお話は、実はCMMについて聞いたことがあります。欧州のとあるOEMさんは部品メーカーさんにCMMレベル３を要求しているのですが、それに対応するための追加工数がものすごくキツイ…とこぼされていました。
ただし、ISO/DIS 26262-6の中身をざっくり見てみますと、少し面白いことに気が付きました。それは、CMMが「開発者の群れをいかにうまく制御するか？」のメソドロジーであるの（かな？）に対して、ISO/DIS 26262-6には「いかに高品質の開発を行うか？」のメソドロジーが記述されている（と思われる）事です。
たとえば、ソフトウェアアーキテクチャの検証をするためにASIL D,C,Bならインスペクションを、ASIL Aならウォークスルーをしましょう、なんていう記述があります。もっと細かいところでは、たとえばコーディングガイドラインとしてスタイルガイドを使用したり、変数の命名規則を用意したりしましょう、なんていう記述もあります。
ソフトウェアエンジニアリングというよりも、もっと低レベル（詳細レベル）でのアクティビティがつらつらと書かれているところを見ますと、オールドタイム エンジニア様がおっしゃるように、ツールによって追加工数を軽減する事ができる部分が、それなりにありそうな気がします。
これから、ISO/DIS 26262を読み込んだり、色々な人に教えていただいたりして、少しずつ勉強していくつもりです。またお会いした際には、色々とご意見をいただければ幸いです。
今後とも、よろしくお願い致します
吉武様
１年ほど前にお尋ねしました。
MATLAB/SimulinkのRTWSを調査していて、偶然御社のHPを拝見しました。
ご病気だとのことで、心配になりました。ゆっくり静養して頂きたいと思います。
今、電力消費のシミュレーションをMATLAB/Simulinkで開発しています。自動車関連とはちがいますが、近似式を作成してシミュレーションなどをおこなっています。
はやくお元気になられますよう祈っています。
ご無沙汰しております。病気の方は、お陰さまで完治いたしました。お気づかい有難うございます。
電力消費のシミュレーションといいますと、プラグインハイブリッドや太陽光発電等をにらんだ住宅モデルでしょうか？それとも、もっと全然別の物でしょうか。
何にせよ、ご活躍のご様子で何よりです。いずれ、一緒にお仕事をさせていただく機会があればと思います。
今後とも、よろしくお願い致します