この記事は フリューAdvent Calendar 2025 の8日目の記事です。
こんにちは。品質支援課のマネージャーをしている吉田です。
今年の4月、フリューではピクトリンク開発組織の中に点在していたQA（Quality Assurance）機能を集約し、「品質支援課」 として新たな組織を立ち上げました。
本記事では、立ち上げの背景から、私たちが選んだ 「スクラムに常駐しつつ独立する」 というハイブリッド戦略、そして現在のリアルな課題までを振り返りとして記録に残そうと思います。
QAエンジニアの方はもちろん、組織づくりに悩むマネージャーの方にも何かヒントになれば幸いです。
🏢 はじめに：なぜQA組織が必要だったのか
以前の課題感と、組織化の構想
QA組織立ち上げの構想は、実は数年前にさかのぼります。
開発者自身がテストを行うことには、「作ったものへの責任感」や「詳細な理解」というメリットがありました。しかし一方で、どうしても 「客観的な視点の欠如」 や 「開発スケジュールの圧迫によるテスト工数不足」 という問題が常につきまとっていました。
「テストで見つからなかったのか？」
障害が起きるたびに曖昧になる責任の所在。局所最適になりがちな品質意識。
ここを解決するために組織化を訴えましたが、当時はまだその必要性を十分に感じてもらえず、構想は一度立ち消えとなりました。
「品質改善」の解像度を上げる
それでも、品質に対するモヤモヤとした課題感は消えませんでした。
そこで約2年前、「自分たちの課題認識は合っているのか？どう打ち手を打つべきか？」を明確にするため、有識者であるコンサルタントを入れた組織診断を実施しました。
そこで突きつけられたのは、厳しい現実でした。
「品質改善活動について、いつ、どこで、何をすべきかが整理されていない」
ビジネス側と開発側の間に見えない壁があり、目標数値も測定できていない。「なんとなく品質が不安」な状態から脱却し、自律的な改善を行うには、土台が圧倒的に足りていませんでした。
そして、「なぜ今？」の組織化へ
改善活動の一環として、まずは「開発チームの中にQAエンジニアを採用・配置する」というトライアルから始めました。結果として、3つの開発チームそれぞれに1〜2名のQAがいる状態まで体制を整え、現場での改善活動は着実に進んでいきました。
そんな中、全社的な組織改革が行われ、各チームに点在していたQAメンバーが集められ、「品質支援課」として独立することが決まったのです。
正直に言うと、開発組織から切り離して独立させた経営的な意図のすべてを、私が把握しているわけではありません。「なぜ今？」という驚きもありました。しかし、これは以前から目指していた理想を実現するチャンスです。そう腹を括り、新しい組織を背負って踏み出すことになりました。
🚀 立ち上げ準備：まずは「計測」から
組織を作る前にまず取り組んだのは、「現状の見える化」 です。
コンサルティングの結果、「指標となる数値が存在しない」ことが大きな課題だと判明しました。そこで、Biz（ビジネス）とDev（開発）の共通言語を作るために、以下の取り組みを行いました。
-
リードタイムと変更障害率の計測
- 「感覚」ではなく「数字」で語れるように整備
-
品質目標の設定
- リードタイム35％減、変更障害率0-15%などの具体的数値を設定
-
テスト自動化の再設計
- メンテナンスコストが高くついていた古い自動テストを見直し、費用対効果の高い形へ移行
これらを推進するために専任メンバーを採用し、満を持して4月に 「QAチーム」 が組成されました。
⚔️ QAチームの戦略：「ハイブリッド型」への挑戦
組織化にあたって最も悩んだのが、「QAエンジニアの立ち位置」 です。
開発プロセスとしてスクラムを採用している私たちにとって、QAが別組織になることで「開発チームとの距離」ができてしまうことは最大のリスクでした。
そこで私たちが採用したのが、「組織としては独立しているが、マインドと動きはチームの一員」というハイブリッドな戦略です。
私たちが目指す「二重帰属」
現在の私たちの基本スタイルはこれです。
| 所属タイプ | 特徴 | 採用理由 |
|---|---|---|
|
チーム所属型 （スクラムチーム常駐） |
開発初期から入り込み、シフトレフトを実現。 チームとの信頼関係を構築しやすい。 |
アジャイルな現場に最適。 QAを「外の人」にせず、チームの一員として動くため。 |
|
プロダクト所属型 （横断・プロダクト軸） |
複数チームを横断して品質の一貫性を担保。 ナレッジの共有・仕組み化に強い。 |
大規模・横断PJ向け。 組織としての品質基準を統一するため。 |
基本的には前者の 「チーム所属型」 をメインに採用しています。
日常的にはスクラムチームのイベントに参加し、開発者と肩を並べて仕様議論から入る。でも、所属は「品質支援課」であり、QAチームとしての横の繋がりも持つ。
「組織の壁を薄くし、みんなで品質を大事にする文化を作る」
その旗振り役としてQAエンジニアが先導する、そんな形を理想としています。
🤝 チームビルディング：離れていても「ONE TEAM」
各スクラムチームに常駐していると、どうしてもQAメンバー同士の顔が見えにくくなります。そこで、要所を絞ってQA組織としてのイベントを設定しました。
- 📅 Weekly進捗会：各チームの状況共有
- 📚 隔週MeetUP：QAスキル向上・ナレッジシェアの場
- 🌙 月次定例：月ごとの活動内容＆発生した問題や困りごとの共有
- 🗣️ 隔週1on1：マネージャーとの対話
基本は現場（スクラムチーム）優先ですが、帰ってくる場所（QAチーム）もしっかり温めておくイメージです。
📝 8ヶ月走ってわかった「リアルと大反省」
さて、きれいな戦略を並べましたが、実際どうだったのか？
正直なところ、「よかったこと」 と 「大反省」 の半々です（笑）。
✅ よかったこと：自然発生的な連携
QAメンバーが集まると、すごいんです。お互いのチームの良い取り組みや失敗談を共有し、自然と「それ、うちでもやってみよう」という空気が生まれます。
横連携が強化されたことで、スキル向上やモチベーション維持の相乗効果は確実にありました。
⚠️ 大反省：役割認識のバラつき
一方で、痛感したのが 「QAの役割定義」 の難しさです。
「各チームにQAがいる状態」からスタートしたものの、実はチームによってQAに求める期待値や、これまでの関わり方がバラバラでした。さらに開発組織自体の体制変更や人の入れ替わりも激しく、「QAエンジニアとは何者か？」という定義が揺らぐ場面がありました。
「ベースはある程度できているだろう」という私の思い込みもあり、QAの立ち位置や提供価値を改めて周知・啓蒙していくプロセスが不足していたな、と猛省しています🥺
現場のメンバーが踏ん張ってくれているおかげで回っていますが、マネージャーとして「交通整理」をもっと丁寧にやるべきだったと感じています。
🏁 おわりに
QA組織として立ち上げてから約8ヶ月が経ちました。
まだまだ試行錯誤の連続ですが、メンバー同士の連携により組織としての一体感は確実に生まれてきています。
「独立した組織だけど、心は開発チームと共に」
この難しいバランスを取りながら、今後も開発者自身が安心してアクセルを踏めるよう、品質の面からプロダクトを支えていきたいと思います。
明日のAdvent Calendarもお楽しみに！