[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 モデリング導入以前

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

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

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

• 単独あるいは限られたメンバーで要件を決定したため、機能の洗い出しが不十分・不適切だった
• 多数の参加者から意見が噴出し、要件がまとまりきらなかった
• 特殊な業務ルールや操作性に議論が集中し、時間的にも予算的にもオーバーしてしまった

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

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

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

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

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

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

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

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

• 業務用語などを整理した概念モデル（クラス図）
• 条件分けを整理したアルゴリズム（アクティビティ図）
• 状態遷移を整理した状態マシン図

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

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

3.1. 導入の利点

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

• 検討内容と深さを規定し、適切な人を適切なタイミングに招集できる
• 検討目的と外れた内容に発散することを抑制できる
• プロジェクト全体で同じモデルを少しずつ完成していくため、整合性チェックがしやすい
• モデルのチェックが簡単になり、効率的に検討できる

3.2. モデルのサンプル

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

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

3.3. 文書の構成について

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

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

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

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

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

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

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

5. 次回の予告

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

© 2008 Keiko Nakase

Index Next