 |
||||||||||||
|
||||||||||||
| 前のページ 1 2 3 4 | ||||||||||||
|
||||||||||||
| DOAの認識を妨げないために | ||||||||||||
|
DOAの一般的解釈を考えるた場合、筆者をはじめとするSE・プログラマが持つ苦悩は、直接DOAの認識を妨げているように思えます。 特に以下の3つの点に注意する必要があります。 |
||||||||||||
| ドキュメント | ||||||||||||
|
DOAを採用したシステム開発が行われた場合、業務をもれなく分析した成果物であるドキュメントが作成されます。 そのドキュメントの品質を保つには、その後にシステム改修が行われた場合、その内容を追加更新していかなければなりません。しかし、以下のような事態が1回でも発生すると、当初の品質は保証できなくなります。
表6：ドキュメント作成時に避けるべき項目 もちろんドキュメントを残さないということは論外ですが、ドキュメントを残したとしても最終的にはDOAの目指す方向からかけ離れた結果になってしまいます。 |
||||||||||||
| システムの改修 | ||||||||||||
|
業務の分析を行い、データの流れを精査しても、諸事情によりすべてを反映することができないことがあります。さらに、すべてのシステムにDAが関われないため、前述のようなドキュメントの問題が起こり得ます。 これは、実際に瑕疵のあるドキュメントが残っているところからも推測できます。 そのため、つじつま合わせの処理が多発し、業務内容の変更などにかかる時間や費用を適切に逓減させることができていません。 |
||||||||||||
| クライアントの意識 | ||||||||||||
|
筆者のようなSEやプログラマに作業は、常にシステム担当者が窓口となって業務を進められます。よって、DAが分析したことや問題提起としてあげたことをシステム担当者がそのまま認識できなければ、筆者らには一切伝わりません。 これは、業務内容を共通の認識として捉えることの妨げになっている可能性があります。 |
||||||||||||
| DOAを推進していくためには | ||||||||||||
|
実際の現場でDOAが普及しきれていない原因の1つとして、筆者らはもちろん、クライアントも含めた開発に携わる人たちの意識の持ち方に問題があるのではないでしょうか。 筆者をはじめとしたSEやプログラマの感じている「DOAに対する意識」は図3のグラフのようにあらわすことができます。  図3：DOAに対する意識 DOAを意識していくうえで大切なことは、以下の2つに集約することができます。
表7：DOAを意識していくうえで大切なこと これらを繰り返し行うことで、現場にDOAが根付いて行くはずです。 上流、下流工程関係なく、現場の人間1人1人がDOAを「意識」することが不可欠だということです。また今回の記事を執筆したことは、筆者たちがDOAを振り返り、DOAを「意識」するよい機会になったことを付け加えておきます。 |
||||||||||||
|
前のページ 1 2 3 4 |
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
-
-
連載
