2007年6月12日の日本経済新聞朝刊に「NTTデータは十一日，情報システム開発作業の自動化に本格的に取り組むと発表した。コンピューターを動かすプログラムを設計図から自動作成する支援ソフトを自社で導入，不具合を半減させる計画。全日本空輸やNTT東西地域会社など産業界で大規模システムの障害が頻発する中，人手をかけないことでシステムの品質を高める。NECや富士通なども開発の自動化に着手しており，今後は他のシステム大手にも広がりそうだ」という記事が載った。

　これだけ読むと，ソースコード自動生成のイメージが強いが，業務アプリケーション分野で，100％ソースコードを自動生成することなど，そもそも不可能に近い。このNTTデータの取り組みも，決してソースコード自動生成を狙っているわけではない。その本質は，極めて泥臭い，しかも地道な，情報システム開発における「業務プロセスの自動化」なのだ。

すべてのモデルをリポジトリで管理

　NTTデータの取り組みは，ビジネスモデリング，要求定義，外部設計，内部設計，実装，単体テストの各工程で「自動化できるプロセスをなるべく自動化する」というもの。言うまでもないが，システム開発の工程で大部分を占めるのは，仕様書などのドキュメント作成とUML（Unified Modeling Language）やERD（Entity Relationship Diagram）などのモデル作成で，「コーディング自体は2割程度に過ぎない」（NTTデータ）。

　そこで，地道な業務プロセス分析により，自動生成できるモデルと人手で作成するモデルを切り分け，自動生成できるモデルは（別のモデルから）自動的に生成できるようにした。そしてWordやExcelなどのドキュメント類は，UMLやERDなどのモデルからすべて自動生成できるようにした。そのためのインフラ・ソフトとして，独ikv++の「medini」を使う。

　モデルを自動生成したり，モデルからドキュメントを自動生成したりするには，モデルを“コンピュータが解釈できる”ようにしなければならない。そこで，まず同社のWebシステム開発用方法論「TERASOLUNA」で決められたすべてのモデルの「構造」を，OMG（Object Management Group）の「MOF（Meta-Object Facility）」で定義して，mediniが解釈できるようにした。

　人手で作成するモデルについては，モデリング・ツールで作成してmediniのリポジトリに格納する。モデリング・ツールとしては，ERモデリング・ツール「ER/Studio」を利用。なお，モデリング以外のツールとしては，「Eclipse」やNTTデータが自社開発した「Flexite IDE」（バージョン管理などを実行するリポジトリ管理ツール）を利用する。

　人手で作成したモデルから別のモデルを自動生成できる場合は，可能な範囲で自動生成する。とはいえ，自動生成できるモデルはそんなに多くはない。

　あたりまえだが，最上流のビジネスモデリング工程のモデル（「ビジネスプロセスモデル」や「ビジネスルールモデル」などUMLを拡張したモデル）はすべて人手で作る。要求定義の工程では，「概要画面遷移モデル」を「ビジネスプロセスモデル」から部分的に自動生成するが，「ユースケースモデル」「概念データモデル」「帳票イメージ」は人手で作成。

　外部設計の工程では，「論理画面定義モデル」と「詳細画面遷移モデル」を「概要画面遷移モデル」から，「論理データモデル」を「概念データモデル」から部分的に自動生成するほか，「エンティティモデル」を「論理データモデル」から100％自動生成する。ただし，「セッションモデル」「コントロールモデル」「共通処理モデル」「コードリストモデル」「メッセージモデル」「帳票仕様」は人手で厳密に作成しなければならない。内部設計の工程では，「詳細クラスモデル」「SQLモデル」「物理データモデル」を部分的に自動生成し，「共通詳細クラスモデル」を人手で作成する。

　TERASOLUNAで決められた「ユースケース図」「ユースケース記述」「詳細画面遷移図」「詳細画面仕様書」「CRUD（Create, Read, Update, Delete）マトリクス」「コード一覧表」「詳細クラス図」「詳細クラス仕様書」「SQL仕様書」などのドキュメントは，モデルからすべて自動生成する。ソースコードやテスト用コードも，同社のJavaフレームワーク用の典型的なコードを，モデルから可能な範囲で自動生成する（コードはEclipse JET＝Java Emitter Templatesを使って生成）。「ドキュメントとソースコートの整合性が取れているため，開発後の保守にも役立つ」（NTTデータ）。

　仕様変更が発生して上流工程のモデルを修正すると，下流のモデル（およびそこから生成されるコードやドキュメント）に修正が自動的に反映される。下流工程で，修正が一意に決まらない場合は，人間が選択できるようになっている。「仕様変更の自動反映はメリットが非常に大きいと考えている」（同）。OMGの「OCL（Object Constraint Language）」で制約条件を記述すれば，影響範囲を調べることも可能だ。例えば，テーブルのカラムの桁数を変えたときの影響範囲を調査できる。

急がれるシステム開発の業務プロセス改革

　この仕組みは現在，要員数が数十名で期間が半年～9カ月程度の，3つの小規模なWebシステム開発プロジェクトに適用している（いずれも公共分野）。3つのプロジェクトで問題点を洗い出した後，2010年度までに，全社で50件のWeb系開発プロジェクトに適用する計画。Web系の開発プロジェクト数は年間200程度なので，その1/4にこの仕組みを適用することになる。同社では，2～3割の生産性向上とドキュメント／コードの品質向上を見込んでおり，プロジェクトマネジメント（リポジトリに格納されたモデルを使った進ちょく管理や見積もりなど）にも適用していきたいという。結合テストなど，適用できる工程も広げる。

　NTTデータの仕組みは極めて「現実的」なもので，（似たところもあるが）OMGの「MDA（Model Driven Architecture）」とも，マイクロソフトの「Software Factories」とも異なる。強いて言えば，1980年代のCASE（Computer Aided Software Engineering）に近い。「ソフト開発のドキュメントやモデルは複雑なので，その処理には多くのマシンリソースが必要になる。CASEの頃はそれがなかったが，ようやく可能になった」（NTTデータ）。

　相変わらず，システム障害がなくならない。そうした中，ITベンダーにもシステム部門にも，今こそ生産性や品質を向上させる業務プロセスの自動化や改革が求められている。そのための一つとして，NTTデータの取り組みは注目に値する。