「1人目SETとして入社して２ヶ月の間におこなったこと」（増刊号）

こんにちは。

入社後初のブログになります。 10X SETのtarappoです。

6/16（木）にQA Test Talk Vol.1を主催しました。

この勉強会で「1人目SETとして入社して2か月の間におこなったこと」というタイトルで登壇しました。

そのときの資料は次になります。

この資料では書ききれなかったことも多いので、本記事では上記の資料を補足しながら、入社してから2か月の間におこなったことをまとめていきます。

入社前におこなっていたこと

入社前に業務委託という形で関わっていました。その間におこなっていたことについては次のブログ記事に書いています。

その間におこなっていたこととしては、かんたんに説明すると次のように目指すゴールを考えて、それに向かって進めていけるように整えだしたというものです。

「10XにおけるQAはどのような姿を目指すか」について考えて文章化
その姿を元に「どのようなメンバーが必要か」を考えて採用活動
- JDを更新したり、カジュアル面談をいろいろとおこないました

目指す姿に向かうには、今がどういった状態なのかというのが分からないと進むことはむずかしいです。そこで、今後新たなメンバーが入ってきたときに動きやすくするためにも、現状を把握しやすくなるように次を進めだしていました。

（1）データの可視化と分析のための準備
（2）テストのプロセスの把握と改善に向けた準備

次に入社後の現在のQAチーム体制や、2か月の間におこなってことについて説明をしていきます。

現在の10XのQAチーム体制

入社してから2か月たった現在（2022/06）における10XのQAチーム体制は次図のとおりです。

私が入社する前から第三者検証会社の方にプロダクトの検証を担当してもらっています。そこから、4月にSETである私が入社して6月に1人目のQAエンジニアが入社しました。

職種としては、SETやQAエンジニアとして入社しています。しかし、現時点では「今、10XのQAはなにをするべきか」を考えた上で、その中で取り組むべき複数のイシューからプライオリティを考えた上でタスクを進めています。

そのためSETが主にとりくむと想像されるような「自動テストの実装」や「CI/CDサービス周りの改善」といったものはこの2か月の間ではおこなっていません。

上記の内容については一定現在の状況をチェックはした上で、それを「今」おこなうべきかを考えて他のイシューのプライオリティが高いと判断しています。

そこで、どのようなイシューがあるのか、それについてこの2か月の間にどのように取り組んだのかについて次に説明をしていきます。

まずなにをおこなったか

まず「10XにおけるQAの未来像」にむかうにあたってなにをするべきかを考えていきました。

そこで「現状把握」のために次を進めていきました。

現状のドキュメントを元にした関係者へのヒアリング
- このドキュメントが実体とあっているのかどうかなど
ヒアリング結果を元にしてドキュメントの更新

この「現状把握」を進めていく中で「曖昧になっていること」や「おこなったほうがよいがおこなえていないこと」などいろいろな課題が見つかりました。これらの課題をリスト化するだけでなく、入社前におこなっていた「データの可視化と分析」と「テストのプロセスの把握と改善」の残タスクにおいても課題としてリストに入れました。

また、上記とは別に社内でふりかえりの際などにまとめられていたQA周りに関する課題についてのドキュメントがいくつかありました。そこで、これらの課題をすべてマージした一覧を用意して重複しているものや解決しているものなどは削除し整理しました。

この一覧をグルーピングし、どういった傾向の課題が多いかといった判断をしていきました。そして、この課題の中から今期（4月〜6月）におこなうことして次をすすめることに決めました。

検証プロセス
- （1）検証プロセスの改善
- （2）不具合分析の実施
検証内容
- （3）検証コスト最適化のためのテスタビリティ向上
- （4）検証にかかっているコストの可視化

QAというのはなにをおこなうものなのか、またQAチームはなにをおこなおうと思っているのかというのはなかなか分かってもらえないことがあります。そこで、次も進めていくこととしました。

（5）QAチームの認知度の向上

また、上記以外にも今期の取り組む内容として次も設定しています。これらについては登壇時点ではあまり進められていなかったため、登壇時には特に紹介をしませんでした*1。

（6）ソフトウェアテストの全社へのナレッジ向上
（7）本番障害に関する情報の活用

この7つの取り組みについては（1）が終わったら（3）をやるといった関係ではなく、内容によっては連携しているものもあります。そのため並行しながら進めていきました。

おこなうのを決めた際の方針

上述した今期の取り組みをおこなうと決めた理由としては、次が前提にあります。

限られた時間の中で本当に大事なことにフォーカスしていくために、そのフォーカスすべきものがなにかを定量的に分かるようにする

そこで、次をおこなえるようにするというのがありました。

現状をわかりやすくする（計測と可視化）
- 例）
  - 検証時にみつかった不具合の傾向
  - 検証にかかっているコスト
得られた情報から改善サイクルをまわせるようにする

実際におこなった次のことについて順に説明していきます。

検証プロセス
検証内容
QAチームの認知度の向上

検証プロセスに関すること

検証プロセスに関することとしては次の2点をすすめました。

検証プロセスの改善
不具合分析の実施

これらをすすめる上で、検証プロセスがどのように変化していったかについて次に説明をしていきます。プロセスは次のように入社から2か月の間に4回変化していっています。

（1）入社前
（2）入社初期
（3）入社1〜2か月後
（4）いま

これは決まっていなかったことを決めていったり、見えてなかったことを見えるようにしていった感じになります。

（1）入社前

利用ツール：GitHub Project
Issue Templateを使って次のIssueを作成
- QAチケット
  - QAチケットは検証を依頼する人が起票をし、検証対象の情報（仕様へのリンクやリリース予定日など）が記載されたもの
- バグチケット

この時点での課題として次のようなものがありました（これらは課題の一部です）。

QAチケット関係
- 一部において記載する情報が不足している
- 一部において起票タイミングが遅い
- closeの条件が「全テストケースの実施完了」になっており、その時点でバグチケットがまだ残っていることもある
バグチケット関係
- 不具合分析をするには記載されている情報が不足している
- 情報の多くは本文にかかれているため、今の形のまま分析しようとする場合はテンプレート化や独自フィールドの追加など対応がいろいろと必要になる
- 全体的な不具合の傾向が分かりづらい
QAチームのスケジュールやタスクの進捗がよくわからない

上記の課題はGitHub APIを使ったりして解決できるものはありますし、プロセスを整えることで一定解決できるものもあります。

これらの対応について考えている際に、他チームがJIRAを利用する流れがちょうどありました。 JIRAを活用することで、上記の課題を一定解決できることが分かっていたため、JIRAへの移行をおこなうこととしました。

（2）入社初期

JIRAの移行にあたっては、次を実施しました。

入力内容の整備
- バグチケットの分析をできるように入力内容のフォーマット整備
- どのような値をいれるべきかをQAチケット、バグチケットともに整備しドキュメント化
利用の仕方の整備
- バグチケットのフロー決めとワークフローの設定
- QAチケットのフロー決めとワークフローの設定
  - QAチケットのサブタスクとしてQAチームのタスクを登録
可視化
- タスクの状態を見えるようにしたQAチーム用のKANBANの用意
- 現在のバグチケットの状況が分かるJIRAダッシュボードの用意

またプロセス面として図の「青色」の箇所として次を追加しています。

QAチケットの完了判断のステップを追加
- バグチケットが残っている場合、そのバグが残っていて問題ないかをQAチームが判断した上で関係者と方針について合意する
一部において「QA必要」「QA不要」の判断をしてPRにラベルを追加
- QA不要の際のみラベルに追加し、あとからチェックできるようにした

上記の内容はすべてドキュメント化した上で、関係者に共有しています。

JIRAへの移行に伴いデータがたまれば、「不具合分析」ができるようになりました。データをためるには一定の期間が必要ということもあり、このJIRA移行は実施できるタイミングになってすぐにおこなっていきました*2。

（3）入社1〜2か月後

JIRAへの移行をおこなってから、1か月ちょっとたったタイミングである程度のバグチケットが溜まりました。そこで、不具合分析を実施しました。

不具合分析では、次を実施しました。

全バグチケットの確認
- JIRAにはGitHubのPRへのリンクもあるため（JIRAのプラグインの機能）、それを活用しコードのチェックもおこないました
今後の不具合分析で追加して取得すべきデータがあるかの確認
- 既存バグが一定ありそうだということでそのためのフィールドをバグチケットに追加

結果として、今回の不具合分析では次の3種類の不具合が全体の約65%と多いことがわかりました。

（1）仕様に関するもの
（2）コーディングミス
（3）他のバグチケットとの重複

（2）においてはユニットテストで担保できるものはあまりなく、UIテストをおこなえばみつかったかもしれないというものが一定ある程度でした。そこでまずは（1）と（3）に対しての改善施策を実施することとしました。

（3）においては現状こういうことが起きているという共有とJIRAのダッシュボードを改善して、よりバグチケットを見やすくしました。

（1）においては、仕様策定段階からQAチームが関われるようにする方向で関係者と相談した上で進めていくこととしました。これに関しては、必要性を社内のメンバーに伝えた上で即座に動けているところが弊社の強みの1つだなとも思っています。

（4）いま

（3）で説明したように、早い段階からQAチームが仕様レビューに加わることをためしています。かかわったレビューにおいて、現時点でもいくつかの仕様考慮漏れを見つけています。

まだ未実施ですが、上図の緑色にある「ふりかえり」も実施する予定になっています。これにおいては、すべてのQAチケットについておこなうのではなく、バグ起票が多いなど特定のケースにおいてのみおこなう予定です。

このようにプロセス面を改善しつつ、検証内容についても改善するためにしてきたことについて次に説明をしていきます。

検証内容に関すること

検証内容に関することとしては次の2点をすすめました。

検証コスト最適化のためのテスタビリティ向上
検証にかかっているコストの可視化

これらについて説明をする前に、現状おこなっている検証について次にかんたんに説明をします。

現状おこなっている検証

今はリリース前に「システムテスト」を手動でおこなっています。

なお、現状把握のために現時点でおこなっているシステムテストの内容などについては関係者にヒアリングをした上でドキュメントにまとめていきました。

リリースされるものとしては、プラットフォームという特性もあり「機能追加・改修」と「新しいパートナーのローンチ」というものがあります。これらはそれぞれおこなうべき検証の内容も異なってきます。これについては次のブログにあるようにすでに一定まとめてくれていたのがありました。

現状をまとめていく中で、次のような課題があることもわかっています（これらは一部です）。

（1）利用している検証端末が実ユーザーの利用実態を考慮していない
（2）システムテスト以外のテストがおこなえていない

（1）においては、整備を進めているところです。

（2）においては現時点の状況では他のテストをおこなえる余裕がないため、手が出せていないというのがあります。しかし、今後いろいろとおこなっていく必要があるため、どのようなテストが必要であるかについてまとめているところです。また、他のテストもおこなえるようにするためについて後述するようなことを進めだしています。

次にこの2か月の間にすすめた2点について説明をしていきます。