小さなチームは新しいことに挑戦しやすく、大きなチームでは新しい試みに手がつかない理由

小さなチームでは新しい技術や生産性向上ツールの置き換えの検討などを挑戦しやすく、大きなチームではリソースの観点で言えば潤沢にありそうなイメージを持つので小さなチームよりはより多く機会があるように思えるが、現実はそうならない。

返って、小さなチームの方が新しいことに挑戦していた経験がある。

その小さなチームとは、4−5人のチームをイメージしてくれれば良く、大きなチームは10人以上のチームをイメージしてくれれば良いが、一層のこと、極端に300人くらいのチームを想像してくれた方がイメージしやすいかもしれない（経験していないと返って300人のエンジニアのチームは難しいか）。

小さいなチームの特徴

小さなチームなのでプロジェクトマネージャは、エンジニアを兼ねているプレイングマネージャの方が多い。

小さなチームばかりプロマネをしていると、体系的なプロジェクトマネジメントを経験的に学ぶ機会はゼロに等しい。経験ベースだと経験したこと以外を身につけられない。身についていないことは視界に入らないし、視界に入らないことは関心を持たないので形式知の対象とならない。

エンジニアの数が少ない（小さいチームだからね）のでエンジニアの性能（能力）がチームへ与えるインパクトが半端ない。5人のチームで1名の能力がチーム平均を１としたときに0.5だとチーム全体の性能は10％ダウンを前提に全てを計画しなければならない。言い換えれば、作業計画時から計画工数の10％の残業が前提としなければならなくなる。

小さなチームであるため、生産性向上のチームへ与えるインパクトは絶大になる。そうした背景から新しい試みに挑戦する文化が作りやすい。ただし、適用できるかどうかの見切りは早い段階でできないと納期を守れなくなることから従来の方法へピボットするタイミングが早い。

人数が少ないので専門技術だけではチームの作業が賄えないことから、（必要に迫られて） マルチスキル化しやすい。そのため、エンジニアの価値が（技術の幅として）上がりやすい。

同じように、人数が少ないのでロールとしての階層構造はほぼフラットになる。そのため、プロマネの仕事が視界に入りやすく、見様見真似で覚えられるし、プロマネによってはプロマネ業を委譲するタイプだと経験が少ないエンジニアでも早くから体験できる機会が得られる。

大きなチームの特徴

10人もいればプロジェクトマネージャは専任でなければやっていけない。そのくらいプロマネ業の作業ボリュームはある。

10人のチームともなれば、プロジェクトマネジメント を顧客が要求する案件であることが多く、体系的なプロジェクトの運営のスキルを必要とする。

人数が多いとチーム全体での作業の統一化、作業品質の確保にパワーがシフトしてしまうため、成功体験をチームの中にインプリする傾向となる。

結果的に統制を取るための活動に注力することになるため、新しい試み、例えば生産性向上のためのツールの置き換えは起きにくくなる。

10人以上ともなればメンバの平均的な性能は1に近く。近くが、低性能のエンジニアの混入率も上がる。

人数が増えると意思伝達の経路の組み合わせが多くなり、チーム内での情報共有に格差が生じやすい。

総じて、受け身のエンジニアが混在する率が高まり、他のメンバからの情報提供に寄生するエンジニアを産みやすいため、チーム文化としての対策（発進と自分から取りに行く）を強要する文化に陥りやすい。

 ロールの階層化、技術の分業化が進む（プロマネが一人二役を推進しなければ）ため、単機能工としての担当エンジニアでいることが可能となる。

しかし、そこで楽をしていると他で使えないエンジニアになる。

劇場版「Fate/stay night [Heaven's Feel] I.presage flower」(完全生産限定版) [Blu-ray]