【専門記者が振り返る】要件管理とトレーサビリティ、この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 にした。
5.2.1 Overview of the safety lifecycleISO 26262 セーフティライフサイクル（図2）は、コンセプトフェーズ、製品開発、生産、運用、保守及び廃棄の間の主要なセーフティアクティビティを包含する。
The ISO 26262 safety lifecycle (see Figure 2) encompasses the principal safety activities during the concept phase, product development, production, operation, service and decommissioning.
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 の特集記事はこれで終了になります。また、来年をご期待ください。自動車業界の皆様また、ツールベンダーの方、規格認証機関の方、ご意見、ご質問があれば随時受け付けますので是非お送りください。
