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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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