ObectSquare [2008 年 9 月号]

[技術講座]


業務モデリングのパフォーマンスを 3 倍にする

モデリングハックス

前編:業務モデリングの適用事例と有効性について
 
株式会社オージス総研
エネルギーソリューション第一部
中清 桂子

 

本稿は、OGIS 総研開催の 2007 年度第 2 回西日本フォーラムで発表した内容を再校正しています。

1. はじめに

1998 年に開始し 2003 年 10 月末で終了したオージス総研の UML モデリング技術者認定制度は、最終的にのべ受験者数が 40 万人を超え、合格者数も約 7 万人に達しました。その後 UML モデリング推進協議会の UMTP のモデリング技能認定試験(現在 L1 〜 L3 のレベルを実施)に引き継がれ、合格者数は 2008 年 1 月の時点で、のべ 1 万 3 千人を超えています。このモデリング技能認定試験は、日本だけではなく世界各国で実施されており、中国やベトナムにおいても、それぞれ中国語、英語で実施されて広がり続けています。

多くの方々に利用されている UML モデリング技術ですが、わたしたちは早い段階から UML モデリングを用いたシステム設計を行ってきました。要件定義工程でも積極的に UML を活用してきました。

今回は、「業務モデリングの適用事例と有効性について」と題して、UML 導入事例を紹介し、モデル/モデリングの有効性がどこにあるのか考えてみたいと思います。そして、次回は「業務モデリングのパフォーマンスを 3 倍にあげるためのモデリングハックス」と題して、要件定義工程でモデル/モデリングのパフォーマンスをあげるちょっとした工夫を紹介したいと思います。

2. UML モデリング導入以前

システム開発では、上流工程で不具合が埋め込まれるほどプロジェクトに深刻な影響を及ぼすことは、既によく知られていることです。コーディングミスであれば該当箇所を修正し、テストし、リリースすればすみます。しかし、システムが想定している利用者や利用方法または認識していた業務要件を誤解していて、その結果として変更が必要になれば、システムの全体構想から見直さなければなりません。要件定義や基本設計から見直すといった事態も発生します。

また、要件定義の進め方によっては、要件定義に予定していた時間・打ち合わせ回数でまとまりきらず、スケジュールが遅延することもあります。わたしたちも、大なり小なり色々な失敗をしてきました。

プロジェクト完了後に失敗の原因を分析してみると、

などの原因がありました。

これまでの要件定義の進め方は、システム化の目的・目標を確認した後、業務分割を行い、業務フローの種類を洗い出し、業務フローをひとつひとつ整理し、業務ルールを文書にまとめ、画面設計を行っていました。作業の流れを図式化すると以下のようになります。

図 1 : UML 導入以前の工程
図 1 : UML 導入以前の工程

この流れで問題になってくるのは、画面定義で整理する内容が多すぎることです(業務ルール、データ項目の属性、操作性、表示項目など)。そのため、打ち合わせでは議論が発散しがちになります。また、打ち合わせのテーマが分からないため、必要と思われる人全員を招集しなければならなくなったり、反対に参加が必要な人を招集できなかったりします。これにより、無駄な時間を費やしたり、打ち合わせ回数が増えたりといった問題が起きます。

また、参加者の特定の興味・関心事にひっぱられて、プロジェクトで想定している時間・予算を超過することもあります。

大きなシステムの場合は別々の担当者が画面定義を行うため、画面・用語・操作性・エラー処理に不整合が発生します。次々とできあがる多数の画面設計書の内容について、整合性をチェックすることは非常に大変です。

図 2 : 低迷する画面設計
図 2 : 低迷する画面設計

3. UML モデルリングの導入

UML を要件定義工程に導入するにあたり、次のように進め方のステップを分解しました。

図 3 : UML モデル導入後の工程
図 3 : UML モデル導入後の工程

業務フローを定義する工程と画面を定義する工程を、アクターを定義する / 業務フローを定義する / ユースケースを定義する / 画面を定義する / 業務ルールを定義する という工程に分解しています。業務フローを検討しているときにはユースケースや画面の操作性には立ち入らず、ユースケースを検討しているときには画面の操作性には立ち入らないようにします。また、業務フローや機能を検討する中で発見された用語やルールは、業務ルールとして切り出し、次の UML の図で表すようにしています。

設計図、モデルの関係は以下のようになります。

図 4 : 設計図・モデルの作成手順と関係
図 4 : 設計図・モデルの作成手順と関係

  1. 各レイヤをレイヤごとに完成させていきます。
  2. 作業の途中で発見された言葉や概念は業務ルールのモデルにすばやくスケッチしておきます。
  3. モデルを次の手順でチェックします。
    1. モデルがある程度の量になったら、あるいは各レイヤでの作業が完了したら、次の観点でチェックします。
      • モデルごとに抜け漏れダブりがないか
      • 適切な名称になっているか
      • 関係は適切か
    2. モデルとして完成していない場合、適切な人が参加し、モデルを完成させます。
    3. 最後にモデルとモデルの間に不整合がないか、チェックします。
  4. 完成したモデルをもとに、(1) で作成した設計書の不整合や過不足を必要があれば確認します。

3.1. 導入の利点

工程を分割し、分割したレイヤごとに完成させることで以下の利点がありました。

3.2. モデルのサンプル

以下に業務ルールとして作成したモデルのサンプルを掲載します。

図 5 : 完成した概念モデル(※1)
図 5 : 完成した概念モデル(※1)
図 6 : 完成した状態マシン図(※1)
図 6 : 完成した状態マシン図(※1)
図 7 : スケッチしたばかりの状態マシン図(※1)
図 7 : スケッチしたばかりの状態マシン図(※1)

(※1) 実アプリケーションの要件定義で作成したモデルのため、ノイズ処理をしております。

3.3. 文書の構成について

UML を導入することで文書の構成も変わります。

図 8 : 文書の構成
図 8 : 文書の構成

4. モデルあるいはモデリングの効能

業務ルール(名称の定義やワークフローなど)を文章だけで記述すると膨大な量になり、全体の把握や整合性確認は困難です。
たくさんの画面設計書に分散して記述された業務要件の整合性を確認することも困難です。

モデルをスケッチすることそのものは、簡単な表記ルールの知識と若干の慣れが必要ですが、時間のかかることでも難しいことでもありません。

業務フローを整理した時点でわかっている情報を基に書いた状態マシン図は、「図 7 : スケッチしたばかりの状態マシン図」のような状況です。この状態マシン図を完成させる過程で、新しい状態を発見したり、状態遷移のためのイベントあるいはアクションを発見したりします。洗い出したイベントあるいはアクションによっては、システムの機能をあぶりだすこともできます。また業務フローを整理した時点でスケッチしたクラス図を精錬することで、曖昧だった概念を明確にすることもできます。
このように、アクター、ユースケース、業務フロー、状態マシン、クラスといった異なるモデルを仕上げることで、一つのモデルだけでは発見できなかったことを発見できるようになります。また、プロジェクトのメンバーがこれらのモデルを共有することにより、理解・認識のレベルをそろえることができます。

システム化対象の業務要件を理解していくにあたり、全体の把握と重要な箇所の詳細化について、モデルは大きな威力を発揮します。
図 4 : 設計図・モデルの作成手順と関係」で、詳細な文書を作成する前に、モデルを作成していることを確認してください。モデルは構造化された図的な目次の役割を果たしています。パッケージ図が業務フロー図の目次、業務フロー図がユースケース定義書の目次、画面遷移図が画面設計書の目次になっています。

業務要件を整理するにあたり、自然言語による文書作成を否定しているのではありません。微妙なニュアンスを正確に定義するには、モデルが最適というわけではありません。モデルが要件定義で効力を発揮するのは全体像(あるいは関係を)把握するという点においてです。モデルは、インド・中国・ベトナムなど言語を異にするメンバーとの情報共有にも有効です。文章による理解よりも図による理解のほうが、正確に速く理解されるようです。また、開発プロジェクトに途中から参入してくる全てのメンバーにとっても、有効であることがわかっています。

5. 次回の予告

次回は、モデル・(モデリング)実践・(モデルの)仕上げ・準備・環境の観点から、パフォーマンスをあげるための、ちょっとした 9 つのコツを紹介してまいります。

 

記事の内容を5点満点で評価してください。
1点 2点 3点 4点 5点
記事に関するコメントがあれば併せてご記入ください。

© 2008 Keiko Nakase
Index Next
Index Next