ドメインモデル作成の5つの注意点 第4回：もう迷わないシステム開発（1/4 ページ）

システム開発を進める上で強力なトレーサビリティーツールとなる「システム開発地図（System Development Map）」について解説。第4回は、概念モデル、用語集、ドメインモデルの話を中心に、システム開発地図の成果物間にあるフィードバック関係にフォーカスします。

[今田忠博, 近藤正裕，ITmedia]

はじめに

　今回は、概念モデルや用語集、ドメインモデルの話を中心に、システム開発地図の成果物間にあるフィードバック関係についてフォーカスしていきます。地図の線を意識して読んでみてください。

　システム開発地図のPDFは、豆蔵のサイトからダウンロードできます。

業務分析の中での概念モデル

　業務分析では、業務の中で課題となっている箇所を特定したり、課題を解決した後の理想的な姿を示したりするために、業務フローや概念モデルなどの成果物を作成し、業務を可視化します。

　ちなみに、業務フロー作成と概念モデル作成のどちらを先に始めるべきかが問題になることがあります。まずは数時間かけて概念モデルのたたき台を作成し、あとは業務フロー作成を主とし、適宜概念モデルを更新すると分析しやすいと思います。

概念モデルの作成

　概念モデルを作成するには、業務で扱う要素を洗い出し、要素の関係を整理していきます。

• この作業の目的：
  • 関係者間で業務に対する認識を合わせるために、用語（概念）整理を行う
• 入力：
  • 業務マニュアル
  • 関係者への聞き取り
• 出力：
  • 概念クラス図
  • 用語集

　この作業は、業務マニュアルや関係者への聞き取りをもとに行います。作成した概念クラス図も大切ですが、概念クラス図の作成過程そのものが、関係者間の用語統一に大きく寄与するため、最初にたたき台としての概念クラス図を作成するときに関係者を参加させる調整も重要な要素となります。

コラム：　実際に概念モデルを行う際の準備

　実際に筆者らが関係者を集めて概念モデルを行う場合は、事前に提供してもらった資料などから想定されるモデルを用意しておいたりします。

　何もないところからモデリングを始めると、どこから手を付けていいのか分からないという状態になりがちですので、ちょうどテレビの料理番組のように、下ごしらえをしたものや、ある程度作っておいたものを用意して、関係者の時間を効率的に使うような工夫です。

　最初から完成したようなモデルを提示してしまうと、そのモデルに考えが引っ張られてしまうので、少しずつ重要そうな部分を提示して、そのモデルの形にした理由とともに説明し、意見を求めます。

　ユーザーの立場から見た用語と、開発の立場から見た別の用語が、実際には「同じものを示していた！」という発見が関係者の共同作業で見つかったことがあり、参加者の方々がモデリングの効果に感動してくれたことがありました。この時、コンサルタントとして参加している私も感動したのを覚えています。

　概念クラス図は今後の作業を通じて適宜修正を受けるため、常に保守し整合性を保つことが重要となります。

　また、関係者間で業務に対する認識を合わせるために、概念クラス図の作成作業を通じて用語（概念）の抽出を行い、用語集への反映や整合性を取りながら、それらの関連と多重度を明確にしていきます。結果として用語の整理が行われます。

　用語の定義内容は、用語集にも必ず反映させます。用語集単体で作成に当たる場合と比較して、概念モデリングから導き出すことによって、精度は格段に向上します。

　概念モデルがある程度完成したら、関係者間の会話はできるだけ、この概念モデルの用語に沿って話してもらうようにします。これによって、会話のブレがなくなるだけでなく、会話で多用することで概念モデルの問題を浮き彫りにし、概念モデルそのものの精度向上が期待できます。

　ここで導き出された概念クラス図は、後続する要件定義の、特にドメインモデル作成の入力となります。

コラム：　DDDのユビキタス言語

　Eric EvansやMartin Fowlerは、ドメイン専門家との会話においてユビキタス言語を使用することが、ユビキタス言語およびドメインモデルを検証できる重要な部分であると述べています。

# http://bliki-ja.github.io/UbiquitousLanguage/

# http://martinfowler.com/bliki/UbiquitousLanguage.html