QAについてのイントロダクション
皆さん、こんにちは。株式会社10X、品質管理チームのブロッコリーです。
この10X.fmは、10Xをつくるをミッションに、小売チェーン向けECプラットフォームStaylerを提供している株式会社10Xのメンバーが、
キャリアや日々の出来事、学び、プロダクトに対する思いを包み隠さず、リアルにお届けしていくポッドキャスト番組です。
今回は、私ブロッコリーがホストとなり、他社の方をゲストに招いてQAについて語っていく企画、「QA部屋」をお届けします。
ということで、今回のQA部屋のゲストは、トヨタ自動車株式会社のQAテスト・テックリードである井芹洋輝さんです。
井芹さん、よろしくお願いします。
よろしくお願いいたします。
それではまず、井芹さんのプロフィールについてご紹介いたします。
井芹ひろきさん、開発者、テストエンジニア、コンサルタントなど、様々な立場でソフトウェアテストに従事。
現在はトヨタ自動車にて、デジタルコックピット開発のテストチームのテックリードやプロジェクトのQAリードを担当。
プロジェクトのテスト・QA活動の方針立てや運用を主導。
主な著作・講演に、テスト自動化の成功を支えるためのチームと仕組み、システムテスト、自動化標準ガイド、Androidアプリテスト技法などがあります。
ということで、今ご紹介したプロフィールや、もともとの井芹さんの印象を踏まえて、まずはここを話したいと思っていたところを、私の方からいくつかお伝えしておきます。
今回、井芹さんにお声掛けした理由としては、組み込みのテストについてまず聞きたかったというところがあります。
私自身、組み込みの経験がないので、本当に純粋に興味があります。
あとは、プロフィールには書いてなかったんですけれども、テスト設計コンテストのUnder30の審査委員をやられていたりとか、前には審査委員長もやられていたというところもありますので、
テスト設計についてもお聞きしたいです。
さらに以前に雑誌ソフトウェアデザインの2024年の2月号にて、私も井芹さんも一緒にテスト設計の特集の寄稿をしていました。
その中で井芹さんが寄稿していたのが、主にシフトレフトの話を書かれていたんですけれども、そこら辺についてもお聞きしたいなと思います。
ということで、井芹さん、改めましてよろしくお願いします。
組み込みシステムにおけるテストの重要性
よろしくお願いいたします。
まず、今の仕事のところ、現職の話を聞きたいなと思うんですけれども、
現職だとデジタルコックピット開発のテストチームのテックリードということなんですけれども、
まずこのプロダクトというか、この開発って具体的にどういうことをされているんですか。
はい、コックピットシステムは車の操作に関わるシステム全般でして、主にナビとメーターのシステムがテスト対象になります。
それに対してテックリードとしてテストやQAをうまくやっていくというのが主な立場になっています。
なるほど、なるほど。
ちなみに、テストチームのテックリードっていったときのテストチームって、もし答えられればいいんですけれども、
だいたいどれぐらいの人数規模で行っていたりするんですか。
はい、そうですね。テストチーム自体は数百人ぐらいいますし、
あと立場としてはプロジェクト全体のテスト、会社のテストも含めてすべてのテックリードを担当しています。
すごい、数百人っていうのがなかなか自分は経験したことがない規模なんですけど、
数百人でのチームのテストのテックリードってなると、その人数規模だからこそ難しさみたいなところってあったりするんですかね。
はい、やはりそうですね。個々の成果物を見ていくと間に合わないので、やっぱりレバレッジをかけていく必要があります。
プロセスや戦略を立てて全体に展開したりとか、あとはレビューするにしても結構レバレッジポイントを見極めて、
そこをレビューするみたいな形で、いかに自分の少ないリソースの影響力を広げていくかっていうのが大事になってきます。
なんかすごい、確かに自分のリソースは一人で限られているからこそ、そこを効率的に使うってすごい聞いてて大変そうっていう風な感想を持っちゃったんですけど、
実際やってみて大変だなとかっていう風に感じたりすることってあったりします?
大変ですね。改善するにしても、例えばスクラムチームも数十チームありますので、展開するにしても各チームとのミーティングすり合わせだけでもかなり時間が取られてしまっているのがあります。
規模がでかいとやっぱり失敗のコストが高いので、なるべく精度高く仕事をしないと結構うまくいかないことが多いです。それがやっぱり大変なところです。
なるほどなるほど。そうすると、例えば標準化であったりとか、チームによって俗人的にばらけづらいようにする。
ちゃんとすごいできる人はどんどん進めてもらえればいいんですけど、やっぱりその人数とかになると、底上げをするっていうような活動がいろいろあるのかなと思ったんですけど、
そういう標準化とかっていうのもやられてたりするんですか?
そうですね。5割はそこですね。やっぱり標準化、プロセス整備、戦略立て、プロジェクトマイルストーンの整備とか、そういった底上げのものは重要な仕事ですね。5割ぐらいです。
5割は結構クリティカルな課題があるじゃないですか。本当にこれ成功させないと失敗するような技術導入とか、そういったクリティカルな課題の対応を個別にやっていくっていう、全体の底上げと本当に難しいピンポイントの技術支援の両方をやっていくという形です。
なるほど。すごい。じゃあ続いて、人数規模を踏まえたところのお話を今していただいたんですけども、次にドメイン的な話で、組込み系になると思うんですけれども、やっていることが。
自分がやっぱり組込みっていう経験がないので、そうなったときに組込み系とそれ以外、特に自分とかだとウェブ系とかなんですけれども、そういう組込み系とそれ以外でテストをやるにあたっての共通点とか相違点ってあったりするのかなと思っていて、まず共通して大事だなと思うところってどういうところがあったりするんですかね。
正直言うとバラバラなんですよね、プロダクトによって。例えば、カーナビとかのシステムだと普通にLinux上に動くPCソフトと変わらないので、クライアントアプリと同じようなアプローチを取りますし、機械制御ですとリアルタイムOSでかなりハードウェアと共存したテストをすることもあって、結構プロダクトによってバラバラな感じですね。
今のシステムですと割と変わらないかなと思っています。サービスはサーバー側に移してサーズ化したりしてますし、ウェブのテスト、クライアントアプリのテストとかと結構似たようなのが多いかなと思っています。機能テストとか、ユーザビリティとか。
なるほど。じゃあ、そんな中でもあえて違うところ、相違点っていうとどういうところがありますかね。組み込み系ならではのというか。
そうですね。ハードウェアがマネージメントの中心になるところが結構違うかなと思います。ハードウェア開発、動かす環境ですね。ものすごく重いんで、それに合わせていく必要がありますね。
これってハードウェアが偉いというわけじゃなくて、本質的にハードウェアって作るのが大変なんですよ。金型作ったりとか言ってどん中でウォーターフォールベースで進めざるを得ないですよね。
それに合わせていく形ですね。基盤がウォーターフォールの中でいかにアジャイル的なソフトの開発を進めていくかとか、あるいはすごく入手が大変なハードウェア環境をいかにその制約を緩和していくか。
テストダブルとかを手配を計画に組み込んでいくかとか、そういったハードウェアの鈍重さに対応するところが結構大きな違いかなと思います。
なるほど。確かにそこら辺のテストダブル的な動きっていうのはあんまりウェブ系で、言ってもDBにアクセスしないでMockみたいな形でやるとかっていうのはあるにしても、
組み込み系ならではのテストダブルでそういうものができてない段階からうまくソフトウェアのところのテストをやるみたいなのは確かにあんまりウェブ系、組み込みじゃないとなかなかできないというか、そういうことに遭遇するのがなかなか少ないかなっていうような気はしました。
あと違いとしてはウェブとかですとDIコンテナとかいろいろテストダブルを作る手段が充実してるんですけど、組み込みはハードウェアが専用なんで結構内製化しないといけないことが多いですね。
既存のものを使って対応できるのに対して組み込みはテストダブルも内製化していくっていうのが結構違いかなと思います。
テストエンジニアの視点
なるほど。すごい自分にはない世界だなっていうふうに感じました。ありがとうございます。
はい。
ちなみに先ほどプロフィールの中で最初のところですね、開発者とかテストエンジニアとかコンサルタントなど様々な立場でソフトウェアテストに従事っていうお話があったんですけれども、
開発者としてっていうところとコンサルタントとしてっていうところとテストエンジニアとしてっていうところの立場の違いによってテストに対しての捉え方とかそういうのって変わったりするんですかね。
はい。立場によって全然違いますね。特に開発コンサルテストエンジニアは結構それぞれ違いが大きいかなと思います。
開発者ですと結構テスト用性、テストアビリティの実装とか手の内化できるじゃないですか。
なので自分たちで築いてガンガン進めることができるのは結構やりやすいんですけど、開発が炎上するとテストにリソースが割けなくなってしまうっていう問題が出てくるみたいな違いがありますね。
コンサルですとやっぱり日頃仕事して開発に熟知しているお客様のプラスアルファを出さないといけないんで、いかにその広い視点でプラスアルファを出せる課題を見つけ出してそれを改善するかっていう分析的アプローチがかなり求められる感じですね。
雑多な現場の業務で時間を消費するよりもいかにクリティカルな問題でそのお客様にプラスアルファを与えていくかっていうのが大事になってきます。
テストエンジニアの立場ですとやっぱり他にちょっと結構依頼をしながら、例えばテストアビリティを実装するにしても開発者に依頼をしながらという形ですので、ちょっと協力を得ながら一緒にプロジェクトをやっていくっていうような立場があります。
確論にいくともっといろいろ話が出るんですけど、大まかにはそんな違いがあるかなと思っています。
なるほど、ありがとうございます。
ちなみにイセリさん個人的にはその3つの立場の中で特に得意というか自分の好みだなって思うのはその3つだとどれに当たるんですか?
開発者ですね。やっぱり自分の力でガンガン回せていけますので、SETもできますし、開発者としてテストをやっていくのが今のところ一番良かったかなと感じています。
開発者として、今SETなのでソフトウェアエンジニアリングインテストですか。
はい。
このセットと呼ばれる部分であったりとか開発者っていうところでガンガンやっていく。
特にテストの考え方を使ってとかっていうと、例えばテストアビリティを中に組み込んでみたいな、そういう感じで開発をしていくみたいな、そういうイメージですかね。
はい。それもありますし、大まかにはシフトレフトですね。上流の成果物もレビューとか早期テストでちゃんと見て潰していくっていうのもありますし、早期からフィードバックサイクルを回していくっていうのもありますし、
大まかに言えばシフトレフトを推進しやすいっていう点で開発者が良いかなと思っています。
なるほどなるほど。ありがとうございます。
シフトレフトの考え方
今ちょっとイセリさんからシフトレフトっていう言葉が出てきたので、そのままシフトレフトの話を聞きたいなと思ったんですけれども、最初に紹介した通り雑誌ソフトウェアデザインの2024年の2月号で、
イセリさんがシフトレフトについての解説を書いていただいていて、そこの時に非常に自分自身も勉強になったんですけれども、
まずシフトレフトのテスト活動といった方がいいのかもしれないですけど、そういうところに関して、
イセリさんのあの記事の中だと、2つって言ってたっけな、
もともとのシフトレフトテスティングの考え方と、もともとの考え方ではないんだけれども、
シフトレフトなテスト活動的な話で、2種類あるみたいな、そういうような書きっぷりでしたっけ、
そうですね、DevOpsが言い始めたシフトレフトと、それより前の90年代ぐらいに言葉を作った人たちの言うことが一種類あるって感じでした。
ちなみに軽く今説明とかしてもらっても大丈夫ですかね。
90年代ごろに生まれたシフトレフトテストって呼んでたんですけど、
それは単純にテスト実行を後回しせずに、前からなるべく早く実行しようという考え方ですね。
当時ってウォーターフォールが主流だったんですけれども、終盤だけじゃなくて、
ユニットテストをしましょうとか、あるいは反復回数を入れて、なるべく早期からテストをしましょう。
後回しにテスト実行をすると、日の目に合うよっていうのが古典的なシフトレフトテストになります。
2つ目ですね、DevOpsが提唱しているシフトレフトはQAエンジニアリング、品質エンジニアリングのシフトレフトですね。
早期から品質確保とか品質補償をやっていきましょうと。
手段はテスト問わず、レビューとかモデリングとかケースチェックとかそういったものも含めて、
品質エンジニアリング資本を総動員しながらシフトレフトしましょうという感じですね。
古典的なものはテスト実行の前倒しで、現在主流のDevOpsとかが言っているシフトレフトはQAの前倒しという感じですね。
その古典的な方のシフトレフト、テスト実行の前倒しっていうのはイメージとして、
JSTQBとかでいうテストレベルをイメージした方がいい感じですかね。
例えば、システムテストレベルであったりとか、そういう話よりももっと前のコンポーネントテストレベルでのテスト実行をやろうよとか、そういった意味合いですかね。
古典的なシフトレフトテストは3種類挙げていまして、3種類の1つがそれですね。
テスト設計コンテストの実績
テストレベルで、ユニットテスト、結合テストに責務を回していきましょうっていうのが3種類のうちの1つになります。
残り2つってどういうものがあるんですかね。
残りはテストレベル関係なしにテスト一通りを早くから回しましょう。
具体的には反復開発とかインクリメンタル開発を導入しましょうっていうのが2つ目です。
反復で早期から反復することによって、ユニットテストとかシステムテストの一通りの活動を前倒ししていくっていうものです。
3つ目が実行可能な仕様を作って仕様テストをしましょう。
動的なモデルでモデル駆動テストをやりましょうっていうのが3つ目です。
なるほどなるほど、確かに。
そこの話でいうと、特に2つ目の反復の部分に関しては、
DevOpsのシフトレフトにも、
DevOpsとかAgileをやっているところでも結構言われてそうなシフトレフトのように聞こえたんですけど。
おっしゃる通りですね。
古典的なシフトレフトテストは今のシフトレフトに完全包含されていますね。
なので古典的なシフトレフトテストを推進すればDevOpsに役に立ちます。
ブロックロリーさんのコメントはまさにその通りで、反復開発とかすれば今のシフトレフトを推進できますね。
他がその微妙なのは、もうすでに90年代ですので普及しきっていて、
実践が広がっているからというので、テストレベルとかの話はあまり魅力的に映らなくなっているというのがあるかもしれません。
なるほど、なるほど。
聞いていると魅力的には映らないかもしれないけれども、
どれも技術として今でも使える、
学んでおくべきというか、ちゃんと考え方を捉えておくと良さそうだなというようには思いました。
おっしゃる通りですね。
なるほど。ありがとうございます。
ちなみに次に、普段の業務というよりはコミュニティ活動にも付随しての話になってくると思うんですけど、
テスト設計コンテストというものがありまして、
アスターですね。
アスターというNPO法人ですね。
ソフトウェアテスト技術振興協会のアスターが行っている活動の一つとして、
テスト設計コンテストというものがあります。
これは何かというと、
一つの同じテストベースに対して複数のチームがテスト設計を競っていく、
まさにコンテストを行うというものがあるんですけれども、
そこでイセリさんはアンダー30、30歳以下のクラスの審査委員とか、
以前は審査委員長もやられていたというところなんですけれども、
イセリさんの中で、さっきもシフトレフトとかの話があったと思うんですけど、
そこの中でもテスト設計という考え方は十分使えるかなと思うんですけれども、
シフトレフトとテスト設計の関係性というか、
そういうテスト設計をどう使っていくかみたいなところに関して、
何か考えとかってあったりしますかね。
すいません、ちょっと抽象的な質問になっちゃうんですけど。
難しい質問ですね。
ただ、テスト設計が重要なのは多分どのテストも同じなので、
DevOpsとか関係なしにしっかりやりましょうというのは自分の立場です。
そうですね。
テスト分析と設計の重要性
テスト設計をしっかりしないとできない必要性は高まっていると思っていて、
シフトレフトをするとDevOpsとか計測テクノロジーとか導入するじゃないですか。
そこで何をするかというと、自動テストはユニットテストとか開発者テストだけじゃなくて、
システムテスト、エンドポイントテストの自動化をして、
どんどんデプロメータパイプラインを組んでいくんですけれども、
そうなるとやっぱり自動テストのテストケースもしっかり設計しましょうという、
システムテストを自動化するならば、
本来システムテストでやっていたようなしっかりしたテスト分析、
設計をしっかり自動テストもやりましょうという必要性が高まっているかなと思います。
まとめるとシステムテスト、シフトレフトを推進するにあたって、
自動テストの範囲を広げれば広げるほど、
自動テストのしっかりしたテスト分析や設計が求められているかなというのは、
ちょっと潮流としてあるかなと思っています。
なるほど。ありがとうございます。
自分も実際によく見聞きするものとして、
自動テストをやっていきたいですと、
アジャイルな組織で開発に追随するために、
自動テストをやっていきたいという話が上がったときに、
なぜ自動テストをやりたいかというと、
手動で1回1回やっていくのに時間がかかるから、
みたいなところから入ってきたりすることが話として多いんですけど、
そうすると結局今まで手動でやってきたのをそのまま自動テストにするであったりとか、
とりあえずこういうテストしたいよねっていうのを、
何でもかんでも自動化するっていうふうにやってしまうと、
結局メンテナンスのコストであったりとか、
そもそもこれって何でテストしてたんだっけみたいなところが迷子になることがあると思っていて、
そういうところで先ほどイセリさんがおっしゃってたようなテスト分析であったりとか、
テスト設計っていうところがすごい重要になってくるのかな、
けどそのテスト設計の重要性っていうのは、
まだ自動テストやりたいですって言った人とか、
もうすでに自動テストやっている人たちのところにみんなにまだまだ浸透しきれてない概念、
テスト設計の考え方なのかなっていうような、
自分は勝手なそういう印象を持っているんですけど、
イセリさんから見て他の組織とか社外でもそうですけど、
テスト設計って自動テストでも重要なんだけど、
なかなか浸透してないなっていう感覚をお持ちなのか、
いやいや、結構浸透してきたよっていう感覚をお持ちなのかというとどっちですかね。
浸透してないことが多いかなと思います、広く見ていてですか。
一番結構多いのがユニットテストのりで、
エンドとエンドテストとか結合テストのテスト設計をやっちゃってて、
まずいテストケースになっているのが多いように思っています。
ユニットテストって結構すごい小さな断片をプログラミングの都合で作っていくじゃないですか、
アドホックに経験的に。
そののりでシステムテストとかの設計もしちゃってるっていうのが結構多いですね。
前者が個体かなというのは自分の印象です。
なるほど、なるほど。自分も同じような印象を持っています。
ちなみにそれでテスト設計をやっていこうっていうふうになったときに、
テスト設計コンテストの審査をされていたりとか、
あとは以前にどっかの講演でイセリさんがしゃべっていたと思うんですけど、
テスト設計をやるときにテスト設計技法をただ知識として知るだけではなくて、
その勘どころ、どのときにどのテスト設計を使うのかみたいな勘どころみたいなところが重要なんだよみたいなことを
イセリさんが発表していた覚えがあるんですけれども、
難しい質問かもしれないですけど、テスト設計の勘どころって何ですかね。
そうですね、やっぱりテスト分析しっかりしましょうっていうのが大事かなと思います。
技法は本当にテキストを覚えれば進む話なので、
それに前ですかね、テストのスコープ、テストどこまでやれば十分か、
テスト対象はどういう構成かっていうのをしっかりテスト分析していけば、
その次は結構流れといいますか、おのちとどういうテストが必要かが見えてきますので、
勘どころやっぱりテスト分析をしっかりやるっていうのが自分の考えです。
自分も近いような認識を持っていて、
自分の場合よく例として言うのが、テスト設計の技法って、
中学とかの数学の公式一つ一つとか、
中学の数学で学んでいるテキストの内容一つ一つだと思っていて、
ただそれが全部覚えましたと、公式とか全部覚えましたってなったからといって、
じゃあ高校受験の受験問題で必ず100点取れるかっていうとそうではないと思っていて、
それは何でかっていうと、高校受験の数学のテストで出てきたときに問題を見て、
じゃあこれって、例えば二次方程式のもので、
このとき因数分解ができない形だから、じゃあ解の公式を使おうっていう、
そういう思考過程があると思っていて、
それに近いところ、それがさっき伊勢さんがおっしゃったテスト分析の部分にも当たってくるのかなと思うんですけど、
ここの部分をテストしようって考えたときに、こういうことがテストとして必要だよね。
そこを明らかにしていく。
パターンとかを導き出すためにはこのテスト設計技法が必要だよねっていう、
テスト分析とその重要性
そういう一連の流れがあるかなって思って、
自分は結構そういう数学の受験の話とかを比喩として持ってきたりするんですけど、
伊勢さんがその勘どころの話をまだあんまり理解できてない人に、
こういうことだよみたいなのを伝えていくときってどういう工夫していますかね。
もう実際に例題与えて、それで頑張って経験してだんだん慣れていけみたいな話なのか、
伝え方で工夫してたりとかあったりするんですかね。
やっぱりやることを分解して具体的に定義するのが良いかなと思っています。
最初の一歩は、テスト分析ですとやっぱり責務ですかね。
テストの対象、スコープ、目的、充分性、
あとはその対応すべき重大な制約とか課題とか、
あとはリスクをどう分析するか、そういったものを提示して、
それぞれちょっと考えてみてねと。
それでちょっと全体のテスト構成を整理してみてねっていうのが出てます。
その後のイソロックメソッドですね。
やってみせて、やらせてみせて、
あ、すいません。
やってみせ、やらせてみせて、褒めてじゃなかった。
あれ何でしたっけ。ごめんなさい。
イソロックの名言ですよね。
あれは、やってみせ、言って聞かせて、褒めてみて。
その3パターンですね。やっていくのがいいかなっていうのを持ってます。
なるほど。そうすると、そうですね。
最初にもおっしゃってたように、数百人規模で標準化とかを考えていくと、
ある程度伝えるっていうところはやっぱりうまくやっていくところは大事かなと思うんですけど、
ちなみにそのテスト分析とか、
勘どころというかテスト分析からどのテスト設計を使ってっていう、
そこの分析のプロセスのところらへんの話って、
うまくその社内で標準化とかって持っていける感じなのか、
まだまだこれからな感じなのかどうなんですかね。
はい、すいません。ちょっと社内のことあまり詳しく話すのはお済みです。
言われてるんでちょっと詳しく話せないんですけれども、
伝えるのはある程度はできるかなと思っています。
アプローチはやっぱりモデリングですね。
そのテスト対象の仕様に対してどういうモデルが潜んでいるか、
その仕様の本質的なモデルは何かっていうのを考えていくと、
じゃあどの技法を使うかっていうのが見えてきますので、
その積目を分析したら、次はテストベースの仕様のモデルを考えていくっていうのをちょっとやっていく感じですね。
モデルもたくさんあるんじゃなくて、
もう結構ある程度パターンを絞れると思っていて、
その組み合わせだったり、同時パーティションだったり、
状態遷移だったり、テッションテーブルだったり、
技法をちゃんと勉強していけば浮かび上がるように本質的なモデルが見えてきますので、
技法を学ばせて、
テストベースにどういう本質的なモデルが潜んでいるかっていうのを見ていくっていうのが、
そのステップかなと思っています。
社内標準化の進め方
モデルが見えてきたら、モデルに合わせた技法を適用するっていうのを持っています。
なるほど。ありがとうございます。
実際、イセリさんの今までの社外での講演とか、
発している話を聞くと、
多分他のテストエンジニアとかが発表する人、
発表する内容以上に、今おっしゃってたような、
モデリングっていうのをすごい、
イセリさんの発表の中で強調しているなっていうような印象を受けているんですけど、
やっぱりモデリングっていうのは、
より大切にしている考えな感じですかね、イセリさんの中で。
はい。テスト設計はモデリング行為だと思っていて、
複雑なテスト対象を網羅可能なモデルに整理して、
それを網羅する。
例えば、ぐちゃぐちゃな日本語をテストテーブルにモデル化して、
テストテーブルを網羅するみたいな形で、
テスト設計のテスト技術を導出する、
その本質的な考え方の一つかなと思っています。
ので、モデリング大事かなとは思っています。
なるほど。ありがとうございます。
すごい、イセリさん、武士というか、
イセリさんの言葉、今まで自分がお声掛け、
今回する前から聞いていた、
イセリさんがよく発表で言っているような話を、
改めて聞けたような気がしました。ありがとうございます。
ありがとうございます。こちらこそ。
そうですね。あと、テスト設計の話と、
あとはさっきプロフィールの中で、
著作とか講演のところで自動化の話があったんですけれども、
さっきチラッと出てきてはいましたけれども、
やっぱり自動化をするって言ったときも、
そういうモデリングであったりとか、
テスト設計っていうのは大いに使っている感じですかね。
はい、普遍的な活動かなと思います。
違いとしては脳内でやるか、
ドキュメントで書くかっていうのはあると思います。
例えば、インテルテストですと、
いちいちドキュメント作ったりしないので、
脳内でモデルを考えて、
それをテストケースに落とし込むっていうのは知っていますし、
システムテストレベルですと、
テスト分析とか設計は設計書として残していって、
こういうモデルがあるからこういう方法を使いましょう、
っていうのがあったりとかしています。
そうですね、普遍的に実践している活動ですね。
影響力の拡大とその実践
なるほど、ありがとうございます。
はい、どういうことでしょうか。すみません。
結構もう30分近く話していただいて、
すごい自分自身も、
毎回このQ&Aはそうなんですけれども、
いろいろな業務の話であったりとか、
テストに関する根本的な考え方とかっていうのを
知れていいなと思っているんですけど、
今回も30分ちょっとで、
いろいろとイセリさんの考え方っていうのを
少し触れられたような気がして、
すごい個人的にはすごい満足しています。
ありがとうございます。
ありがとうございます。
ここまで私の方から結構いろいろ質問しちゃって、
もしかしたら答えにくいところとかも
あったかもしれないですけど、
ここで逆に、
イセリさんから自分にあてに質問とかあれば
お聞きしたいなと思ったんですけど、
質問とかってあったりします?
そうですね。
会話の内容のノリから考えられればと思うんですけど、
大きなものに影響力を発揮するって言ってなんですけど、
ブロッコリーさんの活動は結構、
最近特に強く感じるのは、
流れを作ろうとしているようなイメージがあって、
業界だったり組織だったりに、
大きな流れを作って、
より大きな影響力を発揮して、
テストをより良くしていこうというような動きを感じています。
そういうふうに、
自分の力の影響を広げて、
全体の流れを作っていくには、
どういったものがいいかなと、
ちょっと分かれればと思っていました。
なるほど。
大きな流れを自分が作っている自覚を
そこまで持っていなかったような気がするんですけど。
でも、レビューのシンポジウムだったりとか、
勉強会が発表されたりとか、
いろいろやられていると思うんですけれども。
なるほど。
まず、自分に関しては、
無自覚ですというのが一つある一方で、
ただ、意識もしているところはいくつかあって、
例えば今話として出ていた、
レビューのシンポジウムですね。
JustReviewの実行委員長、今自分知ってますけど、
あれは結局、レビューっていう行為が、
まだテストに比べて言語化できていないっていう風に、
自分はそこに課題感を持っていて、
何でかっていうと、
テストっていうのは、
それこそ一昔前とかだと、
みんなが単独経験でやっていて、
ベテランの人はよく分からないけど、
テストですごいいっぱいバグを見つけたりとか、
できるんだけれども、
ベテランじゃない新人とかはなかなか見つけられない。
けどそういうところが、
テスト設計を使ったりとか、
テスト分析を考えたりとか、
さっき伊勢さんがおっしゃってたような、
モデリングを使って、
うまくできるようにしていくっていう活動が、
できてきたと思っていて、
一方でレビューっていうのは、
まだまだ経験者だったら、
経験者がレビュアになったら、
見つけられるみたいな世界だと思っていて、
まだ言語化がうまくできてないなっていうところに、
課題感というかもどかしさを感じていて、
なのでじゃあそこをもう少しはっきりさせたいなっていうのが、
レビューのところに関してはありますと。
あと開発者に対してのテストの話で言うと、
単純にそこも普段の業務で、
開発者がもっとうまくやれるはずなのにっていうところがあって、
けれどもそれこそJUSTとかテストシンポジウムとか、
SKIP、品質シンポジウムとかっていうのは、
テストエンジニアとかQAエンジニア多く参加しているけれども、
開発者が必ずしも参加しているわけではないので、
じゃあそこは実際に開発の人が参加しているようなイベント、
カンファレンスで発表する価値があるなっていうふうに思ったし、
それで発表しに行ったら結構運営実行委員の方から、
そういう発表してくれる人を待っていたみたいなフィードバックをいただいていて、
なのでそういう発表をしていますと。
あともう一つ、自分がやっていることでよくあるのが、
今海外書籍のテスト関係の書籍の翻訳を結構しているんですけれども、
そこに関してもさっきのレビューと近い話で、
そういう文献っていうのが日本語の文献がすごい少ないと、
けど海外の文献だったらある程度あったりする。
ただそれと海外の文献要書を持ってきて、
自分が読むときってまだ英語のまま読めないので、
自分なりに翻訳をして、翻訳しながら理解しながら本を読んでいってるんですけど、
そうするとじゃあ一回翻訳したその内容って、
じゃあ同じその作業を他の日本語が母国語の人が、
同じ作業をまたやっていくのかっていうのが無駄に感じていて、
自分が一回翻訳したんだとしたら、それを有効活用して使ってほしいっていう風な考えを持っていて、
なので書籍を翻訳して出したりしてるっていうところがあります。
そこら辺が最初に言った疲労を得るっていう、
そこら辺はちょっと無自覚なところが多いっていうのはそういうところで、
自分の影響力をとかはあんま考えてなくてやり始めたっていうところですかね。
質問の答えになってるかわかんないですけど。
ありがとうございます。色々意識のあるお話で。
大丈夫です。ありがとうございます。
ありがとうございます。そんなところですかね。
ということでエンディングに行きたいと思います。
QAとテストの議論
本日はトヨタ自動車株式会社のイセリさんをお招きして、
QAとかテストについて語っていきました。
最後に宣伝についてなんですけれども、
イセリさんの方からは特に。
ないですね。年末に本を出そうという予定ですのですけど、
ちょっとまだ署名とかも決まってないですので、
他には特には大丈夫ですかね。
後、講演とか執筆とかやっていますので、
何かご依頼があれば、
えみどく話し投げていただけると嬉しいです。以上です。
ありがとうございます。
執筆、年末の執筆はすごい自分も興味あるなと思うんですけど、
それは詳しいのが出たら、
また自分はイセリさんのTwitterというか、
若手エンジニアの育成
Xのアカウントとか見て終えればなと思っています。
あと書籍に関してで言うと、
先ほどこのトークの中でも話をしましたが、
随分ちょっと前になってしまうんですけれども、
ソフトウェアデザインの2024年の2月号ですね。
今年の1月に発売された2024年2月号の中で、
自分とイセリさんがテスト設計ですね。
テスト設計の特集で書いていますので、
そちらも興味がある方は。
また物理本はなかなか書店とかには並んでないと思うんですけれども、
多分電子書籍とかまだまだ買えると思うので、
興味がある方は買っていただければなと思います。
イセリさんのところはシフトレフトの話が結構詳細に説明が書かれています。
あともう一つ自分の方からの宣伝としては、
コミュニティ活動の宣伝ですが、
以前もここの中で話したとは思うんですけれども、
若手ですね。
ソフトウェアテストに関する合宿型のワークショップ形式の勉強会の
若手の2024年冬の開催が決定しました。
12月14日、15日ですね。
1泊2日で開催する予定です。
ちなみにイセリさんも以前若手の実行委員ではあったんですけれども、
イセリさんからも若手についての説明じゃないですか、
印象とか思い出とかあれば聞いてもいいですかね。
そうですね。テストエンジニアとして伸びた原動力の一つが若手ですので、
テストについて力を伸ばしたい人はぜひという形で、
手を動かして議論もして仲間も作れて、
コミュニティにも入れてという形で、
明確にテストエンジニアとしてスキルアップできますので、
若手の参加していただけると嬉しいです。
OBとしても嬉しいですという感じですね。
ありがとうございます。
すごい最高の宣伝をいただきました。
ありがとうございます。
ということで、私が関わっているコミュニティとかの宣伝は以上なんですが、
それ以外にもまずTENXでは現在メンバーを募集しています。
このTENX FMを聞いてTENXに興味を持った
カジュアルに話を聞いてみたいと思われましたら、
番組概要欄にある採用情報、
もしくはTENXのホームページのリクルートからご応募をお待ちしております。
またTENX FMではリスナーさんからのお便りも募集しています。
エピソードの感想やTENXのメンバーに聞いてみたい質問など、
どんなことでも構いません。
今回の感想であれば、もちろん井芹さんにもお伝えしたいなと思っています。
こちらも番組概要欄にあるお便りフォームからの投稿、
またはXでハッシュタグTENX FMでツイートをお願いいたします。
最後にSpotify、Apple Podcastなどお聞きのPodcastアプリで
番組のフォローを忘れなく、最新エピソード配信時にお知らせが届いたり、
また過去エピソードの再生済み、未再生が一目で分かるようになり大変便利です。
ということで、本日のお相手はブロッコリーと
トヨタ自動車株式会社の井芹さんでした。
井芹さんありがとうございました。
ありがとうございました。
それではまた次回。
