「モデリングを用いて設計すること」との要件で既存システムをリニューアル。設計者が感じたモデリングとそのツールのメリット、そして課題とは［PR］

情報システムを構築するうえで、適切に要件を把握し設計することは欠かせません。適切に要件を把握して設計へ落とし込む、いわゆる設計開発における代表的な手法の1つに「モデリング」があります。

モデリングは一般に、要件や仕様を抽象化しつつ、その内容をUMLやsysMLといった標準化されたモデリング言語を用いて記述していきます。これにより、漏れやあいまいさを極力排除でき、ダイアグラムによって内容が可視化されるなど、設計開発に多くのメリットをもたらしてくれます。

そしてモデリングを行う際にはモデリングツールを用いることが一般的です。

モデリングツールの支援によって、ダイアグラムの作成、ドキュメントの共有とバージョン管理、アクセス権、排他制御などを用いたチームでの設計開発の効率化や、要求からソースコードへ結びつくクラスまでの関係を管理し影響範囲の追跡を行うトレーサビリティの実現、コードへの変換など、モデリングによるメリットをさらに高めてくれます。

モデリングがなかなか普及しない背景とは

しかし一般にシステムインテグレータ（SIer）などの開発現場において、モデリングを用いた設計開発はそれほど普及していません。

大手SIerである伊藤忠テクノソリューションズ株式会社（以下、CTC）の土屋裕志氏はその理由を、「われわれがこれ（モデリング）をやりましょうと言っても、お客様の方で『モデリング言語で設計書を出されてもレビューできない』と言われてしまう」と指摘。発注側がなかなかモデリング言語を理解してくれないことが大きな要因だとしています。

「業界がモデリングにコミットできていないのはそういうところにあると思う」（土屋氏）

そうしたなかで土屋氏は、お客様からの要件として「モデリングを用いて設計すること」とされた設計開発に参加することになります。

それはすでに10年以上稼働してきた、「個人向けチケット予約サイトの次期システム構築」でした。現行システムから次期システムへのリニューアルです。

「現行システムはドキュメントが陳腐化していたため、システムの拡張や改変を行うたびに毎回ソースコードを読んで、テンポラリな設計書を書き起こす、といったことを毎回やっていたそうです。しかしそれでは工数がかかって積極的な拡張ができず、そうした職人芸的なことができるエンジニアも年々減っていく。だからモデリングできちんと設計することで解決だ、というのがお客様の要望でした」（土屋氏）

今後システムの保守作業においてもモデリングをアップデートしていくことで、つねにモデリングを中心にした設計を維持していく予定とのこと。

果たしてその効果はどうだったのか？ 土屋氏が講演を行った「第3回 Enterprise Architect 事例紹介セミナー」の内容から、その一部を紹介しましょう。

クラウド上にリポジトリを置き、最大70人で共有

今回の「個人向けチケット予約サイトの次期システム構築」で、土屋氏が所属するCTCは次期システムへの要求をモデリングし、また一部の業務の論理モデリングなども担当。それ以外のモデリングや実装については別のパートナー企業が担当したそうです。

開発工数はCTCが関係した部分でパートナー企業などを含めて2000人月以上、開発期間は約1年半。

モデリングツールにスパークスシステムズジャパンの「Enterprise Architect」を採用し、クラウド上にリポジトリを置くことで、モデリングの内容を設計開発に関連したパートナー企業3社のエンジニアを含む最大70人で共有。

経緯が追いかけにくい、複数ブランチの管理など課題

実際のモデリング作業では、例えば要求モデルの作成においてCTCとしては細かい粒度でユースケースを作成することでシステムテストのシナリオに活用することを目論んだものの、お客様としては既存システムのリニューアルという位置づけから、そこにそれほどの工数をかける意向はなかったといった目論見違いや、業務知識などを整理してモデル化するドメインの作成においてお客様のシステム担当者からなかなか協力が得られなかった、といった苦労もあったと土屋氏は振り返ります。

論理モデルについても、結果的に実装コード（スケルトンコード）で表すものを全て論理モデルとして登録する必要があるなど、想定以上に複雑なものになってしまったとの話がありました。

モデリングツールの課題としては、改修した際などの経緯が追いかけにくく、「修正案として2案あるような場合どちらかは採用されないので、この段階でモデルを書き換えるわけにはいかないが、経緯を残すために2つ分の変更後のダイアグラムを描きたい、というような場面があった。

経験上、このようなテンポラリな資料は端的に事情がつかみやすく、後で重宝することも多いのだが、このような時はExcelやPowerPointなどでアドホックな絵を描いて済ませ、検討が終われば成果物にもならないので資料として埋もれてしまうことが多い」（土屋氏）と指摘。

また、1つのシステムに対して複数のブランチが走るようなケース「半年後の機能拡張と、1年後の機能拡張といった複数のブランチが同時に走るとき、Enterprise Architectに備わっているバージョン管理機能ではブランチに対応していないため、複数のリポジトリを切って対応せざるを得ないが、リポジトリ間の整合性をとるのに苦労している」（土屋氏）と、ツールにもまだ改善の余地があるとしました。

影響範囲が追跡できるトレーサビリティなど実現

一方で、当然ながらモデリングを採用したことによる大きなメリットもありました。その1つが、トレーサビリティが確保されたことだと土屋氏。

トレーサビリティとは、例えばシステムの一部が変更される場合、その影響がどこまで及ぶのか、複雑な依存関係を見通した追跡が可能だということです。

「例えば、本プロジェクトにおいてはコンポーネント化という形で画面設計を部品化し、再利用性をあげることで同じ処理を何度も書かなくていいようにしている。 ドキュメントベースでこれを行う場合、使いたいコンポーネントの名前が変わっていたり、消えていたりしても気付かないことも多いが、モデルベースならこういった変更はダイアグラムで知ることができる。

また、設計が進むうちに機能一覧など一覧上の名前と、各詳細設計上での名前が一致しなくなることが多いが、モデル上では同じ要素を指している限り、ズレは発生しない」（土屋氏）

WordやExcelなどを用いたドキュメント化では、ファイル名での検索か、あるいはファイルをいちいち開かないと検索できないといった不便な点が残りますが、モデリングツールのEnterprise Architectならばモデル全体を検索機能で簡単に検索できるのは非常に楽になります。これもツール採用によるメリットだと土屋氏は説明します。

そして記述ルールが統一しやすいこともメリットだと土屋氏。

「本プロジェクトでは利用しなかったが、モデリングツールでのバリデーションなどが可能だ。例えば特定のステレオタイプが付いたクラスの名前は『Service』で終わらなければならないといった細かい記述ルールを設ける場合、ドキュメントベースではレビューで気づくしかないが、モデリングであればバリデーションチェックで制約をかけることができるので（少なくともEnterprise Architectなら）楽ができる」（土屋氏）

土屋氏は、こうしたメリットや課題をうまく把握することが、モデリングでの設計開発をうまく進めるポイントだとまとめました。

会場と登壇者が経験や意見を共有する貴重な機会に

この「第3回 Enterprise Architect 事例紹介セミナー」では、上記の内容のほか、JAXA（国立研究開発法人 宇宙航空研究開発機構）による、運用を含めた設計情報の可視化や関係者間の円滑な情報共有による品質向上などを目指したMBSE(Model-Based Systems Engineering)の適用事例の紹介や、建設機械メーカーのコマツが試みた、設計意図を残すことを目的としたMBSEへの取り組みについての紹介も行われました。

またセミナーの最後には会場から登壇者に対するパネル形式の質疑応答も行われ、モデリングツールを導入する際に壁になる要素をどう解決して導入を推進するか、設計開発におけるトレーサビリティをどう扱っているかなどの質問に対して、登壇者の経験談や意見などが語られる貴重な機会となりました。

（本記事はスパークスシステムズ ジャパン提供のタイアップ記事です）