こんにちは、昔買ったスーツがきつくなってきたので運動しなければと感じているCTOのNariです。
さて今回は“QA”についての内容になります！この記事では、「estieで今一番求められているのはプロダクト品質を追求する仲間である」ということを伝えたいと思っています。
estieでのQAの起こり
遡るともう4年ほど前になりますが、私が業務委託として参加したときは、estieは全社員で10人に満たず、数人の社員と多くの業務委託の方で開発が進められていました。当時のestieはスクラム開発も覚えたてで、2週間スプリントの最後あたりでPull Requestが乱立し、コードレビューが回りきらないままマージされていく状況でした。
そのような状況で決まったQAのプロセスがあるわけもなく、あらゆるものがマージされたアプリケーションをプロダクトマネージャーがチェックし、誰が作ったか特定できないバグに対してプロダクトマネージャー自らがコードを書いて直す、という流れになっていました。プロダクトマネージャーがコードかけてよかった…という話で終わるわけはなく、直しきれなくてリリースができず、顧客との約束を守れないことが複数回起こっていました。
今でも記憶に残っているのは、そのスクラムチームに参加した際に言われた「検証環境はバグっているものなので」という言葉で、「“検証環境はバグっているもの”…どういうことだ…」と頭に？ばかりが浮かんでいました。
その後どうなったのか…について興味がある方は、いつでもお話できるので声をかけていただければと思いますが、当時のことを思い出すとずいぶん遠くまできた気持ちになると同時に、これがまだ数年前の話だということに驚きます。いまやestieでは従業員数は90名近くになり、プロダクトは2個から9個に増え、毎日リリースすることができるようになっています。
そして、状況が変わればまた別の課題が起こってきます。
求められる品質の変化
ところで、この記事はQAに関する記事ですが、そもそも“QA (Quality Assurance)”、特に“Quality (品質)”とはあなたにとって何を意味するでしょうか。その定義は人によって解釈が揺れるものですが、estieでは「品質は顧客への提供価値に直結するもの」として大きく捉えています。そして、（多くの方が同意してくれると思うのですが）品質はフェーズごとに求められる基準が変わるものであり、それに伴ってあるべき姿を描いていくことになります。
創業当初の「検証環境はバグっているもの」というのは「機能が正しく動くことが担保されていない」という品質でしたが、それでも解こうとしている顧客課題が適切であることを確かめたり、ファンになってくれる顧客がいるかことを知るには十分なものでした。それがいまや業務課題を深く解決していること、セキュリティを心配することなく安心して使えることなど、顧客が求める品質の基準は段々と高まっています。
期待の高まりの要因は、ある意味でコンパウンドスタートアップとして複数プロダクトを同一顧客に提供し始めているestie自身であり、「あのプロダクトではできるけど、このプロダクトではできないのか？」といった要望が生まれてきています。つまり、新規プロダクトであっても、求められる品質基準が上がってきているわけです。
その期待にどのように応えていくのか、プロダクトを提供する企業として、品質に向き合う新しいフェーズに来ているといえます。
estieならではの難しさ
estieならではの難しさの1つとして「複数プロダクトを提供するスタートアップであるがゆえに、既存プロダクトと新規プロダクトの品質が比較される」という求められる品質の変化を取り上げましたが、これ以外にもestie特有の難しさは多く存在します。ここでは実際にどのような課題が置き始めているかを知っていただくために、さらに3つほど課題を挙げてみます。
1つ目は、よくある課題として、プロダクト・チーム数に比例して増加してしまう、バグ・インシデントを抑えることです。これらが発生する要因は、例えば各チームで少しずつ品質担保の仕方が異なることが考えられますが、今後プロダクトが増えていくestieにおいてさらに難しくなっていくと想定される課題です。
2つ目は、それぞれのプロダクトのドメインの深さに基づく、顧客体験の担保です。estieは不動産業界の多様なユーザセグメントと、多様な業務を支えるプロダクトを開発しているため、業界を問わない汎用的なサービスと比較して、各プロダクトが扱う業界特化のドメイン理解が必要で、ここがestieでのQAとしての面白いところの1つです。
この課題に対処するために、例えばプロダクトチームの各メンバーが顧客業務を深く理解してドメイン知識を身に付けることで、早い段階で誤りに気付くことができ、後段になればなるほど指数関数的に大きくなる修正のコストを抑えることができます。
estieの開発メンバーは不動産のことを全然知らなかった人がほとんどなのですが、社内の不動産業界出身メンバーからのインプットや、プロダクト開発を進める中で得る顧客の声、チームで物件を巡ってみるオフサイトなど、様々な方法でドメイン知識を獲得し、開発に活かす仕組みを整えようとしています。
3つ目は、estieが不動産業界の様々なデータをプロダクト間連携する際の整合性の担保です。estieは不動産業界にこれまでなかった網羅的でヒストリカルなデータ基盤を提供しており、データがコアな価値となっています。つまり、プロダクト間連携の際に、機能だけでなくデータの整合性が取れているかも担保することが重要な観点となり、この担保が非常に難解です。これについては、VPoE青木の記事で詳しく解説されているのでぜひ御覧ください。
これ以外にもセキュリティ担保などの課題はありますが、このようなestieならではのいくつかの理由で品質を担保することがどんどん難しくなっていく今だからこそ、改めて品質に向き合う必要があり、その仲間となってくださる方を探しています。
どのような方を求めているか
これまで述べてきたように、品質は顧客への提供価値に直結するものであり、開発をする人たちだけの問題ではなく、営業・CS問わずプロダクトを提供する全ての人の問題です。estieでは、不動産業界出身メンバーも多く、社外からのフィードバックだけでなく社内からの声も取り入れながらプロダクト開発が進んで来ています。まさにプロダクトの品質を全社で作ってきたといえます。
現在のestieでは、QA領域の重要さから他社でも見られるようにVPoE 青木が担当しているのですが、多数のプロダクトに対して専任のQAが macho （@ma_cho29）の1人しかいない状況です。
品質担保の基準をそれぞれのチームにあったように適切にデザインし、品質担保の文化を macho と一緒に作ってくださる方を今まさに求めています。
求められる品質の変化やestieならではの難しさに挑戦していくには、品質を顧客価値提供の観点で考えて実践していただける方がさらに必要だと考えています。「ユーザがどう使っているかを知るために営業についていく」と、あるシニアQAの方がおっしゃっているのを聞いたことがありますが、そのような動きを厭わない考え方を持っていただけるのであればestieに非常にマッチするのではと考えています。
ご経験のある方であれば、プロダクトがさらに増えて難易度が上がっていくestieにおいてレバレッジが効く方法を一緒に考えていただきたいですし、これまでQAの経験がなかったという方でも顧客視点を身につけて一緒にプロダクト品質を高めていただける方とぜひ一緒に働きたいです。
estieが提供できるものとしては、上述した“難しさ”がそのまま面白さになると思っており、様々なフェーズのチームへのQAのイネーブリング経験が積めること、複数プロダクトでそれぞれ深い課題に向き合うことができること、他の会社では珍しい“データの品質担保”も含む幅広い課題に取り組めるが積めることが挙げられます。掘れば掘るほど様々な可能性がある、そんなポジションを提供できます。
「品質は顧客への提供価値に直結するもの」に共感いただけた方、estieはあなたを求めています！ぜひ一緒に働きましょう！ご応募お待ちしております。
