共有リソースプール

エンジニアが部分的にアサインするチームを構成。

優秀な人ほどプロジェクトを掛け持ちする。また、互いのスキルを理解しなければ未熟なチームワークでプロジェクトが開始する。

＜解決策＞チームを固定化する。

不連続なチーム

チーム1 --- プロジェクトA |-- Aさん |-- Bさん ↓ チーム2 --- プロジェクトB |-- Aさん |-- Cさん

プロジェクトごとに新チームを新たに構成すると、学びの喪失が起こる。プロセスの反復で学びを蓄積し不確実性を崩していく。

＜解決策＞同一チームが担当プロダクトの開発プロジェクトに繰り返し携わる。

トータルのコントリビューター数や、マイナーコントリビューター（全体コミット数のうち5%未満の貢献にとどまるユーザー）が多いコンポーネントは、リリース前後に置ける故障が増加する。

＜解決策＞プロダクトやコンポーネント、コードに特定のオーナーを決める。個人をオーナーとせずチームで共同所有する。外部コントリビューターのコードはオーナーチームのレビューを受けてマージする。

開発チームと、保守・運用チームを線引すると、保守・運用の容易さが考慮されず運用知識の乏しい設計になる。

＜解決策＞ You build it, you run it. 作った人たちが運用も担う。

顧客とコミュニケーションしてフィードバックループを回し、サービス品質を改善させる。

開発チームと、テストチームを線引すると、最後はテスターがなんとかしてくれるという丸投げが起こる。

a. 機能テスト b. ユニットテスト c. 探索テスト d. 非機能テスト

＜解決策＞ a,bを開発チーム、c,dをテストチームが担う。場合によっては両者で実施する。

行き過ぎると、Aさんしかできない、Bさんしか知らないという固定化が起こる。各自の仕事のやり方を言語化・可視化する動機が減り、ドキュメントなし、コメントなし、複雑なコードなど人が読むことを前提としない開発が生まれる。

＜解決策＞固定チームにも流動性を持たせる。新規メンバーのアサイン時にオンボーディングを実施する。

開発チームと、企画チームを線引すると、間接的な説明で実装に入るため知識がこぼれおちる。

＜解決策＞開発チームとドメインエキスパートが密接に関わる。

マネージャーひとりが強い権限を持ち、開発チームは決定権を持たない。内部品質を上げる動機づけなどが失われる。

＜解決策＞ユーザー、ビジネス、開発それぞれの重要視するものの中でやるべきことを決める。