 |
||||||||||
|
||||||||||
| 前のページ 1 2 3 次のページ | ||||||||||
|
||||||||||
| 業務フロー | ||||||||||
|
業務フローとは、該当業務に関係する担当者やものに加え、手続きの順序やタイミングとチェックポイントが表現されているものを指します。 |
||||||||||
| 業務フローの必要性 | ||||||||||
|
業務フローの必要性には、大きく分けて以下の3点があります。
表3：業務フローの必要性 内部統制の観点から、その重要性がさらに増していることは周知のとおりです。 |
||||||||||
| システム開発での成果物 | ||||||||||
|
システム担当者が書いた業務フローでは、システムやソフトウェアの使い方に重点が置かれ、業務の流れが読み取れないケースが見受けられます。ユーザ側が本来の目的が込められている業務フローを書くことが可能であればよいのですが、開発者側にもそれを検証し、ブラッシュアップするスキルが必要です。 つまり業務SEであるのなら、少なくとも対象としている業務分野に精通しようとする姿勢が求められます。このスキルがあってはじめてユーザインタビューが行えると筆者は考えます。この点を「コミュニケーション能力」という言葉でひとくくりにしてはいけません。 また、業務フローで表現する粒度については、非常に難しい問題です。1つ1つのプロセスをどのレベルまでドリルダウンするか、開発スピードを考えると筆者も非常に頭が痛くなります。決定的な解決策はありませんが、筆者は、次のように心がけています。 適用業務を作業単位にブレークダウンしたとしても、個々の作業にも必ず達成しなければならない目的があります。その目的が明確になるように分割を行い、その分割単位をひとつのプロセスとして定義するようにします。 例えば「伝票を起票する際、明細行を埋めるために複数の情報を閲覧する」というプロセスがあったとしても、それは伝票を起票するという目的を達成するための手段だととらえます。このため「ある作業が持つ目的が達成されるまで」を1つのプロセスの最小単位と位置づけるよう意識しています。 |
||||||||||
| DFD（データフローダイアグラム） | ||||||||||
|
DFDは魅力的な階層構造を持ち、順次詳細化を行っていくことにに適した技法です（図1）。  図1：DFDの階層化イメージ これは1970年代にトム・デマルコらにより構造化分析が提唱されて以来、広く活用されてきた技法ですが、現在でも、例えば日本IBMが適用しているDOAでは、DFDを中心とした分析・設計を行っていくプロセスを採用しています。 筆者がはじめて関わった開発現場では、客先のプロジェクトリーダーが極端にDFDを推奨していたこともあり、その扱いはまさに「DFD＝万能選手」といった感がありました。筆者も当時はそのような幻想を持っていましたし、現在でも魅力的なダイアグラムであることに変わりはありませんが、その役割はある程度限定した方がよいと考えています。 |
||||||||||
| DFDでどこまで描くのか | ||||||||||
|
一般的に詳細化のレベルについては「データフロー、データストア、プロセスが明確になるレベルまで」といった説明が行われます。そして、最下層のDFDをそれぞれ、データストア記述書、データフロー記述書、プロセス記述書といった資料で補完するのが伝統的な手法です。なおDFDで用いる記号については図2を参照してください。  図2：DFDで用いる記号 しかし、この手法では多量に工数がかかり、さらに大量のドキュメントが発生します。また、DFDではプロセスの順序性や条件分岐は表現しませんが、レベルが下位になるほど、そのような点を表現したくなってしまうものです。そして何をもって「データやプロセスが明確なレベル」と判断するのかが、曖昧な点もあるのです。 このため現在では、DFDの役割について下記のように考えることができます。
表4：DFDの役割 この表4にしたがうことで、DFDで表現するのは業務領域単位までとし、階層化は第2レベルもしくは複雑な業務領域での第3レベルまでが妥当だと感じています。 |
||||||||||
|
前のページ 1 2 3 次のページ |
||||||||||
|
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
-
-
連載
