2025.04.21
働き方が多様化し、企業が生産性向上と従業員の働きやすさを両立させることが求められる中、業務システムのあり方も大きく変化しています。
株式会社チームスピリットは、勤怠管理や経費精算、工数管理といった社員が毎日使う業務を一元化し、企業の成長と人的資本の生産性の向上を支えるクラウド型プラットフォーム「TeamSpirit」を提供しています。
このプロダクトの品質を支えているのが、同社のQA（品質保証）エンジニアです。
今回は株式会社チームスピリットでQAエンジニアとして働く、岡内 裕希氏に同社のミッションや品質向上への取り組み、QAエンジニアのやりがいについてお伺いしました。
今回インタビューを受けてくださった方
- 岡内 裕希 氏
株式会社チームスピリット シニアQAエンジニア
2021年6月に株式会社チームスピリットに入社。QAエンジニアとしてテストの自動化やプロセス改善に取り組み、複数のチームと連携しながら品質向上を推進している。前職ではSIerや第三者検証会社での経験を積み、長期的にプロダクトに関わるQAの重要性を実感。社外活動として「JaSST Online」の実行委員も務め、QAの普及と発展を志している。
- もくじ
1. 単なるシステムではなく、企業の成長や人的資本の生産性の向上を支援するプラットフォームを目指す
――――TeamSpiritについて教えてください。
TeamSpiritは、勤怠管理、工数管理、経費精算、電子稟議、社内SNS、カレンダーなど、社員が毎日使う社内業務を一元化したクラウドサービスです。
複数の機能が1つのプラットフォーム上で連携しているので、出社から退社までの働く人に関する活動情報が自然と集まる仕組みになっています。
働き方を可視化できることで、従業員の生産性や働き方の改善、ガバナンス強化に貢献し、人的資本経営の実現を支援するサービスとなっています。
――――会社として目指している・取り組んでいるミッションは何ですか？
チームスピリットは、「すべての人を創造する人に」 というミッションを掲げており、これに基づいたプロダクトを開発しています。
日本の少子高齢化と人口減少により働き手が減り、社会の活力維持が危惧されるなか、チームスピリットは「日本の労働力の供給力不足」という社会課題に対し、「人的資本の生産性の向上」の実現を通じて、その解決に貢献することを目指しています。
例えば、TeamSpiritで取得できる一人ひとりの働くログを活用し、残業時間を正確に計算し可視化することで長時間残業を抑止したり、個人だけではなく、チーム、組織単位で、成果を出す業務に時間を使えているのかだったりといった視点で、生産性向上を支援できるようにしたいと考えています。
単に労働時間の管理や、36協定を守るといった話ではなく、もっと広い視点で、企業の成長や一人ひとりの働き方を支えるプラットフォームとして、ミッションの達成に取り組んでいます。
2. スクラムチーム所属のQAとQA専門チームの連携で品質保証を強固なものに
――――御社のQA業務の位置づけ・ミッションを教えてください。
機能やモジュールごとにスクラムチームが存在しており、その中にQAエンジニアがいて、開発の各フェーズで品質向上に関与する仕組みになっています。各スクラムチームには開発者、QA、プロダクトマネージャーが所属し、開発の初期段階から仕様の議論に参加することで、品質に関するリスクや検討すべき点を早期に洗い出す体制を整えています。
私が所属するチームは少し特殊で、QAのみで構成されています。通常のスクラムチームとは異なり、横断的に関わりながら、全体の改善を進める役割を担っています。
例えば、開発の終盤に実施するリグレッションテストの最適化や、E2Eの自動化、テストプロセス全体の改善などに取り組んでいます。
また、プラットフォームのバージョンアップによる影響確認も行っていて、例えば、Salesforceのプラットフォーム上で動作しているため、バージョンが上がったときに、アプリケーションが正しく動作するかどうかを事前に検証しています。そして時には、遊撃隊のような形でスクラムチームにサポートに入ることもあります。
このように、スクラムチームのQAが開発プロセスの一環として日常的に品質向上に関与し、一方で専門的なQAチームが継続的なプロセス改善や技術的支援を行うことで、品質保証の仕組みをより強固なものにしています。
3. QAだけでなく開発チーム全体で品質向上に取り組む
――――QAの視点から、サービス品質向上のために取り組んでいることを教えてください。
取り組みとしては、大きく2つの柱があります。1つは「品質をQAだけのものにしない」、もう1つは「継続的なプロセス改善」です。
まず、1つ目はQAが品質をすべて担うのではなく、開発者自身にも品質の責任を持ってもらうという考え方です。例えば、開発者自身に機能テストを実施してもらうことで、プロダクトに深く向き合う機会を作っています。そうすることで、開発者自身が「この仕様で本当に問題ないのか？」、「意図した通りに動作するのか？」といった視点を持てるようになります。
また、QAが監査的なテストや、より高度な検証を行うことで、チーム全体の品質意識を高めています。そのため、新しく入社したエンジニアや、テスト経験が少ない開発者向けに、テストの基礎を学ぶためのトレーニングも実施しています。
――――QAだけが品質を保証するのではなく、開発チーム全体で品質に責任を持つ文化を作ろうとしているのですね。では、もう1つの「継続的なプロセス改善」についても教えてください。
「継続的なプロセス改善」についてですが、プロダクトの複雑化や環境の変化に対応するために、QAのプロセスも常に見直し、改善を続けています。例えば、昔からあるプロセスだからといって、それをそのまま維持するのではなく、今の状況に合っているかどうかを考えながら適宜見直していきます。
特に、技術の進化や法律の変更があると、それに対応するためのプロセスも変えなければなりません。例えば、TeamSpiritは経費精算機能を提供しているため、インボイス制度や電子帳簿保存法の改正などに対応しなければなりません。こうした変化に適応できるように、プロセスを柔軟に調整しています。
また、プロダクトごとに求められる品質基準が異なるため、すべてのプロダクトに一律のプロセスを適用するのではなく、それぞれに最適なテスト戦略を考えながら運用しています。
4. 社内勉強会で個々の知識を深めることでリソース不足を解消していく
――――現在抱えている課題や、今後改善していきたい点はありますか？
直面している課題としては、大きく二つあります。一つはQAのリソース不足です。もう一つはプロセスの最適化です。
まず、QAのリソース不足についてですが、これは単純に人手が足りないという問題です。開発したい機能や改善したい部分がたくさんあるのですが、それをカバーするQAの人数が不足しています。特に、スクラムチームごとに専門領域があるため、単に他のチームから人を回せば解決するわけではなく、それぞれのプロダクトに詳しいQAが必要になるので、課題になっています。
もう1つのプロセスの最適化についてですが、TeamSpiritは複数の機能を提供しているため、それぞれのプロダクトごとに求められる品質基準が違います。しかし、現在のプロセスは基本的に統一されているため、一部のプロダクトにとっては過剰なプロセスになっていたり、逆に十分ではなかったりすることがあります。そのため、プロダクトごとの特性に応じた柔軟なQAプロセスを作っていくことが課題となっています。
――――今まさに取り組んでいる課題ということですね。では、QA担当として工夫されていることはありますか？
E2E（End-to-End）テストの自動化を進めることで、繰り返し発生するテスト作業を人の手を介さずに行えるようにすることに注力しています。
また、QAの業務において専門性が高い分野が多いため、知識の属人化が発生しやすいという課題もあるので、社内で勤怠計算に関する勉強会を開き、チーム全体の知識レベルを底上げする取り組みを行っています。
この勉強会は、私の先輩であるQAエンジニアが主導し、勤怠計算に関する基本的な知識から実践的な内容まで幅広く共有する場となっています。やはり、各分野の専門性が高いため、どうしても属人化が発生しやすいという背景があります。しかし、属人化そのものが必ずしも悪いわけではなく、「その領域の専門家がさらに知識を深めていく」というのは、プロジェクト全体としてもメリットがあることだと考えています。
ただし、専門家しか対応できない状態になってしまうと、業務の負担が偏ったり、長期的な運用が難しくなったりするので、ある程度の知識はチーム全体で共有しておくことが重要です。
そのため、「得意な人がより得意な領域を伸ばしつつ、それ以外のメンバーも基本的な知識を理解し、サポートできる状態を作る」というバランスを意識しています。勉強会の開催をはじめ、社内でのナレッジ共有を推進しながら、知識の属人化を防ぎつつ、それぞれの専門性を活かせる体制づくりを進めています。
私自身も、この勉強会を積極的に活用しながら、専門知識を深めつつ、他のメンバーと協力していくことを大切にしています。
5. 周囲への「気配り」がシステム品質向上にもつながる
――――QA担当者として大切にしていることはありますか？
そうですね、私がとても大事にしていることとして、「関わる人への気配り、目配り」を常に意識しています。プロダクトを作るのはあくまで「人」であり、いくらお客様に対して「強いチームを作るためのプロダクト」を提供しようとしても、作り手である私たち自身が健全な状態でなければ、真に価値のあるものを生み出せません。
特に、リモートワークが主流の開発環境では、対面でのやり取りが少ない分、コミュニケーションの取り方が非常に重要になります。
例えば、ミーティングの際には、単なる会話の内容だけでなく、話し方のトーンや言葉の抑揚にも注意を払っています。普段と少し違う様子が見られたときには、「何か悩んでいることがあるのかな？」と気づくことができるよう、意識的にアンテナを張っています。
また、雑談の中で出てくる興味関心にも耳を傾け、相手の関心ごとを知ることも大切にしています。それによって、単なる業務上のやり取りだけではなく、相手の価値観や考え方を理解し、よりスムーズな関係を築くことができます。
こうした日常のコミュニケーションを丁寧に積み重ねることで、チーム全体としてもお互いを理解し合い、より良いものを作るための土台を築けるのではないかと考えています。
6. お客様にとっての「価値」を考え抜き、届けるのがQAのやりがい
――――QAの仕事のやりがいについて教えてください。
やりがいを感じるのは、普段から「本当に大事なことは何か？」を徹底的に考え抜き、それをQAとして実現していくプロセスそのものにあります。まるで頭を逆さまにして絞り出すように、さまざまな視点から深く考え、調査し、最適な形を探ることが求められます。
そして、その結果が実際にプロダクトに反映され、プロダクトマネージャーや開発チームと議論を重ねながら改善されていく過程を見ると、大きな達成感を感じます。
さらに、お客様から「この機能が使いやすくなった」、「ここが改善されてとても助かる」といったフィードバックを直接いただけると、「やった！」という強い喜びがあります。
やはり、考え抜いたことに対して良い反応が返ってくると、本当に嬉しいですね。単に「ものを作る」ことがQAの目的ではなく、それを「どう使われるか」まで考えることが大切です。設計者の意図通りに動くだけではなく、お客様にとって本当に使いやすいものになっているかどうかを突き詰めて考え、実現していく。それがQAの最大の魅力だと思っています。
――――最後に、QAとして働く方々にメッセージをお願いします。
スポットライトが当たるような派手な印象は、QAという仕事にはあまりないのかもしれません。また、「できて当たり前」と思われがちで、プロダクトの一部として目立たない存在になりやすい側面もあります。しかし、その分、責任のある仕事でもあります。
品質とは何なのか、お客様にとって本当に良いものとは何なのかを深く考え抜き、それを形にすることで、プロダクトを通して価値を提供することができます。この過程そのものが、とてもやりがいのある仕事だと感じています。そのため、「何が大事なのか？」を突き詰めて考えるのが好きな方や、それを形にすることに情熱を持てる方には、QAの仕事は非常に向いていると思います。
また、QAとしてさまざまなことにチャレンジしたい、成長していきたいと考えている方がいれば、ぜひ一緒に挑戦したいです。当社もQAのリソース不足という課題があるので、興味のある方がいればぜひお声がけいただけたら嬉しいです。
私はチームスピリットの一員であると同時に、QAという仕事そのものが大好きなので、社外活動としてJaSST Online※の実行委員もしています。（※NPO法人ASTER（ソフトウェアテスト技術振興協会）が運営するソフトウェア業界全体のテスト技術力の向上と普及を目指すソフトウェアテストシンポジウム）
QAという領域で挑戦したいことがある方がいれば、ぜひ気軽にお声かけください。
―――――本日はありがとうございました。
