Autifyコアメンバー活動やってみました！
はじめに
2021年は一生懸命ブログを書こう！そう決めてから、はや12か月が経ちました。 ということで、チームスピリットの生井です。
今年は悲願だったJaSST’21に登壇したり、AutifyのCommunityコアメンバーをしたり…
QAエンジニアとしては登壇だったり外向きの発信する機会が多かったように感じます。
なので、今回はAutifyのコアメンバーとしての活動について話をします。
会社の中ではQAマネージャ兼エンジニアリングマネージャとして、採用とかチームビルディングのためのイベント開催とか新メンバーの受け入れとかとかしていて、 あまりQAエンジニアらしい取り組みが出来なかったかも…と思っており、社内の人にはこの機会をもってこんな活動してます・してました！を知ってもらえたらなぁという感じです。
それではいってきましょう！
Autifyコミュニティ・コアメンバーとは
Autifyユーザ向けのSlackを使ったコミュニティで、ユーザ同士の交流やAutifyへのリクエストが出来ます。
コミュニティのコアメンバーは、月に1回のペースで会議を通して、コミュニティmeet upのコンテンツ案について検討したり、どうしたらコミュニティの活動が盛り上がるかを話したりすることで、コミュニティでの体験をより良いものにするユーザの1人です。
自分としてはなかなかSlackの返信ができなかったりしたので、なるべくアイディア・意見を出したり、登壇の依頼があればなるべく出ることでコミュニティに貢献できれば…と思って行動してきました…つもりです。
参加したイベント
私がコミュニティでの活動を通して発表した内容について振り返っていきます。
1月
Autify Meetup ~Autify導入・運用実践者にそのノウハウを聞いてみる編~ - connpass
発表資料
コメント
社内のAutify導入の様子を発表しました。 開発チームを巻き込んで「みんなが参加できる自動テスト」にするってのが継続して使ってもらえる一番のキモで本質なのかなって思ってます。 シンプルだったり、高機能なのはそのために必要な要素であり、この辺りはチームのスキルだったりによって何が効果的かは変わってくるのかなぁと思ってます。
3月
発表資料
コメント
これについてはコミュニティとは別で動いてたのですが、後日感想戦とかもしたので書いておきます。
自動テストの属人化のアプローチをAutifyの導入の事例に寄せて話した話をしました。
最近はE2Eテストをノーコードで出来るツールがいくつかありますが、ユーザーの好みや自身の状況を鑑みて選べばどれを使ってもいいと思っており、これが正解みたいなのはないと思ってます。
自分の場合は、チームのメンバーのスキルとかを鑑みて、「使いやすさ」と「この先、会社が成長しそうか」どうかで選びました。
この発表ではAutifyの使いやすさだったり、どうすればみんなで使えるようにするのかみたいなことを話しています。
また、会社の規模だったり会社の勢い・影響力みたいな何かは、製品の機能開発の速度にも繋がっていると考えています（個人の見解です）。 なので、ユーザとしてはどんどん機能開発してるツールを使うほうがなにかと便利だと思っているので、「この先、会社が成長しそうか」というのは自分的には大事な要素です。
もちろん、他の選び方もあるよなぁと思うのであくまで一つの意見です。
それと同時にユーザの意見を吸い上げられるのも大事だと思うので、１ユーザとして協力できることは協力する所存です！
4月
コメント
Communityのコアメンバーとして使い方というか、自分の会社はこんな感じで使ってますよーというのを発信しています。
他にも小規模のメンバーで座談会とかをこの時期に行った気がします。。
5月
コメント
社内の目標設定やコミットなどでE2Eテストの成果を定量的に出す際に、カバレッジ等を求められたりしないですか？みたいな話がきっかけで、このテーマの勉強会が開催されました。
Autifyというよりは品質保証組織の在り方について話す勉強会で、コミュニティではAutifyのほかにも品質保証やテストスキルの向上ができるようなコンテンツを心がけています。
8月
コメント
「一人目のQAエンジニアの役割」というテーマでパネルディスカッションを行いました。
自分の場合はチームを立ち上げて4年くらいたちますが、いろんな失敗を経験した結果、考えがいろいろ変わったりしたので非常にいい経験でした。そんな思いの一端をここで発表した感じです。
話していない情報を書くとすると、最近はどこの会社もQA組織の立ち上げとかのために優秀な人の取り合いをしている気がします。
今の私たちのような、QA組織の立ち上げ期でもなく、メガベンチャーでない規模の会社のQA組織に入るメリットを上げると、「幅広い業務を覚えられる」点があると思います。
規模が大きくなると、セキュリティとか性能テストとかの領域で専門部署があったりするので、専門家に任せられるということがあります。安心感があっていいですよね。マジでうらやましい。
そうでない場合、「専門家はいない、私たちしかいないんだ。」状態になるので、悪い意味での無関心ではいられなくなります。
結果として、こういった分野がいくつかあると足りないスキルを補う経験をたくさん行うので、幅広い業務を覚えられる気がします。 （まぁ、これをポジティブに捉えられるかどうかとかはありますが…）
一人目QA組織でもできるじゃん！って反応はもちろんあると思うのですが、チームの立ち上げ期は最優先でやるタスクに対してリソースが追い付いてなかったりするので、幅広い業務をやるっていうよりかは自分で決めた選択肢の中から死なないように選んで遂行するのが多いイメージです。
なので、体系的に幅広く知りたい人には「最近チームの形になってきた…！」みたいな組織はお勧めだと思ってます。
興味を持たれた方はぜひコチラへどうぞ。（露骨な宣伝） ↓↓↓↓
おわりに
いかがでしたでしょうか？
ユーザコミュニティではAutifyの知識のほかにもQAやテストの技術向上ができるようなコンテンツを用意しています！
まだ使っていないAutifyユーザの方はぜひ活用してみてください！
今回の記事はチームスピリットアドベントカレンダーとAutifyアドベントカレンダーの5日目の記事になります。 よければ他の記事も覗いてみてください！
ここまで読んでいただき、ありがとうございました！
おわり
2020年買ってよかったものランキングTOP５
はじめに
今年はブログのアドベントカレンダーの他に、お茶のアドベントカレンダーを買いました。
毎日、異なるお茶を楽しめるのでとても良いです。
さて、2020年は去年とは働き方やいろいろな面で違った一年となりました。
ワークスタイル・ライフスタイルが変化した中で「これは買って（使って）よかったな」という物をランキング形式でお伝えしたいと思います。
続きを読む
テストコンテストに出場してきた話
はじめに
今回は表題の通りテストコンテスト（U-30クラス）に出てきたふりかえりを記事にしたいと思います。
アドベントカレンダーとか以前にブログの記事を書くのが久しぶり過ぎて書き方を思い出すのに時間がかかりそうです。
※注意：テストコンテストにおける要求分析とかテストアーキテクチャ設計のテクニックについていろいろ書けたら良いのですが、今回の記事はプロジェクト進行とかエモの話題が多めです。ご了承ください。
テストコンテストとは
ざっくり言うと…それぞれが持っている、「ぼくのかんがえたさいきょうのテスト設計」を競う大会です。
真面目に知りたい場合は、テストコンテストのHPをご確認ください。
（一応、目的とコンテスト方式は貼っておきます）
ASTER-テスト設計コンテスト
テストコンテストの目的
コンテスト方式
- 指定のテストベースに対するテスト設計を行い、その優劣を競います。
- コンテストのレベルには、OPENクラスとU-30クラスがあります。U-30クラスは、30歳以下の方に限定させていただきます。
- OPENクラスのコンテストでは各地域予選を行い、優秀と認められたチームが決勝戦へ出場する権利を得ます。
- 決勝戦では予選を通過したチームが集い、その腕を競います。予選で作成したテスト設計資料をさらにブラッシュアップすることで、技術を進化させる楽しみを味わってください。
- U-30クラスは書類による予選を行い、優秀と認められたチームが決勝戦へ出場する権利を得ます。
- U-30クラス、OPENクラスともに、各地域でチュートリアルを実施します。チュートリアルではテスト設計に関する講義を行います。このチュートリアルは一般の方も参加可能です。参加予定チームはもちろん、一般の方もぜひご聴講ください。
参戦のきっかけ
テストコンテスト自体はちょっとだけ興味があったけど、いきなりOPENクラスに出るのもちょっとなぁ…と思っていたところ、社外の知り合いの方がテスコンに出たそうにしていたのでご一緒させてもらうことになりました。
チーム結成と認識合わせ
そんなこんなでtwitter上のネットワークの有志で集まったメンバー５人でチーム「王バーフロー」を結成しました。
とはいえ有志のメンバーかつ昨今の事情もあり、全員がフルリモートでのチームの発足です。チームの結成に合わせて実施したことを簡単にふりかえります。
インセプションデッキを作る
チームの構成としては、テストについて知りたいエンジニア３人と業務でもテストをしているQAエンジニア２人といったチーム構成でした。
初対面（対面してない）の人もいるのでチームの認識を合わせるためにリーダー02さんの発案でインセプションデッキを作りました。
インセプションデッキを作ったことがない人も多い中、みんなでワイワイとチームの方向性を決めるのは意外と楽しかったです。
プロジェクト管理ツールを用意する
完全にフルリモートでテストコンテストに参加なので、なるべくオンラインで作業が円滑にできる様にそれぞれが持ち寄ってツールを用意しました。
ざっくりまとめるとこんな感じです。
タスク管理ツール： JIRA
ドキュメント管理ツール： Confluence ＆ google drive
コミュニケーションツール： discord
ホワイトボードツール： miro
JIRA
各々でタスクを切って特にルール細かいルールは決めずにカンバンみたいな感じで使ってました。
miro
ホワイトボードとして使用、アイディア出しには重宝しました。
予選まで
提出物を作るために
…と、いろいろやりましたが、ちょっと風呂敷を広げ過ぎた結果、問題が起こります。
問題と言うか、本質というか。「仕事とテスコンの両立めっちゃ大変問題」に打ち当たります。
全員で集まれる日程がほとんど取れなかったり、他の活動でリソースをとられたりして、予選は全員で集まることができたのは最初のキックオフぐらいだったと思います。（ちなみにその後も同様）
自分達のチームではテスト要求分析に時間をかけ過ぎた結果、当初予定していた計画は破綻してテスト設計・テスト実装にほとんど時間をかけられず、それぞれのメンバーが締め切りギリギリのGWに時間を作って成果物を作成することになりました。
有志のチームは作業時間をいかに確保するかは結構ちゃんと考えないと計画が破綻することを身をもって経験しました。
とまぁ、結果的に十分な成果物を出せた印象はありませんでしたが、テストの要求分析などを自発的に業務でやる機会が少ないので、自分としてはこの期間でやったことは結構面白かったです。
決勝に向けて
正直、決勝には上がれなかっただろうなとほとんど諦めかけていた6月に、思いがけない知らせが届きます。予選通過ギリギリの4位で決勝進出の連絡が来ました。
予選のふりかえりをKPTで行いつつチームの方針を今一度まとめる会をやりました。
結構、当初決めたインセプションデッキの思いからみんな外れかけていたので、向き直りという意味で重要なポイントだったと思います。
予選の失敗を踏まえ、決勝では「はじめに最低限の成果物を一通り用意し、そこからブラッシュアップする」という作戦を取りました。
自分はブラッシュアップするための資料のベースを作るというかなり重要な役回りを担当することになり、いろいろ調べたり一人で考えたりと設計におけるクリエイティブな部分を感じ取ることができました。
テストベースがきちんと用意されているので、要求カバレッジをとってみたり、効率よくテストするためのテストケースの順番を考えたりと業務に活きる挑戦ができたのはよかったです。
とは言え、予選と同様に仕事が忙しいメンバーがいたり、十分な作業時間は取れませんでしたがなんとか提出物については一通り準備することができました。（当日の掲示用資料は発表資料と一緒にすればよかった…などありますが）
そういう意味では、ふりかえりをおこなった成果が出ていると言えます。
決勝
発表資料
決勝はオンライン開催で発表者は1名のみだったので、聴衆席での参加でした。
発表してくれたリーダーの02さん本当にありがとう！！！って感じです。
審査員の皆さんの指摘は「本当にその通りです。」とか「Exactly」って感じでした。
なんていうか、「やり切る」ってとこに注力したので優勝する様なテクニックを載せる余力はほとんどありませんでしたってのが実際の所です。
…ちなみに結果は「準優勝」でした！！
最後までやり切った結果の副賞が準優勝って言うのは、最高の結果だと思います。
頑張ってよかったなぁ。と思いました。
終わりに
以上が、自分達が参加したU-30クラスのテストコンテストの大まかな内容です。
フルリモートでのテストコンテストの難しさを前面に出した記事になってしまいましたが、次回以降参加する人の何かの気付きになったら幸いです。
最後になりましたが、この記事はチームスピリットアドベントカレンダー２日目の記事です。
おわり
継続は力になるの？英語学習を100日間やってみた。
はじめに
仕事用に机とかいろいろ買ったけど、椅子はどうしても座って決めたいけど座りにいくチャンスが存在しないジレンマに悩まされています。こんにちは。
タイトルの通りなんですけど、英語の学習（単語の勉強）を100日間、毎日やってみることに成功したのでレポートです。
きっかけ
去年の冬から急遽、海外拠点のエンジニアが助っ人に来たPM１エンジニア２人の混成チームの一員になり、否が応でも英語と触れ合う機会になりました。（背水の陣！）
他にも、会社の若い同僚が英語学習を習慣にしている話を聞いていたので、「もちろん普段から勉強していますよね！」と言うキレイな視線に後ろめたさを感じていたので、きっかけとしてはちょうど良かったです。
目標設定
勉強らしい勉強（自己学習）は高校生以来で、読んだ英文が頭の中でカタカナの羅列になっているように感じた時から苦手意識を持っているのですが、仕事で使うのでなんとかせねばと言う感じです。
とりあえず、目標は流暢に喋るとかではなく、最低限の仕事のコミュニケーションが取れる状態（お互いが頑張れば意思疎通が出来る位）を目指しています。
と言うわけで、まずは単語の勉強を始めることにしました。（単語が分からないとストレス感じるので。）
勉強内容
使った書籍はこちら。そもそも、自分のレベルがイマイチ分かんなかったのでまずはBasicって書いてあるやつで始めました。
触った感じ、1日分じゃ少なかったので、1日30分~45分ぐらいの学習が出来るよう毎日3日分を進めるようにしました。
大体、50単語弱くらいの量です。自分は手で書いて覚える派なので毎日ルーズリーフ１ページ半くらいを書くような感じです。
日本語の意味＋フレーズで1周、センテンスを1周の合計2周やってみました。
3日分進めると大体３週間くらいで1周が終わります。
1周終わるとルーズリーフの数もそれなりに貯まるので達成感を感じます。
また、後になって気付いたのですが、この本は大学受験用らしいですね。 TOEIC用のがあるのは後で気付きましたが、TOEICも目標にしてないしこれでいいかってなってます。
ある程度、覚えた（気もする）ので次のテキストを買いました、同じシリーズです。
これについては知らない単語ばかりだったので、日本語の意味＋フレーズで2周、センテンスを2周の合計4周やってみる予定です。
（今3周目に入ったところで100日経過しました）
TOEICを受けようとするが…
本当は一月半ほど勉強した3月に、TOEICを受けて自分の英語レベルがどんなもんなのか知りたかったのですが、昨今の事情により試験自体が中止になってしまいました。
なので、この記事を書いているこの瞬間も自分の現在地を定量的に測る機会がなくなってしまったのですが…続けてます。
100日後、どうなったのか。
すごく当たり前なんですど、単語の勉強しかしてないので話せません。でもまぁ、知らない単語が出てきてそこでつまづいて後ろが全部わからなくなる…みたいな頻度が減った気がします。
また、英語の記事を読んだりしてみようかなって思えるようになったので、英語の苦手意識が少し減りました。勉強の成果をどれくらい出せるか試そう！みたいなポジティブな気持ちになれるようになりました。
あとは実戦で海外拠点のエンジニアの面接に出た時には、簡単だけど自分の思いを話して伝えられた気がします。(入社してくれたので多分伝わってるはず。)
Slackでの簡単なコミュニケーションならgoogle翻訳使わずに出来るようになったので、仕事のストレスが多少軽減しました。なので、個人的には良かったなと思ってます。
おわりに
その他にも…休みの日（特に午前中）に勉強すると、それ以降何しても許される免罪符を手に入れたような気分になるのでお勧めです。
たまにかかって来る外国人エージェントとの英語の電話のコミュニケーションが聞き取れるようになりました。（ちなみに、これまでは何言ってるか全くわからなかった。）
単語の勉強だけでも、効率がいいかは分かりませんが変化は感じ取れ、積み上げることの大事さを改めて感じ取りました。
どこまで続けるか分かりませんが、来年以降とかでこの学習の時間を他の勉強とかに置き換えてもいいかもなとは思えました。
継続は力になりそうだよーと言ったところで今回の記事はおわりにしたいと思います。
おわり。
【ポエム】最近のもやもやを供養する
はじめに
最近、普段の「なんだかなー」って思うもやもやしたことが増えてきて、何にもやもやしているのか上手く言葉にできないところがあるので時間をとって考えてみました。
なので今回は完全にポエム回です。
もやもやしただけだと、まったく建設的じゃないのでこうすればいいのでは？っていう一文も添えることでギリギリコンテンツになる…ならない気がする。そんな記事です。
もやもや1：”みんなで”解決策をディスカッションして決めたいと思います… ”みんなで”共倒れパターン
リーダーシップを取るポジションの人がノープランの時にこの手の発信をしている気がする。
また、結構な割合で「仲の良い組織を目指します！」みたいな手段が目的化してるケースが多いと思う。
結果を出せるチームは仲が良いことは多いと思うけど、仲が良くなれば結果を出せる訳ではないと思う。
こういった時は大抵、複雑な問題に直面しているのでディスカッションしてもなかなか有効な解決策がでないので多くの時間を使ってるのをみるともやもやする。
それでもって議論の末に出た、いろんな人に忖度した帯に短し襷に長しみたいな誰のためにもならない施策に残り少ない時間を使って残念な結果になるのを見ると…別の未来はなかったのだろうかみたいな気分になる。
じゃあ、どうするか。
複雑な問題に直面しているときは一つの施策でどうにかなるような銀の弾丸は無いのだから、いろいろな施策をたくさん試す必要があると思う。
ただ闇雲に打ちまくっても無意味なので、なにを大事にするかはきちんと決めるべきだと思う。
なので結果的に一部のメンバーの意に合わない決断をすることもあると思うけど、自分が決めたことを信じて一生懸命やるべきだと思う。
そういった決断を呑んでくれた人の分も含めて。
もやもや2：合議制を取った結果、とんでもない珍戦術が飛び出すパターン
これは逆にリーダーシップを取る人がいなくなったときに起きるパターン。最近の身近な例なら感染症対策に「お肉券」か「お魚券」を配ろうとか言いだすのが近いかも。
「この施策の責任者は誰ですか？」って聞くと静まり返る系のやつですね。頭を失ったゾンビみたいなオーナー不在の仕事にメンバーの時間を使うことになるのは、もやもやポイントが高い。
上手く行かなかったとしても誰も偉い人が責任をとらないのがこれの一番怖いポイント。失敗しても平気で第２、第３のゾンビを送り込んできます。
じゃあ、どうするか。
メンバーを動かして進めることに対しては責任をもって進めて欲しい。
お肉券を配る人に対して「私が考えました！絶対に必要なことなんです！」って胸を張って言えるのか、一度冷静になって考えてほしいですねー。
まぁ、そこに責任持てないから責任者不在のゾンビが生まれるのだけれど。
もやもや3：責任範囲を明確化するフリして自分の仕事じゃないアピールしてる…けどやっぱりあなたの仕事ですよねパターン
SESだったりウォーターフォールのプロジェクトにいた時は工程ごとに仕事を受けたりするので、責任の範囲は（きちんと決めていれば）明確になります。
会社間の仕事だったりするとそういうところできちんと役割を分けたり、リスクヘッジするのは分かります。自分も前職はSESだったのですごく分かります。
でもそれをやるのなら契約だったりした会社間のきっちりした間柄でやって欲しい。事業会社の中で、それも同じ部署の同僚間でそれをやるのは結構もやもやします。
しかも大抵これが起きるとき、柵で囲った責任範囲が狭い方の人が主張してるアンフェアなケースが多い気がする。
渡そうとしてるの対象の範囲が広く担当するのをいいことに、自分の仕事を少なくしようとする魂胆が透けて見えると…うーーーーんってなる。
自分のチームなら「いや、おかしいでしょ。」って言っちゃうんですけどね。（なので言わない。）
じゃあ、どうするか。
渡そうとしてる人も同じ同僚で同じ目的を達成する仲間なんだから、もうちょっと広い視野で見てほしい。
我々がやろうとしてることは、特定の範囲だけを守る仕事じゃない…と思うんですけどね。
広い範囲を持ってる人はチームの中でも難しい、大きな課題に挑んでいるんだから自分のできる範囲のボールは協力して拾うべきだと思うなぁ。
…まぁ、この手のもやもやを感じる時はそれぞれの中間じゃなくてあきらかにアンフェアな場合なので協力以前にフェアにやろうぜって感じだけど。
まとめ～もやもやの共通点を探す～
ここまでつらつらと書いたところ、共通点がありそうなことに気が付きました。
もやもやしてる時は大抵「自分の保身」に走っている人が視界にいることに気づきました。
「決められないから責任を分散しよう」
「失敗するかもしれないから責任を曖昧にしよう」
「自分の仕事さえ少なくなればいい」
みたいなやつですね。
なるほど、ちょっと理解できました。チームプレーの中で利己的なメンバーがいると上手く行かないのをこれまでの経験の中で感じ取ってるからもやもやしている様子。
個人的な気づきが得られたのでポエムを書いたのはよかったのかもしれない。
ある程度収穫があったタイミングで終わりにするのがキリがよさそうに思えたので、この辺で終えようと思う。
おわり
なぜQAとして発信するのか考えてみた話。
はじめに
自分が勉強会の登壇や、外部への発信をやっている理由は端的に言うと「同じ価値観を持つ仲間に知ってもらいたいから」だと思っています。
理由として「同じ価値観・経験を持つ人」が業界の構造としてかなりの少数派であることが挙げられます。今回はそこら辺のことは短めの文章で書こうと思います。
※あくまで個人の見解です。
目指している姿
スクラムチームのエンジニアの理想像は「T字型人材」だと考えていて、開発チームにおけるエンジニアの枠組みの中にQAエンジニアも含まれていると思っています。
なので、スクラムチームがswarmingするときは開発だってするし、仕様検討だってするし、テストだってする。
その中で「一番得意なのがテストだよ」…っていうようなエンジニアをQAエンジニアとして考えています。
参考:Swarmingとは スワーミングがアジャイルチームを助ける
日本のIT業界におけるQAエンジニア人材
といいつつ、こういったエンジニアは少なくとも自分の会社のカジュアル面談の場にはほとんどやってきません。そもそも、QAエンジニア・テストエンジニアの人が少ないです。
PRや採用側の問題…とかもあるかもしれないのですが、日本のIT業界は責任範囲を明確に絞り、その領域に特化した人材で開発を進めてきたこと…とかも理由として考えられます。面接に来ていただける候補者の多くがテストの設計と実行の経験だけという場合が多く、計画や評価を含めたすべてのテストプロセスを担当した経験がある人の方が少ないように感じます。
※テストプロセスについては下記に載せておくので興味があったら参考リンクをご確認どうぞ。
JSTQB TestAnalystにおける テストプロセス
- 計画、モニタリング、およびコントロール
- 分析
- 設計
- 実装
- 実行
- 終了基準の評価とレポート
- 終了作業
JSTQB認定テスト技術者資格-シラバス（学習事項）・用語集-
そのため、経験領域と目指している姿にギャップがあるのは分かった上で、難しい採用活動を進めているのは理解しているつもりです。
しかし、（あくまで自分が見える範囲の）海外に目を向けてみると目指すべき姿とマッチした経験をもった人は日本よりはいるように感じています。
ISTQB Agile Testerを取得できる国もあるので、そういった部分も関係があるかもしれないですが、計画からレポーティングした上で、継続的なテストの推進を経験してる人…とかもたまにいる印象です。
なのでどうするか(まとめ)
グローバルな観点で言えば、海外の品質保証のスタンダードを取り込みながら働くべきだと思っています。
そうしないと独自の品質保証の仕組みを推進した結果として、今度は海外でメンバーが取れなくなるリスクが発生するからです。
なので、日本における採用は経験を持つ人が少ないのは認めた上で、同じ価値観の人に来てもらうしかないかなと考えています。
やったことないのであれば覚えればいいし、そういった成長込みで仕事をするメンバーと一緒に働けたらいいなぁと思っています。
なんでもやるような「T字型人材」を目指すような人に向けて今日も発信していこうと思っているので、引き続きよろしくお願いします。
おわり
JaSST'20 Tokyo RejectCon 登壇の裏側レポート
ブログに書いて欲しいというネタが複数あったので、今回の記事は個人ブログの方に書くことにします。
来る2月3日（節分ですね！）に開催されました。「JaSST'20 Tokyo RejectCon」という勉強会で登壇してきたレポートになります。
個人ブログの方がもう少しフランクに書けるのかな…文体が安定しないので、変わらないかもしれない。
概要
connpass connpass.com
ブログ枠の方のレポート qiita.com
勉強会全体のレポートについてはブログ枠の方が発表していますので主に自分の事について書こう。
はじめに
今回の発表は @tsueeemura さんからお誘いいただきました。
TwitterのTLで開催することは知っていましたし、今年はTokyoに出してないなーぐらいに思っていましたが、対面でお誘いされたので断るなんてことはできません。
加えて「なんでも大丈夫です！！」と強く言われたので、なるほど…それなら一昨年に出してダメだったやつでも大丈夫だなということで参加を決めたのでした。
勉強会自体はみなさん各々の話したいことを発表されていたので、いい意味でRejectConっぽくない勉強会で楽しい感じでした！
実際に勉強会に行ってみてRejectConっぽい発表が自分くらいしかしてなかった…気がするので無駄な心配でした。
実際の発表
発表で使った資料は上記ですが、結論から言うと一昨年に出した内容を発表するのってすごく大変でした。
大変だった理由
- 思い出す&過去の失敗をリカバリするのが大変
- RejectConとはについて悩む（構成について悩む）
- 普通に忙しくて大変
思い出すの大変&過去の失敗をリカバリするのが大変
そもそも事例発表のアブストを提出したのが2018年の秋なので一年以上経過しているわけで、まずは過去のアブスト引っ張り出してくるのに苦労し…加えて過去のものを読み直してみると色々粗があるので、発表に足りる内容まで昇華することが大変でした…。
びっくりしたのが、過去の自分が「健康診断に例える」と銘打ちながら肝心の健康診断は一部分で、アブストの中で話したいことは主にアジャイル開発と品質の捉え方の話をしている訳ですね…。
当時の自分は新規性だったりキャッチーな内容を散りばめたかったのでしょう。
(健康診断の件は結構いろんなところで言われてますけどね…。 )
過去の自分と対話しながら、当時どういうことをしたかったのかを思い出しながら、今の自分だったらこうする…みたいなのを混ぜながら今回の発表を作りました。
…ちなみに普段の仕事でCIサーバーをいじってる時は逆のケースもあり、過去の自分の残してくれた崇高なドキュメントを見ながら、過去の自分が思い描いていた理想を現在の自分が追いかける…みたいなこともたまにありますw
RejectConとはについて悩む（構成について悩む）
JaSST北海道にでて分かったことはJaSSTは学術的なイベントだと感じたので、普段の勉強会より真面目な印象を持っています。
なので、その真面目モードの発表をそのまま持ってくるのは果たしてRejectConに本当にふさわしい内容なのかと悩みました。
「Rejectされた内容に対して勉強会の参加者が得たい情報ってなんだろう」…と。
とか真面目に悩んだ結果、以下の内容を発表に組み込むことにしました。
- 不採択の理由を含めて振り返り、発信する
- 具体的な事例よりも伝えたいエッセンスにフォーカスする
1つ目は事例を出したい人が参加するかもしれないので、その人に向けて情報が残ればいいなぁという思いがあったので組み込みました。
2つめについては実際に事例発表の場でないので、本来厚めに語る具体的な施策・事例の部分だったりといった部分を削減することで伝えたいことを残しつつ15分の発表に押し込みました。
結果としてはRejectConっぽい発表だけど、事例発表っぽくない発表になったので大筋で思惑通りです。
あとはAutifyさんにゴマすりもできたので完璧。
普通に忙しくて大変
結構安請け合いしちゃうタイプなので自分のリソース管理は苦手です。
そんな中、社内の勉強会（ほろよいてっく）に向けたLTつくって、今回の登壇資料作って、QAメンバーのAL取得のためのテスト技法勉強会の準備したり…この頃は普段の仕事以外のタスクを引き受けすぎました。
本当に間に合うか怪しい瞬間もありましたが、無事に発表できてよかったです。
とはいえ、結果的にどれもある程度良い結果になったので必要だと思ったことはこれからも引き受けちゃう気がします。
まとめ
最近、自分の忙しさにかまけていたせいか参加も含めて久々の勉強会の参加となりました。
別の会社のQAエンジニアの人とお話したり、自分が企画した勉強会の話をして頂いたりと、普段の仕事とは別の刺激になりました。
こういった活動は大事にしていきたいと遠のいていた自分に反省をしつつ頑張ろうと思いました。
おわり
