こんにちは。UbieでQAエンジニアをしているharuです。
私は、「データプロダクト」を開発、運用するチームのQAエンジニアを担当しています。「データプロダクト」というのは、「データそのものを価値として提供するプロダクト」です。Ubieでは様々なデータを社内外で活用しています。社外でも活用されているため、お客様の業務でも利用されています。
事業の成長に伴い、さまざまな要因で、インシデントやヒヤリハットが増えてきました。この状況を改善するため、安定稼働プロジェクトが立ち上がり、私もQAエンジニアとして参画しています。
どのような活動を行っているのかは、こちらの記事に全体像が書かれていますので、ぜひ合わせてご覧ください。
安定稼働プロジェクトでは、インシデントの要因分析をして必要な打ち手を進めていきました。ここで進めてきた打ち手の中で、QAプロセスを作るということも行いました。
この記事では、QAプロセスをどのように作っていったか、ということについてお話ししたいと思います。
どのプロセスに問題があるかを決める
インシデント要因分析の結果、複数の問題がある中で、作成した成果物に対する確認が不足していることがわかりました。そのため、要所要所で確認を行うプロセスを新たに追加することにしました。
この安定稼働プロジェクトのゴールは、年末までにインシデント・ヒヤリハットの件数を具体的な目標値まで減少させることでした。約1ヶ月半という限られた期間の中で、新たに構築したプロセスを実際の案件で適用し、定着させる必要がありました。
一方で、私自身はこのチームに参画したばかりで、システムや業務の知識が乏しい状態からキャッチアップしながら進める必要がありました。
QAプロセスを作る
1.確認すべき観点を挙げる
まず、最終的な成果物に対して、確認すべき観点をあげました。このプロジェクトで扱うシステムはデータプロダクトであり、最終的な成果物はデータ（ファイルやデータベースの形式）です。どのようなインプットや条件の場合に、どのようなアウトプットが出力されるべきかを確認することが中心となります。
大きく２つのやり方で観点を挙げました。
-
要件定義のドキュメントやサンプルデータを見ながら、テストケースを作るつもりでテスト観点を挙げる
- インプットとアウトプットのデータ状態をイメージしながら、確認したい観点を挙げていきます。レビューで確認するかテストで確認するかは意識せずにあげます。たとえば、下記のような観点があがりました。
- データの抽出条件が正しいこと
- 最終的に出力されたデータの編集処理が正しいこと
- このやり方をして、良かったことは、要件定義のドキュメントの記載が不十分だったり、曖昧だったりという点に気づくことができたという点です。テスト観点も挙げつつ、ドキュメントの記載内容の改善点にも気づくことができました。
- インプットとアウトプットのデータ状態をイメージしながら、確認したい観点を挙げていきます。レビューで確認するかテストで確認するかは意識せずにあげます。たとえば、下記のような観点があがりました。
-
社外のガイドブックの活用
- 上記で、一通りの観点は挙げられたと思ったものの、本格的にデータQAに取り組むのが自分としてもチームとしても初めてだったので、データQAならではの観点が漏れていないか、という懸念がありました。
- デジタル庁から発表されているデータ品質管理ガイドブックというガイドブックがありました。その中に、評価項目が載っていました。この評価項目をもとにして、担当のデータプロダクトだったら、どんな確認観点が考えられるか？を挙げていきました。このガイドブックには不具合例が載っていたので、自分のプロダクトに置き換えて考えやすかったです。
2.テストレベルを決める
テスト観点を挙げたら、それぞれの観点をどこのテストレベルで確認するかを決めます。
テストレベルは下記の３種類を定義しました。インシデント要因分析の時に、V字プロセスで整理をしていました。すでに単体テスト、結合テスト、システムテストはチームの共通言語になっていました。馴染みのある言葉を使った方が良いと考え、そのまま使いました
- 単体テスト
- 結合テスト
- システムテスト
これらのテストレベルがどの範囲を指すかについては、システム構成図をもとに定義しました。下記の図は実際に使ったMiroです。そのままお見せすることができないため、モザイクをかけていますが、Miroでまとめたシステム構成図に対して、どの範囲をテスト対象とするか示しています。
結合テスト用の環境準備が間に合いそうにないため、今回は結合テストは追加せず、単体テスト、システムテストの２つのテストを行うことにしました。結合テストで行いたいテスト観点を単体テスト、システムテストで行えるように観点を整理しました。
また、テスト観点を整理するタイミングで、テストではなく、レビューで確認したほうがよいこともこのタイミングで整理しました。
レビューとは、要件定義のドキュメントやソースコードのレビューです。レビューで確認した方が良いことは、たとえば、要件定義のドキュメントであれば、抽出条件や設定仕様の曖昧さや記載不備、です。テストケースを考える時に気づくこともできますが、早い段階で気づいておいた方がよいと考えました。コードであれば要件通りの設定がされているか、という観点です。単体テストでも確認ができそうに思えますが、コンポーネントの中には、構成上、ローカル環境で動作して確認することが困難なものがありました。そういうコンポーネントは、コードレビューで確認可能なことは確認しておくということにしました。
3.実際の案件でできるように手順を作り、実際の運用を行うメンバーに説明し、実施してもらう
どのテストレベルでテスト観点を確認するか決めたら、実際の案件で行えるようにしていくという定着を進めました。実際の運用を行うメンバーが行えるように手順を作り、説明し、実施してもらう、ということを一つずつ進めていきました。これは私一人でではなくて、実際の運用を行うメンバーと一緒に進めていきました。また、確認を効率化するAIのプロンプトを作ったりということも行いました。
開発フェーズのタスクに限らず、マスタデータの更新などの運用フェーズでのタスクに関しても、ミスしそうなところや確認が不足しているところの改善もしていきました。基本的には、その手順で何をやろうとしているかを明らかにして、その手順でやりたいことができているか、を確認する手順を加えていきました。
4.チームに共有する
決めたプロセスで今後は開発や運用を進めていくことになるため、プロセスについて、プロダクトの開発や運用に関わるメンバーがいつでも参照できるようにしたいと考えました。そこで、Notionの記事にまとめました。構成としては以下の通りです。まとめた記事をチームに共有しました。
- 全体をまとめた記事
- 単体テスト、システムテストの目的・観点をまとめた記事
文章だけだとわかりにくいと思ったので、生成AIをつかってさらに図にして共有をしました。生成AIを使ってテキストと図解するという事例は下記の記事が詳しく解説されています。
図解がもたらす理解のすすめ-Nano Banana Proの社内活用術｜3284
図解をしたことで直感的にわかりやすくなりました。QAプロセスについてあまり関わってこなかったメンバーにも印象に残りやすいというメリットもありました。
おわりに
- 以上でで安定稼働プロジェクトでQAプロセスの作成と定着までを１ヶ月半で進めてきた話を書きました。時間がタイトであったことや、私自身のドメイン知識が不足していたことなど、課題もありました。チームメンバーが相談にのってくれたり、定着に向けた準備を協力してくれたおかげで、定着まで完了することができました。
- 一方で、短期的にできることを中心でプロセスを作ったため、下記の課題があります。今後、一つずつ対応していきたいと考えています。
- システムテストが一番ボリュームがある。単体テストや結合テストといった前段のテストに寄せていく余地がある
- システムテストなど各種プロセスに効率化の余地がある
- Ubieに入社してからAIを使って仕事をする場面が多かったですが、この一連の活動はAIに手伝ってもらうことはあっても、人間が行う部分が多かったように感じました。その点で新鮮な経験でした。環境や期日の制約を踏まえた上で、理想的ではないが現実的なプロセスで進めると意思決定したり、実際の現場メンバーが進められるかを確認し、プロセスを調整するということをしたりということは、プロセス改善の難しいところの一つだと思います。こういうことは人間の仕事になるのかもしれないという気づきにもつながりました。
Ubieでは、QAエンジニアもBIチームも採用を強化しています！生成AI活用も全力でやってますので、気になる方はみて見てください！
Discussion