2013年8月の読者の関心事

下記の表はこのブログサイトの8月のアクセスページを滞在時間で1位から50位まで並べ替えたものだ。

不思議なことに8月は忙しくて一回もブログを書かなかったにも関わらず、お盆休みを除き、ウィークデーは毎日200件くらいのアクセスがある。そして新規読者が半数を超えている。

そして、下記の通り、時間をかけて読まれているは特集記事「ISO 26262との向き合い方」だ。

自分が興味をなくしたテーマにも関わらず世の中では記事を読みたい人がいるらしい。また、Google アラームで ISO 26262 のキーワードがヒットしなくなってきた。

約3ヶ月前くらいから ISO 26262 に関するニュースが流れなくなってきた。ついにキーワードによるブームが去ったのか。

これは勝手な想像だが、やっと当事者達はキーワードに踊らされていたことに気がついてきて、本当は何をするべきか考えるフェーズに入ってきたのではないだろうか。

それはいい傾向だ。そもそも機能安全で安全を追求できるのかについて、自分達の環境で自分達が作っている製品で考えてみるステージに移ってきたのだろう。

今、自分のドメインのことで頭がいっぱいなので自動車のことを考えている余裕がないが、困っていることがあって取り上げて欲しい話題があればこのサイトの右上の Message Leaf からメッセージを送って欲しい。

といっても、半分以上の読者が 検索エンジンで目的のページを直接開けているようなので、このメッセージは伝わっていないか。

1	ページ タイトル	平均ページ 滞在時間（分）
2	ISO 26262との向き合い方 (8) リスク分析しないでいいの？	29.72
3	ISO 26262との向き合い方 (10) ISO 26262 をテンプレートで乗り切る功罪	29.43
4	ISO 26262との向き合い方 (1) 最初に読んで欲しいこと	28.88
5	ISO 26262との向き合い方 (3) 規格認証とスコープについて	28.57
6	ソフトウェア資産の価値を可視化すべし	28.08
7	ユーザー要求の多様化とペルソナ法	27.90
8	ISO 26262との向き合い方 (17) 安全機能の複雑性を分析する	27.00
9	ISO 26262との向き合い方 (21) 安全について理解を深める	26.62
10	ISO 26262との向き合い方 (1) 最初に読んで欲しいこと	25.33
11	ISO 26262との向き合い方 (6) 機能安全のマネジメント2	25.27
12	ISO 26262との向き合い方 (8) リスク分析しないでいいの？	25.22
13	MATLABのビジネスから見る知的生産性とは	25.00
14	ISO 26262との向き合い方 (24) ソフトウェア安全分析・設計2	24.78
15	ISO 26262との向き合い方 (14) FTAとFMEAの歴史	24.10
16	ISO 26262との向き合い方 (24) ソフトウェア安全分析・設計2	23.93
17	ISO 26262との向き合い方 (18) ツール認証って何だ？	23.55
18	ISO 26262との向き合い方 (21) 安全について理解を深める	23.35
19	100%の安全が確保できないからルンバを作らない？	23.23
20	ISO 26262との向き合い方 (22) テンプレートで乗り切る功罪2	22.58
21	ISO 26262との向き合い方 (5) 機能安全のマネジメント1	22.37
22	ISO 26262との向き合い方 (11) ASILの分解は本当に可能か	22.16
23	ISO 26262との向き合い方 (21) 安全について理解を深める	22.12
24	ISO 26262との向き合い方 (17) 安全機能の複雑性を分析する	22.05
25	ISO 26262との向き合い方 (3) 規格認証とスコープについて	21.68
26	プリウスブレーキ制御ソフト改変についての考察（再考）	21.55
27	ISO 26262との向き合い方 (13) 機能安全の歴史的背景1	21.50
28	トヨタのソフト戦略	21.20
29	ISO 26262との向き合い方 (4) 用語の定義からのトピックス	21.02
30	ISO 26262との向き合い方 (12) 対訳版を読み始めて思うことあれこれ	20.88
31	ISO 26262との向き合い方 (15) FTAを描いてみる1	19.95
32	ソフトウェア系の国際規格はどのように使うのか？ (ISO 26262 が正式発行される）	19.63
33	ISO 26262との向き合い方 (1) 最初に読んで欲しいこと	19.28
34	ソフトウェア系の国際規格はどのように使うのか？ (ISO 26262 が正式発行される）	19.00
35	ISO 26262との向き合い方 (18) ツール認証って何だ？	18.95
36	NHKのドラマ「メイドインジャパン」を見て2	18.82
37	ISO 26262との向き合い方 (15) FTAを描いてみる1	18.80
38	ISO 26262との向き合い方 (11) ASILの分解は本当に可能か	18.41
39	ISO 26262との向き合い方 (21) 安全について理解を深める	18.35
40	ISO 26262との向き合い方 (5) 機能安全のマネジメント1	18.12
41	ISO 26262との向き合い方 (18) ツール認証って何だ？	17.63
42	Embedded Software Manufactory	17.23
43	ソフトウェア系の国際規格はどのように使うのか？ (ISO 26262 が正式発行される）	16.92
44	ISO 26262との向き合い方 (20) 品質と安全の違い	16.83
45	西洋の真似をするだけというのはそろそろやめよう	16.70
46	ISO 26262との向き合い方 (13) 機能安全の歴史的背景1	16.50
47	ISO 26262との向き合い方 (1) 最初に読んで欲しいこと	16.27
48	ISO 26262との向き合い方 (6) 機能安全のマネジメント2	16.18
49	ISO 26262との向き合い方 (5) 機能安全のマネジメント1	15.83
50	ISO 26262との向き合い方 (5) 機能安全のマネジメント1	15.53

冒険の旅をやりきるにはEP(Experience Point）の積み上げが必要

仕事で問題を解決すると自分の経験値が上がったと実感することがある。

ロールプレイングゲームの E とか EP (Experience Point) というヤツだ。経験値が設定値まで達すると主人公のレベルが一つ上がる。

ロールプレイングゲーム（左は初代ドラゴンクエストの画面）と現実の世界が違うのは、現実の世界では経験値が見えないということだ。

自分はセミナを開催したときは、「メールで送っていただいた質問には必ず返信します。」とアナウンスすることにしている。会場での質問に答えるのも自分自身の訓練になるが、メールで相手が満足するまで、納得するまでやりとりすると達成感があるとともに、自分自身の経験値が上がった実感を持てる。

自分のエンジニア人生を振り返ると、いろいろなことを勉強するのに必至だった20代、成果が上がってきた30代、そして、40代になって問題解決能力が高まってきた感じがする。

問題解決能力が高まってくると、いろいろな問題を解決することがだんだんおもしろくなってくる。難しい問題であればあるほどモチベーションが上がるのが自分でも分かる。

あるラジオ番組のパーソナリティが、日本人のボランティアは指示を待つ人が多いが、ボランティアの先進国であるアメリカのボランティアは助けが必要なところに乗り込んでいき、そこで求められていることを探して自ら仕事を作ると言っていた。

この話は『採用基準』に書かれていた、リーダーだけがリーダシップを発揮するという狭いリーダーシップの概念ではなく、プロジェクトの誰もがリーダーシップを発揮してよいという本来のリーダーシップのあり方にも通じると思った。

問題解決能力が高まると、どうすれば解決の道が拓けるかの道筋が見えてくるので、提案すべきことが浮かんでくる。メンバーの多くにそのようなひらめきが浮かべば、それを議論して何を採用すべきかを決めればよい。

日本の会議ではみんな黙っていることがあまりにも多い。解決策が思い浮かんでそれやりたいと思ったら、どんどんリーダーシップを発揮して、問題を解決してしまえばよい。自分が名目上のリーダーや責任者じゃなくてもいいのだ。

それを実践すると自分の経験値がどんどん上がっていくことが実感できる。外から見ると自らやらなくてもよい仕事を背負ったように見えるのだろうが、本人はものすごくモチベーション高く、取り組めている。自ら選択した問題に集中することができ、解決できれば実績になる。

それを繰り返してくると不思議と、他の人でもできる仕事が寄ってこなくなる。すると、結果的に難しいが自分がやりたい仕事だけに集中することができる環境ができてくる。

ただ、一つだけ問題があって、ロールプレイングゲームでは常に画面に表示されている HP(Health Point）やEP(Experience Point）は現実の世界では表示されてはいないということだ。

そうなると、溜まった経験値を何らかの形でアピールする必要が出てくる。いろいろ方法はあるだろうが、直属の上司にだけアピールするのはあまり得策ではないと思う。もちろん、組織内の機密情報は明かせないが、どんな経験値が積み上がったのかを一般的なことばで自分のプロフィールに追加して何からの形で表示するのは表現の自由が保障されている国でやってもよいだろう。

エンジニアのEP(Experience Point）って、とても重要だと思う。他人の批評だけしていても EP はまったく上がらない。現実の世界では、問題を解決してこそEP が上がるのだ。

そう考えると、人生観すら変わる可能性がある。嫌々日々の仕事を片付けるのではなく、どんな仕事も自分の経験値を高めることにつながると感じられるようになり、経験値が積み上がってきてレベルアップすると、よりやりたい仕事が選べるようになり、モチベーション高く、さらに難しい問題に挑戦できる道が拓ける。結果的にサラリーが上がるか、もしくはその実績を評価できる別の組織から声がかかるかもしれない。

傍目で見ていると EP がなかなか上がらない人がいる。そういう人はEP の上がり方をもう少し意識してみたらどうだろうかと思う。EP を効果的に上げるにはどうしたらよいか必至に考えると、何を学習すればよいのかが見えてくる。RPG の世界では EP を上げるには敵を倒すのだが、現実の世界では、リアルな問題を解決できるとぐっと EP を上げることができる。そのためには、どんな知識が必要で、どんな経験がいるかをよく考えるようになる。

そういう感覚を持っていると、世の中にある洪水のような情報の中で、自分の EP を上げるのに役立つ情報と、役に立たない情報の切り分けができるようになってくる。

情報を右から左に流したり、評論しているだけでは EP は上がらない。冒険の旅をやりきるには必ずレベルアップが必要で、レベルアップするには EP を積み重ねることが必要だということを意識しないといけない。

ISO 26262との向き合い方 (27) 最終回：何に向き合いますか？

2011年12月1日から1年半、27回に渡り続けてきた特集記事「ISO 26262との向き合い方」をいったん終了にすることに決めた。

書きたいネタはまだまだあるのだが、6/7 に開催した SESSAME のソフトウェア安全分析・設計セミナの参加された自動車ドメインの方達と接して、ハタと気がついたのだ。

薄々気がついていたのだが、自動車業界は業界構造がサプライヤが部品を作りメーカ（OEM）がアセンブリするというスタイルが出来上がっている。

だから、ソフトウェア安全分析・設計セミナで訴えている「現代の大規模・複雑化したシステムでは Fault Avoidance（個々の構成要素の信頼性を高めることで安全を確保しようとする設計）は無理で、Fail Safe, Fault Tolerance, Error Proof(Fool Proof) の設計を目指しましょう」という主張が肩すかしにあう。

サプライヤは自分達が供給している部品やその部品を制御するソフトウェアにしか関心がなく、完成品の安全について切々と語ってもぼんやりとしか受け取ってもらえないということに気がついた。

だから、メーカから ISO 26262 の規格に適合せよと言われて、そこで要求されているいろいろなことをクリアできるようになりたいという欲求はあっても、「エンドユーザの安全について考えよう」という問いかけには反応が薄い。

コンサルタントも含めてセミナで訴える最終製品の安全の実現よりも、リスク分析の手法を習得することに興味が集中しているらしい。

そして、ISO 26262 という規格の構造自体が 自動車業界の構造を意識したものであり、サプライヤが供給する部品に Fault Avoidance（個々の構成要素の信頼性を高めることで安全を確保しようとする設計） を求める規格であることが分かった。

ISO 26262 も上流工程(ISO 26262-1,2,3 機能安全の管理、コンセプトフェーズ、システムレベルでの製品開発）でシステム全体のリスクアセスメントをすることになっているが、これは絵に描いた餅で後から取って付けた要求に見えてきた。

メーカとサプライヤが一緒になって、コンセプトフェーズやシステムレベルでの製品開発について、頭を付き合わせてディスカッションしている構図がまったく想像できない。

雰囲気的には、メーカはサプライヤの規格適合を命令するだけ、サプライヤはISO 26262に適合せよと言われてやるだけのように見える。間をつなぐはずのソフトウェア系コンサルタントはハードウェアによるリスクコントロール手段には興味がなく自分達の守備の範囲外だという顔をしているように見える。

唯一、ECUのプラットフォームを担当する会社のエンジニアはセミナの内容にビビッときたようだが、自動車のシステム全体を見渡せるようなポジションにはいないようだ。

そんなことを考えていたら、下記のようなニュースが飛び込んできた。

【中日新聞2013年6月27日記事より引用「衝突軽減装置、誤作動の恐れ　トヨタ、２万台リコール」】

トヨタ自動車は２６日、前の車にぶつかりそうになると自動ブレーキがかかる衝突軽減装置に誤作動の恐れがあるとして、昨年末に発売した新型「クラウン」約１万９千台と、５月に発売した新型「レクサスＩＳ」約１０００台のリコール（無料の回収・修理）を国土交通省に届け出た。衝突軽減装置のリコールは国内２例目で、トヨタ車では初めて。

　この装置は車体から前方に電波を飛ばし、跳ね返った電波を受信して障害物の距離を測る。近づきすぎると警報音が鳴り、自動的にブレーキがかかる仕組みだ。
　国交省によると、４月以降、リコールの対象車の所有者から「突然ブレーキがかかった」などの情報が６件あった。うち５月下旬、東京の首都高速道路で、渋滞で徐行中のクラウンに急ブレーキがかかり、後続車に追突された。運転手にけがはなかった。 

　トヨタは、クラウンとＩＳを全面改良した際、隣車線からの割り込みにも対応できるよう、障害物検知の感度を上げた。東京の追突事故では、先行車に当たって乱反射した電波が、並走のタンクローリーにも反射。電波が横から来たため「割り込み」と誤って認識して急ブレーキがかかったという。 

　リコールでは、障害物検知のソフトを修正する。衝突軽減装置は、各メーカーがここ１０年ほど開発にしのぎを削り、量産効果で価格も下がってきたことで搭載車が増えている。トヨタによると、販売台数のうち新型クラウンでは４割、新型ＩＳでは６割が搭載車という。 

　国交省によると、搭載車のＩＳ約８００台が北米や欧州に輸出されており、リコールが必要かどうかトヨタが調べている。
　衝突軽減装置をめぐっては今月４日、三菱自動車もスポーツタイプ多目的車（ＳＵＶ）「アウトランダー」で、トンネルの壁を前の車と誤認して自動ブレーキがかかる不具合が判明し、リコールを届け出た。

【引用終わり】

ソフトウェア安全分析・設計セミナでは、車の基本機能である「走る」「止まる」「曲がる」がアーキテクチャ的に独立している時には、問題が起こりにくいが、今後市場要求が多様化して「走る」「止まる」「曲がる」の機能が相互に干渉してくると、これまで予想もしなかったような原因の分かりにくい不具合が増えてくるということをレクチャーしている。

安全をインテリジェントにするということの裏側には、思いもよらない副作用も付いてくる。その複雑性に伴うリスクの怖さが自動車ドメインの技術者にはピンときていない。

プリクラッシュ・セーフティシステムは「走る」「止まる」がソフトウェア的に結合し、緊急操舵回避支援システムでは「走る」「止まる」「曲がる」が結合する。

上記の誤動作は「止まる」の機能の中に閉じた問題だが、各機能が結合した状態で発生する不具合はこんなに簡単には原因がつかめないかもしれない。しかし、時代はそういった複雑な安全機能・安全性能を求めている。

トヨタ自動車は自動車メーカの中では唯一プリクラッシュ・ブレーキシステムをCMで大々的に宣伝せず、あのろくでもない読み切る前に消える免責事項の表示もしていない。おそらく、プリクラッシュ・セーフティシステムに不具合が絶対に起こらないこともないとは思っていないし、仮に起こったとしてもCMで免責を表示しているからといってユーザに責任を押しつけることなどできないから、そうしないのだろう。

そして、実際問題が起こったらソフトウェアを修正して粛々とリコールをする。それが正しい自動車メーカとして立ち振る舞いだと思う。

CMで免責を表示している他の自動車会社は事故が起きたときに、免責出しているので不具合があっても許してくれと言うのだろうか。そんな言い訳は通用しないのだから、一刻も早くCMの免責表示を取るべきだと思う。

さて、ISO 26262 はこのような複雑化した自動車ソフトウェアシステムの不具合の再発防止に役立たなければ、まったく意味がないと思っている。

だから、ISO 26262 を推進している担当者やコンサルタントは、上記のような不具合は ISO 26262 を使ってどうやって防止するのか現場のエンジニアに説明して欲しい。

自分は自動車業界の産業構造と、自動車業界の産業構造を意識した規格である ISO 26262 は、このような問題には有効には働かない（どこかに方法は埋め込まれているのだろうが、上手くマネジメントされる気がしない）と感じている。

数年後、自動車への安全要求が多様化した後、分かりにくい不具合が増えてくる。そして、電気自動車の割合が増えて、聞いたことがないメーカの車が出てくると、分かりにくい不具合が一気に増えて社会問題になるだろう。

そうなって初めて、自動車業界は現在の産業構造のままでは問題を解決できない、サプライヤにISO 26262 の適合を押しつけただけでは、安全を確保できないことに気が付くようになる。

そうなるには、あと数年以上はかかると見た。そして、自動車メーカもサプライヤもそういった痛い目に遭わなければ、真剣にリスク分析やリスクコントロール設計を学ぼうと思わないと悟った。

だから、ISO 26262との向き合い方の特集記事はいったん今回で終わりにすることに決めた。

時代が再び自分の知識や経験を求めるようになったら、また書き始めようと思う。

長い間、特集記事「ISO 26262との向き合い方」におつきあいいただきありがとうございました。

※ブログ「組込みソフトウェア工房」は続きますので、記事のリクエストは引き続き募集します。単発で ISO 26262 の記事を書くことはあります。

P.S.

2013年7月1日に『トヨタの部品共通化、海外メガサプライヤーに好機到来』という記事が掲載された。部品が共通化し中小のサプライヤが淘汰されメガサプライヤーに集約されるとう内容だ。どっちにしても、自動車業界はサプライヤの供給部品を組み合わせて使うサプライチェーンの仕組みは変わらないらしい。安全の考え方も Fault Avoidance をやめるつもりはないようだ。安全機能が複雑化したときのことは考えているのだろうか。