効率的な連携を実現する、複数プロダクトを横断するQAアプローチ

こんにちは、千株式会社でQAを担当している村谷と申します。
今日は「千のプロダクト成長を支えるQA」というテーマで、お話させていただければと思っています。

会社概要と主要プロダクト

サービスの展開

千は創業期から「はいチーズ！」というサービスを提供しています。
メインとなるお客様は幼稚園や保育園といった教育機関で、各種イベントの撮影をはじめ、インターネット上での写真販売も行っています。また、フォト事業だけでなく卒業アルバム制作、保育事業向けICTサービスなども展開しており、保育DXを進める企業として幅広いソリューションを提供しています。

「はいチーズ！フォト」の概要

ここで代表例としてご紹介したいのが「はいチーズ！フォト」というサービスです。
運動会やお遊戯会、合唱コンクールなど、いわゆる“神イベント”と呼ばれるイベントの写真を、カメラマンや先生が撮影してアップロードすると、保護者の方はオンライン上で購入でき、配送までワンストップで行えるサービスです。保育園や幼稚園などの施設に加え、自宅でも受け取れる利便性が強みになっています。

これまでにアップロードされた写真の総数は6億枚を超え、全国330万人ほどの方々に利用していただいているという歴史があります。さらに特徴として、AWSの画像認識技術を活用した顔検索により、見たい写真を効率的に探せる仕組みも取り入れています。

開発組織とQAチームの概要

開発組織の規模と編成

下記が開発組織図になります。

社員は45名ほどで、業務委託の方も含めると全体で約60名規模のチームになります。編成は7グループ10チームほどに分かれており、そのうちQAチームが横断開発グループの中に所属しています。

サプライチェーンを形成するプロダクト

千のプロダクトは、これまで各サービスが独立した形で開発していたのですが、現在サプライチェーン^[1]内でのシナジーを高めるため、個々のサービスの特色を活かしながら、より相互の連携を高めていけるような形を意識しております。

例えば「はいチーズ！フォト」は園の撮影イベントとカメラマンをマッチングし、撮影後に写真を編集・掲載を行い、保護者の方が閲覧・購入した写真を印刷・配送まで提供しています。単なるECというより「カメラマンの派遣から印刷配送までのサプライチェーン」を提供しているイメージです。

そのように各サービスが独立しているわけではなく、他のサービスとも連携を高めるため、エンジニアには「ドメインに対する幅広い知識」が求められます。これが当社の開発プロジェクトをユニークにしているポイントでもあり、今後もサービス拡充にあわせて、その関連性はますます高まっていくと見込んでいます。

QAチームの体制

肝心のQAチームについてです。
現在は9チームをまとめる形で7名体制でQAを行っています。

そのなかで、QAチームは「各開発チームに常駐するわけではなく,必要に応じて集まったり分散したりといったスタイルをとっている」点が大きな特徴です。

開発案件の規模やフェーズによっては、1人でまかないきれない部分もあるため、まとめてQA活動を行うときもあれば、別々に動くときもある。つまり、従来の「各チームごとにQAが常駐する」モデルとは少し異なる運用なのです。

なぜチーム常駐型にしていないのか

各開発チームに常駐としていない背景ですが、千の開発が比較的規模の大きい開発案件が多いため、１人のQAエンジニアが常駐する体制では対応しきれない、というリスクがあるからです。

実際、案件によってはボリュームの差が激しく、一人で抱えてしまうと手が回らなくなる場面も少なくありません。そこで複数人でQA活動に取り組める体制を整え、互いをカバーできる体制にしています。

もう１つの理由として挙げたいのが、サプライチェーン構造です。
サプライチェーンが複雑になるほど、仕様やドメイン知識も膨大になりがちです。もし特定のメンバーだけがそれを深く理解している状態だと、属人化が進み、破綻しかねないというリスクがつきまといます。そこで「全員がある程度の理解を共有する」姿勢を大事にして、リスクヘッジを図っているわけです。

このような背景もあって、私たちのQAチームは全体でドメイン知識や状況を把握しながら、案件ごとに最適な形で関わるようにしています。

品質保証の取り組み

千における品質保証の特徴

現在、千のQAチームはまだ発展途上の段階にあり、そのため「すべての品質保証を完璧に行うことはできない」という前提のもと、柔軟な運用を重視しています。
プロダクトや開発チームの数が増えるにつれ、QAのリソースが不足することも少なくありません。そのため、品質保証のプロセスを完全に内製化するのではなく、案件規模や期日に応じてQAの体制を柔軟に変更する方針を取っています。

また、体制の際にも書きましたが、QAエンジニアの活動範囲を特定のプロダクトに限定せず、チーム全体で複数のプロダクトの仕様を把握する体制を整えています。これにより、幅広いテスト対応が可能となり、リソースの最適化を図っています。

さらに、自動テストを導入することで、決済処理障害などのクリティカルなリスクを検知し、未然に防ぐ仕組みを構築しています。ただし、自動テストだけで全てをカバーすることは難しいため、何を優先すべきかを意識しながら、テストの範囲や方法を工夫することが求められています。

開発プロセスとの関わり方

千のQAチームでは、シフトレフトを意識した活動を行っています。これは、開発の最終段階でまとめてテストを行うのではなく、早い段階から品質保証を意識するという考え方です。

各開発チームごとに定期的な会議へ参加し、タイムリーな情報収集や不明点の解消を行います。これにより、テスト設計や品質保証の観点を開発プロセスの初期から取り入れることができます。

柔軟な対応と情報共有

テストの規模や内容、リリース頻度は開発チームやプロジェクトごとに異なるため、状況に応じて柔軟に対応しています。開発チームからは、開発内容だけでなく、スケジュールや懸念点についてもヒアリングを行い、適宜レビューや調整を実施しています。

また、収集した情報はQAチームのWikiに記録・蓄積し、開発チームへも開示することで、チーム全体での情報共有を円滑に進めます。

スムーズなテスト移行

開発の設計・実装と並行してテスト準備を進めることで、実装完了後にスムーズにテスト実行へ移行できる体制を整えています。万が一、スケジュール変更が発生した場合でも、事前に用意したテストケースのラインナップ(松・竹・梅)を調整することで、迅速に対応可能です。

「手戻り」と「バグ」の違い

テスト実行中に発覚した不具合を「手戻り」、リリース後に発覚した不具合を「バグ」と呼び、それぞれ適切に対応しています。

「手戻り」が発生した場合は、以下のような情報も合わせて共有し、開発チームが改修の優先度を判断できるようサポートします。

• どの程度のインパクトがあるか（例: 決済・個人情報関連なら高リスク）
• テストケース上で発生したものか、想定外のケースなのか
• ブロッカーの規模はどの程度か

このように、QAチームは開発と密接に連携しながら品質保証を進め、リリース前後のリスクを最小限に抑える体制を構築しています。

大事にしているポイント

千のQAチームとして大事にしているポイントは大きく5つあるのですが、特に「2.利用目的が異なる利用者を念頭に置くこと」と「5.品質保証はQAだけの活動では達成が難しい」という2点に注目していただければと思います。

1. 開発に至る背景を理解しよう
なぜこの機能やサービスを作るのか。その背景を理解することでテスト範囲や優先度を明確にし、目的に合った品質保証が行えます。

2. 利用目的が異なる利用者がいることを念頭に置こう
「はいチーズ！」を例に挙げると、「保護者」だけでなく、写真をアップロードするカメラマンや写真館、そして千の社員も利用者です。それぞれ目的や視点が違うため、想定される利用シーンも多岐にわたります。全ユーザーにとっての使いやすさを考えることが重要です。

3. 頻繁なリリースにおける期日と内容のバランスを大切にしよう
リリース頻度が高いため、すべてを網羅的に検証するのは現実的ではありません。リスクを見極め、テストの優先度や範囲を決めるバランス感覚が求められます。

4. 決済機能・個人情報・外部連携の影響の有無を気にしよう
写真販売や保育関連サービスでは、個人情報や決済機能、さらに外部連携などを扱うケースが多々あります。障害発生時の影響が大きくなるため、特に慎重な品質管理が必要です。

5. 複数の部門と協力をしよう
最後に、品質保証をQAチームだけで完結させることは難しく、開発チームをはじめとする複数の部門との協力が欠かせません。コード品質向上の施策やリファクタリングなどはエンジニア主導の活動も多いですが、そこにQAがしっかり関与してこそ、高い品質を維持できると考えています。

今後の課題と展望

直面する課題

品質保証の現場では、さまざまな課題が存在します。特に、千のQAチームが直面する主な課題として以下の2点が挙げられます。

1. 広範なドメイン知識の必要性

プロダクト規模が大きく互いに連携しているため、どうしても一方を深く見ているうちに、もう一方が抜け落ちるといった問題が起こりやすい、という課題があります。今後、より各プロダクトの連携を高めていく中で、日頃から継続的にドメイン情報を収集・アップデートし、理解を蓄積しておく必要が高まっています。

2. 自動テストの拡充と安定性の確保

自動テストですが、拡充の方向には向かっているものの、導入の順番やカバー範囲、リスク判断などを考慮しながら進めていかなければなりません。

今後の展望

実は今年からCTO室が新設され、その中にAIの開発チームができました。
「AIを活用した品質保証」という壮大な伸びしろに挑戦できる土壌を整えております。AIが当たり前に活用される品質保証体制はまだこれからの話だと思いますが、そこに向けて少しずつベクトルを向けて頑張っていきたいと考えています。

もし「事業に深くコミットするQAを目指したい！」と思われる方がいらっしゃれば、ぜひ千の取り組みに興味を持っていただけると嬉しいです。今後さらにスケールアップしていくであろうQAの世界で、新しい風を一緒に巻き起こせればと思います。^[2]

【QAエンジニア / リーダー候補】使い勝手の良いサービスを仕様化の段階から設計（東京・フルリモート）