IoT時代におけるシステムズエンジニアリングの重要性：フラウンホーファー研究機構 IESE×SEC所長松本隆明（後編）：IPA/SEC所長対談（3/4 ページ）

情報処理推進機構のソフトウェア高信頼化センター（IPA／SEC）所長を務める松本隆明氏が、ソフトウェア分野のキーパーソンと対談する「SEC journal」の「所長対談」。今回は、ドイツ フラウンホーファー研究機構 実験的ソフトウェア工学研究所（IESE）のイェンス・ハイドリッヒ博士とマーティン・ベッカー博士に、システムズエンジニアリングの有用性やインダストリ4.0への取り組みなどについて話を聞いた。

[MONOist]

要件だけでなく、システムの挙動、振る舞いもモデル化し共有していく

松本　システムズエンジニアリングについて、先程のようにダイナミックに自分を適合していくようなシステムという発想になってくると、開発そのものも、今までのようなウォーターフォール型の開発ではなくて、アジャイル的な開発が主流になってくるように思うのですが、それについてはどう考えていますか。

ハイドリッヒ　イノベーションにかけられる時間が短くなり、いわゆるイノベーション・サイクルが短縮化されてきてしまうと、どんどん変わっていく顧客の需要やニーズに対応していくために、企業には俊敏性が求められると思います。そのために、ドイツの多くの企業は反復性の高いプロセスに移行しようとしています。どんどん変わっていく顧客デマンドに対応していくためです。そのため、アジャイル開発の手法はドイツではかなり多く使われています。とくに情報システムと言われる部分に関しては多用されています。

　少し前に私どもは、企業がどういうアジャイルの手法を活用しているのか、という調査をしました。その結果として出てきたのが、スクラムとかエクストリームのプログラミングを、教科書通りに使うのではなく自分たちのニーズに合わせて、適応させて使っているということでした。

　例えばスクラムでは、セキュリティとか機能安全とか、それからシステム・プロパティに関してのところまで記述されていません。アジャイル開発をしようと言っても、それをそのまま使うのではなく、その側面を取り入れて、プロセスの中でより成熟化させて活用していく、ということだと思います。まず目標を見据え、目標に対して適切なプロセスは何であるのか、そういう考え方をしていくことが必要です。

松本　日本では、なかなかアジャイルの開発が広まりません。私はその大きな理由に、日本の産業構造があると思っています。ITの場合ですが、ユーザ企業とベンダ企業がある時に、開発はほとんどベンダ側が行うのです。アジャイル的に、先程のリクワイヤメント・エンジニアリングで考えるときには、やっぱりユーザ側とベンダ側が一体になってやらないといけないのですが、それがなかなかできません。ドイツの場合その点はどうでしょうか。ユーザ企業の中に開発部隊を持っているケースが多いのでしょうか。

ハイドリッヒ　それは、その企業により異なるという状態です。外部で開発されたソフトウェアを、供給を受けて使う企業も多く、ソフトウェア開発専業の企業もたくさんあります。ただドイツでは、IP（Intellectual property：知的財産権）やUSP（Unique Selling Proposition：独自の売り）が何なのか、ということによって変わってきます。IP、USP、その企業が持つ資材などがソフトウェアである、という場合には、社内的な開発能力を持つ場合が多いと思いますが、そうではない場合にはアウトソースするという場合が多いと思います。

松本　アウトソースする場合もシステムズエンジニアリングでそれをやろうとすると、契約などいろいろな問題が出てくると思いますが、そこをうまく解決する方法は、あるのでしょうか。

ハイドリッヒ　大変難しい問題だと思いますが、どういう開発プロセスを取るのか、ということによっても変わってくるでしょう。アジャイル手法であった場合には、ソフトウェアを供給する側と、そのソフトウェアの開発の注文を出した側との間に、信頼関係が必要になります。というのも、最初から大きな要件を規定した文書を持つのではなく、かなりの反復が行われていきます。その反復の作業の量によって支払いをしていく、ということになるからです。これまでと違う協力体制が必要だ、ということになります。

ベッカー　以前であれば、企業は要件、情報を共有するだけだったのですが、今出てきているのは、とくにモデルベースのシステムズエンジニアリングというやり方をしていく際には、OEMのメーカーが、システムモデルのパーツも共有していく。それをサプライヤー側に渡していく。そして、両方がコラボレーションをやっていく、ということです。文書ベースで要件の受け渡しをする、ということではなくて、それに追加してモデルもサプライヤーのほうに提供していきます。それによってより開発がやりやすくなりますし、両方が何が開発されるのかということに対して、共通の理解を持つ助けにもなります。

　しかも、構造型のモデルを渡すだけではないんです。構造に関してのモデルというと、システムのエレメントやシステムのインターフェースだけがモデルに入っていると思われるのですが、そうではなく、システムの挙動、振る舞い、これもモデル化し、それを渡していく、という形になります。それをつかって、いわゆるバーチャル・エンジニアリングを行うことが可能になります。最初は、セントラル・システムに関してのシミュレーション、そして、いわゆるヘテロジニアスなシミュレーションを実行できるようにしていく、ということですね。OEM側のパーツのシミュレーションと、サプライヤー側のパーツのシミュレーション、これを混在させたヘテロジニアスなシミュレーションを実行していく、ということです。

松本　それは非常に興味深いお話ですね。今後の重要な方法論になってくるような気がします。

ベッカー　とくに自動車産業においては、既にかなり多用されています。