SaaSベンダーとしての品質保証ってどうなるの？
アジャイル時代のQAマネージャー#4
これはウイングアーク１ｓｔ Agile and DevOps Transformation Stories のAdvent Calendar 2022、2022年12月23日の投稿です。
Happy Merry Christmas！！いかがお過ごしですか？
思えば、去年のアドベントカレンダー記事でQMファンネルを使ったQAキャリアの記事を書きましたが、もう一年経つのですね。時間の早さに驚いています。（この時も本社でクリスマスデザインの写真撮ってました）
キャリアの話は引き続きアップデートしているので、どこかでまた詳細を説明したいと思います。
今回の記事は、「SaaSベンダーとして、どう品質を保証していくのか？を話してほしい」という社内からのリクエストがあったので、その内容をお届けします。
ドヤリング大会
突然ですが、「ドヤリング大会」という会を社内で定期開催しています笑
ウイングアーク１ｓｔにはBusiness Document事業（以降、BD事業）があり、「帳票DX」として、帳票ソリューションのデジタル化に力を入れています。
BD事業では、関係者が定期的に新潟に集まり、事業内で活躍したメンバーやグループにその活躍内容を大いに自慢してもらい、みんなで褒め合おう！という会。正に「ドヤリング大会」という会を開催しています。
私、個人的に、BD事業が開催するこの会、大好きなのです。
ということで私もBD事業とは密接に関係していることから、ドヤってきました。
ところでSaaSベンダーとしての品質保証ってどうなるの？
それでは本題です。
実はBD事業のステークホルダーとは、プロダクトの品質について色々語り合うことが多く、事業責任者と品質管理責任者という立場から、意見を出し合いながらお互いに学び合っている。そんな良い関係性でもあります。
ある時ステークホルダーから「もっとわかりやすい品質の話をしてほしい」と言われました。
どうやら、私の品質の話ってどうも分かりにくいようです。
今までオンプレミスプロダクトの品質を保証する活動はなんとなくわかったが、SaaSベンダーとして今後DX化を推し進める中で、品質の観点ではどういう方向性や戦略を持っているのか？エンジニアだけでなく、事業内のみんなが理解できるようにドヤリング大会で説明してほしい。
といったリクエスト内容です。
思えば、確かに開発プロジェクト内や、QAチーム内では品質について語ることはありますが、営業やカスタマーサクセス等を含んだ、事業全体で関わりを持つ人を対象に品質を説明したことはありません。さらに言えば自分が活動しているコミュニティも、アジャイル開発系やテスト系なので、もしかすると今まで使っていた言語を変えて説明するのが良いのかも。
ということで、今回はあまりマニアックな説明ではなく、なるべくわかりやすく書きたいと思います。
プロダクト品質とプロセス品質
色々考えた結果、「品質はプロダクト品質とプロセス品質の両面から確保する」といったテーマで説明することにしました。
プロダクト品質
先ずはプロダクト品質です。これはオンプレミスプロダクトもSaaSサービスも基本的な考えは変わりません。さらに言えば、従来のウォーターフォール開発でもアジャイル開発でもプロダクト品質の確保は変わらないと信じています。
基本的には品質ゴールをしっかりと意識して、テスト計画を立てて、段階的な品質確保をする。また段階的な品質確保の中では、テストを体系的に管理して、テストはできるだけ自動化する。と言った流れです。
それではいってみましょう。
品質ゴール
よく、「プロダクトの品質を計測するためのメトリクスは何か？」や、「何をもってプロダクトの品質は保証されたと言えるのか？」というテーマで議論されます。
この辺の話は答えのない世界でもありますし、議論し始めると品質工学のより深いところまで行ってしまって、「また難しいこと言ってるよ」とか「分かったようで分からない」と言ったようなフィードバックを受けることがあります。
我々が考える品質のゴールとは簡単に言うと以下のようなものです。
- ステークホルダーの気持ちに含まれている（ので話をよく聞く）
- デリバリーに関係する人全員（Whole-Team）が理解可能
- 品質についての基準（守るべき）や指針（目指すべき）について定義されている
- プロダクトやサービスによって定義は異なる
- 常に変化しアップデート可能
オンプレミスプロダクトに関してはプロダクト共通の品質ゴールを「品質基準」という名のもと定義しましたが、やはり深く考えていくとプロダクト毎に見直した方が良い部分はあります。
特にSaaSサービスにおいては、常に変化しながら成長します。そのため品質に関するゴールを作っても、市場が変化すれば品質ゴール自体も変化を求められます。とはいえ「変化するから品質ゴールをいちいち考えてもしかたがない」というと、そんなことはないはずです。関係者全員で議論し、全員が納得のいく定義は必要と感じています。
BD事業ではinvoiceAgentという、電子帳票プラットフォームを開発しており、サービスのラインナップもどんどん増えています。こういった環境で品質ゴールを作ることはかなりハードルが高いこととは思います。ですが、ステークホルダーの意見をよく聞き、製品ライフサイクルを理解し、事業として目指す方向や戦略、現在の立ち位置、そして「ここだけは絶対に外せない品質」を定義することにより、品質ゴールを言語化しました。
段階的に品質確保するプロダクト品質
「プロダクト品質は段階的に確保するモノ」という話は以前にもブログにまとめていますので、ご一読いただければと思います。
簡単に説明すると、従来のウォーターフォール開発では開発プロジェクトの最後のフェーズでテストしていました。ただ、SaaSサービスのような頻繁にリリースをする開発プロジェクトにおいては、開発プロジェクトの初期から品質保証活動に入り、段階的に確実に品質を確保していく仕組みになります。図に表すと以下のようなイメージになります。
ただ、このような形はさらっと書いていますが、到達するのは簡単ではなく、長い年月をかけて現在にたどり着きました。そしてまた変化していくとは思いますが、今はこの形がベストだと思っています。
この辺の歴史の話については、スクラムフェス札幌2021で詳しく話しましたので、以下のスライドを参照してください。
体系的なテストマネジメント
ここで言う「テストマネジメント」とは要件からテスト実行、そして改善して次の要件に行くまでの流れを管理する意味で捉えています。
わかりやすいように下の図で表します。（わかりにくいかもしれませんが...）
要件を分析し、品質ゴールに合わせた形でテスト計画を作ります。この時に機能と非機能に分けてると、テスト設計がしやすくなります。テスト設計ではテストレベルとテストタイプのマッピングのような形で考えます。テスト設計中に要件とマッチしないことが分かったときは、要件にフィードバックします。そしてテスト実行をして、結果を基に品質分析をします。品質分析する際は品質特性を利用すると第三者に説明がしやすくなります。品質分析の結果、改善が入り、別の要件が作成されます。この流れをしっかりとトレーサビリティをとって管理します。
テストの自動化
手動で行うテストは極力すべて自動化したいものです。つまり人間ではなくシステムにテストを実行してもらいたいです。加えて、一度テストを自動化すれば回帰的なテスト（リグレッションテスト）がしやすくなり、デグレード等のバグの発見が早くなります。
テスト設計では、テストレベル毎にテストタイプが定義されます。するとテスト自動化ピラミッドでいう、各層でのテスト自動化が可能なことがわかってきます。
テストの自動化は早く作れれば、それに越したことはありませんが、焦る必要はありません。例えば、リリースまでに手動で行っていたテストは、リリース後にでも自動化に取り組めば良いです。テストを自動化する際は極力テスト自動化ピラミッドの下位層に落とし込んであげるとメンテナンス性が上がります。
個人的には昔からAPIテストが好きで、システムテストのようなUI層で組みがちなテストも、よくAPIテストに落とし込んでいました。UI層のE2Eテストで自動化を組んでも、UIをガラッと作り直した時のメンテナンスコストが尋常じゃなかった時の経験がそうしています。
プロセス品質
Build quality in！（この言葉大好き）
品質はプロセスの中で作り込みます。これはたぶんアジャイル開発をする上で肝になると思います。開発プロジェクトの中で、我々が取り組んでいるプロセスを簡単に説明すると以下のような図になります。
この図の用語の説明は以下の通りです。
- Dev：開発エンジニア
- SET：Software Engineer in Test（テストを自動化するエンジニア）
- Test：テストエンジニア
- QA：QAエンジニア
- 機能KickOff：要件の内容と機能に落とし込む際の説明会
- MTP：マスターテストプラン（テスト計画書）
この図は要件毎の開発プロセスになります。先ず、要件がDevにて計画され、機能に落とし込まれたら、「機能KickOff」という要件がどのように機能に落とし込まれるかの説明会を開催してもらいます。その上で、SET、テスター、QAとでテスト計画を立てます。テスト計画が作成される間は、Devで仕様書を作成します。SET、テスター、QAは作成された仕様書をレビューして、テスト自動化フレームワークを作成したり、テスト設計をしたりします。作成されたテスト設計は関係者全員でレビューします。その後テスト実行し、品質を分析する流れです。
因みに基本的な流れは上記の通りですが、もちろん同時に進行するプロセスもあれば、前後するプロセスもあります。
以下はDr.Sumの開発プロセスですが、開発エンジニアとQAエンジニアが協力し合って、品質をプロセスで作り込むやり方を詳細に説明していますので、参照してみてください。
BD事業部のinvoiceAgentにおいては、開発部にDev、SET、Testの役割があり、SPQI部にQAの役割があるイメージになっています。しかし実際の開発現場では、SETとTestに関しては開発部とSPQIメンバーで協力し合いながら行っています。
リスクマネジメント
リリースサイクルが早くなればなるほど、リスクをしっかりとマネジメントすることが大事になります。
というのもリスクありきでリリースすることはよくあります。そこで大事なことはリスクは透明性を持っており、ステークホルダーを含めた関係者全員が把握していることです。またリスクは発生してから解決されるまでの状態を把握できることが望ましいです。
ただ、注意すべきことがあります。リスクに対して透明性を持った時、せっかく勇気をもってリスクを報告してくれたのに、犯人探しになる傾向があります。人ではなく問題に対して議論し、関係者全員がリスクの内容を理解して、責任を持つ必要があります。
これからのSPQI部
さて、ここまで長く書いてしまいました。
わかりやすい説明を意識していましたが、読み返してみると結局わからないかも…ですが、既にドヤリング大会で発表した内容ですので、これで押し通します！
色々書きましたが、ではBD事業内での今後のSPQIの活動はどうすれば良いのか？という話で終わりにしたいと思います。
はっきり言ってしまうと、組織としての立ち位置はあまり考えなくてよいでしょう。開発部門にテストに詳しいエンジニアがいれば、SETやテスターの役割も担えばよいし、反対にSETやテスターの人材が開発部門にいないのであれば、SPQI部門のメンバーがその役割を担うことができます。要は組織に囚われず、足りない役割があればお互いに補い合うことが大切です。
invoiceAgentの開発プロジェクトでは、開発部門に開発エンジニア、SET、テスターの役割を配置すると決めています。そうすると、SPQI部門としてはQAの役割を配置しますが、部門を超えてSETやテスターの支援ができればよいと思います。図に関単に表すと以下のようになります。
組織はより柔軟に、目的は事業に関係する全員が「品質と言えばプロダクト品質とプロセス品質の両面で確保できる」ことを理解し、お互いに協力し合える環境が望ましいと思っています。
おそらくそのためには、お互いにリスペクトし合える関係性だったり、SaaSサービスをより良い方向にするには忌憚のないフィードバックを言い合える関係性が必要だったりします。
もしかするとSPQI部の今後は、そういった環境づくりを目指すべきかもしれません。
宣伝
ハイヤリング
ここまで読んでくれた方は、ウイングアーク１ｓｔのQAがBD事業内では何を考え、どこに重きを置いてるか？なんとなくわかっていただけたかと思います。興味ある人、もう少し話を聞いてみたい人、一緒に働きたいと思った人はお気軽に連絡をください。先ずはカジュアル面談をしましょう。
JaSST’23 Tokyoでスポンサーセッションします
この度ウイングアーク１ｓｔは、JaSST’23 Tokyo プラチナスポンサー協賛企業になりました。
スポンサーセッションでは、ウイングアークQAの紹介、QAキャリアや体制の説明、マネジメント方法。また、開発プロジェクト現場で具体的にどういった品質管理や自動テストをやっているか、デモを含めて紹介したいと思います。
是非、遊びに来てください。
それでは！良いクリスマスを！
