2011-12-23

ISO 26262との向き合い方 (6) 機能安全のマネジメント2

今週、下記のような記事が Tech-On! に掲載された。(読むには無料のユーザー登録が必要)

【専門記者が振り返る】要件管理とトレーサビリティ、この1年――ISO 26262適合で日本でもツール基盤の導入進む

変更管理や構成管理はここ10年で浸透した。要件管理はこれからで、ISO 26262 への適合がトリガーになって、導入が進むのではないかという内容だ。

要件管理のツールとして「Rational DOORS」、米PTC社の「Integrity」、フランスDassault Systemes社の「Reqtify」が挙げられており、国内のツールとしては経済産業省から約5億円の助成を受け、組み込みソフトウエア開発ツール・ベンダーのキャッツなどが中心となって、「TERAS」というツール基盤を目下、開発中であると書かれている。

※そういえば Google が検索エンジンのスタンダードになりつつあったときに、経済産業省が主導して国産検索エンジンを作ると言っていた『情報大航海プロジェクト』はいったいどうなったのだろう。

自分は、日本では要件管理ツールは日本のソフトウェアプロジェクトにはなじみにくい、ツールの価格(Integrityはサーバー側で200万円、クライアント側ノードロックで1本40万円。)だけの価値、効果を導き出すことは難しいと思っている。

なぜなら要件管理ツールは要求定義→アーキテクチャ設計→実装 というトップダウンの開発に向いており、すでにベースとなるソフトウェアシステムがあって、変更しながらものづくりを進めていくような大量に変更が発生するプロジェクト、また、要求定義を横に置いてまず作り始めてしまうような開発は想定していないからだ。(そうしないことを強制するためにツールの使用を強制するということはあるかもしれないが)

ところが、日本のソフトウェア開発ではこれまでボトムアップで作ってきていて、要求定義が曖昧なままものづくりを進め、ガンガン修正してそれなりの品質のソフトウェアを作ってしまう。

※医療ドメインではUSでAgileをクリティカルソフトウェアに使う場合にどうすれば安全を確保できるかというガイダンスが今作られている。

そのやり方がよいとは言わないが、一つ言えるのは日本ではボトムアップでソフトウェアを作っても、それほどひどい品質にはならない。要求定義をしっかりやって、そこを動かさずに先に進むという開発ができていないのに、なんとかなっているという現状だ。どんなに優れたプロセスやツールが使われている欧米製品よりも、必ずしもそのようなプロセスやツールを使っていない日本製品の方が品質がいいのはなぜなのか、これから先も、そのやり方でこれからも突っ走っていいのかどうかをじっくり考えてから、ISO 26262 を取り入れないと失敗すると思う。

日本では問題が分かったときの修正のスピードが速い。デグレードはゼロとは言えないが、とんでもない見落としは少ない。それは、品質を心配する意識: Awareness: Worrying about Quality  の力ではないかと思っている。(これうまくいかず品質に悪影響を与えるケースが増えており、変更の影響を分析、管理しながら変更を実装していく XDDP という取り組みが今話題になっている。)

ユーザー要求はプロジェクトメンバの頭の中にたたき込まれていて、同じメンバが商品や商品群のライフサイクル全般に渡って関わっているので、要求定義を文書化する必要がないのだ。

だから、現場のエンジニアにとって要求分析の結果を文書にすることは「余計なこと」「規格要求のため」「作るのがルールだから」になる。要求管理が本質的な意味で役に立っていない。

これが、例えば製品開発ごとに人がごっそり変わったり、それまで開発経験がまったくないメンバを半分以上投入するようなプロジェクトだったらそうはいかない。トップダウンで粛々と進めていかないとものができてこない。要件管理ツールは、そういうトップダウンの開発にフィットしている。

構成管理や変更管理が日本でも受け入れられているのは、 構成管理や変更管理がボトムアップの開発にも十分に役立つからである。同じように要件管理ツールも普及すると思ったら大間違いだと自分は思っている。(構成管理や変更管理のボトムアップでの組織への浸透については『リコールを起こさないソフトウェアのつくり方』の二章にやり方も含めて詳しく書いた。)

さて、要件管理は製品開発にとって、ユーザーの安全確保にとってなぜ重要なのか。それは、商品の潜在的価値(別な言い方をすれば当たり前品質)に関係がある。

ユーザーは安全は当たり前に確保されていると考えている。商品を使うユーザーはメーカーがキチンと安全設計をしており、多少荒っぽい使い方をしても安全になるように作っていると信じている。特に日本製品には絶大な信頼を寄せている。

余談だが、最近の技術系新人はものづくりを企画立案からリリースまでやりきって他人に提供する経験をしたことがある者が極端に少ない。エンジニアなのに使う側の視点しかなくて、作る側の視点がほとんどない。だから、商品が当たり前にできていること、安全を実現している技術がなんだかまったく分からないし、分かりたいとも思わないし、裏方の技術に感動した経験がない。エンジニアなのに消費する側の気持ちが抜けきれていない。iPad や iPhone のユーザーインタフェースの良さをさかんに強調し、これを取り入れた方がよいと言ったりするが、その裏側にある技術については何にも知らない。このような者たちにはスティーブ・ジョブズの伝記を読んで、iPad や iPhone の誕生の裏側に何があるのか理解し、自分でも同じことができるかどうか考えてみろということにしている。

さて、製品の安全を信じているユーザーに対する保証はなんだろうか。これまでの日本では、それはエンジニアの頭の中の「品質を心配する意識:Awareness: Worrying about Quality」だった。安全を担保している技術は技術者の中にたたき込まれており、組織の中で先輩から後輩へ伝承されてきた。プロジェクトがフラットであるため、問題が起こったときに全員がその問題に対して協力して対処することで、品質に関する意識がプロジェクト全体に醸成された。設計の規範が構築されていくのだ。

誰かに命令されたからではない。エンドユーザーに迷惑をかけたことが技術者として恥じだと思うから、一刻も早く顧客満足を回復したいからプロジェクトが全員で一丸となって対応するのだ。

ところが、前述のように近年商品の当たり前にできていることを支える技術がなんだか分からない技術者が増えてきて、また、ソフトウェアシステムの規模が増大かつ複雑化してくるとユーザー要求や商品の使われ方を熟知しているプロジェクトリーダーであっても、プロジェクトメンバ全員の安全確保の意識やスキルに自信が持てなくなり、そして、商品の安全を確信できなくなってきている。

その状態を回避し、ユーザーの期待(安全は当たり前に確保されているはず)に答えるには、安全に対する要求と、その実現方法、実現の結果(証拠)を常にトレースが取れるようにしておく必要がある。そのトレースのセットがトレーサビリティマトリックスとなる。

要件管理ツールはこのトレーサビリティマトリックスを保持するための助けとなる。

しかし、日本では上記のことがプロジェクトメンバ全員に理解されていなければ、要件管理ツールは必ず形骸化する。要件管理ツールを導入しただけなら、重要な要求も、どうでもいい要求も同じレベルで管理されることになるだろう。そして、日本のプロジェクトではどうでもいいことは、ものすごい勢いで変更をかけるのでツールを使ってもかなりの手間だと感じるに違いない。

だから、要件管理をしっかり実施して、トレーサビリティマトリックスを維持するのなら安全に関わる重要な要件とそうでない要件を分離することが必要になる。要求分析を行う手法としては品質機能展開(QFD)などがあるから、日科技連でしっかり勉強して、重要な安全に関わる要件と、仕様と検証記録を Excel シートで管理してみて、管理工数が一人あたり 40万円を超えるようなら 要件管理ツールを使ってみればよい。(Google Document を使えばExcelも買わなくていい)

または、ボトムアップ的な要件管理ツールの使い方なら組込みソフトでも有効な可能性はある。例えば、すでにあるソフトウェアシステムのアーキテクチャを UML で描いて、そのモデルの元となる要求はどんなものかを逆に分析してツールで可視化するというやり方だ。ユースケースをトップにするのではなく、ユーザー要求の分析がトップになるように可視化を進める。

技術者の頭の中にある暗黙のアーキテクチャとユーザー要求を目に見える形にトレースし直して、可視化した後は、明示化した方の要求とモデルを維持する。そして、ソフトウェアシステムのアーキテクチャを表すモデルとユーザー要求とを行ったり来たりしながら、最初に考えたアーキテクチャが崩れないように慎重にソフトウェアシステムに変更を加えていく。これなら現場にも受け入れられる。この方法は、スパークスシステムズジャパンの Enterprise Architectと RaQuest で実現できる。モデルの描画はEnterprise Architectで、要件管理はRaQuestで、そしてこの二つのツールを組み合わせると要件とアーキテクチャの関係を関連づけることができる。二つ合わせても5万円以下だ。

ソフトウェアは見えにくいからツールの効果も数字で表しにくいが、それでもソフトウェア組織を率いる責任者はツール類に投資した資金がどのように組織に貢献しているのかを定期的に検証しなければいけない。末端のエンジニアはそのツールがそこに当たり前のようにあるものだと思って使っているだろうが、彼らにはそのツールにどれくらいの費用がかかっており、その費用分の効果を出す義務がエンジニアやプロジェクトにはあるのだという意識を植え付けなければいけない。

だから思う。一本50万円とか、100万円する要件管理ツールは、問題が発生したら数十億円規模の損害が発生するような事業、プロジェクトに使う。それは軍事産業や航空宇宙開発、原子力開発などだろう。実際そのようなツールはそういう業界で使われているのであって、自動車業界でペイするのかどうかについては疑問がある。何かあったら、数十億円の損害が出るようなコンポーネントがあるのなら、そのコンポーネントの開発に対して導入して、開発のスタイルをトップダウンの設計に切り替えばよい。しかし、単純に ISO 26262 という規格に適合するために一本数十万円する要件管理ツールを導入するのなら「気前がいいですね」と自分なら言う。また、形骸化していないかどうか3年間は定期的なチェックをお勧めする。3年たって組織内で習慣化するところまでになれば、大丈夫、形骸化はしない、組織の文化として根付くだろう。

要件管理だけでなく、日本のソフトウェアプロジェクトではたましいの入っていない活動(Activity)は必ず形骸化する。アウトプットドキュメントは「言われたから作っているだけ」「役に立たないがルールだから作っています」という代物になる。

それが積み重なっていくと技術者たちは「組織が、無駄なドキュメントを作らせているから開発が遅れる」と言い出す。サプライヤは「何も現実を分かっていないクライアントが作れと言っているので無駄だと思いつつもしかたなく作っている」という状態になる。そうではない。それは嘘だ。その技術者は無駄ではないドキュメントを作るスキルがない、そのドキュメントを作る意味を理解していないことを他人にせいにしているだけなのだ。

ISO 26262 の導入によって、日本では確実に「組織が無駄なドキュメントを作らせているから開発が遅れる」と不満を漏らす技術者が増大する。この台詞を吐く技術者には二通りあって、ひとつはソフトウェア品質に自信があるのに余計なことをやらされていると考える者、もうひとつはスキルもなくやっつけ仕事で書類の作成をしている者。

前者には、ISO 26262 が達成しようとしているユーザーの安全に対して共通の価値観を持てるように徹底的に議論することで道が開ける。後者はどうしようもない。実際に規格要求の求めに対して、まったくたましいの入っていない、うわべだけ取り繕った書類を見たことがある。彼らは要求者から注意を受けない限りうわべだけの書類作りを繰り返す。そいういう場合は、粛々と是正を要求する。そう、このやり方が欧米流のプロセスアプローチなのだ。たましいの入っていない技術者、プロジェクト、組織に対して、ルールとシステムで安全を確保する方法が欧米流のプロセスアプローチであり、ISO 26262 は基本的にはそのやり方だ。

一方、技術者の品質を心配する意識: Awareness: Worrying about Quality に働きかけ、たましいの入った成果物を作って、それがプロジェクト全体に伝搬し、改善を積み重ねていくのが日本流のやり方だ。

自分が自動車業界の皆さんに聞きたいのは、どっちのやり方で ISO 26262 への適合を進めようとしているのかということだ。

【ISO 26262-2:2011 Part 2: Management of functional safety】

さて、今回は Management of functional safety のOverview of the safety lifecycle を見ていこう。図は前回と同様に、英文をトレースし直したものと日本語にしたものをペアにして PDF にした。

(「セーフティライフサイクルの外観開くためのパスワードは"guild26262")









5.2.1 Overview of the safety lifecycle
The ISO 26262 safety lifecycle (see Figure 2) encompasses the principal safety activities during the concept phase, product development, production, operation, service and decommissioning.
ISO 26262 セーフティライフサイクル(図2)は、コンセプトフェーズ、製品開発、生産、運用、保守及び廃棄の間の主要なセーフティアクティビティを包含する。
Planning, coordinating and documenting the safety activities of all phases of the safety lifecycle are key management tasks.
セーフティライフサイクルのすべてのフェーズにおいて、安全活動を計画すること、コーディネートすること、文書化することはキーマネージメントタスクである。

→安全活動の全般において、計画とコーディネイトと文書化が重要といっているということは、すなわち、ISO 26262-6 のソフトウェアレベルでの製品開発だけを切り出して、そこだけの要求を満たそうとしたのでは、セーフティライフサイクルは機能しない、すべてのフェーズにおいてセーフティマネジメントの計画が浸透し、各活動がリンクしていなければ、安全という目的は達成できないということを言っている。このことを分かって活動しているかどうかがとても不安。切り出し始めたら形骸化も始まる。
Figure 2 represents the reference safety lifecycle model.
図2は セーフティライフサイクルのリファレンスモデルを表している。

→この図は是非手元において自分が今やっている活動が全体のどの部分に相当するのか、製品開発のフェーズにいるのなら、コンセプトフェーズの要求を満たしているかどうかをチェックして欲しい。
Tailoring of the safety lifecycle, including iterations of subphases, is allowed.
サブフェーズの反復を含む安全ライフサイクルのテーラリングは容認されている。

→ウォーターフォールモデルのように見えるが、一つ一つの箱または複数の箱を繰り返すようなプロセスにしてもよいということ。セーフティライフサイクルにおいても自組織に合わせてプロセスのテーラリングをした方がよいということだ。概念だけでなく活動の実態に合わせて、テーラリングしたプロセスを可視化しておくのがよいだろう。
NOTE 1 The activities during the concept phase and the product development, and after the release for production are described in detail in ISO 26262-3 (concept phase), ISO 26262-4 (product development at the system level), ISO 26262-5 (product development at the hardware level), ISO 26262-6 (product development at the software level) and ISO 26262-7 (production and operation).
NOTE1 コンセプトフェーズ及び製品開発間のアクティビティ及び、生産のためのリリース後については、ISO 26262-3(コンセプトフェーズ)、ISO 26262-4(システムレベルの製品開発)、ISO 26262-5(ハードウェアレベルの製品開発)、ISO 26262-6(ソフトウェアレベルの製品開発)そして、ISO 26262-7(生産及び運用)に詳しく説明されている。
NOTE 2 Table A.1 provides an overview of the objectives, prerequisites and work products of the particular phases of the management of functional safety.
NOTE2 表A.1 は、機能安全のマネジメントの特定のフェーズの目的、前提条件、及び作業成果物の概要を示している。

→表A.1 は前回の記事『ISO 26262との向き合い方 (5) 機能安全のマネジメント1』にあるのでそれを参照して欲しい。

※今年の ISO 26262 の特集記事はこれで終了になります。また、来年をご期待ください。自動車業界の皆様また、ツールベンダーの方、規格認証機関の方、ご意見、ご質問があれば随時受け付けますので是非お送りください。

2011-12-17

ISO 26262との向き合い方 (5) 機能安全のマネジメント1

ISO 26262 に関するアンケートで 「 お金や工数がどれくらいかかるか知りたい。」に5票入っていた。そこで、インターネットでいろいろ調べてみたら、アメリカの KVA という会社が ISO 26262 のトレーニングのオーダーシートを公開しており、そこに金額が書かれているのを見つけた。(KVA のサイトURL http://www.kvausa.com


↓オーダーシートのURL はこちら
 http://www.kvausa.com/sg_userfiles/kVA_ISO26262_Training_Registration_2011_10.pdf

トレーニング項目と金額の部分だけ書くとこうなる。

Day 1: Functional Safety Management Training    $895 約7万円
Days 2 & 3: System and Hardware Level Implementation of ISO 26262
including FMEDA workshop and FMEDA Workbench database tool for reliability calculation according to ISO 26262
$2,095  約16万円
Day 4: Software Level Implementation of ISO 26262  $895  約7万円
Days 1, 2, 3 & 4: Special Bundled Rate  $3,755 約30万円
Days 1, 2, 3 & 4 Plus Qualifying Exam for FSCAE Certification
FSCAE examination not available without full 4-day training session
 $4,755  約37万円

1日目は機能安全マネージメントトレーニングで、2日目、3日目はシステム&ハードウェア実装、4日目がソフトウェア実装となっている。全部合わせると約30万円、一番下の行にある FSCAEとは Functional Safety Certified Automotive Engineer の略で、この会社が独自に設定した認定資格のことのようだ。この認定資格の試験を入れると総額で約37万円となる。

さて、日本のこのブログの読者の多くが、この価格を高いと感じたと思う。しかし、自分はそれほど驚かない。なぜかというと医療機器の世界でもアメリカでトレーニングを受けようとするとこれくらいの金額が要求されるからだ。

ここでよく考えて欲しい。欧米では安全や信頼はルール/責任、システム/ツール で確保するのだ。一方、日本では品質を心配する意識の強さが安全や信頼の実現に貢献している。しつこいようだが今一度『USとJapanの文化の違いと商品品質との関係』の記事を読み返して欲しい。

欧米では組織内のルール/責任に対する力が強いので、このようなトレーニングを受ける者は教育資格を根拠に組織内で責任と権限を持つ。そして資格を持ったものがトレーニングで得た知識と権限を使って、作業者へ指導をする。機能安全の要求実現に関しては資格保有者が上、作業者が下になる。組織で階層構造ができている場合に有効なアプローチだ。セーフティマネジメントのマネージャは規格の要求事項ができていないと判断したときには是正を要求できる権限を組織から与えられているし、是正を要求された方も粛々と実施する。しかし、定時になればきっちり帰る。後ろめたさはない。問題が発生したのはシステムがきちんと回っていなかったからであり、作業者の資質ではない。スキルが足らないのなら、追加のトレーニングを行う義務は組織にある。このような、是正の指摘を自分の失敗や恥じだとは思わない、考えない階層構造の組織において、品質システムはうまく機能する。

だからこそ、責任を任される者はその責任と権限に見合った知識、スキルを持っていないと上と下から「お前は能力がないから辞めろ」とか「あの上司は能力がないから辞めさせてくれ」と言われるし、逆に実績を積むことができればよりサラリーの高い組織に転職することも可能だ。だからこそ、アメリカではトレーニングに参加する者の知識を習得しようとする意気込みや真剣さが半端じゃない。分からないことは決してそのままにして帰らない。日本人がセミナーに参加する態度とは雲泥の差だ。

自分は日本でやられているほとんどのセミナーは受講者が話を聞くだけの一方的なものが多く、できるようになるまで徹底的にやる「トレーニング」ではないと思っている。トレーニングはできるようになるまでやるからこのように高いのだ。トレーニングする側の能力が低ければ客足はすぐに途絶える。それなり価値と知識やスキルを身につけさせられるという自信がなければ、これだけの金額にはできないだろう。

一方で外資系でも無料のセミナーはある。こういう場合は、その裏側にものすごく高いコンサルテーションやツールの購入を勧めるセールスが含まれていると考えた方がよい。ものすごく高いというのは、例えば1日コンサルテーションしてもらうと30万円とか、ライセンス一本あたり100万円のツールのことだ。このような費用が日本の会社の中で認められるかどうかは、組織上位層の人たちが安全や信頼を実現するための規格適合費用としてそれ相当の金(数百万円から数千万円)を支払う決心をしたときだけだ。日本のエンジニアがタダで安全や信頼を実現できている状況では認められるわけがない。

さて、欧米に比べて日本では役職の違いがありながら、特に技術分野ではフラットに近い組織構造になっており、また、マネージャーがマネージメントだけでなくエンジニアリングもやっていたりする。だから、プロジェクト内のマネージャやマネージャに指名されたベテラン技術者一人が上記のようなトレーニングを受けて、プロジェクトメンバーに「これに従え」と指示を出してもうまくいかないと思う。日本のエンジニアは「なぜ」「なんのために」について納得しないと動かない。逆に根拠も理解せずに今までのやり方を変えてしまうようなら非常に危ない。

日本の技術者はこのような縛りがなくても高い品質のハードウェア、ソフトウェアをアウトプットできる非常に珍しい人種だと感じる。たいしてトレーニングに費用をかけなくても高品質の製品を作ることができる。だからこそ、経営者はトレーニングに上記のようなお金がかかることについてなかなか理解を示さないと思う。

実際、日本では ISO 26262 の要求を社内ルールに取り込んでガイドラインを作り、そのガイドライン通りにものづくりをさせることで、形式的に規格要求を満たしたように見せるという作戦をとるだろうと予測する。いい悪いは別にして、説明責任を果たすためには、まずはそうするしかないのだ。欧米のように、一部の精鋭に資格を取らせて、そのリーダーの権限でヒエラルキーの組織構造の中で規格適合を推し進めるというやり方ではなく、関係者全員が一定の組織内ガイダンスにしたがうことで、降りかかってきた危機に対して全員でフラットに乗り切ろうとすると思う。

このやり方は下手をするとすぐに形骸化する。規格要求を理解せずにアウトプットドキュメントを形式的にそろえることが目的になりやすい。

このブログの特集では欧米流のやり方はうまくいかないということを見越した上で、マネージャもエンジニアもみんな同じ目線でエンドユーザーの安全を確保するために、自分たちが何をし、また、諸外国の人々に自分たちが作った成果物の安全性や信頼性をどのように主張したらよいのかを解説し、活動が形骸化せずに安全という最終目的を達成できることを目指している。

日本の製造業の会社でソフトウェアエンジニア出身の品質保証担当という人にはなかなかお目にかかることがない。電気や機械の出身であったり、純粋に品質畑で上に上がってきた人が多いように感じる。その人たちに、ISO 26262 のソフトウェア開発の要求部分を指導させるには、相当無理がある。だからといって、ソフトウェアQAのような部門、担当を急遽作って勉強させ、権限を与えるのもフラットな組織構造ではうまくいくような気がしない。ソフトウェアの規格適合の部分を外部に丸投げすると、さんざんかき回され、規格の認定を受けているというツールを買わされ、ぐちゃぐちゃになる危険性がある。ルール/責任が明確化されており、システム/ツールを使いこなすのが上手なところでうまくいった方法をそのままテーラリングもせずに日本で実践しようとしても失敗するだけだと思う。

そうならないためには、日本人がアウトプットする成果物の品質がなぜ高く、ルール/責任、システム/ツールを駆使している欧米製品の品質が日本の製品の品質に追いつけていないのはなぜかについて、自分たちの中に答えを持っている必要があると強く思う。その確信がないと、欧米流を受け入れても実質的な安全や信頼は向上しない。

この命題に対する答えのヒントとして言えることが一つあると思う。それは、上記のことはスタンドアロン製品には当てはまるかもしれないが、ネットワーク接続するような製品、複数の機能を組み合わせないと要求を実現できないような製品や機能ではたぶん成り立たないという点だ。

ようするに、特定のエンジニアが商品や商品群全体を見渡すことができ、商品のライフサイクル(開発開始から市場になくなるまで)全体に渡って関わる、責任を持つことができる場合は日本の商品の品質は高いが、他部門や他社のコンポーネントを組み合わせないと商品の重要な機能を動かすことができないようなケースでは、その限りではないということだ。

自動車で言えば、機能と性能が責務分割できていたこれまでは品質を高く維持できてきたが、今後、それらがクロスオーバーしないとユーザーの要求を満たせなくなってくると、それまでのやり方では予測できない不具合に悩まされることになるということだ。そのために、ISO 26262 を使う必要があり、これまでの日本のエンジニアの良さ、高品質を実現できる能力を低下させないようにしながら、ISO 26262 の要求のよいところを吸収していく必要があると思っている。

【ISO 26262-2:2011 Part 2: Management of functional safety】

さて、用語の定義の邦訳はもうしばらくまっていただくとして、今回は ISO 26262-2:2011 Part 2: Management of functional safety の解説に入っていきたいと思う。

以下が Management of functional safety:機能安全のマネジメントのパートの目次で、「5 セーフティマネジメントの要求」「6 コンセプトフェーズと製品開発間のセーフティマネジメント」「7 製造のためのアイテムリリース後のセーフティマネジメント」が3つの大きな柱となっている。

ISO 26262-2:2011 Part 2: Management of functional safety は、セーフティマネジメント全体に対する要求であり、こういったところはエンジニアには苦手な分野で、品質保証担当や製品開発のプロセスをマネジメントするような人が得意なところだ。

ISO 26262-2 Part2 Management of functional safety 機能安全のマネジメント
Contents 目次
Foreword 序文
Introduction イントロダクション
1 Scope スコープ
2 Normative references 基準となる参照
3 Terms, definitions and abbreviated terms 用語、定義、省略語
4 Requirements for compliance 規格適合要求
4.1 General requirements 一般要求
4.2 Interpretations of tables 表の解釈について
4.3 ASIL-dependent requirements and recommendations ASILに依存する要求及び推奨
5 Overall safety management セーフティマネジメントの全体像
5.1 Objective 目的
5.2 General 一般
5.3 Inputs to this clause この箇条へのインプット
5.4 Requirements and recommendations 要求と推奨
5.5 Work products 作業成果物
6 Safety management during the concept phase and the product development コンセプトフェーズと製品開発間のセーフティマネジメント
6.1 Objectives 目的
6.2 General 一般
6.3 Inputs to this clause この箇条へのインプット
6.4 Requirements and recommendations 要求と推奨
6.5 Work products 作業成果物
7 Safety management after the item's release for production 製造のためのアイテムリリース後のセーフティマネジメント
7.1 Objective 目的
7.2 General 一般
7.3 Inputs to this clause この箇条へのインプット
7.4 Requirements and recommendations 要求と推奨
7.5 Work products 作業成果物
Annex A (informative) Overview of and workflow of functional safety management (情報提供としての)機能安全マネジメントの概要とワークフロー
Annex B (informative) Examples for evaluating a safety culture (情報提供としての)安全文化の評価の例
Annex C (informative) Aim of the confirmation measures (情報提供としての)確証対策の目的
Annex D (informative) Overview of the verification reviews (情報提供としての)検証レビューの概観
Annex E (informative) Example of a functional safety assessment agenda (for items that have an ASIL D safety goal) (情報提供としての)機能安全アセスメントアジェンダの例(ASIL D のセーフティゴールを持つアイテム用)

この手のエンジニアが不得意なパートを理解するためにはコツがあって、まず、Annex や、各工程で作成すべき成果物が何かを見る。日本の技術者はプロセスのインプットが曖昧でもアウトプットのイメージが分かっているとものづくりができてしまう不思議な人種だ。そして、インプットとなる要求の説明をするよりも、アウトプットのイメージを見せてあげると非常に喜ぶ。

逆に言うと、アウトプットの型にはめ込もうとする傾向があるので注意が必要だ。答えは一つではないのに、アウトプットの例を見せるとその一点を目指そうとしてしまう。

下記は ISO 26262-2 Part 2: Management of functional safety の Annex A の機能安全マネジメントの全体像を表す表で、3つの箇条に対するインプットとアウトプットが何かが明確に書かれている。

セーフティライフサイクルに対する要求定義やルールと責任の定義、市場へのリリース後のモニタリングの義務などが定義されている。これらは、ISO 9001 の要求とも一致しているので、品質マネジメントシステムを持っている組織ならそれほど違和感はないと思うが、自動車の場合は製造業者とサプライヤの関係があるのでそう簡単ではないと思われる。

ルールとプロセスは自動車製造業者が作ことになるが、サプライヤに対してルールと安全ライフサイクルの中でサプライヤに委託するプロセスを提示し、セーフティケース等エビデンスの要求を行い、それらの活動が継続的に実施されていることをエビデンスを残さなければいけない。

これは各開発における成果物だけでなく、 ISO 9001 と同様に定期的な内部監査や外部監査を通じたオーディットの実施記録によって示すことになるだろう。

ブログの読者が機能安全マネジメント要求の内容を直感したいのなら、左側の作業成果物を文書化して用意する必要があると考えて見て欲しい。ルールとプロセスは組織承認される必要があり、安全に関わるコンポーネントに関係する製造業者の部門とサプライヤはそのルールとプロセスを知っている必要がある。知っているだけでなく、教育訓練をしてその履歴の残さなければダメだ。そういった履歴を確認することでしか、ルールやプロセスが徹底されていることを証明することはできない。

エビデンスは証拠だから、メモはダメ。きちんと責任と権限を持った者が承認されたものでなければいけない。このような取り組みがまどろっこしいと思っても、日本以外の人たちに安全や信頼を説明するためにはそうするしかないのだ。

Table A.1 — Functional safety management: overview
Clause
箇条
Objectives
目的
Prerequisites
事前必要条件
Work products
作業成果物
5 Overall safety management The objective of Clause 5 is to define the requirements for the organizations that are responsible for the safety lifecycle, or that perform safety activities in the safety lifecycle.
Clause 5 serves as a prerequisite to the activities in the ISO 26262 safety lifecycle.
None 5.5.1 Organization-specific rules and processes for functional safety.
5.5.2 Evidence of competence.
5.5.3 Evidence of quality management.
5 セーフティマネジメントの全体像 箇条5の目的はセーフティライフサイクルに責任を持つ、またはセーフティライフサイクルの中で安全活動を実施する組織に対する要求を定義することである。 なし 5.5.1 機能安全の組織承認されたルールとプロセス
5.5.2 適格性の証拠
5.5.3 品質マネジメントの証拠
6 Safety management during the concept phase and the product development The first objective of Clause 6 is to define the safety management roles and responsibilities, regarding the concept phase and the development phases in the safety lifecycle.
The second objective of Clause 6 is to define the requirements for the safety management during the concept phase and the development phases, including the planning and coordination of the safety activities, the progression of the safety lifecycle, the creation of the safety case, and the execution of the confirmation measures.
Organization-specific rules and processes for functional safety (see 5.5.1)
Evidence of competence (see 5.5.2)
Evidence of quality management (see 5.5.3)
6.5.1 Safety plan.
6.5.2 Project plan (refined).
6.5.3 Safety case.
6.5.4 Functional safety assessment plan.
6.5.5 Confirmation measure reports.
6 コンセプトフェーズ及び製品開発中のセーフティマネジメント 箇条6の目的はコンセプトフェーズ、セーフティライフサイクルの開発フェーズに関してセーフティマネジメンのトルールと責任を定義することである。 機能安全の組織認証されたルールとプロセス(5.5.1)
適格性の証拠(5.5.2)
品質マネジメントの証拠(5.5.3)
6.5.1 セーフティプラン
6.5.2 プロジェクト計画(見直し後の)
6.5.3 セーフティケース
6.5.4 機能安全アセスメント計画
6.5.5 確認手段レポート
7 Safety management after the item's release for production The objective of Clause 7 is to define the responsibilities of the organizations and persons responsible for functional safety after the item's release for production. This relates to the general activities for ensuring the required functional safety of the item during the lifecycle subphases after the release for production. Evidence of quality management (see 5.5.3). 7.5 Evidence of field monitoring.
7 生産のためのアイテムリリース後の安全管理 箇条7の目的は生産のためのアイテムリリース後の機能安全の組織と人員の責任を定義することである。これは製品のリリース後のライフサイクルサブフェーズ中のアイテムの機能安全要求を確実にする一般活動に関係がある。 品質マネジメントの証拠(5.5.3) 7.5 市場モニタリングの証拠

次回は、さらに ISO 26262-2 Part 2: Management of functional safety を読み進んでいきたいと思う。

2011-12-10

ISO 26262との向き合い方 (4) 用語の定義からのトピックス

ISO 26262-1:2011 Part 1: Vocabulary を邦訳しようと思ったら用語が142もあって、さすがに一晩や二晩でできる分量ではないことが分かった。用語の定義の邦訳(全体)については正月明けを目標にリリースを目指したいと思っている。

ちなみにVocabularyは用語とか用語集と訳した方が正確かもしれないが、用語の内容を正確に理解することが規格解釈の重要なポイントであることを強調したいためこのブログサイトでは『用語の定義』とした。

用語の定義の翻訳作業をしていてつくづく思ったのが、英語を日本語にすると原文のニュアンスが伝わりにくくなるということだ。例えば、safety architecture を安全構造とか安全方式と訳してしまうと、ソフトウェアには関係ないような印象を与えてしまう。safety validation も安全妥当性確認としてしまうのはイマイチだと感じる。よって今回は、それらカタカナで示すことでニュアンスが伝わりそうな用語はそのまま、セーフティアーキテクチャやセーフティバリデーションと書くようにした。ただし、safety measure (セーフティメジャー)のようなカタカナにすると意味が認識しにくくなる言葉は、「安全対策」と日本語にするようにした。(セーフティ対策は語呂がよくないので安全対策とした) 英語のままにしておくか、日本語にするかはこの規格を適用するエンジニアにとってどちらの方が規格要求を正しく理解できるかと考えながら振り分けた。

さて、ISO 26262 の142の用語を眺めてみると、次の3つのグループに分かれることが分かる。
  1. 安全工学、品質工学、規格適合に関係することば
  2. ソフトウェア品質工学に関係することば
  3. 自動車ドメイン特有のことばまたはISO 26262 特有のことば
例えば、1の安全工学、品質工学、規格適合のことばとしては、assessment:アセスメント、audit:オーディット、harm:危害、hazard:ハザード、failure:故障、failure mode:故障モード、fault:欠陥、residual risk:残留リスク safety case:セーフティケース、safety measure:安全対策 などが、

2 のソフトウェア品質工学に関係することばとしては、statement coverage:ステートメントカバレッジ、branch coverage:分岐カバレッジ、verification:検証、walk-through:ウォークスルー、random hardware failure:ランダムハードウェア故障、systematic failure:決定論的故障、software unit:ソフトウェアユニット、software component:ソフトウェアコンポーネント などが、

3 の自動車ドメイン特有のことばまたはISO 26262 特有のことばとしては、Automotive Safety Integrity Level:ASIL, ASIL decomposition:ASILデコンボジション、special-purpose vehicle:特別目的車両、single-point failure:シングルポイント故障、dual-point failure:デュアルポイント故障

などがある。この規格には3つの分野のことばが多く使われていることから ISO 26262 全体を理解するには3つの分野を総合的に理解していないとダメだということが推察される。このことは今後の ISO 26262 を適合する現場のエンジニアにとって悩ましい問題になると考えている。

それはどういうことかというと、1. 安全工学、品質工学、規格適合 に関する知識は規格適合会社が得意とすることだが、彼らはソフトウェア品質工学や自動車ドメイン特有の知識にはうとい。2. ソフトウェア工学に関する知識は、ソフトウェア系品質コンサルタントが得意な分野であるが、彼らは安全工学、規格適合、自動車特有のドメインの知識、経験があまりない。また、今回 ISO 26262 のために新しく導入された概念、ASILや ASILデコンポジションなどの概念は、ISO 26262 の規格制定に関わった人たちが詳しい。

そこを踏まえたうえで、自動車ドメインの技術者は、自動車ドメインに特化した部分、ISO 26262で初めて導入された概念は自分たちで理解を進めるとして、安全工学、品質工学、規格適合、ソフトウェア品質工学に関する知識に関しては、外部から指導を受ける必要性はあると感じる。このとき、お勧めしたいのは、急に ISO 26262 の適合を看板に掲げたところよりも、それぞれの分野の知識や方法論を昔から、ひたむきに、純粋に教えているところに教えを請うということだ。例えば、安全工学、ソフトウェア品質工学なら日科技連などがお勧めだ。例えば、FMEAやFTAを含む品質管理セミナー、ソフトウェア品質マネジメントセミナーは何十年も前から開催している。

このブログを利用するのも一つの手だが、エンジニアや品質保証担当はこれからたくさん勉強しないといけないということは間違いない。自らの勉強する努力なしに、今後複雑化する安全機能をユーザーに安心して使ってもらうことはできない。現場のたたき上げでここまでやってきたという自負があってもダメだ。その自負だけでは未来の自動車システムの実質的な安全性を確保できないし、諸外国に安全性を証明することができない。

諸外国への安全性の証明という観点から考えると、ISO 26262 を日本語だけで理解してしまうのは危険であると感じる。英語の規格を日本語に訳して、安全性の説明を日本語でして英語の翻訳して外国人に伝えると、二回変換があるので真意が正しく伝わらないかもしれない。よって、自分の仕事に関係する規格原文の箇所は必ず読んでおく必要がある。

【ランダム故障と決定論的故障の違い】

用語の定義は今後、少しずつ紹介していくとして、今回は random hardware failure:ランダムハードウェア故障と systematic failure:決定論的故障 について説明しようと思う。
1.92
random hardware failure
failure (1.39) that can occur unpredictably during the lifetime of a hardware element (1.32) and that follows a probability distribution
NOTE Random hardware failure rates (1.41) can be predicted with reasonable accuracy.
※(1.39)といった記述はその言葉の定義が ISO 26262-1:2011 Part 1: Vocabulary の別の項にあるということ。

ランダムハードウェア故障
邦訳:確率分布に従ったハードウェアエレメントのライフタイム中に予知できずに発生する故障
NOTE:ランダムハードウェア故障率は妥当な正確性で予測することができる。

ランダムハードウェア故障は、後述する決定論的故障の対照的な位置づけにある。ようするにある一定の故障率、歩留まりを持ったハードウェア部品の故障のことで、例えば1万個に3個の確率で故障するとか、10万時間使い続けると故障するといったもの。確率論的に故障を予測できるため、対策も立てやすい。
1.130
systematic failure 
failure (1.39), related in a deterministic way to a certain cause, that can only be eliminated by a change of the design or of the manufacturing process, operational procedures, documentation or other relevant factors
決定論的故障
邦訳:設計、開発プロセス、運用手順、ドキュメント、その他の関連する要因の変更{改善}によってのみ取り除くことができる決定論的な故障
1.131
systematic fault 
fault (1.42) whose failure (1.39) is manifested in a deterministic way that can only be prevented by applying process or design measures
決定論的欠陥
邦訳:プロセスまたは設計対策によってのみ取り除くことができる決定論的に現れる故障の原因となる欠陥

※failure と fault は用語の定義の中で何回もでてくる。 fault:欠陥 が原因となって failure:故障が発生すると考えるとよいだろう。

さて、systematic failure/fault をシステマテック故障/欠陥とせずに、あえて決定論的故障/欠陥とした理由は、どっちにしてもその言葉だけではわかりにくい概念であるため、よりわかりにくい日本語の方にして、「この言葉はなんだろう」という疑問を常に持って欲しいと思ったからである。

「設計、開発プロセス、運用手順、ドキュメント、その他の関連する要因の変更{改善}によってのみ取り除くことができる決定論的な故障」という説明でsystematic failure:決定論的故障を理解できる者は何人いるだろうか。

簡単にいってしまえばソフトウェアのバグが systematic fault で、ソフトウェアのバグ、欠陥によって起こる故障、不具合が systematic failure である。(ハードウェアによる決定論的故障もまったくないとはいえないので、ソフトウェアによる決定論的故障は systematic software fault と言うこともある)

ソフトウェアのバグによって起こる不具合を考えてみれば分かるが、ランダムハードウェア故障のようにある一定の確率で起こるようなものではない。例えばめったに通らないプログラムのある箇所を通ったときにのみ発生する不具合だったとする。そして、それが普段あまり行わない複雑なオペレーションの組み合わせによって発生する不具合だったとする。

これはまれにしか行わないオペレーションなのだから、確率で表すことができるだろうか。人間工学的にはできるかもしれない。しかし、安全保障という観点から考えてみて欲しい。ランダムハードウェア故障はある一定の確率で起きるが、今起きるかどうかと言えばほとんどの場合起きない。ユーザーも「めったに起きないがある確率で発生する故障」という状態に理解を示してくれる。

ところが、めったに通らないパスに存在するバグが原因の不具合はどんなに複雑なオペレーションであっても、そのオペレーションを実施すると確実に発生する。だからこそ、systematic:決定論的ということばが使われる。しかし、この不具合は修正したソフトウェアと入れ替えると直ってしまう。被害の大きさにもよるが、直せば直る不具合を放置することをユーザーは許してくれない。

これが、systematic failure/fault:決定論的故障/欠陥 の正体だ。ソフトウェア品質工学の世界では長年、決定論的故障/欠陥はレビューやテスト、検証、妥当性確認を含む設計プロセスや設計対策によってのみ防止できると言われ続けてきた。日本人がアウトプットする商品の品質が高い理由はプロセスや設計対策だけが要因ではないという主張はソフトウェア品質論の世界では証明できていない。(詳しくは 『ソフトウェア品質論の歴史的推移』を参照のこと)

さて、ソフトウェアの不具合に起因する危険からユーザーを守ることは、エンジニアや品質保証担当と決定論的故障/欠陥との戦いであると言える。

しかし、ソフトウェアエンジニアは数百万行もあるソースコードのすべてのパスをテストするような完璧なテストを実施することは不可能だし、不具合をたたき出すテストだけで、何も問題はないという安心を得ることなどできるないことはよく分かっている。ソフトウェアは簡単に変更することができるし、たった一行、たった一ビット変えたことでシステムの動作が変わることだってあるし、コンパイラやMAT LAB などのモデルベース設計ツールによりはき出すされたコードに変換ミスがまったくないなどと言える訳がないことは分かっている。

だからといって、ISO 26262 の適用の全体工数、全体費用に対して、ツールやコンパイラの検証に30%以上の工数や費用を割くのはナンセンスだと思う。(あくまでも個人的な見解)

ユーザーの安全確保を第一に考えれば、まずやるべきことはシステムを安全に関わる大事な部分とそうでない部分に分けて印を付けることだ。それが ASIL であり、コンポーネントも分解すれば危ない部分とそれほどでもない部分にわけることができるかもしれない、それが ASILデコンボジションだ。

システムの中の大事な部分、安全を担っている部分をできるだけを機能ごとに凝集し、他のコンポーネントとの結合を疎にして、その大事なコンポーネントに関わる設計や検証に工数や費用を投入するのがよい。そのためにはシステム全体の安全に対する分析を最初に進める必要がある。ISO 26262 の Part で言えば、2, 3, 4, 9 にあたる。

ただし、ハイブリッド車のブレーキシステムのように、多様な安全要求が求められる市場環境を見れば安全機能を一つのコンポーネントだけに集約できないことも予想される。

そのときに重要なのが安全を実現しているアーキテクチャを可視化し、それがシステムの中で有効に働いていて、かつ、決定論的欠陥が含まれていない、またはリスクが受容できていることを明確にすることが大事なのだ。

※用語の定義の邦訳にあたり、ISO 26262 の全体像を説明する図も一部ことばを見直して Ver 1.01 としたので利用して欲しい。(ISO 26262 全体構造図 開くためのパスワードは"guild26262")







ISO 26262 に関するアンケート結果(投票総数 47, 複数選択可)

44 (93%)  もっとこの規格に関する記事を書いて欲しい。
 8 (17%)  どこから手を付ければよいか分からない。  
 5 (10%)  技術者がやるべきことが分かりません。
 5 (10%)  お金や工数がどれくらいかかるか知りたい。
1 ( 2%) 売り込みが多くて困っています。  1 ( 2%)  特に興味ありません。       
 0 ( 0%)  この話題はもういい。

投票ありがとうございました。この結果を記事を書き続けるモチベーションにしたいと思います。

2011-12-05

ISO 26262との向き合い方 (3) 規格認証とスコープについて

ISO 26262 に関する記事をもっと書いて欲しいという意見が多いので、しばらくこのテーマを続けていこうと思う。(引き続き 12/9 まで右上から二番目の投票はお願いします。一番上は本テーマの記事一覧です。)

今後の構想としては、1. 一般的な話題 2. 規格の内容と考察 という記事構成で進めようかと思っている。

では

【規格認証について】

ISO 26262 に関して規格適合の認証や“コンサルテーションをやります”という会社が続々と出現している。老舗もあれば、新規参入の会社もある。

製品の安全に対して責任を負うメーカーや、開発の委託を受けるサプライヤによく考えて欲しいことがある。それは規格適合を認証したり、コンサルテーションした会社は、規格適合認定後に発生した安全に関する事故に対してなんら保証はしないということだ。

規格適合を認証した認証機関は、その製品や組織の安全性や信頼性を保証するわけではない。特にプロセス規格、ソフトウェアに関する規格に関して、なんらかの保証を与えることはできない。

一方、電気的安全性に関する規格適合に関しては、それを試験した試験所は試験内容について責任を負っている。試験の判定基準(Criteria)が明確だから、試験結果に対して責任を持つことができる。公正で正しい試験をしていることを証明できる。試験所は ISO/IEC 17025 試験所及び校正機関の能力に関する一般要求事項 の認定を取っているから、いい加減な試験レポートを出していると、試験所としての ISO/IEC 17025 の認定を取り消されてしまうのだ。

ところが、プロセス規格、ソフトウェア規格に関しては白黒が明確に判断できない要求事項だらけなので、規格認証自体の公正性、厳格性を評価することは難しい。CMMIのすごいところはなんだかんだいってそれをやりきったところだが、最近は CMMI のレベルに関する話題をあまり聞かない。ISO 26262 に関しては規格適合の成熟度のような指標はまだない。そうなると「強く推奨する」などという要求に対して適合の公正性や厳格性を問うこと自体意味がない。

よって、プロセス規格、ソフトウェア規格の適合にはかなりの範囲があると言える。はっきり言うと厳しめにも甘めにもできる。正当性を主張することが可能なのだ。ところが、こと外部規格に関しては日本人の技術者は免疫がない(ディベートのような議論のトレーニング経験がない)ため、ノーガードできついパンチを打たれる者が多い。ハタから見ていると打たれるのが好きなのではないかと思うくらい、言われるがままのように見える。

そうではなくて、日本の技術者は自分達の強みややってきたことを自信を持って主張して欲しい。ただ、そのとき相手が要求していることの意味を理解した上で主張して欲しいのだ。

規格認証機関に厳しく審査され、やっと適合を受けたとしても、適合を受けた組織、システム、コンポーネントの安全性が保証された訳ではない。何かあったときの責任を取るのは自分達なのだ。だったら、納得のしてから要求を呑むのが筋というものだ。

USのFDAや日本の厚生労働省などは医薬品、医療機器に関して規制当局としての責任を負う。USではFDAは消費者団体から認定が甘いという批判を受けて、認定を厳しくしたし、日本では注射器を使い回しを禁じていなかったことが原因で広がったB型肝炎、C型肝炎に関する訴訟が起こされ国が責任を問われている。

自動車の場合どうだろうか。規格適合を認定した機関やコンサルタントは規格認定をしたのに事故が発生したらその損害賠償責任を一部負ってくれるのだろうか。安全性を保証してくれる訳ではないし、損害賠償責任を問われることもない。よって ISO 26262 への適合は“安全保証のお墨付き”ではない。

安全に対する責任を負うということは、すなわち人の命に関わる責任を負うということだ。これはメディカルのドメインだけの話だけではない。自動車だって安全に関する機能や性能が期待どおりに動かなかったら、死に至るリスクがある。ブレーキが期待どおりに働かなかったら人が死ぬ危険がある。制動という機能や性能が、自動車の中で走行という機能や性能から完全に独立しているのであれば、制動に対する責務はブレーキのサプライヤに凝集できる。(ブレーキとアクセルの両方を同時に踏まれたときはブレーキを優先するという制御は必要だが)

その場合は、ブレーキを供給するサプライヤのみが安全に対する責務を全うすればよい。そうだからこそ、ブレーキという機能や性能の価値は高まり、ブレーキ安全に対する対価も上がり、安全なブレーキシステムを供給するサプライヤの評価も上がる。

しかし、ハイブリッド車はどうだろうか。制動という機能や性能はブレーキだけに凝集しているだろうか。現状ではドライバーがブレーキを踏んだときに回生エネルギーを回収するため、内部では複雑な機能連携を行っている。そうなったら、制動に関する責務はブレーキを製造するサプライヤだけに集約できない。だからこそ、ISO 26262 のような組織全体、プロジェクト全体に渡る安全管理を継続的に実施する必要があり、安全に関する責務、責任は一つのサプライヤに集約しにくくなってきている。だから、この機能に関しては○○サプライヤに任せておけばよいというアプローチでは安全が確保できない。(安全機能をコンポーネントに集約して、責務を閉じ込めるというアーキテクチャ設計のアプローチは可能で、その状態を可視化することは有効だ)

規格認定機関やコンサルタントは、ユーザーのリスクに対する責任は負わない。ユーザーに対する責任はメーカーが負う。ISO 26262に適合したシステムやコンポーネントを採用したメーカーは、ISO 26262 の認証があるかどうかよりも、認証に使ったドキュメント、エビデンスを評価することになる。規格に適合することのメリットは、共通の規範要求に対するアウトプットを安全管理者がレビューしやすいということにある。そして、絡み合ったコンポーネントで安全機能を実現する場合、その安全を管理する安全管理者はユーザーに対して責任を負う者でなければいけない。(自動車メーカーが担うことになるはず)

ISO 26262 の中では、2. Management of functional safety (機能安全のマネジメント)のパートの中で、開発からリリース後までの安全管理のマネジメント要求が書かれている。この部分を立案するのは、ユーザーに対して安全の責任を負う者でなければおかしい。ようするに自動車メーカーのことだ。制動の例で示したように制動のような自動車の安全に関する責務がコンポーネントに集約しきれない(コンポーネント同士の協調によって安全に関する機能や性能が実現するという意味)のなら、ISO 26262 の Part 2 を自動車メーカーがサプライヤに丸投げすることはできない。

よって、ISO 26262 によって自動車の安全に対する責務を全うするのならば、自動車メーカーは、まず、2. Management of functional safety (機能安全のマネジメント)の指針をサプライヤを含むプロジェクト関係者全体に示す必要がある。もしも、あなたがサプライヤの技術者で、自動車メーカーから 2. Management of functional safety (機能安全のマネジメント)の指針を示されていないのならば、この状況下で右往左往するのではなく、まずは規格要求について理解を深めることをお勧めする。

安全管理者からの指針が末端にまで行き渡っていないという状況は、規格の基本的な理念にこの段階で沿っていないことを示している。

もしも、何から手を付けたらよいのは分からない技術者が、何かしなければいけないと思っているのであれば、自分が作っている、これから作ろうとしているハード、ソフトが自動車の安全という側面から見たときにどのようなリスクを持つのかハザード解析をしてみるとよい。( 3.7 Hazard analysis and risk assessment )

もしも、自分が関わっている ECU もしくはソフトウェアコンポーネントの、エンドユーザーに対するリスクが分からない場合は、要求された仕様どおりのものを作るしかない。この物づくりの仕方は日本的ではないと常々思っている。インプットに対して正確なアウトプットを出力し、インプットとアウトプットの整合を検証(Verify)するところで留める。そして、この作業者は安全に対して責任を負わない。安全に対する責任を負っているのは、どのようなリスクが存在するのかを知った上で、このコンポーネントの仕様を書いた者、若しくは組織内の品質保証担当である。

自分は、日本人が作る製品の品質の高さはこんなことで実現しているとは思わない。こうではなく、末端の作業者一人一人がエンドユーザーのリスクを意識しながら Awareness: Worrying about Quality 品質を心配する意識 を高く持つ物づくりをしているから、安全を確保できているのだと思う。ただ、一人の技術者が全体を把握できないほどシステムが複雑化しているのも事実であり、Awareness: Worrying about Quality 品質を心配する意識 だけではこれまでのように安全を確保し続けることはできないことは分かっている。

だからといって、日本人の技術者は自分達の強みを簡単に捨て去るべきではないと思う。だからこそ、日本の技術者は日本人の良さを活かすためにも、自分が作っているものに対するエンドユーザーのリスクについてハザード分析をするべきだと考える。簡単に言えば、エンドユーザーの気持ちになって、どんなリスクがあるのか、どんな障害があり得るのか、事故が起こったらどのような被害を被るのかをリストアップして、重み付けし、それに対する対策を掲げてみるとよい。

まずは、自分達がアウトプットする成果物が自動車の安全の一端を担っているのかどうか、より分けていくことから始めても良い。

繰り返すが、ISO 26262 への適合を目指すのは、適合していることを誰かに自慢するためではない。自分達がアウトプットする製品の安全性を実質的に高め、安全性が高いことを客観的な証拠によって内外に示すためだ。そして安全が確保されたかどうかを示すには、ユーザーリスクが受容できるレベルまで低減できていることを示す必要がある。リスク分析、ハザード解析なしに、設計上の対策だけで安全性の高さを示すことなどできる訳がない。

【ISO 26262:2010 Scope】

ISO 26262-1:2011 の1~9の各パート には Introduction に続いて、Scope で規格の適用範囲についての説明が書かれている。Scope の大部分は各パートでほとんど同じことが書いてあり、最後の数行で各パートに関する説明がある。

ISO 26262-1:2011 Road vehicles -- Functional safety --
  1. ISO 26262-1:2011 Part 1: Vocabulary
  2. ISO 26262-2:2011 Part 2: Management of functional safety
  3. ISO 26262-3:2011 Part 3: Concept phase
  4. ISO 26262-4:2011 Part 4: Product development at the system level
  5. ISO 26262-5:2011 Part 5: Product development at the hardware
  6. ISO 26262-6:2011 Part 6: Product development at the software
  7. ISO 26262-7:2011 Part 7: Production and operation
  8. ISO 26262-8:2011 Part 8: Supporting processes
  9. ISO 26262-9:2011 Part 9: Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analyses 
今回は Scope の共通部分を順に追っていこうと思う。→は規格内容に関するコメント。
Scope (範囲
ISO 26262 is intended to be applied to safety-related systems that include one or more electrical and/or electronic (E/E) systems and that are installed in series production passenger cars with a maximum gross vehicle mass up to 3 500 kg.
ISO 26262は車両総重量最大3500kgまでのシリーズで生産される乗用車に実装される一つ以上の電気・電子システムに含まれる安全関連システムに適用することを目的としている。 
→トラックやバスは ISO 26262 の範囲外だということ。乗用車以外でも共通のリスクはあると思うのだが、この規格では扱わないらしい。不思議だ。 
ISO 26262 does not address unique E/E systems in special purpose vehicles such as vehicles designed for drivers with disabilities.
ISO 26262は、ハンディキャップを持ったドライバーのために設計された自動車のように特殊な目的の車両に搭載される独自の電気・電子システムを扱わない。 
Systems and their components released for production, or systems and their components already under development prior to the publication date of ISO 26262, are exempted from the scope.
ISO 26262 の発行以前から開発中のシステムやコンポーネントや、規格発行前に{自動車}製造のためにリリースされていたシステムやコンポーネントは本規格のスコープから外されている。 
→すでに開発が終わっているシステムやコンポーネントは対象外ということ。ということは枯れたコンポーネントを使い続けていれば対象外ということか。本当にそれでいいのか。また、規格発行前と後で ECU やソフトウェアの構成を分けて管理できるのだろうか? 規格発行前に作ったコンポーネントに対してどんなに関連が強くても、対象外にしてしまっていいのだろうか。疑問は尽きない。
For further development or alterations based on systems and their components released for production prior to the publication of ISO 26262, only the modifications will be developed in accordance with ISO 26262.
ISO 26262 の発行前に生産のためにリリースされたシステムやコンポーネントをベースにした追加の開発や改変においては、変更点のみがISO 26262にしたがって開発される。 
→本当にそんなことできるのかなあ・・・ 
ISO 26262 addresses possible hazards caused by malfunctioning behaviour of E/E safety-related systems, including interaction of these systems.
ISO 26262 は電気・電子安全関連システム、これらのシステムの相互作用を含む故障によって引き起こされる可能性のある障害を扱う。 
→この部分が重要。システムの相互作用に関連する不具合を未然に防止するためにこの規格がある。 
It does not address hazards related to electric shock, fire, smoke, heat, radiation, toxicity, flammability, reactivity, corrosion, release of energy and similar hazards, unless directly caused by malfunctioning behaviour of E/E safety-related systems.
電気・電子関連システムの故障によって直接引き起こされない場合、電気ショック、火災、煙、熱、放射線、毒性、燃焼製、反応性、腐食、エネルギーの放出等のハザードは扱わない。 
→二次的な障害は扱わない。電気、電子システムに関する複雑性を伴う一次故障を扱う。 
ISO 26262 does not address the nominal performance of E/E systems, even if dedicated functional performance standards exist for these systems (e.g. active and passive safety systems, brake systems, Adaptive Cruise Control).
ISO 26262はたとえ、これらのシステムのために存在する機能的性能の標準(例えばアクティブ、もしくはパッシブセーフティシステム、ブレーキシステム、適用型クルーズコントロールなど)に専念していても、電気・電子システムの名目上の性能を扱わない。   
→the nominal performance of E/E systems とは、たとえセーフティシステムであっても、カタログでユーザーに性能をアピールするような部分に関しては範囲外ということではないかと思う。あくまでも安全に関する基本機能に関する部分だけを見るということか。

この後、各パートに関する説明が数行書かれる。この続きはまた後日。

2011-12-04

ISO 26262との向き合い方 (2) イントロダクションを読む

自分は組織内で次の(2)の立ち位置にいる。

(1) 規格適合を求める外部機関→(2) 組織内の規格適合推進者→(3) 現場のソフトウェアエンジニア

(1) と (3) の間にあって、現場には時には厳しく、時にはエンジニアと一緒になって作業をしたり、目的に導くための教育や指導をしている。

ドメインは違うものの自動車ドメインでも (2) の立場の者の活躍なしに規格適合を現場にプラスになる形でやりきることは困難だと予測する。

(3) が日程に追われ、やらなければいけないことが山積みになっていることはよく分かっているつもりだ。だから、(3) の成熟度や安全への本気度に応じて対応を変えている。ただし、ユーザーの安全が脅かされるような危険性があると感じたときは容赦はしない。

日本のエンジニアはこれまでは安全で信頼性の高い製品をアウトプットできてきた。そのベースには Awareness: Worrying about Quality 品質を心配する意識の大きさがある。詳しくは『USとJapanの文化の違いと商品品質との関係』の記事を読んで欲しい。トヨタ自動車とアメリカのGMの両方を経験された吉村達彦氏が感じたのは、日本人技術者は Awareness: Worrying about Quality が大きく、USではそれが小さいということだ。そして、USでは、ルールや責任を重んじ、システムやツールをうまく利用する。日本人は、ルールや責任に重きを置かず、システムやツールの利用もうまくない。しかし、人一倍  Awareness: Worrying about Quality : 品質を心配する意識が強い。プロジェクトメンバの一人一人の品質を心配する意識が、総力となって日本の高品質の製品をアウトプットしてきた。

ISO 26262 は、ルールや責任に重きを置き、システムやツールの利用がうまいが、品質を心配する意識が小さい人たちのための規格であるという印象が強い。熟練した職人を意識した規格ではない。

だから、ツールや責任に重きを置かず、システムやツールの利用がうまくない、日本人技術者は「これまではできてきたのに」「これで本当に安全を確保できるのか」という感覚を持つと思う。 Awareness: Worrying about Quality : 品質を心配する意識 がこれまでに高品質を実現してきたのに、それを否定されているかのようにも感じるだろう。だからこの規格は日本では形骸化しやすい。

ではどうすればいいのか。まず、最初にやるべきことは規格が要求している安全の実現という目標に対して価値観を一致させる、すなわち方法論はとりあえず横に置いておいて、規格のコンセプトと対峙し、規格と自分たちが共通の目的の実現を目指しているという認識を持つことだ。

そのためには、規格の前文をよく読む必要がある。規格の前文にはその規格が目指していることが書かれている。それを繰り返し読むことから始めるのがよい。

それでは規格原文のイントロダクションを少しずつ読み進んでいこう。邦訳の間違いについてはコメントで指摘して欲しい。

→は自分の解釈やコメントを示す。

Introduction
イントロダクション
ISO 26262 is the adaptation of IEC 61508 to comply with needs specific to the application sector of electrical and/or electronic (E/E) systems within road vehicles.
ISO 26262は路上を走行する自動車の電気的な、または電子システムの領域のニーズに従うIEC 61508への適合である。 
→E/E のような用語の定義は ISO 26262-1:2011 Part 1: Vocabulary に書かれているので Part 1: Vocabulary は手元に置いておく必要がある。ことばの定義はキチンと書かれているので正確に把握しておく。例えば「E/E system は system (1.129) that consists of electrical and/or electronic elements (1.32), including programmable electronic elements. E/Eシステムとは 電気的またはプログラマブルな電子構成要素を含む電子構成要素からなる。EXAMPLE Power supply; sensor or other input device; communication path; actuator or other output device.」と説明されている。(1.129)や (1.32)は用語の説明が別にあるということ。これらすべての意味を理解しておく。
→この一文はようするに ISO 26262 は自動車向けの IEC 61508 機能安全規格であるということ。(余談だが、医療ドメインのソフトウェアライフサイクルプロセスの規格 IEC 62304 が IEC 61508 の派生規格であると言ったり、書いたりする人がたくさんいて、見つけるたびに間違いを指摘している。嘘だと思うなら IEC 62304:2006 の本文で functional safety というフレーズを検索してみるとよい。まったく出てこない) 
This adaptation applies to all activities during the safety lifecycle of safety-related systems comprised of electrical, electronic and software components.
この適合は電気的、電子・ソフトウェアからなる安全関連システムの安全ライフサイクルの間のすべての活動に適用される。
→自動車における安全に関係するシステムの開発から廃棄まで全期間においてこの規格が適用されるということ。 
Safety is one of the key issues of future automobile development.
安全は今後の自動車開発のキーとなる問題点の1つである。 
→ここが大事。安全の確保のために必要なことをこの規格は要求している。それを実践することが安全の確保につながるという意識を持つことが大事だ。
New functionalities not only in areas such as driver assistance, propulsion, in vehicle dynamics control and active and passive safety systems increasingly touch the domain of system safety engineering.
{自動車の}新しい機能はドライバーの補助、推進力、車両力学制御、アクティブ、パッシブセーフティのような領域だけでなく、ますます、システム安全工学の領域に踏み込んできている。 
→障害物を検知して自動的にブレーキがかかるようなシステムも実用化されている。(スバルのプリクラッシュブレーキのCMで最後に一瞬だけ注意事項の文言が表示されることにお気づきだろうか。このようなインテリジェンスを持った安全機能はメーカーは最大限ユーザーにその効果効能をアピールしたいが、その機能には限界や保証できないことがあるということをよく見て欲しい)エアーバッグシステムも同じだ。 
Development and integration of these functionalities will strengthen the need for safe system development processes and the need to provide evidence that all reasonable system safety objectives are satisfied.
これらの機能の開発と統合は、安全システム開発プロセスの必要性と、すべての妥当なシステム安全目標が満足しているという証拠を提供する必要性を強くするだろう。 
→安全性を内外に示すためにはその妥当性を証拠・証跡によって示すことが求められる。日本人には苦手な領域ではあるが、これはグローバルマーケットで商売をしている限りやらなければいけないことである。 
With the trend of increasing technological complexity, software content and mechatronic implementation, there are increasing risks from systematic failures and random hardware failures.
増強する技術的な複雑さ、ソフトウェア内容、およびメカトロニクスの実装の傾向と共に、決定論的原因故障とランダムハードウェア故障から増加するリスクがある。 
→今後 ISO 26262 が必要になる理由はここにある。自動車は安全を実現するための付加価値を次々にユーザーに提供するようになるのだが、これによりシステムはどんどん複雑になり、決定論的原因故障が増加するのは間違いない。この対策を取らなければ利用者の安全は脅かされてしまう。このことには現場のエンジニアも同意してくれるはずだ。『Random Failures と Systematic Failures の違い』を参照のこと。 
ISO 26262 includes guidance to avoid these risks by providing appropriate requirements and processes.
ISO 26262は、適切な要求とプロセスを提供することによってこれらの危険を避けるためのガイダンスを含んでいる。 
→ISO 26262 はそのリスクを規格要求とプロセスによって回避しようとしている。日本のエンジニアは本当にそれで安全が実現できるのかどうかを納得できるまで考える必要がある。 
System safety is achieved through a number of safety measures, which are implemented in a variety of technologies (e.g. mechanical, hydraulic, pneumatic, electrical, electronic, programmable electronic) and applied at the various levels of the development process.
システム安全は多くの安全対策を通して達成される。安全対策は、さまざまな技術(例えば、メカニカルな、水中力学の、空気の作用による、電気の、プログラム可能な電子的な技術)で実装されて、開発プロセスの様々なレベルで適用される。 
→自動車の安全は一つの領域では達成できないという主張は同意できる。ハードウェアだけでもソフトウェアだけでもダメで、安全を実現するためのリスクコントロールをすべての領域の総合力によって実施する。 よってサプライヤ任せ、各担当任せで安全は確保できない。それぞれが安全に関する情報を共有し合って、納得し合って製品を作り上げなければいけない。
Although ISO 26262 is concerned with functional safety of E/E systems, it provides a framework within which safety-related systems based on other technologies can be considered.
ISO 26262は電気・電子システムの機能安全に関係があるが、それは他の技術に基づく安全関連システムも考慮できるフレームワークを提供する。 
ISO 26262:
ISO 26262 は次を提供する 
a) provides an automotive safety lifecycle (management, development, production, operation, service, decommissioning) and supports tailoring the necessary activities during these lifecycle phases;
a) 自動車の安全性ライフサイクル(マネジメント、開発、生産、運用、サービス、廃棄)を前提として、これらのライフサイクル段階の間、必要な活動の実現をサポートする。 
b) provides an automotive-specific risk-based approach to determine integrity levels [Automotive Safety Integrity Levels (ASIL)];
b) 自動車安全インテグリティレベル(ASIL)を決定するため、自動車の固有のリスクベースアプローチを提供する。 
→IEC 61508 では SIL という指標があるが、ISO 26262 では自動車用にカスタマイズしている。その内容については ISO 26262-9:2011 Part 9: Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analyses に詳しい説明がある。 
c) uses ASILs to specify applicable requirements of ISO 26262 so as to avoid unreasonable residual risk;
c) 合理的でない残留リスクを避けるためにISO 26262の規定要件を指定するのにASILを使用する。 
d) provides requirements for validation and confirmation measures to ensure a sufficient and acceptable level of safety being achieved;
d) 達成される安全の十分で受容できるレベルを確実にするための妥当性確認と判断基準の要求を提供する。 
e) provides requirements for relations with suppliers.
e) サプライヤとの関係に関する要求を提供する。 
Functional safety is influenced by the development process (including such activities as requirements specification, design, implementation, integration, verification, validation and configuration), the production and service processes and by the management processes.
機能安全は開発プロセス(要求仕様書、設計、実装、統合、検証、妥当性確認、および構成管理のような活動を含んでいる)と、生産と保守プロセスとマネジメントプロセスに影響を受ける。 
Safety issues are intertwined with common function-oriented and quality-oriented development activities and work products.
安全問題は一般的な機能指向と品質指向の開発活動と作業の成果物をからめていく。
→機能を実装するのは顕在的価値の実現、 当たり前品質を含む品質を作り上げるのは潜在的価値の実現である。システムが複雑になればなるほど、これらは分けて考えられなくなってくる。将来カーナビゲーションの情報(今どこを走っているのかといった情報)が自動車の安全の実現に使われるかもしれない。ブレーキは安全にのみ使われ、カーナビ、オーディオのような機能とはアイソレート(隔絶)されているという時代は終わりつつある。その場合、安全を実現する要素の他の要素との結合度や安全機能自体の凝集度を内外に示せるようにしておく必要がある。今後起こりうる安全問題は機能面と品質面の両方をプロセスで作り上げた証拠によって説明しなければいけない。
ISO 26262 addresses the safety-related aspects of development activities and work products.
ISO 26262は開発活動と作業の成果物の安全に関連する面を扱う。 
Figure 1 shows the overall structure of this edition of ISO 26262.
図1はISO 26262のこの版の全体的な構造を示している。 
ISO 26262 is based upon a V-model as a reference process model for the different phases of product development.
ISO 26262は製品開発の異なったフェーズのためのから参照プロセスモデルとしてVモデルに基づいている。
Introduction の文章と Overview of ISO 26262 の図は ISO 26262-1:2011 のすべてのパートの先頭に挿入されている。

ISO 26262 の全体像を説明する図は非常に重要であり、常に手元において眺めておく必要がある。原文の図をトレースしなおしたものと邦訳したものをPDFにしたのでダウンロードして利用していただきたい。(ISO 26262 全体構造図 開くためのパスワードは"guild26262")

12/9 まで引き続きアンケートをお願いします。(ブログの右上)

2011-12-01

ISO 26262との向き合い方 (1) 最初に読んで欲しいこと

まず、自分が ISO 26262 にこだわっている理由を書こうと思う。

自分は医療機器ドメインのソフトウェアエンジニアとしてのキャリアが24年である。そして、約20年前、自分がソフトウェアを担当した製品が、FDA(アメリカ 食品医薬品局)の定期査察で査察の対象となり、Warning Letter を受け、約1年間アメリカ向けの出荷が停止された。

その当時、一人で製品のソフトウェアを作っており、システム全体を完全に把握できていたし、ソフトウェアの検証についても我流ではあったが自信があった。実際、その製品でソフトウェアの問題はほとんど起こらなかった。(唯一、たった1ビットの設定ミスでソフトウェアを改変したことがあったので完璧ではなかった)

1990年頃、すでに、FDA は医療機器や医療機器に搭載されているソフトウェアに対して V&V (Validation & Verification)を客観的な証拠によって示すことを要求していた。

自分は個人のファイルとして検証記録を持っていたが、それは組織的な品質マネジメントの一環として実施したものではなかった。すなわち、「自分はキチンとやっていたが、組織的な品質システムとして実施されたものではない」という状態だった。

それだけの問題ではなかったが、組織的にFDAが要求している品質システムが実施できていないという理由で Warning Letter が発行され、その後、是正できたことを示すための取り組みを苦労しながら実施し、確認の監査をパスした。

その当時、自分は「なぜ、それがダメなのか」「担当製品の検証の証拠があるのになぜ認めてくれないのか」まったく分からなかった。

その後、FDAが公開している要求を読み進むうちに、その理由が分かった。個人が自分の考えで実施している検証は品質マネジメントに基づいたものではないローカルルールで行われものであるため認められないのだ。

おそらくこの認識のギャップは、国民性にも大きく関係している。プロジェクトへの人の出入りが多い欧米の企業では、個人的なアクティビティで支えられている信頼や安全は非常に危ういものに写る。製品のライフサイクル全て、また、製品群のライフサイクルのほとんどに同じ技術者が関わるような日本の開発スタイル、品質保証の概念とは状況が異なる。

だからこそ、しっかりやっているはずだった自分の製品への Warning Letter は青天の霹靂だった。ただ、このことは自分の技術者人生の中で大きな分岐点となった。世界標準のやり方でないと通じないことがあることに気がついた。この頃から品質マネジメントシステムとは何か、日本人が品質を作り出すやり方とは何が違うのかについて考え続けている。

この出来事ををきっかけにして、アメリカや国際標準が求める品質マネジメントシステムやソフトウェアの安全設計、品質管理について約20年間取り組んでいる。

自分は品質保証部門出身ではない。いくつかの製品開発の実績を経て、技術者から支援者になった。製品担当、エンジニアの視点と品質保証や規格適合を求める側の視点も持っている。

だから、自動車ドメインで ISO 26262 の適用に関して、現場のソフトウェアエンジニアがこれから苦しむことがどんなことか分かる。実際に医療機器のドメインで20年前に経験済みだから、自動車系のエンジニアがこれからどのようにして階段を上っていかなければいけないのかが見える。

ここ数年で多くの自動車系技術者が青天の霹靂を実感することが分かっている。そして、そのショックが「した方が良い」と書かれていることを「しなければならない」と判断させてしまうことも分かっている。ISO 9001:1997 や CMMI の取得を目指したときのことを思い出して欲しい。規格要求を神のお告げのようにふれ回る者が必ず出てくる。

ISO 26262 は誰のために、何のために作られたのか。それは、自動車を利用するものの安全のためだ。これからの技術者の努力が、いかに大変であろうと自動車の安全に貢献するものであればよい。しかし、自動車メーカーやサプライヤのエンジニアが外乱光で利用者の安全という目標を見失ってしまうのは忍びない。

幸い、医療機器ドメインは市場もそれほど大きくなかったせいか、これまで、そういった外乱光はなかった。アメリカ人は我が道を行くが、基本的にフェアーな精神を持つ。よって、FDAの査察は非常に厳しいがそれで儲けようという考えはない。あくまでもアメリカ国民の安全を確保するために厳しくチェックをする。

そのコンセプトに自分は共感を持っている。あくまでも目的は利用者の安全であり、そのためにやるべきことを要求する。要求とは異なる手段であっても、利用者の安全が確保できる代替え手段があるのならばそれは認められる。

こういった国際標準に対する考え方が分かっていないと、振り回されたあげくに、利用者の安全をかえって脅かすハードウェア、ソフトウェアができてしまう。自分は門外漢かもしれないが、そのことをを非常に恐れているし、技術者、特に日本のソフトウェアエンジニアも規格に適合したら前よりも危ういソフトウェアになってしまったなどという結果は決して望んでいないと思う。

こんな背景から、自分はドメイン違いでありながら、 ISO 26262 に関する記事を書いている。

もしも、このブログの読者がさらなる情報を引き出したいと思うのであれば、このテーマに関する記事を続けていこうと思っている。ブログの右上にアンケートがあるので12/9 までに投票してもらい、反応が多ければ、このテーマの記事を続けたいと思う。

【ISO 26262 の取り組み方 その1】

前置きが長くなってしまったのだが、記事一回につき、一つ以上のトピックスを書いていきたい。まずは、その1 「国際規格の読み方」。

国際規格を読む場合、注目して欲しいのは規格番号の後ろに付いている年号である。ISO 26262 の場合、2011年に発行されたので、ISO 26262-1:2011といったように表現される。

なぜ、年号に注目すべきかというと、規格は必ず改変されるという目で見て欲しいからである。時にISO 26262 は新規に制定された規格だから、運用していくうちに問題点がどんどんでてくる。この場合、規格の利用者はその問題点を国際委員に告げて、よりよくしていけばよい。

日本人の多くは国際規格は天から振ってくると思っている。実際にはそうではない。国際規格は各国で意見を出し合って、よりよい方向に修正していくものなのだ。日本人は奥ゆかしいから、文句をなかなか言わないが、おかしいと思うこと、修正した方がよいと思うことはキチンと主張しないと自分達が損するだけだ。

では誰に言えばいいのか。それは各業界には工業会があり、工業会から必ず ISO Technical Committee に代表を出しているはずだから、工業会の代表に問題点を伝え、工業会に参加していないのなら今からでも参加すればよい。自組織に工業会の代表がいるにもかかわらず、その人が情報を発信しない、もしくはその人へ情報を伝達しない技術者がたくさんいる。それでは国際規格を自分達に使いやすいように変えることはできない。まずは、交渉のテーブルに乗る必要がある。

さて、ISO 26262 に取り組むにあたって最初にするべきこと、それは規格を読むことだ。最初に自動車メーカーとサプライヤのエンジニアに警告しておきたいのは、規格を読まずにコンサルタントなど外部の者から知識や支援を一方的に受けては絶対にいけないということだ。

例えば、ISO 26262-6:2011 Part 6: Product development at the software で

Methods for the verification of software unit design and implementation のセクションの表9に

Control flow analysis と Data flow analysis が ASIL C と D について ++ となっている。

++ の意味は“++” indicates that the method is highly recommended for the identified ASIL;だ。

highly recommend は強く推奨されるだから、日本語に変換すると、「ASIL C と D のソフトウェアユニット設計では、コントロールフロー分析、データフロー分析をすることを強く推奨する」という要求になる。

8.4.5 The software unit design and implementation shall be verified in accordance with ISO 26262-8:2011 Clause 9, and by applying the verification methods listed in Table 9, to demonstrate:

※26262-8:2011 Clause 9 のタイトルは"Verification" で具体的に関係ありそうなのは 9.4.3 Verification execution and evaluation と思われる。

とあるので、表9 に示された検証メソッドを使って ISO 26262-8:2011 箇条9 への一致を示せと言っているが、考えてみて欲しい。電気的安全性に関する要件、例えば「患者漏れ電流が AC/DC 0.01mA 以下」ならば、テストによって確実に合格か不合格かを判定できる。ところが、ソフトウェアの場合、「コントロールフロー分析、データフロー分析をすること」と、利用者の安全は直接は結び付かないし、「コントロールフロー分析、データフロー分析」ができているのかどうかどうか、目的に対して効果を発揮できているかどうかを証明するのも難しい。ようするにに自分達が目的の達成のために有効であることを確信した上で、実施しましょうというのが本質的な要求のはずだ。

※医療機器ドメインでの歴史的経験から考えると、できているかどうか客観的に判定できないことを規格要求にしてしまっているところに ISO 26262 の未熟さを感じる。こういう場合は方法論ではなく、Activity (どのような活動が必要か)を要求してその活動に対するエビデンスがあるかないかをまずチェックし、その次に段階で活動の妥当性(=目的への貢献度)をヒアリングするような仕組みの方がよいと思う。方法論を推奨してしまったら、その方法論が絶対に必要だという話しが一人歩きするのは目に見えている。

これを規格原文の NOTE を含むディテールを読まずに、また規格を適合する側のスタンスが固まっていないうちに外部の者から話しだけ聞くと「自動車のソフトウェアユニット設計では、コントロールフロー分析、データフロー分析をしなければいけない、しないと規格が通りませんよ」となる。人間は、潜在的にそうして欲しいと思うと、表現をより大きくして聞いている者の気を引こうとするからそうなるのだ。

自分ならこう言う。

ISO 26262 では ASIL C と D のソフトウェアユニット設計において、コントロールフロー分析、データフロー分析をすることを強く推奨しています。なぜ、それが必要だと主張しているのか分かりますか。まず、この○○のソフトウェアユニットの ASIL を C と D にしている根拠を説明してください。そのユニットがユーザーに及ぼす危険はどのように回避されるのか、意図しないようなシステマティックフェイラーが起こらないためにどんな分析、設計、検証をしているのか教えてください。

そこで、十分に納得のいく説明ができるるのなら、コントロールフロー分析、データフロー分析以外の手段を使っていたとしても、外部の人間に聞かれたら、それを堂々と説明するように言う。全く何のことかわからないという反応を示したら、方法論ではなく規格のコンセプトや背景をプロジェクトメンバ全員に対してレクチャーする。そのトレーニングから始めなければ手段が目的になる。

手段が目的になってはいけない。目的を達成できるのなら手段は重要ではない。規格が手段を例示しているのは、何をすればいいのか分からない、これから何をすればいいのかの指針が欲しい者にサジェスチョンを与えているのだ。だから、highly recommend と表現しているのだ。highly recommend を「絶対にやらないといけないと規格に書いている」という者は驚くほどたくさんいる。彼らの中には悪気がなく、大事なことを教えて上げようと親切心でそういう者もいる。そう、彼は規格適合を自分の力でやりきった経験がないから、簡単に表現を強くしてしまう。しかし、自分はそれを現場でやりきることがどれだけたいへんかを知っているから、軽々しく highly recommend を「絶対にやらないといけない」などとは決して言わない。

したがって、規格適合を目指しているメーカーとサプライヤのエンジニアは必ず、規格の原文を読み、誰かから「規格要求だから○○をやれ」と言われたら、規格のどこの要求のことを言っているのかを聞く習慣を付けるべきだ。そして、その方法が利用者の安全にどのように貢献するのかを必ず考える。そこに確信が見いだせないのに実践しても意味がない。利用者の安全に貢献するという確信があってこそ、その方法論は生きてくるし、実際にそうなる。エンジニア側の確信なしにコントロールフロー分析、データフロー分析をやって、利用者の安全につながるわけがない。形式的に規格適合を示すことに貢献するだけだ。

ISO 26262 のような国際規格は、多くの場合工業会が和訳して対訳版を日本規格協会が発売する。最近は PDF 版と 紙のどちらかを選択して買うことができる。現時点で ISO 26262 は邦訳版ができていないようで、英文のものしか売られていない。(ちなみに ISO の本家からも買うと 円高差益の御利益に預かれるのに、日本からアクセスしていることが分かると 日本規格協会から買いなさいと怒られる。)

さて、ISO 26262 は下記のようにパート分けされており、それぞれ単独で発行販売されている。FDAがガイダンスを無料で公開しているのに対して ISO 規格はしっかりお金を取る。下記の各パートは日本規格協会で買うとそれぞれ一万円くらいするが、適合を目指すのであれば買うしかない。

ちなみに、自動車系のソフトウェアサプライヤーなら、まずは、Part1, 2, 3, 6 を読んで欲しい。工業会の邦訳を待たずに、英語版を買って組織内で持ち回りで訳しながら勉強会をするとよい。邦訳しながら読むと詳細に理解できる。

ISO 26262-1:2011 Road vehicles -- Functional safety --
  1. ISO 26262-1:2011 Part 1: Vocabulary
  2. ISO 26262-2:2011 Part 2: Management of functional safety
  3. ISO 26262-3:2011 Part 3: Concept phase
  4. ISO 26262-4:2011 Part 4: Product development at the system level
  5. ISO 26262-5:2011 Part 5: Product development at the hardware
  6. ISO 26262-6:2011 Part 6: Product development at the software
  7. ISO 26262-7:2011 Part 7: Production and operation
  8. ISO 26262-8:2011 Part 8: Supporting processes
  9. ISO 26262-9:2011 Part 9: Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analyses 
自動車メーカーとサプライヤのエンジニアは ISO 26262 が利用者の安全にどのように貢献するのかについて、十分に議論し、確信を得ることから始めなければいけないということを強く主張したい。

※この記事をここまで読んでくれた方はこの後『ISO 26262との向き合い方 (21) 安全について理解を深める』を是非続けて読んでいただきたい。そうすれば、筆者がなぜ、この規格にこだわっているのかの本質が分かると思います。

2011-11-26

ソフトウェア系の国際規格はどのように使うのか(2)? (ISO 26262 が正式発行される)

前回に引き続き、ソフトウェア系の国際規格(ISO 26262)がどのように使われるのかを解説したいと思う。

自分は自動車ドメインの仕事はしていない。しかし、ソフトウェア系の国際規格には長いことつきあっているので、おそらくこの見解は当たっていると思う。もしも、自動車業界の方で間違っているところに気がついた方は是非お知らせ願いたい。このブログ上で訂正したい。

まず最初に読者に認識して欲しいのは国際規格はそれだけでは法的な拘束力はないという点だ。国際規格と聞くと国際法のように守らないと罰則がある、当局に捕まるというイメージを持っている人が大勢いるようだがそうではない。

国際規格は各国の規制当局が規制に使うと宣言したときに初めて法的拘束力が生じる。日本のトヨタ自動車が ISO 9001 を取得していないという事実は有名だが、だからといって誰からも咎められることはない。トヨタは ISO 9001 に適合てきなくても自分たちのやり方で品質をマネジメントできているからいいのだ。

他の国際規格も全く同じだ。自信がある組織は国際規格を使わない選択肢も取れる。しかし、多くの場合は国際規格に乗っかった方が楽であり、みんなと同じであるとアピールしやすい。さて、では自動車の電子制御系に関する安全規格 ISO 26262 が2011年11月15日に正式発行されたがこれはどうだろうか。

EUとUS(アメリカ)と日本、中国、その他一般海外で分けて考えてみよう。

まず、EU。ISO規格を最も重要視するのがヨーロッパの国々で特にドイツがその度合いが強い。ドイツを筆頭にEUの国々は ISO 規格の策定に積極的に参画するし、策定された暁にはそれらに適合することに精を出す。自分たちでルールを決めてルールを守ろうとする。

そしてドイツには有力な二つの規格認証機関がある。これらの認証機関は世界展開しており、主要各国に拠点を持っている。規格認証機関は規格の策定にも関わり、規格が発行されると、その規格を認証することで利益を得る。規格認証ビジネスは結構儲かる。規格の適合を監査し、適合できていないことが分かると、その規格が何を求めているのかを説明し、適合できるように指導する。監査するときも指導するときも費用が発生するから、厳しく監査してダメだしすればするほど、やるべきことが増えてたくさん指導を受けなければいけない。

ドイツの規格認証機関は特に厳しく規格適合を求める傾向があり、結果として厳しく監査して欲しい対象企業からの信頼が高い。

そういう傾向があるため、ドイツのメーカーは規格適合に積極的であり、ドイツの自動車会社が日本のサプライヤーに対して ISO 26262 への適合を求めるシチュエーションは大いにあり得る。しかし、これは法的な要求ではないことを頭に入れておいて欲しい。ただ、クライアントが規格に適合せよと言ってきたのであれば、サプライヤーはイヤとはなかなかいえない。なぜなら、「イヤなら規格適合している他の会社から調達するか君たちとはサヨナラ」と言われてしまうからだ。

ただし、冷静に考えて欲しいのは、例えばイタリヤやイギリスの自動車メーカーがドイツほど強くISO 26262 への適合を求めるだろうかということである。自分の予想では EU の中でも声高に言ってくるのはドイツの会社だけだと思う。それでなくても、今 EU は大変な状況なのに、規格適合のために莫大な費用をかけたいとは思わないはず。まして、法的な要求でもなんでもない規格への適合に今人と金をかけようと考えるヨーロッパのメーカーとサプライヤがどれだけいるかと思う。

つぎにアメリカの考え方だ。アメリカは国際規格をそれほど重視しない傾向がある。代わりに自分たちで作ったルールが一番だと考え、アメリカ国民の安全を守るために自分たちが決めたルールを守らせる。このルールにはばっちり法的拘束力をもたせる。時にTBT協定違反だと批判されることがあるが、そんなことは気にもせず、我が道を行く。

よって、アメリカの自動車会社がサプライヤに対して ISO 26262 の適合を直ちに要求するとは思えない。アメリカ人はフェアーを重んじるので、アメリカ国内のサプライヤに求めず、国外のサプライヤだけに求めるということはしない。

ただし、アメリカは訴訟社会であるため、事故が起きた時に、自動車に搭載されたソフトウェアの安全性について説明せよと言ってくる可能性はある。そのとき、ISO 26262 に適合してソフトウェアを作っていると主張するのは説得力があるだろう。

つぎに日本。日本は ISO 規格をそのまま規制に使うことはない。まず、日本工業規格 JIS にする。要するに日本語にする。これには結構時間がかかり、2~3年はざらにかかる。通常は工業会が持ち回りで翻訳をし、何回か見直しをかけたあとパブリックコメントを募り JIS 規格として登録される。

ただ、JISになったからといってそれが規制になるわけではない。車ドメインのことは詳しくないが、自動車に関する許認可の権限を持っているのは国土交通省だろう。国土交通省が法律に基づいて自動車に搭載されているソフトウェアの安全性を審査できるかと言えば、できる訳がない。それをやるには法律を改正する必要がある。また、国土交通省が自動車のソフトウェアの安全性を審査できる訳がない。そんなことができる人材も組織もない。何十年も前から取り組んでいるドイツだって難しいと思われるのに、これまでまったく取り組んでいなかった日本でソフトウェアの審査はできないし、仮にやり始めたらとんでもない指摘が飛んでくる可能性がある。例えばソフトウェアに関する知識がまったくない審査官が「このソフトウェアはコードレビューはしているのかね」などと、よく意味も分からず聞いてくるかもしれない。

また、現在自動車のソフトウェアで社会的な問題が頻発しているか。そんな話はないし、日本の自動車は世界一品質が高いと言われている。取り締まりを強化しないと国民の安全が確保できない状況ではない。

よって、日本では ISO 26262 は法的規制になるとは到底思えない。

次は中国。中国は予測がしにくい国だ。どの分野においても国際的なレベルに達したいと考えているため、国際規格への取り組みの意気込みは日本よりは遙かに強い。しかし、国際規格が求めるレベルにすぐに達することができるかどうかという問題もある。よって、周りの国々の様子を見ながら遅れを取らないようにしようとするだろう。おそらく政府として ISO 26262 の要求についての勉強はしていると思うし、中国語への翻訳も始めているかもしれない。ただ、だからといって規格を規制にするかどうかはわからない。中国国内のメーカーがまだ対応できないと見たらすぐには規制用件にはしないかもしれない。

最後に一般海外は、各国の動向を見てみんなが規制するようになったら同調するだろうと予測する。

【誰が何のために ISO 26262 を使うのか?】

これまで解説したように、現時点で ISO 26262 の適合の積極的なのはドイツであり、ドイツの自動車メーカーが日本のサプライヤに対して ISO 26262 の適合を要求する可能性は高い。また、日本の自動車会社が日本のサプライヤに安心材料として ISO 26262 への適合を求める可能性もあるかもしれない。

ただし、ドイツと日本の場合では事情が異なる。ドイツは歴史的に国際規格への適合をチェックするための規格認証機関を持っている。彼らは規格の内容もよく理解しており、監査テクニックも持っている。個人レベル、会社レベルの規格適合コンサルタントもうようよいる。規格適合に関するビジネスモデルができている。

ところが、日本には日本オリジナルの規格認証機関はあまりない。特に、ソフトウェアを監査できる認証機関は存在しない。しかし、ドイツを始めEUでは規格適合ビジネスの市場はあるので、日本でもそのビジネスモデルに乗っかりたいと思う会社はたくさんいる。

でもソフトウェアの監査の経験は皆無に等しいだろうから、最初のうちは規格適合について尋ねている方も答えている方も何を言っているのかわからないという状況が続くだろう。

したがって、ここ数年はドイツを始めヨーロッパの自動車会社が ISO 26262 への適合を日本のサプライヤに対して求めるだろうが、規格への適合を監査できそうなのはヨーロッパ系の規格監査経験の長い規格認証機関に頼むことになる。

そして、ソフトウェアの監査ができる人材は希少なため、本質的な突っ込みを入れることはほとんどできず、結果的に規格適合はチェックシートを埋めるという形式的なものになると予測する。

そこで、サプライヤの皆さんに聞きたい。「誰のために、何のために ISO 26262 に適合するの?」「誰のために、何のために ISO 26262 に適合したいの?」と。

この質問に対して、「クライアントから求められているから」と答えるのならは、それは形式的なことのために人、物、金を投入するのだと考えた方がよい。

「自分たちが作ったソフトウェアが安全で信頼できることを証明するための手段として ISO 26262 を使う」と答えるのならば、その組織は投資が無駄にならないかもしれないし、この不景気な時代に規格ビジネスで金儲けしたいと集まってきて有象無象の輩をかき分けて真の支援者を探し出せるかもしれない。

前者でお金を捨てたくないのならば、まず、規格要求を腰を据えて読むことだ。そして、規格認証機関には規格要求の疑問点を尋ねる。要求の中身を一回も見ないで、規格認証機関やコンサルタントに頼ってはいけない。それは思うつぼで湯水のように形式のためにお金を使うことになる。

そして、技術誌の編集の方たちにお願いしたいのは、ISO 26262 の策定委員に対してのインタビュー記事を多く載せて欲しい、できれば座談会をしたり、それぞれに記事を寄稿してもらって欲しいということだ。国際規格はそれを読んだだけでは、規格の本当の意図が分からないことが多い。そしてそれが分からないと、規格認証機関やコンサルタントが自分たちのビジネスに有利になるように規格を解釈してクライアントに伝える。そうなるとサプライヤは形式に金を使い、本質的な安全にはなかなか近づかないという不幸が訪れる確率が高くなる。

繰り返すが、今一度考えて欲しいのは、誰が何のために国際規格を使うのかという点だ。

※本件に関するコメントを募集していますのでよろしくお願いします。

2011-11-24

ソフトウェア系の国際規格はどのように使うのか? (ISO 26262 が正式発行される)

自動車の電子制御系に関する機能安全規格「ISO 26262」が、6年間の策定期間を経て、2011年11月15日ついにISOの正式な国際規格となった。


下記が Tech-On! で報じられた記事である。

クルマの機能安全規格のISO 26262がついに正式発行

自分は自動車ドメインの仕事はしていないが、メディカルデバイスの世界で国際規格とは20年以上付き合っている。

そこで自動車ドメインの方々にアドバイスをしておきたいと思う。

【ソフトウェア系の国際規格はどのように使うのか?】

  1. 自分達がアウトプットしているソフトウェアの安全性や信頼性を外部に対して説明するために使う。
  2. 実質的に自社のソフトウェアの安全性や信頼性を高めるために使う。

1の説明責任を果たすためという目的と2の実質的な目的は、同じように見えてかなり差がある。

なぜかというと「説明責任を果たせること」と「実質的に安全であること」は必ずしもイコールではないからだ。特に日本の組込みソフトウェアは、実質的にリコールの件数が少ないが、説明責任を果たせる組織やプロジェクトは非常に少ない。

それは一つは、日本人が元来記録を残す文化が希薄だからだ。嘘だと思う人は40年来のベストセラーとなっている梅棹 忠夫氏の『知的生産の技術』を読んでみるとよい。

もう一つの理由は日本人は品質を気にする気持ち Awareness がプロジェクトメンバー一人一人に浸透しているため、開発プロセスを厳格に管理しなくても、安全性や信頼性の高いソフトウェアを作れるという特性を持っているからだ。ソフトウェア系プロセスの国際規格の根幹にはソフトウェア品質はプロセスを管理することでしか測れない、証明できないという主張があり、その主張を覆すことはまだ誰もできていない。

日本人が品質を気にする気持ち Awareness が安全性や信頼性の高いソフトウェアを生み出しているからといって、日本人が作るソフトウェアの安全性や信頼性を外部に説明する責務を放棄することはできない。「日本人が作っているので安心してください」と言っても今や説得力がないからだ。

100万行を超えるようなソフトウェアの規模になってしまった現在では、すべてのソフトウェアが日本製だとは限らないし、一人のソフトウェアエンジニアがシステム全体を把握できない。

だからこそ、ソフトウェアの安全性や信頼性を何かしらの標準を使って外部に説明する必要がある。

そのときに、国際規格を使うと説明の効果が高い。国際規格は各国の代表が原案を審議し投票によって決めた標準であるから、その内容に沿って説明責任を果たすのは合理的だ。仮に、日本のメーカーが作ったソフトウェア搭載製品が事故を起こしたときに、「そのソフトウェアは安全なのか、信頼はおけるのか」と聞かれたら「国際標準に適合しています」と答えることができる。そうでない方法で、説明責任を果たすのは可能かもしれないが非常に難しい。特にソフトウェアの場合は、バグは一つもないと言い切れないからなおさらだ。

よって、ソフトウェアの国際規格に適合していることは、安全性や信頼性を主張するための根拠となりうる。

ただし、ソフトウェアの国際規格とハードウェアの国際規格の間には決定的な相違点がある。それはハードウェアの場合は規格に適合しているかどうかが試験によって判定できるが、ソフトウェアの場合は正当性を試験では判定できないことがほとんどなのだ。

ソフトウェアのつくりかたは千差万別で、ある作り方をすれば確実に安全とか信頼できるとは言えない。また、ソフトウェアの最大のメリットは変更容易性であるから、一度安全性や信頼性を確認しても、たった一行変更しただけで、その安全性や信頼性は崩れる可能性がある。

よってソフトウェアの国際規格では要求に対して、その通りにしていなくても別の代替え手段で説明することが容認されている。要求に対して根拠を持って説明できればそれでもOKとなるのだ。

これが日本の技術者は本当に苦手だ。自分達のやっていること、やってきたことに自信があれば、堂々と説明できるののに、監査等で説明を求められると急にできていないことばかりが頭をよぎり、できていること自信があることを全面に出して主張することができない。

ディベートの訓練をしていないせいもあるだろうが、元来正直者ではったりをかますのが得意ではないのだ。決して嘘を言えといっているのではない、相手の要求を理解した上で、本質的な目的(エンドユーザーに対する安全や信頼)のために日々やっていることを自信を持って主張すればよいのだ。それは毎日の自分の行動に対して根拠を説明できる技術者であればできるし、誰かから言われた通りに日々を過ごしている者にはできない。

後者は、自分ややっていることに自信がないから「この方法論を使うと規格に適合できますよ」とか「このツールを使うと規格に適合できますよ」と言われるとすぐにそれに乗って「よく分からない要求から逃れたい」「楽になりたい」と考える。それは、完全に思うつぼだ。

説明責任を果たす目的を達成したいのなら、まずは国際規格の要求を自分の頭で理解することだ。要求を理解せずに方法論に乗っかろうとしてはいけない。そうすると必ず振り回され、最終的には監査やオーディットの際に「このツールを使っているから規格に適合できています」とか「○○に適合を確認してもらっています」などを答えて早々と「これはダメだ」と烙印を押される。

監査や査察で一番重要なのは、実担当者が規格要求をどれだけ理解しており、その要求に対してキチンと受け答えができるかどうかだ。規格要求の真意を理解もせずに方法論に走ってしまっている場合、実担当者は受け答えができないので、すぐにコンサルタントやQA担当に助けを求ようとする。監査官、査察官はその目の動きを決して見逃さない。

国際規格を使ってソフトウェアの安全性や信頼性を説明したいのなら、まず、規格要求を理解している者を組織内に少なくとも一人は作る必要がある。そして、実務担当者も徐々に理解を深めていく。


2番の「実質的に自社のソフトウェアの安全性や信頼性を高めるために使う」はまたの機会に説明をしたいと思う。

今回の記事に関して、疑問質問がある方はこの投稿にコメントを書いて欲しい。(必ず回答を書きます)

2011-11-06

スティーブ・ジョブズの伝記を読んで


iPad で Steve Jobs ⅠⅡを読んでいる。現在はⅡの頭の方で、スティーブ・ジョブズが一度 Apple から追い出された後復帰してApple を立て直そうとしているところだ。

この本(電子書籍)を読んでいると、途中で無性に Apple ⅡやMacintosh、ジョブズの演説、有名なCMなどが見たくなる。

電子書籍なのだから写真やリンクを埋め込んでくれればいいのに、本をそのまま電子版にしただけなのでリンクはない。写真は最初に固まってあるが、本当に見たいのはその商品や場面のくだりの部分で見たい。

スティーブ・ジョブズは伝記を書くことを許可したけれども、自分では原稿を読まなかったので、読んでいたら作品としていろいろ注文を付けたのではないかと思う。

さて、Steve Jobs ⅠⅡを読んでいて気がついたことがいくつかあった。一つはアメリカの企業の前に進む進み方が非常にダイナミックだとういことだ。Apple だけの話ではない。企業の吸収や合併、方針の大幅な転換、リストラが当たり前のように行われている。

そして人の移動もダイナミックだ。△△の○○は□□が得意だから連れてこようとかいったシーンがしょっちゅう出てきて、呼ばれた方も一つの会社のCEOをやっていてもそこを抜けてしまったりする。

また、企業のトップ同士のコミュニケーションが頻繁に行われる。スティーブ・ジョブズとビル・ゲイツは犬猿の仲で会ったこともないのかと思ったら、そんなことはなく、水と油ではあるものの業務提携したり、話し合いや交渉もけっこうやっている。

スティーブ・ジョブズがゼロックスのパロアルト研究所(PARC)を訪れた際に、初めてPCがGUIで動くのを見てMacintoshのルックアンドフィールのGUIを思いついたという話は本当のようだが、その後、ビル・ゲイツがWindows を作ったときにスティーブ・ジョブズはビル・ゲイツに「おまえがしているのは盗みだ!信頼しているたというのに、それをいいことにちょろまかすのか!」と言ったそうだ。

それに対してビル・ゲイツは「なんと言うか、スティーブ、この件にはいろいろな見方があると思います。我々の近所にゼロックスというお金持ちが住んでいて、そこのテレビを盗もうと私が忍び込んだらあなたが盗んだあとだった。むしろそういう話なのではないでしょうか」と反撃したらしい。

なにはともあれ、企業と経営者と社員がダイナミックに動き、企業という枠がありながらもその間を人や技術や商品が行き来している。落ち着かない面もあるかもしれないが、思い切ったことができるような気がした。技術者もその枠の中に留まってはいない。技術を請われてあっちに行ったりこっちに来たりする。最初から必要だという気持ちでマーケティングや宣伝にもきっちり予算を付ける。

日本の企業には動かない変わらない良さ、伝統的な技術を継承し続ける強みがあるので、企業のダイナミックな動き方がよいとは言い切れないが、魅力的に見えるのも確かだ。失敗と挑戦を繰り返しても受け入れてくれる土壌がアメリカにはあるように思った。

ただ、だからこそ契約が大事だとういうのも分かった。Steve Jobs ⅠⅡの中で大事な契約がいくつも出てくる。スティーブ・ジョブズが分厚い契約書を数ページに簡素化するよう指示する場面が何回かあったが、それはすなわち企業のトップが契約内容を掌握し、契約によって企業活動を動かしている証でもあると思った。

契約の中には今から考えるとそんなことがあったのかという物もある。Microsoft初のアプリケーションはマック用の Excel と Word だった。Apple にとっても、Excel と Word は重要なアプリだったので、これを引き上げられては困る。そこで、Apple 交渉の過程で GUI を Windows 1.0にライセンスし、その見返りとしてExcel を最長2年間、マック専用とするという契約を交わしている。

日本では、企業間でこんなダイナミックな契約はなされないだろうなと思った。

この本を読んでるとエンジニアはものづくりにかける情熱をなくしたら終わりだとうことがよく分かる。みんなすばらしいものを作って胸を張りたいと思って仕事に打ち込んでいる。リリース前に商品(特にソフトウェア)が完成しておらず、徹夜して何とかしようとする技術者の行動は今も昔も同じだ。その気持ちがなくなったら自分の存在価値がなくなると思った。

下記に示した若き日のスティーブ・ジョブズが行っているMacintoshのプレゼンテーションは、製品のソフトウェアが間に合わずに徹夜して仕上げた後で、プレゼンテーションにインパクトを与えたいと思ったソフトウェアエンジニアたちが最後の力を振り絞って完成させたデモソフトだ。

スティーブ・ジョブズは人間として幸せだったかどうかは分からないが、少なくとも多くの人に感動を当てる商品をもたらした。それを達成した時は関わった人々も含めて技術者として幸せだったと思う。

自分自身の中では Apple の商品の中で初代Macintoshと、iPad が世の中に革命をもたらしたと思っている。そのどちらも自分の手にすることができたことに幸せを感じる。

----------------
この記事の一番後ろに、本を読みながら“見たい”と思った画像、映像をインターネットで探すことができたので貼り付けておく。

2分間で Apple の製品を眺めることができる映像




こっちは、マッキントッシュのプレゼンテーション




有名なCM二つ。

1984

Think Different



2011-09-19

技術書の現在と未来

2006年3月に『組込みソフトエンジニアを極める』を書いてからはや5年が経過した。このブログ自体、この本の読者と双方向で情報交換をするために書き始めたことを思い出す。

第一回目の投稿は今でもここに残っている。

この本が出版されるまでは自分も技術書の一読者だった。それ以降は技術書の出版や雑誌の編集についてその裏舞台も知ることになる。

読む側の立場だとあまり実感がないと思うが、今技術系の雑誌や本は売れない。技術系だけでなく本や雑誌全体が売れていない。2005年から2010年までの約5年間、ソフトウェア特に組込みソフトの雑誌や本が次々と出版された。今はそのブームは去っている。

製造業自体が大幅な落ち込みを見せている訳ではないので、出版業界が「組込みソフト」というキーワードに踊らされていたのかもしれない。

さて、2006年3月に日経BP社から出版された『組込みソフトエンジニアを極める』は初版の4000部がほぼ市場からなくなりかけたところで、増版はされないことが決定された。

理由は過去一年の売り上げのペースから考えると、増版したときのコストが見合わないという判断からだ。

本は出版するときに出版社がかなりのリスクを背負う。本を少しずつ刷るとコストが高くなるので、技術書なら概ね1000部以上は刷らないといけない。本を印刷するまでに、著者への印税の支払いやイラスト作成代、編集者の人件費等もかかり、印刷費用も数十万円はかかる。紙代、インク代も馬鹿にならない。

そして本の場合、日本では再販制度があるため書店はいくら書籍を仕入れても返品が可能で、倉庫代も出版社が持つことになる。

技術書の場合、1万部も売れればヒットの部類に入り、10万部売れれば大ヒットだ。しかし、それだけ売れても著者はその印税だけではとても食べてはいけない。何しろきちんとした本を作ろうとすると時間と労力がかかるので、まったく割に合わない。

しかも、今の技術者はインターネットから情報を仕入れてしまうので、あまり本や雑誌を買わない。技術系の出版社は非常に苦しい状況に立たされていると思う。

それでいいのかと思うが、これが現実だからしようがない。ちなみに電子出版に未来があるかというと必ずしもそうではないようだ。そこら辺の事情を知りたい方はペーパーバックスの『出版大崩壊 電子書籍の罠』文藝春秋 800円を読んでいただきたい。

読者のみなさんにアドバイスしておきたいのは、これからは絶版になる技術書も増えてくるので、「これはいい本だな」と思ったらためらわずに今かっておいた方がよいということだ。ネット書店だからといって在庫切れが起こらないとは限らない。中古品もネットで流通するようになったが、市場に出回らなくなってくると中古品でも定価の倍以上の値が付くこともある。

ところで、日経BP社から発売された『組込みソフトエンジニアを極める』は絶版になってしまい、Amazonを見ると中古品も品薄状態になりつつある。

もしも、将来この本を読みたいと思う人が現れたときに買えないのは著者としては非常に残念である。そこで、いろいろな方々に協力してもらいこの本を新刊として再出版することになった。

再出版といっても最初に出版した日経BP社にイラストや編集の権利があるため、自分自身のオリジナル原稿と図表をもとにまた編集を一からやり直した。編集は結果的に8ヶ月かかった。

この本や他の技術書に比べても異常とも言えるくらい図が多い。この図をトレースし直すのに時間がかかっている。

編集は、フレデリック・P・ブルックス Jr. の名著『人月の神話』の翻訳者で株式会社エスアイビー・アクセス 社長の富澤 昇氏にお願いした。

タイトルは前とは少し変わって『リアルタイムOSから出発して 組込みソフトエンジニアを極める』とした。理由は、リアルタイムOSのを使った実際の組込み製品のアプリケーションソフトの開発を題材にした本はあまり見たことがないのと、やはり組込みソフトエンジニアはリアルタイムOSから出発して、システムの時間制約をクリアし、大規模システムのアーキテクトもこなせるようになることがキャリアパスの本流ではないかと思ったからである。

前作と『リアルタイムOSから出発して 組込みソフトエンジニアを極める』の違いを示すと次のようになる。

  • 一番大きい変更点。価格を買いやすくするために2800円から1800円に変更した。
  • ページ数は296ページから260ページに減った。(1ページの文字数が増えた)
  • 本の厚みが2/3ほどになった。(紙が薄くなったから。内容は同じ)
  • 人物イラストは省いた。
  • 5年経過して時代に合わなくなった文言等を修正。

人物イラストは若いエンジニアが成長していく姿をドラマ風に見せるために付けていたのだが、台詞だけでも十分にその雰囲気は伝わるし、やはり技術書なので中身で勝負しようと思い省いた。(イラスト入り外伝はまだ生きているので参考にされたし)

また、若いエンジニアに是非読んでもらいたいという気持ちから2800円だった定価を1800円に下げた。

中身は同じなので前作同様よい評価を得られることを祈っている。

若い技術者の方たちにはもっと本を読みなさいといいたい。もしかすると日本人が日本語で書かれた本を読む時代ではないのかもしれない。英語なら読者の数は一気に増えるので、英語の本を英語のままで読めるようになった方が情報収集の効率はよい。

でも、日本人の気質、日本特有の技術や仕事の進め方は英語の本の中には書かれていることはまれだ。そんな本を書くことを目指している。

2011-08-14

ソフトウェアアーキテクチャの改善はなぜ進まないのか

ソフトウェアエンジニアでない人にはピンとこないかもしれないが、ソフトウェアのアーキテクチャ(構造)を改善するということには意味がある。

家が完成してしまうと外面からはどのようなアーキテクチャ(構造)でその家ができているのかがよく分からなくなってしまうのは実際の建築物もソフトウェアシステムも同じだ。でも、そのアーキテクチャの善し悪しが災害に対する強度だったり、住みやすさに大いに影響する。テレビ朝日の『大改造!!劇的ビフォーアフター』で、古い家屋を骨組みだけにする過程で、基礎がいい加減だったり、支えとなる柱が途中で切られていたりするケースをたまに見かけるが、これらの手抜き工事は外からでは見られないから恐ろしい。

ソフトウェアの場合、アーキテクチャが悪いと、非常にわかりにくいバグを生んだり、ソフトウェアの再利用によく多くの時間と工数がかかる。こちらも、それらの問題がソフトウェアのことに詳しくない人には見えない、理解できないからやっかいだ。

ソフトウェアアーキテクチャの改善(=ソフトウェアプロダクトラインの導入)は組織のトップからおろしていくのであれば、品質面のメリットよりも、コストメリットや開発期間の短縮のメリットが強調されると思う。ただし、改善の実現には一時的にソフトウェア資産の再構築が必要になるため、成果が現れるまでには2~3回製品を開発するサイクル(1年以上)を回す必要がある。その投資期間をじっと我慢することができれば、その後から劇的な効果が現れる。

日本の組織ではそのようないったん我慢をして後々の利益を取るという判断ができる企業は少ないので、なかなかソフトウェアアーキテクチャの改善に踏み出せない。

そこで考えるのは、プロジェクトやエンジニアにアーキテクチャ改善の重要性を諭して取り組んでもらうというアプローチだ。しかし、それもなかなかうまくいかないケースがあることに気がついてきた。

既存のソフトウェアシステムのアーキテクチャを可視化して問題点を共有しても、思ったより改善に対する気持ちがイマイチ盛り上がらない場合がある。それはそもそも既存のソフトウェアシステムのアーキテクチャ設計を外部の協力会社の技術者に任せているケースだ。建築業界においてハウスメーカーが自社の商品の構造設計を外注することはないと思うが、ソフトウェアの世界ではソフトウェアシステムのアーキテクチャ設計を外部の技術者にゆだねることはよくある。悪い言葉で言えば丸投げだ。

アーキテクトがプロジェクトのメインメンバーの外にいる場合、アーキテクチャの改善は非常にやりにくい。なぜなら、アーキテクチャに問題があることに対してアーキテクトはすぐに理解できるが、プロジェクトのステークホルダには十分に理解できないからだ。協力会社のアーキテクトはアーキテクチャの改善をプロジェクトに進言するということは、これまで納品してきた自分たちのソフトウェアに問題があったことを告げることににもなる。アーキテクチャの改善とはこれまでのソフトウェアシステムの中にある問題点を自ら認め、未来のために一時的な苦労を強いることである。そのためには協力会社のエンジニアを含めたプロジェクト全体で現在のアーキテクチャの問題点について認め合い、目標となるゴールについての認識を一つにしなければいけない。

エンジニア個人としては、アーキテクチャが改善したことでどれくらい自分自身が成長し、仕事が楽になるのか感覚的に分かっていないと改善への第一歩を踏み出せない。

鶏と卵のような関係で、アーキテクチャの改善に必要なトレーニングを与えるのが先か、それともアーキテクチャの改善によるメリットを実感させることが先かは微妙なところだ。前者はメリットが実感できないと学習効果が上がらないし、後者はスキルがないとメリットを実感できないからだ。

日本でソフトウェアアーキテクチャ改善の話題がいまいち盛り上がらないのは、ソフトウェアアーキテクトの存在が組織内で認識されておらず、その職務が不明確で地位が確立していないからではないかと思う。建築業界では建築士という資格によってその地位が認められているが、ソフトウェアの世界では、そのような資格は存在しない。(資格があればいいってもんじゃないが)

ソフトウェアアーキテクチャを改善し、ソフトウェアコンポーネント間の関係がすっきりすると、開発は非常に楽になる。簡単に言えばソフトウェア資産に一切手を入れずにコンポーネントを再利用できるようになるから、資産の再利用のコストは限りなくゼロに近くなる。

かつて作ったソフトウェアの“流用”すると言っておきながら、新規にソフトウェアを開発するのと同じくらいの費用や期間がかかっていることに疑問を持つプロジェクトやクライアントの会社が少ないことに驚きを隠しきれない。ソフトウェアの再利用に成功したことが一度もないから、ソフトウェアはよく分からないが金がかかるものだと思っているのだ。

また、ソフトハウスの経営者としても再利用資産が増えることで工数が削減されることは利益の減少につながるから積極的にアーキテクチャ改善には動かない。しかし、それは発想を変えるべきで、ソフトウェアのアーキテクチャを改善し、再利用性が高まったら、その資産を利用して新たな派生製品を作り、そのアプリケーション開発のための仕事を受注すればよいのだ。前者の考え方は長期的な視点に立てば、コストダウンで開発費を縮小され、少人数で仕事量が増えるから悪循環に陥り、後者は資産の再利用により開発効率が高まるので長い目で見れば好循環につながる。

新しい技術を学びながら、自分のスキルと市場価値が向上し、開発効率が上がって、よりクリエイティブな仕事ができるようになるのに、なぜアーキテクチャの改善に積極的に踏む出そうとするソフトウェアエンジニアが少ないのか自分には理解できない。

その答えの一つは、自分や自分のプロジェクトが作成したソフトウェア再利用資産が他のプロジェクトや他の商品に利用されても、再利用できたことのメリットが表面にでてこないという現実がある。

どんなに自分自身が成長しても、その成果を自分の中だけにとどめておいたのでは自己満足に終わってしまう。組織に認められてこそ、組織貢献を果たすことができ、顧客への貢献につながる。

そんなこんなの問題が山積していることから、ソフトウェアアーキテクチャの改善は難しいのだ。

最後にソフトウェアエンジニアに言いたいのは、これからも続く長いソフトウェアエンジニアのキャリアパスを考えたときに、10年後、20年後に振り返ったら日々忙しくしていた自分しか見えないというのはあまりにも悲しくないかということだ。自分が組織に残したソフトウェア資産やアーキテクチャは「これだ」と言えるようになりたくないのか。一回やってみるとそのありがたみが分かるはずなのに、日々の忙しさを言い訳にして最初の一歩を踏み出せない技術者が多すぎる。

2011-06-25

「部下に任せないとダメだ」と考えさせられる一冊(その2)



小倉 広著『任せる技術』を読み進んだので前回に続き感想と思ったことを書こうと思う。

小倉氏は CHAPTER 3 任せる、と伝える の中で、「人生のビジョンがない部下には任せられない」と書いている。仕事を任せる時には部下に自分からジャンプさせ選ばせる。しかし、そうするためには絶対に必要な条件があり、それが、自分なりの「判断基準」を持っていることだという。そして、その「判断基準」が長期的な「人生のビジョン」であることが必要というのだ。

【CHAPTER 3 「任せる、と伝える」 より引用】
部下の立場に立って考えてみよう。上司から仕事を任せたい、と申し出があった。どうやら今よりも仕事が増えそうだ。しかし、すぐに給料が上がるわけではない。目先の損得だけを考えれば、これは間違いなく「損」だ。

「給料が上がるわけじゃないないし、だったら面倒だから断ろう」

このように考えるのがごく普通の判断というものだろう。しかし、もし、彼に将来の夢があったならどうだろう。例えば独立して社長になりたい。もしくは他社からスカウトが来るようなプロフェッショナルになりたい。そんな夢があったら、きっと判断は変わるに違いない。

「将来独立するためには、この経験はプラスになる。自己成長のために是非やらせてもらいたい。」そのように答えが変わってくるだろう。
【引用終わり】

小倉氏は組織人事のコンサルタントだったからこう書いているが、この話しはソフトウェアエンジニアにも全く同じように当てはまる。

ソフトウェアの開発効率や品質を高めるためには、高度なスキルを学んだり、自動化のシステムを構築したり、アーキテクチャを見直したり、プロセスを組み直したりするため一時的に仕事量が増える。日々忙しいのなら、さらに忙しくなるということだ。

ソフトウェアプロダクトライン(ソフトウェアの再利用戦略)もそうだが、最初に再利用資産を構築する際には通常の作業よりも1.5倍くらいは軽く工数も時間もかかる。それを乗り越えて「今やろう」と決断できなければ、その先開発が楽になることはない。エンドレスの悪循環が待ち構えている。

エンジニア個人やプロジェクトにスキルアップや新しい取り組みを進言するとき、必ず聞かれるのは「それをやるとどれくらい工数や時間がかかるのか」だ。目先の損得だけで判断されると大抵は辞退される。だからこそ、エンジニアとしての将来の夢を語りたいのだが、なかなか自分自身がエンジニアとしてどう成長したいのかを頭に描いている人はいない。

新人は夢があっていいのだけれど、職場に配置されて1年もたつと、夢を語らなくなる。上記の引用のように、夢のないエンジニアに仕事を任せても成長のスピードが遅い。

本サイトでよく読まれ低r記事「問題解決能力(Problem Solving Skill):自ら考え行動する力」の「どうせどうせ子ちゃん」や「評論家君」が多く、「問題解決キッズ」が少ないのだ。

小倉氏は、『任せる技術』のなかで「世の中には、明確な人生のビジョンを持ち仕事に取り組んでいる人は1割に満たないと思う。これまで3万人の管理職に研修や講演をしてきた僕の実感値では、1~2%がいいところだろう。」と言っている。よって、上司は部下が自分の人生のビジョンを描くお手伝いをする必要があり、そのためには定期的な面談が欠かせないと書いている。

【CHAPTER 3 「任せる、と伝える」 より引用】

■ビジョンなし、なら今に集中
実際に部下と人生のビジョンについて面談するとわかることがある。それは何度質問を繰り返してもビジョンが見つからない部下がたくさんいるということだ。これまで彼らは「ベキ論」に縛られて生きてきた。だから突然、「どうしたい?」「どうなりたい?」と聞かれるとうろたえてしまうのだ。「やりたいことが見つからない」。そういう若者が増えているのだという。では、僕たちは彼らに対してどう接すればよいのだろうか?

これまで言ってきたことと矛盾するようだが、僕はその場合は、ムリしてビジョンを描かなくてもいいと思う。今、目の前にある仕事に120%集中するよう導いてあげればいいのではないか。

キャリア・ドリフト理論という考え方がある。キャリアはデザインするものではない。偶然に出会うものだ、という考え方だ。ただし、そのためには条件がある。今、目の前にある仕事に120%集中することだ。「自分には向いていないかもしれない・・・」などと言わずに、その仕事に集中するのだ。そのときに初めて偶然が、幸運が訪れる。
【引用終わり】

「明確な人生のビジョンを持ち仕事に取り組んでいる人は1割に満たない」というのは悲しいことだ。そうなっているのは、人生のビジョンを描く訓練をしてこなかったからだと自分は信じたい。「ベキ論」に縛られることなく、やりたいことをやるにはどうしたらいいのかを考え、実行し、ダメだったらなぜそうなったのかを反省するそれを繰り返していけば、人生のビジョンを描けるようになると思う。

本当ならば、それを学生の時代に訓練しておいて欲しいのだが、その訓練をする機会もなく社会で出てしまった人達は大勢いる。だから、上司は部下に仕事を任せなければいけない。

【CHAPTER 3 「任せる、と伝える」 より引用】

■任せる、とういことは、自分の違うやり方に異を唱えないこと
任せた以上は、自分と違うやり方を許容しなくれはならない。
「オレだったらこうするのに・・・」
「そのやり方をすると後で必ず問題が起こるぞ。あ~。やっちゃった・・・」
そう思ったとしても、部下のやり方に異を唱えてはいけないのだ。失敗することも含めて部下に経験させなくてはならない。それが本当の意味での任せる、ということなのだ。
【引用終わり】

もう一つ、重要な教訓。

【CHAPTER 4 「ギリギリまで力を発揮させる」 より引用】

■相手に矢印を向ける人は成長しない
先にお伝えした通り、上司が持っていた仕事を部下に任せると、部下には大きなストレス負荷がかかる。能力以上の仕事にチャレンジする部下は思い通りにならない仕事にイライラを感じるのだ。これを心理学の言葉では認知的不協和と呼ぶ。

これは前にも説明したが、そのイライラを解消する時に常に選択肢は二つある。一つは自分に矢印を向ける方法。つまり、問題の原因を自分にあると考え、自分を変えることで問題を解決しようとするアプローチだ。これを選ぶ部下は成長していく。仕事を任せたかいがある、というものだ。

しかし、もう一つの選択肢を選んだ場合はそうはいかない。それが他人に矢印を向けるという方法だ。
「目標達成できないのは不景気のせい」
「期限内に提出物を出せないのは、仕事の量が多すぎるから」
「チームの目標達成率が低いのは、人員を補充してくれない人事部のせい」

そうやって問題をすべて他人のせいにすることで自己正当化する。自分は悪くない、悪いのは他人だ、と言って必死に自分を守るのだ。

当たり前にことではあるが、このタイプの人は成長しない。自分は変わる必要がない。すべては他人が悪いと思っているからだ。
【引用終わり】

相手に矢印を向けずに、「自分に矢印を向ける」ように指導する、これが難しい。どうすればいいかを考えるのも自分の仕事だ。

2011-06-12

「部下に任せないとダメだ」と考えさせられる一冊


いま『任せる技術』という本を読んでいる。プレイングマネージャを自負している方には是非読んでいただきたい一冊だ。まだ最初の方だけしか読んでいないが、とても心に響いている。

【CHAPTER1 ムリを承知で任せる より 引用】
そもそも部下の仕事とは「今日」の食いぶちを稼ぐことにある。一方で上司の仕事とは「今日とは違う明日」をつくることである。例えば、業務フローを標準化し改善する。営業戦略を立案し実行する。未来のビジョンを策定し部下を勇気づける。部下育成をする。これまでとは違うやり方を示し、より良い未来へ踏み出すのだ。

部下の仕事を奪っている上司は、これを怠っているということになる。目先の忙しさにかまけて本質的な上司の仕事を一切していないことになるのだ。先に掲げた「高い給与で部下の仕事を奪うこと」が目に見える損失だとすれば、「今日とは違う明日」づくりを放棄するということは目には見えない大いなる損失と言えるだろう。
【引用終わり】

耳が痛い。著者の小倉広氏は組織人事コンサルティング畑の方で、エンジニアではないが、技術者の上司と部下も同じことが言えるだろう。

小倉氏は上司が部下に仕事を任せない理由として次のようなことを挙げている。

  • 部下に任せて失敗することを恐れている。上司の責任になってしまうのが恐い。
  • 部下に任せることで仕事の質が下がり、部署全体の業績が下がることを恐れている。
  • 部下に任せるためには手取り足取り教えなければならない。自分がやった方が早い。
  • 部下に教えられるほどにノウハウが整理体系化されていない。
  • 口べたであり、うまく部下に教えることができない。
  • 部下が自分の仕事が増えることを嫌がり、場合によっては任せられることを拒絶する。
  • 仕事を部下に任せることにより職場にストレスがたまり雰囲気が悪くなる。
  • 部下に仕事を任せることで、上司が楽をしているのではないかと疑われるのが恐い。
  • 上司自身が忙しくなることに快感を覚え、仕事を部下に渡したくない。
  • 部下に任せることによるわずかな品質低下が許せないほどに上司が完璧主義者である。
  • 部下に仕事を任せたいと思っているが、何をどこまで任せていいのかわからない。
まさに図星だ。自分の場合「部下に任せることによる品質低下が最終的に顧客満足を低下させることにつながらないか?」という恐怖が強い。しかし、そのことは自分が戦列を離れたときの顧客満足度の低下については考慮していないということになる。

「自分がいなくなったら?」「そんなことは知ったこっちゃない」ということになり、きわめて自己中心的であり、組織力を弱体化させ、結果的には顧客満足も下げてしまうことになりかねない。

【CHAPTER2 ムリをしなければ脳の筋肉はつかない より引用】
「小倉さん、今の仕事にやりがいが感じられないのです。転職すべきかどうか迷っています。アドバイスを下さい」と言うのだ。なぜ、やりがいがないの? と聞くと返ってくる答えは2種類に大別される。

1つ目は「今の仕事が自分には向いていない」というものだ。例えば営業をやっている人は自分には営業は向いていない、と言う。本当にそうであるかは大いに疑問が残るのだが。

2つ目の理由は、「上司や会社に問題がある」というものだ。職場に問題があり、上司に直訴しても変わりそうにない。だからあきらめて転職する、と言うのだ。

僕はその2つを聞くたびにこう思う。

「その状態でどこへ転職しても、絶対にやりがいは見つかりませんよ」と。

「やりがい」とは、楽ちんな仕事を通じては手に入らない。「やりがい」は壁を乗り越えた向こう側にあるものだからだ。決して壁の手前にそれはない。様々な障害やつらさを乗り越えたときに初めて僕たちは「やりがい」に出会い、それを手にすることができる。しかし、先に相談してくる人達のほとんどは壁を乗り越える前に逃げ出そうとしている人ばかりだからだ。
【引用終わり】

部下のモチベーションは維持しなければいけないし、ムリもさせないと基礎体力がつかない。自分自身は若いことムリをした経験がある。今の若い人達には「ムリをさせろ」ということ自体がムリという人がいるが、小倉氏が書いていることはその通りだと思う。障害やつらさを取り越えないで「やりがい」に出会えることなどない。

【CHAPTER3 部下が失敗する「権利」を奪うな より引用】
失敗が喉の渇きを引き起こす

なぜ人は「任される」と育つのだろうか。

もちろん答えは一つではない。任されるから主体性が育つ。任されるからモチベーションが高まる。任されるから期待が伝わりそれに応えようとする。様々な要因があげられるだろう。

しかし、それらの中であえて一つを選ぶとするならば、僕は真っ先に「失敗の経験」をあげるだろう。つまり「任される」ことで初めて「失敗」を経験し、「失敗」により人は多くを学ぶのだ。「失敗」すれば痛みが伴う。そのとき初めて人は「失敗したくない」と心から思う。「うまくできるようになりたい」と切望する。つまりは、うまくやるための方法という「水」を求めて「喉が渇く」のだ。

そして様々な「試行錯誤」を行う。自分の頭で考えて「工夫」する。やがてうまくいくやり方を見つける。そこで見つけた方法をゴクリと飲み干すのだ。そうして全身にそれをしみ渡らせる。それを繰り返すことにより体で覚えていくのだ。
【引用終わり】

この話を、ソフトウェア開発の世界に投影してみると、何しろ今は「失敗させる機会」が少ない。「渇きを引き起こす」だけの「失敗の経験」を与える機会がない。また、ソフトウェアは失敗作でも一見動いてしまうこともあり、それが失敗であると気づかずに先に進んでしまうこともある。

さらに、大規模プロジェクトでは自分の作ったソフトウェアに失敗(=バグ)があることを自分ではなく、後工程のメンバーが見つける責務を担っていることもある。作りっぱなしで失敗を見つけるのも他人という環境では渇きが起こらない。

自分の場合は「渇き」は「今よりも美しいソフトウェアを作りたい」「より楽に、より高品質で、クリエイティブな仕事がしたい」という気持ちから生まれていたと思う。

「失敗の経験」により「渇きを引き起こす」ためには、この本のタイトルどおり任せる技術が必要そうだ。「渇きを引き起こす」どころかやる気がなくなってもまずい。

失敗しないように手取り足取り教えてしまうと任せたことにはならず、「渇き」にはつながらない。

コンピュータではなく相手が人間だとこれほどまでに物事をうまく進めるのが難しい。もっと、この本を読み進める必要がありそうだ。

2011-05-14

「それは仕様です」とは絶対に言ってはいけない

浜岡原発の停止に際して、中部電では「(対策が済む)2年後に本当に再開できるのか確証がほしい」(中部電幹部)と、政府に何らかの保証を求めるべきだとの意見が出ているという。

これを聞いて「ああ、やっぱりそういう考え方をする人はいるのだな」と思った。こういう発言をする人はリスクマネジメントの本質が分かっていない。

リスクに対する保証というと生命保険や損害保険などの金銭的保障がすぐに思う浮かぶが、多くの人の命が関わっている場合、話しはそう簡単ではない。

人の命に関わるようなハザードの発現を、防げるのに防ぐための対策を取っておらず、金銭的な保障で備えるという選択肢はない。

よって想定したリスクに対して、リスクを分析しリスクコントロール手段を講じる必要がある。そのときにリスクコントロール手段によって100%リスクを回避できれば、それに超したことはないが、ほとんどの場合は100%のリスク回避などできないため、リスクコントロール手段によってリスクが受容できるレベルまで軽減されているかどうかを確かめる必要がある。

そこに保証という概念はない。リスクコントロール手段を講じる当事者ではない者は誰も保証などはできない。世の中にはそれが分かっていない人が大勢いる。

例えば、契約書や取扱説明書に禁忌・禁止事項を記載して、それをよく読まずに実行してしまったらそれはユーザーの責任だという人がいる。それは正しいが、現代のリスクマネジメントの考え方からすると正しくない一面もある。

社会通念上ユーザーがやってしまっても不思議ではないことに対して、契約書や取扱説明書に禁忌・禁止事項が記載してあったとしても、事故が起これば機器の製造業者やサービス提供者は社会的責任を求められる。

刑事裁判では勝訴しても、民事裁判では負ける、もしくは裁判には勝っても社会的な制裁を受けて、会社は潰れる。そんな事件は世の中でしょっちゅう起こっている。

さて、リスクコントロール手段によって事故の発生を誰も保証してくれないのならば、どうやってGO か STOP かを判断するのか。

それは一にも二にもリスクコントロール手段にの有効性の根拠による。GO か STOP かを判断した結果ではない、根拠が大事なのだ。

よく、クリティカルデバイスのリスクマネジメントに関する判断で最終的な結果を求めてくるエンジニアがいる、というか、ほとんどがそうなのだが、そういうときは最終判断の案と共に判断の根拠を必ず伝えるようにしている。自分がエンジニアに聞きたいのは、結果を受け入れるかどうかよりも、その根拠に同意するのかしないのかだ。

何も考えずに、結果だけを受けているのだけは絶対やめてくれと常に言っている。大事なのはリスクが軽減できると考える根拠だ。もちろん、客観的な証拠、統計的なデータに裏付けられた根拠に基づいた判断がベストだが、ソフトウェアの場合は障害の特徴がランダムではなくシステマティックでることが多いため、客観的な根拠だけではなく、エンジニアの自信の大きさで判断をすることも少なくない。

冒頭の中部電の「(対策が済む)2年後に本当に再開できるのか確証がほしい」(中部電幹部)と、政府に何らかの保証を求めるべきだという意見は、その観点から考えると保証だけを求めていて、「リスクコントロール手段に対して自分達はまったく自信がありません」と言っているのと同じだ。

本来ならば、「これこれのリスクコントロール手段と根拠となるデータを用意したので、これで判断して欲しい」と言うのは正しい。

リスクが受容できるかどうかは、どんなリスクを想定し、どんなリスクコントロール手段を用意し、どんな根拠によるのかを説明しないといけないのだ。

そして、それは誰も保証はしてくれない。ユーザーが納得するかどうかは機器やサービスを提供する側がどれだけ客観的なデータを使って、自信を持って説明できるかどうかにかかっている。

そのことが分かっていないエンジニアやマネージャが多いと感じる。ある講演で自分は「レビューの席で技術者が“それは仕様です”という台詞を発すると心底むかつく」と言った。

実際そのとおりで、「それは仕様です」という言葉は「私はまったく何も考えていません」と言っているのと同じであり、自分はそういう発言をする者はなぜそうなっているかという根拠を説明できない最低のエンジニアだと思っている。

リスクマネジメントでもまったく同じであり、誰かに保証して欲しいという発言は、自分はリスクコントロールに関して何も考えていませんというと言っているのと同じだから、絶対に言ってはいけないNGワードなのだ。

2011-05-08

是正・予防駆動のプロセス改善アプローチ

ソフトウェアの開発をし商品に実装し、その商品を売って対価を得て、最終的にサラリーをもらう。ソフトウェアの一行一行の向こうには、そのソフトウェアを使うユーザー(お客様)がいる。それが医療機器などのクリティカルソフトウェアであった場合、そのソフトウェアは利用者の命を左右する可能性もある。

クリティカルでなくても、危険なエネルギーを制御したり、大切な情報を扱ったり、重要な設備を管理したりするソフトウェアもある。

ようするに職業としてソフトウェア開発に携わっている技術者はユーザーに対して何かしらの責務を負っている。これは、ソフトウェアがハードウェアと違うのは、Systematic Failures/Faults(決定論的原因故障/障害)と呼ばれる障害が多いことだ。Systematic Failures/Faults(決定論的原因故障/障害)は出荷前の検査で発見することが難しく、出荷後に故障や障害が発生してから始めて分かることが多い。

故障や障害がランダムに発生せず、ある複雑な特定のシーケンスを実行すると必ず発生する故障や障害、それがSystematic Failures/Faults(決定論的原因故障/障害)だ。

Systematic Failures/Faults(決定論的原因故障/障害)は開発のプロセス(工程)、ライフサイクルの中で作り込みを防止し、検証や妥当性確認によって発見・除去する。

そして日本人は開発のプロセス(工程)、ライフサイクルの中で作り込みを防止し、検証や妥当性確認によって発見・除去のが苦手だ。

どちからというと、問題が発生した時点で修正し、個人個人が是正・予防する方が得意だ。だから、プロジェクトメンバーが入れ替わらなければ、是正・予防を繰り返すことで設計の規範が醸成され、そのプロジェクトからアウトプットされるソフトウェアの品質は徐々に上がっていく。

ところが、最近ではソフトウェアの開発をどんどんアウトソースしてしまうので、ソフトウェアの委託元では設計の規範どころか設計技術自体が醸成されないし、アウトソース先は人が入れ替わるため、是正・予防を繰り返す方法ではソフトウェアの品質は上がっていかない。

日本人が苦手な、Systematic Failures/Faults(決定論的原因故障/障害)をプロセス(工程)、ライフサイクルの中で作り込みを防止し、検証や妥当性確認によって発見・除去するしかない。

しかし、昔気質のソフトウェアプロジェクトリーダーやハードウェア出身のプロダクトマネージャなどは感覚だけは昔のままなので、気がついたら修正し、個人個人が是正・予防するマネージメント以外の成功体験がなく、プロセスアプローチによってソフトウェア品質が高まるというイメージがわかない。

その結果、Systematic Failures/Faults(決定論的原因故障/障害)は増加する一方で、昔気質のソフトウェアプロジェクトリーダーやハードウェア出身のプロダクトマネージャはいらだつ。

これが今多くのソフトウェアプロジェクトが抱える悪循環の構図だ。

このままでは、ソフトウェアを使うユーザー(お客様)への責務が果たせない。ではどうすればいいか。

ひとつの解決策として、トップダウンでプロセスアプローチにシフトするのもいいが、日本人の得意な是正・予防で改善を進めるというのはどうだろうか。

問題が起こったら、関係者全員で問題が発生した原因を分析し、どうやったら予防できるのかを考える。これを進めていくと、当然のことながらソフトウェア開発の上流を改善しなければいけないことに気がつく。結局、プロセスアプローチを導入するという結論に至ると思うが、人から押しつけられるのではなく、改善の取り組みの中でプロセスマネージメントの重要性を学ぶ方が日本の技術者には合っていると思う。

問題が起こったときに、エンジニアを責めるのはたやすい。難しいのは問題の原因を分析し、是正、予防し、同じような問題が起こらないようなオペレーションを決断することだ。

結果を批判するだけの評論家はたくさんいるが、未来に起こるかもしれないリスクを皆に知らせ、プロジェクトを止めたり、方向を変えたりするには技術的な裏付けもいるし、何よりも勇気がいる。

ユーザーの顔を思い浮かべて、ユーザーリスクを防止するための決断ができる者こそ、プロジェクトのリーダーとなるべきだと思う。