この章と次の章で，実際に私が携わった業務システム構築の業務分析工程のうち主にUMLを使用した事例について紹介しましょう。

A社は小売量販店で，契約した顧客に対して指定された場所に食材を配達するサービスを行っています。このサービス業務の一部として，ピッキング担当員が各顧客用の配達用ケースに顧客が指定した食材を入れ，配達用のラベルを貼付するまでを行う作業を支援するピッキングシステムがあります。

現在のピッキングシステムはメインフレームで構築されており，今回オープンシステムへの移行を計画していました。

しかし，A社内にはオープンシステムに関してのシステム構築事例がなく，業務分析，要件定義から本稼働までの全工程を顧客と作業を分担して進めて開発を行うことになりました。

顧客側はメインフレームでのシステム構築の経験は豊富であるため，新システムの業務分析をするにあたり，すでに使用されていた業務フロー図とOOAでよく使用されるUMLの両方を作成し，顧客側の理解を得やすい手法を採用しました。

現行システムの状況を俯瞰

新システムの構築にあたり，まず現行システムの業務分析を行いました。

現行システムの開発時の資料は残されていましたが，ほとんどの資料がメインフレームでのシステム構築用であるため，文章と表，詳細レベルのフロー-チャートで作成されていました。ただし，システムの全体像については業務フロー図が作成されていました。しかし，機能ごとの関連やデータの流れなどを把握することは難しい状態でした。

そこで，これらの資料は参考資料として，実際の業務システムのソース及び現場のリーダーから直接ヒアリングを行い，業務分析を行うこととしました。この際，業務フロー図とUMLのアクティビティ図とユースケース図を作成しました。

まず，既存システムの概要レベルの業務フローの修正を行いました。この作業は現行システムの資料としてすでに業務フロー図があったため，顧客側で現場へのヒアリングと共に修正をお願いしました。ここで作成された概要レベルの業務フロー図を基に，我々開発者側でアクティビティ図とユースケース図を作成しました。このように対比する物を作成することにより，顧客のUMLへの理解を高め，顧客との意識のずれをなくすようにしました。

次に新規構築するピッキングシステムについての概要レベルの資料を，先に作成した既存システムの概要レベルの業務フロー，アクティビティ図とユースケース図を参考にしながら，顧客と共同で作成しました。この作業にはとても時間がかかりましたが，顧客にも参加していただくことで，OOAの概念からUMLのさらなる理解，新規に構築するシステムへの理解も深めてもらうことができました。

この後は以下の資料を順次作成していきました。

• サブ機能レベルで作成
• 複数機能連携レベルで作成
• 単機能レベルで作成

資料作成にあたり，その前の工程で作成した資料を基に作成していきました。これにより，前工程の資料の見直しをすることができ，修正，仕様変更があっても迅速に対応することができました。しかし，いくつかの機能で「単機能レベル」での資料作成中に仕様変更と仕様ミスが発生し，「⁠サブ機能レベル」まで戻って修正を行う必要がありました。このような場合も修正対象が局所的であったため，大きな遅れとはなりませんでした。

この段階まで来ると顧客側と作業を分担し，進めることができました。ただし，定期的および随時の打ち合わせとレビューは実施し，顧客側と開発者側の意識及び認識のずれが発生しないようにしました。

また，「⁠複数機能連携レベル」⁠，「⁠単機能レベル」でのレビューには現場のリーダーの皆さんにも参加してもらい，実際の業務に合った機能とすることと，できるだけ早い段階で新システムへの移行について意識をもっていただくようにしました。

顧客から見てわかりやすくするための工夫

上記の工程で作成したアクティビティ図とユースケース図について，UMLの規格からは外れてしまいますが，少し工夫した点があります。

アクティビティ図についてですが，担当者やシステム(これらをアクターと呼びます)の境界で区切られている「スイムレーン」ごとに色分けをしたり，「⁠データ」⁠，「⁠モノ」⁠，「⁠作業」の流れを表す「フロー」の線を「データ」⁠，「⁠モノ」⁠，「⁠作業」それぞれで線の種類を分けるようにしました。これにより，視覚的な変化が出て，より理解しやすくなりました。

また，ユースケース図ではアクターおよびユースケースにメモで具体的な使用対象者や使用タイミング，関連するデータやモノ等を記述しました。

これらの工夫により，ユースケース図を見てより具体的なシステムイメージを掴んでいただくことができました。

確かに上記の工夫はUMLで規定されていません。しかし，これらの資料の目的は顧客側，開発者側で意識を合わせ，認識のずれが発生しないことがもっとも重要であると思います。そのためには規定されていなくても，よりわかりやすい資料の作成を目標としたほうが結果的に良いと思います。