QAエンジニアから見た、ログラスの品質文化のユニークさを言語化できた

この記事は毎週必ず記事がでるテックブログ "Loglass Tech Blog Sprint" の 35 週目の記事です！
1 年間連続達成まで 残り 18 週 となりました！

ログラスのQAのコタツです。今年もよろしくお願いします（2024年スタートからもう3ヶ月過ぎましたが）

この前、以下のイベントに登壇させて頂きました。人生初パネルディスカッションでした...わざわざご来場いただいた方、オンラインで見守ってくれた方、設営していただいたウィングアークさん、パネラーの方々、モデレーターの大平さん、ログラスのスタッフなどなど、関係者の皆さん本当にありがとうございました！
ATN#20　BtoBプロダクトQA集合　Loglass×WingArc1st×テストの街「葛飾」 (2024/02/15 19:00〜)

今回登壇させていただいたイベントはBtoBプロダクトのQAの面白さを語るというテーマ設定でした。また、パネラーの方はウィングアークさんのマネージャーのじゅんぺーさんとテストの街「葛飾」のオンライン区長のisekiさん、モデレーターは同僚兼私のコーチ兼知識の引き出し兼タバコ仲間の大平さんでした。
また、ログラスはスタートアップ、ウィングアークさんは上場企業、isekiさんの会社は社名は伏せておりますがパッケージ製品を扱っている企業という対比構造がありました。

今回パネルディスカッションや、打ち上げで他社の方々とお話し、メタ的に自分の置かれた環境を見つめ直したことで、自分やプロダクトチームの品質文化についてわかったこと・言語化できたことがあるので、残しておきたいと思っております。

ユニークさ①：事業フェーズ初期からQAエンジニアがいる

「通常、アーリーフェーズのスタートアップはQAを採用しないです。」当日参加していただいた方から言われた言葉にハッとしました。

思い返せば私がログラスに参画した2022年6月は社員数40数名で、会社のフェーズで言うとシリーズAラウンドでしたし、社内の雰囲気はガチのスタートアップでした。同じ小さな部屋で全社員が肩を並べて仕事していて、全員が必死こいてなんとかしようという熱気がありました（今もありますが）。圧倒的、当事者意識ってやつです。

世間一般的に、ある程度プロダクトが大きくなったがまだPMFしていないフェーズや、リリース間もないプロダクトだったり、リリースしていないプロダクトに対してQAを採用する判断をする会社は少ないと思います。お客さんがたくさんついたPMF後に不具合が出てQAが欲しくなるというのが一般的な流れだと理解しています。

引用元：PMF（プロダクトマーケットフィット）とは何か？　PMFのシグナルとそうでないシグナルを見極める

QAを採用する判断をしない理由は何個かあると思うんですが、主たる理由はQAはエンジニアに投資をした後にする投資だからだと思います。エンジニアのほうが優先順位が高いので、後回しにされがちです。

一方でログラスはなぜQAを採用するに至ったのか？色々聞いて回りましたが、以下の流れがあったからQAを採用するという決断をしたようです。

1. もともと品質に対して危機意識が高いエンジニアだけで頑張っていた（だが、QA的スキルは十分ではなかった）
2. 不運にも障害が発生した
3. QAと働いたことがあり、QAの重要性を理解しているPdMやCSが、QAを組織に導入しケイパビリティを補うべきだと提言した
4. 過去の失敗などから学び、品質への投資に理解がある人が多く、提言を否定する人はいなかった　※出典古いですが、強くてニューゲームの記事のニュアンスです

代表の布川も「エンジニアが技術的負債を返済したいと言っていたら、NOと言わない」という趣旨の発言をしていたり^[1]（これまたちょっと前の出典で恐縮です）、会社としてLTV firstというバリューを掲げているなど、感度が高い組織文化を作ることを狙っているのも大きいと思います。

引用元：ログラスコーポレートサイト：わたしたちについて

ユニークさ②：プロダクトチームはAgile Testingの理想を理解し、愚直に実践している

ここでいうプロダクトチームとは、エンジニア、デザイナー、QA、PdM、EM、SREなどの、プロダクト開発に関わる職種全般を指します。

個人的には、テストをどう設計、実施するかということよりも、バグの予防に主眼を置いています。もちろんテストも行うのですが、それよりもプロセスの改善や、チームビルディング施策等が主な関心の範囲となっています。
また、「品質はQAの責任よりもチームの責任」という責任ナラティブ^[2]がプロダクトチーム内に根付いているので、プロダクトチーム全体でバグの防止を心がけています。Whole-Teamアプローチ^[3]を実践しているとも言えます。

スタートアップのフェーズで似たようなことを実践している他社QAの方は少ないんじゃないでしょうか（推測）。実践している具体例を上げます：

• エンジニアとともに品質についての勉強会を実施
  • 実践アジャイルテスト、単体テストの考え方/使い方、LEADING QUALITYの輪読
  • ソフトウェアテスト技法練習帳を解いてみる
  • JaSSTなどのカンファレンス資料を読み合わせ
• エンジニアがテスト設計し、QAエンジニアがテスト設計方針をレビューする
• エンジニアとペアでテスト設計を実施
• エンジニアとテストコードのペアプログラミング
• スクラムチームで要求分析、VOC整理、顧客ヒアリング
• プロダクトチーム、ドメインエキスパートを交えて実例マッピング、ドメインモデリング
• プロダクトチーム全体の組織設計/コミュニケーション設計や提案

プロダクト品質を上げるためにプロセス品質を上げる、プロセス品質を上げるために組織品質を上げる（cf. 品質富士山）というスタンスなので、かなりいろいろ、なんでもやっています。アジャイルのなかでQAをしていくスタンスはインストールできているので、これから実践をしながらより高みに登るためにどうすればいいのか考えていくフェーズになっています。

ユニークさ③：QAもプロダクトエンジニアとしての素質を求められている

最近、プロダクトエンジニアという概念を知りました。プロダクト志向を持って課題解決に邁進するエンジニアのことです。

プロダクトエンジニアとは何者か｜Niwa Takeru｜アセンド株式会社CTO

ログラスはQAも含めて、サーバーサイドエンジニア・フロントエンドエンジニアなど、エンジニアと冠がつく役割はプロダクトエンジニアと呼ぶとしっくり来ると思いました。

例えば、ログラスのQAはテストを基軸にしつつも、不具合分析、開発チーム全体のプロセス改善、データ分析、VOC収集、ときにはPdMの補佐やスクラムマスター等も行いながら、周辺の職種に染み出し、プロダクトの品質と価値を向上することをミッションに動いています。

QAはものを作る立場ではないし、お客様と直接話をする機会も少ないです。ですが、QAはやりようによっては何でもできて、周辺の職種のプラクティスを取り入れつつ、日々今までのやり方を疑いながら様々なことを改善していくことが面白さだと思っています。

この資質はQAだけではなく、最近策定されたエンジニアリング組織のTech Valueにも現れています。

急拡大するログラスのエンジニアリング組織のTech Valueを策定しました｜いとひろ@ログラス

今後やりたいこと

このようにログラスはQAという概念の普及期は終わり、成長期となっていて、かつ前述のように色々とユニークな箇所がありつつ、まだまだなりたい姿とは乖離があります。

チームのケイパビリティを上げていきたいのです。マインドは育ってきたものの、ケイパビリティを上げるためにはやはりQAエンジニアとして各スクラムチームの品質のリーダーシップを取れる人がいないといけません。現状、全チームに対してQAがいるわけではないので、チームのアクティビティ一つ一つに対して十分に目を配ることができておらず、品質担保体制にはまだまだ伸びしろがある状態です。プロダクト組織がどんどん大きくなっていく過程で、QAが2名だけだと十分にサポートできているとはまだ言えないと思っています。

さいごに

ログラスではエンジニアがテストをして当たり前、内部品質も外部品質もひっくるめてプロダクトチーム全員で品質を高め、顧客価値の提供にコミットしています。

一方で、スタートアップですので、日々泥臭いことばかりです。品質ナラティブのベースがあるとはいえ組織としてもまだ未熟なところばかりなので、テストや品質に対してのスキルも必要で、それをもってプロダクト組織をサポートしていく必要もあります。

要件難しすぎて私も頭を抱えているんですが、スタートアップとしては珍しい環境でQAをやってみたい、挑戦してみたいという方がいらっしゃったら、是非一緒に働きましょう。

脚注

1. 参考：技術負債を抱えず、自走力の高い組織こそがSaaSを急速に成長させる

2. 責任ナラティブ（The Ownership Narrative）：誰が品質に責任を持つかが考えられ、語られているか。引用元：LEADING QUALITYより

3. Whole-Teamアプローチ:「テストはチームの課題」であり、「品質はチーム全体責任」とする考え方。冒頭、私が参加したパネルディスカションのオーナーであるじゅんぺーさんのブログより：「QAはテストする組織」と思っている人は、世の中にまだたくさんいる様です。しかし、テスターは「テストだけをする人」ではなく、「テスト活動における色んなことをする人」なのですね。では、誰がテストするかと言うと、広義の意味では「チーム全体」であり、スキルや役割によって実施するテストは変わるはずです。引用元：Janet先生の「認定研修Agile Testing for the Whole Team」に参加してきた！より