はじめに プレイリスト ビデオ 導入の助言 リンク トップへ戻る

はじめに

Banner


Enterprise Architect のメリット

Enterprise ArchitectはUML 2.5, SysML 1.5, BPMN 2.0など、様々な表記方法に対応したモデリングツールです。 効率的なモデリングを実現する数多くの支援機能を有しており、設計内容の影響関係の把握(トレーサビリティ)を支援する機能・ドキュメント生成機能・シミュレーション機能・アドインの作成機能などがあります。 これらの機能を組み合わせることで、開発フロー全般を包括的に支援します。

Enterprise Architect

Enterprise Architectは、同種のソフトウェアと比較しても、以下の点が優れています。

  • データベースが統合された真のモデリングツール
  • 論理要素を多角的な視点で捉える統合環境を提供
  • 要件定義、設計、実装、検証と包括的なワークフローで使用可能
  • 設計のみならず実装でも活用可能な有用な機能を多数完備
  • 小規模設計から大規模設計までスケーリング可能
  • 高い拡張性を持つプラットフォーム
  • 優れたコストパフォーマンス
  • 知れば知るほど奥が深い = 幅広い有効利用可能な場面

Enterprise Architect 典型的な導入の障壁

Enterprise Architectは、広範囲に渡って適用可能な汎用性が魅力の統合モデリング環境です。 特にコスト面において導入の敷居が低く、初めてモデリングツールを使い始める方から、シミュレーション環境と組み合わせての統合的な利用を行なう方まで、長く幅広い範囲でお使い頂けます。

一方で、Enterprise Architectを最初に導入しようとしたときの障壁があるのも事実です。 導入障壁の例を以下に挙げます。

  • 少なくとも無償ではない
  • 機能が多くて訳が分からない
  • 身近に使っている人がおらず心細い
  • 無骨なユーザーインターフェースで親しみが湧かない
  • 使ってみたものの効果が実感できるまで使いこなせなかった経緯がある

これらはスパークスシステムズジャパン株式会社の中の人が公開している動画を見る事でかなり解消できます。 一方で、スパークスシステムズジャパン株式会社の中の人は業界数十年のベテランでツールに詳しすぎており、ユーザーの戸惑いを理解できない事もありそうです。

そこで、本ウェブサイトでは、Enterprise Architectを使い始めた人が最初に戸惑うであろう内容を、実際に使い始めてから感じた様々な疑問を整理する形で短い動画に纏める事にしました。 きっと皆様のお役に立てるはず。


本ウェブサイトの対象読者

  • Enterprise Architectを初めて使う組織や人
  • Enterprise Architectを現在導入しているものの、効果を実感できていない組織や人
  • Enterprise Architectを過去に使用したものの、効果を実感できなかった組織や人
  • Enterprise Architectの仲間を探している組織や人
  • UMLやSysMLなどを使った設計の整理に興味のある組織や人
  • 近年注目の集まるシステムズエンジニアリングなどの新しいアプローチに興味のある組織や人
  • コストパフォーマンスに優れたモデリングツールを探している組織や人
  • システムやハードウェアやソフトウェアの設計に新たな手法を取り入れたいと考える組織や人
  • 他社製ツールを使用しているがEnterprise Architectに興味のある組織や人
  • 個人的な研鑽や学習のためにEnterprise Architectを導入したいが迷いのある人
  • ドキュメントベースエンジニアリングに疑問を感じており、組織における開発のあり方や取り組みを変えたい方

プレイリスト


Enterprise Architect お役立ちテクニック集まとめ

番号 タイトル よくあるユーザーの疑問や戸惑い リンク
001 境界線に塗りつぶしを設定して視認性を向上 配置した要素を視覚的にグルーピングする事で分かりやすいダイアグラムにしたいです。 見る
002 プロジェクト作成後に何をしたら良いの? プロジェクトを開いて手が止まりました。次に何をしたら良いのか分かりません。 見る
003 画面レイアウトの復旧 モデリングに必要な部品が並んでいるユーザーインターフェース部品を閉じてしまいました。操作が出来ずに困っています。どうやったら元に戻せますか? 見る
004 用語集を活用して一貫性を確保する ツールを使っているのに設計が効率化されているように感じませんでした。何か具体的なメリットをひとつ例示して下さい。 見る
005 用語集をドキュメントに出力する ツールを使っているのに設計が効率化されているように感じませんでした。用語集のメリットを水平展開するアイデアも欲しいです。 見る
006 ダイアグラムの凡例 ダイアグラム内の要素が全部同じ色で分かりやすさに改善の余地がありそうです。どのようにしたら見やすい表示を簡単に実現できますか? 見る
007 コードを読み込んで分析する ツールを使っている具体的なメリットのひとつとして、既存実装の分析にも使えたらとても便利です。コードを読み込んでモデル化するような機能はありますか? 見る
008 ダイアグラムの印刷設定 ダイアグラムを印刷したら1つのダイアグラムが何ページにも渡って分割印刷されてしまい、使いものになりませんでした。どうしたら良いですか? 見る
009 クラスに操作を追加する クラスに対して関数を追加する方法が分かりません。どうやったらクラスに関数を追加できますか? 見る
010 既定のダイアグラムを設定して利便性を高める 利用者がプロジェクトファイルを開いた時に、プロジェクトの全体像が一目で分かるような挙動を実現できたら素敵です。具体的にどうしたら良いですか? 見る
011 「使いづらい」印象はどこから来るのか?(その1) 要素を整列させたり大きさを整えたりする手順が面倒です。どのようにしたらこの手順を省略して使いづらさを改善できますか? 見る
012 「使いづらい」印象はどこから来るのか?(その2) モデリングツールの良さを理解は出来ましたが見た目が無骨で敷居の高さを感じます。お絵描きツールのような親しみの湧くユーザーインターフェースにできませんか? 見る
013 システムの表現に最適なSysML UMLでは表現しづらいシステム表現を効率的に行なう手法を知りたいです。 見る
014 SysMLでブロックを内部ブロック図に配置する時にポートがめちゃくちゃに配置されて困る ブロックの付属要素としてインターフェースブロックがポートとして配置されています。このブロックを内部ブロック図に配置した時にポートの配置が出鱈目で困ります。どうしたら良いですか? 見る
015 モデルベース設計への段階的移行 今の設計の仕方に幾分の疑問はあるものの、設計の仕方を大幅に変えるのはいまさら難しいと感じる事が多いです。何かお勧めの移行方法はありますか? 見る
016 スクリプトレットで手軽に自動化 単純な操作を膨大に繰り返し行わなければならない場面に遭遇する事があります。なんとかして自動化したいのですが手段はありませんか? 見る
017 画像を使ってダイアグラムの表現を豊かにしよう! モデリングしてもシステムに関する理解が深まったように思えません。理解を進めるためにできる工夫があれば教えて下さい。 見る
018 SysMLのポートを整列する グリッド設定をしても、SysMLのポートがグリッドにのりません。どのようにしたらSysMLのポートを手軽に整列させられるでしょうか・・・。 見る
019 効率的なモデリングツールの活用 モデリングツールを採用したものの、作業が増えただけでメリットを感じませんでした。何かアプローチを間違えているかもしれません。 見る
020 プロジェクト管理情報も統合しよう (ガントチャート編) このガントチャート機能って、どうやって使うのですか? 見る
021 プロジェクト管理情報も統合しよう (ドキュメント編) モデリングツールを導入した結果、単に使うツールが増えただけで、管理が大変になっている印象があります。何か間違ってしまいましたか? 見る
022 ツールを持っていない人にプロジェクトを見せたい 周りにEnterprise Architectを持っている人がおらず、自分の設計情報を見せる事ができません。どのようにしたら良いですか? 見る
023 要求の色付けと状態の定義 手始めに要求を整理しているのですが、プロジェクトの状態を俯瞰して見るような工夫があれば教えて下さい。 見る

Enterprise Architect お役立ちテクニック集 プレイリスト

ビデオ


001: 境界線に塗りつぶしを設定して視認性を向上

Enterprise Architectの境界表現は、設定を行なう事で特定の色で塗りつぶすことができます。 ダイアグラムの中で色表現を加える事で、視認性の高いダイアグラム表現を実現できます。


002: プロジェクト作成後に何をしたら良いの?

Enterprise Architectでプロジェクトを作成した後、画面が劇的に変化しないので戸惑う方もいるようです。 この動画では、プロジェクト作成後、手始めに何をすれば良いのかについて解説します。


003: 画面レイアウトの復旧

Enterprise Architectのユーザーインターフェース部品を誤って閉じてしまった場合、2度と復旧できないのではないかと不安になる事があります。 実際には、画面レイアウトを簡単に復旧する手段が提供されていますので、便利な機能を御紹介します。


004: 用語集を活用して一貫性を確保する

Enterprise Architectに備えられた用語集の機能を用いる事で、設計に使用する用語の定義を厳格にすることが可能になります。 モデリングツールでは、往々にして「どうしてこの機能があるのか分からない」といった事が最初に起こります。 用語集を用いる事で論理構成する時の定義の揺れを最小限に留め、効率的な設計を実現できるはずです。


005: 用語集をドキュメントに出力する

用語集は、モデリングツールであるEnterprise Architect内に留まるものではありません。 二次成果物としてWordのような文書に出力した場合にも、効果的に二次利用できる事から、この方法について解説する事にしました。


006: ダイアグラムの凡例

Enterprise Architectでモデルを実現した場合、その外観が同じような見た目をしていることから、見やすさを重視する人達にとっては効率的なものに感じられないことがあるようです。 この動画では、ダイアグラムの凡例の機能を用いて色分けした要素表示を行なう事の効果を御紹介します。


007: コードを読み込んで分析する

Enterprise Architectの優れた機能のひとつに既存コードを読み込んで要素にする機能があります。 設計情報が全くないような成果物に対して分析を行わなければならない場合に特に有効です。


008: ダイアグラムの印刷設定

Enterprise Architectでモデリングを実施した後、喜び勇んでダイアグラムの印刷を試みた時に最初に驚くのが出力結果です。 1つのダイアグラムにも関わらず数ページに分割されて印刷される事もありますが、この挙動は設定によって変更できます。 この動画では、印刷設定の方法とそのメリットについて解説します。


009: クラスに操作を追加する

Enterprise ArchitectでUMLクラス図にクラスを配置した後、クラスを定義したいときに戸惑う方もいるようです。 この動画では、クラスに操作を追加する方法について解説します。


010: 既定のダイアグラムを設定して利便性を高める

Enterprise Architectのプロジェクトを開いた時に、画面があまり変化しないので何が起きているのかユーザーには分かりづらいと頻繁に聞きます。 この動画では、規定のダイアグラムを設定する事でプロジェクトを開いた時に特定のダイアグラムを開く動作にする方法について解説します。 また、更に便利に御利用頂くためのヒントについても御紹介します。


011: 「使いづらい」印象はどこから来るのか?(その1)

Enterprise Architectは、デフォルトの挙動に由来する「使いづらい」と感じる要素があるように感じます。 このデフォルトの挙動は設定によって変える事ができ、それらの変更によって印象が大幅に改善されます。 この動画では、要素の配置や整列に関連するグリッド設定と大きさを揃える方法について解説します。


012: 「使いづらい」印象はどこから来るのか?(その2)

Enterprise Architectは、その筋の方々が使用するモデリングツールです。 従って、モダンでファンシーな見た目といったことは本質的ではないため、そこに重点は当然ながら置かれません。

しかし、利用者である我々は人間で、実際には見た目に影響された印象を得るものです。 この動画では、使いづらく感じる要因のひとつは無骨な見た目にあるのではないかとの仮説の下、見た目を変更することでどのようになるのかを実演を交えて御紹介します。


013: システムの表現に最適なSysML

SysMLを使用すると、システムのブロックとブロック間を流れるデータの表現が可能になります。 UMLでは表現しきれないこれらの内容は、ハードウェアとソフトウェア、あるいは、システムとソフトウェアといった観点で設計対象を見る人達にも有用です。 この動画では、SysMLを使い始める最初の一歩として、簡単なブロックの定義と、ブロック間の接続について実演を交えて解説します。


014: SysMLでブロックを内部ブロック図に配置する時にポートがめちゃくちゃに配置されて困る

ブロックの付属要素としてインターフェースブロックがポートとして配置されています。 このブロックを内部ブロック図に配置した時にポートの配置が出鱈目で困ります。 手作業でポートを再配置するのではなく、配置する際にポートが理想的な状態に配置される方法を御紹介します。


015: モデルベース設計への段階的移行

様々な組織での開発経験をもとに、成功しやすいモデルベース設計への移行方法について御提案するビデオです。 モデルベース設計はあくまで手段であり、真の目的は顧客の要求を満たすシステムを、効率的かつ効果的に、そして確実に実現することにあります。 段階的移行を用いる事で、組織的な負荷を最小限に抑えながら、改善効果を実プロジェクトで確認できます。


016: スクリプトレットで手軽に自動化

スクリプトレットは、ダイアグラム内に「スクリプトレット」要素を配置する事で使用できます。 スクリプトレットはJavaScriptで記述でき、Enterprise Architectのオブジェクトを直接操作できるものです。 これまで手作業で行なっていたことを自動化する際に便利な機能です。


017: 画像を使ってダイアグラムの表現を豊かにしよう!

システムを表現する時に、ドメイン固有の内容をよく表現した画像をダイアグラムに配置する事で、劇的に理解しやすくなることがあります。 この動画では、画像をダイアグラムに配置する基本的な方法と実際のメリットの例を解説します。


018: SysMLのポートを整列する

もしかすると何かの設定があるのかもしれませんが、グリッド設定をしても、SysMLのポートがグリッドにのりません。 今回の動画では、SysMLのポートをスクリプトレットを使用して整列させる例を見てみましょう。


019: 効率的なモデリングツールの活用

モデリングツールを採用した時、最初に簡単なモデルの記述から始められると思います。 ドキュメントベースのエンジニアリングを行なっていた企業の場合、モデリングツールによる設計を始めた初段では、単に仕事が増えただけと感じる事も少なくないようです。

この動画では、ドキュメントベースのエンジニアリングを行なっている方のヒントとなるように、モデリングツールでのモデリングからドキュメント生成までの流れを御説明します。 Enterprise Architectのドキュメント生成機能を用いる事で、モデルを一次成果物、ドキュメントをモデルからの二次成果物として扱う事ができます。

常にモデルを設計活動の主軸にすることで敏速で矛盾の無い設計活動を推進できる他、成果物としてドキュメントを求められる場面でもドキュメント生成機能によって適合できます。


020: プロジェクト管理情報も統合しよう (ガントチャート編)

プロジェクトに関連する情報があちこちのツールに分散すると、結果的に情報の整合性が失われてしまいます。 プロジェクトの進行を管理し、次の仕事の形を決める場合、計画内容が設計内容と整合性が無ければ意味の無いものになってしまいます。

Enterprise Architectのガントチャート機能は、モデル要素に対して担当者を割り当てるという効果的なアプローチにより、設計とスケジュールを効率的に管理できます。 動画ではUMLのクラス図を使用していますが、パッケージ単位になったり、SysMLのブロックに対して担当チームを割り当てるといった応用が考えられます。


021: プロジェクト管理情報も統合しよう (ドキュメント編)

プロジェクトに対して外部からドキュメントが入力される事は少なくありません。 例えば、ドキュメントから要件を定義する時、デバイスデータシートからクラスを設計する時、様々な場面で外部ドキュメントを情報源とする場合があります。

Enterprise Architectのプロジェクトファイルの傍らにそれらドキュメントを配置する事もできますが、この動画ではプロジェクトファイルに統合する事で得られるメリットについて解説します。


022: ツールを持っていない人にプロジェクトを見せたい

Enterprise Architectを使って設計する事の利点のひとつは、単一の論理に対して情報が一元管理されており、横断的に論理階層を渡り歩ける点です。 ツールを持っていない人にプロジェクトを見せたい場合、この横断的な視点が失われがちですが、Enterprise Architectの各種出力機能を用いる事で、同じような体験をして頂くことが可能です。

この動画では、ツールを持っていない人にプロジェクトを見せたい時の3つの選択肢に触れます。


023: 要求の色付けと状態の定義

Enterprise Architectを使って要求を整理している時、少しの工夫を加える事でプロジェクトの状態を俯瞰して見る事が可能になります。 この動画では、要求の色付けと状態の定義について述べます。

導入の助言

以下は、よく寄せられる質問とそれに対する、経験に基づいたアドバイスです。 ぜひ、ご参考になさってください。


Q. 無償ツールを探しています。

A. 知識への投資という考え方を取り入れましょう。

無償ツールを探したい気持ちはよく理解できます。 私自身もかつてはそうしていました。

しかし、長期的な成功を考えると、有料ツールがもたらす価値に目を向けることが重要です。 無償ツールを使い続ける場合、より良いツールを探すこと自体が目的化してしまうことがあります。 その結果、知識の体系化や設計の質が向上しないまま、時間を浪費することになりがちです。 また、無償ツールは企業戦略の一環として提供されていることも多いため、突然の仕様変更やサポート終了に悩まされることも少なくありません。

Enterprise Architectは、ライセンス費用が手頃で、安定したツールを20年以上も提供し続けています。 ツールを使いながら知識を体系的に整理することができ、まさに「知識を買う」ための投資に最適です。 このような考え方に移行できる組織や人材は、結果的に豊富な知識を獲得し幅広く活躍する傾向があります。

個人での導入が難しい場合は、信頼できる上司に相談するのも一つの方法です。 この内容が上司の説得材料になるかもしれません。


Q. Word, Excel, PowerPoint, Visio, draw.ioとの違いを教えて下さい。

A. 汎用ドキュメントツール(Word, Excel, PowerPoint, Visio, draw.io)とモデリングツール(Enterprise Architect)の違いを理解するために目的を整理します。

汎用ドキュメントツールの目的 = 表現とコミュニケーション

汎用ドキュメントツールは、アイデアや情報を視覚的に表現するためのものです。 文章や文字と共に図やフローを作成し、それらを使って他の人に共有、説明、議論したりするために使います。 これら汎用ドキュメントツールは、デザインやレイアウトを視覚的に整える点に重点を置いており、見た目が重視されます。

モデリングツールの目的 = 論理の構築と検証

モデリングツールは、システムやプロセスやコンポーネントの論理的構造を作成し、それを基に分析や設計を行うためのものです。 たとえば、Enterprise Architectでは、システムの要件、設計、プロセスの流れなどを、内包するデータベースに論理モデルとして格納します。 この論理モデルは、あらゆる視覚的表現に用いる事のできるもので、背後にあるデータや関係性を含みます。 これにより、論理的な関係性検証やシミュレーション、システムの分析や自動コード生成など、開発プロセスで発生するあらゆる要件に活用できます。

モデリングツールの具体的な利点
  1. 一貫性の保持: モデリングツールでは、システム全体の一貫性を維持しやすいです。たとえば、ある要素が他の部分にどのように影響を与えるかを視覚化し、全体として論理的に矛盾のないモデルを作成できます。一方、作図ツールでは、手動で変更を加える必要があり、一貫性を保つのが難しくなります。
  2. 再利用性: モデリングツールで作成したモデルは、他のプロジェクトでも再利用が可能です。システム要件や設計パターンをライブラリとして保存し、他のプロジェクトで簡単に適用できます。作図ツールでは、このような再利用は一般的には困難です。
  3. データ駆動の設計: モデリングツールは、単なる図ではなく、データの集合体としてモデルを扱います。これにより、さまざまな観点からシステムを分析し、問題点を早期に発見できるほか、ドキュメント生成やコード生成を自動化することができます。作図ツールはこのような機能を持たないため、手作業が増え、エラーのリスクも高くなります。
  4. コミュニケーションとトレーサビリティ: モデリングツールでは、要件から設計、テストまでのトレーサビリティを確保することができます。これにより、システムの進捗や変更履歴を追跡しやすくなり、関係者間のコミュニケーションがスムーズになります。作図ツールでは、個別の図が独立しているため、トレーサビリティを確保するのが難しいです。
結論

結論として、作図ツールは視覚的な表現に優れている一方で、モデリングツールはシステムの論理的な設計や分析に強力な機能を提供します。 モデリングツールを検討するエンジニアの方には、モデリングツールが単なる作図を超えたものであり、システムの本質的な理解や効率的な設計・開発を支える強力な武器であることを理解して頂くことが重要と考えます。


Q. ちょっと触ってみましたが使いづらいです。

A. 使いこなすには少し時間がかかりますが、それが価値を生みます。

最初は誰でも使いづらさを感じることがありますが、それはあなただけではありません。 モデリングツールは、設計対象の論理要素を矛盾なく整理するためのツールであり、慣れるまでに時間がかかるものです。

Enterprise Architectのようなモデリングツールを使いこなすには、何度かの挫折や、数年の期間や、幾つかの実プロジェクトへの適用が必要になるものです。 実際に実プロジェクトの中で試行錯誤する過程で、徐々にその効果を実感し、隠された真の価値が見えてくるものです。 ツールの挙動を理解するためには、背景にある「なぜ?」を理解することが重要です。 毎日使い続けることで、理解が深まり、ツールの真の力を引き出すことができます。

「使いづらさ」は、学習が進んでいない段階で感じるものです。 そのたびにツールを変えてしまうと、知識を修正する機会を逃してしまいます。 ツールを変えるのではなく、自分の理解を深めていくことが、新しい仕事のやり方を会得する鍵となるでしょう。


Q. モデリングなどと言う人を信用できません。

A. その気持ちは理解できますが、シンプルな論理が複雑な設計を支えます。

過去には私自身も、実際の設計を知らない人たちがやっているように感じたものです。 技術者として誇りを持つあまり、ツールで論理を扱うことに抵抗を感じるのも無理はありません。

しかし、複雑な設計も、シンプルな論理の積み重ねで成り立っています。 このシンプルな論理を整理し、人に説明できるレベルに持っていけなければ、複雑な設計を成し遂げることは難しいでしょう。

大規模な設計に直面したとき、簡単に見えることを丁寧に論理構築することが求められます。 頭の中で整理できていても、第三者にも理解できるように可視化することは、次元の異なるスキルが必要です。 新しい仕事の仕方を試すことで、これまで気づかなかった知見を得ることができるでしょう。


Q. ツールを使わずとも十分に設計ができています。

A. その主張はとても理解できます。

既に十分に設計ができていると感じている組織にとって、ツールを導入して新しい仕事の仕方を身に着けることに抵抗を感じるのは無理もありません。 単に設計負荷が増えるのではないかと懸念されることもあるでしょう。

しかし、実際にモデリングツールを用いて論理要素を整理すると、一見難しそうに見える課題が単純化されたり、思わぬ設計波及効果によって新たな価値が創造されることも少なくありません。 また、これまで十分に設計できていたエンジニアが、モデリングツールを手にした途端、これまで以上に高い価値を短期間のうちに提供するようになった光景を何度も見てきました。

新しい結果は、新しい考え方や新しい仕事の仕方から生まれると考えた場合、モデリングツールを使った論理設計は、取り組む価値のあるものと考えています。


Q. あなたがEnterprise Architect を導入するきっかけになった出来事は何ですか?

A. 設計活動に対する疑問から、より効果的な方法を模索しました。

あるプロジェクトで、拡張設計を担当することになったとき、設計情報が整理されておらず、実装を読み解く必要がありました。 最初はコピー用紙にクラス図を描いて整理していましたが、次第にもっと効率的な方法が必要だと感じ、ツールを探し始めました。

幾つかのツールを試した結果、Enterprise Architectが最も適していると判断しました。 他のツールは、コードを読み込む能力が不足していたり、ライセンス費用が高すぎたり、そもそも試すことが難しかったりしました。 Enterprise Architectを導入したことで、手作業で行っていた分析が自動化され、設計の理解が大幅に促進されました。


Q. 導入に際して挫折しないお勧めの方法や考え方はありませんか?

A. 以下を参考にして下さい。

お勧めの方法や考え方
  • 導入に際して、組織や個人で絶対に解決したい内容を、数個に絞って具体目標とすること。
  • 何度かの挫折(使わなくなる期間)を導入計画に盛り込むこと。
  • 確実にできそうな部分から小さく始めること。
  • 最初から完璧を目指さないこと。数年経ってから誤解が解けることは往々にしてある。
3-3-3-3の法則
  • [3回挫折] 3回くらいの使わなくなる期間(前の仕事の仕方に戻る期間)が往々にしてあります。正常系と捉えて活動を続けましょう。
  • [3年経過] 諦めずに続ける過程で3年くらいが経過します。自分達の発想を変革するために必要な時間と割り切り活動を続けましょう。
  • [3回適用] 3つ以上の実プロジェクトに適用し、ポジティブな視点で効果検証する事で、活動を続けられるようにしましょう。
  • [3段階の段階的導入] 導入がスムースに進む企業の特徴は「1.自分で使い有用性を確認する / 2.周囲の人に有用性が伝わる / 3.組織的な活動に波及する」のようです。

これらの導入障壁を乗り越えてツールの効果や背景概念を理解したチームには、相応の知識と新しい仕事の仕方が身についているものです。

モデリングツールを使って設計を論理的に整理する組織では、設計がチーム内で共有され、結果的に各個人の能力は飛躍的に向上します。 熟練技術者は繰り返し同じことを行なうのではなく、自らの設計ノウハウを若手技術者に共有することで、次の技術的な高みを目指す機会を得ます。 モデリングツールのメリットのひとつは、思考の結果が形としてプロジェクトファイルとして残ることです。 形に残ったプロジェクトファイルは、別のメンバーがプロジェクトに新たに参加する時、数年経過したプロジェクト成果物の検討を進める時、既に忘れてしまった自分の設計を振り返る時、などあらゆる場面で有用です。

導入には相応の時間を要するため決して平坦な道のりではありませんが、乗り越えた先のメリットが大きいのもまた事実です。

リンク


ツール提供元

Enterprise Architectは、日本国内においてスパークスシステムズ ジャパン株式会社が開発と販売を手掛けておられます。 日本市場に適合する数多くの独自機能拡張が施された国内用バージョンは、その魅力を理解すると手放せないツールのひとつです。

Enterprise Architect ウェブサイト

直接ツールを見てみたり話を聞いてみたりしたい方は、イベント情報も御覧下さい。

スパークスシステムズジャパン イベント情報


お役立ち情報提供元

お役立ち情報は、リベラルロジック株式会社の提供でお送りしています。

リベラルロジック株式会社ウェブサイト