技術別組織

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

機能別組織のほうが好みだが、 機能別組織にはない、技術別組織のテクニカルな意見を軽んじることも出来ないだろう。

技術ベースの組織では、プロジェクトや組織の技術的側面で人材を揃える。 大企業では、Webインターフェイスのスペシャリストやデータベーススペシャリスト、ネットワークスペシャリストなどになるだろう。 この場合チームは、上流の複数のサービスから使用される特定のサービスに携わることとなる。 ひとつのプロジェクトの中でも、アプリケーションの自然なレイヤー分割にしたがって、似たような組織構造が現れることはよくある。

ソフトウェア開発は複雑だ。 現実的なシステムを構築するには、多くのスキルと知識が必要である――人間のオツムに入りきらないくらい多いのよ。 何が行われているかを本当の意味で理解するには、その分野を極める必要がある。 それでこそ、最も効率的かつ効果的なやり方でテクノロジーを使えるってもんだ。

能力の低いひとには、これはまさにあてはまる。問題の数が多すぎると、うまく扱えないからだ。 だが、能力の高いひとにも、これはあてはまる。絞り込んだ問題に集中して取り組むことができるからだ。 分野を極める方針でいけば、いちばん有能なスペシャリストを、最も複雑かつ価値のあるITインフラの部分に割り振ることが出来る。 組織中でいろいろなところから必要とされる部分は特にそうだ。

組織の生産性を向上させるためには、重複作業を排除しなければならない。 もし全てのプロジェクトでデータベースインタラクション層（もしくはメッセ―ジングシステム）を構築するとしたら、重複したところにかけるお金は無駄だ。それに、保守費だってバカにならないだろう。 機能的チームは自分らのやりたいようにやって、チーム間でコミュニケーションをとらないから、どうしてもこういった無駄な重複作業が発生してしまう。 どうしてそんな汚いやり方でいろいろとヤッチまうんだ。 きちんと一回で済ませばいいじゃないか？

開発者が単一のアプリケーションに関わっていたら、 ビジネスをとりまく広い視野を得ることは出来ない。 それは、区画されたビジネスユニットと同じで、ひとりよがりな考え方である。 近年、ソフトウェアはビジネス同士をつなぎあわせる代物である。 また、包括的な視野でビジネスを俯瞰するのにITは不可欠だ。

それに、技術別に組織化を行うと、 自然と同僚と人脈をつくり、 お互いに技術的スキルを向上させ合うことが出来るのだ。