こんにちは！jagaです 🥔
私が所属するNstockでは現在、QAエンジニアがいません。
QAエンジニアの採用活動を進めていますが苦戦しています。
そこで、令和トラベルでQAエンジニアをされているmiisanの協力を得て、できることから始めています。
これまでに実施した取り組み
これまでNstockで実施してきた取り組みです。
- 品質に対する思いを相互理解するワークショップ
- 品質レベルを考えるワークショップ
- インシデントレベルを考えるワークショップ
- QAエンジニアの求人の更新
今回は「品質レベルを考えるワークショップ」についてお話しします。
背景
- QAやっていきマインドが実は既にある
- Nstockのバリュー「真摯にやろう」がそれに影響していそう
といったことが分かりました。
そうすると「より実践的な品質基準を作り、品質を管理できる状態にすること」の優先度が高そうです。
そのため、次のステップとして「Nstockではどのような品質レベルを守りたいか？」を言語化することにしました。
目的
「より実践的な品質基準を作り、品質を管理できる状態にする」ために「Nstockではどのような品質レベルを守りたいか？」を言語化すること
やり方
参加者
株式報酬SaaS Nstockの開発・運用に関わるメンバー全員(PdM、デザイナー、CS、エンジニア)
進め方
- 過去に経験した or 今後ありうる、インシデントについて挙げてみる
- それぞれ、どんな緊急度で対応することになりそうか考えてみる
- インシデント発生として、検知後すぐに対応
- Issueを切って、数週間以内に対応
- 対応しない
- どんな軸で品質を考えているか、まとめる
適宜、miisanにコメントをもらったり、互いに質問したりしながら進めました。
共有に使ったFigJam
話したこと
共有された内容の例
インシデント発生として、検知後すぐに対応
- ユーザーがログインできない
- セキュリホールをつかって侵入された形跡があった
- データベースの吹き飛ばし
- 金額計算のミス
Issueを切って、数週間以内に対応
- 外部サービスの不具合により、自社サービスに影響が生じた
- 退会済みのユーザーにもメンテナンス告知を送ってしまった
- SOや役員従業員のソートがきかない
- iPadで表示がバグって、特定の操作ができなくなった（スマホはできる）
- 大量操作時に明らかにレイテンシが悪化する（全体のSLOは違反していないので緊急対応はしない)
対応しない
- クラウドの障害でどうしようもない系
- サポート外のスマホ・ブラウザで見れない・使えない
- 特定の拡張機能を入れたユーザーのみ再現するバグ
行われた会話の例
「利用している外部サービスがタイムアウトして、割当契約書が作成できない」について
「割り当て契約書」とは、会社と従業員で結ぶSOを渡すための契約書を指します。この契約書PDFを生成する機能について話した際、優先度について議論が行われました。
- 契約社数の少ない今であれば、仮にシステムが止まってもそこまで影響がなさそう
- 一方で、契約締結までに日数の少ないお客様がいると緊急度は跳ね上がる
- また、今後ユーザーが増えていくと全ての会社の割り当て契約を知ることは難しくなるし、多くの会社でSOを配る頻度が増えていくと、より落とせない機能になっていく。
こうしたやり取りを通じ、会社のフェーズやお客様の状況によって、対応優先度が変わりうる！ということが共通認識として得られました。
「データ数が増えて、画面表示にめっちゃ時間がかかるようになった」について
- 所要時間や、その画面を使う頻度によって緊急度がかわるかも
- 特にSOを行使するという体験は人生でそう何度もあるわけじゃない(Nstockとしては増やしていきたいけど)
- いかにNstock上での「レアな体験」の品質を上げるかは重要そうだ
品質を考える軸になりそうなキーワード
- セキュリティインシデント
- 代替手段
- 法令遵守
- Nstockとの契約内容とのアライン
- 体験の希少性
- 影響範囲
- タイミング
Q&A
メンバーから出た質問に、miisanに答えていただきました。
- Q) 品質を考える軸ごとに重みづけをして、スコアリングをしたりする？
- ある。掛け合わせたスコアを利用して、機械的に判断する方法は、認識のずれがなくなって動きやすくなる。
- Q) 障害が起きたらすぐ集まって対応する体制をしてる。まずはスコアづけからやるイメージ？
- 実際に利用者が増えて開発機能も増えてくると、最小工数で対応しながらも、同時並行で動かせた方が持続可能性は維持できやすい
- (この頃から、インシデントが起きたら集まれる人全員で集まったのち、10分たったら残る人数を決める、というインシデント対応フローに変わりました)
- Q) たくさん軸がでてきたけど、今のフェーズだったら、観点を絞れると良さそうにおもえる
- すごく大事！その1st stepが今日の話なんだと思う
振り返り
得られたもの
- みんなの良いものを作りたいという思いをはじめ、普段それぞれの心の中にあった当たり前が言語化できてよかった！
- miisan) 品質って正解がないので、みんなが思ってることを言語化するっていうのがすごく大事
- 品質を考えるうえで軸になりそうな概念が洗い出せた
- 同じ事象でも、状況やタイミング、影響範囲によって緊急度が変わりうることがチームの共通認識になった
難しかったこと
- 大人数で言語化まで収束するのは難しかった
次回へ
このワークショップの後miisanと振り返りをして、実際に普段の意思決定で品質レベルを考えられるようにしたいね、という話になりました。
そこで次は、過去のインシデントを振り返りながら、「インシデントレベル」を作ってみることにしました。
Nstock QAの旅はつづく...
We are hiring!
Nstockでは、QAエンジニアを募集しています！
Nstockの開発メンバーは品質の改善をもっとやっていきたいと思っていて、学ぶ姿勢があり、とりあえずはできることからやっていっています。
が、まだまだ道半ばです。
各開発チームが品質保証に関する知識と技術を取得し、自立して活用できるよう、一緒に伴走していただけませんでしょうか？
ちょっとでも興味が湧いた方は、気軽にカジュアル面談にお申し込みください!
Discussion