二人目QAエンジニアから二代目QAエンジニアになってやったこと
はじめまして、アルプでQAエンジニアをやっているyokota(@katawara)です。
2023年3月に転職し、アルプの二人目QAとして入社しました。
アルプでは継続収益ビジネスを行う企業様向けに、今まで手作業や自社開発がスタンダードだった契約や請求の管理をSaaSとして提供するScalebaseというプロダクトを開発しています。
現在は先人の卒業に伴い、二代目QAエンジニアとなりまして、一人QAエンジニアという状況の中で色々と試行錯誤する日々です。
今回は、入社から少々間が空いてしまっていましたが、これまでの振り返りも兼ねて、やってきたことを書いてみようかなと思います。
共通言語をつくろう
ということで、予期せず一人でQAを担当することになり、まず知りたいと思ったのはここまでのコンテキストでした。ここまで様々な意思決定を重ねた結果があるから今があるわけで、それを踏まえずに何かを論じるのは本意ではありませんでした。
また、目の前のことをひたすら倒していくというのも（できそうではあるけど）きっと違うだろうとも思っていました。
このとき（入社して2ヶ月前後）見えていた景色としては、いろんな武器は用意されているけど、どこに向かって振るうのがいいのかは見えていない、みたいな感じでした。
そんな話をチームでした結果、何を大事にしてきたのか、どこに向かって進めばいいのかを理解するべく、「Scalebaseとして守るべき品質」のブレストをさせてもらうこととなりました。
「守るべき品質」とは何なのか
考えるにあたっては、多くの人とブレストさせてもらいました。
開発チームのチームリード、SRE、PdM、Sales（社内ではAM = Account Management / SM = Sales & Marketingと呼んだりします）といった方々にお集まりいただき、各品質特性で見るとどういうことを大事にしてきたか、内部品質で見たらどういうことが大事か、といったことを発散させました。
その後別の会で、似ているものをひとつにまとめつつ、それぞれの項目を
できて当たり前のライン
できているほど嬉しいライン
できていると魅力的なライン
といった形に分類し、全体をまとめて抽象度を高めた表現をするとこうかな？ といったものをたたきで作っていきました。
さらにここから、各項目を関連する品質特性や、理想とする姿、想定される具体的なHowをブレイクダウンして肉付けしていきました。
品質基準という言葉とのずれ
初期の頃はこのドキュメントは「品質基準（仮）」という名前にしていました。守るべき品質の中で満たされる基準、みたいな想定のもとの命名です。
この手のものは、誰かが考えたものを一方的に押し付ける形になってしまうみたいな構図になるのが一番危ういと思ったので、できるだけいろんな人の目を何度も通すようにしました。途中経過を週次で全社向けに周知したり、事業定例の議題にしてもらってマネージャーに見てもらったりといった形です。
ある程度固まったところで、開発チームのチームリードに見てもらいました。自己採点用のシートも仮で作ってみて、ギャップを明らかにするぞ、そこから今後の改善の作戦を立てていくぞ、としたのです。
この時点では、仮説として、理想像からは一定のギャップがあって、そのギャップを具体にしていくことで次の方向性が見えてくるだろう、と思っていました。
しかし、蓋を開けてみると、全体的にやれていることが多い、という反応。これ自体は喜ばしいことですが、どうやらあては外れたようでした。
そこで見えてきたのは、
基準というにはマインドセットっぽい色も一定あり、多くの人が想像する基準とはちょっとずれてそう
バグ率とかそういう指標を入れたいかと考えてみたけど、見れば見るほどそんな気がしてこない
自己採点なので甘くついた可能性は捨てきれないが、もともとみんなが思っていることをベースにしてるのだから、定性で見ればそりゃできとるわい、みたいな話もあるのでは
ということ。
作っているものとつけた名前の間に、こんな感じのずれがありそうだということがわかってきました。
品質基準 → Quality Compass
ここまでを踏まえて、「品質基準」という看板は下ろすことにしました。
ChatGPTにたくさん案を出してもらい、厳正なる審議の結果、"Quality Compass"という名前に落ち着きました。
結局、基準というよりは指針みたいなものを作っていたのだな、と振り返って思います。
※ 余談ではありますが、弊社のデザインシステムはTORCHという名前がつけられています。トーチとコンパスで山登りできそうというコメントも社内ではあり、偶然の一致ながら結構気に入っています。
さて、そんなQuality Compassですが、せっかくなので、全文を公開してみます。
偉そうな目標を掲げつつもまだ至らぬ点はありますし、公開用に多少手直しはしましたが社内向けの言葉も散見されるかと思います。そのあたりはあらかじめご了承ください。
# 1. 共通理解が構築されていること
開発、PdM、デザイナー、AM、SM、すべての人達が何を作るのか、お互いの理解を合わせよう。せっかく時間をかけて作るのに、いざできてみたら何かこれは違うよね、という悲しいすれ違いをリリースする前から起こしてはならない。それは手戻りを生み、生産性を下げ、事業の成長を遅くする。
## 関連する品質特性
保守性、機能性
## 理想とする姿
- 仕様の理解が十分にチームに備わっている
- イレギュラーな手動のオペレーションが少ない
- 不具合があってもすぐ直る
- 作るものに対してステークホルダーを交えて議論し、イメージをドキュメント（図や表等も含む）で共有している
- 正誤の確認が可能なドキュメント（ユニットテスト等でも可）がある
## 想定される具体的なHow
- ドメインに関する理解
- 型を使った制約の表現
- ユーザーストーリーマッピングの活用
- 実例マッピングの活用
- E2Eの活用と日次の確認
- datadogやSentryの活用と日次の確認
# 2. 機能の顧客価値を誰にでも説明できること
「なぜ、その機能を作らなければならないのか。」
作るものに対して、きちんと説明をしよう。後から入ってきた人、方針に疑問を持った人、機能開発について説明を求めるすべての人に、説明できるものを作ろう。作るものの価値が曖昧なままにしてはいけない。説明できないものは仮説を立てることもできないし、結果を検証することもできない。
## 関連する品質特性
保守性、効率性
## 理想とする姿
- 仕様を理解している人が十分に存在している
- フィーチャーの開発において提供する価値の大きさと支払うコストを天秤にかけて折り合いがつく
- フィーチャーの必然性をファクトベースで語ることができる
- ドキュメントを作っただけで終わらせず、関係者の疑問をゼロにする
## 想定される具体的なHow
- ユーザーインタビューの活用
- PRDの作成
- 現在進行中のフィーチャーの定期的な発信
- 目的や背景、提供できる価値
- 全体のロードマップと現在の進捗
- datadogやSentryの活用と日次の確認
- AWSやGitHub Actions等の費用の推移の週次の確認
- 提供価値の仮説と、AWSの利用料が増えることが同時に議論ができている
- 人件費（≒工数）が想定を大きく超えてきた（たとえば仮で3倍とか）ときに、開発継続の判断が途中で入れることができている
# 3. 顧客視点で請求業務が止まらないこと
B2Bとしてサービスを提供している以上、顧客の業務を止めてはならない。特にアルプのプロバイダーから見て、月末月初の請求業務は、時間的制約が強く、請求金額の計算結果のミスは許されない。もちろん普段の業務が止まらないことも大事ではあるのだが、最低限の最優先事項として請求業務が問題なく行われることを担保する。
## 関連する品質特性
- 信頼性、機能性、使用性、効率性、保守性
## 理想とする姿
- 大量の請求があっても画面表示が止まらない
- 顧客が復旧できないエラーはなるべく早く検知/通知して、なるべく早く復旧する
- 顧客が復旧できるエラーは復旧方法を用意し、なるべく早く通知する
- 不具合があってもすぐ直る
- システム変更による顧客の請求業務の分断が予告なく起こらない
- 固定のインプットに対して固定のアウトプットができる
- 情報漏えいが起きない
## 想定される具体的なHow
- 内部品質の向上
- コードのメンテナンス性を上げる
- 適切なエラーハンドル
- ライブラリ等の継続的なアップデート
- デプロイ、デプロイサイクルの高速化
- 顧客側でエラー検知できる仕組みづくり
- E2Eの活用と日次の確認
- フェーズに応じて何をテストするべきか、今のテストは十分かの分析
- リスク分析
- 不具合分析
- datadogやSentryの活用と日次の確認
「つくる」から「使う」へ
つくった後は、どこかに飾って終わりとしてはいけません。
もともとみんなが大事にしていることを言語化したものではありますが、折に触れて大事だよねということを思い出してもらう必要があります。
現在は、理想とする姿をチェック項目とするチェックシートをスプレッドシートでつくり、大きいフィーチャー開発が終わったタイミングで振り返りに使ってもらっています。
そして、四半期ごとに振り返ってもらった内容をまとめて、全社としてどうだったかの考察とあわせてレポートにまとめ、読み合わせなどの形で共有をしています。
先述のとおり、もともと結構できているという話はあるので、チェックしたときの結果が前より落ち込むことがないのかのヘルスチェックとして使っています。
今のところ、2四半期分回してこれましたが、今後もなんとか続けていければと思っています。
おわりに
ということで、入社してからこんなことやりました、というお話でした。
同じような境遇の方が多いかはわかりませんが、品質に関する共通言語をつくりたいぞ、と思った方の参考になるようであれば幸いです。
最後までお読みいただきありがとうございました🙇
この記事が気に入ったらサポートをしてみませんか？