UbieでQA Engineer(QAE)をしているMayです。Ubieでは11月から「クオリティカルチャーの醸成」を目指して動き出しました。クオリティカルチャーとは、品質が低い状態から「品質が大事」を定着させるために使われがちな言葉のようですが、Ubieで狙っているクオリティカルチャーは「適切に品質を優先する」ことを目指しています。まだ検討段階のお話ですが、やっていくぞという決意表明も兼ねて、書いていきます。
クオリティカルチャー醸成のはじまり
クオリティカルチャーとは
クオリティカルチャーとは、ソフトウェアの世界ではまだあまり定着していない言葉で、検索すると製薬業界の情報がヒットします。規制ではなく文化を形成することで品質を高めよう、という背景のもと生まれたもののようです。ソフトウェア開発の世界では、2022年5月に にしさん[1] がJaSST nanoで「品質文化」について紹介されています。 にしさんは、「品質文化が根付いた組織とは「みんなが自然に品質を優先するよう思考・行動する組織」のことである」と言っています。品質が低い状態から「品質が大事」という意識を定着させるために使われがちな言葉のようですが、Ubieで狙っているクオリティカルチャーは「適切に品質を優先する」ことを目指しています。
QAを民主化せよ
Ubieでクオリティカルチャーを醸成しようと言い始めた理由は、Quality Assurance（QA）やセキュリティといった専門職の活動を開発チーム内で一定勘所押さえてできるようになることを目指し始めたことにあります。
私は2023年6月にUbieに6人目のQAEとして入社しました[2]。Ubieに入社して感じたのは、プロダクト開発組織内の品質への意識は総じて高めであるということです。ユーザー体験の作り込みや評価は当然のように行われているし、セキュリティの専門家も当然のように所属しています。データエンジニアからはデータ品質についても語られています。
ただし、力を入れるところと抜くところの加減が人それぞれで、品質のプロセスを厚くしてしまってスピードが上がらないケースや、当たり前にできてほしいと思うような実装がQAで差し戻されてしまうケースなど、波を感じています。具体的には、以下のようなことがありました。
- 素早くリリースしてユーザーの反応を見たい機能が、関連する機能への影響を過剰に恐れてリリースを足踏みしてしまう
- システム運用体制が定まっていないばかりに、信頼性への意識が高いエンジニアが反射的にトラブル対応をしている[3]
Ubieのプロダクトは0->1フェーズのものから1->10フェーズ、10->100フェーズと入り乱れている段階なので、QCDのバランスは異なります。QCDの勘所を押さえたQAEがすべてのチームに入れば品質は安定するかもしれませんが、QAEがリリースのボトルネックになってしまう可能性は否めません。SWEとQAEが独立することで、SWEの品質への意識が下がってしまうことも懸念されます[4]。ユーザーに安定して価値を届け、新しい価値も素早く届けていくためには、品質への活動をチームで担っていくことが重要です。この課題は組織全体の課題として取り上げられ、1年後のマイルストーンの一つとなっています。
チームでQAの活動ができる世界を目指すためには、活動するみんなの目線合わせが必要です。プロセスや品質基準をガチガチに固めることは、自由な発想や柔軟性を奪ってしまいます。そこで、行動のよりどころとなる指針を示して定着させ、文化として築いていくのはどうだろうかと考えました。UbieにはカルチャーガイドというMissionを達成するための”現時点での最適なhow”として設計されてたガイドがあり、Ubieに所属する全員がこのカルチャーの中で活動しています。プロダクト品質[5]についても、カルチャーの一つとして浸透させていこうという作戦です。
クオリティカルチャーの考察
クオリティとは何か
さて、「チームでQAの活動ができるようになる」とはQAEがやってきたことをQA以外の人ができれば十分なのでしょうか。ここは慣性を捨て[6]、いったんまっさらにして「プロダクト品質」について考えてみました。システム・ソフトウェア品質標準であるSQuaRE(ISO/IEC 25000シリーズ)なんかが参考になります。
「システム・ソフトウェア品質標準SQuaRE シリーズの歴史と概要」より
私たちは不確実性を扱うスタートアップ企業なので、自動車や医療機器にも適用できるような品質モデルを愚直に活用することはできませんが、機能性や使用性や信頼性といった品質特性は、考え方として必要であることには変わりません。
それは現状、QAEだけでなく、セキュリティエンジニアやデザイナーなどの専門家が担当していた範囲を大いに含みます。QAの活動をチームでできるようにするためには、品質モデルのどの特性を、誰がどこまで担保するかの整理が必要です。まずはプロダクト品質に関わる活動の現状把握を進めています。
目指すところはEngineering Cultureなのかもしれない
品質保証の活動は、システムの機能が動作するかを確認すること（検証）だけではなく、ユーザーに価値が届くかどうかを確認すること（妥当性確認）でもあり、工程の初期段階から行われるのが理想です。価値と一緒に品質を作り込み、充実したテストとリリースのPipelineが整えば、リリースのサイクルはより一層加速できます。これは品質にとどまった話ではなく、技術的な取り組みや思考の文化、Engineering Cultureと呼ぶ方が適切かもしれません[7]。
"Engineering Culture"（エンジニアリングカルチャー）とは、組織内の技術的な行動や思考の方式を指します。これは、ソフトウェアの品質や開発プロセスに対する共通の理解を形成し、連続的な改善や協力、イノベーションの重視を推進します。この文化は、最高の品質の製品を提供することを目指し、組織が新しい技術や手法を採用し、その変化に適応する能力を高めます。
(gpt-4-0613)
DevOpsのチームでは現在、DevOps Research and Assessment(DORA)を参考にしながら、チームでの開発能力向上を目指しています。コラボしながら、品質の最適化を実現していきます。
2024年に向けて
QAEの未来を模索する
一昔前はテストエンジニアという表現が定着していたQAEですが、ソフトウェアテストの国際規格であるISTQB[8]では、テスト担当者、テストマネージャー、テストアナリスト、テスト自動化エンジニアといったいくつかのロールが挙げられています。私は主に、テストマネージャーとしてキャリアを積んできました。
では、これから築こうとしている「チームでQAの活動ができるように」なったとき、QAEは一体何をすればよいのでしょうか。ヒントはQMファンネルにあるかもしれません。QMファンネルは、ソフトウェア技術者協会の分科会の一つ、ソフトウェア品質保証分科会（SigSQA）が考案した、品質マネジメント(QM)のスペシャリティをモデル化したものです。
QMファンネルでは、品質マネジメントには以下の3つのスペシャリティがあると言われています。
- テストやレビューといった評価技術のエキスパート
- 様々な自動化を行うエキスパート（SETやSRE）
- 組織能力を高めるエキスパート
そして、それぞれのロールには「スプリット」「インプロセス」「コーチ」「コンサルタント」「プロモーター」といった段階が定義されています。
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話（3D版）より
現在、UbieのQAEは複数のスペシャリティを掛け持ったスキルを持ち、「インプロセス」の段階で活動していますが、今後は「コーチ」として活動していくことが求められるかもしれません。
QAコーチは、Design Program Manager(DPM)のQA版、Quarity Program Manager（QPM/Quarity Ops）とも言えそうです。
デザインプログラムマネージャーは、デザイン関連のプロジェクトやイニシアチブを統括し、スケジュール管理、リソースの割り当て、品質管理を行い、デザインチームと他の部門間のコラボレーションを促進します。彼らの目標は、デザインの目標達成とチームの効率性を確保することです。
(gpt-4-0613)
もちろん、スクラムマスターやプロダクトオーナー、SWEに転身するという道もありそうです。この辺りは、QAEのみんなと議論しながら進めていこうと思います。
マイルストーン達成報告をお楽しみに
マイルストーンは2024年の9月末。来年のこの頃には、Ubieのクオリティカルチャーがどうなったか、ご報告できる予定です。人間は、自分が納得できる原則に従って思考し行動を行うもの。いろんな職種やチームの皆さんと協力しながらカルチャーをつくり、当たり前の世界になるよう浸透させていきます。
Ubieでは、「テクノロジーで人々を適切な医療に案内する」をミッションにプロダクトを作っていく仲間を募集しています。一緒に世界の平均寿命を伸ばしましょう！
-
電気通信大学の故西康晴先生。ソフトウェアテストの業界を牽引したリーダー・ビジョナリー。私の心のよりどころであり、とっても大好きでした。もっともっと話したかった。にしさんは旅立ってしまいましたが、クオリティカルチャーやQAEのあり方について、ぜひディスカッションしましょう。 ↩︎
-
現在、QAEは開発チームのスクラムで、レビュー・テスト・自動化・ドキュメンテーションなど、品質に関わる役割を担っています。開発チームは大小さまざま20チームぐらいはあるでしょうか。私はその中の1チームで活動しながら、11月から開発基盤のチームでも活動を始めました。7人目のQA、takamaっちの活動は、昨日のAdvent CalenderでPDEのsousukeが書いています。
テーブル駆動テストを使った QA エンジニアとソフトウェアエンジニアの連携 ↩︎ -
システム運用の改善活動については、SWEのsyucreamがブログを書いています。
症状検索エンジン「ユビー」の共通基盤を支えるシステム運用改善活動 ↩︎ -
これはテスト技術者資格制度 Foundation Level シラバスにも、独立したテストの欠点をとして「開発者が品質に対する責任感を失ってしまうことがある」と書かれています。 ↩︎
-
「プロダクト品質」としたのは自組織がプロダクト開発を銘打っているからであり、厳密に「サービス品質」や「プロセス品質」「利用時品質」などと分けて考えているわけではないことを念押ししておきます。 ↩︎
-
UbieのValue（個人の行動指針）は3つあり、そのうちの1つである「All In」（慣性を捨て、大きな未来に賭けよう）をイメージしました。 ↩︎
-
最初、テックカルチャーかなと思って調べてみたら、弊社代表quvoのnoteがヒットしました。quvoが書いている内容は、テクノロジーを中心に据えたカルチャーのことでUbieのカルチャーの根源にもなっています。今回扱いたい範囲はもう少し具体的なHowに近いものになるかもしれません。そこで、社内のGPTツールと会話してみたら、Engineering Caltureに辿り着いたのでした。 ↩︎
-
ISTQB（日本ではJSTQB）は認定資格ではありますが、ソフトウェアテストに関するシラバスが公開されていて、学習に最適です。 ↩︎
Discussion