【セミナーレポート】「チームスピリットのアジャイル開発における品質保証~チームの形成から現在まで~」

【セミナーレポート】「チームスピリットのアジャイル開発における品質保証~チームの形成から現在まで~」

2019年8月30日(金)、北海道札幌市にてソフトウェアテストシンポジウム 2019 北海道(JaSST'19 Hokkaido)が開催されました。「マインドアップ ~テスト設計技法を知っていたら十分と思ってないかい?~」というテーマのもと、様々な事例紹介やワークショップが行われました。

ビジネススピードが加速し続ける今、変化に柔軟にかつスピーディーに対応できるソフトウェアが求められています。開発チームにとっては、プロダクトの品質を保ちながらも、短い開発サイクルを実現する仕組みづくりが不可欠になっています。変化に素早く対応する必要性から、アジャイル開発に取り組む企業が増えていますが、開発プロセスにおける品質保証体制への取り組みについては、まだベストプラクティスが確立されておらず、企業によってさまざまなアプローチを行っているようです。

本シンポジウムでは、チームスピリットQAエンジニアの生井が登壇し、「チームスピリットのアジャイル開発における品質保証〜チームの形成から現在まで〜」というテーマでチームスピリットの事例について語りました。

<講演>アジャイル開発における品質保証体制の構築:株式会社チームスピリット QAエンジニア 生井龍聖

チームスピリットではスクラムによるアジャイル開発を行っています。私がチームスピリットに参画した2017年当時は、アジャイル開発経験が少ないメンバーでチームが構成されており、十分な品質保証体制がとられていませんでした。そこから現在に至るまで、開発チームはその組織の規模や状態によって異なる課題に直面しました。今回は組織規模を「形成期」、「統一期」と2つの段階に分け、それぞれの段階における取り組みについてご紹介します。

DSC_0589.jpg

「形成期」の取り組み

【課題】チームが10人未満の規模だった「形成期」。機能別チームに分かれて開発をしていたものの、チーム間での情報共有ができておらず、チーム間のパフォーマンスに顕著な差がありました。また機能毎のテストのみを実施しており、機能をまたがるテストはありませんでした。QAエンジニアがいなかったため、十分な品質保証体制が取られておらず、プロダクト全体の品質についても判断できる状態ではありませんでした。

【施策】私自身がすべてのスクラムイベントに参加して情報収集し、自らがQAエンジニアとスクラムマスターを兼務することで解決を図りました。職務を兼務する「ねらい」は、スクラムマスターとしてまずスクラムをチームに根づかせること。スクラムマスターとしては、機能毎に細かく分かれていたチームを統一し、開発とテストを分けて考えずに、チーム全体で品質を意識して開発をすることを意識させました。QAエンジニアとしては、4ヶ月の開発サイクルで実施するテスト計画を決め、テスト実施、インシデント分析などプロダクトの「透明性」を確保することに努めました。

【施策の結果】テストプロセスにおいては、特に計画・テスト実施・評価&レポートの段階をしっかりと押さえることで、スクラム開発プロセスに品質保証体制を融合する仕組みが動き始めました。具体的には、まずテスト計画やインシデント定義を通してテスト対象・抽出対象を明確にし、その後、QAエンジニア先導によるテスト設計・実施を通して定義したインシデントを抽出します。最後に結果を評価及びレポートし、チームに課題をフィードバックすることで、その課題を次の開発計画・テスト計画に組み込みます。スクラムプロセスとテストサイクルの融合は、現在の品質保証体制の考えの基礎になっています。

スクラムマスターとQAエンジニアを兼務することで仕事量が倍になるという懸念があるかもしれません。しかし、スクラムマスターは開発プロセスを整理する仕事であり、QAエンジニアは品質をリードする仕事、つまり必然的に開発状態全体を見る役割を持つため、この2つの職種はかなり親和性が高いと言えます。開発プロセス全体を視野に入れて品質保証体制を整え、プロダクトの透明性・開発の透明性を高めるという意味では、スクラムマスターとQAエンジニアを兼務するメリットは非常に大きいと考えられます。

チームスピリットの開発チームが理想としているのが「スウォーミング」です。スウォーム(swarm)とは、群がるという意味がありますが、ひとつのタスクにチーム全員が取り組むことで、プロダクト開発のリードタイムを短くし、メンバー間での情報共有やスキル共有を高速で行うことを目指しています。チーム全員で開発とテストに取り組むことでチームとしては「未テスト」の在庫を抱えずに済み、個人としては「T型」のスキルを身につけられるというメリットもあります。

「統一期」の取り組み

【課題】チームが20人〜30人規模に拡大した「統一期」。「形成期」においては品質保証体制を構築することができましたが、新メンバーの受け入れがうまくいかない、人数増加からチームを分割しなければならない、などの課題が表面化していました。さらにQAエンジニアも、これまで一人で担当していたところから、チームでの品質保証体制に変えていく必要がありました。

【施策】改めてスクラムチームの仕組み化を行い、チーム内の価値観や行動規範を明文化しました。属人化していたコードに関しても規約を作成し、誰でもがすぐに理解・修正できるように標準化を図りました。また、人数が増えたQAエンジニアを組織化し、チーム内の役割と職務内容、キャリアパスも明確化。複数のQAエンジニアでテストサイクルをまわすことができるような仕組みを構築しました。

【施策の結果】インシデント管理の事例で紹介したように、仕組みづくりを通して人数を増やしながら開発ができる「再現性」を獲得するとともに、形成期・統一期を通して、スクラムのサイクルにあわせた品質保証体制を構築することができました。2019年4月には、今回チームで定義した優先度最高レベルの障害を出すことなくリリースすることができました。

そして現在......

現在、日本とシンガポールの2拠点4つのスクラムチームで開発を進めています。さまざまな仕組みを整えたことにより、ベテランだけではなく若いエンジニアも活躍できるようになりました。今後は、さらに開発規模をスケールしていけるように仕組みを磨きこんでいきたいと考えています。

<情報交換会>

講演後には、別室にてポスター展示と情報交換会がありました。講演を聞いてチームスピリットの開発体制に興味を持った参加者が、ブースに訪れ、熱心に質問をしていました。

DSC_0598.jpgのサムネイル画像

  • 実際にどのようにテスト計画を立てているのか
  • QAエンジニアとプロダクトオーナー、スクラムマスターの関わり方、役割分担などはどうなっているのか?
  • 「形成期」と「統一期」で一番大変だったことは、どのようなことか

など、いろいろな質問をいただきました。短いサイクルでテストとリリースを繰り返す仕組みを作ることが求められている今、アジャイル開発の中で、どのような品質保証体制を構築すれば良いのか、その施策について迷っている企業も多いのではないでしょうか。チームスピリットのようにスクラムマスターとQAエンジニアを兼務するという事例は、まだあまりないようです。チームスピリットの開発チームは、時代の変化を見据え、日々仕組み化や効率化に取り組んでいます。今回の事例紹介が、何かのヒントやきっかけになれば幸いです。

一緒に働く仲間を募集しています!

チームスピリットでは、通年でQAエンジニアを募集しています。今回登壇した生井を中心に、世界で通用するプロダクトを支えるQAチームの構築を進めています。自社サービスのQAやアジャイル×QAに挑戦してみたいQAエンジニアのみなさん、少しでも興味を持っていただけましたら、下記ページよりご連絡ください!

チームスピリット採用ページはこちら

TeamSpiritの最新情報をお届けします

お客様の個人情報の取り扱いについて「プライバシーポリシー」をお読みいただき、
同意いただける場合にのみお申し込みください。

担当者に相談する

導入に関するご質問や
実際の画面操作を見ながらの製品デモまで
お客様のご連絡をお待ちしております

無料トライアル

正式版と同一機能・操作が可能な
無料版TeamSpiritを30日間ご提供しています
まずはTeamSpiritを体験してください