「システム開発地図」の使い方と作り方 第3回：もう迷わないシステム開発（1/4 ページ）

システム開発を進める上で強力なトレーサビリティーツールとなる「システム開発地図（System Development Map）」について解説。第3回は、地図の見方と、業務フローを記述する具体的な手順を解説します。

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

はじめに

　前回は、システム開発地図の特徴や、利用シーンなどを紹介し、システム開発にどのように役立つのかをお話ししました。

　今回は、地図の見方を説明し、具体的な活用手順をお話ししたいと思います。

地図の構成要素

　システム開発地図には、要件定義を中心として業務分析から実装までが描かれています。

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

　成果物は、メンバーの教育コストを考えて、なるべく標準の書式であるUMLを利用するようにしています。UMLと同等の表現力がある別の記法を採用しても構いません。現場のルールによってカスタマイズするといいでしょう。

　行う作業については、次のようなマークに大まかな粒度で書かれています。

　作業の成果物は、作業からの黄色い矢印で示されています。

　成果物同士の関連は、水色の矢印で示されています。矢印の方向は、作成する順番を示しています。

　成果物の中に現れる要素同士の関連は、紫の点線矢印で示されています。矢印の方向は、変換する方向を示しています。

「業務フローを記述する」

　それでは、業務分析の「業務フローを記述する」という作業について、具体的内容を説明していきます。

　ここでは、対象ビジネスの業務をモデル化した「業務機能構造図」に現れた業務について、課題となっている業務の手順を確認することが主目的になります。業務の中で扱われる情報として、概念モデリングで得られる概念クラス図が関連してきます。

　業務フローを記述する目的は、以下の通りです。

• 現状の業務の流れ、課題を可視化する
• 課題を解決した将来像の業務フローを検討する
• 業務で扱う概念を確認する
• 業務から属人性（特定の人にしか業務が出来ない状態）を排除する
• 業務の中でシステムとやりとりする部分を明確にする

　入力としては「業務機能構造図」と「概念クラス図」があり、出力は「業務フロー」と「ビジネスルール」になります。

　UMLを使用する場合、業務フローはアクティビティー図を用いて記述します。業務フローを記述する作業は、大まかには次のようなものです。

• ビジネスイベント（ビジネスユースケース）ごとに、業務フローを作成する
• 人やシステムをレーンとし、業務の流れ、システムとのやりとりを記述する
• 業務判断や規約などのビジネスルールを抽出する

　ビジネスイベントとは、例えば在庫管理業務では「出庫する」「入庫する」などの単位となります。その業務を行う人や関係するシステムを抽出してスイムレーンに割り当て、業務の流れやシステムとのコミュニケーションを記述していきます。作業手順としては、以下のようになります。

1. 担当者を抽出し、レーンとする
   • 業務の担当者は、概念モデルやヒアリングから抽出する
2. システムレーンを追加する
   • システムのレーンを右端に（横書き時は下端に）追加する
3. 手順を箇条書きにする
   • 作業手順を箇条書きする
   • 手順の主語（作業者）を明確にする
4. 手順をアクティビティーにする^（注1）
   • まずは大まかな時系列に上から並べる
5. 流れをフローで表現する^（注2）
   • アクティビティーをフローでつなぐ（並列や条件分岐に注意）
   • 分岐条件など、重要なものはビジネスルールとして抽出しておく
6. アクティビティーとやりとりのある情報を概念クラスから抽出し、関連を引く
   • 必要に応じて概念クラスのモデリングを行う

---

注1：　業務フローを記述する際に、アクティビティーをどの単位でまとめればいいか分からないということがよく問題になります。現場の作業者が行う作業を理解することが目的であれば、作業者をまたがらないようにし、作業の区切りで同じ役割の別の人に引き継げる程度にまとめると良いでしょう。ただし、1つのアクティビティーの中に人の判断が含まれる場合は、アクティビティーを分けたほうが、人に伝わりやすいモデルになります。コラム「アクティビティーの単位」を参照してください。

注2：　フローで表現するといっても、ただ単に順番につないでいけばいいというわけではありません。ある業務をどのように表現すればいいのかということも、よく問題になります。コラム「業務フローの書き方」を参照してください。