MDAの可能性
すでに死に体とすら言われているMDA(Model Driven Architecture)ですが、日本の受託開発プロジェクトの"問題"を解決する特効薬だと個人的には思っています。
膨らむ仕様
"問題"にはいろいろありますが、その一つに「仕様がどんどん膨らんで納期/予算をオーバーしてしまう」というのがあります。その現象(仕様ビッグバンとでも呼びましょうか)が発生する典型的なストーリーは次のような感じです。
従来の受託開発ストーリー
1. 要求があいまいな状態で見積もりを要求される
2. 開発者が不完全な情報(顧客の業界に関する基礎知識のみ、それすらないこともしばしば)を元に見積→受注→設計
3. レビュー(これがないこともしばしば)しても顧客が不備(顧客企業内のローカルルールなど)を指摘しきれない
- 自社内のローカルルール自体無い、もしくはバラバラでその社内調整が始まる場合もしばしば
4. 現時点で判明している仕様を元にシステムを作成する
5. できたものを見て顧客が不備に気づく、または新しい機能を思いつく
6. 4,5のループ
- 終了条件：顧客が納得するまで＝無限ループ
- 無限ループ中に状況が変わり、新しい仕様が発生することもしばしば
対策あれこれ
仕様ビッグバンが"問題"であることは皆分かっています。そしてそれが上記の流れで発生することも分かっています。そのため、「ユーザーがきちんと要求定義できるようにしよう」「工程ごとに分割契約しましょう」「仕様が変わる/増えるのを受け入れられる仕組み(＝アジャイルな開発手法)を作りましょう」etc...いろいろな対策が講じられ、実行されたりされなかったり(wしています。
これらはどれも「顧客から出される複雑な要求を具現化する」という点で共通しています。それはもちろん間違いではありません。顧客が満足するものを提供することはビジネスにおける絶対的な正義です。
しかし、顧客を完璧に満足させようとして、かえって顧客に迷惑をかけていないでしょうか？複雑なものはどう作ったって複雑で、失敗するリスクは高いものです。割り切って、単純なシステムを構築するという選択肢は無いものでしょうか？
simple is a best
そこでMDAです。私が理想とするMDAによる受託開発の流れは次の通りです。
MDAによる受託開発ストーリー
1. 要求があいまいな状態で見積もりを要求される
2. システム化対象業務で現在使われている帳票をもらい、その中に含まれている項目数等から見積もる
3. "設計"とは、あるデータを誰がいつどうするか(create/update/read/delete)を明らかにすること
4. モデル化→自動生成
新規開発としては以上で終わり。ビジネスロジックの実装は厳選し、基本的に実装しない。
ビジネスロジックはあいまいで、複雑で、変化しやすく、システム化するのに向いていません。それを承知の上で、そうしなければならない必然性があり、かつ十分な予算が確保できるのなら、今までと同様の開発を行うのもいいですが、そうでない場合はこんなアプローチも「アリ」じゃないでしょうか？
