1. はじめに
こんにちは。QAエンジニアとして働いている市川です。
今回は、私が所属しているカミナシ設備保全サービスチーム（以下サービスチーム）で「チーム全体で品質を考える文化づくり」を進めるために行った取り組みについて紹介します。 チーム構成は、エンジニア2名、デザイナー1名、PdM1名の体制で、私は昨年末からチームにスポットで参画して取り組みを進めてきました。
私が取り組んだことは大きく分けて以下の3つです。
- QAやテストの考え方を伝える座学セッション
- 品質を考えるワークショップ
- 設計ワークへの参加によるコラボレーションの強化
これらの活動の背景には、「プロダクトの品質はQAだけで担保できるものではなく、チーム全員が品質に対して主体的に取り組む文化が重要」という考え方があります。
まだすべてが解決できたわけではありませんが、まずは1チームでトライしてみたプロセスを共有したいと思います。
2. 取り組みの概要
なぜサービスチームを対象にしたのか
本来は全チームに横断的に品質活動を浸透させたいところですが、各チームが抱える課題感は異なり、さらに私自身が参加している時間やリソースにも限りがありました。そこで、まずは一つのチーム（設備保全）を対象にして、品質文化を醸成する打ち手を試し、その成果や学びを今後ほかチームへ展開していくことにしました。
今回はやらなかったこと
品質チェックリストの導入
何を確認すれば良いかのチェックリストが欲しいという要望もありましたが、他チームへの横展開が難しそうだったため不採用としました。
全チーム横断での一斉活動
やはり時間や背景の違いが大きく、全チーム一斉には難しいと判断しました。まずはサービスチームに集中することに。
読書会（Agile Testing Condensed や LEADING QUALITY）
- Agile Testing Condensed
- チーム全体で品質に関する共通言語・認識を持つには良書ですが、サービスチームはすでに一定の共通認識があり、ワークショップのほうがより身近なテーマで考えられると判断しました。
- LEADING QUALITY
- 今回は見送りました。PdMやEMなど、チームや組織を俯瞰して見る方が集まって実施すると効果がある本だと思います。
- Agile Testing Condensed
やったことの概要
- 座学 (20-30分) でQAやテストの基礎知識を共有
- 品質を考えるワークショップ
- 設計ワークへの参加とコラボレーション
それでは、各取り組みを詳しく見ていきます。
3. 実施した内容
3-1. QAやテストについての座学
最初に行ったのは「QAやテストって何を意味しているのか」をチーム全体で再確認するための短い座学セッションです。Notionにまとめた資料を使い、20～30分ほどで以下のポイントを紹介しました。
品質は相対的な価値であり、「誰にとっての品質か」を意識することが重要であること
例えば「ユーザーが期待する品質」と「社内運用担当が期待する品質」は異なるかもしれません。そうした相対的な違いを意識するだけでも、開発における優先度やリスクヘッジの考え方が変わります。
昔のテストアプローチと最近のテストアプローチの違い
アジャイル開発やDevOpsの流れの中で、不確実性が高い状態でリリースをどんどん回していくため、テスト対象や品質に関わるステークホルダーや要求も増え、より複雑になっています。
チーム全体で品質を考え続ける文化
QAが「最終チェック担当」のように見られるのではなく、開発、デザイン、企画といったさまざまな役割のメンバーが「自分ごと」として品質に関わる意識を持っている状態が理想です。
併せて、Agile Testing や Holistic Testing の概要も簡単に紹介しました。
- DevOpsループのライフサイクル全体が品質・テストの検討対象となる
- 「テスト」という言葉のハードルが高いなら、「アウトプットへの期待値を確認する・ギャップを見つけるアクション」と捉える
- すでにサービスチームで実践している「設計ワーク」や「バグバッシュ」などもテスト活動の一環だということを再認識する
この座学は短時間ではありますが、「そもそも品質って何？」という根本的な概念を共有できる大切な機会になりました。
3-2. 品質を考えるワークショップ
次に、品質を考えるワークショップを行いました。
以下のような目的・進め方をとりました。
- 目的:チームでの現状認識・共通認識を作り、「そもそも品質とは誰にとっての何か？」を言語化する
- 進め方:
- 「顧客にとっての品質とは？」「ビジネス側にとっての品質とは？」といったテーマで付箋を出し合う
- 意見をグルーピング・可視化し、チームとして重要視している観点をディスカッション
よかったこと
チーム内の温度感が揃っている: サービスチームは普段から顧客目線を強く意識していたため、付箋にも「カミナシの都合などユーザーには関係ない」「とにかくユーザー体験を損なわないこと」といった意見が多数出ました。
主体性の高さ: 全員が積極的に意見を出し合い、ディスカッションも活発だったのが印象的でした。
伸びしろ
- ビジネス観点の解像度がやや低い: 顧客視点はしっかりある反面、ビジネス的にどう評価されるかという観点はまだ十分に言語化できていない様子でした。
ワークショップを通じて、チームとして品質を考える素地は非常に高いものの、ビジネス側とのすり合わせや期待値調整をより強化できそうだ、という気づきが得られました。
3-3. 設計ワークへの参加
💡 設計ワークとは、サービスチームが隔週で実施するオフラインでの集まりで、普段のGather（バーチャルオフィスツール）やオンラインMTGとは異なり、同期的に腰を据えて取り組む機会として位置づけられています。この場ではドメインモデリングや機能設計、ロードマップの優先度検討、さらにチームの振り返りや方向性についての議論が行われています。
最後に、日頃の設計ワークにもQAの立場で入り込みました。具体的には下記のようなコラボレーションを試みています。
- 仕様やユーザーストーリーの策定時にQA視点のコメントを入れる: 仕様決めの段階で気になるリスクや不確実性を洗い出し、テスト方針や検証手法のヒントを提案。
- 開発プロセスの中でのバグバッシュやテスト項目すり合わせ: リリース前に「ここが落とし穴になりそう」というポイントをディスカッションし、チームで認識をそろえる。
テストは「実装が終わってからの行為」ではなく、「仕様や設計の段階で既に始まっている」という考え方を少しずつ醸成する取り組みです。
4. 学び・気づき
今回、サービスチームでの取り組みを通じて学んだこと、気づいたことをまとめます。
- チームの品質に対する理解が揃っていない場合や顧客への向き合い方が高い場合、ワークショップや座学でより深い学びが得られる
- サービスチームは既に「顧客目線で開発を行う」という共通認識が強かったため、「品質とは何か」を自分ごと化しやすかった。
- 一方で、チームの品質に対する理解が揃っていない場合は、より基本的な読書会（Agile Testing Condensedなど）から入り、共通言語を作るところが必要になる。
- Agile Testing / Holistic Testing の考え方はチーム全体で品質を考えるうえで有効
- DevOpsループ全体が品質とテストの対象であり、すでに設計ワークやバグバッシュなど実践している活動も「テスト活動の一部」という再定義ができる。
- これにより、メンバーが「自分たちが既にやっている取り組みは実はテストの一環だったのだ」と認識し、より積極的に参加しやすくなる。
- ビジネスチームとの連携や期待値調整が課題となりやすい
- ワークショップで顧客目線の付箋は多数出たが、「ビジネス的にどこまでOKか」という視点はカバーしきれなかった。
- 品質に関する優先度やリスク判断をするうえで、Bizとの連携は必須になる。
5. 今後の展開
今回サービスチームで得られた学びを、今後ほかのチームに横展開するときに考えているアプローチをいくつか挙げます。
- チーム品質に対する理解度に応じたメニュー選択
- チームが主体的に意見を持てない場合は、まず読書会を通じて共通言語を作る。
- ある程度成熟している場合は、今回のように「品質を考えるワークショップ」を行い、より抽象度の高いテーマをディスカッション。
- Biz⇔Dev連携の強化
- 期待値をすり合わせる場（品質レベル合意ミーティングなど）を設置する。
- 必要に応じてQAがコミュニケーションの緩衝材となる。
- プロセスへのテスト組み込み
- Discoverフェーズ（要件定義やアイデア検討）からすでに「利用者の視点でどんなリスクや期待があるか」を考え、ペルソナを用いたテストを取り入れる。
6. まとめ
今回は、QAエンジニアとして携わった中で、「チーム全体で品質を考える文化づくり」を進めるために実施した座学・ワークショップ・設計ワーク参加の事例を紹介しました。
- サービスチームのフィードバックをご紹介します
- 私たちのチームは新規プロダクトの立ち上げフェーズということもあり、各職種が暗黙的もしくは場面ごとにスピードと品質をトレードオフしながら進んできていました。このタイミングで広義で「品質」を捉え、チームでディスカッションできたことは非常によい機会だったと思います。（Designer）
- 自分はエンジニアなのでテストと聞くとプロダクトの機能をテストするというイメージが強かったのですが、そこにとどまらずプロダクトライフサイクル全体が品質・テストの対象となるという考えは品質を考える上で重要なポイントであると感じました。各ポイントで何を重視してどういったアウトプットを期待するかというところをチーム全体の共通認識として持ちながらプロダクト開発を進めていきたいと思いました！（Engineer）
- 品質への共通理解のために一定の時間を確保したことで、チーム全体を俯瞰して見た際のStrong/Weakポイントを明らかにすることができました。品質ワークを実施したことで、各メンバーが職種を超えて品質に対する考え方をオーバーラップさせながら、健全かつ継続的にサービスに向き合うための土壌ができたと感じています。また、EM個人のミッションとして、LEADING QUALITYの概念をチームを超えて組織にインストールしていきたいという思いを新たにできました。(Engineering Manager)
- 『品質』という人によってとらえるものが異なるキーワードについて、チームとして初めて意識することができました。ワークショップをやってみて、すでに自分たちの中でできていることも認識できました。一方で、ビジネス観点での品質への理解が浅いことがわかり、チームとして認識できていない弱みに向き合うことができたことは収穫でした。これからチームの規模が拡大して、今以上に経験やスキルのバラエティが広がる中で、プロダクト開発チームとして『品質』を共通言語にしていく重要性を実感できました。（Product Manager）
最初からすべてのチームを巻き込もうとすると、時間的にも内容的にもハードルが高くなります。まずは一つのチームで試し、成功や失敗、課題などを明確化したうえで次の施策へつなげるやり方がおすすめです。
今後はBizチームや他のサービスチームとも連携し、カミナシ全体としての品質文化を醸成していけたらと思っています。
最後までお読みいただき、ありがとうございました。
