当然だけど正しいとは限らない。 普段思っている事を書きなぐった。
理想的には一人が最高。 コミュニケーションコストは人によってはコードを書くよりも遥かにコストが高い。 自分はコミュ障なのでコミュニケーションコストがとても大きい。
たとえ git を使っていてもクソコードを製造する働き者がいるとコンフリクトが怖くて全体的な改善に手を付けられない。 生産性 x0.1 と x10.0 の人間を同居させると、二人の生産性は高々 x0.1 で固定される。 無能な働き者は排除するしかない。
本人の志向もあるとはおもうが、基本的には得意なことがあるなら得意な事に専念するべき。 ゼネラリストに転向させるよりは、そちらの方が結局は全体の効率化につながる。 （この辺は次のチームの話にもつながる）
あるメンバーが抜けても大丈夫なように他のメンバーが補えるようにするというのが多分、大半の意見だろう。 リスクコントロールとしては妥当だと思う。
一般的な作業であればたしかにその通りだが、すべての作業が他人が行う事ができるなら、はたして自分は一体なんのためにその場にいるのかという疑問にあたる。 そして各作業の最大効率は関わっているメンバーの最大公約数となる。 互いの役割を尊敬しあい、信頼して任せることが重要。
その人の代わりになる人を作るのではなく、その人が抜けたときにたとえクオリティが落ちたとしても他の方法で乗り切れるようにする方が大事。 どうしてもそれが不可能だというなら、あらゆる手段を用いて抜けないようにする。
ただし、単純なコーディング上のミスなどは互いにチェックし、指摘しあえる環境が良い。 あとは、ひたすら各々がやってることを自慢する会みたいのとか良いと思う。
余裕がある場合は、同じ事を二人ですすめそれぞれ独立した実装をつくり議論のネタできると最高。 コミュ障にはペアプロとかつらそうなので実装を戦わせた方が建設的。
他のひとほど難しく考えていない。 単純にコードの read/write のバランスをみて、明らかに read の回数が多いならばそちらに最適化を寄せて全体の消費時間を減らすべき。 read/write のバランスは時間で経過するので定期的に見直すのが良さそう。