【2】DOAの課題
ＤＯＡが認知され、大規模なコンピュータシステムの開発に適用されてくると、課題が顕在化してきました。
この点、まずは前項で引用した記事の続きを見てみましょう。
■システム開発技術の変遷とＤＯＡの歴史
ＤＯＡ＋コンソーシアム「システム開発技術の変遷とＤＯＡの歴史」 より引用（※）
…（略）…
ＤＯＡが認知され、データモデリングが行われたが、多くは個別アプリケーションＤＢのテーブル設計 を目的とするものであった。ＣＡＳＥツールが登場し開発の生産性アップが図られたが、アプリケーショ ン間のデータの共用／重複などは見過ごされ、孤島システムが乱立する結果となった。実装独立のドキュ メントは用意されず、ビジネスやＩＴの変化に対応する保守は、ソフトウエア実体に対する差分メンテや 温泉旅館別館建て増し方式で行われ、属人化・暗黙知化が進行した。
※DOA＋コンソーシアムのサイト（http://www.doaplus.com/html/whatsdoa_01.html）
の閉鎖に伴い、引用記事はこちらをご覧ください。
上のコラムの中で使われている略語については、次の様に補足しておきます。
- ＣＡＳＥツール
“Computer Aided Software Engineering”の略（ケース・ツールと呼ばれます）。それまで紙の手書きするなどしていたシステムの設計書を、各設計書間の整合性も管理しながら作成できるコンピュータシステム のことです。
- ＩＴ
“Information Technology”の略（アイ・ティーと呼ばれます）。“情報技術”と訳されます。コンピュータを含めた、情報の処理や通信技術の総称です。
課題１：ＤＯＡはお絵かき方法なのか？
ＤＯＡの考え方は「データベースを中核に据えて、各業務システムがこれを共有する」ことです。このため 「では、ある業務システムが使用するデータが記録されたテーブルは、データベース内のどこにあるのか」が分かるような“地図（データ・マップ）”が必要になってきます。そして、この地図の上に、どの様に業務データ を配置するかを設計・表記する手順のことを、データ・モデリングと呼んでいます。
ところが、ここで問題となったのが、「データ・モデリングは、設計思考手順なのか、表記作業手順なのか」 です。
私の知る限り、多くのシステム開発の現場では、後者のみを重視したデータ・モデリングを行ってきました。 そのため、前述のＲＤＢを使用したシステムでは、この地図のことを“ＥＲ図(※)”と呼んでいますが、このＥＲ図に「どういう設計思想で作成されたか分からない様なデータ・テーブル」が、ただ漫然と記載されたものがいくつも作成されていきました。また、この表記重視の考え方から、「では、データ・テーブルが少なければ、ＥＲ図を描く必要もないし、データ・モデリングも必要ない」といった考え方も出て、小規模なシステム開発では“ＤＯＡ不要論”が大勢です。
※ＥＲ図…“Entity-Relationship Diagram”の略。ＲＤＢ内の（複数の）データ・テーブルと、それらの関係 が記述された図面のことです。この表記方法には、いくつかの流派があります。
課題２：他の担当と調整できるのか？
大規模なシステム開発では、多くの場合、複数の開発チームで構成され、さらに、各チームのシステム・エンジニアは（異なる開発会社から来ているため）利害関係が対立することも少なくありません。
こうなると「あるデータの“データベース上の持ち方”が、あるチームには都合が良いが、他のチームには都合が悪い（ので、このままだと開発コストが増加してしまう）」といった事態が発生し、調整する時間もないまま、「では、別々に持ちましょう」という結論になってしまいます。（これが、上記の記事の“（データが共有されない）孤島システム”になります）
課題３：全部プログラムで個別に作られてしまわないか？
ＤＢＭＳでは、データ・テーブルを保管するだけでなく、データ・テーブル間の関係のチェックも行う機能を提供しています。
たとえば、「注文テーブルに注文データを登録する際に、発注顧客の管理番号は、顧客テーブルにある顧客番号になければならない」といったチェックです。こうしたチェックを、共有されるデータベースで行えれば、 各業務プログラムは同じチェックをする必要はなくなります。（こうしたチェック関係は、ＥＲ図に記載されま す）
ところが、こうしたチェックを「自分の作成するプログラムで行いたい」と考えるプログラマは少なくありません。そうすると、こうしたチェック関係すらも、ＥＲ図には記載されなくなってしまいます。