「DOORSより軽量」，要件管理ツール「Reqtify」のGeensoft社に聞く～時代は機能安全

要件管理ツールの記事です。

「DOORSより軽量」，要件管理ツール「Reqtify」のGeensoft社に聞く

http://techon.nikkeibp.co.jp/article/NEWS/20100608/183300/?ref=ML

◯ライバルに押され始めているDOORSのビジネス

IBM退職直前にやっていた仕事が自動車分野での機能安全規格「ISO 26262」だったので、要求管理のトレーサビリティをとるためのここらへんのツールも勉強していました。Doors使いづらい、面倒くさい、高いとか言われまくっていたので、こういうツールが売れてデファクトという強さが失われていくとますますIBMのビジネスは大変になりますね～ (--;;。

◯機能安全が求められる背景～リコール問題に学ぶ、安全のキーワード

ちなみに機能安全というキーワードはこれから先かなり重要になると思うので簡単に説明しておきます。トヨタのリコール問題があってから、にわか仕込みの評論家が「品質に対する姿勢が甘かった」などと批判していますが、問題はそういうことではないんです。（もし品質面での問題があったとしたら、）複雑化する製品に対して適切な開発プロセス・技術レベルの簡素化（プラットフォーム化、カプセル化）と安全の作り込みの高度化ができていなかったんです。

簡素化というのは同じ目標に対してシンプルな手段で目標を実現することです。例えばコンピューターがいい例ですが、昔はエンジニアがハードウェア、ソフトウェアの全てを理解してドライバからUIまで開発していましたが、現在ではプラットフォーム上にアプリケーションを構築すればいいだけになっています。これは全部を理解することが不可能な規模になった状態からモジュールに切り分け、再び人間が扱うことが可能なレベルに「簡素化」していると言えます。お互いのモジュールの詳細は知っているほうが好ましいですが、ちゃんとインターフェースが定義されていれば、最悪相手を知らなくても作ることが可能です。

高度化というのは簡素化でシンプルにできなかった残りの部分を実現するために安全を作り込むことです。機能安全が対象としているのはこちらの高度化の領域です。

◯機能安全の概要

ざっくり言うと

安全分析・リスクアセスメント→安全要件定義→全体要件定義→実装→検証→妥当性確認

のプロセスを行い、それぞれの要件・実装のトレーサビリティを取ることで「安全をケアした開発を行ったことを証明」することです。エンジニアとしてはこういう面倒くさいプロセスがいろいろ入ると「余計な仕事が増える」と感じる方もいらっしゃると思うのですが、統一された指標・やり方で安全を織り込んだ開発をすることは個人差でブれまくるより遥かに均質で高品質な開発を行えると言えるでしょう。

人に依存した日本型の開発は効果を発揮する場面もあれば弱くなっている場面もあります。やはり人の能力を超えたところはきっちり分業してやるべきで、そのためにしっかりしたプロセスに乗っけて開発を行うことは今後重要になってくるでしょう。

タグ：機能安全 ISO26262