後藤卓司
日立製作所 情報・通信グループ プロジェクトマネジメント統括推進本部
業務プロセス設計では，システムの動き（振る舞い）を明確にする。ここでは「(1)業務フロー設計」と「(2)ユースケース分析」というステップを踏み，5種類の設計書を作成する（図4）。要件定義で作成した「業務流れ図」「業務機能階層図」「業務用語集」「アプリケーション機能一覧」を用意しておこう。図5と照らし合わせて読んでほしい。
(1)業務フロー設計では，業務機能がどのような組織，手段，手順で処理されるのかを記述した「業務流れ図」と，業務全体を大機能，中機能，小機能に構造化した「業務機能階層図」を作成する。
要件定義でも業務流れ図や業務機能階層図を作成しているが，これらはユーザー側の視点で記述されているものだ。業務フロー設計ではこれを，開発者側の視点で書き直すことになる。その際，次の3点に注意する。
一つ目は，それぞれの図で業務機能の粒度（階層）をそろえること。業務機能階層図に示された小機能（最下位の粒度）の業務機能と，業務流れ図の業務機能のレベルが合致していることを確認する。
業務機能の中には，手作業で実施するものもある。読み手の混乱を避けるには，システム化の対象となる機能と手作業を明確に区別することが大切だ。システム化する業務機能をアイコンで視覚的に示すなどの工夫がいる。
二つ目は，業務機能とデータの関係を明示すること。データ設計で作成する論理データ・モデルと不整合がないようにする。
三つ目は，業務のライフサイクルを明確に示すこと。業務の開始や終了が見当たらない場合，他システムとの連携や例外処理，代替フローなどを見落としていることが多い。もしこれらがある場合は，発生条件や分岐条件を確認し，明記する。
画面操作方法まで盛り込まない
業務の流れを明確にしたら，次に個々の機能の設計に移る（(2)ユースケース分析）。ここでは各業務機能に対するアクター（人や組織）とシステムの責任分担を明確にする。業務流れ図で定義した業務機能の最小単位を「ユースケース・シナリオ」として作成することになる。
アクターとシステムの振る舞いを文章で表すユースケース・シナリオは，個条書きで簡潔に示すようにしたい。システムの内部仕様や画面操作，画面内のボタン名，タブ名をユースケース・シナリオに記述する書き方もあるが，これは混乱のもとだ。画面の仕様変更を常に反映させる必要があるだけでなく，不整合があったときに確認作業に追われることになりかねない。
ユースケース・シナリオの作成に当たっては，読み手が誤解するような，あいまいな表現や同音異義語の使用も避ける。要件定義のときに作成した業務用語集を逐一参照しながら，作業を進める。データ設計で作成する論理データ・モデルとの間で整合性を保つことも忘れない。
業務を遂行する上での制約や規約は「業務ルール一覧」としてまとめておく。業務ルールには重要なビジネスロジックが含まれることが多い。ユーザーと十分に擦り合わせた上で，記述するように心掛けたい。
ユーザーの合意を得たユースケース・シナリオは，アプリケーションに実装する機能として「アプリケーション機能一覧」に追記する。これは要件定義で作った機能一覧の精度を上げ，ユーザーの視点から開発者の視点に書き替えていく作業になる。一つひとつの機能は，ユースケース・シナリオのシステム行（システム側が担当する処理）に着目して抽出する。
