システム横断プロジェクトの品質計画

こんにちは、カトです。弥生でQAエンジニアをしています。この記事は弥生 Advent Calendar 2021の5日目エントリーです。

結論

弥生は、昨年2020年に記帳代行支援サービスを開始しました。
記帳代行支援サービスは、複数のシステム・複数のソフトウェアで構成されるサービスです。
弥生ではシステム横断プロジェクトと呼ぶことが多い、シームレスなサービスの裏側のおはなしです。

私は、QAエンジニアとして、記帳代行支援サービスに関わりました。 「かんたん、あんしん、たよれる。」の裏側では、複数のシステム・複数のソフトウェアから成り立つサービスの品質をどのように見ていくのか、何をやって何をやらないのかを決める必要がありました。

そこで、各テストフェーズでどのようなテストをすべきかをまとめました。それがこちらです。 改めてまとめたものをみると、難しいことは何も言っていないように思えます。
しかし、これを作成するまでに、いろんなことがありました。

本当に、いろんなことがありました……？

背景

U字プロセス

弥生の製品開発の多くは、開発プロセスとしてU字プロセスを取り入れています。
（参考：エンジニア採用｜採用情報｜弥生株式会社）
このU字プロセスは、弥生入社時に導入研修で学びます。日々の業務でもプロセスに準拠しているかどうかを判断基準としています。
弥生のエンジニアには浸透しているプロセスです。

「いつもの感じでよろしく」で、だいたい伝わる

システム横断プロジェクトで発生したこと

記帳代行支援サービスにおいても、「いつもの感じでよろしく」で済むものだと思っていました。
ところが、「そっちのシステムでテストしてると思ったからこっちでは見てないよ」「そっちでもやってるの？こっちのシステムでテスト終わってるよ」などなど、いろいろなトラブルが発生します。

特に、問題になったのが2点。

• システム間のインターフェース誤りにより、統合テスト開始直後にテストが中断してしまう
  結合テストでは、単一のサービスを対象にしたを実施するため、連結するサービスはダミーシステムを使ってテストしています。 このため、個別のシステムとしては動作していても、いざ連結してみると想定していた挙動にならないことが発生し、テストを中断せざるを得ないことがありました。

• 準備や設定が複雑なシステムを除外して、システムテストを実施してしまう
  システムテストは最終テストフェーズであり、リリース間近におこなうため、期日に追われています。 設定が複雑だったり、準備工数がかかったりする手順は、前フェーズでテストしているはずだから大丈夫だと思って省略させてしまいがちでした。 省略に根拠がないので、システムテストが貧弱になっていきました。

これらの問題を解決しなければいけません。

奮闘

文章にしてみた

どのフェーズのテストで何をしなければいけないのか、品質計画として文章化していきました。

一生懸命つくった品質計画書のイメージ

確認が必要なときには、集まってミーティングをしました。
フェーズごとに実施するテスト内容を品質計画で明示する前と明示した後で比較すると、各段に認識齟齬がなくなりました。
しかし、品質計画として書いてあるから全員が熟読している、というわけではありません。途中参加で読めていない人もいるし、読んだけれど忘れてしまったという人もいます。
そのつど確認をしていましたが、もう少しよりどころになるようなものが必要だと思うようになりました。

図にしてみた

「よりどころになり、これを見れば責任者に細かく確認をとらなくても安心して確認できるようなものがほしい」と思ってつくったのが冒頭の図です。
もう一度貼っておきます。
この図をつくって共有したところ、記帳代行支援サービスに関係するメンバーそれぞれがこの図を見ながら会話ができるようになりました。

問題になっていた2点に対しては、このような変化がありました。

• システム間のインターフェース誤りにより、統合テスト開始直後にテストが中断してしまっていた
  Aさん：「統合テストの前に連携テストする必要がある。いつ頃テストできそう？」
  Bさん：「〇月×日にテストアップ可能になる予定。」
  Aさん：「両システムがテストアップして、連携テスト後に、統合テスト開始ですね。」
  ⇒システム間のインターフェースに着目した連携テストを実施することで、統合テスト開始直後の中断がなくなりました。

• 準備や設定が複雑なシステムを除外して、システムテストを実施してしまっていた
  Aさん：「心配だから統合テストで2つ先のシステムまで確認しておく？」
  Bさん：「対象のシステムと直接連携していないシステムは、統合テストの確認対象じゃないよ。」
  Cさん：「システムテストで確実に実施するよう申し伝えておこう。」
  ⇒システムテスト内容が明確になり、最終フェーズとして有効なテストができるようになりました。

結果

「記帳代行支援サービスのテスト、どう考えればよいの？」というときに、よりどころになる図ができました。
そして、この品質計画の図は、記帳代行支援サービス以外でも複数のシステム・複数のソフトウェアから成り立つサービスでのテストを考えるときに使える内容になっています。

私は、2019年から記帳代行支援サービスに関わり、2020年にサービスの開始、2021年には記帳代行支援サービスのバージョンアップに立ち会いました。
まだまだ記帳代行支援サービスは進化していきます。しかし、私がQAエンジニアとして記帳代行支援サービスに関わるのはここまで。

私は、QAエンジニアとして別のサービスに参画し始めました。記帳代行支援サービスでつくった品質計画の図をさらに進化させ、今以上に弥生の資産となる品質計画をつくっていきます。

お知らせ

弥生では「弥生会計」に限らず、さまざまな製品・サービスに関わることができます。
一緒に、弥生の製品・サービスの品質を追求してみませんか？

herp.careers