ISO 26262 を商売とする各社の営業活動が活発になってきたことから、そろそろ現場のエンジニアにも「ISO 26262に関して調べろ」とか「体制を作れ」といった指示が飛んできているに違いない。
ISO 26262 は基本的には自動車の安全に関して開発プロセスをマネージメントせよという規格だから、それぞれの所属組織の開発プロセスを見直すことが必要だとみな考えるだろう。
それはそれで間違ってはいないと思うが、この後日本のソフトウェアエンジニアが多くの違和感を感じるはずだ。
【日本の技術者が感じる疑問と違和感】
- ISO 26262 のプロセス認証を取得すると自分達の開発するソフトウェアが安全で信頼できるようになるのか。
- ISO 26262 の認証を取っているツールを使うと自分達の開発するソフトウェアが安全で信頼できるようになるのか。
- どこまでやれば終わりが来るのか。
この疑問一つ一つに答えていこう。
ISO 26262 のプロセス認証を取得すると自分達の開発するソフトウェアが安全で信頼できるようになるのか？
答えは No。まず、プロセスをマネジメントすることで安全を確保することはできない。プロセスは自動車の安全に対して直接作用するわけではない。安全は想定したリスクに対する分析とリスクコントロールの実装・実現によって確保される。プロセスはリスク分析やリスクコントロール手段の実現をマネジメントするように求めるかもしれないが、それは間接的な要求であって直接の要求ではない。だから、プロセスをマネジメントすることで安全や信頼が確保されるとは言えない。特に安全に関しては、必ず「何に対して安全と言うのか」「その具体的な根拠は何か」が答えられないといけない。プロセス要求の適合ではその質問には直接答えられない。
車の安全について、リスクコントロールのソフトウェアについて何をやってきたのか、何が危ないのかを一番よく知っているのは誰なのか。それは、車の設計者でしょ。プロセスは漏れや抜けをなくすことに貢献し、組織全体のマネジメント力を高めることに役立つが、リスクコントロール手段の一つ一つを実装するように設計するのはエンジニアだ。
「プロセスをマネジメントすることで安全を確保することはできないが、世界は安全の実現をプロセスで説明することを求めている。」 なんでこのような禅問答のようなことを言うのか、それは特に日本のソフトウェアエンジニアはこのことを意識していないと、規格適合の活動が自動車の安全や信頼に結びつかないからそう言っている。
そもそも、ソフトウェアの開発プロセスを管理することによって、ソフトウェアの品質を確保するという考え方は欧米で1970年代から構築されてきた長い歴史がある。しかし、1980年代、1990年代、2000年代と、日本の組込みソフトウェア製品は欧米の製品に対して品質面で劣っていただろうか。
ISO 26262 を商売にしようとしている会社は、みな「日本は欧州よりも遅れている」「国際標準に追いついていない」と声高に主張するが、「じゃあ、プロセスアプローチを進めてきた欧米の製品は日本の製品よりも、安全で信頼できていたのかよ」と聞き返したい。
自分は自動車を含む日本の組込みソフトウェアは、プロセスアプローチ至上主義ではなかった日本の製品の方が、欧米の製品よりも品質が高かったと思っている。
ようするに、欧米発のソフトウェアプロセスマネジメントよりも、日本のソフトウェア技術者が行ってきた“何か”の方が優れていたのだと考えている。（詳しくは『
USとJapanの文化の違いと商品品質との関係』の記事を参照のこと。）
左図は、GD3 コンサルティング代表/JMAC GD3 センター長 の吉村達彦氏が日科技連主催の第15回 品質機能展開シンポジウムのプレゼンテーションで使った図だ。
吉村氏はトヨタ自動車に約30年務め、その後九州大学教授を経て、GM(General Motors)の Executive Director Reliability & Durability Strategy の仕事をし、GD3コンサルティング代表に至る。
GMに3年間いてそのときに感じた日本とアメリカの文化の違いを表したのがこの図である。この図は日本人とアメリカ人の違いを端的に表してる。
図が意味するところは、アメリカ人（吉村さんの経験ではGMのこと）はルールと責任はしっかりしており、システムやツールを構築することには長けているが、品質を心配する意識が小さい。一方、日本人（吉村さんの経験ではトヨタのこと）は、品質を心配する意識はとても大きいが、ルールや責任を重要視する姿勢は小さく、システムやツールの構築もアメリカほどは進んでいないということだ。
特に、アメリカのカルチャーの問題点として次のことを指摘されていた。
【アメリカのカルチャーの問題点】
- 明確に責任や役割を定義すると・・・品質は他の人の仕事だと思ってしまう。
- すばらしい支援システムを作ると・・・現地に行って現物を見て考えたり、心配したりする必要はないと思ってしまう。
したがって、品質を心配する意識をもっと大きくしなければいけない。製造業はエンジニアとテクニシャンの創造的技術・技能を製品に付加して利益を得ている業種であり、創造的技術とは問題を発見してそれを製品の価値に変換する能力である。発見するということはシステムやツールでできるものではなく、人間の行為であり、製品に価値を付ける上で意識がもっても大切であると説明されていた。
システムやツールで問題点を発見しやすくすることはできるけれども、そこには気づきが必要であり、気づくためには品質を心配する意識が必要であるということだ。
ISO 26262 が求めているのは、この図でいうシステム（=プロセス）やツールであり、品質を心配する意識ではない。そして、自分は日本人の品質を心配する意識の強さが、日本の組込製品の品質の高さだったのではないかと考えている。
だから、ISO 2626 がシステムやツールを日本人の技術者に要求するのは苦手な部分、不足している部分を強化しようというプラスの力が働く反面、もともと強かった「品質を心配する意識」が製品の安全や信頼を実現していたことを忘れて、これまで築き上げてきた製品品質を落としてしまわないか心配しているのだ。
品質というよりは安全を確保する力が弱まることが心配だ。このような背景が分かっていない実績を積み重ねてきたベテランのエンジニアは、ISO 26262の要求に嫌気がさすと同時に、意味がないことをやらされていると感じるに違いない。
そんなときは、この特集記事を今一度最初から読み直してみて欲しい。日本のソフトウェアエンジニアの強みと弱み、過去と現在と未来について何ができていて何ができていないのか分かるはずだ。
さて、プロセスに関してもう一つ図を見ていただきたい。この図は『
ソフトウェア品質論の歴史的推移』の記事で取り上げた図で、日科技連主催のソフトウェア品質シンポジウム2010（SQiPシンポジウム2010）で広島市立大学の大場充先生が講演された内容を図にしたものだ。
この図で示したかったのは、プロセス重視のソフトウェア品質論は1970年代から連綿と続いていて今のなお強固な考え方である一方、日本では当たり前品質／魅力的な品質といった、商品の価値や顧客満足に根ざした品質向上の取り組みが行われてきたという事実である。
このことは、前述の US と Japan の文化の違いとよく符号している。US はプロセス重視で、システムやツールを使うことに長けており、Japan は品質を心配する意識が強く、価値や顧客満足重視で商品の品質を高めてきた。
ISO 26262 の規格適合を日本で目指すのなら、技術者はこの二つの図を頭の中にたたき込んでおいて欲しい。そして、自分達の良さを消すことなく、足らない部分を補って欲しいと思う。
最初の質問、「ISO 26262 のプロセス認証を取得すると自分達の開発するソフトウェアが安全で信頼できるようになるのか」にもう一度答えると、日本のソフトウェアエンジニアがこれまで安全や信頼を確保するためにやってきた取り組みを殺すことなく、取り入れることができらば Yes であり、日本人の特性を無視して欧米的なやり方をごり押しされたら No になる。
これは、東京大学 ものづくり経営研究センター センター長、東京大学 大学院経済学研究科 教授の藤本隆宏先生が『
日本もの造り哲学（p125 図10 アーキテクチャとは何か）』で日本のものづくりの方法をインテグラル型として表した図だ。（こちらの記事『
すり合わせと組み合わせ』も参考されたし）
藤本先生は、ものづくりの機能と構造の関係をモジュラー型とインテグラル型、すなわち、組み合わせとすり合わせに分類でき、日本の自動車の作り方はインテグラル型（=すり合わせ型）で、インテグラル型は機能とサブシステムの関係が一対多で、機能とサブシステムが複雑に絡み合っているがユーザーニーズに対して最適解を得られるとしている。
一方、モジュラー型は機能とサブシステムが一対一になっていて、真似すること、アセンブリメーカーとしての市場参入が容易である。ISO 26262 の流れに乗って、日本の自動車のものづくりを組み合わせ型に変更し、個々のモジュラーの信頼性を高めることに精力を注いでいると、日本のサプライヤーは欧米のサプライヤーに飲み込まれるか、アジアの振興サプライヤと三つ巴で消耗戦を繰り広げることなるだろう。そうなったら日本の自動車のものづくりは衰退するだろうし、消費者にとってもかゆいところに手が届く商品は減っていくだろう。
自動車の安全を可視化するのは重要だが、だからといってものづくりのやり方全部をすり合わせから組み合わせに変えてしてしまうと自分のクビをしめることになる。機能と構造が絡み合ったノウハウが隠蔽されたモジュールをその組織のコアコンピタンスにしてアドバンテージにしていかないと、すぐに代替えが用意されてしまう。
ISO 26262 の認証を取っているツールを使うと自分達の開発するソフトウェアが安全で信頼できるようになるのか？
これは単純に No だ。最初の質問にも関係があって、ツールを使いこなすことに長けている組織、プロジェクトなら Yes になる可能性があるが、品質を心配する意識でこれまでの実績を築き上げてきた日本のプロジェクトでは成功の確率は低い。
そうでなくても、これまでに宝の持ち腐れになったツールの一つや二つはあるだろう。日本のプロジェクトではツールをトップダウンで導入するよりも、ボトムアップでじわじわと広げていくことが多いと感じる。この際、プロジェクトリーダーのリーダーシップが必要であり、このとき品質を心配する意識がプロジェクト全体を方向性を一つにできればツールは有効に働く。しかし、認証が取れたツールだから使いなさいと言われたら逆に品質を心配する意識は低下するだろう。
日本では、まったく同じツールであっても、規格の認証が取れているからという理由で採用したら有効には活用されず、認証とは関係なく組織やプロジェクトが商品の安全や信頼のために必要だと思って採用した場合は有効に活用される。プロジェクトメンバの意識が一致していればうまくいくし、押しつけられたらうまくいかないといののが、日本のソフトウェアプロジェクトの特徴だ。
欧米ではシステムやツールを上手に使いこなす下地や国民性があるから、そのようなまどろっこしい問題は起きないのだろうが、日本ではそうではない。この点を理解しないでツールを導入するともう一つ宝の持ち腐れが増えるだけだ。
どこまでやれば終わりが来るのか？
当たり前だが、規格の認証を取ることがゴールではない。安全で信頼できるソフトウェアをすでに提供できているのならゴールに到達しているとも考えられる。足らないのは説明責任だ。だから、今自分達がやっていることを、規格の要求に基づいて説明できるようになればそれがゴールとなる。
そのとき気をつけたいのは、自分達がやってきた安全や信頼に対する良い取り組みを規格要求の答えとして何とか説明することをまず考えることである。その努力をせずに、自分達がやってきたことをあっさり否定して、欧米的な要求を神のお告げのように捉えてはいけない。規格要求の文言通りに何でもかんでもやらなければいけないと考えるのは間違いだ。
もしも、今現在、安全で信頼できるソフトウェアを提供できていないのなら、それができるようになることがゴールとなる。ただ、問題なのは、日本でそんな問題が起こっているのなら、それは単独の機能ではない可能性が高いということだ。一つのサプライヤだけでは解決できない、複合的に絡み合った要求仕様、機能や性能の実現方法に絡んだ問題があるときだろう。
この場合、サプライヤ単独では問題は解決できない。機能安全はそもそも、サプライチェーンを意識しすぎているから、その点に弱点を持っている。信頼性の高い部品の組み合わせで安全は確保できない。ISO 26262 はシステム全体の安全マネジメントを取り入れたぶん、自動車メーカーとサプライヤが一体となってマネジメントできれば対応できるかもしれないが、現実には難しい点が多いと感じる。複数のサプライヤにまたがってリスクコントロールを実現していることを可視化して証明するのはとても難しい。
またの機会にそれについて語りたいと思う。
