http://martinfowler.com/bliki/PreferFunctionalStaffOrganization.html

私がソフトウェア業界に身を置いて以来、 機能別組織か技術別組織かという議論は尽きることがない。 こういった議論はプロジェクト内、いや、ITに関わる組織の至るところで巻き起こっている。 両者ともに理に適った根拠があるため、議論はいつも絶えない。 実際、どちらが優れているかなんて判断する術はないのだ。

とは言うものの、私はやっぱり機能別組織が好きだ。 もちろん例外はあるだろうし、正しい道は常にひとつとは限らない。 だが私は、過剰なまでに機能指向的な方を選ぶのがよいと思っている。

こちらを選ばざるを得ないのは、 私はビジネス価値にあわせてアプリケーションチームを揃えているからだ。 というのも、Conway’s Law{は避けられないし、アプリケーション境界は社会的なものだからだ。 ソフトウェア開発の醍醐味はソフトウェアをお客様に提供することにある。 故に、組織はそれを反映したものでなければならない——技術を深追いするようなチームではなく、ビジネス価値を提供することにフォーカスした従順なチームが必要だ。

技術別組織の根本的な論拠は生産性にある。システムを重複して持つのはムダであるし、人々は特定の仕事に集中したほうが効率的であるというわけだ。私は機能別組織で重複が起きないといっているわけではない、ただそんなに非効率になるかどうかは疑問だと思っているだけだ。資本家の競争による重複のムダよりは、中央集権化された計画経済のほうが効率的だ信じる人はたくさんいたわけだし。マクロ経済とソフトウェア開発を一からげに議論しようとしているわけではないよ。ただ、共通な点はあると思っている。それは、人のモチベーションだ。ビジネス上の問題を解くという目標から人々を離してまったら、いろんな要素がからみあってきて、技術別組織が解決しようとした重複のムダよりはるかにひどい非効率を招いてしまう。

機能別組織の必然性は他にもある。 ビジネスユニットはアプリケーションを必要とするが、 もしアプリケーションがなければ、彼らは自分らで作ることになる。 そうすると、自ずと機能別組織となるのである。 つまり、ビジネスユニットは資本と権力をもっているのだ——これはエンタープライズアーキテクチャの流行り廃りと本質的に同じである。

以上のことから、組織を作る際は機能別にしたほうがよいだろう。 ただし、盲目的にこの方法を採用しろということではない。 作業が重複してしまったり、技術的なスペシャリストが欠けていたりすれば、深刻な問題となる。 そしてあなたは、こういった問題に対応していくことになるだろう。 他の選択肢に比べれば、いくぶんマシな問題だが。