なるほどなるほど。で、実際に今もともとプロジェクトマネージャーを経験した後にQAエンジニアに転向っていうふうなプロフィールでしたけれども、QAエンジニアに転向するっていうのは何かきっかけとかあったんですか。
ものすごく自分の昔の話なので恥ずかしいんですけど、もともとプロジェクトマネージャーになった経緯って、開発のラダーを登っていくとプロジェクトマネージャーになるんですよね。
当時はSIだったので。
で、そこでキャリアのことでいろいろ悩んでいた時期で、その時にたまたま入ったプロジェクトがオンライン証券の取引システムの開発の話だったんですけど、
そこでは自動テストのフレームワークの開発とかをやってて、それきっかけでテストのこととかを勉強するようになって、だんだんテストのこととか品操者のことが面白くなっていって、気づいたらそっちのほうが自分の中のモチベーションになっていたので、そこのタイミングでキャリアを切り替えたって感じですね。
なるほど。
ちなみに、その時にアスターとかJSTQBの技術委員とかに入っていった感じなんですかね。
当時は最初はJUSTにソフトウェアテストのシンポジウムなんですけど、JUSTっていうシンポジウムがあるってことを知って、
当時いろいろ読んでた中で、秋山さんのエイスト4の入門書籍があるんですけど、その本がすごく自分の中に刺さってて、秋山さんがミニチュートリアルをやるっていうのをイベントで見つけて、それがJUSTだったんですけど、
サインしてほしくて、ファン審議で遊びに行ったみたいな。それっかけでJUSTっていうものの面白さに気づいて、翌年にソフトウェアテストに関する研究会っていうのか、集まりみたいなものはあって、そこにお邪魔するようになって、だんだん知り合いが増えて、
JUSTの実行委員になって、その後にお話いただいて、JUSTの実行委員になるきっかけがあって、そこからJUSTの実行委員になり、そこからまた知り合いが増えて、アスターのNPO4人なんですけど、そこのNPO4人に上院して、その流れでJSTQBのリーズインなんかもやらせていただくことになりました。
なるほど、ちなみにいろいろと今、用語が出てきたんですけど、ヘイスト法は何て言えばいいんですかね。
ヘイスト法は余計です。
テストの設計というか、分析に近いのかもしれないですけど、テスト設計の手法の一つぐらい紹介でもいいですかね。
そうですね。テスト設計のテクニカルな一つですね、ヘイスト法は。
それこそ、それ以前の中野さんがどうだったかわからないですけど、テストっていうとテストの実行をどうするかみたいな話とかが多かったりする中で、当時のヘイスト法のテスト設計、開発者が実装するだけじゃなくて、それ以前に設計が必要だよねっていうのと同様に、
テストを実際に手順書を書いて実行するとかいう、その前に考えることがあるよねっていうのでテスト設計っていうのがあるかなと思うんですけど、やっぱりそこの秋山さんのヘイスト法がきっかけというか、最初そこでテスト設計っていうのを知る感じなんですかね、中野さんにとって。
そのちょっと前からテスト設計みたいなものはなんとなく。
テスト設計っていうものの意識がどこで芽生えたかはもうちょっと忘れちゃいましたけど、でも本格的に複雑な仕様とか膨大になるテストケースをどううまく現実的なところに落とし込んでいくかみたいなところにやっぱり設計の面白さがあると思っていて、
それができないからやっぱり辛いんですよね。そういう意味でやっぱり当時、書籍を読んですごく感銘を受けたし、こういうことがうまくなることでより楽もできるっていうところが自分の中ですごく面白くてですね、その辺からのめり込んでいった感じになりますね。
この書籍でそういうふうにやっていくといいんだっていうのがいろいろと感動というかであって、それでシンポジウムジャスト東京に参加して、ジャスト東京もそういうので参加して、なるほどみたいなところも多かった感じなんですかね、知見が得られたみたいな。
そうですね、実際に行ってみたら、秋山さん目当てで行ったんですけど最初、行ってみたら本当にいろんなドメインで全然違うことを考えて品質について取り組まれてるっていうのが一気に視野が広がったというか、そのショックもすごくあって、
自分が見てきたものって結構それまでExcelにテストケースを書いてそれを実行してバグを見つけるっていう割と地味な作業がテストっていうイメージだったんですけど、もう少し品質を広く取ったときに、もしくは広く捉えてるような捉え方が割とドメインでも違うし、それに対する向き合い方も違うし、
そこにすごく熱量を持ってる方ってものすごくたくさんいるってことがそのとき初めてわかって、それが嬉しくもありショックでもあり、それでどんどんのめり込んでいった感じですね。
なるほど、なんかテストのシンポジウム、JUSTっていうのがテストのシンポジウムですけど、ある意味特殊というか、多分開発だったらプログラミング言語ごとにそういうシンポジウムとかあったりする中、テストっていう一つの括りの中でやったりするので、さっき中野さんもおっしゃってたように、ドメインの違いがいろいろある中でいろいろ切磋琢磨してるとかっていうのも自分もJUSTに参加してすごい感じたところだし、
そういうところで響いて、けどそこから実行員になって、そこからAsterであったりとかJSTQBのっていう話でしたけれども、JSTQBの話でいくと、JSTQBというのがソフトウェアテスト技術者資格認定、どう説明すればいいですかね、JSTQBって。
でも、日本でもおそらく最もメジャーなソフトウェアテストの資格試験だと思いますので、シラバスとかも広く公開されてますし、
割と現状を足元を見るに割とデバクターな位置づけにいるのかなと思っていまして、この資格試験の扱っている標準的な用語とか技術的なところが割と業界に浸透してきたことで、
それぞれの企業文化独自のテストのあれこれみたいなことの際から余計なマスが起こらないような状況に少しずつなってきているのかなということは世の中を見ていて感じます。
なるほど、なるほど。自分もJSTQBって何って自分が聞かれたときに技術委員の中野さんを前にしてこういう雑な説明するのもあれですけど、
開発は結構基本情報技術者試験、情報処理試験は結構認識が認知度が高いと思うんですけれども、雑に言うとそれのテストとかについて扱っているような形。
けど同じように今中野さんがおっしゃってたように資格としてあるし、資格を取ってるかどうかっていうよりもやっぱり用語としてこういうものJSTQBではこういう用語ですよっていうので、
共通認識を取れるっていうのは本当にさっきまさにおっしゃってたように企業ごとの方言を少なくしていくみたいなところでは自分も非常に役に立ってるかなと思います。
そうですね。補足するとJSTQBはもともとはISTQBという国際団体の一つのボードなので、さっきの用語の話でいうと共通言語を日本だけじゃないですね。
共通言語を持てばこのISTQBに所属するすごくたくさんの国の技術者たちとコミュニケーションがスムーズに取れるので、その意味でその共通言語を持てるっていうことはすごく大きいと思いますね。
そうですよね。しかもISTQBの中でいうともう百何十カ国とかありますよね。
そうですね。かなり多いですね。
仮に他の、それこそ今後グローバルで働いたりとか、逆に今いる会社に海外の方のQAエンジニアが採用されて入ったとしても共通言語として使えるっていうのはすごい確かに役に立ちます。
そこで技術委員にもなられて、協調としてソーシャルテスト教科書JSTQBのファンダメーションの第4本が書かれたってことですけど、そこの執筆のきっかけというか、そこもコミュニティの中で書こうよみたいになって、じゃあ自分が書きますみたいな、そういう流れだったんですか。
もともと僕が今初版から参加してたわけではなくて、私がもう技術委員に上院したときにはもうすでに発行されたもので、途中で開判がかかるんですけど、途中のタイミングで自分もその教授さんに入れていただいたっていう感じになりました。
お客様が気づかないバグって、それってリリースまでに急いで直す必要があるのかみたいな議論があって、やっぱりものすごく警備のことを気にするよりもいち早く価値を届けたいっていう気持ちがすごく強い。
そこの熱量がすごく高くて、爆速開発ならではにそこの価値とお客様っていうところ、そこのところがやっぱりカルチャーとして面白いところかなと思いますね。
なるほど。爆速開発っていうところとQAってなると、QAっていろいろな動き方あったりすると思うんですけど、場合によってはQAがブレーキ役になったりとか、ゲートキーパー的なところになったりすることもあると思うんですけど、
そうするともう爆速開発でいくと、そこでブレーキかけられても困るんだよねみたいなことがもしかしたらあるかもしれないですかね。
そうですね。ブレーキになってるっていう感じではないんですよね。あくまでもそれをフィードバックしてるのがQAなので、
我々は止めようとしてるっていうスタンスではなくて、プロダクトの状態を適切にフィードバックして、それでチームでちゃんと判断していく材料を増やしてるみたいなイメージですかね。
なるほど。そうですね。フィードバックするってすごい大事だなって思っていて、結構テストの目的でいうとバグをどれだけ見つけられるかみたいなことを目的として見えたりもするんですけど、
それだけじゃなくて、それこそいろいろ確認をした上で、これだけテストしてこういうところは大丈夫でしたよとかっていう情報の提供とかっていうのは、
それだったらリリースしても大丈夫かなっていうふうに後押ししたりとか、そういうところの面でもテストを使ってたりとかQAとして動いているのかなっていうのを聞いて思ったんですけど、そんな感じですかね。
そうですね。やっぱり仕様も割とチームで、プロダクトチーム内で検討したりとかしてる部分もあるので、バグのこともそこだし、やっぱりUX的なことであったり、まだまだこれからやることはあるんですけど、
品質をいかに広く捉えてチームにフィードバックできるかみたいなところが、QAが担うべきところなのかなっていうふうに私自身は考えてます。
なるほど、なるほど。
そうすると、そんな中でライフルさんのときもそうですし、今のRayXさんでもQAマネージャーという肩書きというかだと思うんですけど、
今度はQAマネージャー、マネージメントのところでちょっとお聞きしたいのが、プロジェクトマネージャーも経験した後にQAマネージャーとかになっていると思うんですけど、
プロジェクトマネージャーと違う部分というか、QAとかQAマネージャー、QAマネージメントとかテストマネージメントならではの部分ってあったりするんですかね。
領域は被る部分はあると思うんですけど、大きくは見てる軸が違うのかなと思っていて、
そうですね、プロジェクト推進の軸、プロダクトを成長させる軸、品質軸みたいな軸の違いなのかなと思ってますね。
QAマネージメント、品質保証のマネージメント、テストのマネージメント、品質をマネージメントするっていうと、
それこそこのポッドキャストを聞いてる人にとってはどういうことをやるのみたいに思われる気がするんですけど、
すごい今中野さんの悩んでる顔が見えてるんですけど、品質マネージメントってどんな感じなんですかね。
QAのマネージャーは品質をマネージメントするのではなく、QAチームのマネージメントですね。
品質をマネージメントするって言ってしまうと、品質の責任があたかもQAにあるって聞こえちゃうと思うんで、そこは多分ちょっと違うのかなと思っていて、
品質ってやっぱり組織全体のものだし、組織全体で大事にしなきゃいけないものだと思うんですよね。
QAマネージャーのお仕事としては、それを実現するためにくわ立てる、先頭に立つ者たちがQAのチームだと思うので、
そこのくわ立てとか戦略とか、そういったところを一番考え込む人がQAマネージャーなのかなと思いますね。
今ここ聞いてる、それこそ開発者の人とかにとっても、QAが品質の責任を持つんじゃないのって思ってた方もいるかもしれないですけど、
やっぱりチームとして持つみたいなのは弊社10Xでも結構意識してるところはあると思っていて、それは今聞いててすごい近いなっていうのは感じました。
そうじゃないと、それこそさっき言ってた爆速開発とかの時に、QAだけが品質の責任を持っていないと、
うまくチームとして回りづらいかなっていうのは個人的な感覚としてはあるんですけど、やっぱりそういう感じですかね。
そうですね。チームで一番分かりやすいのは、やっぱりプロダクトの品質をプロダクトチーム全体で大事にしていくっていうところが分かりやすいのかなと思いますけど、
その結果、でもプロダクトの品質ってその人たちが開発するかもしれないけど、それを実際に携わる、それに関連するステークオーダーっていっぱいいるわけで、
その人たち全体が品質に興味を持つっていうことがすごく重要なのかなと思っています。
なるほど。
ステークオーダーっておっしゃってましたけど、だから開発者とかだけじゃなくて、それこそCSであったりとか営業の人とか、
そういう人も巻き込んで品質っていうのを結構考えていく感じなんですかね。
そうですね。開発に携わらなくてもやっぱり自分たちのプロダクトなので、そこにちゃんと誇りとか情熱みたいなものって持つべきだと思うんですよね。
当然、弊社もそうですし、10Xさんもそうだと思うんですけど、なので、自分たちが品質目線で自分たちのプロダクトを見たときに感じることであったりとか、
お客様も同時にそれを感じたときに、それをちゃんとコミュニケーションしていくっていうことがすごく重要だと思っていて、
それが一つの品質の取り組みなのかなっていうふうに思ってますね。
なるほど。それはもう本当に自分というか弊社もすごい大切にしたいなって思うところを改めて今の話聞いて思いました。ありがとうございます。
はい。で、ちょっとここまで結構自分の方からいろいろ質問ばっかりして、結構もう中野さんも冷や汗かいたような表情してますけど、
ちょっとここから逆に今ここまでいろいろ質問してて不安でもあるんですけど、逆に中野さんから自分ブロッコリーに質問したいことって何かあったりしますかね。
はい。特に冷や汗かいてるつもりなくて、ごめんなさい。ちょっと笑っちまいましたけど、
10XさんのQAの皆さんが価値観として大事にしているもの、そこのバリューみたいなものとかってどんなものがあるんですかっていうのを伺ったことですね。
なるほど。10Xとしてっていうところもちゃんと会社として、会社の品質管理部としてちゃんと言語化できてるかどうかわからないですけど、少なくとも10Xの品質管理部の一人の自分としてっていうと、
すごいやっぱり価値観として大事にしているのは、やっぱりいかにお客さんに使ってもらえてるかっていうのはすごい大事にしていて、
それは今までの自分の前職までの経験以上に、かなりお客さんの方を見ていると思っていて、もちろん前職まででも見てはいたんですけれども、
さらにすごい寄り添っている感じがすごいしていて、どうすればお客さんがすごいいい感じに使ってもらえるかっていうところ、そこをやっぱり大事にしていて、
そうするとやっぱり使用が書かれている、使用通りに動いているとか、こういうふうに言っていたからそれ通りに動くとかではなくて、
例えば修正であったりとか、機能開発によってお客さんが使ってもらえて嬉しいのかとか、そもそも作ったけども使えないよねってなったら、
一番もったいないと思っているし、コースとしてももったいないし、それはQAだけではなくて開発としてももったいないことだと思っているので、そういうことがないようにする。
なので一番最近自分はよくあるのは、開発が実装とかする前の段階で、開発としてはこういうコードを書きたいっていう話になったときに、
それってアプリ上の振る舞いだとどういうふうになるのかっていうところをすごい気にしていて、
それってアプリ上ではどうなっているのか見えてないとかだったらそこをはっきりさせましょうよとか、
その結果アプリ上の振る舞いではこういうふうに見えるってなったときに、
それってお客さんが本当にそれで解決できるのかっていうのは議論を結構しているところになります。
それはちょっとスクラムの文脈で言うとリファイメントっていうスプリント開発が入る前の段階での、
そもそもどういうものを作ろうかっていう議論のときに結構そういう話はしていて、
そこは前職まででも大切にはしてたんですけど、それ以上に大切にしているところかなと思います。
はい、ちょっと質問の答えになってるかわかんないですけど、そこはすごい価値として感じているところです。
今それがまだそこまでないので、個人としてある人だったらできるけど、ある人だったら気づかなかったかもしれないとか、
そういうことがあるので、そこを課題として個人的には感じていますし、そこを何とかしていきたいなと思っているところですかね。
確かにあれですよね。スタートアップっていろんなところからいろんな方が入ってこられるから、
それは開発のいろんな人たち、いろんな職種の人たちが入ってくるし、QAもそうだから、
すごくこの言葉のバラツキとかすごい気になりですよね。めちゃくちゃわかるよ。
それこそさっきまで話してた方言的なやつもあったりもするとは思うのし、
そこがその人たちが、例えば方言があったとしても、その人たちが考えてること自体は全然間違ってないと思っていて、
ただただ言葉が合ってないとか、合ってないっていうのは人それぞれずれちゃってるとかっていうのもあるだろうし、
あとは先ほどテスト設計とかテスト分析っていう話ありましたけれども、
それらもテストプロセスの考え方としてテスト分析があってテスト設計があってとかっていうのがあると思うんですけど、
人によってはテスト分析が成果物にないことがあって、
ただそれって多分テスト分析の成果物が表現されてないだけで、
多分頭の中で考えているはずなんですよね。それが表現されてないだけなので、
その頭の中で考えていることをアウトプットしようよみたいな話もしていて、
その人自身が多分考えていることは決して間違ってないし、
頭の中で考えているから見えづらいだけで、それを見えるようにして、
あなたはこういうこと考えてたんですね、テスト分析の段階でっていうのを明らかにしていくっていうのは今後やっていきたいことかなと思っています。
いいですね、確かに。
そんな感じで大丈夫ですかね、質問は。
大丈夫です。ありがとうございました。
自分も質問どういうの来るのかちょっとヒヤヒヤしてたんですけど、
すごいいい質問をいただけて本当にありがたいなと思いました。
とても参考になりました。ありがとうございます。
ありがとうございます。それではエンディングです。
本日は株式会社レイアーXの中野さんをお招きして、QA品質保証について語っていきました。
最後に中野さんから何か宣伝とか告知したいことがありましたらお願いします。
ありがとうございます。弊社QAチームの仲間を絶賛募集中です。
すごくスタートアップっていう領域で、SaaSでFintechですごく面白いこの爆楽シリーズの爆速開発、
一緒にQAで汗かいてくださる方を募集しておりますので、興味あればぜひカジュアルメンバーからやってますので、
お声掛けいただけると思います。よろしくお願いします。
ありがとうございます。そういう意味だと10Xも同じように募集をしているので、
それも宣伝というか告知としてお伝えしておきます。
10Xでも現在様々な職種のメンバーを募集しています。
QAだけではなくて様々な職種のメンバーを募集しています。
この10X FMを聞いて10Xに興味を持ったとか、ちょっとカジュアルに話を聞いてみたいと思われましたら、
番組概要欄に採用情報とか、あとは10Xのホームページのリクルートからご応募ができますので、ご応募お待ちしております。
またこの10X FMではリスナーさんからのお便りも募集しています。
エピソードの感想や10Xのメンバーに聞いてみたい質問など、どんなことでも構いません。
また今回の感想であればもちろん中野さんにもお伝えしたいと思っています。
番組概要欄にあるお便りフォームからの投稿、またはTwitterでハッシュタグ10X FMでツイートをお願いいたします。
そして最後にSpotify、Apple Podcastなど大ききなPodcastのアプリで番組のフォローもお忘れなく、最新のエピソード配信時にお知らせが届いたり、
また過去のエピソードの再生済み、未再生が一目で分かるようになり大変便利です。
ということで本日のお相手はブロッコリーと株式会社レイアXの中野さんでした。中野さんありがとうございました。
ありがとうございました。
それではまた次回お会いしましょう。