QA×SWE×CSMになってみた私が思う、QAのキャリア観
noteのQA
noteにおけるQA活動軸・指針
Team Mission:
noteサービス全体の品質を向上し、クリエイターが安心して利用できるようになる。
note社員全員が品質について、自然と意識できるようになる。
Team Vision
QA組織があることで、開発者は快適に安心して素早くサービスを提供出来るようになる。
障害・不具合の予防をしていく。
noteのQAでは、QMファンネルでいうQAに特化した形で活動してきました。
主にQAファンネルが60%、TEファンネル20%、PEファンネル20%といった具合です。
ファンネルとは？
QMファンネルのことで、QA/TE/PEがあります。
QAファンネルでは、
チーム全体の品質を向上させる。
開発プロセスや、プロジェクトの振り返りや、品質戦略を立案し、組織に対して能力を発揮する。
TEファンネルでは、
テストやレビュー、メトリクス測定など、製品やサービスを評価する能力を発揮する。テスト技法・集計・分析など。
PE(SET)ファンネルでは、
E2Eやユニットテストの自動化、CI/CDや自動化に対して能力を発揮する。
エンジニアリング文化、自動テストの書き方などにも関与する。
といった役割になっています。(勘違いしてたらすみません。)
noteのQAは人がとにかく少なかったため、まず全体に影響を与えられる施策を、メトリクスを取得しながら行い、プロジェクトによってテストエンジニアとしてジョインしてテストケースを作成するといった役割になります。
8ヶ月間のQAで行ってきた事
週報・QAクイズ
毎週金曜日に週報・クイズをSlack chに流し、情報共有する。
ハマりそうな不具合のポイントや、リリースノートを共有します。
クイズは、GoogleのTotTを参考にしました。
障害フローの整備
MTTR(平均復旧時間または平均修復時間)削減のため、障害フローを整備し、lambda(AWSのサービス)とbolt(Slackのアプリ)を使って一部自動化を行いました。
不具合分析と報告窓口開設
noteにある不具合を報告できる窓口と、それをスタックできるリポジトリを分析できるようにしました。
QA会/実例マッピング
プロジェクトによってはテストケースを作成したり、
仕様検討段階からジョインして仕様設計のお手伝いをしていました。
リリースフロー構築
自由リリースで日に5-10回リリースしていたのを、1日1回固定で検証できるように固定リリースにしました。
Revert数や、Mergeされた成果物をメトリクスとして計測しています。
mablを整備し、高速でデグレチェックができるようにテストケースを1.5倍にし、実行時間を1/3に短縮しました。
複数ロールをやってみて見えてきたこと
サーバーサイドエンジニアをして、見えてきた事
サーバサイドエンジニアをしている時は、リファクタリングや機能追加時にどれほど拡張性と保守性、可読性が高くなるかどうかを考えていました。
デザインパターンやSOLID原則を用いて、自分が考える綺麗なコードについて勉強していたりしました。
サーバサイドエンジニアをしていて、コードの、即ち内部の品質が大切なのだということが見えてきました。
※SOLID原則
- S 単一責任の原則
- O オープンクローズドの原則
- L リスコフの置換原則
- I インターフェース分離の原則
- D 依存関係逆転の原則
※デザインパターン
ソフトウェア開発におけるデザインパターンまたは設計パターン（英: design pattern）とは、過去のソフトウェア設計者が発見し編み出した設計ノウハウを蓄積し、名前をつけ、再利用しやすいように特定の規約に従ってカタログ化したものである。
QAをしてきて、見えてきた事
QAをしていて、1つのチームのサーバサイドエンジニアという枠組みを超えてサービス全体のプロセスや、機能単一の振る舞いに対して責任を持つようになってきました。
また、如何に素早く不具合を見つけた方が、コストが削減出来るかについてわかるようになってきました。
QAエンジニアをしていて、プロセスの品質と、外部の振る舞いの品質に着目するようになっていました。
スクラムマスターになって、見えてきた事
認定スクラムマスターの資格をとり、開発プロセスについて考えるようになりました。特にスプリントプランニングから、レトロスペクティブまでの流れ、そして次のスプリントに前のスプリントの経験をどう活かすか。
なんとなくスプリントをしていたけど、PDCAをどんどん回していくことができ、如何に改善し続けられるかという視点を持つことができました。
また、心理的安全性を担保した上でモブプログラミングやペアプログラミングを通し、自律分散型のチームにしていかなければならないということも学びました。
スクラムマスターになり、組織の品質と、プロセスの品質について考えるようになりました。
総括と、今後
シフトレフト！
QAでは、左側で不具合を主に発見していこうというシフトレフトという概念があります。
主にこれは開発プロセスの中での話で、要件定義〜実装〜モニタリングの中でテストしていこうという図です。
どのプロセスの中でも、静的テストや動的テストでテスト出来るよ〜という話です。
品質のレイヤーについての仮説
サーバサイドエンジニア、QA、スクラムマスターの経験を経て、以下のような品質のレイヤーがあるのではないかという仮説に辿り着きました。
外部の品質については、機能的な・振る舞いが要件と合っているか・価値提供出来ているかの部分。
内部の品質については、コードの可読性・保守性、ドキュメント有無やテストコードの質や量の部分。
開発プロセスの品質については、スクラム・アジャイルなど日々の開発プロセス、devopsの図の全ての部分。
組織の品質については、組織図やメンバー間の感情面、関係性による部分。
このレイヤは左から順に右に影響を与えていて、左レイヤの品質が良くないと後続レイヤに悪影響を及ぼすのではないかと考えています。
サーバサイドエンジニアとQAとスクラムマスターと今後
私がこのレイヤに影響出来るようになるのはどの部分だろう？
答えは、多分「現在は一部、今後は恐らく全て」です。
現在は、
サーバサイドエンジニアとして、内部の品質に関与することもできるし、
QAとして外部の品質に関与することもできる。
スクラムマスターとして開発プロセスの品質に関与することもできます。
全体を巻き込むことで品質文化を作れるかもしれないし、
プロジェクト単体の品質を保証することもできるかもしれません。
組織の品質については、ORSC(システムコーチング)という資格を現在取得しようとしています。
ORSC=システムコーチングでは、システム（＝関係性）が自らの強みやチャレンジ、潜在的な可能性を自覚することを促し、また、システム（＝関係性）は「Right Relationship（正しい関係）」を自ら見つけだし育むことを支援します。
ここで「Right Relationship（正しい関係）」とは、自覚的で意図的な関係性を創り上げ、それを維持する力です。
同時に全て出来るというわけではないとは思いますが、出来るだけ全てのレイヤーに関与出来るよう、スキルセットを構築していこうかなと考えています。
チーム全体の生産性を、1.1倍くらいに出来るような仕掛けをし続けられると良いなと思います。
QAのキャリアは無限大！
以上の品質のレイヤーが全て、QAの範囲と言うこともできます。
QAが学び、スキルを手にすることで、品質に関与出来る幅はどんどん広くなっていき、いろんな分野に手を伸ばし、チャレンジすることが出来ると思っています。
私はQA=テストだけをする人ではなく、
品質に関することはなんでもする。を体現出来れば良いなと考えています。
この記事が気に入ったらサポートをしてみませんか？