事例でわかる,プロジェクトを失敗させない業務分析のコツ

第2章 事例1:顧客とともにUML資料を作る

2008年9月16日

この記事を読むのに必要な時間:およそ 1.5 分

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図1 今回作成したアクティビティ図のイメージ

図1 今回作成したアクティビティ図のイメージ

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

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

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

著者プロフィール

露木敏博(つゆきとしひろ)

1966年神奈川県横浜市生まれ。1990年,株式会社日立システムアンドサービス(旧日立システムエンジニアリング株式会社)に入社。

流通系SE,営業所駐在SEなどを経て,2003年から生産技術部門で.NET技術に関する技術支援業務に携り,.NET技術に関する各種基準書および標準化,設計ガイドなどを作成。

マイクロソフトMVPアワードプログラムよりDevelopment Platforms - ASP/ASP.NETのカテゴリで2008年7月よりMVPアワードを受賞。

コメント

コメントの記入

ピックアップ

EC事業者が注目,.shopドメインとドメイン名をとりまく新たな流れ

インターネットの可能性を広げる新たな動きが,ドメイン名をめぐって起こりつつあります。

エンジニア特化型Q&Aサイト「teratail」のトップランカーたちが語る,確実な力を付けるための“質問力”

エンジニア特化型Q&Aサイト「teratail」のトップランカーの方々に集まっていただき,座談会を開催しました。

Webサイトに“安心”をプラス―知らないでは済まされないSSLサーバ証明書の仕組み

いまやユーザといえでも必須の知識となったWeb通信の暗号化と,その信頼性を確保するための「SSL証明書」のしくみについて紹介します。

リクルートライフスタイルの技術力を追え!

ビジネスを拡大し続けるリクルートライフスタイルの技術力を,編集部の徹底取材により紐解きます。

開発スピードに限界を感じたときの処方箋

「JIRA」をはじめとするアトラシアンのツール群。多くのオープンソースソフトウェアを継続して提供する支えとなっている使い易さを探ってみます。

デジタルコンテンツを日本から世界へ―MyCommerceで始める越境EC

自社開発ソフトウェアを海外も含めてオンラインで販売したいというニーズに即したサービス「MyCommerce」を用いて,誰もが手軽に越境ECを実現するためのノウハウを紹介します。

バックナンバー

No12(2009.04)

今回のSoulHackで主に取りあげるのは,梅田望夫の「ウェブ時代をゆく」という本です。

No11(2009.03)

今回のSoulHackで取りあげるのは,阿部謹也の「世間学への招待」と他1冊の本です。

No10(2009.02)

今回のSoulHackで取りあげるのは,山本七平の「空気の研究」という本です。

No9(2009.01)

今回のSoulHackで取りあげるのは,アーノルド・ミンデルの「紛争の心理学」という本です。

No8(2008.12)

今回のSoulHackで取りあげるのは,河合隼雄氏の「カウンセリングを語る」という本です。

No7(2008.11)

特集:2008年度日本OSS貢献者賞受賞者インタビュー

No6(2008.10)

特集:エンジニアの実践的キャリアアップ思考法

No5(2008.09)

特集:事例でわかる,プロジェクトを失敗させない業務分析のコツ

No4(2008.08)

特集:ゼロからはじめるPSP

No3(2008.07)

特集:今こそ使える! プロトタイピング

No2(2008.06)

特集:「開発スタイル」開発法

No1(2008.05)

特集:エンジニアが身につけたい基本スキル 2008

-->