2024.06.25
さまざまな現場でQA業務に携わっている方々の「声」をお届けする『隣のQAに聞く！』。「DX」といったキーワードに代表される社会のデジタル化が推進されている今、ソフトウエアの品質への関心も高まりを見せており、QA・品質向上の重要性が増しています。そんな中、他のチームでは、どのようにQA業務を実施しているか、気になっているエンジニアの方も多いのではないでしょうか？
本記事では、QAに取り組むきっかけや「モチベーション」などを伺い、皆さまにお伝えします。今回はSansan株式会社の横田明浩さんに同社のQA活動についてお話いただきました。
※実際のインタビューはオンライン形式で実施しています。写真撮影時のみマスクを外しています。
今回インタビューを受けてくださった方
- 横田 明浩 氏
Sansan株式会社 技術本部 Quality Assuranceグループ
グループマネジャー
開発エンジニアとして営業DXサービス『Sansan』や名刺アプリ『Eight』などの開発に携わった後、2019年9月、『Sansan』QAチームの発足に立ち会う。現在は、同社プロダクトのQAを担う技術本部 Quality Assuranceグループのグループマネジャーとして同社QA業務を牽引している。
- もくじ
1．QAに挑戦したのは「開発者にのびのびと開発してもらいたかった」から
――QAを担当するようになったきっかけは？
私の場合は「たまたま」です。Sansan株式会社のほぼ創業期からWeb開発のエンジニアとして在籍して 10年がたち、会社の体制変更の中で上司に打診されたのがきっかけでした。それまでの開発で培ったサービス全体の業務知識があったので、広い方面に目を配ることを期待されたのだと思います。
話を聞いて、今いるメンバーがのびのびと開発できるようにするために自分の知見を提供したいと考えるようになり、QAに挑戦してみようと考えました。飾った言い方をすれば、今まで作り込んできたものを引き継いで面倒を見てくれるみんなへのある種の恩返しという感じかもしれません。
――品質保証チームを作った背景にはどのようなことがあったのでしょうか？
当時、Sansanプロダクトには品質保証の機能が存在していませんでした。開発者の自助努力で品質が維持されていたのです。しかし、プロダクトのフェーズとして徐々にユーザーが増加する状況にあり、品質保証を役割とする専任者がいないと、開発が回らなくなるだろうという懸念がありました。その流れで品質保証チームが作られたわけです。ですから、今後は社内での重要性が増す一方だと理解しています。
――現在はどのような体制でQA活動に取り組まれていますか？
当社はマルチプロダクト体制で、複数のプロダクトを同時に開発しています。まだ、全てのプロダクトにQAが入ることができておらず、各プロダクトに専任のQAメンバーをつける体制を整えているところです。現在は、全社の事業の優先度とQAチームの体制が合ったタイミングで、入れそうな順で対応しています。
チームは、プロダクトごとに正社員と業務委託の方で組んでいます。プロダクトによって異なりますが、チームは2人から7～8人前後といった規模感ですね。トータルで30名ほどのメンバーがいて、プロダクトの拡大に応じて増え続けています。
――他社のQA活動と比べて、御社ならではの「ここが違う」というポイントがありましたら教えてください。
他社の体制について詳しいわけではないので、あくまでも自分が感じていることになりますが、当社は先ほど話したマルチプロダクト体制で、複数のプロダクトがいくつものフェーズで成り立っているのがポイントだと思っています。「0→1」のフェーズから、「1→10」「10→100」のフェーズまでのプロダクトが存在しているのです。
くわえて、開発文化がプロダクトによって異なっています。例えば、アジャイル寄りのスタイルで開発を進めているところもあれば、ウォーターフォールに近いスタイルで開発を進めているプロダクトもあるといったことです。さらにビジネスモデルも「BtoB」「BtoC」があります。このように多種多様なバリエーションのプロダクトのQAにチャレンジできるのが当社QAの面白いところですね。
2．問題を未然に防ぐことができたとき「やりがい」を感じている
――現在、QA業務をされていて、どんなときに「やりがい」を感じますか？
私は現在、マネジメントの役割を担っています。実際には、実務に当たるのが好きなので現場よりの話になりますが、案件の仕様などの内容を聞いた段階で「これが抜けているのでは？」といった点を見つけることがあります。
テスト開始前に考慮漏れや問題点が指摘できて、問題を未然に防いでテストに持っていけると「やったぞ」と思います。開発があらかじめ問題を把握し、うまく回る形に持っていけるとうれしいですし、やりがいを感じますね。
――QA業務を進めていく上で大事だと考えておられるポイントは何ですか？
経験則になってしまいますが、不具合はテストをしてないところから出ることが多いと感じています。そういう潜在的な不具合が、あとから見つかって問題になると、開発側は直す以外の選択肢が取りにくくなります。そのため、QAチームから気をつけるべき点の情報を出して、開発者がその状況に能動的に対応できる状態を作っていきたいと思っています。
自分たちで主導権を持ってコミュニケーションを取ったり、開発したりできる状況に持っていってあげたいと思っています。
――現在、課題だと感じられていることを教えてください。
これはマネジャーとしての視点になりますが、メンバーそれぞれの進捗状況や情報を簡単にキャッチアップできる状況を作る必要があると思っています。
これまでは、誰が何をやっているかは担当者と直接コミュニケーションするだけでわかるケースが大半でした。しかし、プロダクトの規模が大きくなり、その数もメンバーも徐々に増えて、話を聞かなければいけない人が増えてきたのが理由です。
何かしらのWEBサービスを利用して、ガントチャートなどを使って進捗状況を表現し、直接、会話をしなくてもある程度の全体状況がキャッチアップできる状態を作り、属人性を薄くしていこうとしています。今の機動力を落とさない開発スタイルとQAのスタイルを作って、備えおくことが大切です。皆がパフォーマンスしやすい状況を作っていこうとしています。
