よろしくお願いいたします。
まず、今の仕事のところ、現職の話を聞きたいなと思うんですけれども、
現職だとデジタルコックピット開発のテストチームのテックリードということなんですけれども、
まずこのプロダクトというか、この開発って具体的にどういうことをされているんですか。
はい、コックピットシステムは車の操作に関わるシステム全般でして、主にナビとメーターのシステムがテスト対象になります。
それに対してテックリードとしてテストやQAをうまくやっていくというのが主な立場になっています。
なるほど、なるほど。
ちなみに、テストチームのテックリードっていったときのテストチームって、もし答えられればいいんですけれども、
だいたいどれぐらいの人数規模で行っていたりするんですか。
はい、そうですね。テストチーム自体は数百人ぐらいいますし、
あと立場としてはプロジェクト全体のテスト、会社のテストも含めてすべてのテックリードを担当しています。
すごい、数百人っていうのがなかなか自分は経験したことがない規模なんですけど、
数百人でのチームのテストのテックリードってなると、その人数規模だからこそ難しさみたいなところってあったりするんですかね。
はい、やはりそうですね。個々の成果物を見ていくと間に合わないので、やっぱりレバレッジをかけていく必要があります。
プロセスや戦略を立てて全体に展開したりとか、あとはレビューするにしても結構レバレッジポイントを見極めて、
そこをレビューするみたいな形で、いかに自分の少ないリソースの影響力を広げていくかっていうのが大事になってきます。
なんかすごい、確かに自分のリソースは一人で限られているからこそ、そこを効率的に使うってすごい聞いてて大変そうっていう風な感想を持っちゃったんですけど、
実際やってみて大変だなとかっていう風に感じたりすることってあったりします?
大変ですね。改善するにしても、例えばスクラムチームも数十チームありますので、展開するにしても各チームとのミーティングすり合わせだけでもかなり時間が取られてしまっているのがあります。
規模がでかいとやっぱり失敗のコストが高いので、なるべく精度高く仕事をしないと結構うまくいかないことが多いです。それがやっぱり大変なところです。
なるほどなるほど。そうすると、例えば標準化であったりとか、チームによって俗人的にばらけづらいようにする。
ちゃんとすごいできる人はどんどん進めてもらえればいいんですけど、やっぱりその人数とかになると、底上げをするっていうような活動がいろいろあるのかなと思ったんですけど、
そういう標準化とかっていうのもやられてたりするんですか?
そうですね。5割はそこですね。やっぱり標準化、プロセス整備、戦略立て、プロジェクトマイルストーンの整備とか、そういった底上げのものは重要な仕事ですね。5割ぐらいです。
5割は結構クリティカルな課題があるじゃないですか。本当にこれ成功させないと失敗するような技術導入とか、そういったクリティカルな課題の対応を個別にやっていくっていう、全体の底上げと本当に難しいピンポイントの技術支援の両方をやっていくという形です。
なるほど。すごい。じゃあ続いて、人数規模を踏まえたところのお話を今していただいたんですけども、次にドメイン的な話で、組込み系になると思うんですけれども、やっていることが。
自分がやっぱり組込みっていう経験がないので、そうなったときに組込み系とそれ以外、特に自分とかだとウェブ系とかなんですけれども、そういう組込み系とそれ以外でテストをやるにあたっての共通点とか相違点ってあったりするのかなと思っていて、まず共通して大事だなと思うところってどういうところがあったりするんですかね。
正直言うとバラバラなんですよね、プロダクトによって。例えば、カーナビとかのシステムだと普通にLinux上に動くPCソフトと変わらないので、クライアントアプリと同じようなアプローチを取りますし、機械制御ですとリアルタイムOSでかなりハードウェアと共存したテストをすることもあって、結構プロダクトによってバラバラな感じですね。
今のシステムですと割と変わらないかなと思っています。サービスはサーバー側に移してサーズ化したりしてますし、ウェブのテスト、クライアントアプリのテストとかと結構似たようなのが多いかなと思っています。機能テストとか、ユーザビリティとか。
なるほど。じゃあ、そんな中でもあえて違うところ、相違点っていうとどういうところがありますかね。組み込み系ならではのというか。
そうですね。ハードウェアがマネージメントの中心になるところが結構違うかなと思います。ハードウェア開発、動かす環境ですね。ものすごく重いんで、それに合わせていく必要がありますね。
これってハードウェアが偉いというわけじゃなくて、本質的にハードウェアって作るのが大変なんですよ。金型作ったりとか言ってどん中でウォーターフォールベースで進めざるを得ないですよね。
それに合わせていく形ですね。基盤がウォーターフォールの中でいかにアジャイル的なソフトの開発を進めていくかとか、あるいはすごく入手が大変なハードウェア環境をいかにその制約を緩和していくか。
テストダブルとかを手配を計画に組み込んでいくかとか、そういったハードウェアの鈍重さに対応するところが結構大きな違いかなと思います。
なるほど。確かにそこら辺のテストダブル的な動きっていうのはあんまりウェブ系で、言ってもDBにアクセスしないでMockみたいな形でやるとかっていうのはあるにしても、
組み込み系ならではのテストダブルでそういうものができてない段階からうまくソフトウェアのところのテストをやるみたいなのは確かにあんまりウェブ系、組み込みじゃないとなかなかできないというか、そういうことに遭遇するのがなかなか少ないかなっていうような気はしました。
あと違いとしてはウェブとかですとDIコンテナとかいろいろテストダブルを作る手段が充実してるんですけど、組み込みはハードウェアが専用なんで結構内製化しないといけないことが多いですね。
既存のものを使って対応できるのに対して組み込みはテストダブルも内製化していくっていうのが結構違いかなと思います。
今ちょっとイセリさんからシフトレフトっていう言葉が出てきたので、そのままシフトレフトの話を聞きたいなと思ったんですけれども、最初に紹介した通り雑誌ソフトウェアデザインの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エンジニア多く参加しているけれども、
開発者が必ずしも参加しているわけではないので、
じゃあそこは実際に開発の人が参加しているようなイベント、
カンファレンスで発表する価値があるなっていうふうに思ったし、
それで発表しに行ったら結構運営実行委員の方から、
そういう発表してくれる人を待っていたみたいなフィードバックをいただいていて、
なのでそういう発表をしていますと。
あともう一つ、自分がやっていることでよくあるのが、
今海外書籍のテスト関係の書籍の翻訳を結構しているんですけれども、
そこに関してもさっきのレビューと近い話で、
そういう文献っていうのが日本語の文献がすごい少ないと、
けど海外の文献だったらある程度あったりする。
ただそれと海外の文献要書を持ってきて、
自分が読むときってまだ英語のまま読めないので、
自分なりに翻訳をして、翻訳しながら理解しながら本を読んでいってるんですけど、
そうするとじゃあ一回翻訳したその内容って、
じゃあ同じその作業を他の日本語が母国語の人が、
同じ作業をまたやっていくのかっていうのが無駄に感じていて、
自分が一回翻訳したんだとしたら、それを有効活用して使ってほしいっていう風な考えを持っていて、
なので書籍を翻訳して出したりしてるっていうところがあります。
そこら辺が最初に言った疲労を得るっていう、
そこら辺はちょっと無自覚なところが多いっていうのはそういうところで、
自分の影響力をとかはあんま考えてなくてやり始めたっていうところですかね。
質問の答えになってるかわかんないですけど。
ありがとうございます。色々意識のあるお話で。
大丈夫です。ありがとうございます。
ありがとうございます。そんなところですかね。
ということでエンディングに行きたいと思います。