「クロージングパネル:⼈⼯知能の未来~その未来をどうテストし、どうテストに活⽤するのか~」聴講レポート #JaSST19Tokyo #JaSST

目次

自己紹介

榊原彰(以下、榊原)

TariqKing(以下、Tariq)

  • Ultimate Software Senior Director

石川冬樹(以下、石川)

松原仁(以下、松原)

  • はこだて未来大学 副理事長
  • 人工知能学会 前会長

現在のチャレンジについて

  • 榊原

    • TariqがやっているAI-Driven-Testingが現状どこまで進んでいるのか、今やっているチャレンジングなことは何か?
  • Tariq

    • これまでのところ、自動テストの生成をやっていた。
      • テスト結果の確認をハイレベルまで行っている
      • 自律的で独立型のAIを行っている
      • 自動的にサイトを探索してモデリングすることができる
      • アプリケーション用のユーザーフローを生成するようにしている
        • 抽象的なテストから学ぶことで実現している
    • テクノロジーとしては、long short-term memoryを使っている
    • マニュアルでは順番通りに入力している、AIはユーザーフローを使うことでテスト手法を補完する
    • 結果の確認も成功している
    • 予測の問題が現時点でのチャレンジ
      • AIが完全に理解できていないから
      • 「そのシステムのゴールはこれ」というものを教えようとしている
  • 榊原

    • 石川先生の今行っていることとBigチャレンジを教えて欲しい
  • 石川

    • 機械学習もAIも使って自動運転を研究している
    • AIも10回に2回外す
    • 今まではバグがあるとしていた
      • では、テストって何か?バグって何か?
    • 機械学習ではルールを生成し、データから学ばせている。エンジニアは知らないものである。これをテストする。
      • この話は大違い。
    • テストオラクルは何が正しいのか、そもそも分からない。一意の基準がない。
    • 今までのやり方が通じない。
      • けど、AIブームでみんな作り始めちゃった。
    • 4割ぐらいは新しいやり方でやらないといけないぐらい難しいと回答している。
    • 「どうあるべきか」を問われていると思う

AIとドメインナレッジについて

  • 榊原

    • 自動化を助けるところにAIを用いているが、そこにドメインナレッジが入ってくる余地があるか
  • Tariq

    • アルティメットソフトウェアにおいても様々なドメインがある。
      • 例えば、税法通りかどうかは、どれだけそこに関わってきたかが重要。
      • 税額を計算するために、理解する必要があり、そこは人間に頼る必要がある
    • 色々なパラメータを考える必要がある。
    • また、人間の専門家であっても正しいことを確認するには人間同士で対話する必要がある。
      • エンジニアチームが開発するときに、お客様が本当に欲しいものを作るために対話することが多くなっている。
    • 専門家に質問している内容をAIが学習することで、できるのではと思っている。
    • そのためにはドメイン知識が必要になってくる
    • レーニングをシステムに教え、システムを人間が評価するように我々は行っている
      • これを実現するまでには時間がかかると思ってます。
  • 榊原

    • 例えば、ボナンザのように、人間の指し手をAIが学習することから、逆転してAIの指し手を人間が学ぶ、そんな世界が来るか?
  • 松原

    • あり得ると思う。
    • 今のディープラーニングでは身につけているので、それを形式化すれば、それを利用できることがあるはず。
    • ただし、それには時間がかかる
  • 榊原

    • 学び方を抽象化して学ぶようになれば良いということか。
  • 松原

    • 学習したAIのディープラーニングの数値を明示化できれば、学ぶようにできると思う。
    • コンピュータを学習する手法から、人間も学習できるようになる

品質の担保の仕方について

  • 榊原

    • ヒューリスティックになって、確率論的な近似解が当たり前の世界になったとき、品質はどうやって担保すればよいのか。品質の定義はどう考えるべきか
  • 石川

    • 正解のラインがしっかり決まっていれば、統計の知識があれば良い
    • 正解のラインがぼやけている場合、擬似的に正解を近似して、点数をつける手段を行う。
      • 人が良いと思うことをチェックするなど。
    • 作ってみるまでどれだけの精度が出るのか分からない。
    • データの中から規則性を見つける。
    • まずはアドホックに作ってみて、規模を広げて作ってみる。
    • 文化がぜんぜん違う。すべてが試行錯誤。研究に近い開発。
    • 今は本当に知見がない。
  • 榊原

    • AIで作るシステムをテストするのにAIを使うことが今後出てくると思うが、指針についてアドバイスをくれ、と言われたりするか
  • Tariq

    • これから先起こる一番大きな変化の1つは、今日行っているオフラインのバリデーションではできなくなるかもしれない。
    • AIはオラクルが膨大で、YesかNoか言えなくなるものになっている。
    • こういうAIのシステムは常に環境に適用しようとする。事前に基準を設けることができるが、本番稼働後に変化が起き続けるので、常にモニタリングして変化に追従する必要がある。
    • これまでのエンジニアリングの方法を再考する必要がある。
    • 学術的な問題だったものを、これまでのやりかたでできないと理解して、私が提供できるガイドは、
      • AIや機械学習のそれぞれの違いを理解すること
      • 適用型のシステムを理解すること
      • マシンラーニングの精度、誤り率は今使っているものと比較して評価すること
    • 私達自身がそういうガイドラインを作ってくる必要がある
  • 榊原

    • こういう推論だけでなく、本番環境でラーニングしていく例はあるのか
  • 石川

    • 大規模な例はまだないが、やってみている例は噂として聞いている
      • うまく言ってからじゃないと公開しないと思う。
    • 解が見つかるか分からないものを対象にしているのがAI。
    • 走りながら書き換えていっているのがAI。
    • それがシステムとして完成していて、それを方法論としてまでには言っていない

AIの学習過程の可視化について

  • 榊原

    • AI、特にディープラーニングでよく言われる問題で、複雑過ぎてブラックボックスで分からないということがある
    • 学習過程をどう可視化するか、というのはQAをやっている人にとって重要だと感じている。
    • この点についてのご意見を欲しい
  • 石川

    • 規則性を学んで、規則性に従って処理する
    • どういうルールなのかはいくつか例を出せるが、汎化して表現できていない
      • 「雪が写っている時の写真であれば、この動物は狼だ」という例は報告されている
    • こういう規則性は何かというのを説明できるのがexplaineble AI
      • 例えば、ローンとかの場合、いくらAIが導き出したとしても説明できないと信用できないですよね。
    • ただ、それって本当にいつでもいるのか?
      • 天気予報を見ていて、気圧線を使って説明しているが、あれって無かったら信用できなくなるんですかね?
      • お客さんが納得するって何なんでしょうね?
  • 松原

    • 将棋の解説は説明しているが、頭の中をそのまま解説しているわけではない。
    • 説明を聞く人のレベルに合わせて説明しないと意味がないので、再構築している。
      • 実験で羽生さんに独り言をしながら指してもらうことがある。
        • 聞き相手が素人かプロかによって変わってきた。
    • 説明とは何か、わかった気になるとは何か?
  • Tariq

    • 非常に哲学的な問題
      • 私の場合も、5歳の娘と奥さんと上司に対してでは説明の仕方が違う
    • データの総量と複雑さが問題だから。
    • 我々の能力に限界があり、我々の知識に限界があるから
    • AIに説明して欲しいと依頼しても、きっと理解できないでしょう。
    • 時には、人間以上に機械には高いレベルの説明を期待してしまう
      • 人間が「でもうまくいくんだよ」で納得する話も、機械が説明すると納得しないだろう。
    • 許容できる分野に対しては説明が必要なくなる

AIによるデータのバイアスの指摘について

  • 榊原

    • 説明に関してはそうだと思う
    • データのバイアスに関してはAIが使えるのでは。
    • システムで、顔写真をUpしようとしたら、「目を開けた写真をUpしろ」と言われた
    • 白人男性だったらうまくシステムが出来上がっていた。学習データが白人男性
    • 学習したデータの網羅性を示唆してくれることはできないのだろうか?
    • データの信頼性にフォーカスして話したい。
  • 石川

    • テストデータの信頼性を担保して、と依頼されるかもしれないが、相当難しい問題。
    • 東洋人の問題が起きた後に、東洋人の割合が正確かどうかを見るのは簡単だが、問題が起きる前にチェックできるようにするのは難しい。洗い出しが網羅的かをチェックするのは難しい。
    • 社会の中でどうだ?という話は難しい。
      • 自動運転で、「雪の日は?」「霧の日は?」ときりがない。
    • なので、やってみて出てきたら直すというアプローチをとっている
  • Tariq

    • レーニングの課題はご存知だと思う。
    • テストするときに組み合わせが多くなってきていると思う。
    • ペアワイズや同値分割など、様々なことを使おうとしている。
    • 例えば、ミューテーションテストのような分野がある。実際に使っているアプローチはAIのようなものにも応用できるのではないかと思っている。
    • 私はこれらの課題を解決する担い手だと思っている。
    • 皆さんも経験を共有することで貢献をすることができる

過学習について

  • 榊原

    • 事前にパネラーの皆さんに「過学習をシステマティックに解決できる方法があるか?」と聞いたところ、「難しいが気をつけるようにしている」という回答が来た
    • 信頼度成長曲線はノウハウとして溜まってきた
    • 体験したことからメソッドを作るというアプローチをQAでできると思うが、QA4AIではできるか?
  • 石川

    • 経験的に積み上がってきたノウハウが大事なのはそう。
    • 逆に突き詰めるとキリがない。
    • All Pairを崇めている人は多いと思うが、そういう人は「3種類以上はしょうがない」としたりしている。
    • 機械学習周りでは、曖昧なことが増えるので、特にそういうものに頼ることが多くなる
  • 松原

    • 最初、Deepラーニングは世界で200人ぐらいしか使えなくて、「Deepラーニングは黒魔術」と言われたことがある。
    • Deepラーニングは少しずつシステム化されてきた。
    • ただし、完全にはされていない、発展途上のもの。
  • Tariq

    • このフォーラムにおいては、過学習は適切な問題です。
    • 過学習はどういうものか。特定の答えをあまりに覚えさせるというもの。
    • 理解しようではなく、ただ単に覚えさせること。
    • 子供にストーリーを一言一句覚えさせることはできる。
    • でも、その物語について質問すると、理解できていないことがわかる。
    • 機械学習に対して過学習と言うと、まるで正答率がすごい良くなっているように見えるが、テストすると、一般化して理解しているかどうかがわかる。
    • ということは、どういう風にテストすれば一般化して理解しているか考える必要がある。

データの調達について

  • 榊原

    • データの調達とかも品質の保証範囲内に入ると思うが、それに対して研究のアプローチはあったりするか?
  • 石川

    • まずは現場単位でデータを集めないといけない
    • QAが後から確認するだけでは済まない。
    • 例えば、データをバージョン管理するということは今まで無かった。
    • アカデミックでは、足りなかったときにどういう訓練データを足すのか、は難しい。
    • 苦手なデータを教えてあげるというのは大切。
  • 榊原

    • データの来歴について。バージョン管理という話があったが、自分で集めたデータやちゃんとした業者が集めたデータは管理できるが、信頼性に書けるデータしか集まらない場合はどういうアプローチをすればよいか
  • 石川

    • それはまさに難しい部分。
    • 学び続けているものが対象だとさらに難しい。
    • データの自動収集はかなり難しい。常にチェックし続けないといけない。
    • 信頼があるところであろうが、全てチェックをかける、というようなノウハウや手法の確立が必要。
  • 榊原

    • IoTの分野でのオンラインバリデーションで、ウイルスなどによって、例えば農業の温度データが2度ずつ高かった、ということもあり得る。
    • セキュリティについても難しいと思うが、AIの分野ではどういうアプローチをしているか
  • 松原

    • AI分野の単独研究では難しい。セキュリティ分野と共同して研究する必要がある。
    • 一番気にしている分野として、自動運転がある。
    • AIとセキュリティは結びついて行っている。
    • ウォッチするプログラムをリアルタイムで動かしているが、最終的には人間の専門家が本当かチェックしている
    • チェックしているAIが乗っ取られたら…とかになるので。
  • 榊原

    • もっと強靭なシステムを作るためにAIを使ったりしていることがあるか?
  • Tariq

    • セキュリティに関して、私自身が担当はしていないが、セキュリティに対する取り組みは会社として続けている。
    • 現在はセキュリティエンジニアが存在して、会社・組織として何をするかというと、倫理的ハッカーに対処してもらっている。
    • 倫理的ハッカーには、知識を持ってもらわないといけない(敵のやりそうなことの理解、セキュリティの理解、システムの理解など…)
    • データが第一級市民だ、という認識が広がってきた
    • データに対して攻撃は仕掛けられる。なので、データセキュリティは今後伸びていく。
    • 投資していく必要がある
    • それを優先課題として取り上げなければ、すべてが無駄になってしまう

会場からの質問

  • 榊原
    • ここからは会場からの質問を受けたいと思う

質問1:QAはAIを育てる立場になるか?

  • 会場

    • ECOシステムを作れないのか?
    • QAがAIを育てる未来が来るのではないかと予想している。
    • データを入れてトレーニングしていると考えると、お客さんにフィードバックかけた内容をQAが投入する未来になるのではないかと考えている。
    • この考えについてどう思うか?
  • 石川

    • それはそのとおりだが、今までもそうではなかったのか?
    • 今までもQAがそうやっているようになる。
    • AIの話でいうと、ただ文句を言っていても難しい。
      • だめな例はいくらでも出てくる。
    • 育てる側に回らないといけなくなると思う。
      • 「あいつら、文句言ってるだけだぜ」となる。
  • Tariq

    • サイクルの話はそうだと思う。
    • Qualityを一番に考えている人にとって、私達はガイダンスを提供することが大事だと思っている。
    • 開発において無くてはならないことの一つだと思う。
    • システムのゴール、目的は何かを考えて、そういった問題を解決するために、どういうシステムが必要なのか考える必要がある
    • AIを使っているかマシーンラーニングを使っているか関係なく、顧客の要求を満たさなければいけない。
    • 一般的に、新しいことに恐れを抱くことがある。
      • QAのしごとがなくなるのではないか?と思ったりする。
    • けど実は我々のやり方が改善されるだけである。

質問2:学習データのシェアについての課題

  • 会場

    • AIの学習したデータをシェアすることについて。
    • 一企業が学習に使ったデータやシステムを公開するのはためらうことがある。
    • 共有することに対する課題はあるか
  • Tariq

    • コミュニティとして重要なのはナレッジを共有すること。
    • ただしデータを共有することに対して気を付けなければならない。セキュリティの問題とバイアスの問題がある。
    • そういった問題を解決してから出ないと、広範囲で共有することにはならない。
    • 同時にやらなければならないのは、ツールを開発しなければならない。確認ができるようにしないといけない。
    • データに関しては、個人的にはセキュリティが一番重要だと思う
  • 石川

    • 相当、品質に気を使わないといけない。
    • 運転の分野では、一般性の高いデータ
      • 衝突事故時などのデータはシェアが難しい
      • ただし、一般的な運転データはシェアできる。
    • また、AIの動きを外から見て、似たようなAIを作ってしまう問題が出ている。
    • 電子透かしみたいなものができないか考えている。
  • 松原

    • アメリカにはOpen AIの協会があったりする。
    • Deepラーニングがこれだけ普及したのは、一般公開したからではある。
    • そういう動きがあることはある

質問3:評価データの省略について

  • 会場

    • 訓練データの話があったと思うが、評価データについて聞きたい。
    • テストの人たちはデータを少なくしたいと思っている。
  • 石川

    • 小さい方が楽なのは確か。
    • ただし、Deepラーニングに同値クラスのような概念がない。
    • また、テストデータを用意しても無駄打ちしている可能性がある。
    • なので、いっぱい入れたくなる。
    • そこは難しいところである。
    • 効果的なテストについては、要求から決まるところも実装から決まることがあるので、自分たちが作ったものを理解して、テストを考えなくてはいけない。
    • また、なぜそのテストをするのかも考えていかないといけない。
    • 近似的に多様なデータを入れたりすることを考えたりする。

「テストの未来、品質の未来~⾃動化はテスター撲滅の夢を⾒るか?~」 聴講レポート #JaSST19Tokyo #JaSST

目次

発表スライド

speakerdeck.com

当日のツイートまとめ

togetter.com

自己紹介

今回は自己紹介と働いている組織の形を紹介してもらう

山口鉄平(以下、山口)

  • Yahoo! Japan
  • システム統括本部 技術支援本部(元)
  • 元々は組み込みのソフトウェア開発をしていた
  • Yahooは多種多様なサービスが色々な作り方をしている
  • Unitテストの導入だけでなく、E2EやAPIも行っていた
  • Yahooはプロダクト単位で行っており、その範囲でテストも行っている
  • それを我々の間接支援部門が支えている
  • QAというプロセスは存在しない

大園博昭(以下、大園)

  • LINE Fukuoka
  • UI Test Automationチーム
  • プロダクト単位で行っている。
  • テスト自動化チーム、SETチーム、QAチームが別にあり、それぞれのプロダクトチームに入っている

木住野奈夫人(以下、木住野)

  • LIFULL
  • 開発志向を持っていたがQAチームへ
  • 半年前にQAチームから分離される形でSETチームが誕生
  • 4,5名/チーム、週4回のリリース
  • リリースパッケージに対するE2Eのテストを実施
  • 不安になっている自動テストの相談に対して対応している

根本征(以下、根本)

  • メルカリ
  • 新卒からWebバックエンド→SETチーム→Automation and Engineeringチーム
  • E2EテストやCI/CDを実施
  • テストがメインではなく、開発者の生産性向上のための動きをしている
  • これまではQAチームと協業して自動化をしていたが、それだけでなくリリースを早めるためのE2Eテストの自動化を直接プロダクトチームに入って行っている

松尾和昭(以下、松尾)

  • HeadSpin
  • 今回はクックパッド在籍時代の話を中心に話す
  • UnitテストからE2Eテスト、プロセス改善を経験
  • クックパッドでは国内外の開発に携わっていた

  • 1つのプロダクトに対して、機能ごとにチームができていた

  • QA(QITチーム)は横断的に見る形で
  • テストの破綻を見越してテストチームを行っているのが特徴的(by 藤原さん)

モデレータ:藤原大(以下、藤原)

  • メルカリ

本セッションのコンセプト

  • 自動化を中心に、今後の未来について話す

    • 自動化の課題
    • どういう組織になっていくのか
  • ここで言うのはあくまで一例なので、ご自身の自動化推進に参考にしてほしい

テスト自動化への期待とその結果

期待

  • 素早いフィードバック
  • テストの効率化
  • コスト削減
  • すばやいデリバリ
  • バグの早期発見
  • 心の不安

結果

  • 素早いフィードバック
  • テストの効率化
  • すばやいデリバリ
  • バグの早期発見
  • 心の不安

なぜコスト削減が消えた?

  • 藤原

    • 期待と実際の結果を見比べると、コスト削減の期待が消えているのが特徴的に感じた。
    • ここについて実際の経験を元に話してもらいたい
  • 大園

    • 最初はすべて手動テストをしていた
      • QAチームが行っていた
    • 品質も担保したいし、コストを削減したいという目的で自動テストを実施した
      • 大失敗だった
    • 教訓を元に、「まずは品質を担保しよう」ということになった
    • あるサービスでは90%は担保している状態になった
    • テスト実施のコストは減ったが、自動テストスクリプトの作成コストが増えたので、結局は人的コストがトントン
  • 根本

    • 2年前にテスト自動化を立ち上げた
    • 始めた当時は目に見える効果が大事
      • コスト削減は見えやすい
    • ただ、メンテナンスコストや、自動スクリプトの作成スキルがあるエンジニアの採用活動コストなどを考えるとトントン

テスト自動化の課題とその対策

テストが失敗したわけではないが、別の要因(データ作成とか)でテストに失敗してしまう

  • 松尾

    • 時間帯によってネットワークの遅延で失敗したりする
    • モバイルアプリのテスト自動化に対しては、テストの実行基盤がどれだけ保全できるか、どれだけ安定しているかが特に大事
    • 現職では、安定した環境や実環境に近い環境でテストが成功するものを提供できるようにしようとしている
  • 山口

    • まず、このことがどうして課題かと言うと、安定しないと「テストをやらない」という判断をプロダクトがするようになってしまうから
    • そのような場合は、先にインフォメーションを与えて、回避することを先に行う
    • もちろん安定させていくことも同時に行っていく
    • そこじゃなくても自動テストのメリットを享受できる部分があるはず

自動化チームがいない、または立ち上げが難しい、人材がいない、または少ない

  • 大園

    • 立ち上げに難しいというのはあまり感じていない
    • むしろ拡大フェーズにおいて、なかなか採用が難しい
    • システムを作るに置いてエンジニア力が必要
    • エンジニアの採用と同じ感じ
  • 山口

    • 3000人いると、SETチームに頼るのは難しい
    • 各現場で書けるようになるのが大事
    • その人達ができるようになるにしていく
    • サービスに伝える、教える人を増やしていくようにする
  • 藤原

    • 作れる人のポイントは?
  • 山口

    • システムを作ることができる人
    • テストをなるべく無駄なく効果的にできるようになる人
    • 一夜でできる話ではないので、学び続けられる人

何を自動化の対象とするか?どのテストを自動化するか?のスコープや計画や準備がきちんとできていない

  • 木住野

    • 当時、常識が無かった
      • まずはテストカバレッジを増やすようにした
        • 1000ケースほど作ったが、何を守りたいのかが不明確なままだった
      • 当時、週2回のリリースを行っていたが、リリース前に自動化エンジニア4人が1日がかりでテスト結果を確認するようになっていた
    • テスト対象が明確になっていなかったので、テスト計画を作るようにした。
      • テスト対象を絞った
    • 手動テストと自動テストのカバーする範囲を明確化した
    • その中で、どういったテスト対象にするかは、以下のいずれかを満たすものにした
      • ビジネス上絶対に守らないといけないもの
        • 明確に定義した(Google Analyticsより)
          • ページビュー数
          • ページの価値
      • 過去に不具合が起きたもの
    • 現在は、テストエンジニア3人で長くて4時間、だいたい1時間で完了するようになった
  • 大薗

    • 何も考えずにどんどんスクリプトを作った
      • プロセスを抜かして、自動化した
        • 「すごいでしょ」と一人で思っているようになった
    • 失敗した数はかなり多い。それだけ何をやればよいか学んだ
  • 根本

    • テストケースの問題が多かった
      • 新しい機能のときに更新されていなかった
      • どういう意図でこれを作ったのか誰も分かっていなかった
    • テストケースを作り直すことになったので、さらに自動テストも直すようにした

手動のテストケースをそのまま自動化してしまってテスト効率が悪い

  • 藤原

    • 手動テストは手動のためのケースだと思っている
  • 松尾

    • アプリのUIのテストだと、いくつものシステムをまたいだ設定があったりする
      • 自動テストすると無駄が多く、非常にもったいない
    • 自動テストでは裏側の設定をスクリプトで行ったりできるはず
  • 木住野

    • いきなり自動テストケースから作り始めたが、困った
      • 自動テストを実行して失敗したときに、手動で実行することができない

テスターが自動化用テストケースをかけない

  • 藤原

    • 自動化エンジニアになっての苦労は?
  • 木住野

    • プログラミングスキルによる苦労は無かった
    • 逆に、テストスキルが元々なかったのですごい苦労した
    • 「ブラウザを自動的に動かすことが楽しい!」と自動化ハイになってしまった
  • 大園

    • 多分、苦労は無かった
    • テストに精通していたわけではない
    • ソフトウェアには明るかったので、実装に対しての苦労はあまりない

テスト自動化チームがマネジメント層やテスター、他の関係者から十分なサポートを貰えない

  • 根本

    • メルカリでは現在、それぞれの品質や生産性に責任を持っている人とは働きやすい状態になっている
    • 一方で、佳境の中でテスト自動化の大切さを伝えるのは難しい
      • 砂漠の中で「森は大事ですよ」と言っても、彼らが欲しいのは水なので伝わりづらい
  • 山口

    • Yahooの中において、明確に「これをやらなくてはいけない」という仕事の仕方をしていない
    • 実際にテストして困っている人のところに行く
      • その人が「自動テストいいな」と思えれば、その人のマネージャに伝わっていく
    • 個人的には「サポートをもらう」という形をしていない
    • 逆にトップダウンで入れたほうが良いときもあるので、その時の効果を示さないといけない
      • こっちから仕掛けていくことになる
  • 藤原

    • だいたい失敗する時は「カバレッジを正確に求めてくる」という人が現れた時だと思う

テスト自動化のための理想の体制とロール

質問1:自動化チームは必要か?

  • 必要
    • 大園
    • 根本
  • 不要
    • 山口
    • 木住野
    • 松尾
「必要」派
  • 根本
    • メルカリだと、技術の変化を非常に感じる
      • マイクロサービス化など
    • モノリシックであれば現場が書けるが、ついていってキャッチアップするのは、チームではなくとも人への投資が大切なのでは?
「不要」派
  • 木住野

    • 開発が行えるのが理想
    • 開発プロセスを理解している人がやれば良い
    • 実施できるスキルを持っている、投資できるのが大前提
  • 松尾

    • 「自動化チーム」という組織は不要
    • あるサービス開発チームにおいて、自動化のロールを持って動く人がいれば良い。
      • 自動化チームとして存在している必要がない
    • 全社の基盤を作るチームは必要だが…
    • 独立したチームが確固たる地位を持つ必要はない

質問2:QAエンジニアは必要か?

  • 必要
    • 大園
    • 根本
    • 松尾
  • 必要ない
    • 木住野
  • サービスによる
    • 山口
「必要ない」派
  • 木住野
    • 開発チームやPOが決める
    • どうテストに対して納得感を作るのかができれば、QAエンジニアは必要ない
    • ただし、そのための教育としてQAエンジニアは必要になってくるかも
「サービスによる」派
  • 山口
    • YahooのサービスにおいてはQAエンジニアが必要なサービスが特に無い
    • 開発チームが改善や品質について見れる状況にある
      • 修正してリリースできる範囲にある
    • 1回リリースしてからバグが起きたり、人が死ぬようなプロダクトでは必要だと思う

テスターは必要か?

  • 部分的に置き換わる
    • 山口
    • 根本
    • 木住野
    • 松尾
  • 完全に置き換わる
    • 大園
「完全に置き換わる」派
  • 大園
    • テスターが多様化してきている印象がある
      • 単にテスト実行するだけでなく、プランナー的に企画段階から入っていったり、UXの部分も入り込んだりしている
    • 自動化エンジニアがもてはやされている感がある
「部分的に置き換わる」派
  • 山口

    • 実行作業をするテスターは無くなっていくだろうし、なくしていきたい
    • 探索的に見つけてくれる人は残るだろうし、その人の価値は高い
  • 木住野

    • 「テスターの仕事=手動テストを実施する人」と考えていると不要になる
    • 技術的にトレンドを追い、開発に取り込んでいく人は価値がある
    • リーン開発においては探索的テストをまずテスターにやってもらって、自動化は後追いでやっていくことはありそう
  • 根本

    • リグレッションテストは置き換えていきたい
    • スクリプトを書くのと手で書くのがどっちが早いかわからない場合は、力を割いてもらいたい
      • 新機能の部分とか
  • 松尾

    • 「現地に行って人の生活をする」というようなテスト実施はすぐに置き換わらない
    • 人に対してのサービスを作る上では、切れない
    • 特定の国で、実際の地域の通信を使ってテストするようなものは自動化に置き換えられる
置き換わる条件について
  • 大園

    • 前提条件をいくつかつければ、完全に置き換われると思う
      • 開発体制などを見直すなど
    • まずは直近のサービスで、そういう環境を作ることをやろうとしている
  • 山口

    • 何を外の環境にするかによる
    • 外にすればするほど現場との距離ができる
    • 「なぜ開発の人たちができないのか」という阻害要因を取り除いていくのが役目
  • 木住野

    • すぐは達成できるか分からないが、それを目指してやっている
      • 誰でもメンテナンスできるように
      • どんな環境でもメンテナンスできるように

質問:Agile、DevOpsがあたりまえの時代に求められる人材とは?

  • 藤原
    • テストフェーズを作ると、その部分がボトルネックになりがちだと思っている
プログラマが出せない価値を出せる人
  • 山口

    • 皆さんが語っていたように、テスターが多様性しており、QAエンジニアが見る範囲が広がっている
    • ものづくりをするにおいて、プログラマがパフォーマンスを出せる領域がある
    • 一方で、領域を広げることはプログラマが苦手な部分
      • そういう領域で価値を出せる人が求められると思う
  • 藤原

    • プログラミングスキルはいる?
  • 山口

    • 何を作っているのか分からないレベルだと厳しい
    • 何が必要なんだっけ?と伝えられる人
誰もやったことないことに果敢にチャレンジする人
  • 大園
    • 今まで「めんどくさいな」と思っているところを、我々が拾い上げる。
    • Developerが開発に集中できるようにする環境を提供できるようにチャレンジできる人が求められている
技術スキルを持ち、継続的な改善を推進する人
  • 木住野
    • 技術スキルを持って、その中で最適な価値を選択する必要がある
    • 最初から正解を選ぶことは難しい
      • 低確率で最初に正解が出たとしても、時間の経過で最適解にならなくなることもある
越境する人
  • 根本
    • スクリプトを書くだけの人は、なくなっていくと思う
    • 一つの専門性を持ちながら、他の分野にも貢献を持つためにキャッチアップできることが大事
    • 技術力だけではない
学びを続けられる人
  • 松尾

    • 自分たちが活動しているチームで足りないものは何か
    • 自分たちはどういうふうに動けばよいか
    • これらを常に考え続けている人は生き残っている人が多い
  • 藤原

    • モバイル業界だとツールがどんどん出ているが、そういうのもキャッチアップすべき?
  • 松尾

    • 使ってみるのも大事だと思う
    • それだけでなく、例えば、機能を見るのは自動化しているが性能評価はモニタリングを手動で行っていたら、そこをどうすれば自動化できるのか?とかを考えている

まとめ

  • 自動化はテスター撲滅の夢を見るか?は実はテスターだけの話ではない

テスターの仕事は自動化によってどうなるか?

  • 全部ではなく部分的に置き換わる(92%)
  • 完全に置き換わる(8%)
  • 置き換わらない(0%)

「テスターの仕事は自動化によって置き換わらない」は0%だった。

  • テスターはメルカリにはいない
    • そこに価値を感じていないから
  • テストだけ極めるのは難しいと感じている
    • 極端に言うと、給料が上がらない

テストの未来、品質の未来

  • 超高速な環境によってテスト実行スピードも超高速になったら?Dockerでできるよ!
  • AIやMLの力で自然なシナリオを自動生成できるようになったら?それOSSでできるよ!
  • これらを提供できるテストサービスが登場したら?それたくさんあるよ!
  • テストピラミッドがひっくりかえり
  • 探索テストやテスト設計手法すら必要なくなり
  • テスター、QAエンジニア、テストエンジニアが必要なくなり
  • 完全自動で全ケース網羅すればよくなる

かもね?

会場からの質問

  • 現場への改善と新しい技術を試すバランスが難しいと感じているが、どういうふうに気を付けているor工夫があれば?

回答

  • 大園
    • 会社の風土として、完全に独立部隊を作ってもらった。コストも度外視で
    • 失敗を学びにして変えて欲しい
    • QA環境もある程度固まっている状態だった

関連記事

昨年のJaSST Tokyoでのテスト自動化セッション

nihonbuson.hatenadiary.jp

nihonbuson.hatenadiary.jp

パネルディスカッション「QAの過去から現在・現在から未来」(後編) #DeNA_QA_Night

前編はこちら

nihonbuson.hatenadiary.jp

目次

登壇者

奈良 隆正(以下、奈良さん)

西 康晴(以下、にしさん)

河野 哲也(以下、河野さん)

講演資料

www.slideshare.net

※p8以降

昔からあるツールで今でも使い物になりそうなものについて

f:id:nihonbuson:20190310002908p:plain
今回の講演資料8ページより

  • 河野さん

    • 奈良さんはなぜすべて○を?
  • 奈良さん

    • みんな口が悪いね?
    • どれも参考にはなると思う
      • ただし、具体的なプラクティスを教える人がいない
      • なので、本を読んでほしい
  • 河野さん

    • 基礎知識として知っておけということですね

品質管理手法

  • 河野さん

    • にしさんは◎/×という付け方になっていますが、どういう意味ですか?
  • にしさん

    • 何も考えずにランダムにつけたんですけど(笑)
    • 考え方は知っておいたほうが良いが、実際に使う機会に出くわさない
      • 大量生産をする、統計を使う場合のみ有効
        • 本当の統計を使ってないので機械学習で役に立たない
  • 河野さん

    • コンサルが来たときにだまされないようにするため○にした
  • 奈良さん

    • すごい納得

品質管理図

f:id:nihonbuson:20190307110514p:plain
奈良さんの講演資料24ページより

  • 河野さん

    • にしさんは×にしてますが、その理由は?
  • にしさん

    • いつ何がリリースされて、いつ何がテストされていて…みたいなのもわからない状況で使っても意味がないのでは?
  • 河野さん

    • 10日間とか、リリースごとで使うと良い
    • 3日間とかだと意味がない
  • にしさん

    • スプリントの性質による
    • 他のサービスと横並びして比較するのは意味がない
  • 奈良さん

    • Microsoftのツール(Microsoft Project)を使えば簡単に作れるのでは?
    • 会場の皆さんは、この絵を見て、瞬間的に見てテストがどこまでできているのか答えられるの?
  • 河野さん

    • 普段書いている人?少ないですね。
  • 奈良さん

    • テストが終わりそうかという質問にどこまで答えられるのか?
    • 明日デートいけないですよ?
  • にしさん

    • どんな場合でもデートできる状況を作るのが大切じゃないの?
  • 奈良さん

    • 説明できる状況ならどんな方法を使っても良いと思う

V&V

  • 河野さん

    • にしさんはV&Vが◎の理由は?
  • にしさん

    • これが仕事ですから
    • 「V&Vが大事なんです!」というだけの人は信用できない
    • 全体を考えてやっているならすごい大事
  • 河野さん

    • 実際の状況、具体論で考えられるのが大事
  • 奈良さん

    • レビューはなんでやるの?と言ったときに、V&Vの考え方が分からなければ上手くできない
    • 似たような考え方でV字モデルがあるが、開発でもちゃんと知るべき。
    • 開発者にとっておまけではなく、コードを書くのと同じように知るべき。
  • にしさん

    • 自動化できてるところ、自動化できてないところ、これからしたいところ、人間が考えるべきところをちゃんと区分けするため
    • そうしないとSETがTDDからCIで組み込んだあとに、SETが孤立するかQAが孤立する

探針と信頼度成長モデル

f:id:nihonbuson:20190307110635p:plain
奈良さんの講演資料27ページより

  • 河野さん

    • 探針と信頼度成長モデルは知っておいた方が良い?
  • 奈良さん

    • 今だと、こういう管理をしなくて良いのですか?
    • 私の場合は「テストがいつ終わるのか」を知るために使っていた
    • 組織の特性などによって適用する曲線は使い分けた
    • 最近のテストってこうなってるのかな?
  • 河野さん

    • なってないですね
  • 奈良さん

    • 期間が短いからできない感じ?
  • 河野さん

    • 期間が3ヶ月とかだと役立つかもしれないが、今だとブレブレになる
    • 探針もそう
    • 私が○にしている理由は、これもコンサルに騙されやすいものだから
    • にしさんは、信頼度成長曲線について言いたいことは?
  • にしさん

    • 信頼度成長曲線の言葉を少しでも言うぐらいなら今日の質問の投稿をするべき

LOC・FPベースの品質マネジメント

  • 奈良さん

    • ソフトウェアの目方をどうやって測るかで必要なのでは?
  • 河野さん

    • 計測してる組織が少ない
    • 開発者が嫌がるのでは
    • コード行数をマネジメントで使っている人?一部いますね
  • にしさん

    • 自分の書いたコードを行数で測るのはちょっと…
  • 奈良さん

    • 今そういうことをやるのではないのかもしれないが、必要だと思う
  • にしさん

    • 他のプロジェクトと比べたいんですよね?
  • 奈良さん

    • 上司から求められているから
  • にしさん

    • どんなテストするかによって出方は変わるはず
    • LOCとかではなく、「うん、うちらはちゃんとテストできてるね」とみんなで納得できるようにするほうが大事
  • 奈良さん

    • いや、上司との説得で使う必要がある
  • 河野さん

    • 他プロジェクトではなく、自分のプロジェクトの比較で使うことはあるか?
  • 奈良さん

    • この結果のみを使って信じるのは間違い
  • にしさん

    • 他に測る指標があるのでは?
      • Unitテストがあるかどうか
      • Unitテストはあるけどコードをなぞっているだけ
    • コードの規模ではないと思う
  • 奈良さん

    • 皆さんCMMをご存知ですよね?
  • 河野さん

    • いや、知らない人が多いですよ
  • 奈良さん

    • CMMIの中でも、未だに「必要だ。これがないと管理できない」と書いてある
  • 河野さん

    • なんか測ったほうが良いということですかね

メトリクス

  • 河野さん

    • メトリクスはどうですか?
  • にしさん

    • 「ISOをそのまま使えば良い」という捉え方だとまずいけど…
    • GQMにおける測り方のデザイン、把握のデザインは役に立つ
  • 河野さん

    • データに基づく議論が少ないと思う
    • もっと知ろうよ、という意味で○
    • やたらめったら取ろうよ、ではない
    • GQMはフレームワークとして美しいが、非常に難しい
  • にしさん

    • 開発者よりもっと頭を使わないと品質は良くならないよね
  • 河野さん

    • 大学の先生が言うと説得力がありそうですね
  • 奈良さん

    • 上司が取っているから○にした
    • 取っている理由が分かってない人が多い
      • だったら自分でメトリクスを取れば良いじゃない
      • その参考になるのがメトリクス
    • 作業でメトリクスを取っている仕事は辞めちゃえば良いのでは?
  • 河野さん

    • 日々の業務で、意味がない、ちゃんと考えたほうが良いと気付く機会が無いのでは
  • 奈良さん

    • みんな物理的根拠がない状態で働いている
    • 文句を言うなら自分で考えれば?
      • なんかにしさんの隣に座ると口が悪くなるな…

ソフトウェア工学

  • にしさん

  • 河野さん

    • QAの人が業務ですぐに使えるのか怪しいので◎ではなく○にした
  • 奈良さん

    • 私はソフトウェアを開発して飯を食っている
    • どんな仕事をしたら飯が食える?コードを書いたら?
    • コードを書く以外にいろいろある。
      • 見積もり、テストの管理などのその1つ
    • そういうことができない人がソフトウェア開発をしていると言ってほしくない
    • そのためには、ソフトウェア工学を勉強してほしい
  • 河野さん

    • やり始めると噛みごたえのある勉強にはなる
    • 進めるなら輪読でやればよいのでは
  • にしさん

    • 本当は大学でやるべきですよね
      • 自動車工学知らない人がつくった自動車
      • 航空工学知らない人がつくった飛行機
      • 機械学習知らない人がつくった自動運転
      • 乗りたくないよね?
    • だからソフトウェアを開発しているならソフトウェア工学を勉強しよう
  • 河野さん

    • 電通大で夜間に有料講義でやらないの?
  • にしさん

    • 夜働きたくないじゃん
    • トップエスイーという選択肢もある
    • あとは自社内で勉強するのが良い
  • 奈良さん

    • PSP(Personal Software Process)をやると良い
    • …なんか意見が合わないね

会場からの質問(1)

  • クソCHAPDコントロールな感じで仕事が面白くないのですが、ここから抜け出すために何を初めにするべきか。
  • またマネジメント層に「クソCHAPDコントロール」にはあまり意味がないことを分かってもらうためにはどういえばいいでしょうか。

  • にしさん

    • 「スキルを付けて会社を辞めろ」が正解です
    • 「会社に残ってここから抜け出す」は結構な難問
    • 自分の周りのチームで「自分のやり方まずいよね」と言って、こっそりやって、上の人には「ウォーターフォールやってます!」と言いつつおこなって、品質が良くなったら隣のチームに広げていくやり方が良い
  • 河野さん

    • 組織を変えるのは難しいですよね?
  • にしさん

    • QAは横断組織であることが多いので、一人の開発者が変えるよりは楽
    • 今どきのクラウドな会社の場合、創業者で技術理解のある経営陣がいる時は変えやすいはず
  • 河野さん

    • 社内政治をするということですよね?
    • ちなみに、こういう努力をすることで転職アピールにも繋がる
  • にしさん

    • なんか、辞めそうですよ?大丈夫?
  • 河野さん

    • 転職アピールは置いといたとしても、こういう話をできない(仲間を作っていけない)人は一緒に働けない
  • 奈良さん

    • こういうイベントを一人で来ても意味がない
      • 「来るんだったら3人でおいで」と言ったりしている
    • どうやって聞いた話を実現するの?
    • 複数で来て、裏で組んでこっそりやる
  • にしさん

    • 1人でしか来れない人は割り切って、自分の会社の中で帰ることとして割り切って、自分のチームで試してみて「見てみて!楽しいよ!」と伝える
      • 会社内でアピールし、社外にもアピールする
    • だんだん分かってきてくれる人がいる
    • 絶対「このクソ会社!」と思っている人がいる
      • その人を探すためにもやる
    • 「そんなことやっても意味ないよ」という人が実は理解者になる可能性のある人
      • その人の愚痴を聞いてみる
      • 愚痴をずっと聞いて、「そんなことばっかり言ってもしょうがないよね」という発言があったら、「こんなことをしようと思っているんですけど」と話す
    • 押し付けないこと、傾聴することが大事

会場からの質問(2)

  • 次の時代のQAが身につけるべきスキルとはなんですか?

  • 奈良さん

    • 質問を見た瞬間に頭をかかえた
  • にしさん

    • 個々で話しているQAはソフトウェアのQA
    • 実現しているのはサービス
    • じゃあ、「サービスの品質とは?」を考える
      • 自動運転の制度ではなく、自動運転が及ぼす影響とか
      • 高齢化、過疎化対策としてサービスを提供しようとしている会社もある
      • 自分のサービスは社会の解決をできているのか評価する必要がある
    • 身につけるべき範囲が広がっていっている
    • 開発者よりも先取りして学んで、もしも自分が適用するなら…を考え続ける必要がある
  • 奈良さん

    • 技術を磨くときに、世の中に通用する技術を磨いてほしい
      • 自分の会社だけで役立つ技術は、なんの意味もない
    • グローバルなり、スタンダードと比較して通用する技術を学ぶべき
  • にしさん

    • 外部のMeetupで話をするのも大事
  • 河野さん

    • 議論するのは大事ですよね
    • SSでも議論をするので興味がある人は来てください
    • 旅行するついでに参加してみてください

パネルディスカッション「QAの過去から現在・現在から未来」(前編) #DeNA_QA_Night

タイトルに「パネルディスカッション」と書いておきながら、実際のパネルディスカッションは後編になります。

後編はこちら

目次

イントロダクション(河野さんの発表)

発表資料

www.slideshare.net

※p7まで

今回のパネルディスカッションの狙い

  • 温故知新がイベントのテーマ
    • 前回の松尾谷さんの発表もテーマは同じ

背景

皆さんが困っていること
  • 品質保証をマネジメントする仕組みと仕掛け(大きな話)
  • ワークさせる固有の技術の理解・習得(小さな話)
    • 小さな話だけやれば良いのではなく、大きな話もする必要がある
  • チーム構築
    • チームの仕組み
    • 品質確保の仕組み
QAの仕組み・仕掛けや道具
  • テストのやり方、ドキュメント体系などを習得すればよいのでは?

過去の経験を活用する

  • 奈良さんの講演資料
  • 奈良さんの書籍
  • これらの内容をベースに話し合いを行う
  • そのまま使ってよいのか?
    • コンテキストが違う
  • どちらかというと過去の話がベースになっている
    • サービス要求
      • 昔…信頼性が何よりも重要
      • 今…スピードも大事
    • QAと開発の形
      • 昔…監査・分業の存在
      • 今…協業の形
    • テスト方法
    • 昔…スクリプトテスト
      • 今…探索的テスト

にしさんへの講演リクエス

  • 過去から現在について
  • 現在から未来について

オープニングスピーチ(にしさんの発表)

発表資料

www.slideshare.net

自己紹介

  • いろんなことやってます
    • テスト方面
    • AIプロダクト(ソフトもシステムもデバイスもサービスも含む)のQA

ソフトウェアTQM

  • 1980年代からソフトウェアの品質は行われていた
  • 汎用機の頃のソフトウェア開発ではうまく作用した
    • 日立などは自社で内製していたりした
    • ネオダマの頃になってどうも怪しくなってきた
  • 奈良さんは汎用機の頃にうまくやっていた一人

かなり昔(汎用機時代、アトランティス時代)

特徴
  • 正社員が内製もしくは子会社の人たちで開発していた
  • ほとんどが紙だった
  • 動作環境も自社製で揃えられた
  • エンジニア意識の強い人が集まった
どんな開発・QAだったか
  • マシンパワーが高価のため、人間がガンガン改善した
    • 結果が出てくるまで3日ぐらいかかる時代
    • 紙の上で考えざるを得ない
      • 奈良さん「古すぎる話をしてるよ!」
  • 改善するとみんなが儲かる嬉しい状態
  • 全体としての問題が分かっていた
  • 内製なので、組織能力を積極的に高めていた
    • 教育も積極的に行っていた
  • 人間らしい仕事をしていた
  • 奈良さんなどの人に頼っていた時代

ちょっと昔(プロジェクト時代、奴隷時代)

特徴
  • 多重下請け構造に基づいたプロジェクト制だった
  • コマンドアンドコントロールの徹底を目指していた
  • 電子化をしたが、Excel方眼紙なのでメリットがない
    • 規模は大きいが探せない状態
  • 制約によってなんとかできると思っていた
  • サラリーマンエンジニアが多かった
    • エンジニアが雇用の受け皿になっていた
      • コミュ障の大学生は「それならソフトハウスに行きなさい」と就職課の職員に言われる
  • わずか10年前ぐらいまでこういう状態だった
どんな開発・QAだったか
  • 不具合を直すのにもお金がもらえる
  • 人間を取り替えのきく機械のように扱っていた
  • ソフトウェアのQAについてWebで探すと、この時代のQAの方法がヒットすることが多い
    • 結果として、解決できると勘違いしてしまう恐れがある
  • オープンソースの検証を自分たちで力技でやってしまおう、という時代

現在(クラウド時代)

特徴
  • 内製化が進んできている
  • GAFAMのやり方を学ぼうとする企業が多い
  • ソフトウェアが好きな人を集めやすい
どんな開発・QAなのか
  • アトランティス時代と似ている
    • ただし、ちゃんと考えてできているかは分からない
  • 中身をちゃんと理解して納得して作れている?
  • カイゼンのサイクルを短くすることができている?
  • 「QAはリソースが足りないので対応できません」と言ってないですか?
  • 組織能力を高めることができている?
    • スキルの高い人が流動化しているので組織能力を貯めにくいという側面もある

我々はどこに向かえばよいのか?

ちょっと昔(プロジェクト時代)と同じQAをすると概ね失敗する
  • クソCHAPDコントロールによる形骸化
    • Criteria-based control (基準値に従え!)
    • Human resource-based control (人力でなんとかしろ!)
    • Authorization-based control (誰の責任だ!)
    • Process-based control (マニュアル化しろ!)
    • Document-based control (文書!文書!文書!)
アトランティス時代と同じQAをしても的外れ・時代遅れになるだけ
  • 豊富なマシンパワー
  • 安価でリッチな開発・運用環境
昔ながらの良い考え方は取り入れる
  • 現在の状態に合わせて進化させる

自分たちで進化させよう

優れた組織イニシアティブの創出や醸成
  • 経営トップから品質を考えていける組織にする
    • 以下のような発言を経営陣がしていませんか?
      • 早く作れ!
      • リリースはいつだー!
      • 利益がー!
  • 納得感を共感して進めていく
  • 質の高いアウトプットを出すことを正義にしていく
  • QA部門は全員で品質を高める仕組み・文化を進めるように働きかける
    • SETと違う意味で、みんなで品質を上げていく
  • 品質はバグがなくなるだけでなく、人間らしい仕事にしていくことも大事
品質保証戦略を作る
  • 品質保証のアーキテクチャを作る
  • ありありと改善が分かる部分から行っていく
    • QAは主語がでかくしがち
QMSを構築する
  • 品質を上げることを嬉しくなる、評価されるQMSを作る
    • 「QMS?ISO9000でしょ?」という人は無視しよう
  • QMSによって開発の在り方そのものを進化させていく

よくやりがちなワナに気をつける

  • ラクティスファーストを行わない
  • 品質保証戦略のコピペをしない
    • Agileだから〜
    • 他社でやっていたから〜
  • 局所的で循環しない施策はデザインしない
    • クオリティーゲートを言っている人は奴隷時代の人
  • 深く考えずに協力会社に丸投げをしない

まとめ

  • 品質保証は組織を賢くするために行う仕事
  • ある意味経営と同じようなことを考える必要がある

後編(パネルディスカッション編)はこちら

nihonbuson.hatenadiary.jp

テストエンジニアはどのような思考でペアプロ・モブプロに参加しているのか #WACATE

はじめに

この記事は、モブプログラミングアドベントカレンダーの24日目の記事です。

前日も私がモブプログラミングをやっている人にレビューについて語ってもらった話 #JaSSTReviewというタイトルで書きました。

今回は、WACATEというイベントでのモブプログラミングの体験談と、モブプロ実施時の私の思考をお伝えします。

同じ題材、同じ時の開発者目線の思考は、かりあどさんが既に記事にしています。

kariaduu.hatenablog.com

目次

前段1:WACATEとは

公式ページはこちらです。

wacate.jp

公式ページによるとWACATEとは、

Workshop for Accelerating CApable Testing Engineers:内に秘めた可能性を持つテストエンジニアたちを加速させるためのワークショップ

だそうです。*1

今回のWACATEで学んだものについては、別記事を書いているので、そちらを参考にしてください。

nihonbuson.hatenadiary.jp

前段2:テストエンジニアがモブプロをやってみると…

私は以前にも、ペアプロ・モブプロを様々なところで試しています。

nihonbuson.hatenadiary.jp

nihonbuson.hatenadiary.jp

また、実際の業務でも試していますが、それはまた別の機会にブログに書きます。

モブプロ体験会@WACATE を開催

WACATEでは「夜の分科会」という、WACATE参加者の一部が自由にテーマを持ち寄って、他のWACATE参加者が興味のあるテーマに参加するというセッションがあります。

そこで今回私は、以下のようなモブプログラミング体験会を開催しました。

f:id:nihonbuson:20181223182907j:plain
モブプログラミング体験会風景(参加者のツイートより

  • お題…自動販売
  • 使用した言語など…CucumberとJavaを使ってATDDで作成*2
  • 役割…
    • 私…PO兼モブプロ・TDDの講師役
    • WACATE参加者…モブプロのドライバーもしくはナビゲーター
  • 人数構成…今回の参加者の内訳は以下です。
    • 普段の業務でも開発者でTDD経験済…1名
    • 普段の業務でも開発者だがTDD未経験…1名
    • 普段の業務ではテストエンジニアでTDDも未経験…8名

テストシナリオが出来上がっていく過程

分科会の中で出来上がったテストシナリオを、その過程を含めて紹介します。なお、実装コードは今回記載しません。

シナリオその1:100円の入金を確認する

まず、私は雛形として以下のシナリオを用意しました。

  Scenario: 入金額確認
    Given 自動販売機がある
    When 100円を入金
    Then 100円が入金されている

このシナリオが動くように、実際にテストコードを書き、実装コードを書きました。

シナリオその2:入金が2つあっても対応できるようにする。

PO(私)は、次のように伝えました。

「お金を100円入れた後に、50円を入れたら、ちゃんと150円になるようにしてほしいな」

その結果、テストシナリオは以下のようになりました。

  Scenario: 入金額確認
    Given 自動販売機がある
    When 100円を入金
    Then 100円が入金されている

  Scenario: 入金額確認
    Given 自動販売機がある
    When 100円を入金
    And 50円を入金
    Then 150円が入金されている

最初にあったテストシナリオをコピペして、「And 50円を入金」を追加しただけです。POの話を忠実に再現してくれていますね。

その後、このテストシナリオが通るように実装コードを修正しました。コードのリファクタリングも数箇所行いました。

シナリオその3:使いたくないお金はカウントしないようにする

続いて、PO(私)は次のように伝えました。

「1円硬貨は対応したくないです。」*3

その結果、テストシナリオは以下のようになりました。

  Scenario: 入金額確認
    Given 自動販売機がある
    When 100円を入金
    Then 100円が入金されている

  Scenario: 入金額確認
    Given 自動販売機がある
    When 100円を入金
    And 50円を入金
    Then 150円が入金されている

  Scenario: 入金額確認
    Given 自動販売機がある
    When 1円を入金
    Then 0円が入金されている

最初にあったテストシナリオをさらにコピペして、1円を入金した場合に「入金状態が0円になっている=1円には対応しない」という状態を追加しただけです。

その後、このテストシナリオが通るように実装コードを修正しました。コードのリファクタリングもさらに数箇所行いました。

ここまでで、モブプログラミング体験会の時間(30分間)が無くなってしまったので、終了にしました。

モブプログラミング体験会延長戦:テストエンジニアはどの部分が気になり、どのように指摘するのか

モブプログラミング体験会は、上述のように終了となりましたが、その後に延長戦を行いました。

そこでは、テストエンジニアの思考と発言が話題になりました。

テストエンジニアは指摘事項を言い切るべきか

延長戦では以下のような話が出てきました。

開発者はテストのことが分かってない部分が多いので、テストエンジニアにはもっと言い切りの形で言ってほしい

私は上記の話には半分賛成、半分反対です。

確かに、テストエンジニアはテストの知見が多いので、その頼りに応えるために発言するのは重要です。その一方で、コードを書く主体は開発者だとも思っています。なので、提案はしつつも開発者に最終的な判断を任せることが多いです。

話す内容に強弱をつける

昨日のJaSST Reviewの記事でも、以下のように書いたのですが、モブプロやレビュー時に私からは「指摘」ということはあまりせず、「質問による深掘り」を多く行います。

そもそも「指摘する」ということはあまりなく、質問をすることで深掘りしていくことが多い

モブプログラミングをやっている人(及部さん)にレビューを語ってもらった話 #JaSSTReview - ブロッコリーのブログ

その時に重要視しているのは、優先度をつけて言う・言わないではなく、発言時に強弱をつけて伝えるようにしています。*4

例えば、今回の題材となるテストシナリオ(以下)では、次のような会話をしました。*5

題材

  Scenario: 入金額確認
    Given 自動販売機がある
    When 100円を入金
    Then 100円が入金されている

  Scenario: 入金額確認
    Given 自動販売機がある
    When 100円を入金
    And 50円を入金
    Then 150円が入金されている

  Scenario: 入金額確認
    Given 自動販売機がある
    When 1円を入金
    Then 0円が入金されている

会話内容

  • 私「このシナリオって、すべてシナリオ名が『入金額確認』になってますよね。同じ名前はどうかと思うので変えたほうが良い気がしてます。(★1)」
  • 開発者「なるほど。そしたらこんな感じですかね。(テストシナリオを編集する)」
  Scenario: 1回のコイン投入
    Given 自動販売機がある
    When 100円を入金
    Then 100円が入金されている

  Scenario: 2回のコイン投入
    Given 自動販売機がある
    When 100円を入金
    And 50円を入金
    Then 150円が入金されている

  Scenario: 使いたくないコイン投入
    Given 自動販売機がある
    When 1円を入金
    Then 0円が入金されている
  • 私「なるほど。ちなみに、2つ目のテストの意図ってなんですかね?(★2)」
  • 開発者「これは、コインを1回だけではなく、2回投入した時にもちゃんと動くか確認したいという意図です。」
  • 私「なるほどー。そしたら、『2回のコイン投入』と書いていますが、3回目はどうなるのでしょうか?(★3)」
  • 開発者「3回目は2回目と同じく、加算されていく仕組みなので、ロジック上は大丈夫です。」
  • 私「ということは、気にしているのは2回のコイン投入ではなく、複数回のコイン投入なんですね。(テストシナリオを編集する)」
  Scenario: 1回のコイン投入
    Given 自動販売機がある
    When 100円を入金
    Then 100円が入金されている

  Scenario: 複数回のコイン投入
    Given 自動販売機がある
    When 100円を入金
    And 50円を入金
    Then 150円が入金されている

  Scenario: 使いたくないコイン投入
    Given 自動販売機がある
    When 1円を入金
    Then 0円が入金されている

会話における発言の意図

…いかがでしたでしょうか。

この会話は、★1、★2、★3で私の発言の強弱が変わっています。

★1「同じ名前はどうかと思うので変えたほうが良い」

この発言は、完全に指摘に近い提案になっています。これは誰が見ても直したほうが良いと思うからです。

★2「2つ目のテストの意図ってなんですかね?」

この発言は、開発者に思考を委ねています。

これは、自分が考えているテストの意図とは違った場合に私の提案は見当違いになることが多く、その時点で提案しても意味がないと判断しているからです。

あくまでも開発者自身にテストの意図を考えてもらうことが大切です。

★3「『2回のコイン投入』と書いていますが、3回目はどうなるのでしょうか?」

この発言は、私の考え「2回目も3回目も同じ仕組みなのでは?」も含んだ上での質問になっています。

「コインを1回だけではなく、2回投入した時にもちゃんと動くか」という開発者が発言したテストの意図は、以下の2通りのテストの意図に分けられます。

  • コイン投入が1回だけでない(複数回投入した)場合
  • コイン投入を2回(特定の回数)の場合

そして、私は「コイン投入が1回だけでない(複数回投入した)場合」というテストの意図の方が、今回のテストシナリオで考えているものだと感じました。

なので、確認の意味も含めて「『2回のコイン投入』と書いていますが、3回目はどうなるのでしょうか?」という発言をしました。

最終的に、テストシナリオ名をより良いものにできたと実感しています。

おわりに

今回は、モブプロ・ペアプロを行う時に、テストエンジニアである私はどのように考えているかという話をしました。

冒頭に紹介したかりあどさんの記事にも以下のように書いている通り、テストエンジニアはもっと開発コードに近い形で入ることも重要かと感じています。

そうした中で同じチームにテストエンジニアに入ってもらい、一緒に働くことで早い段階からテストエンジニアの観点を持って開発することができます。

テストエンジニアの観点を持ってテスト書いていくぞな話 - かりあどぷらねっと

今回はその一端を見せることができた気がしました。

おまけ

今回は開発コードに対してどのようにテストエンジニアが入り、協業して開発するかという話でした。

一方で、テスト設計、テスト実行に対して開発者が入る方法として、モブテストがあります。

それについては、ちょうど昨日、マンガも踏まえて紹介している記事がアップされたので、リンクを紹介しておきます。

testerchan.hatenadiary.com

おまけ(その2)

2019年3月14日に本記事をもとにした発表を行いました!

speakerdeck.com

*1:私は未だに覚えられません

*2:なぜCucumberを選んだかというと、シナリオの部分がプログラミングに慣れていないテストエンジニアにも抵抗が少なく入れるのではないか?という予測と、最近自分がやっていて楽しかったことが理由です。

*3:なにげに、シナリオその2でのPOの言葉よりも曖昧な表現にしています

*4:これは元々無意識でしたが、レビューやモブプロを考えた時に、そうしているなと感じたことです

*5:モブプロ体験会時はPO役だったので何も口出しをしていませんでしたが、延長戦はPO役は取り払ってフリートークしていたので、内容の指摘に入っています

モブプログラミングをやっている人(及部さん)にレビューを語ってもらった話 #JaSSTReview

はじめに

この記事は、モブプログラミングアドベントカレンダーの23日目の記事です。

前日は martin_lover_se さんの モブプロが大好きなので熱い想いを言語化する です。

今回は、JaSST Reviewというイベントに、モブプログラミングの人(及部さん)を招待して、レビューについて語ってもらった話を書きます。

目次

JaSST Reviewとは

JaSST Reviewについての説明の前に、JaSSTの説明から。

JaSSTとはテストを題材に扱っているシンポジウム*1です。公式ページはこちら

2003年から毎年全国各地で開催しています。

f:id:nihonbuson:20181222084053p:plain
出典:JaSST Reviewオープニングより

そんなテストのシンポジウムでなぜレビューを取り扱うのか。それは、レビューとは静的テスト技法の一つだからです。*2

なぜJaSST Reviewにモブプログラミングの話をしてもらうのか

一見すると、モブプログラミングはレビューと無縁の存在のように見えます。

そんな中、本シンポジウムのプログラム構成を考えた私が、今回及部さんに発表を依頼したのは2つの理由があります。

理由1:レビューの内容と共通点があるのではないか

及部さんが以前から発表で伝えていた通り、レビューというプロセスは存在しません。

しかし、一般的にレビューのMTGで話す内容とモブプログラミング中に話す内容に共通する部分があるのではないかと考えました。

この考えは、今年の6月にあったJaSST’18 Kansaiで私が発表した頃から思い続けていた考えです。当時の資料にもその考えが載っています。

f:id:nihonbuson:20181221185103p:plain
出典:「超」やさしいレビュー ~開発とQAに壁はない!~(JaSST Kansai)より

理由2:純粋に指摘についての話が聞けるのではないか

一般的にレビューの発表というと、以下のような議論になりがちです。

  • 適切なレビュー MTGの参加者構成について
  • 適切なレビュードキュメントの読み方について
  • 適切なレビュー MTGを行うタイミングについて

一方で、私自身興味があるのは、レビュー時にどのような指摘をしているのかという点です。

なので、レビューMTGが存在せず、レビューMTGの形式について議論する余地がない、モブプログラミングでの場合を聞くことにしました。

以上の理由で、モブプログラミングを積極的に行なっている及部さんに講演を依頼しました。

講演を聞いた感想

私からの依頼を受けて、及部さんは素晴らしい発表をしていただきました。

内容については、発表スライドと及部さんのブログをご覧ください。

speakerdeck.com

takaking22.com

実は、私は講演を聞いて「狙い通りだった部分」「狙いとは(いい意味で)違った部分」の両方がありました。

狙い通りだった部分

忖度が発生するという話は、レビューで起きがちな問題で、それをモブプログラミングと比較することで明示してもらえたのは非常にありがたかったです。

f:id:nihonbuson:20181221184319p:plain
出典:「レビュー再定義」p48より

また、講演後のパネルディスカッションの時には、さらにレビューの指摘についての話が色々と聞けました。*3

  • リスクに気付くのは経験によるところが多いので、属人化は仕方ないものではないか。暗黙知暗黙知のまま伝えれば良いのではないか
  • 人にフォーカスしてレビューする。発言者の自信がなさそうな部分を見つけて深掘りしてみる
  • 時間軸を意識して気になる点を伝える。現時点では良くても将来気になる点があったり。
  • そもそも「指摘する」ということはあまりなく、質問をすることで深掘りしていくことが多い

狙いとは(いい意味で)違った部分

「レビューの必要性を感じてきた」という話は講演を依頼した私自身、非常に驚きでした。

f:id:nihonbuson:20181221184533p:plain
出典:「レビュー再定義」p58より

モブプロやレビューを行う意味を、3つの観点に分けた以下の図は大変新鮮でした。

f:id:nihonbuson:20181223143510p:plain
出典:「レビュー再定義」p59より

また、「あなたの言うレビューは本当にRe(再び)View(見る)なのか」という問いは、ハッとさせられました。

f:id:nihonbuson:20181221184628p:plain
出典:「レビュー再定義」p64より

この話は、モブプログラミング(モブワーク)という、レビュープロセスが元々存在しないからこそ見出せたものかなと思います。

おわりに

今回はJaSST Reviewというレビューについてのシンポジウムで、敢えてモブプログラミングの経験を伝えてもらいました。それによってレビューについてもう一度考えてみました。

JaSST Reviewに参加してモブプログラミングに興味を持った皆さん、登壇していただいた及部さんに本当に感謝します。*4

そして、皆さんがこれからも(レビューというプロセスがあるなしに関わらず)指摘・相談・質問する行為の時に活かせる内容になっていれば幸いです。

おまけ

このイベントの次の日に、モブプロの体験会を実施しました。

その時にテストエンジニアがどのような思考をしていたかについても別記事に書きました。そちらもどうぞ。

nihonbuson.hatenadiary.jp

*1:JaSST=Japan Symposium on Software Testing

*2:JSTQB シラバス参照

*3:一部、及部さんが話した内容ではないかもしれませんが、及部さんを含めた登壇者全員が同意した内容を含みます

*4:参加者の中で、ブログなどを書いてくださった方も出てきて、実行委員としては嬉しい限りです。

fortegp05.hatenablog.com

kdnakt.hatenablog.com

qiita.com

note.mu

panmania.hatenadiary.com

ma-garin.hatenablog.jp

www.aster.or.jp

モブプログラミングにおける交代のタイミング

はじめに

この記事は謎の集団 Zenelo Advent Calendarの19日目の記事です。

前日は atom4lightning さんの Webフロントエンドにおける品質の可視化と向上を目指して(エラー監視編) でした。

モブプログラミングをしていく中で、様々な交代のタイミングを経験したので、今回はそれを紹介していきます。

目次

方法1:7分1分制

7分で強制的に終了し、次の1分間で「ドライバーをやってみた感想」「次のドライバーに引き継ぐ内容」などを伝える方法

オススメの現場

  • モブプロの体験をとりあえずしてみたい
  • ドライバーになることにまだ若干の抵抗感がある

実際に行なっていた場所

メリット

  • 1分のインターバルがあるため、そこで考えを整理できる。
    • 実況しながら手を動かす、というドライバーの役目に慣れていない人に有効

デメリット

  • 1分間のインターバルにナビゲーターが甘えてしまい、7分間のモブプロ時間内に集中しないことがある

方法2:7分制(10分制なども同様)

7分で強制的に終了し、次のドライバーにすぐ交代する方法

オススメの現場

  • 参加者全員がモブプロへの意欲がある現場
  • 時間内でドライバーを全員に経験させたい現場

実際に行なっていた場所

メリット

  • モブプロの本質である、みんなで取り組む姿勢が出る
    • さらに集中させる方法として、ドライバーが1名、ナビゲーターが1名、オブザーバーがその他全員というやり方もある。
      • ドライバー…キーボード操作をする人。ナビゲーターの指示なしで勝手にキーボード操作をしてはいけない
      • ナビゲーター…操作を指示する人。
        • この方法で行うと、ドライバー以上にナビゲーターの緊張感が高まる。なぜなら、唯一のナビゲーター全ての指示をすることになるので。
      • オブザーバー…ナビゲーターが助けを求めた時のみアドバイスをする人。ナビゲーターの代わりに指示をしてはいけない。
        • この場合、オブザーバーは基本的に「観察すること」が主業務になる。もしも観察をきちんとしていないと、ナビゲーターになった瞬間に「何をすればいいんだっけ?」となり、ナビゲーターを務められなくなるので。

デメリット

  • 中途半端な状態での交代になる可能性がある*1

方法3:1Step制

サイクルの1Stepごとに交代する方法。例えば、TDDにおけるRed -> Green -> Refactoring のそれぞれで交代したり。

オススメの現場

  • 区切りの良いタイミングまで1人で行いたい現場
  • TDDなどのサイクルを意識させたい現場

実際に行なっていた場所

メリット

  • 区切りの良いタイミングでの交代なので、次に何を行うのか分かりやすい

デメリット

  • サイクルの1Stepが長い場合、なかなか交代にならないことがある
    • 一番よくありえるのは、TDDでなかなかRedからGreenにならないパターン*2
  • 次にドライバーになるタイミングが1サイクルよりも大きい場合、そのサイクルが集中できない可能性がある
    • 例えば、TDDのサイクルでやっていた場合、次のドライバーになるタイミングが4人目以降だった場合、Red -> Green -> Refactoringの1サイクルでドライバーになれるのは3人だけのため、今回のサイクル内は集中しない可能性がある*3

方法4:我が家方式

コントトリオ「我が家」のように、代わりたいタイミングで「代われ!」と宣言し、ドライバーに自分からなる方法。

オススメの現場

  • どのメンバーもモブプログラミングに対して理解があり、かつ意欲的な現場
  • ドライバーになることもナビゲーターになることも嫌だと感じていない現場

実際に行なっていた場所

メリット

  • 時間やサイクルに縛られず、自分達が考える区切りの良いタイミングで交代できる

デメリット

  • 発言力やスキルに差がありすぎると、ドライバーになる時間の差が大きくなり、そのスキルの差を埋めにくくなる可能性がある*4

おわりに

今回は、今まで経験したモブプログラミングを交代のタイミングに着目して分類分けしてみました。

おそらく、これが正解!というものはなく、チームの成熟度によって変わっていくと思います。

もしもモブプログラミングがうまくいっていないチームがあれば、交代のタイミングについて見直してみるのもいかがでしょうか。

アドベントカレンダーは次の日の yuinchirn さんの 受け入れテスト駆動開発(ATDD)で簡単なiOSアプリを作ってみたにお繋ぎします!

*1:その交代がデメリットと感じている場合は、まだモブワークになりきれていない証拠かもしれないが

*2:逆に、それを利用することで、「交代してないということはRedが長くなっているから、一旦リバートしようよ」といった、改善に繋がる話ができる可能性あり

*3:そんな人はいないと信じたいが…

*4:ドライバーがきちんと実況しつつ操作できればスキルの伝達はできるかもしれない