開発ドキュメント体系と業務フロー

基本設計工程のドキュメント

   要求分析フェーズは後回しとし、基本設計フェーズのドキュメントから説明したいと思います。業務システムの設計は基本設計（外部設計とも言う）で骨組みを決め、詳細設計（内部設計）で肉付けを行います。

   基本設計がユーザとの仕様確認、詳細設計はプログラマに対する指示書という役割が強いとも言えます。ただし、基本設計と詳細設計は別物ではなく、詳細設計は基本設計をベースに肉付けを行います。

   ここでのポイントは、リバースしないことです。基本設計をベースにして詳細設計作業を行うのですが、その結果基本設計の内容が変更になったとしても後戻りしません。詳細設計は、基本設計を"踏み台"にするものと位置づけており、詳細設計書が完成したあかつきには基本設計書は顧みないことにしています。

業務フロー

   今回は基本設計工程における標準ドキュメントの中から、「業務フロー」について説明しましょう。業務システムを構築する際は、ユーザの業務の流れを正確に把握する必要があります。流れをイメージしないで断片の組み合わせで作成されたアプリケーションは、運用に大きな落とし穴がある場合が多いからです。業務に関して自分の頭を整理し、ユーザと確認し、プロジェクトメンバーにも伝える、そういう重要な役割を持ったドキュメントが業務フローなのです。

   図2は、DUNGEON様式の「業務フロー」の記入例です。表紙、記号説明に続いて、業務単位にシートを分割して業務フローを記述していきます。以下、業務フロー作成時のポイントについていくつか解説しましょう。

担当部門（ロケーション）

   業務フローは、業務担当者の役割分担が明確にわかるようにします。そのため、業務処理の行われる場所を欄で分け、業務の流れに沿って記載します。図2の例では、営業とユーザに欄を分けて、見積依頼から見積、見積書出力、再見積、受注、注文請書出力までの流れを上から順番に記載しています。

主なデータ

   図2の例では、左端に主なデータ欄を用意しています。業務フローの書き方も、"データを書く派"と"データを書かない派"がいます。ユーザ自身が業務フローを書くような場合は、データを書かないケースが多いでしょう。しかし、我々のような開発サイドが業務フローを作成する場合は、主なデータを記載した方がわかりやすいと思います。

   入力処理でどのようなデータができるか、どのテーブルから照会画面や帳票出力のデータを取り出すかなどが明確に理解できるからです。その際に記載する対象のテーブルは主要なものだけでかまいません。業務の流れをデータの流れと対比させて見る目的さえ達成できれば十分です。