 |
|
|
| 前のページ 1 2 3 4 次のページ
|
|
| 開発現場の視点でみるDOA
|
業務の分析はDOAで行われていますが、そのDOAがどのくらい開発に影響を与えているのでしょうか。
図1：DOAの長所と問題点 （画像をクリックすると別ウィンドウに拡大図を表示します）
DOAは業務で使用するデータ項目とその性質を洗い出すことにはじまり、不要なデータ項目や重複したデータ項目を排除し、必要なデータ項目を業務の流れで整理し、それに基づいてシステムを設計する開発手法（technique）です。
- 必要となるデータ項目を洗い出すことで、業務内容をもれなく把握することができる
- 必要なデータとその流れを可視化することで、業務内容を視覚的に理解することができるため、業務に携わるユーザからシステム開発のSE、PM、管理者といった関係者全員の共通の認識を得ることが可能となる
- データをプロセスから独立したものとして管理することで、システムの柔軟性を高め、業務内容の変更による時間・費用を圧縮することが可能である。また、業務内容をもれなく把握することが可能なので、現時点での業務分析、システムが抱える問題点などを目に見える形で捉えることもできる
表1：DOAのメリット
これらの長所を活かすために必要な、いくつかの工夫や注意すべき点は以下のようになります。
- ビジネスの目標（システム化の範囲）を明らかにした上で、意味のあるDOAのレベル（個別プロジェクト、部内、全体）でモデリングする
- プロセスとデータの名前付けルールを確立する
- ユーザが理解できる標準的な言葉で表現する
表2：DOAの工夫・注意点
|
| 現場で出会うドキュメントの問題点
|
筆者が関わっている現場では以下のようなことが問題になっています。
1つ目がドキュメントに関する問題です。
- ドキュメントの内容とシステムの処理内容とが異なる
- データ項目の修正や追加、更新方法の変更など、システム変更を行う際は必ず影響調査を事前に行います。しかし、データの流れが精査されていない「テーブルの関係を示しただけ」のER図や、大雑把な内容でしか書かれていない業務フローしか存在しないケースでは、仕様上把握しきれない部分がでてきて、実際のプログラムと適用業務との間に差異が生じることがあります。また、ER図や業務フローといったドキュメントがないシステムでは、ソースをひとつひとつ解析して業務を理解しなければならない事態となります。
- ドキュメントが活用できない
- もちろん、支障のあるドキュメントしか存在しない例が多いわけではなく、ほとんどのケースは技術スタッフのDA（データ管理者）が精査し作成したER図と、業務に携わるユーザが作成した業務フローの2つが完備してあります。しかし、データ定義の変更が後の工程で行われれば、プログラムの仕様変更が発生します。こうした場合、ER図を見ただけではシステムへの影響範囲がわかりにくく、結局ソース解析を行ってデータ関係の確認をしなければなりません。
表3：ドキュメントに関する問題
|
| 現場で出会うシステム改修の問題点
|
さらにシステムの改修に関する問題も発生しています。
- プログラム内容の複雑化
- 現在でも10数年前に作られたプログラムが稼働し続けています。古くから稼働しているシステムは、正規化されていないデータ体系を基に作成されていることが多く、そういった場合に、業務の変更や追加はすべてプログラム修正のみで対応しています。このように不安定な情報基盤の上に、何層にもまたがって処理の修正・追加を行ってきたため、とても複雑なプログラムがシステムの中核に多数存在しています。さらに複雑さを回避するために設けられた新たな処理が、プログラムを増加させる要因の1つになっています。同様に、業務の引き継ぎ資料は、純粋に業務内容を記載したものではなく、その複雑な処理の膨大な解説書になってしまい、効率性を著しく損ねる結果を招いています。
表4：システムの改修に関する問題
|
前のページ 1 2 3 4 次のページ
|
|
|
|
|
著者プロフィール
システムズ・デザイン株式会社 DOA推進ワークショップ
ビジネス解析方法論であるDOAと、開発プロセス方法論であるRAD、ウォーターフォール、UPなどを現場の最前線で適用している技術者を中心に開設した、sdc独自のワークショップ。PDCAサイクルを回して、さらなる進化と「確かなモデリング∧確かな開発プロセス→いい仕事」の可能性を追求する。
|
|
|
|
|
|
