品質管理部の職種と役割
皆さん、こんにちは。 株式会社10Xソフトバイエンジニアのフタブーです。
この10X.fmは、10Xを作るようミッションに、公立MKECプラットフォームSTAYLAを提供している株式会社10Xのメンバーが、キャリアや日々の出来事、学び、プロダクトに対する思いを包み隠さず、リアルにお届けしていくポッドキャスト番組です。
今回は、10X.fm内の企画の一つであるエンジニアの部屋の第6弾として、品質管理部のたらっぽさんにお越しいただいています。
たらっぽさん、よろしくお願いします。
よろしくお願いします。
早速なんですけど、最初に簡単に自己紹介をお願いできますでしょうか。
はい、わかりました。
品質管理部の部長をしている平田ことたらっぽです。
10Xには2022年の4月入社なので、今もう1年8ヶ月ぐらいですね。
入社してから経っています。
最初に品質管理部。
そのとおりじゃ、
品質管理部なかったので、QAチームっていうところでしたけれども、最初にQAに関する職種の一人として入って、そこから品質管理部ができて、今部長として組織を色々と作っているっていうところになります。
本日はよろしくお願いします。
よろしくお願いします。
僕とたらっぽさんの出会いみたいなの、最初ちょっと全然仕事のとこ関係ないですけど、お話ししたいなと思ってて。
餃子を食べに行ったのが、初めてです。
初めてリアルでお会いしたときですよね。
そうですね。餃子で出会ったのが、物理的には最初だと思います。
僕が当時勤めてた会社の同僚が、多分iOSエンジニア、彼はiOSエンジニアで、多分iOSDCとかのつながりで誘った人の、さらにこうつながりでたらっぽさんがいてみたいな。不思議な縁で餃子を食べに行ったりとか、そういうふうに思ってますね。
そうですね。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はがい
そうですね。あの時の行勢は今でも言いますね。
あー、いいですね。美味しかったですね。
はい、ありがとうございます。
じゃあ、そんな感じで、お仕事の話とか聞いていければなと思うんですけど。
そうですね。
今、品質管理部の部長としてっていうところと、
あともう一つ、
お会計チームにセットとしてみたいな感じになるんですかね
そうですね
今は認識管理部部長と
あとはお会計チームにセットというスキルを生かした形で
関わっているというところになります
あと一つマスターデータチームというところにも関わってますけれども
お会計チームは結構長く関わっているという感じですね
お会計チームの中では
実際セットのスキルみたいなのを生かして働いているというところだと
もう少し具体的にどんなことをやっているかとかって聞いてもいいですか
はい
うち品質管理部としては
外にはジョブディスクリプションとして
セット
一般的にあるソフトウェアエンジニアにテストというものと
Qエンジニア
テストエンジニアというのを出しているんですけれども
内部的にはその3つの職種
それぞれの特有のスキルだけを使うというわけではなくて
総合して品質管理部の職種それぞれのスキルを
得意なものを生かして働いているという感じになっています
その中で私はお会計チームでセットスキルが一番強いので
お会計チームとテスト戦略
セットスキルとQエンジニアのスキルとテストエンジニアのスキルを
いろいろやりながらお会計チームの中で動いています
お会計チームって名前の通りお金を扱うという
非常にセンシティブなチームになるので
守りをとても強くしなきゃいけない
ミスをそんな簡単にするわけにはいかない
というところでその中でいかに守っていくか
というテストの戦略を考えながら
そのコードに対してどう守っていくか
なので一般的によくあるアプリを通してとか
ウェブを通してエンドツーエンドテストを
ガンガンやっていこうぜというよりかは
コードを見てそれに対して自動テストもしっかり持って
自動テストで守れないところは
自動テストを使っていこうねみたいな
テスト戦略を考えて日々
しているという感じですね
たらっぽさん自身が自動テスト書いたり
みたいなこともやったりするんですかね
最初の最初は書いたことはあるんですけど
結局私はそれやっちゃうと
全然回らなくなっちゃうので
私はあくまでもプロダクトコードと
エンジニアが入ったテストコードを見た上で
こういうテストコードが足りないとか
テストコードに対する書き方に対するヒードバックとか
そういうのをメインに行いながら
そんでするテストコードとプロダクトコードをもとに
ここは自動テストだと守りきれないよね
っていうところをリストアップして
それを普通に自動テストするっていうのに
持っていってる感じですね
自動テスト自体は書くことはそんな多くない
ほぼないぐらいの感じですがね
エンジニアの方に書いてもらっている
書かれたテストコードをレビューするみたいなのとか
この観点を追加しましょうみたいなのは
どういうふうに書いてもらっていいのか
基本的にはプルリクベースで全部やってるんですけど
お会計チームに限らず
他もそうだと思うんですけど
基本的にコードにドキュメントを書いてくれているはずで
そのコードドキュメントと
あとは実際の仕様書
あとはそのプロダクトコードの中身を全部見た上で
テスト設計をしていくわけですね
結構お会計が使っている中でも
状態遷移とかがいろいろあるので
状態遷移とかを書いてるんですけど
書いたりしながら見てると
テストケースここ足りないよねとか
ここは自動テストに守った方がいいよねとか
見てくるので
コードもドキュメントも全部見てやってるって感じですね
テスト設計のところを
もうちょっと具体的に
こんなことをやってましたとかって
話せる範囲で聞いても大丈夫ですか
そうですね
なかなかレイジが難しいところはあるんですけれども
お金回りも結構状態遷移があって
クリストカードでお金を払うってなった時には
最初はその大反りっていうものを取って
その後キャプチャーとかが当然あるわけで
その中の状態遷移の中を
あくまでも文字だとわかりづらいんで
状態遷移図をちゃんと書いて
その状態遷移図を書いた時に
このパターンはどう守られてるのかとか
このパターンはそもそも守れるのかとか
そういうのを図式化して
それを見ながら自動テストに対して
どこが担保されてるかっていうのを
見たりするっていう感じになります
マニュアルテストと自動テスト
特にお会計チームが使っているものって
結構外部サービスを使うものが多くて
決済も結局
決済サービスに連携していながらやるものになるので
自動テストだとそこってテストダブルを使うじゃないですか
なのでテストダブルを使わざるを得ないところに関しては
どう守るかとか
そういうのを文字や図にしながら表していく感じ
になりますね
今うんうんって言いながらうなずいて聞いてたんですけど
テストダブルって何ですかっていうのを聞いてもいいですか
そうですね
なんかテストダブルって言うと
皆さんMockとかStubっていうのを思い浮かべるのかなと思うんですけれども
基本的にはそのテストしづらいものに対して
テストダブル自体はスタントマンって意味があるんで
要は置き換えるものになります
なんでMock、Stubに置き換えて
実際にはアクセスせずに返すっていうものを取っていくんですね
実際にはアクセスせずに返すっていうものを取っていくんですね
特に結成サービスで
さすがに結成サービスに対して
自動テストでバンバンバンバンリクエストを発行する
っていうわけにもいかないので
そういうものに関してはテストダブルを有効に活用していこう
でも使わなくていいところに関しては
極力本物を使おうみたいな形は取ってます
そうですね
自動テストとマニュアルテストの関係みたいなところも
ちょっと聞いてみたいなと思って
僕は
10X来てから結構テストコードを書いたりとか
するようになったっていうのがあって
今までは割とマニュアルのテスト
それこそテストのチームがいて
そこにもお願いしますってやってもらうみたいなことが多かったんですけど
今みたいにしっかりとコードを見た上で
自動テストが整備された状態のマニュアルテストって
どう進めるのかとか
そういった場合はどういう観点が大事だったりするのかとか
ちょっと聞いてみてもいいですけど
そうですね
お会計の場合だと
結局最終的には
それはサーバーサイドでいろいろやっているものの
クライアントサイドで
関係する話になってくるので
実際にテストダブル使ってたら
本当に問題なく動くんだって
一切見ないっていうのはなかなか危ないので
そういうテストダブル使っている箇所に関しては
正常系
一般的に問題なく動くようなものに関して
本当に動くかどうかっていうのは
自動テストで見なきゃいけないよねっていうのはありましたが
あとは実際の見た目っていう観点も大事で
何かしら作ったときに
エラーが発生したときに
どういうふうなハンドリングをして
どういうふうにユーザー見しているかっていうのは
コードを見て想像はつくんですけど
実際に使い勝手がいいかとか
見た目大丈夫かって
さすがに自分の中でコンパイルしても
頭の中のコンパイルは信用しきれないので
そこに関しては
実際にお会計チームの方だと
エラーを起こす
専用の動作確認用のプロジェクトを作ってもらって
実際に実際に見たときに
自動テストで見たときに
アップデートしてみたときにどう見えるかとか
実際に変になっているかっていうのが
見えるかっていうのを
自動テストで見ようとかはなってます
なので
SWでやっているような箇所とか
あと見た目が見なきゃいけないよねっていう箇所に関しては
基本的には
自動テストに担保しているっていう形をとってます
なるほどですね
そこを例えば
E2Eみたいな
感じで
UIもテスト書くかみたいな感じには
まだなったりはしないんですかね
そうですね
そこら辺に関して
一般的なエンドツーエンドテスト
Flutterもインテグレーションテストあるので
セットを使ったテスト戦略
そういうのを活用するっていう手は
一定あるとは思っています
ただ正直
今お会計チームの中において
それを導入しても
そこまで
表提効果は良くないんですよね
結構今の自動テストで守れている
という
範囲が多いので
そうすると運用コストって
どうしても高くなってしまうので
それを考えると
ガンガン導入するよりかは
今のスタイルの方が
現時点では良いっていうところですね
ただ将来的には多分
入れた方がいいケースも出てくるんで
入れたいとは思ってはいるものの
現時点ではこのスタイルが一番最善だろう
っていうところですね
でも他のチーム
例えばお会計以外のチームにおいては
結構これが効果を発揮するっていうのは
あるとは思うんですけども
お会計のチーム特性を考えると
今はそっちで
エンドとエンドのテストを追加するよりかは
サーバーサイドの自動テストをいかに守れるようにするかとか
そういうところに重点を置いてるっていう感じですね
チームの特性みたいなのが
今お話であったんですけど
そのお会計はこういう特性で
UIのテストもあると良さそうみたいなのは
逆にこういう特性を持ったチームとか開発みたいなのは
もうちょっと聞いてみますかね
言ってもいいですか
なかなかチームトークスで
完全に把握してないので
ここが効くぞと言い切れないところがあるんですけど
でもお買い物とかを届けば
よりユーザー
それがパートナーだったり
エンドユーザーだったりしますけど
に近いところで
ちゃんと動くかどうかもあるし
エンドツーエンドテストの目的なかって
今だとパフォーマンスのデータも取れるんで
本当に問題なく
動いているのプラス
それがサクサクなのっていうところ
サクサクがパフォーマンステストだけで
取れるわけではないですけど
以前と比べて遅くなってないのとかは
見れるんで
そういうところには一定の効果を発揮できるだろうな
っていうのはあるかなと思っています
特に見た目も当然取れるし
それを考えると
いろんなことが
そっちの方ではバリューを発揮できるんじゃないかな
とは思うものの
ただ正直ステーラーって
状態複雑で
エンドツーエンドテストやろう
って思ったときに
その状態を作るのがしんどいよねっていうのがあるので
運用コストもそうだし
自動テスト
要はエンドツーエンドをしやすい
その作りになってるかっていう大前提があるので
いきなりやろうぜって言ったとしても
ちょっと先に考えなきゃいけないことは
言ってやるかなって思ってますけどね
いや本当そうですね
自分はクライアントメインで今解体するんで
UIのテストよりも
まず先にやっぱりこう状態
ステートとかの方の
テスト書いて
それからだなっていう感じは
やっぱ結構あったりしますね
今もないわけじゃないんですけど
整えたいなーみたいなのはあったりしますね
そうですねそこら辺なんか
整えていくにあたって
やっぱセットスキルが一定ある人が入って
自動テストとかをサポートしながら
こうやっていけるといいなとは思うので
ぜひとも品質管理部にもう一人
セットが来てほしいなとずっと思ってますね
いいですね
もともと
分かんないですけど
もともとセットソフトウェアエンジニアテストになろうとして
なるみたいな人もいると思うんですけど
例えばソフトウェアエンジニアとして
コードを書いた人が
テストに興味を持ったりとかして
入っていくみたいなパターンもあるのかなと思ってて
こういう人はセットを向いてるなとか
っていうのってあったりするんですかね
そうですね
何だろうな
でもセットに向いてる人って
当然テストに対して強い興味があるとか
あとはテストに対して
何かしら痛みを持っている
っていう
そこに対していろんな思いを持っている人っていうのは
大事かなと思っていて
結局そこら辺に対していろいろやってきて
ここテストしておけばよかったとか
次ここでやれるなとか
何かしら痛みを負いながら
いろいろと
経験してきたもの
っていうのは重要だったりするんで
そういうのがあるといいなとも思うし
当然テストが好きならウェルカムだし
セットってまだまだ
業界的には名前はちょっと知られて初めているけど
そんな多くない職種なので
新しいキャリアの一環として
テストっていうのに興味があるなら
手を出してみるのもありかなとは思いますけどね
セットのキャリア
やっと
やってみたいなって思う人は手前味噌ですけど
じゃあ10Xで働くと
すごいいい環境を用意できるかもな
みたいな感じですか
そうですね
そこはいい環境を用意できると思います
私も一緒にやりますし
なんかあと
うちってサーバーサイドとクライアント
別々じゃなくて一緒にやってるじゃないですか
あれってなんか過去そんな経験今までなの?って思いますよね?
あれってなんか過去そんな経験今までなの?って思いますよね?
あれってなんか過去そんな経験今までなの?って思いますよね?
私の中ではなくて
結構別れてるのが一般的だったので
そうするとサーバークライアントを一気通貫で見れるって
セットからすると
テスト戦略のやり方がすごいいい感じにできるんですよね
サーバーサイドはこうしてて
クライアントサイドはこうしててっていうのを
行き来しやすいっていうか
一つとして見れるんで
なのでなんかセットとして
そういうところをやっていくってなると
効果的に見れるって意味では
結構いい環境なんじゃないかなっていうふうに思いますね
動きの中でのサーバーだけを見てロジックだけじゃなくって
機能一つをまるっと全体を把握した上での
テストの設計ができるとか
そこを見た上で
じゃあサーバーってどうすればいいんだっけみたいなのを
考えることができるみたいな感じですかね
そうですそうです
なんか分かれてしまっていると
それはそれで当然メリットがあるんですけれども
なんかサーバーサイドで何をやってるかが分かってなくて
クライアントサイドで無駄に厚く守ってしまうとか
逆の叱りとかもあったりとか
連携ミスが起こるとかってのもあったりとか
あとなんか両方見たいけどコードが違うから
読みづらいとかも普通にある
そういうのがないので
結構そういう意味では
やりやすいというか
テストの戦略を考える上では
面白いというか
一気に見ることができるような
いいなって
最近周りの人と話してて気づきました
忘れてましたけど
いいですね確かに
ありがとうございます
そしたらちょっと
別の観点のお話
品質管理部の役割と組織の変革
今お会計チームにおける
役割とかもやってること
セットとはみたいなところをお聞きしたんですけど
品質管理部の
部長という役割としては
どんなことをやられてるんですか
これはですね
基本的には
今ってエンジニアインゴ本部に
品質管理部がいて
開発チーム体制になっていて
いろいろと皆さんいるっていう中で
品質管理部はどうやって動くのっていうのは
全部任されている状態なので
じゃあステイラーっていうのを守ろうってなった時に
我々はどういう形を
今の人数とかスキルセットを持っているメンバーで
やればいいのかなっていう
その組織のあり方を
日々考えてると
っていうのはあります
目指すべき姿っていうのがあるけれども
今の我々は何ができるのとか
何ができないのを考えた上で
動かなきゃいけないので
なので
偽装はこうだけど
確実にできるわけじゃないから
その中で我々ができるのってどうなのっていうのを
常に考えてる
その中で今年の4月から
開発チーム体制になって
あそこでうちはそれに乗らないと
今後を考えたら
厳しいなっていうところで
組織の形を変えたりとか
組織の形を変えた時には
どういうメンバー配置にするといいかとか
このチームはどういうスキルセットを持ってる人がいいかとか
そういうチームとして
誰がどのように関わるとかを考えたりするとか
さらにはこの先
開発チームがどう変わるかとか
あとエンジニアリング本部としてどう動くかっていうのは
一定情報は共有されるので
それに対してうちはどうするかっていうのを都度考えたら
結局はステイラー全部守りたい
良くしたい
もっと早くいろいろと出したいとなった時に
我々はどこに強くベットする必要があるのか
何をする必要があるのかっていうのを
考えているっていうところにはなります
テイクスは良くも悪くも
何でしょうね
組織の構造とかスタートアップあるあるかもしれないんですけど
仲間としては
仲間としては
仲間としては
仲間としては
仲間の組織の構造って
割と頻繁に変わる方だなと思っていて
そこに影響されてチームのことを考えるの
すごい大変そうだなとか思ったりするんですけど
工夫されてることとかあるんですか
メンバーとの共有と開発体制に寄り添う
いやもうただただ大変ですけどね
メンバーがどういったことやりたいかとか
どういうスキルセットを持ってるかっていうのは
知らなきゃ始まらないので
そのメンバー自身
どういう人たちがいるかっていうのは
常日頃から
定期的にワンオンしてるんで
そういうので把握したりとかすることで
どういう風にメンバーを頑張ってもらうか
私も頑張るんですけど
っていうのを考えるっていう形ですね
結局のところはもう
メンバーのことを理解した上で
開発体制に寄り添っていけるかどうかっていうのを
常日頃考えるっていうところですね
さっきのこう
お買い物チームのやってること役割みたいなところと
日に通管理部の部長としてやってることみたいなのが
すごい使う頭が違いそうだなと思っていて
コンテキストスイッチ大変そうだなって思ったんですけど
実際はどうですか
そうですね
お買い物チームの品質管理部
もう違うので見るべき視点が変わるので
大変ではありますね
でもお買い物系チームにいて
お買い物系チーム視点で見ながらも
日に通管理部の部長として
その案件を全体でどう見るかっていう視点をやると
プラスの効果はあるんで
コンテキストスイッチは激しいし
一つのチームの中にいながらでも
コンテキストスイッチは発生してるんだけれども
そういうことをすることで
全体感は保てるので
やんなきゃいけないっていう感じですかね
でも確かにおっしゃる通り
コンテキストスイッチは激しいので
1日のうちにコロコロ変えたくないですね
今日は移管部長として働きたいとか
そういうのはあります
ありがとうございます
そういった意味でも
窃盗早く来てくれると嬉しいな
みたいなところは
そうですね
来てほしい
すごい来てほしいですね
言わせているみたいになっちゃいますけど
ありがとうございます
最初僕が聞きたかったことは
結構聞けたなと思っていて
タラップさんの方からも
もうちょっとこの辺話したいなとかって
あったりしますか?
そうですね
私は逆にフタブーさんに聞きたくて
フタブーさんって私より先に入社されてたじゃないですか
なので私が入社される前の状態から
今の開発チーム体制に変わっての状態まで
全部一応知っていると思うんですよね
その中で正直現場で開発してきたエンジニアにとって
この1年半ちょい
フタブーさんが入られてからの
2年間ぐらいの間って
ぶっちゃけ品質面って考えるときに
どうでしたっていうのは
聞きたい気はしますね
そうですね
一言で言うと
よくなったなとか思ってますね
品質がよくなったなって言ったときに
品質ってなんだみたいなところとかは
あったりするんですけど
一旦定義とか無視して感覚っていうところだと
僕が入ったばっかりの頃と
今2年とか3年とか経ってって考えると
めちゃめちゃ良くなったなって思いますね
もうちょっと具体で
僕がいるお買い物チームで言うと
今品質管理部のメンバーとしては
屋さんがほぼ月一切りで入ってくれていて
この間とか何ですかね
朝会で
今こういう機能作ってて
今度テスト設計お願いします
みたいなのを言って
テスト設計しまっているときに
あれそういえばこの仕様ってどうなってますか
みたいなのを屋さんから突っ込まれて
ちょっとそれ確かに観点考えられてなかったんで
実装漏れてますわみたいな話をしたりとかして
実際に手を動かしてテストする前に
仕様を見てもらった段階で
バグりそうなところが見つかるみたいなところがあって
それはすごい自分の体験としてはめちゃめちゃ良くて
屋さんがいる安心感がすごいあるなって思ったりはしてますね
それは本にちゃんと聞かせたいですね
そうですね
振り返り会とか言った気がしますね
この間のあれでめっちゃ助かりました
ぜひこれも聞いてほしい
そうですね
そう言ってもらえるといろいろと我々としては嬉しくて
でもまだまだ目指す姿からしたら
到達はしてないので
もっといろいろと関わっていけたらいいなとは
まだまだ思いますけどね
品質向上への取り組み
そうですね
これは僕の個人の考えっていうところですけど
レビューじゃなくて
仕様を作るとか
実際に使う体験を作るところとかから
QA 品質管理部もそうだし
デザイナーとかソフトウェアエンジニアとか
プログラムとかとか
プロダクトマネージャーが一人で考えて
何かそれをレビューしてというかは
もうちょっと同期的に一緒に考えてやれる
みたいなチームになっていけると
いいなと思ったりはしてますね
そうですね
そこらへんお買い物とかお届けとか
そういうチームはそういうのがやりやすい
やるといい効果を生む
側面が結構強いんじゃないかなと思いますね
そうですね
今まで
どうぞ
ごめんなさい
お会計もそういう側面がなくはないんですけど
結局インボイスに対応しますとかって
仕様はもはやお国がみたいなところが一定あったりする
それとは違って
そういうのがお買い物とかお届けは一定あるし
民間メンバーとしても
そこまでやれると楽しかったりする
そういうのがやりにくいですね
お会計とお買い物だと
確かにそこの何でしょう
システムオブレコードみたいなやつと
エンゲージメントみたいな
違いが多分結構あって
いかにこう仕様はあって
そこを堅牢に守るかみたいな
そもそも仕様はなくて
体験をどう良くするかみたいなのは
考えるところとか違うな
動き方違うなってのはありますね
そうですね
そこらへんも
民間とかのメンバーも
それぞれ要は
体験を良くしていく方が
得意好きなメンバーもいるし
逆に守らなきゃいけないメンバーもいるし
そういうものを
いかに良く守っていくか
っていうのが好きな人
得意な人もいるし
チーム特性とメンバー特性
そこらへんは結構我々も
メンバー特性とかがあったりするので
チーム特性とメンバー特性を合わせて
対して考えていかなきゃな
っていうところがありますね
ありがとうございます
このエンジニアの部屋第6回目にして
今までは結構僕が
一方的にゲストで来ていただいた方に
質問を投げかけていくというターンだったんですけど
初めて逆の質問をされて
ワタワタしてしまいました
めっちゃ新鮮で良かったです
そう言ってもらえると
ガンガン聞いてもらっても構わないですけど
そうですね
もうちょっと何か
いろんなこと聞いたりとか
深掘っていきたいなというところはありつつ
いいお時間になってきたので
今回はこの辺で
締めさせていただいて
また次回ちょっとゲストとして
お呼びしたいなと思っております
はいお待ちしてます
ありがとうございます
今日はタラッポさんをお招きして
お会計チームのセットの話とか
品質管理部としての動きみたいなところを
聞いてきました
10xFMではリスナーさんからのお便りを
募集しています
エピソードの感想や10xのメンバーに
聞いてみたい質問など
どんなことでも構いません
番組概要欄にあるお便りフォームからの投稿
またはツイッターで
今はxで
10xFMでツイートをお願いいたします
また10xでは現在様々な
職種のメンバーを募集しています
この10xFMを聞いて
10xに興味を持ったカジュアルに
話を聞いてみたいと思われましたら
こちらも番組概要欄にある採用情報
または10xのホームページのリクルートから
応募をお待ちしております
最後にSpotify、Apple Podcastなど
お聞きのPodcastアプリで
番組のフォローを忘れなく
最新エピソード配信時に
お知らせが届いたり
また過去エピソードの再生済み、未再生が
一目で分かるようになり大変便利です
今日のお相手は
フタブーとたらっぽさんでした
それではまた次回
