QA組織構造ごとのメリットデメリットをまとめてみました。だいたい数パターンに集約されるように思います。 もし、これ以外にご存知であればぜひ教えて下さい。
開発部● 概要○ 職能ごとの部門からプロジェクトごとにアサインする体制○ 大きな企業やSIに多い、昔ながらの構造● メリット○ 職能ごとに集まるので育成やノウハウ共有がしやすい○ 職能が明確なので人を比較的集めやすい● デメリット○ 概して、部門間の仲が悪い。いわゆるサイロ化○ プロジェクトに知識が残らないQA部プロジェクト職能ごと組織構造とプロジェクト体制
View Slide
開発チームQA開発チーム 開発チーム 開発チーム● 概要○ QA、セキュリティ、SREなど横断的組織を残すパターン● メリット○ 職能ごとに集まるので育成やノウハウ共有がしやすい○ 職能が明確なので人を比較的集めやすい○ QA部分を外注しやすい○ QAリソースを開発は気にしなくていい● デメリット○ 横断部署へのリクエストはキューになるため、窓口理論でボトルネックになりやすい○ 人貸し商売になりがち○ 依頼されたことをやるだけになりがちQA横断組織体制（社内受発注型）仕事の依頼
開発チームQA開発チーム 開発チーム 開発チーム● 概要○ QA、セキュリティ、SREなど横断的組織を残すパターン● メリット○ 職能ごとに集まるので育成やノウハウ共有がしやすい○ 職能が明確なので人を比較的集めやすい● デメリット○ 横断部署へのリクエストはキューになるため、窓口理論でボトルネックになりやすい○ 人貸し商売になりがち○ 開発チームとレポートラインが異なるので現場にコミットしにくいQA横断組織体制（アサイン型）
開発チームQA開発チーム 開発チーム 開発チーム● 概要○ QA、セキュリティ、SREなど横断的組織を残すパターン○ さらにマネージャだけでなく、開発チームを支援する人材を残して全体的なサポートをする● メリット○ 職能ごとに集まるので育成やノウハウ共有がしやすい○ 職能が明確なので人を比較的集めやすい○ ボトルネックに対応しやすい○ 横断的な関心に対応しやすい（例：自動テストを支援部隊でやっていくとか）● デメリット○ 人貸し商売になりがち○ 開発チームとレポートラインが異なるので現場にコミットしにくい○ 即支援できる強いスキルを持った人材が必要になるQA横断組織体制（アサイン型2）支援
開発チーム 開発チーム 開発チーム 開発チーム● 概要○ 詳しくはこちら（https://bit.ly/3rmWJ1C）○ スタートアップ中心にこの構成が多い● メリット○ 開発チームに権限を委ねているので機動力がある○ スクラムを利用する場合は、この形でやるのが無難（集合知であり共通解になりつつある）○ 横軸の職能部門をもたせることもできる○ より柔軟性を高めるなら、横軸組織をコミュニティのようなゆるやかなつながりで運営できる● デメリット○ チームに必要な職能すべての採用を一気にやる必要がある（そうしないとバランスが悪くなったりスケールに躓く）○ コミュニティ形成など、主体的に仕事ができる人材や、組織文化づくりが必要Spotifyモデル
開発チームQA開発チーム 開発チーム 開発チーム● 概要○ QAとよばれるサービスを完全に外出しする体制。完全に独立した QA組織を作れるかは疑問があるが、これができると開発チームは QAを外注できる。○ 注意： 今もQAの外注はあるが、納品型だと発注者のレビューが必要になり、発注側に QAの管理コスト負担がある。 QaaSはそれすらなくした状態を目指している● メリット○ 職能ごとに集まるので育成やノウハウ共有がしやすい○ 職能が明確なので人を比較的集めやすい○ ボトルネックに対応しやすい○ 開発側の負担が少ない（まかせられる）● デメリット○ 人貸し商売になりがち○ 開発チームとレポートラインが異なるので現場にコミットしにくい○ 品質の丸投げになりやすいQA as a Serviceサービスの提供
daipresents
mkeeda
microcms
y0gi
tomokusaba
mackee
speed1313
manfredsteyer
ericgpks
tonkotsuboy_com
aanrii
yuya4
ryunen344
aarron
addyosmani
kneath
mthomps
reverentgeek
marktimemedia
samlambert
brianwarren
malarkey
geoffreycrofte
tanoku
brad_frost