設計チームの役割って？
システム開発プロジェクトでは，一般的に「設計チーム」と「実装チーム」に分かれて作業を進めることが多い。この「設計」と「実装」の切り分け，これが非常に難しく，けれどプロジェクトの生死を決める最も重要な要素だ。
- 設計チームはどこまで設計とするのか？* 実装チームはどこまで実装とするのか？
この線引きは，人によって様々である。全く同じ線引きをする人を見つけることは困難を極める。というか，「境界線はここだよね？」「俺もそう思う，全く一緒だよ」なんて会話を，少なくとも僕は今まで聞いたことがない。
ただし，設計チームも実装チームも，「システムを構築すること」という目的は一緒である。そのことを忘れてはいけない。特に設計チームに配属された人は，だ。
僕が考える実装作業は，設計チームが最終的に「あるアーキテクチャで規定された型」に従って落とし込んだ仕様を，プログラム言語を使って実際に記述することだ。Javaを代表とする今日のプログラム言語は比較的業務処理を簡潔に記述することができるため（アーキテクチャの質に依存するけど），実装者の作業は極端な話「単純」であることが理想である。もちろん現実はそんなに甘くないので，クールなアーキテクチャの指導の下にコーディングを進めていくことにはなる。
これを踏まえると，設計とは「業務をあるアーキテクチャ上で表現する」ことであり，決して業務分析や業務理解に止まるものではない。ましてや，画面やDBなどの外部設計を行うだけで，業務の理解は二の次，なんてことでもない。
業務分析と業務理解は，ぶっちゃけ実装者が顧客に聞けば得られるものであり，それだけしかやってくれない設計チームなど必要はない。また，画面設計を上っ面だけで行い，ろくに業務の把握をしない設計チームも，これまた必要ない。「そんな設計チームなんてないよ」と思うだろうが，これは１年以内に僕が実体験したものであり，まさに真実なのだ。
Unified Processでは，業務分析を行っている間，アーキテクトが着々アーキテクチャを「業務分析の結果をもらいながら」決めていく。そして，業務分析の結果から導き出されるシステムの仕様を，アーキテクチャに当てはめながら業務内容をシステム的な内容に落とし込んでいく。もちろん，業務内容にそぐわないアーキテクチャはまずいので，アーキテクチャも変化させていきながら最適解を見つけていく。
アーキテクチャは開発チームだけのものではない。顧客も同時に理解を深めていってもらい，業務内容がシステム内でどのように表現されるのかについて共通の認識を持ってもらうことが重要だ。いつまでも開発ベンダーが顧客には付き合ってはくれない。ベンダーが離れても良いように，少なくとも顧客の情報部門はシステムのアーキテクチャを理解すべきであり，共通の言葉でベンダーと会話することが理想である。これは，保守のコストに直結する。
つまり，設計チームは顧客に対して，「いかにして業務をシステムのアーキテクチャに当てはめたのか」について示す必要があり，そしてアーキテクチャに落とし込むために必要となった業務内容の整理を，成果として残す必要があるのだ。
以上の内容を踏まえると，設計チームが外部設計しかやらなかったり，業務把握を怠ったり，業務分析で作業が終わってしまうことは，ありえない。
「結局実装チームが最も顧客の業務に詳しくなった」という結果になった時点で，プロジェクトは失敗だと言っても言い過ぎではないのだ。
