並列開発について2

前回に補足です。
単に「並列開発」というと色々なイメージが生まれてしまうので、とりあえず「UIや業務ロジックなど領域でシステムを分割して扱える上、（ある程度の連携は必要になるが）開発担当者もチームも分けて開発を進めるようにする」といった意味で「並列開発」という言葉を使うことにします。

さらに前回の「並列開発をできるようにしておくべき理由」に1つ追加します。

• UIを決める際、どうでも良い所にこだわり続けるヤツは必ずいる。

・・・愚痴なんですけどね。

それはさておき、続きを少し。

このアプローチの最大のメリットは、「メンバー1人あたりの責任領域が狭められる」という点です。
システムは、UIと業務ロジックだけで出来ている訳ではなく、インフラストラクチャやRDBなど多種多様なテクノロジの集合です。それら全てに対して全知全能である事は（少なくとも私のようなボンクラには）不可能です。

そのため、「メンバーそれぞれが自分の得意分野と思う領域に専念しながらシステムを開発していく方法」というアプローチがあると良いな、と。今回、この並列開発と呼んでいるアプローチを考える中で、そういった願望的な側面も少なからずあると思います。

この願望とアプローチがマッチすると意外な効率化がはかられるのではないか、と思います。
Jakarta Strutsには詳しいけどRDBについてはあまり詳しくなく、そのせいで非常に巨大な内部表を作る使ったクエリを作っていた、なんてよくある話です。それが世に出る前に発見できれば良いですが、単体テスト通過後、きちんとしたパフォーマンス・テストができなかったりすると、改善されないまま出荷される事になってしまいます。
その場合、パフォーマンス・テストをしなかった点がまず責められますが、次いで開発者が吊るし上げを食らったりしますよね。Strutsに精通しつつ、かつRDBにも精通せよと言うのは簡単ですが、実践するのはなかなかきつそうです。

であれば、RDBに精通しているメンバーがいるならそのメンバーにクエリを全部作ってもらうなり、クエリのソースレビューをしてもらうなり、できると手戻りはずいぶん減るんではないかな、と。RDBに精通しているメンバーがいなければ、RDBに精通したいメンバーを専任することで、そのメンバーは自分が知りたいことをそこで学べ、製品の品質もまた安心できるものになる可能性が上がるのではないでしょうか。