設計の落としどころ （前編）〜J2EE金融基幹システムの構築現場から〜：開発現場の天国と地獄（5）（3/4 ページ）

[佐藤大輔，オープントーン]

（3）細設計、実装詳

実装者は「プログラムを書く人」か？

　効率的なソフトウェア開発工程の条件の1つとして、多くの現場で理想として挙がるのが、「揺るぎなき要件に基づいた厳格な設計」、そして「効率的なコーディング作業」です。確立された設計に基づいてコードを記述するだけなら「ツールでできる」というMDA（Model Driven Architecture）の思想を多くのMDA検討の場で聞いてきました。

　しかし、実際には、実装者の役割はプログラムを書くだけにとどまりません。もっと広いからこそMDAより効率よく開発ができるのです。

　例えば、点と点として置かれているそれぞれの（機能の）仕様を設計書で厳密に定めなくても、実装者はそれらの機能を作成することができます。極論をいえば、画面とデータベースの項目をひも付けて実装者に渡してあげれば、システムの規模によってはコレだけで、開発作業が進み始めるでしょう。しかし、MDAでは振る舞いを厳格に決めなければなりません。機械に設計を伝える以上そこに想像力が働くことはなく、仕様と実装は、実は表し方を変えただけの同じものでなければなりません。

　実装者が持つ想像力のおかげで「100％定義しなくても作れる」ことは非常に重要な意味を持ちます。MDAが進歩したとはいうものの、現在の動画CG生成ツールのように、基点と終点を定義してあげればおよそ最適パターンを選択し自動生成するという域にはまだ達していません。

図4 「実装者も設計を埋めてくれる」図

　では、設計者は何をすべきなのでしょうか？ 可能な限り精密で厳格な設計書を描くことではないのはいま述べたとおりです。また、そのように設計できたとしても、限りなく精密な設計は、限りなくコーディングに近くなり、つまるところ第1回「“完璧な設計”がプロジェクトを失敗に導く！？」のように、実装者の負担を設計者に乗せるにすぎないという事態を招きます。

　もちろん、仕様の重要な「点」は一通り決める必要があります。しかし、その「点」には2種類あります。

　1つは統一的な振る舞いです。更新時に確認画面があるのか、検索時は子画面でするのか戻るはどこに戻るのか……といった統一されたシステム全体の動きの定義です。もう1つは個々の機能ごとの振る舞いです。どの項目がDBのどのカラムと関係し、どんなロジックが関係してどんなチェックが行われるのか、などです。

　しかし、それ以外の部分、つまり、入力値の型は合っているか、そのチェックは、ロジックに入る前に行うのか、そもそも、データベースにつながらないときにプログラム何行目でエラーにするのか……、そういった情報は「設計しない」「実装者に任せる」という選択肢を取ることによりチーム全体の負荷を幅広く分散することが可能です。

　品質の平準化やコードの統一性をいえば、プログラムの1行1行まで設計してある方が効率が良いことになります。ただし、そこには効率とのトレードオフがあります。もちろん、コードの標準を制定し、プロトタイプで「大体の書き方」を示唆することが必要です。さらにチェックスタイルのようなツールを使い、細かいレベルの整形も行う必要があります。逆に、これ以上は実装者の能力に任せてもいいともいえます。むしろ、そこを設計者が背負うと、設計者には従来実装者が背負っていた負荷がそっくり降りかかることになるのです。

なぜMDAだけではシステムの構築は無理なのか

　仮に、実装者を「コードを書く人」と定義した場合、彼らの役割はMDAで置き換えることができるようになります。しかし、実装者がコードを「いわれたまま書けばいい」状況にするためには非常に工数の掛かる精密な設計が必要です。想像力のないMDAというツールに任せて実装が完了するようにするためには、完璧（かんぺき）に設計を行う必要があるのです。完璧な設計を実現するのに費やす工数を考えると「コードを書いた方が早い」という結論に落ち着くわけです。

図5 「MDAは設計者の負荷でしかない」図