メールマガジン

MAIL MAGAZINE

2019年01月号 オートモーティブ・ソフトウェア・フロンティア2019での講演決定(土屋)

2019年2⽉12,13⽇に開催される第4回オートモーティブ・ソフトウェア・フロンティア2019で⾮機能要件に着⽬したシステムズエンジニアリングについて講演を⾏います。是⾮会場まで⾜をお運び下さい。

【⾮機能要件に着⽬したシステムズエンジニアリング】
INCOSE Systems Engineering Handbook v.4ではシステムズエンジニアリングの定義を「システムの実現を成功させることができる複数の専⾨分野にまたがるアプローチおよび⼿段」と記述しています。何をどこまで達成したらシステムの実現が成功したと⾔えるでしょうか?

システムズエンジニアリングを導⼊するモチベーションとして、製品に求められるQCD⽬標を⾼いレベルで達成することがあげられます。導⼊効果を確認するためには、⽬標達成の尺度と評価基準を定義し、プロジェクト活動において尺度を計測・評価していくことが必要です。システムズエンジニアリングで⽤いられる、Technical Measurementプロセスを凡例として紹介しつつ、達成の尺度、評価基準を定義し、測定、評価を⾏う⼀連のアプローチと、事例を講演いたします。

これからシステムズエンジニアリングに取り組まれる⽅が陥りやすい問題点として、チーム内で成果物作成アプローチやシステムをモデル表現する際に着⽬すべき視点を定義せずに要件定義やアーキテクチャモデル作成を進めてしまうと、ドメインエンジニアリング(ハード・メカ・ソフト)に本当に必要な情報が⽋落してしまい、結果的に実開発には使えない成果物を作ってしまうことがあげられます。特に性能要件など定量的な⽬標値を含む⾮機能要件が定義されていない現場をよく⾒かけます。本メールマガジンでは私⾃⾝のシステムズエンジニアリング導⼊時に関する実体験を例にこのポイントについて触れたいと思います。

私が過去に経験したプロジェクトのお話です。そのプロジェクトではシステムチームを⽴ち上げ、既存システムをベースとした次ジェネレーションのシステム開発に初めてシステムズエンジニアリングの導⼊を試みました。このときプロジェクトは製品コンセプト、ターゲット顧客や性能⽬標などが定まっておらず、コスト⽬標だけが明確に決まっている状態からのスタートでした。

このプロジェクトでは利⽤できる既存の成果物が全くなかった状態でしたので、まず要件管理ツール(Rational DOORS)を⽤いた階層的な要件定義と管理、SysMLによるシステムアーキテクチャ記述(既存システムのリバースエンジニアリングなので設計ではなく、記述とします)に時間を費やし、システム要件定義書+ドメインへの要求仕様書と、システムアーキテクチャ定義書を作成しました。試⾏錯誤しましたが、初めて作成した成果物にしてはよい出来栄えだったと思います。

しかしながら、先のシステム設計成果物をドメインチームと共同レビューした際にこんなことを⾔われてしまいました。「ここに記述されている、実装しなければいけない機能はもう分かっているから、どんな性能にすればよいか性能要求を提⽰してほしい。それがないと設計できない」
SysMLで機能的な振る舞いやシステム構造をモデル記述をすることにとらわれて、ドメイン設計に必要なシステム性能や特性に関する定量的な要件が定義されていなかったのです。

このような課題への対応としては、アーキテクチャ設計する際に⽤いる技術として、ビューポイントが活⽤できます。どの視点でシステムをモデリングするかといったルールなくアーキテクチャモデルを記述していくと、必要な情報の⽋落や、情報の重複によるモデル肥⼤化といった問題が発⽣するため、アーキテクティングの視点をルール化するためにビューポイントを⽤います。ビューポイントの⼀例として、要求、振る舞い、構造、パラメトリックの4つの視点が紹介されています。パラメトリックが定量的な⽬標値、すなわち定量的な⾮機能要件に着⽬するビューです。このビューポイントを理解してアーキテクチャ記述を進めていたら、私たちの活動ももっとよいものになったと思います。

⼀⽅では、このプロジェクトでシステムズエンジニアリングとして良かった点もあります。コストという明確なプロジェクト⽬標達成に向けて、プロジェクト開始からプロジェクトリーダー、製造、購買、開発のメンバーがクロスファンクショナルチームとして、製品設計・⼯程設計エンジニアリングやMake or Buy判断を⾏ない、マネジメントチームとのレビューを通して上層の判断をタイムリーに得ることができたことです。

このように、システムの背景にあるビジネス⽬標やミッション、ユーザーニーズに対しての達成を評価する尺度を、測定可能な指標に置き換え、システム⾮機能要件として設計に織り込んでいく、またはシステムアーキテクチャ設計の評価項⽬として利⽤していくことをエンジニアリング活動に取り⼊れていくと、プロジェクトやプロダクトの成功が⾒える形で評価できる=システムズエンジニアリング導⼊効果の可視化につながると考えています。

このテーマに関する資料はホワイトペーパーとして弊社ホームページにも掲載する予定です。

2019/1/14 ⼟屋 友幸