アーキテクト以外は「限定されたことだけやっとけ」

> 私の個人的な意見としては、一部の人(例えばアーキテクト)だけ、
> フレームワーク全体を把握していて、残りのメンバーは
>「限定されたことだけやっとけ」みたいなことは好きではありません。

大規模だと好き嫌いに関わらずこういったアプローチになるのでは？
アーキテクト以外の学習コストはむしろ減ると思いますが…

きっとこのコメントを書いてくれた人は、本気でこう考えているんだと思いますが、私は、このようなアプローチが嫌いというだけではなく、効率が悪いと思っています。
一番の理由は、開発者のモチベーション。「限定されたことだけやっとけ」という状況で、開発者のモチベーションが上がるとは思えません。実際、モチベーションは下がるでしょうから、それにあわせて、生産性も落ちるでしょう。
二番目の理由は、開発者が成長しないこと。開発者というのは、いろんなプロジェクトに参加し、いろんな経験をつみながら成長していくものです。それが、いつも、「限定されたことだけやっとけ」では、成長していくことができません。
こんなことを書くと、「お前って甘すぎ、客は開発者を成長させて欲しいとは思ってないから、そんなことするのは余分なだけでなく、客に迷惑かけてるよ」そう、思う人もいるかもしれません。確かに、たった一度の付き合いだと、そうかもしれませんが、何度も付き合うことを考えると、客にとっても、開発者の成長は、メリットになるでしょう。その際、開発者が基本的なことはちゃんとわかっているように、事前にしっかり教育する必要があります。
SIerの方なら、こう思う方もいるかもしれません。「甘いな。社員を教育するならともかく、パートナー会社を教育する必要ないじゃん。」甘いのはそう思ったあなたのほうです。今は、一社が利益を独占する時代ではなく、「ともに繁栄」していく時代です。自分たちがよければいい的な企業は、社会のエコシステムから取り残されていくはずです。少なくとも私はそう信じています。
あなたがアーキテクトなら、「仮にお前の言ってることが正しいとしても、現実問題として、全員がこれだけ複雑なアーキテクチャを理解できるとはおもえないし、時間もない。」そう思うかもしれません。
その複雑なアーキテクチャを選択したのは、あなた(アーキテクト)です。最初から、誰でも短時間で理解できるシンプルなアーキテクチャを選んでいれば何の問題もなかったのです。
苦労して、複雑な技術をマスターした人がそういう罠に落ちやすい。そういう人は、全然悪い人じゃないんですよ。努力家だし、技術に対しても常に前向き。
そういう人に言いたい。less is moreの言葉を思い出してくださいと。