入社して半年で3回も勉強会講師を担当したのでドヤる
はじめに
これはウイングアーク１ｓｔ Agile and DevOps Transformation Stories のAdvent Calendar 2023、2023年12月7日の投稿です。
SET/SREの斎藤です。本当はSETとしての働きをドヤりたかったのですが、細かい調査系タスクが多くてちょっと地味だな～と困っていました。そこで自分がやってきたことを改めて振り返ると、勉強会の講師を頑張ったなーということに気付いたので、今日はそれをドヤりたいと思います。
タイトル通り3回やったんですけど、ライトニングトークでもライトなトークでもない、全て1時間枠(かつ2回目はめっちゃ伸びて質疑応答合わせ1.5時間！)のガッツリ講義形式でした。今日はそれらの内容を紹介しながら今年1年を振り返りたいと思います。
第1回目
初回は、入社して1ヶ月経った7/6に行いました。タイトルは、『 テストコードを読もう ～QAと開発の棲み分け～ 』です。この回はどちらかというと知見共有というよりも、配属されたPJやSPQI部の状況を見た上で、自分がどんな働きをしていきたいか意見表明を述べるという側面が強い勉強会となりました。内容としては、前半は昨年7月に行われたオンラインイベント『 リーダブルなテストコードについて考えよう 』にて得た知見について紹介し(イベント当日の観客の声は こちらのtogetter にまとまってます)、後半は自分が考える理想的なQAと開発の協力体制について語りました。
前半のリーダブルなテストコードについては、特に伊藤さんとブロッコリーさんの講演内容を重点に知見共有しました。テストコードってどう書いたら読みやすく(=保守しやすく)なるのか、テストケースをどう表現したら理解しやすいのか、これらの話はSPQI部内でもかなり評判が高かったです。
そして後半では、「QAもユニットテストのテストコードを読めるようになろう！そしてテストコードをレビューしよう！」ということを話しました。その中で「テストコードが読めないのは、テストコードの品質が低いから！(だから恐れずテストコードを読もう！)」と少々過激なことも発言してみました。全員がテストコードを読めるようになってプルリクレビューに参加出来るようになると、内部品質は爆上がりするんじゃないかと期待しています。
更に、開発者にリーダブルなテストコードを書いてもらえるように、まずは私が開発者と伴走していくよと宣言をしました。虎の威を借る狐のように、「ライオン(t-wadaさん)の威を借る狸(私)」になります！ジョジョ4部のチープ・トリックのように、開発者の背中でささやき続けます！
「ユニットテスト書いて、ねっ！テスト書いてないとか、t-wadaさんにばれたくないでしょ、ねっ！」
まとめでは、SPQI部の将来ってこうありたいよねという自分の考えをまとめました。日進月歩の速度で進む開発技術に対して開発者がキャッチアップしていくのと同様に、QAも品質向上のための技術をしっかりキャッチアップしてお互いに助け合いたいと、私は思っています。開発とQAの理想的なシナジーを生み出して事業を押し進めていきたいなという意思表示をした回でした。
なお、具体的なテストコードの読み方やレビューの仕方については、来年の1～2月を目処にまた勉強会を開きたいと思っています。
第2回目
新人研修担当から「新人向けにユニットテストの書き方を講義してくれ」という依頼があったので、第2回目は10/10に新人向けに勉強会を開催しました。タイトルは『 テストコードの書き方 ―なぜ開発者がテストまでしなきゃならないのか― 』です。
この話を受けたとき、「新人向けのユニットテストの書き方だったら沢山記事あるんだよな～」と思ったので、サブタイトルでもある「なぜ開発者がユニットテストを書かなければいけないのか」について重点的に話すことにしました。「テストコードはQAが書けばいいじゃん」という開発者、昔はよく居たんですよね。まさか今でもそう思ってる開発者なんて、いねぇ～よなぁ～！？私の理解では、プロダクトコードとあえて密結合させることでその変化を検知しやすくするのがテストコードなので、プロダクトコードの書き手が、必然的にテストコードも書くことになるのです。
勿論しっかりユニットテストの書き方も解説しました。うちの製品ではJavaをよく使ってるので本当はJUnitで書きたかったんですけど、私の都合でpytestで書くことに。Given When Thenパターンで書くこと、できるだけ網羅性を高めるようにホワイトボックステストで書いてほしいことの他、応用編としてモックを使った外部システムとの連携や、リーダブルなテストコードについても紹介しました。
一つ誤算だったのがMSパワポのバグで、編集画面ではちゃんと表示されているのにプレゼンモードだと文字化けするという落とし穴にハマったことですねwこれは酷いw
そして最後には、テスティング技術の知識は開発以外の仕事にも応用できることを、講師権限で語り始めてしまいましたwいやぁこのスライドは個人的に会心の出来ですね。数年前にQAを勉強し始めた頃は、こんなマイナーな方向に進んで今後のキャリアは大丈夫かと不安でしたが、今はけっこう大真面目に一生食いっぱぐれない自信があります。技術を進歩させるために人類が見出した手法がテスティング技術だと今では思っていて、この技術はどの業界にも応用できるんだもん。
まとめでは、ウイングアークに限らず業界の弱みだと思う、中堅層(テックリード)の育成を視野に入れた、社会人の心得を伝えたつもりです。「会社の文化ってもんは人から与えられるものじゃねぇ、お前らと俺らで作りだすものなんだぞ(だから現状に諦めるのではなく、足掻いていこうぜ)」という言葉でまとめました。制限時間を15分くらいオーバーしてたけどw
第3回目
前職でDockerの勉強会聞いた時の不完全燃焼モヤモヤとか、今の配属PJでDockerを使ってなくてモヤモヤとか、毎週の勉強会枠がスキップされてモヤモヤとか、諸々モヤモヤが積み重なったので、3回目はQAと関係ないですがDockerの話をしました。発表日は11/2、タイトルは『 Dockerが生まれた背景とDocker利用デモ 』です。
QAエンジニアがどれだけDockerを扱えると良いかという私の意見としては、コマンドを渡されればそれを実行できて、ローカル検証環境を自動構築できる、というレベルで良いと思っています。0から構築するスキルはまあSETが持っていればよいかと。なので今回の勉強会は、Dockerの使い方よりも、この技術が生まれた背景や利用する利点はどこにあるのかを伝えようと思っていました。
開発者が書く公開記事や社内wikiであるあるですけど、こういった話を丁寧にすること無く、すぐ技術の話をし始めちゃうパターンが多いですよね。技術史の話をきちんとして、古い技術と比べて新しい技術がどういう位置付けなのかをまとめることで、その技術を理解しやすくなるし、更に新しい技術が出てきてもすんなり吸収できると思います。
Docker誕生まで技術史については、以下のストーリーで構成してみました。
- 「集中と分散」というキーワードから振り返るコンピュータの歴史
(cf: 電子計算機の黎明期に作られた巨大なコンピュータの写真いろいろ | DailyNewsAgency) - クラウドの成立と、それを支える仮想化
- 仮想化の一種としてのコンテナ型仮想化と、その制御ソフトウェアのDocker
「お前の解釈、間違ってるぞ」というマサカリ、お待ちしております。
最後にDockerの主要概念を説明しながら、デモを見せて終わりです。今のチームはこれまでWindowsのHyper-Vを用いて仮想化してきていましたので、自動で検証環境が構築されていく様を見たら、「これは便利！」との声が上がりました。そりゃそうだ。
以上が講師をした勉強会の内容の概要です。抜粋でしたが、どんな勉強会だったかイメージ出来たなら幸いです。
薄々は感じていましたが、やはり自分は、多数の人にわかりやすく教える(わかった気にさせる)スキルを持っているようです。SET × 勉強会講師という独自ポジションを確立できたな。来年から「成り駒の斎藤」とでも名乗ろうかねフヘヘw
来年も、勉強会を開いて新しい技術をみんなに広めて、SPQI部や開発部の技術力を底上げしていきたいな～と思ってます！
皆様、今年もお疲れ様でした！来年も頑張ろ～！
