WACATE2019夏を通して感じたこと
はじめに
どうも、お疲れ様です。
WACATEのあと休みを取らなかったことでずっとテスト尽くしの12日間を終えて土曜日にたどり着きましたhalspringです。
WACATE2019夏に参加してきました(WACATEについての説明は省略します)。
この記事では自分がWACATEに参加して"感じたこと"を中心に書こうと思います。 ですので、今回のWACATEの内容については他の参加レポートやtogetterをご参照ください。
パッとしらべて出てきた参加レポートはこちら
感じることというのはその人の周囲の環境や経験、体調や気持ちによって大きく異なります。 ですので、記事に価値のある情報はほとんどないかもしれません。
興味のある方のみおもしろ半分で読んでいただければと思います。
目次
説明ができる
WACATEは2018冬が初参加で、今回が2回目です。 夏と冬でワークの時間も雰囲気も異なる影響もあるとは思いますが、冬のときよりも積極的に発言や説明を出来るようになっていた気がします。 ソフトスキルが向上した と言いたいところですが、班のほとんどが初参加者で若干頼られる存在になっていたことと、そのことを感じてある種の責任感があったのだと思います。
また、普段はチーム内でテストについてわざわざ説明を行う機会はあまりありません。組織によってはクライアントに説明をすることがあるかもしれませんが、例えば「テストレベルとは」のようことを話したりする機会は少ないと思います。( テストジョークのようなことを雑談で話したりはしますが )
普段 説明したり話すことの少ないことについても、（正しくない可能性は否定できませんが）自分なりに説明をすることができることに気が付き、1年前 やっと新卒研修を終えたばかりだった自分から成長できていることを感じられました。 ソフトウェアテストは 開発のように目に見えるアウトプットを作りにくく、成長の実感をすることも難しいと思います。 WACATEのワークショップは なにが説明できて何が説明できないのか 何を曖昧なまま使っているのか、その辺りをスッキリさせる良い機会なのかもしれません。
経験の共有
WACATE2019夏のひとつの目玉である（と勝手に思っている）テスト計画、 参加者の何人がこれまでに作ったことがあったのでしょう。 別に作ったことがあるから偉いとか、やったことがないからどうとか、そんなナンセンスなことを言うつもりはありません。
過去にテスト計画がテーマの勉強会でも「テスト計画を作ったことがある人」の質問に対して手が上がったのは半分に満たないくらいでした（手をあげるのが好きではない人もいるとは思いますが）。 テーマにテスト計画を掲げている勉強会でその割合であれば、テストプロセス全体をテーマとし若手を中心（新卒や業界1年目2年目の方も多かったです）としたWACATEでは より少ないだろうと思います。
ひとつ前で述べた責任感の話もあり、運良くテスト計画を経験したことのあるだけの自分は おこがましくはありますが、他の参加者になるべく多く自分の持っている知見を共有しなければと感じました。
全てがそうだとは思いませんが、経験できる/できないには運が大きく関わっていると思います。 しかし、経験を出来ずとも経験者から知識を得ることはできます。 当然、実際の経験から得られるものに比べれば不確かで、偏っていて、不足している情報かもしれません。 それでも自分の経験を出来るだけなぞれるように、聞いた人が咀嚼して飲み込めるように意識して伝える責任があると感じました。
経験を積めないことについては本人が悪いわけではありません。 （意図的に避けて経験を「積まない」場合は別ですが。）
自ら飛び込んでいけばいいと言う意見もあるでしょうが、飛び込んで行くにはそれ相応のリスクも必要です。 ただ本を読むだとかそのレベルなら良いですが、転職するだとか職種を変える必要が出てくると様々なものと別れる必要が出てきます。飛び込んだ先で叶うとも限りません。 自分が経験を積むために何かを捨てる必要があるとき、その決断を迷わず出来る自信は正直ありません。
ですから、運良く経験出来る立場になったら 経験出来ないけれど「せめて知識だけでも」と情報を必要としている人達に向けて共有しなければいけない、 そうしなければ、業界全体は良くならないように思いました。なにもせず良くなるとしても、したほうが格段に速いはずです。
土日にお金払って遠出してまでテストを勉強している我々です。 古臭い文化、目的のないテストが行われるような現場、QAエンジニア・テストエンジニアの価値向上、発展のために出来ることがあります。 今すぐは難しいかもしれませんが、加速していきましょう。大層なことを言ってしまったので自分も頑張ります。
リードするということ
テスト計画の経験から、計画を立てる際に班をリードして進める役に他薦して頂きました。 自分がテスト計画を立てるときに、どう考え、どんな流れで進めているのかを説明し、ひとつひとつの自分の判断に対してなるべく理由も話すようにしました。
「こんな理由から こんな感じに進めようと思うのですが、どうでしょうか？何かご意見ありますか？」と尋ね、合意を得ながら進めていったものの、「そういうものなのか」と丸呑みをさせてしまったのではないかと少し不安になっています。
ワークを進める上でなるべく全員に共通の理解を納得感を持てるように自分の意見を言う前に「ここはどう思いますか？」と先に話を振るなどもしてみました。
結果として班のメンバーから意見が出て、「こうした方が良いのではないか」「ここのリスクは◯◯なので優先度をスコープから外してもよいのではないか」と議論検討することもでき、充実したワークを楽しむことが出来ました。 しかし、全体への問い掛けでなく、もっと個人に振ればよかったのではないかと後悔もしています。 ファシリテートって難しいです。
班の方にはありがたいことに評価して頂けましたが、今後 同じような役割を担うときにもっと上手くできるように意識したいです。
リスク分析
自分はテストアプローチを考える時にまずはリスクを出してくのですが、全体のリアクションを見ていて「あまりリスク分析ってされていないのでは...？」と感じました。
意識せずにリスクを気にしている、ということは当然あると思います。無意識にリスク分析を行ってテストを設計することはもちろん不可能ではありませんが、無意識で行なっていては考慮していないもの（例えば機能）が出てきてしまうのではないかと思いました。
全体の成果物の発表を聴いていて、ほとんどの班が「リスクの大きい部分を中心にテストしました」と発表していました。 時間の都合もあって詳細までは聴くことができませんでしたが、テストする機能/しない機能の決定にロジックがあったのかなかったのか、あるならどう決定したのか、ひとつひとつの機能や複合的にどんなリスクがあるか検討していたのだろうかと気になりました。 （どんなアプローチを取っていたのか気になるので、差し支え無ければtwitterか何かでお教え頂けると嬉しいです！）
他の班としみじみアプローチや見つけた不具合について話し合う時間を取れれば良かったのですが、疲れと 人に話しかけるスキルの低さが露呈してしまいました。無念。
経験？ロジカル？閃き？
今回のワーク中、システムテストで主機能を確認、受け入れテストで全機能をシナリオベースで確認するアプローチを取りました。パフォーマンステストやクロスブラウザテストは今回のテスト計画からは外す方向で進んでいました。
ところが、班の人が使っている端末がwindows 4人とmac 2人であったため「システムテストをwin、受け入れテストをmacで実施すればある程度のクロスブラウザの担保はできるのでは？」と判断して、その方針で進むことになりました。
このようなアプローチのアイデア、これは経験から来るのでしょうか？それともロジカルに導いているのでしょうか？あるいは咄嗟の閃きなのでしょうか？
初めは閃きorロジカルから来るもので、徐々に脳にキャッシュされ経験から出せるものになるのでしょうか？ だとすると、キャッシュが古くなり過ぎないように工夫しないとなぁと感じました。
前回も思いましたが、WACATEでtwitterアカウントを開設する方や、放置していたアカウントを掘り出す方、多いですよね。 今回は時間的制約の強いワーク中心であったため、あまり活発ではなかったのかなぁとは思いますが、勉強会やイベントでは大体 誰かが 議事録的なメモ、実況、疑問、感想をつぶやいています。 WACATEに関して言えば、ハッシュタグのない裏側で有識者達がTLの内容を見てつぶやいたりもしています。
この辺りの情報も拾いながら参加すると より視野が広がったり造詣が深まったりします。 疑問をつぶやくと講演者や有識者が答えてくれたり、誤ってメモしていたり理解していることは指摘してくれたり周りを見て気が付けたりします。
界隈の方には（よほどのことがなければ）とても温かく見守って貰えますし、自分はなかなかの人見知りですが twitterから認知して頂いて話しかけてくださる人が増えたり、登壇させて頂く機会を頂けたりと良いこと尽くしです。 リアルのコミュニケーションが苦手な方はテスト用のアカウントを作るもよし、ROM専でもよしなので、情報源は増やしておくことをオススメします。
QAの需要
感覚値ですが、開発やその他職種からテストエンジニア/QAにジョブチェンジしている人が多かった気がします。 テストの重要性が少しずつ理解されるようになって来ているように思えます。
ただ、QAの求人もよく見かけるようになってやはり「必要になったものの、今まで抱えていなかったからどうすればいいのかわからない」という面が見えます。
QA人材のおおまかな獲得方法は、
- 中途で雇う
- 新卒から育てる
- ジョブチェンジさせる
の3つだと思います。 中途で雇う選択肢は、評価できる/見極めることができる人が社内におらず 採用が難しいのかなと思います。 また、必然的にQAチームの立ち上げからになるので、チーム立ち上げ型転職芸人のような熟練者は別として、応募側にとってもハードルが高くなってしまうのかなぁと感じます。
新卒から育てる選択肢も同じような理由で難しく思います。わかる人がいないということは、育てられる人がいないのです。
そうなると残る選択肢はジョブチェンジです。 元々開発をしていれば、自社のドメインには詳しいですし、テストもまぁできる、開発をより良くするにはどうすればいいのか考えることもできます。 おそらくそういった背景の下、ジョブチェンジでQAになられた方が増えているのかなと思いました。
そしてその流れが進んでいけば 開発の知識やマーケティングの知識など、品質保証プラスアルファの知識を持つ方が増えてくるのだろうなと思います。 もちろんその流れがなくともそうなのですが、QAやテスト以外の技術や知識、観点も身に付けて自身の価値を創造して磨いていく必要を強く感じました。
最終的に目指したいところは自分の価値の最大化ではなく関わる方に与える価値の最大化なので、得たものは現場やコミュニティ、業界に還元できるよう頑張ります。
おわりに
色々と生意気なことを書いてしまっていると思います。大変畏れ多いです。
夏と冬でこんなに違うのかと驚きました。 WACATEはどんな参加者にも何かを与えてくれるので本当にすごいコンテンツですね。 実行委員の方々にはとても感謝しています。 そして次回も楽しみにしております。ありがとうございました。
