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

第1章 業務分析を成功に導く6つのポイント

2008年9月16日

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

筆者は後の章で述べる事例を含め,これまでさまざまなプロジェクトに参加してきました。これらの経験から,業務分析工程を間違いなく進め,プロジェクトを成功に導くためのノウハウをいくつか得ることができました。最初にこれをまとめて紹介します。

1.全体の業務が俯瞰できる資料を作成する

業務フロー,アクティビティ図,ユースケース図などを使用して,一目で業務全体が見渡すことができる資料を作成します。大規模なシステム開発では,なかなか作成することは難しいかもしれませんが,できる限り作成するようにします。

こうした資料は業務要件や要件定義を作成する際に使用されるのではなく,システム変更や障害発生時などさまざまな場面で役立ちます。発生した事象が業務全体のどの部分に影響が発生するかを見渡すことができるのです。

私の経験では,これらの資料は業務要件や要件定義を作る工程で作成しない場合,後の工程で作成されるケースも非常に少ないです。なぜなら,本稼働後はシステムの維持管理,保守や仕様変更,新システムの構築等で資料を作成する時間がなくなる場合がほとんどだからです。

一度作成しておけば,変更が発生した際にメンテナンスすればよく,メンテナンスにはあまり時間がかからないものです。ぜひ要件定義の工程で作成することをお勧めします。

2.『誰が』,『いつ』,『どこで』,『どの処理を』行うか」を明確にし,顧客と意識を合わせる

業務分析,要件定義の作成において,最も重要な事項の1つに「『誰が』,『いつ』,『どこで』,『どの処理を』行うか」があります。

業務分析時にこれらは明確にされるべきですが,この中の1つでも明確になっていないと,後工程での修正に膨大な工数がかかることがあります。

あるプロジェクトで,「出荷伝票を出力する」という機能がありました。この機能について,業務要件や要件定義の工程で『どこで』の検討を行うのを忘れたため,顧客側と開発側とで認識のずれが発生したことがあります。

顧客側は「出荷指示」機能の中でシステムが自動的に「『操作者の手元で』出荷伝票を出力する」と思われていました。しかし,開発側は「出荷指示」機能の中でシステムが自動的に「『倉庫で』出荷伝票を出力する」と思っていました。そのため,テスト行程になって初めて出力する場所が異なることが発覚しました。

この認識のずれにより,クライアント側およびサーバ側のアプリケーションに仕様変更が発生し,工程遅延の元となってしまいました。

このように,わずかな認識の違いにより,工程の遅延や顧客の信頼の失墜を招くことがあります。必ず「『誰が』,『いつ』,『どこで』,『どの処理を』行うか」を資料に中で明確にし,顧客側と開発側で認識のずれをなくすようにします。

3.「『誰が』,『いつ』,『どこで』,『どの画面を』操作するか」を明確にし,顧客と意識を合わせる

これも前項と同じように見えますが,処理だけでなく画面表示についても注意が必要です。

画面は直接エンドユーザが使用するため,要望,クレームが発生しやすい部分でもあります。そのため,画面レイアウト,画面遷移,ボタンの表示,画面内で可変となる表示項目を明確化します。とくに画面内で可変となる表示項目については別枠に記載して明確に(できれば具体的に)変更される内容を記載します。

エンドユーザの立場からすると,サーバやデータストアなどの裏側の仕組みが変わっても特に問題にはしないものです。しかし,直接操作する画面が変更になることには非常に敏感です。そのため,エンドユーザの立場に立って「どのように画面が変更になるのか」,「どのように操作が変わるのか」,「どのように業務が変更になるのか」,これらを具体的に説明できる資料を提示することが必要となります。

これらの顧客側の調整はお願いするとしても,開発者側は顧客側内で必要となる資料や情報を提供する必要はあるでしょう。

4.実際に使用するエンドユーザとのレビューを行う

これも前項に関連しています。業務分析の現状分析の段階でエンドユーザのリーダーの方にレビューに参加していただくことが最初の段階になると思います。その後,新システムの業務分析,要件定義の段階でレビューに参加していただき,入出力設計にも参加していただくほうが良いでしょう。早い段階で新システム構築に参加していただくことは,新システムへの変更を意識づける意味もあり,システム移行時にスムーズに進む事が期待できます。

この際注意するのは,レビューでは確認のみをお願いし,業務的仕様が間違っている,業務が回らない等のシステムとして仕様変更が必要な場合を除き,基本的に仕様の変更,画面レイアウト変更などの要望は受け入れないようにすることです。

5.データの流れを明確にする

業務分析の工程ではあまり細かいデータの流れなどには注目しない場合が多いです。しかし,複数の業務に渡り使用されるデータやユーザ認証情報などについては,本工程から意識しておく必要があります。

第3章で紹介しますが,将来大規模システムになる可能性がある場合,アプリケーションフレームワークの構築を検討する必要がある場合があります。このような場合,本工程でこれらのデータの流れを認識し,顧客側と開発側で意識を合わせておく必要があります。

6.エラー情報の取得方法を明確にする

業務分析の工程では個々の障害発生の対応方法についての検討は行いません。しかし,障害の原因究明,リカバリ時に必要となるエラー情報の取得方法については方針として検討する必要があります。

一般的にエラー情報の取得の方針については基本設計で行われることが多いと思われます。しかし,複数のシステム開発が並行して行われる場合,基本設計工程では各システム単位で設計が行われることが多いため,なかなか統一することが難しいことが多いです。そのため,本工程で方針を決め,必要であればシステム間で共通化したエラー処理機能を使用するようにする必要があります。

著者プロフィール

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

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

-->