> 私の個人的な意見としては、一部の人(例えばアーキテクト)だけ、
> フレームワーク全体を把握していて、残りのメンバーは
>「限定されたことだけやっとけ」みたいなことは好きではありません。
大規模だと好き嫌いに関わらずこういったアプローチになるのでは？
アーキテクト以外の学習コストはむしろ減ると思いますが…
きっとこのコメントを書いてくれた人は、本気でこう考えているんだと思いますが、私は、このようなアプローチが嫌いというだけではなく、効率が悪いと思っています。
一番の理由は、開発者のモチベーション。「限定されたことだけやっとけ」という状況で、開発者のモチベーションが上がるとは思えません。実際、モチベーションは下がるでしょうから、それにあわせて、生産性も落ちるでしょう。
2008-02-15 - ひがやすを blog
禿同。超禿同。
ITアーキテクトって職種が認知され始めてから、よりこの傾向って強くなってる気がする。
（前々からこうだったかもしれないけど。）
知ろうとしないエンジニアがいる、大規模だとそれが顕著って話もわかる。
だけど、規模の不経済が適用されるってことを念頭に置いて、そういう人を除いていかないと。
（今すぐは無理だとしても。）
全体を把握しているメンバーをできるだけ多くしていく。
そもそも、今までよくあったプログラマは全体を知らずに部分だけ製造するってのはベルトコンベア的な流れ作業で、その失敗プロジェクトとなる確率の高さから有効な方法とは言えない。
ひがさんはモチベーションについて述べられているけど、僕としては「動きが遅くなる」ことが問題じゃないかと思う。
「限定されたことだけやっとけ」ではアーキテクチャはアーキテクチャチームしか理解していない。
フレームワークのバグ修正などアーキテクチャへの対応はアーキテクチャチームしかできない。
その対応が終わってからでないとエンジニアは作業できない。
バグがビジネスロジックにあるのかフレームワークにあるのかを判断することすら、アーキテクチャチームがかかわらないといけなくなる場合があるだろう。
やっぱり少人数→全員が全体を知る（深さは別にして、要求も設計もアーキテクチャも）ってのが理想というか現実にしていくべき方向なんじゃないかな。
それに、部分だけではプロジェクトに対して「自分のプロジェクトだ（所有感）」はないから、どうしても責任感は低くなる。
全体を知ることで所有感が高まり、ひいてはモチベーションupなんかもあって、より熱心に取り組める。
プロジェクト成功のキーが「人」である以上、多くのメンバーに「これは俺のプロジェクトだ！絶対成功させる！」みたいに思ってもらうことは超重要だと思う。
