第1回アジャイルな品質・QA組織パターン

私はアジャイルコーチとして様々な現場で改善活動を行っています。主に開発プロセスや組織体制の改善、スクラムマスターの育成がメインのお仕事ですが、ソフトウェア品質の改善要望も、お客様からよく伺っています。
テストを実施したり、CIサーバを使ってテストを自動実行したり、レビューを念入りに行なったり・・・。品質改善のための様々な活動によって、プロダクトの品質はどんどん改善されていくでしょう。改善はとても重要な活動ですが、活動だけではなく、その活動自体を持続的に行っていくための体制も重要です。
今回は、アジャイル開発において、品質やQAを高めていく組織づくりについてまとめていきます。これまで見てきた組織の形をパターン化し、それぞれの特徴を比較していきましょう。
ここではQA組織を例にあげていますが、QAだけでなく、開発、更に詳しく分けてフロントエンドやバックエンドなど、さまざまな職能も同じようにパターン化できると思います。ぜひ、ご自身の現場に当てはめてみてください。

また、この記事では以下の用語を使用しています。

組織：人間の集まったまとまりを指します。
企業：部門やチームが所属する会社です。
部門：職能ごとに分かれた組織を指します。
チーム：プロジェクトやプロダクトに直接関わる最小単位の組織です。

プロジェクト参加型パターン
一部横断部門・受発注パターン
- 一部横断部門・アサインパターン
一部横断部門・アサイン・横断パターン
Spotifyモデルパターン
QAいないパターン
QAサービスパターン（イネイブリングチームパターン）
まとめ

プロジェクト参加型パターン

プロジェクト参加型パターンは、SIや大企業に多く見られるパターンです。開発やQAといった職能ごとに部門としてわかれているのが特徴です。職能ごとに人が集まり、チームを作ります。プロジェクトだと期限があることが多いので、チームも期限とともに解散します。

メリットは、部門が職能ごとに分かれているので、それぞれで専門性を高められるため、人材を経営資源とする場合、経営効率に優れ最も無駄がない形と言えます。コラボレーションが苦手なので新しい価値創出は苦手ですが、すでに成果を出しているサービスやプロダクトの価値を、さらに高める場合に有効的な構造です。また、職能ごとで育成やノウハウ共有がしやすく、スキルや経験が似通ったメンバーが多いので、評価や採用がやりやすいでしょう。

デメリットはサイロ化です。職能をまたいでのコラボレーションが苦手です。企業レベルで職能が分かれている場合は、すべてのやりとりが企業同士のコミュニケーションになるため、難易度が上がります。同じ企業であっても、部門ごとにサイロ化してしまうと、コミュニケーションが難しくなるでしょう。いわゆる「持ち帰って検討します」なので、意思決定が遅くなりがちです。チーム間でのサポートがしやすい体制でもありません。

また、プロジェクトに集まったメンバーは、レポートライン（報告する企業や部門）が異なるため、共通のゴールを立てるのが難しい場合があります。共通のゴールがないとプロジェクトへのコミットメントが弱まってしまいます。

レポートラインが異なると評価も難しくなります。たとえば、ある人がプロジェクトで良い評価をされて、それぞれの組織で悪い評価にされたなら、それが最終評価になります。はたして、これはフェアな評価といえるのでしょうか？

最後に、プロジェクトが終わるとチームが解散する場合が多いので、そのたびに知識や経験が分散してしまいます。逆に言うと、プロジェクトによって職能に閉じた専門的な経験は増えます。

メリット

経営効率が高い
管理、育成、ノウハウ共有、評価や採用がしやすい
職能ごとの知見が増えやすい

デメリット

サイロ化によってやりとりのコストがかかったり、意思決定が遅くなったり、プロジェクトへのコミット力が下がったりする。コラボレーションが苦手

部門を横断したプロジェクトの評価が難しい
チームが解散するので、チームで得た知見が次に活かせない
チーム間でのサポートもしにくい

一部横断部門・受発注パターン

このパターンの特徴は、横断的な関心に強い組織を切り出した形です。よくある例としては、CTO直属でQA、セキュリティ、SREなどの部門がぶら下がっている形でしょうか。また、開発部とQA部で分かれているケースも多く見られます。

良い点は、先程のプロジェクト参加型パターンと似ています。職能それぞれに分かれている先程のプロジェクト参加型パターンよりはサイロ化は弱くなります。

ただ、作業が依頼形式で行われると、企業間や企業内で受発注のやりとりをしなければなりません。よって、「ちょっとこれもやってほしいんだけど」が「発注書出してください」になるので、正規の手続きを踏むと柔軟性が低くやりとりに時間がかかるでしょう。そして、Aプロジェクトの依頼とBプロジェクトの依頼が並んだときに、横断組織内で優先順位をつけにくい問題も発生してきます。

さらに、自分たちの職能に関わる部分を外部に依存している場合は、より手間が増えます。特定の業界でも問題になっている多重請負の問題が起きます。私も経験がありますが、結局手を動かすのが外部企業の方だと、間に誰かを挟むより、直接やり取りしたほうがはやくなります（ただ、ほとんどの場合、契約の関係などでダメと言われますが・・・）。

横断部門へのリクエストは、それぞれが個々に請け負うと優先順位を間違えたりするので、窓口を立てるなどして管理されます。この方法だと、リクエストがどんどんキューにたまっていき、窓口自体がボトルネックになりがちです。もし、横断部門の人数が少ない場合、横断部署メンバーが複数案件を持つケースも多くなり、そこがボトルネックになってしまいます。このように、全体へ何かを適用するのが苦手です。

依頼をラボ型組織で請け負うケースもあります。ラボ型とは、仕事にかける人数は約束せず、仕事を処理する契約形式です。依頼者は期待する結果と期限を伝えます。ラボの中では、その結果と期限に合わせて人員調整を行い仕事を期限内で終わらせます。この方法だと、ラボ内のリソース管理に柔軟性が増します。仕事を効率化すると作業量が増えるので売り上げも増えます。依頼者側から見ると、リソースの空き具合などを気にせず依頼できます。

メリット

意思決定が少しだけはやくなる
管理、育成、ノウハウ共有、評価や採用がしやすい
職能に閉じた知見が増える
ラボ型だとリソースを気にせず依頼ができる

デメリット

サイロ化が少し弱くなるが、部門が分かれている部分のやりとりのコストはかかる

部門を横断したプロジェクトの評価が難しい
窓口部分や複数案件抱えるメンバーがボトルネックになりやすい
チーム間でのサポートもしにくい
全体への適用が苦手

一部横断部門・アサインパターン

このパターンは、横断部門を作るところは同じですが、メンバーをチームにアサインするのが特徴です。

育成や採用や評価のために横串で部門を残しつつも、アサインすることで弱点であったコミットメント力が高まります。チーム内のコミュニケーションコストも低くなります。

アサインする場合は、人数をある程度確保しなければなりません。そうしなければ、1名が複数プロジェクトを担当するなど、メンバーに対する負荷がプロジェクトやプロダクト活動に影響を与えてしまいます。そうなると、またサイロ化が進み、「QA部門のせいで・・・」といったやりとりが起きてしまうかもしれません。

メリット

意思決定がはやい
チームの知見が増えて活かせる
チーム内でのコミュニケーションが取りやすくコミットメント力も高まる

デメリット

人数を確保しないと体制が作れない

チーム間のサポートがしにくい
全体への適用が苦手

一部横断部門・アサイン・横断パターン

先程登場した「一部横断部門・アサインパターン」の進化系です。アサイン型を試して問題や課題を経験した組織がこの方法に進化するケースがあります。

アサイン型でメンバーはチーム内でプロジェクトやプロダクトに貢献します。しかし、チームによって忙しかったりそうじゃなかったり波があるので、その波を横断部門に残したメンバーがサポートします。昔、私がQA部門のエンジニアリングマネージャをしていたときは、この方法をとりました。横断部門に残ったメンバーに「シューター」という役割をもたせ、文字通り困ったところに行ってシュートを決めてきて（問題を解決してきて）もらいます。

このシューター制度の難しいところは、シューター自身がさまざまなプロジェクトや技術に精通しなければならない点です。シューターには高いスキルが求められます。

また、横断部門に残ったメンバーは、横断的な関心事にも集中できます。QA部門であれば「テスト自動化を広げる」や「プロダクト全体のテスト自動化を担当する」などが考えられます。最近人気の書籍『チームトポロジー』を真似るのであれば、「新技術をそれぞれのチームにインストールする」役割をもたせても良いかもしれません。

この方法は、比較的大きなプロダクトやシステムで採用されているように思います。各チームでなんとかできていたものが、だんだん規模が大きくなり、その規模に対して組織としてどうアプローチするか？となってこの形になっていくように思います。

メリット

意思決定がはやい
チームの知見が増えて活かせる
チーム内でのコミュニケーションが取りやすくコミットメント力も高まる
チーム間のサポートが少しやりやすくなる

デメリット

人数を確保しないと体制が作れない
シューターに高いスキルが求められ、育成も時間がかかる

Spotifyモデルパターン

アサイン型の組織を更に拡張したのが音楽配信サービスSpotifyの組織構造です。通称Spotifyモデルと呼ばれるこの形は、スタートアップを中心に多くの企業が採用しています（参考： Spotifyのスケーリングアジャイル – 部隊、分隊、支部やギルドと共に歩む）。

彼らは支部という呼び名で部門を残しています。さらに、職能ごとの一部の部門ではなく、すべての部門がわけられた構造になっています。縦軸でプロダクトに貢献します。プロダクトを優先させるため、チームが最も重要な組織になります。

更に彼らは、ギルドという形で関心事のあるメンバーを集めます。ギルドはコミュニティのような集団となり、「テスト自動化に関心のある人たち」や「CI/CDに関心のある人たち」のようにゆるやかにつながり、組織全体の課題を解決していきます。

メリット

意思決定がはやい
チームの知見が増えて活かせる
チーム内でのコミュニケーションが取りやすくコミットメント力も高まる
チーム間のサポートがやりやすくなる
社内にコミュニティ文化が根付きやすい

デメリット

人数を確保しないと体制が作れない

QAいないパターン

ごく一部ですが、QAが存在しない組織もあります。つまり、職能ごとの部門がなく、だれもがエンジニアと名乗るだけの組織です。

高い練度が求められますが、QAに限らず、チームで必要なスキルをチームでなんとかしていきます。もちろん、テストの詳しい人、CI/CDに詳しい人・・・のような人は存在しますが、チーム内で自己完結するために、だれもが学んでいくチームです。

このパターンに出会ったときに思ったのは、そもそも部門のような組織が必要あるのか？という点です。もちろん、集まるメリット・デメリットはあると思いますが、「似たようなものをまとめる」という考え方が、もしかしたら、今の時代だと古い考え方なのかもしれないと感じました。

GAFAレベルの組織や、国内でも技術に力を入れている組織はこの形を好むようです。ただ、このパターンにシフトしていくのは相当難易度は高く、どの企業でもできるパターンとは言えないように思います。

メリット

意思決定がはやい
スキルあるメンバーが集まるので強いチームになりやすい
チームの知見が増えて活かせる
チーム内でのコミュニケーションが取りやすくコミットメント力も高まる

デメリット

それぞれが自律してスキルアップが必要になる
なんでもできるメンバーを確保・育成するのが難しい
チーム間のサポートがやりにくい

QAサービスパターン（イネイブリングチームパターン）

最近はSaaS型のサービスが全盛期を迎えていますが、QAというものもServiceにできないかと考えたことがありました。いわゆる「QA as a Service（QaaS）」です。

この場合、QAが依頼を受けるわけではなく、サービスを提供し、チームはそのサービスを活用します。これも前述の書籍『チームトポロジー』のイネイブリングチームの役割に似ています。端的に書くと、サービス自身が何かを引き受けてくれるのではなく、テストや品質、新しい方法論をチームに教え、チームがアクションを行えるようにしていく形です。チームが自分たちの意思でサービスを使い、開発に役立てていきます。

メリット