コミュニケーションコスト
- チーム開発で、コミュニケーションを無視することはできない。
- チームの人数だけ階乗的にコストは増える。
- 無駄な情報共有と会議が増える。
ブルックスの法則
遅れているソフトウェアプロジェクトへの要員追加はさらに遅らせるだけだ
プロジェクトが遅延している時に、新しい人をプロジェクトに参画させても、
その人の作業パフォーマンスよりもコミュニケーションにかかるコストが
上回ってしまい、結果的にさらに遅延するといった感じです。
どのくらいのチームのサイズでプロジェクトを始めるか真剣に考えよう。本来は少なければ少ないほうがいい。
チームの構造 == ソフトウェアの構造
コンウェイの法則
システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう。
裏を返すと、それらのチームが上手にコミュニケーション取れている場合は、
ソフトウェアも品質が高くなるということかもしれませんね。
マイクロサービスとの関係
組織構造とアプリケーションの構造が対応しているときにはチーム間のコミュニケーションがうまく行われます。 マイクロサービスは組織のアーキテクチャのお話とも言えます。
マイクロサービスを始めるとき | FiNC Developers Blog
人が辞めたら問題
少人数での開発の場合、人が辞めることはプロジェクトのストップを意味します。ソフトウェアはメンテナンスできなくなり、いままでのノウハウは消えてなくなります。テストを書いても、ドキュメントを整理しても、丁寧に引き継いでも難しいでしょう。
定期的にチームでノウハウを共有し、コードレビューを行い、リスクを低減させましょう。人が辞めないような職場にしましょう。
それでもデスマーチやりますか？
炎上プロジェクトに巻き込まれ、一人で抱え込み、オーバーワークで壊れてしまう人が少なからず存在します。特にIT業界ではその傾向が顕著です。幸いにも、私は潰れたことはありませんが、多くのメンバが潰れていくのを目の当たりにしてきました。ある日突然、メンバーが会社に来なくなる。彼らはアラートを上げられませんでした。その気持ちがわかるからこそ言いたいのです。
デスマーチ・激務に巻き込まれたアナタが取るべき12の対策【メンバー編】 - プロジェクトマネジメントの話とか
採用、評価制度、カルチャー、マネジメント
- 人が辞めたらメンテナンスする人を採用する必要がある
- 採用、研修、チーム作業の流れが整っているか
- 適切な評価制度で辞めない仕組みなっているか
- 継続的にマネジメントする仕組みがあるか
- エンジニアが挑戦できるカルチャーはあるか