ソフトウェア開発をめぐる品質やコスト、納期にかかわる要求がますます高まっている状況の中、そうした要求に応えるための効果的なアプローチとして脚光を浴びているのがUML/SysMLモデリングをベースとした設計・開発の実践である。

去る2018年3月2日、東京国際フォーラムにおいて、UML/SysMLモデリングツール「Enterprise Architect」の提供元として知られるスパークスシステムズ ジャパン主催による「Enterprise Architect 事例紹介セミナー」が実施された。事前予約で満席となり、キャンセル待ちも出る中、会場に集まった100名を超える参加者の期待のほどが伺える。

ここでは、2017年に続き第2回目の開催となる同イベントで実施された各セッションの模様をレポートしたい。

モデルによる表現に拘泥しないこともMBSEの実践においては時として重要

この日最初のセッションには、SUBARUの古賀祐一郎氏が登壇。同社が4年ほど前から進めてきた、自動車のボディ系と呼ばれる電子制御領域におけるMBSE（Model Based System Engineering）の実践についての紹介を行った。

今日の自動車産業において、さらなる安全性、電動化の追求が進む中で、自動車に搭載される自動制御システムはますます複雑化する傾向にある。「⁠そうした電子制御をめぐる要求がますます高度化、複雑化するのに伴い、その設計・開発においても、システムズエンジニアリング的なアプローチにより、複数のECUの連携を見据えた設計の検討が求められる一方、利便性といった指標化しにくい価値を比較的自由度の高い構造により実現していくには、ユーザーの要求を広範な視野で分析し、それに合致した機能を提供していくことが不可欠です。それが、我々がMBSEを実践していこうと考えた動機です」と古賀氏は説明する。

とはいえ、いざMBSEを実践していくとはいっても、実際にどうやって進めていいのかわからない状況だったという。そこで同社では、モデリングツールの活用が効果的なガイダンスになり得るものと考え、検討の結果、Enterprise Architectを選定したという。「⁠Enterprise Architectの採用については、社内の他部署で導入実績があり、マネジメント層を説得しやすかったことに加え、コストも含めて新たな取り組みを進めていくうえでのハードルが非常に低かったことが、その理由としてあげられます」と古賀氏は言う。

その後、SUBARUではトライアルとして、コンサルティング会社の支援を受けるかたちでMBSEの実践に着手。自動車のトランクリッドの開閉にかかわる制御をテーマとする仮想プロジェクトを立ち上げ、SysMLのダイアグラムの利用をベースに取り組みを進めた。その大まかな流れとしては、まずステークホルダ要求分析を行ってユースケース図、要求図を作成。洗い出された要求を充足するための機能をステートマシン図で記述し、アクティビティ図でデータのやり取りを含めた処理内容を明らかした。さらに、アクティビティ図で表現した処理を、ブロック定義図に置き換えて処理の一覧を作成し、処理を内部ブロック図で記述して、論理的な構造化を実施。同様に物理的な部品の構造についても、ブロック図と内部ブロック図で表現して構造化を行い、どの論理要素を物理要素に割り当てるかといった関連づけを実施して、評価を行った。

こうしたトライアルを進める中で、SUBARUではMBSEを実践するうえでの工夫にかかわる、いくつかの気づきを得たという。「⁠たとえば、すべてをSysMLのダイアグラムを用いてモデルで表現することにこだわらないということ。一連のプロセスの中で、一旦、Enterprise Architectの外に出て、ExcelやWordなどで自分たちがわかりやすいかたちで記述するといったことも行いながら、またEnterprise Architectの世界に戻っていくというアプローチなども効果的であると感じました」と古賀氏はそうした工夫の1つを紹介する。

特に要求分析のフェーズについては、ExcelやWordなどのドキュメントとして文章での記述を行ったのち、それをEnterprise Architectのモデルに落とし込んで、分析を行うという方法が主体になっているという。また振る舞いの記述には、シーケンス図をExcelで作成した同社独自のタイミングチャートなども、随時併用しているという。

「MBSEの実践は、単にツールを導入すれば何とかなるというわけではなく、導入後、当面は様々な工夫を凝らしながらの実践を継続し、自分たちにとって最適なアプローチの確立につなげていくことが肝要であると考えます」と古賀氏は語った。

技術力の維持・育成を目的として標準開発手法の確立に取り組む

続く2つめのセッションの壇上には、三菱スペース・ソフトウエアの藤原啓一氏が上がった。自社が進める標準設計手法に基づく開発を紹介し、その実践の中でEnterprise Architectをいかに活用しているかについて説明した。

三菱スペース・ソフトウエアの事業では、高品質かつ高度な信頼性を備えたソフトウェアの供給が最優先の課題であり、同社では継続的な技術革新に取組みながらそうした要請に応えている。「⁠様々なドメインのシステム開発に取り組む中で当社では、ドメイン横断で活用可能なMBSEに基づく標準的なシステム設計手法を策定。その適用による開発を実践しています」と藤原氏は語る。

「組織品質自体は表面上、非常に良好になってきていましたが、一方、その裏ではスクラッチ開発が少なくなり、派生開発が増大。その結果、プロダクト品質確保に必要な技術力の維持・育成がなおざりになってしまうという問題が浮上してきました」と藤原氏は語る。特に機能安全設計を行うには、アーキテクチャ開発力が必須であり、スクラッチ開発の形式化、手順化を図る、つまり標準開発手法を確立することで、自社の開発力の底上げを図ることが喫緊の課題であると捉えるに至った。

標準開発手法の確立に向けた考え方としては、規格や手法、ツールありきではなく、まずは、真の目的であるところの品質の向上や安全の確保、コスト低減を達成できる開発・管理プロセスを検討。そのプロセスと各種規格や手法、適用ツールとのギャップを洗い出して、それをプロセスに反映させていくかたちで、標準設計手法を要覧、ガイドラインへとまとめ、それに基づいて現場の開発プロセスを統制していくというアプローチをとることにした。

設計手法の基本的な流れとしては、MBSEをベースに開発対象となるドメインで扱う用語にかかわる辞書の構造定義に始まり、要求図によりシステム要求の構造化を行って、ユースケース図やシステムコンテキスト図を用いてシステム要求仕様を作成。その後ドメイン分割を行って各ドメインごとにユースケースによって振る舞いを定義し、ロバストネス分析を実施したのち、ブロック定義図を用いて論理的な機能分割を行う。それを今度は、ハードウェア、ソフトウェアの視点で分割を行ってそれぞれにおいてなすべきことを決定するというかたちでシステム方式設計を進めるということになる。

このとき、モデリングツールとして同社ではEnterprise Architectを採用している。「⁠ただし、設計プロセスをモデリングツールのみでサポートするには無理があると考えます。そこで当社では、Enterprise Architectをベースに据えながら、自社開発したアドインツールやWord、Excel、Visioを適宜、分析において活用するというアプローチをとっています」と藤原氏は紹介する。Enterprise Architectの採用に際しては、APIが公開されていて、その仕様がリリースやバージョンによってブレることがないという点を高く評価したという。

藤原氏の後を受けて登壇した三菱スペース・ソフトウエア 関西事業部 第五技術部第四課長の馬場明子氏からは、Enterprise Architectを用いた設計において、どのような工夫をしているか、すでに述べた自社製の補完ツールにフォーカスするかたちで紹介がなされた。これについて同社では、3つの補完ツールを開発し、設計にかかわるより高度な効率性を追求している。

1つは「CONVExⅡ+」と命名されたツールで、これは開発プロジェクトにおいて不可欠な用語統一を支援するもの。このツール自体、Enterprise Architectのアドインツールではないが、Enterprise Architectのファイルの検証が可能となっている。「⁠目視に比べて、はるかに迅速かつ正確な用語のチェックおよび統一が可能となっています」と馬場氏は紹介する。

2つめは、仕様とモデル間のリンクを編集するためのツールだ。同社では、Excelを使ってUSDMを作成しているが、Excel上で記述したものを、Enterprise Architect上にコピー＆ペーストで持ってくるといった作業に大きな手間が生じていた。そこでこのツールをEnterprise Architectのアドインツールとして開発。Excel内のUSDMをアドインで読み込んで、画面上の操作でEA上のコントロールと容易にリンクできるようにしている。

そして3つめは、「⁠SUBSpACE」と呼ばれる、サブシステムの定義を支援するツール。一般にサブシステムやサブブロックの定義は、設計者の主観に頼ることが多く妥当性、正当性を評価しにくいという問題がある。設計・評価のためには、DSM（Dependency Structure Matrix）を用いる場合には、その作成には時間を要する。そこで同社では、Enterprise Architectのアドインとしてこのツールを開発した。具体的にはロバストネス図のバウンダリやコントロール、エンティティなどの要素の結合性についての評価値が自動出力できるようになっており、評価値を見ながらEnterprise Architectの画面上でサブシステム境界を決定するといったことも可能。設計の効率、品質を向上に大きな貢献を果たしている。

最後に馬場氏は「これらのツールは、当社ホームページで公開しており、どなたでもダウンロードして、無償でご利用いただけるようにしています。ご利用いただいた皆様の声をフィードバックし、継続的にツールを改善していきたいと考えています」と語った。

上流からの品質確保を目指して ―“ドキュメントファースト”を徹底

この日最後となったセッションの壇上に上がったのは、リコー オフィスサービス開発本部 開発戦略センター ソリューション統括室 要求開発推進グループの野口大輔氏である。現在、プロジェクターを中心に、PCやタブレットなど複数の機器やソリューションで構成されるプロジェクションシステムにかかわるビジネス領域の強化にも着手している。

「従来の複合機などの開発でも、オブジェクト指向やUMLにかかわる取り組みもある程度進められてきており、一定の効果を享受していましたが、たとえば開発者の行ったコード修正がドキュメントに対し適正に反映されない、などの問題を抱えていました。加えて、利用していたモデリングツールは、モデルとコードを一致させることを想定したツールではなかったため、設計と実装の間の親和性も高いものと言えませんでした」と野口氏は振り返る。

これに対しリコーでは、同社にとって新規プロジェクトとなるプロジェクションシステムの開発をスタートさせるに当たって、新たなモデリングツールの導入に向けた検討に着手。いくつかのツールの比較検討を行った。「⁠新プロジェクトでは、既存ツールによる開発をめぐる課題を踏まえるかたちで、ソースコード生成やドキュメント生成が行えることを念頭に、価格や効果予測といた評価軸で総合的に検討を重ねた結果、最終的にEnterprise Architectを導入することに決めました」と野口氏は語る。

その後、同社ではプロジェクションシステムの中でも、とりわけ機能追加や変更が多く発生するプロジェクター内のネットワークボードに実装されるアプリ、サービスレイヤのソフトウェアモジュールの開発にEnterprise Architectを適用。その中で、大きく2つの特徴的な施策を実施している。

1つは、ツール選定時の要件にもあげていたドキュメント／ソースコードの自動生成。具体的には、Enterprise Architectの機能を使って、ツールのプロジェクトファイルからドキュメントとソースコードを生成することにした。「⁠開発者はこれら生成後のドキュメントやソースコードを直接変更するのではなく、必ずEnterprise Architectのプロジェクトファイルをベースに開発を行うこととし、それによって“⁠ドキュメントファースト⁠”の徹底を図ったわけです」と野口氏は説明する。それに沿うかたちで同社では、開発プロセス／ガイドの全社標準からのテーラリングを実施するとともに、モデリングのルール策定なども行った。

またそれにあわせて、CI環境の構築も実施。開発者はEnterprise Architectのプロジェクトファイルのみをリポジトリに格納することとし、夜間のデイリー処理ではJenkinsを利用してEnterprise Architectによるドキュメント／ソースコードの生成を実施。その成果物を再びリポジトリに投入するという流れとなっている。万一、開発者がドキュメントやソースコードを直接修正するようなことがあっても、その日の夜にはプロジェクトファイルから生成された正しいドキュメント／ソースコードがリポジトリに格納されることになるわけだ。

そのほか、Enterprise Architectの以前のバージョンで開発した、過去のプロジェクターの機種に対する機能追加などの変更が生じた場合には、現行バージョンで自動生成を行うと生成されるコードに差異が生じてしまうケースがある。そうするとリグレッションテストなどの負荷が高まってしまう。「⁠これについては、過去機種の設計変更を行うための作業用PCを用意して、そこで以前のバージョンのEnterprise Architectを使って開発を行えるような環境も整えています。Enterprise Architectはフローティングライセンス契約で購入しているので、こうしたことを実現するうえでのコスト面のハードルも下げることができました」と野口氏は言う。

こうした一連の施策によるドキュメント／ソースコードの自動生成により、モデルと仕様書とソースコードの一致を実現。ソフトウェアモジュール開発にかかわる上流からの品質確保が可能になるという成果が得られている。

一方、リコーがEnterprise Architectの適用に伴って実施したもう1つの施策は、ツールのユーザーインタフェース（UI）のカスタマイズである。そのねらいは、開発者がEnterprise Architectを使ってモデルを作り込む際の生産性の向上にあった。「⁠EAは汎用性が高いツールなので、UIにたくさんの入力項目が存在しています。ところが実際に当社で開発者が使う項目はその一部なので、円滑に作業を進めるという観点から、Enterprise Architectのカスタマイズ機能を使って、状態遷移図作成用画面の表示／入力項目を必要なものだけに絞り、最適化を行いました」と、野口氏に代わって登壇したリコーの岩崎遼氏は説明する。

さらに、インタフェース仕様書の作成用UIについても、複数画面を切り替えながら入力する手間を省力化するため、必要な項目を単一画面上にまとめるというカスタマイズを行っている。「⁠もっとも、これについては、入力内容と仕様書の対応関係がわかりづらいという声や、プロジェクトがかなり進んでからの対応だったために、既存のUIに慣れていた人の中からは使いづらいといった声もあがりました。このため、自ら使いたいという人や、既存UIに十分に慣れ親しんでいない人などに向けて限定的にリリースするという運用となっています」と岩崎氏は明かす。

これら一連の取り組みを推進しながら開発プロジェクトを推進するリコーでは、Enterprise Architectのオブジェクト指向開発ツールとしての機能性、および汎用性、カスタマイズ性も高く評価している。「⁠ただし、そうしたメリットを享受するうえでは、導入前にUMLやオブジェクト指向など、ツールを使いこなすための十分な教育を開発者に対して行っておくことが重要であることは言うまでもありません」と最後に岩崎氏はアドバイスする。

これらの3つの講演の後には、講演者との質疑応答がパネル形式で行われた。パネル形式にすることで、単なる情報提供ではなく、参加者の持つ課題を講演者と共有するという試みである。参加者からのさまざまな質問に、本音も交えて回答する講演者に共感が多く寄せられ、大いに盛り上がった。寄せられた質問が非常に多く、時間の関係でいくつかの質問が取り上げられなかったのが残念であった。

以上のように、今回の「Enterprise Architect 事例紹介セミナー」では、単にEnterprise Architectの導入がソフトウェア設計・開発にもたらした成果にとどまらず、ツールやMBSEのもたらすメリットを最大化するための各社各様の工夫についての紹介が強く印象に残った。そうした意味では、特にEnterprise Architectの一歩進んだ活用を目指すユーザーにとっては、大いに有意義なイベントとなったはずだ。イベント参加者からの評価も高く、スパークスシステムズ ジャパンでは、今後も定期的な開催を検討しているとのことで、次回にも期待したい。