クロスファンクショナルなチームとドメインベースのチームの比較（たとえば、プロジェクトベースとソフトウェア/メカニックスなど）はありますか？

私は多くの統合システム製品を作成する組織で働いています。つまり、機械/システム/電子機器/ソフトウェアが設計および製造されている完全な製品です。現在のところ、ほとんどのチームはプロジェクトを中心に機能横断的に編成されています。このような組織の利点は、共通の目標のために緊密に協力している人々が近いことです。

不利な点は、エンジニアが同僚から孤立していることです。通常、プロジェクトには1人のソフトウェアエンジニアのみが割り当てられます。つまり、プロジェクトには高いトラック係数、最小限の知識の共有、ベストプラクティスがあり、技術開発は限られています。

だから私の質問です：これら2つのアプローチのコスト/利点を比較する研究はありますか？

使用するのに最適なタイプのチーム構造は、必ずしも費用対効果の高いものではなく、現在実施されている組織文化、従業員の特性、および実施されているプロジェクトのタイプに基づいています。これらの変数のために、特定の戦略またはアプローチが最善であると言う方法はありませんが、目前のタスクを完了するためにチームを最適に構築する方法に関するいくつかの一般的な指標があります。

チームにはさまざまな種類があり、チームや組織を編成する方法があります。より一般的な形式には、機能的、軽量、重量級、自律型があります。以下では、技術革新の管理に関する本の一部であるMelissa A. Schillingの技術革新の戦略的管理について要約しています。

機能チームは完全にクロスファンクショナルではありません。すべての従業員は自分の部署に残ります。科学、工学、人的資源などを完全に分離します。従業員は機能マネージャーに報告します。この構造では、プロジェクトに携わる人々は、プロジェクトよりも機能部門に専念する傾向があります。この構造は、派生プロジェクトとして知られているものに適しています-わずかな変更または改善のみの既存の作業と、単一のタイプの専門知識しか必要としない（またはほとんど）プロジェクトとを活用します。

軽量チームは、メンバーが機能部門に常駐し、機能マネージャーに報告するときに発生します。ただし、プロジェクトマネージャーが導入されます。プロジェクトマネージャーは、プロジェクトの実行に必要な人々を監督しますが、直接管理することはありません。プロジェクトマネージャーの役​​割は、コミュニケーションを促進し、プロジェクトの各メンバーが適切に貢献できるようにすることです。この構造は、メンバー間の大量の調整とコミュニケーションを必要としない派生プロジェクトに最適です。

ヘビー級チームは、必要な個人を機能部門から削除しますが、それでも機能マネージャーに報告します。プロジェクトマネージャーはプロジェクトの活動を監督しますが、個々のチームメンバーを直接監督または管理しません。通常、プロジェクトマネージャーは、この環境の機能マネージャーよりも優れており、プロジェクトメンバーの評価、報酬、主導を担当しています。これらのチームは、プロジェクトに割り当てられたチーム間で高度なコミュニケーションとコラボレーションを行っており、メンバーはプロジェクトの成功にも取り組んでいます。このフォーマットはプラットフォームプロジェクトで使用され、前世代のコスト、品質、およびパフォーマンスを向上させるために使用されます（ただし、大幅な新しい革新はない場合があります）。

自律チームは、機能部門からメンバーを完全に削除し、プロジェクトマネージャーの直下でメンバーを機能させます。ここのプロジェクトマネージャーは、組織の上級スタッフメンバーとリーダーです。時には、これらのチームは独自のポリシーと手順を開発することにより、「仕事を成し遂げる」ための非常に大きな自由を与えられます。同時に、彼らはプロジェクトの成功または失敗に対して完全に責任を負います。これらのタイプのチームは、組織の製品に新しいイノベーションを導入したり、新しいビジネスユニットを生み出したりする画期的なプロジェクトに配備されることがよくあります。

ただし、特定の種類のチームが特定の種類のプロジェクトに適しているという理由だけで、組織の文化も重要です。一部の組織では、文化的な理由により自律チームをサポートできません（またはサポートしません）。他の人は特定の方法で「常にそれを行ってきた」ので、変更されません。また、チームにどのような種類の人がいるかも重要です。同じ場所に配置され、高度なコミュニケーションとコラボレーションの能力を持っていると機能が向上する人もいれば、問題を解決してそれを元に戻すために自分のスペースを好む人もいます。

次の論文/本/ドキュメントは、私が読んでいる本のセクションで引用されています。

• SC WheelwrightとKB Clark、製品開発に革命を起こす：スピード、効率、品質の飛躍的向上（ニューヨーク：フリープレス、1992）。
• F.ダマンプール、「組織革新：決定要因とモデレーターの影響のメタ分析」、Academy of Management Journal 34、No。3（1991）。
• EFマクドノウ、「部門横断的なチームの成功に寄与する要因の調査」。Journal of Product Innovation Management 17（2000）。

複数の部署からなるチームを編成することもできますが、複数のパートタイムエンジニアがいるチームにスタッフを配置することも害にはなりません。たとえば、ボブをプロジェクトaとプロジェクトbに配置し、ジェーンをプロジェクトaとプロジェクトbに配置することもできます。この方法で配布されますが、1人のソフトウェアエンジニアだけで構築できるほどプロジェクトが小さい場合は、このアプローチにも制限がある場合があります。

別のオプションは、チーム構造を同じに保ちながら、機能を中心に作業環境を編成することです。すべてのソフトウェアエンジニアをまとめて、オープン環境で共同作業できるようにします。これは一部の考え方に反するものであり、壁を倒すと人々が防御的になる場合がありますが、ブルペンタイプの配置で作業すると役立つ場合があります。

コワーキングの概念もこれに基づいています。他の方法では在宅勤務のオフィスで働く独立コンサルタントやデザイナーは、お互いの強みを活かせる共有施設に移動します。

これらのアイデアについてはそれほど多くはないかもしれませんが、仕事の生産性と満足度を高めるための実験として、関係するチームに提案することができます。次に、結果についてホワイトペーパーを作成します。