- 専門家中心の大規模チームは、内部依存、伝達ミス、ボトルネック、責任の分散などにより、生産性と協業効率が急激に低下する
- デイリースタンドアップミーティングでは大半の内容が不要または退屈になりがちで、チーム規模の拡大と専門化がコミュニケーションの断絶と無関心を招く
- 技術別（フロント/バックエンド）分離、臨時フィーチャーチーム、外部コンサルタント活用など複数の実験を行ったが、最終的にジェネラリストへの転換が最も実質的な効果を生んだ
- Mobプログラミングなどの集団協業は、知識共有、自律性、責任感、動機づけを促進し、単一分野へのこだわりよりも結果重視の協業と成長に向いている
- ただし、ジェネラリスト化の副作用（専門性の低下、バーンアウトのリスク）もあり、継続的な実験と文化的改善が不可欠である
チームが大きすぎるときの問題
- 14人規模の大きなチームで始まった問題: スタンドアップの会話の大半が不要で、業務伝達の漏れや非公式な作業が頻繁に発生
- 非同期スタンドアップ（Slackなど） に切り替えても、重要な会話や協業の機会が失われ、単なる報告書に変質
さまざまな分割・運用の実験
- 技術別（Task Force）分離: フロントエンド/バックエンドに分けたが、すぐに相互依存の問題が発生し、追加のスタンドアップ参加で時間も増加
- 臨時フィーチャーチーム: 特定機能の実装に応じて人員を一時的に再配置したが、保守やリソース管理の課題が発生
- 外部コンサルタント投入: すでにチームが大きいにもかかわらず非効率で、上級経営陣からはリソース活用への圧力があった
最終的に効果的だった解決策
- スペシャリストではなくジェネラリストモデルを導入
- フロントエンド、バックエンド、QA、DevOpsなどの役割を分けず、1つの目標/製品を中心に全体のスキルセットを共有
- 知識共有、責任分散の抑制、ボトルネック解消、より速いデリバリー/高品質を実現
- Mobプログラミングなどの集団協業で、コミュニケーション/自律性/オーナーシップを強化
なぜジェネラリストが効果的だったのか
- 共通の文脈と目的: 新しい分野であっても、同じ製品/目標を基準にすることで学習曲線が緩和される
- 限定された必要性: 特定のツール（CI/CDなど）だけ習得すれば十分で、深い専門性より生産性と保守性を重視
- 動機づけの3要素（自律性、熟達、目的） をすべて満たし、チームの当事者意識と成長を支援
- Egalitarian文化: 平等なアクセス権、自律的な知識獲得、権限と責任の分散、集団学習
- 責任の3要素（知識、権限、責任） が明確で、オーナーシップに基づく迅速かつ高品質な成果を導く
副作用と限界
- 専門家の離脱: ジェネラリスト化はすべての人に合うわけではなく、一部人材でバーンアウトやリソース過熱が発生
- 専門性の深さ不足: さまざまなスタックを浅く扱う分、1つの分野で深く熟達することは妨げられうる
結論と教訓
- 画一的な解決策はなく、実験と改善の文化のほうが重要
- スペシャリストモデルの欠点（ボトルネック、コミュニケーション断絶、フェイクワーク、文脈の断絶）は、ジェネラリストと集団協業で解消可能
- 最終的には目標、人員、予算、製品特性によって最適化されたモデルは変わりうる
- 重要なのはオープンな実験、フィードバック、継続的改善の文化
4件のコメント
私はゼネラリストですが、実務で感じたのはこうです。
役に立つのはゼネラリストですが、本当に「価値」を認められるのはスペシャリストなんですよね。
同じ大学を出て同じ成績でも、結局はスペシャリストたちが2〜3倍高い報酬を受け取るのが現実です。
私も似たような考えです。
でも私の考えでは、ソフトウェア基準ではアメリカのディープテックでない限り、スペシャリストは本当の意味でそれほどスペシャルではない気がします。
差し支えなければ、例をお願いしてもよろしいでしょうか！ 実際にスペシャリストと呼ばれるのが、どの程度の「スペシャル」なのか気になっていて……
HRの基準では、大企業または中堅企業で3年ほどの経験を求めているようで、私基準の「スペシャリスト」は、バックエンドの観点からLLMを活用して、誰でも簡単に使えて高可用性まで考慮した構造を設計できるかを見ています。
例えば、私はジェネラリストですが、国内のどんなサービスでも1億人以上のトラフィックを、小学生でも理解できるくらいシンプルに設計できます。
でもまた、ジェネラリストなので大企業の書類選考では落とされます（笑）