4月17日に募集要項を公開してから2日間で事務局宛に11名の応募があったようだ。（定員は30名なので参加を検討されている方は早めに申し込んで欲しい）
東京近郊以外の遠方から申し込んでいただいた方も半分くらいおられるので、その方達の期待に添う内容にしたいと思っている。
セミナで使うスライドはまだまだこれから作成、ブラッシュアップしていくので、参加を希望されている方達の業務ドメインを眺めながらそれぞれの実務でイメージが湧くような事例を多く紹介しようと思っている。
なお、このブログで ISO 26262 の特集記事を書いていることもあって、現在のところ自動車系のドメインの方の申し込みが多い。（自動車ドメインに特化した内容ではないので、他のドメインの方も来て欲しい）
この記事では、『ソフトウェア安全分析・設計セミナ』が、他の ISO 26262 に代表される機能安全のセミナとどこが違うのかを説明したいと思う。
プロセスアプローチの話をするつもりはない
このセミナでソフトウェア開発のプロセスアプローチの説明をくどくどとするつもりはさらさらない。そこが他のセミナとの違いだ。 ISO 26262 に代表される機能安全のセミナは、必ずソフトウェア開発プロセスの話から入り、ソフトウェア開発プロセスの重要性を説き、ソフトウェア開発プロセスのマネジメントの話をし、場合によっては、プロセス管理に有効とされるツールが紹介され、コンサルテーションを勧められる。ISO 26262 だけでなく、ISO 9001 以下、ほとんどの品質要求がプロセスアプローチをベースにしているのでしようがないが、自分はこの流れに対して常に違和感を感じてきたエンジニアの一人だ。
プロセスアプローチを否定するつもりはまったくないが、特に日本のプロジェクトの場合、そこから入ると本質を見失うような気がしてならない。
自動車ドメインの方達はもしかすると自分が考えるこの違和感に慣れていないのではないかと思っている。特に自動車ドメインではハードウェアエンジニアの人や、ハード・ソフト込みでコンポーネントに対する責務を負っている人達、品質保証部門の方達が今後の方向性が分からなくなっているような気がする。
自動車業界では、昔からソフトウェアの開発に対してプロセスアプローチが求められてきた訳ではない。今回 ISO 26262 が国際規格になって初めて、ソフトウェア開発にプロセスアプローチが求められた。それまでハード屋さんは、ソフト屋さんにソフトウェア開発に関するすべてを委任してきた。ところが、ISO 26262ができて、ソフトウェア開発にプロセス要求が求められていることに気がついた。
そこで、ソフト屋さんに「これらの要求は当然これまでもやってきていて、できているんだよな」と尋ねる。ところが、その回答の歯切れが悪い。「当然、できています」という答えが返ってこないのだ。
そこで、ハード屋さんやQA担当は、「だから、ソフトウェアで問題が起こるんだ」「国際規格にも適合できないような作り方をしているから問題を起こすんだ」とはや合点する。
自動車ドメインのソフト屋さんを代弁して言う。「そうじゃないからね」。
日本の自動車産業の組込みソフトウェアの品質は海外のソフトウェアの品質より格段に高かったし、今でもその品質を高く保っている。
そして、それが達成できている理由は、下記の図にあるように文化の違いともの作りのアーキテクチャの違いから来ている。
欧米のもの作りでは「ルール/責任」を重視し「システム/ツール」を使いこなすのが得意だが、「品質を心配する意識」が低い。一方、日本のもの作りでは、「ルール/責任」は重要視せず、「システム/ツール」を使いこなすのが下手だが、「品質を心配する意識」がものすごく強い。それも、マネージャクラスの意識だけが強いのではなく、プロジェクトメンバー全員の意識が高い。そして、システムのアーキテクチャがコンポーネントの組合せではなく、すり合わせたような作り方をする。
サンプルは少ないかもしれないが、日本のソフトウェアに起因する不具合が修正されるスピードは欧米のそれに比べて格段に早い気がする。
海外の開発品で不具合の現象がはっきり出ているのに、なんだかんだ理由を付けて改善のためのアクションを起こさないという例を数多く見てきた。
責任の所在があっちだ、こっちだと言っているうちの時間だけがどんどん経過していくというケースもたくさんある。
それに比べると日本のソフトウェアプロジェクトでは問題が起こったという情報が伝わってきた時点から、猛然と原因を調べ始める。これは「品質を心配する意識」が強く、恥の文化があるからだと思う。
逆の言い方をすると、欧米の文化では、「品質を心配する意識」が弱く、恥の文化がないから、ソフトウェア開発プロセスをがっちり管理しないと、品質が上がらないのだ。
ソフトウェア品質系の国際規格で問題解決プロセス(Software problem resolution process)がやたら強く要求されていて、何でだろうと考えていた。
問題解決プロセスの例 (Software problem resolution process)
- 問題報告の作成
- 問題の調査
- 関係者への通知
- 変更管理プロセスの使用
- 記録の保持
- 問題の傾向分析
- ソフトウェア問題解決の検証
- 試験文書の内容への要求
すべてのケースでそのやり方がよいとは思わないが、通り一遍の問題解決プロセスの適用はかえって顧客満足度を下げる結果になると思う。
だから、プロセスアプローチ至上主義のような説明は本セミナではしない。
自動車ドメインの例で説明するとこうなる
だからといって、自動車ドメインのソフトウェア開発のあり方がいままでのままで何も変えなくてもよいとは考えていない。そう考える理由を一つの例で説明しよう。
そして、それらの三つの基本要素はハードウェア的にもソフトウェア的にも独立していた。
それは設計としては美しい。それぞれの機能・性能要素の関連が疎でり、独立性が高い状態で維持できていれば、システム全体としての複雑性を回避できるし、何か問題が起こったときでも、どこに不具合の原因があるのかがすぐに分かる。
さらに、コンポーネントごとにサプライヤを分離できるため、設計上だけでなく問題が発生したときの責任も明確になる。
完成度の高いコンポーネントを組み合わせることで製品全体の信頼性が高まる。
このようなアーキテクチャはセーフティの観点から見るとフォールドアボイダンス(Fault Avoidance) と言う。
しかし、現代の自動車のシステムはこんなに単純な構造ではない。
高凝集、疎結合のコンポーネントの組合せではなくなってきている。前述したすり合わせのソフトウェア構造が有効なのは、基本機能・基本性能のコンポーネントの中の話だ。「走る」の機能・性能を司るコンポーネントの内部である程度のすり合わせがあるのは総合的にプラスに働くことがある。（競争力の高いコア資産の形成に有利）
ハイブリッド車では「走る」と「止まる」はすでにエネルギーの回収をすることで結合しているので、今後、自動車のシステムアーキテクチャはどんどん複雑になって結合を強めていく可能性がある。
その結果、コンポーネントごとに明確だった責務が「走る」「曲がる」「止まる」にまたがってくる。
このことは不具合が起こったときの対処や、そもそも安全を考慮した設計ができているかどうかの確認の所在が、サプライヤをまたがる可能性が出てきたということだ。
この状況はこれまでの強みだった日本の良さを消しかねない。自動車のシステムアーキテクチャの変化が、日本的なもの作りのやり方のアドバンテージを低下させようとしている。
そうなると、欧米的なプロセスアプローチを取り入れないと安全が確保できないかもしれない。
リスクマネジメントとセーフティアーキテクチャの重要性
ただ、自分は日本のもの作りにおいて、今後も世界の優位に立つための必要なのはリスクマネジメント（リスクアセスメント+リスクコントロール）とセーフティアーキテクチャ設計だと考えている。そこを押さえた上で、プロセスアプローチを取り入れていけばよい。
こういった話を織り交ぜながら、セーフティの考え方と具体的な実践手法を6月7日のセミナでレクチャーしたいと思っている。
今回の記事では自動車ドメインでの例を取り上げたが、参加者の業務ドメインを見ながらどのドメインにも通じるような話をしたいと思う。
P.S.
自動車業界でも医療機器業界でもUSでは規制をクリアするために必要な知識・スキルをを身につけるセミナはだいたい3日間で$1500～$2000くらいかかる。（1日あたり $500 以上） これに宿泊代や飛行機代がかかるから、結果としてものすごい金額になる。（例えば、こんな感じ。大学のセミナだってそれぐらいかかる。）
0 件のコメント:
コメントを投稿