2013-01-21

ブログへのコメントとリクエストへの返答

組込みソフトウェアギルドの仲間である山崎さんからこのブログに対してテーマリクエストがあったのと、ブログの記事『ISO 26262との向き合い方 (11) ASILの分解は本当に可能か』にコメントをいただいたので、今回はそれに答えてきたいと思う。

なお、このブログの記事にコメントするのはコメント自体が公開されてしまうのでハードルが高いと考えている方もいるかもしれないと思い、MassesgeLeaf を導入したので是非使ってみて欲しい。ブログの右下に現れている緑のロゴをクリックするとコメントを書く領域が現れるのでここにメッセージを書く。そうするとブログの著者だけにFacebookのIDでメッセージが送られる。

ブログにもらったコメント

今回のブログをISO26262について調べていてたまたま発見し、大変面白く読ませていただきました。 私はISO26262を遵守した設計をするシステムLSIの設計にかかわってます。 
ソフトウェアと同様にシステム構成を持つLSI(当然組み込みソフトと協調して動作します)の場合も、同様な問題があり、正直言って、この規格に従ったところで安全性が高まると思えない部分が多くあります。一方、とりあえず、商売のために規格を遵守し、そのエビデンスを作成する。(手法が定義されていない部分は、このように定義した手法で解決しているとエビデンスを残す)ことによりISO26262を遵守した設計を行っています。 
ヨーロッパの人にそんなに知り合いは多くないですが、議論をすると必要性や、理由をしつこく聞いてきて、彼らが納得しないと何もしない。という気がします。厳格な(様に見える)規格を作りそれを守っているから品質が高いと言い切り、その規格を強制させないと話が始まらないかとも思いました。(気に入らなかったら、カウンターの規格等で対抗せよというスタンス) 
どちらにせよ、国内のメーカーも規格化等がめんどくさいので同じ要求となると、仕事がめんどくさいことになるとは思っています。 
今後も、いろいろ発信してください。
このコメントをもらってまず思ったのが、LSIの設計にも ISO 26262 の適用が始まっているんだ、という感想だ。医療機器の世界では まず、IEC 60601-1:2005 医用電気機器―第1部:基礎安全及び基本性能に関する一般要求事項 という規格があって、これに適用できていないと日本を含む諸外国で医療機器を売ることができない。(法規制の範疇に入っているということ)

この規格は2版までは通則(この規格には通則と副通則がある)にソフトウェアに対する要求が入っていなかったが、3版になってソフトウェアに対する要求が独立した箇条として追加された。

IEC 60601-1:2005 の安全に対する要求は基本的にハードウェアとソフトウェアに分かれており、設計のプロセスにまで踏み込んでいるのはソフトウェアの方だけだ。そして、LSIに搭載するロジックがソフトウェアか否かについては未だにはっきりとした判断がなされていない。

一方でISO 26262 は未だ法規制にはなっていないのに、すでに対応されている技術者もいて、さらにLSIの設計にも適用されているということに驚いた。発注元の自動車会社が要求してくれば、法規制がどうかは関係なく適用が求められるのだろう。

「ISO 26262 が提唱する開発プロセスや設計手法を実践する」 = 「システムの安全が確保される ではないということ」は、このブログで何度となく説明してきた。(『ISO 26262との向き合い方 (20) 品質と安全の違い』参照のこと)

一方で、「ISO 26262 が提唱する開発プロセスや設計手法を実践する」 と 「システムの品質が向上する」 は相関があると思う。品質の向上がどの程度安全確保につながるかは、国や個人によっても考え方は異なるだろう。だから、日本人と欧米人との考え方の違いについて国を超えて議論していくしかないと思う。

そこで、ひとつ提案がある。自分が、最近使っているのは LinkedIn という SNS だ。Facebook と同じように実名使用が基本だが、ビジネスユースで使っている人が多いSNSだ。

LinkedIn にはさまざまなグループがあって ISO 26262 Functional Safety というグループもあり、自分もこのグループに最近入った。自分のドメインのグループのコメントを見るの精一杯でこちらのグループのコメントはじっくり読んでいないが、次のようなディスカッションが複数投稿されている。
Confirmation of ASIL D compliance measures used for protocol conversion controllerWe are developing a system with one of the safety goal at ASIL D level. This system has a microcontroller only for converting SPI data to CAN data.
 :
Are above measures sufficient to ensure, ASIL D compliance of this microcontroller? We have selected a single core microcontroller. Want to verify correctness from experts in this community.

日本の自動車系エンジニアも LinkedIn の ISO 26262 のグループに参加して、いろいろな国のエンジニアやコンサルタントの意見を聞いてみたり、自分の考えをぶつけてみたりしたらどうだろうかと思う。

現場の問題は、現場の関係者同士でディスカッションするのが一番だ。そして、グローバルマーケットで仕事をしなければならなくなった現在ではディスカッションもグローバルにやらないとわかり合えないと思う。日本の品質にエンジニアが自信を持っているのならば、そのことを根拠を持って説明しなければいけないと感じる。

安全性に関心のある初学者(学生,技術者)は何から勉強すればいいか?

つぎに山崎さんからもらったテーマについて考えてみたい。実はこの話は意外に深い話である。なぜなら、医療機器にしろ、自動車業界にしろ、安全に対する関心が高まってきたことで関係する技術者に対する教育のことも考えなければいけなくなってきているからだ。

セーフティについて学習するべきことは大きく「リスクアセスメント」と「リスク低減策」の二つに分かれると思っている。ソフトウェア技術者の場合は、ソフトウェア工学も知っていた方がよいが、それは安全に特化した知識ではないのでこれ以外にベースとして習得するべきものとする。

また、リスクアセスメントの前に「要求分析」の知識、スキルは必要である。これはソフトウェアに特化したものではなく、顧客要求や安全に関わる要求も含めて、要求仕様を分析する技術だ。

商品には顕在的価値(Real Value)と潜在的価値(Potential Value)があり、安全要求は潜在的価値の側に含まれる。カタログに掲載されるような機能や性能は顕在的価値に含まれ、コスト低減要求は潜在的価値の方になる。これらの要求は常に入り乱れ、商品開発の際にトレードオフの材料となる。

安全に対する要求は表面的にはクローブアップされないものの、いったん事故が起こると大変な騒ぎになるので、要求分析の段階でこれらの優先度が整理されている必要がある。セーフティ・クリティカルな商品、システムの場合は、安全に関する潜在的価値としての要求優先度は最も高くなる。

商品に対する要求分析をしっかりやっていないと開発の途中でころころ変わることがある。ステークホルダの鶴の一声で採用されたり削除されたりすると後でとんでもないことになることもある。だからこそ、安全に関する分析を行う者は要求分析の技術を習得しておいた方がよい。

安全設計に関わる技術者は下記の開発の流れの中で赤の部分で使う知識・スキルは必須で身につける必要があり、青の部分もできるようになっているとよい。ようするに開発のライフサイクルの上流に関係する技術が必要だということだ。

【セーフティ・クリティカルな製品の開発ライフサイクルの例】
  1. システム要求分析
  2. リスクアセスメント(リスクの特定+リスク分析+リスク評価)
  3. リスク低減策の立案
  4. ハード/ソフトの分離
  5. ソフトウェア要求仕様の策定
  6. ソフトウェアアーキテクチャの設計
  7. ソフトウェアの実装
  8. ソフトウェアの検証
  9. システムの妥当性確認
  10. ソフトウェアのリリース
なお、リスクアセスメントができるようになるには、どんなリスクがあるのかを分析しなければならないのでドメイン知識が必ず必要になるが、そう言ってしまうと、就職前の学生さんや転職してきた技術者はドメイン知識がたまるまで何もできないことになってしまう。

また、リスクアセスメントに必要な分析技術、評価技術は基本的には実装の手段には関係ないはずである。ようするにハードウェア技術者の分担とかソフトウェア技術者の分担とかは決まっていないはずだ。じゃあ、品質保証担当がリスクアセスメントをやるのかというと、彼らには商品が使われる環境に対する知識が十分でないことがある。実際には、リスクアセスメントは商品に責任を負っている製品担当者、多くの場合ハードウェアエンジニアがやっていると思う。

しかし、ずっとそのままでいいのだろうかと思う。というのは、リスクマネジメントは繰り返しのプロセスで続けていくため、同じ商品群の差分開発の中でやっていくことが多い。この点はソフトウェアの再利用の技術、ソフトウェアプロダクトラインと関連がある。

既存の技術、既存のシステムに新たな要求を追加、修正する設計をしながら、システムの安全を確保するには、今現在、システムがどのようなアーキテクチャで成り立っているのか、どのようにリスク低減策を実現しているのかを知らないといけない。

リスクアセスメントの際にこれは設定上の対策で対応するかしないか、コストは見合うかどうか、現行製品のアーキテクチャを大幅に変える必要があるのかないのか、最新の技術を使うことによってリスクは低減できるのかどうかといった高度な判断をしなければいけない場面も出てくる。だから、リスクアセスメントの行う者は設計技術についても幅広く知っていた方がよい。

また、今後システムにおけるソフトウェアの割合が増え、ユーザーインタフェースにリスク低減策に果たすソフトウェアの役割が大きくなっていくにしたがって、ソフトウェアの知識をまったく持たない者だけでリスクアセスメントを担当するのは危ないと感じる。だから、オールラウンドプレイヤーはいなくとも、ドメイン知識を持ちメカ、エレキ、ソフトの各技術を持った者たちが協力してリスクアセスメントに関わった方がよい。

ソフトウェアアーキテクトやソフトウェアプロダクトラインの推進者もいろいろな領域を幅広く知っている必要があると思ったが、セーフティ・クリティカルなシステムのリスクアセスメントを行う者も同様に幅広い知識が必要だと考える。セーフティの方では安全工学に関する知識・スキルがさらに必要となる。

最初のリクエスト「安全性に関心のある初学者(学生,技術者)は何から勉強すればいいか」に立ち戻ると、方法論として知っておいた方がよいものは三つあると思っている。

一つは要求分析を行う際に使う「品質機能展開」。二つ目はFTA、三つ目はFMEAだ。これらの技法は応用範囲も広いので、安全に関する仕事以外にも十分使える。

よくよく考えて見ると、これらすべて日科技連が長年講習を続けている分野である。この3つに加えQC7つ道具を使いこなせるようになっていると何かと便利だ。

本なら下記の二冊をじっくり読んでもらい、ソフトウェアで対応するならどのように応用すべきかを考えるのもよいと思う。(ドメイン知識が必要のない分析手法をマスターして使いこなせるようにすることがよい)

FMEA、FTAの活用 (日科技連信頼性工学シリーズ (7))
FMEA・FTA実施法―信頼性・安全性解析と評価

そして大事なのは、産学が連携して具体的な安全系の問題について産はドメインに特化した話題を、学は分析技術を提供して実際に起きている問題をともに対処していくことだろう。これがうまくいければ技術は発展していくと思う。

2013-01-13

ISO 26262との向き合い方 (20) 品質と安全の違い

これまで安全の領域に携わっていなかった人達が医療機器ドメインに入ってきたこともあってか、ソフトウェアの品質の向上と安全の確保が同意であると考える人が増えてきて困っている。

ソフトウェア品質の向上と安全の確保とは概念が異なることは何度となくこのブログで書いてきたが、今回、機能安全規格である IEC 61508 や ISO 26262 や、医療機器ソフトウェアのプロセス規格であるIEC 62304 の上位に位置する ISO/IEC GUIDE 51:1999  安全側面-規格への導入指針 にそのことがキチンと書いてあったので今回はそれを紹介しようと思う。

ISO/IECガイドとは、ISO と IEC の国際規格制定に関連する共通事項のガイドラインだ。ISO や IEC の規格制定、利用にあたっては ISO/IEC ガイドに留意する必要がある。例えば、下記のようなガイドがある。

ISO/IEC GUIDE 2 (2004)
Standardization and related activities -- General vocabulary
標準化及び関連活動-一般用語

ISO/IEC GUIDE 21 (1999)
Adoption of International Standards as regional or national standards
国際規格の国家規格への採用

ISO/IEC GUIDE 51 (1999)
Safety aspects -- Guidelines for their inclusion in standards
安全側面-規格への導入指針

これらは、ISO/IEC 規格を策定する際の共通事項のガイドなので、IEC 61508 も ISO 26262 も  IEC 62304 もこれらのガイドに考慮する必要があるという訳だ。

今回、紹介するのは ISO/IEC GUIDE 51:1999 で、規格に安全に関する側面を導入する際の指針である。

なお、安全に関しては 日本では明治大学  理工学部  情報科学科の 向殿 政男 教授が有名である。向殿先生は、日本テレビ「世界一受けたい授業」やNHKの「クローズアップ現代」などにも出演されているのでテレビで顔を見たことがある方もいると思う。

向殿先生は ISO/IEC GUIDE 51 を解説した本『安全設計の基本概念―ISO/IEC Guide51(JIS Z 8051)、ISO 12100(JIS B 9700) (安全の国際規格) 』も出されているが、インターネット上の ISO/IEC GUIDE 51を説明した資料『2006-10-4日機連シンポジウム:「機械安全」の新しい波「機械安全」を取り巻く最近の動向』も公開されているのでそれを読むのもよいと思う。

なお、ISO/IEC GUIDE 51は JIS Z 8051:2004 として JIS にもなっているので、このガイドのもとを日本語で読むことも可能である。


安全の定義

ISO/IEC GUIDE 51 によると安全(safety) とは 『受容できないリスクがないこと』 (safety: freedom from unacceptable risk) とある。この定義は非常に重要なのでクリティカルデバイスの開発に携わる技術者は頭の中にたたき込んでおいて欲しい。(受容できないリスク = unacceptable risk がキーワード。Risk は Acceptable か Unacceptable かを判断する。)

安全の概念について ISO/IEC GUIDE 51に解説がある。
安全という概念
安全は,あらゆる技術領域にまたがり,かつ,ほとんどすべての製品,プロセス及びサービスのための規格で扱われている。市場に投入される製品,プロセス及びサービスは,ますます複雑化しており,安全の視点に立った配慮の優先度を高くすることが求められている。 
絶対的な安全というものはありえない。この規格で残留リスクを定義しているように,ある程度のリスクは残る。そのため,製品,プロセス又はサービスは,相対的に安全であるとしかいえない。
安全は,リスクを許容可能なレベルまで低減させることで達成される。許容可能なリスクは,絶対的安全という理念,製品,プロセス又はサービス及び使用者の利便性,目的適合性,費用対効果,並びに関連社会の慣習のように諸要因によって満たされるべき要件とのバランスで決定される。したがって,許容可能なレベルは常に見直す必要がある。技術及び知識の両面の開発が進み,製品,プロセス又はサービスの使用と両立して,最小リスクを達成できるような改善が経済的に実現可能になったときには,特に見直しが必要である。
許容可能なリスクは,リスクアセスメント(リスク分析及びリスクの評価)によるリスク低減のプロセスを反復することによって達成させる(図 1 参照)。
下記に「リスクアセスメント及びリスク低減の反復プロセス」の図を示す。


また、この図に出てくる用語も重要なので、言葉の定義を開催しておく。

 リスク (risk):危害の発生確率及びその危害の程度の組合せ。

危害 (harm):人の受ける身体的傷害若しくは健康傷害,又は財産若しくは環境の受ける害。

危険事象 (harmful event):危険状態から結果として危害に至る出来事。

ハザード (hazard):危害の潜在的な源。備考  ハザードという用語は,起こる可能性のある危害の発生源又は性質を定義するために用いることが一般的に認められている(例えば,感電,押しつぶし,切断,毒性によるもの,火災,おぼれなどのハザード)。

危険状態 (hazardous situation):人,財産又は環境が,一つ又は複数のハザードにさらされる状況。

許容可能なリスク(tolerable risk):社会における現時点での評価に基づいた状況下で受け入れられるリスク。

保護方策 (protective measure):リスクを低減するための手段。
備考  保護方策には,本質安全設計,保護装置,保護具,使用上及び据付け上の情報並びに訓練によるリスクの低減策を含む。

残留リスク (residual risk):保護方策を講じた後にも残るリスク。

リスク分析 (risk analysis):利用可能な情報を体系的に用いてハザードを特定し,リスクを見積もること。

リスクの評価 (risk evaluation):リスク分析に基づき,許容可能なリスクに到達したかどうかを判定する過程。

リスクアセスメント (risk assessment):リスク分析及びリスクの評価からなるすべてのプロセス。

意図した使用目的 (intended use):供給者が提供する情報に基づいた製品,プロセス又はサービスの使用。

合理的に予見可能な誤使用  (reasonably foreseeable misuse):供給者が意図しない方法であるが,人間の挙動から生じる容易に予測しうる製品,プロセス又はサービスの使用。

品質の定義

品質と安全を比較するために品質に関する情報を示す。

SQuBOK(ソフトウェア品質知識体系ガイド)に品質の定義についていろいろな考え方が書かれているので、参考までに一部紹介しておく。(品質の概念はいろいろあるようだ。)

定義というよりは、つぶやきのようなもの?もある。詳細な説明はSQuBOKを参照して欲しい。なお、品質とソフトウェア品質は区別されていない。
  • 「本来備わっている特性の集まりが、要求事項を満たす程度」[ISO 9000:2005]
  • 「(1) システム、コンポーネント、またはプロセスが指定された要求を満たしている度合い。(2) システム、コンポーネント、またはプロセスが顧客またはユーザのニーズ、または期待を満たしている度合い」[IEEE Std 610.12-1990]
  • 「指定された特定の条件で利用する場合の、明示的または暗示的なニーズを満たすソフトウェア製品の能力」[ISO/IEC 25000:2005]
  • 「品質は誰かにとっての価値である。」[Weinberg 1994]
  • 「システムが本稼働するときに、どこまで真のビジネス(ユーザ)ニーズにあっているかということ。」[Martin 1994]
  • 「一つ目はプロダクトの特性が顧客のニーズに応えることで満足を提供するという観点、二つ目は不備(障害や誤り)から免れるという観点である」[Juran 1998]
  • 「要件に対する適合」[Crosby 1980]
  • 「機能および性能に関する明示的な要求事項、明確に文書化された開発標準、および職業的に開発が行われた全てのソフトウェアに期待される暗黙の特性に対する適合。」[Pressman 2005]
まあ、ISO 90001 の「本来備わっている特性の集まりが、要求事項を満たす程度」で品質を説明しておけば間違いはないであろう。

品質と安全は観点が異なる

一方、ISO/IEC GUIDE 51 には安全に関して次のような解説が書かれている。
安全は『受容できないリスクがないこと』と定義される。すなわち安全は受け入れ不可能なリスクから解放されていることであり「受容できないリスクがない」ことを持って「安全」と規定される。 
安全はリスクを経由して定義され,リスクはその時代,社会の情勢、環境によっても変化するため安全の尺度を一定にすることはできず,絶対的な安全を定義することはできない。そのため,製品,プロセスまたはサービスは相対的に安全であるとしか言えない。
機器製造業者にとってリスクの概念は時代とともに厳しい方向に推移する。機器に施された安全装置、安全対策は消費者や社会が成熟するにつれて「付いているのが当たり前」「対策されているのが当たり前」と捉えるようになるからである。自動車のABS(アンチロック・ブレーキ・システム)が最初に登場したときはオプション機能だったが、今日本ではABSは付いていて当たり前になりつつある。国によって差がある点にも留意して欲しい。(機器の利用環境の成熟度によっても変わる。)

だから、リスクコントロール手段は一度設計すれば終わりという訳にはいかない。時代、社会の情勢、環境によって見直しを続けなければいけない。だから、上記の図は「リスクアセスメント及びリスク低減の反復プロセス」なのだ。機器が市場にある限り、リスクアセスメントとリスク低減は反復しなければならない。
安全は,リスクを許容可能なレベルまで低減させることで達成される。許容可能なリスクは,製品,プロセスまたはサービスにおける使用者の利便性,目的適合性,費用対効果,並びに関連社会の慣習のように諸要因によって満たされるべき要件とのバランスで決定される。 
したがって,許容可能なリスクは常に見直す必要がある。技術及び知識の両面の開発が進み,製品,プロセスまたはサービスの使用と両立して,最小リスクを達成できるような改善が経済的に実現可能になったときは,特に見直しが必要である。
技術は時代とともに進歩する。リスクコントロール手段も新しい技術によって、より効果的な対策に置き換えることができるかもしれない。だから、機器の後継機種を開発する際には、「リスクアセスメント及びリスク低減の反復プロセス」をもう一度回して、よりよいリスクコントロール手段がないかどうかを検討しなおす必要がある。

下記にリスクを受容可能にするための手順を示す。
  1. 製品,プロセスまたはサービスの対象と考えられる使用者及び触れることが予見される者を特定する。
  2. 製品,プロセスまたはサービスの意図した使用を特定し,合理的に予見可能な誤使用を見積もる。
  3. 製品,プロセスまたはサービスの使用(据え付け,保全,修理及び解体,廃棄を含む。)の全段階及び全条件においてハザード(危険状態及び危険事象を含む。)を個々に特定する。
  4. 特定したハザードが引き起こす個々に特定された使用者群及び接触者群に対するリスクを見積もり評価する。
  5. そのリスクが許容可能かどうかを判断する(例えば,類似の製品,プロセスまたはサービスを比較して)。
  6. そのリスクが許容可能なものでなければ,許容可能なレベルまでリスクを低減する。
そして、リスクを低減させる際の優先順位は次の順番になる。
  1. 本質安全設計
  2. 保護装置
  3. 使用者に対する情報
本質安全設計を実現する本質的安全設計方策とは「ガードまたは保護装置を使用しないで,機械の設計または運転特性を変更することによって,ハザードを除去するまたはハザードに関連するリスクを低減する保護方策」である。 
また,保護安全を実現する方策は安全防護策と付加保護方策がある。保護防護策とは「本質安全設計によって合理的に除去できないハザード,または十分に低減できないリスクから人を保護するための安全防護物の使用による保護方策」であり,付加保護方策とは,非常停止,機械などに人が捕捉された場合の救助手段,脱出ルートの設置などを指す。この方策は支援安全機能と考える。
安全はリスクを許容可能なレベルまで低減させることで達成される。リスクを低減させるためには事前にリスクの特定、リスク分析、リスク評価といったリスクアセスメントが必要になる。

このことが安全に責任を負ったことのない人にはピンとこないらしい。品質を高める手法が仮にあったとしても、それがすべてのリスク低減に効くとは限らない。

例えば、OSやアプリケーションソフトウェアが暴走したときにCPUをリセットさせるためのウォッチドッグタイマーというCPUから独立したデバイスがある。一見、ウォッチドッグタイマーはすべてのリスクに有効なリスクコントロール手段になり得るような感じがする。

しかし、ウォッチドッグタイマーだけでは解決できないリスクもある。例えば、医療機器の生体情報モニタには意識のない患者さんの血圧を自動で定期的に測定するインターバル測定の機能がある。健康診断で使う上腕にカフを巻いて血圧を測定するやり方を例えば30分おきに機械が自動的に計測する機能だ。

そして、この非観血血圧測定の国際規格には次のような要求がある。

電源の瞬断があっても、血圧のインターバル測定の設定は維持されなければいけない。

※正確には下記が該当する要求文章。(すべての設定は変更されてはならない)
When the equipment contains an internal electrical power source and is capable of operating from it, and the mains supply is interrupted, does not apply. In this case the equipment shall continue operation, and the mode of operation and all operator settings shall not be changed. (IEC 60601-2-30:1999)
なぜ、こんな要求があるのかと言えば、意識のない患者さんの生体信号を計測している生体情報モニタにリセットがかかって、インターバル測定がリセットされると血圧の測定が中止されてしまう。ナースステーションにいる看護師さんや先生は血圧測定が定期的に行われていると思っているから、患者さんの血圧の変化に気がつかない。

このようなリスクがあるから個別規格にはこんな要求があるのだ。ちなみに、この要求は技術的にどのようにクリアすればよいか分かるだろうか。

まず、血圧のインターバル測定を開始したときは、装置内の不揮発性メモリ(例えばフラッシュメモリ)にその内容を記録しておく。インターバル測定が終了したときにはクリアする。

そして、電源が立ち上がったときに、まず、その領域をチェックしに行きインターバル測定のデータが残っている場合は、何らかの原因でインターバル測定が異常終了したと判断する。

※この方法を実施するには不揮発性のメモリが必ず必要だからコストダウンを理由にフラッシュメモリを取り除くことはできない。リスクアセスメントをしていなければやってしまうかもしれない。

ウォッチドックタイマーによるCPUのリセットはそこだけを捉えれば、信頼性を確保するための有効な手段かもしれないが、どんなシステムに使うのかが分からなければ、リスクの特定、リスクの分析、リスク評価ができないから、リスク低減策として使えるのかどうかを判定できない。したがって、”安全”を示す、すなわち「受容できないリスクがないこと」が言えないのである。

このことは、すべてのリスクに対して有効に働くリスク低減手段は存在せず、個々の製品、プロセスまたはサービスに対してスクアセスメントを行った上でリスク低減策を設計しなければ安全は確保できないことを示している。

これは、製品、プロセスまたはサービスの品質が高いことと安全であるとは同位ではなく、品質の概念と安全の概念の間に異なる観点が存在することを意味している。

品質と安全はビュー(観点)が異なるのだ。このことは、すべてのドメインに共通の品質向上策を武器に商売したい人たちにはとてつもなくマイナスな要素である。

品質の概念の一つに「顧客満足を高める」があり、これが安全の定義である「受容できないリスクがないこと」につながると思うが、どっちにしても安全を確保するためには、リスクを特定、分析、評価することは絶対に必要であり、それは機器やシステムが使われる場面を知っている者でなければできない。

ソフトウェアの品質特性を説くことと、リスクの特定、分析、評価は観点が異なるのだ。このことが分かっていないソフトウェア品質のエキスパートと呼ばれる人と話していても目指しているところが異なるからいつまでたっても議論がかみ合わない。

最後にもう一度繰り返すと、製品、プロセスまたはサービスの品質が高いことと安全であるとは同位ではなく、品質の概念と安全の概念では観点が異なる。

安全を実現するためには、リスクの特定、分析、評価といったリスクアセスメントを行った上で、リスク低減策を考える必要がある。リスク低減策を考える上で品質向上策は役立つかもしれないが、それはあくまでもリスクアセスメントを行った後に初めて判断できる。

そして、リスクアセスメント及びリスク低減のプロセスは、製品やサービスが市場にある限り反復しなければいけない。

したがって、セーフティ・クリティカルな製品を開発しているエンジニアは、リスク低減策について学ぶ前にリスクアセスメントに役立つ技術を習得すべきであると自分は考えている。そうしないと、受容できないリスクがなくなったかどうか判断できないからだ。

2013-01-05

使う側の視点と作る側の視点

新年、明けましておめでとうございます。

2013年の最初の記事に何を書こうかなあと考えている。

組織にいるときは「自分が組織を通じて社会に何を貢献できるのか」を、プライベートな立場では「個人としての自分が社会に何を貢献できるのか」についていつも考えるようにしている。

その中で、新人技術者の教育を始めるに際して、いつも話している事柄があるので、読者の皆さんにも役立つかもしれないと考え、これを紹介しようと思う。

技術者には使う側と作る側の両方の視点が必要

今の時代、社会人になる前にもの作りに触れる機会はかなり減ってしまったと思う。社会が成熟するにつれて、生活の中で不便と感じることを解決するデバイスが次々と供給され、不便がどんどん駆逐されている。

企業が次々と不便を便利に変える商品を投入していったことで、エンジニア予備軍となる若い人たちが、自分のアイディアで不便を便利に変えるくふうの機会が減ってしまった。

だから、多くの若い人たちは使う側の視点しか持たないようになり、かつ、もの=デバイスを使うことは楽しい=FUN という感覚が支配するようになった。

この流れは「当たり前にできていること」に対する関心を薄れさせ、「当たり前にできていること」の裏側にある仕組み、工夫に対する感動やそれを作った人への畏敬の念を忘れさせてしまう。

すべてのエンジニアがみんながそうなってしまったら、日本も終わりだなと思う一方で、そういう環境が若いエンジニアを変質させていることを認識して、じゃあどうすればいいのかを考えるのが我々の仕事だと思う。

だから自分は、冒頭の図を新人技術者たちに示して、これまでは使う側の視点しか持っていなかったかもしれないが、これからは作る側の視点を持ち、それまで自分たちが知らなかった「当たり前にできていることの仕組み」に感動できるようになりなさい、と諭している。

今やTOYOTA だって「FUN TO DRIVE, AGAIN.」なのだ。車は移動の手段ではなく、運転を楽しもうと言っている。

このスローガンは日本がいい意味でも悪い意味でも成熟してしまっていることをよく表していると思う。

こういう世の中で、もの作りをする技術者に不足しがちなのは「要求を実現するために必要な技術に対する飢え」だと感じる。何か足らないこと、不便に感じていることを自分が実現してやるというモチベーションが下がっている。

ある意味それは当然である。ユーザーが解決して欲しい問題はほとんど先人が商品化してしまっているからだ。先人が強いモチベーションで作った商品にちょっとした機能を付け加えたり、改変したりする仕事しかなかったら「よし、やったるぜ」という気持ちにはなれないだろう。

だからこそ、先人の技術者たちは商品を通じて社会やユーザーに何を貢献しようとしたのか、何が貢献できているのか、どんな工夫が貢献に結びついているのかを、新人技術者たちに説明する義務がある。

新人技術者は残念ながら商品を自分の手でゼロから作り上げる機会はほとんどないかもしれないが、商品開発の歴史や課程を知ることによって、貢献の疑似体験をするとよい。

自分が作った製品ではなくても、お客さんから「役に立っている」とか「これが便利だ」と言われれば自分のことのようにうれしいだろう。そして、「ここが良くない」とか「こうなると良い」といった意見を聞いたときに、作る側の視点で製品の中身(アーキテクチャ)が分かっていれば、「こうすれば解決できる」という感覚が思い浮かぶはずだ。

新人技術者の人たちには、いざというときに問題解決の方法が思い浮かぶようになって欲しいと思うし、そうなるためにはどんな技術を身につけなければいけないかを常に考えるようにして欲しい。

エンジニアが社会に貢献できるようになるためには、使う側の視点と作る側の視点を持ち、当たり前にできていることの裏側を理解し、それを自在に操れるような技術を習得することが必要なのだ。

P.S.

ここまでの記事を読み返して、新人向けにはよくても指導者向けにはちょっと掘り下げが浅いと感じたので追伸を書こうと思う。

百万行を超えるソフトウェアシステムが珍しくない昨今、新人の技術者に対して、ただ単にソフトウェアシステムのアーキテクチャを理解できるようになれというのは、あまりにも不親切なアドバイスだと思った。

現代のソフトウェアエンジニアはもしかしたら、好むと好まざるとに関わらず、システム全体の構成を設計するごくわずかなアーキテクトになる者と、システムの一部の開発を担当するか、変更要求に応じた設計をする者や、テストを専門に行うテスターなどに分業せざるを得ないのかもしれない。

皆がアーキテクトになれればハッピーかもしれないが実際には組織の中で実力でその地位を奪い取る競争をしなければならないだろう。

今の世の中それはしようがないとして、こんな時代にソフトウェアエンジニアはどこにモチベーションの源泉を求めればよいのだろうか。

それは、ソフトウェアシステム全体の中で自分がやっている仕事がどんなユーザー要求に貢献しているのかを理解し、システムの一部であっても自分が顧客要求を満たす価値を生み出していることに満足を感じることが大事なのだと考える。その貢献度が自分の成長とともに大きくなっていけば高いモチベーションを維持することができる。

そう考えると最初に必要なのはシステムの要求仕様を完全に理解することである。新人技術者は自分が担当する製品やシステムの要求仕様書を理解し、分からない言葉がない状態に早くなることをまず目指す。

そのためには要求仕様書の完成度が高くないといけないし、要求仕様に設計仕様やアーキテクチャの記述が含まれているとよくない。優れた要求仕様書はユーザーが理解できる言葉で記述されている。そして、どうすれば要求が実現できたのかを判定する判定基準が明確になっている。先人は、優れた要求仕様書を後の世代のために残すことが求められている。

そして、要求仕様が理解できるようになったら、次に若いエンジニアはアーキテクチャ設計書を読む。アーキテクチャ設計を理解するにはそれなりのスキルが必要だが、アーキテクトになりたいのなら要求仕様とアーキテクチャ設計の結びつきを理解できるようにならなければダメだ。要求仕様とアーキテクチャがばらばらであることに気がついたら、アーキテクトにのし上がれるチャンスがある。要求仕様とアーキテクチャが綺麗に整合するような設計ができるようになれば、アーキテクトとして認められる。そこまで到達しなくても、要求仕様とアーキテクチャの関係性に何らかの違和感を感じることができるようになれば、アーキテクトになれる可能性はある。

そのためにも、先人は現行システムのアーキテクチャが分かるような情報を残さなければいけない。言わずもがな、アーキテクチャ設計を説明する資料がないようでは、100万行を超えるソフトウェアシステムを維持し続けることはできないし、新人技術者に指導するのも無理だ。口づてで伝えられるような情報量ではないし、ソースコードでは階層的に理解を進めることができない。

現代の新人エンジニアを本気で組織的に育てようとするのなら、先人の技術者たちがソフトウェアシステムの上流工程のドキュメントをしっかり作り込まないといけないということである。

ベテランのエンジニアもこれまでの実績にあぐらをかいていたのでは、行く先が危ういのである。