前回はこちら：JaSST'24Kansai基調講演こぼれ話（その１） - テストウフ
- 講演に入れなかった内容の話
- 時間の関係で削った話
- 意図的に触れていない話
- 講演概要には書いてあるけど実は回収していない部分の話
- B案
- miisanや平田さんの講演内容とどう分けようと思ったか
- 当日の情報交換会や打ち上げなどできかれたこと
- 本会参加者の皆さんへ
を予告していたのでこのあたりを書いていきます。なお他にも書きたいことが出てきたのでこぼれ話は最低でも３部構成になります。多いね。
講演に入れなかった内容
色々な都合で講演に含めなかった内容についてここで補足しておきます。
スキル不足とピーターの法則
時間の関係で削った話です。
QAの仕事をつくるうえで、「スキル不足」に悩む場面が絶対に出てくるよなーと思っています。 そして、「自分にはスキルが足りていない」とか「うまくいかない」というモヤッとした感情がトリガーになって、悪い意味で「QAとしてどう生きるか」、つまり「やっていけるのかなぁ」といった悩みへと発展していきがちです。 おそらくこういった側面で「どう生きるか」を考えるのはあまり健全ではないので、できるなら避けたほうがいい。
ここで「ピーターの法則」という考え方があります。
ざっくり言うと「なぜ上司は無能なのか」という話で、
有能で活躍すると出世するが、みな有能さを発揮できる限界まで出世して、有能でなくなったところで出世が止まる。だから、皆いまいるポジションにおいては「無能」なのだ、という法則
です。 これが事実かどうか正確な話をしたいわけではないので、ここでは「ほーん、なるほどね」で済ませて貰えればOKです。 また、有能とか無能とかいうワードはなんとなくいけ好かない人もいると思うので、「スキルが足りている」「不足している」という表現で置き換えてみると良いでしょう。
つまり、ピーターの法則を信じるならば、皆「スキル不足」とされる難易度まで業務レベルが上がってしまうので、スキルが足りててヨユーという人はいない、ということになります。
だから気にするな！ということを言おうと思っていました。
実はプロダクト品質とかビジネス側面の話をしていない
ことにお気づきでしたでしょうか。
これもあえて入れてなかった部分です。
というのも、講演中で説明したように組織体制としては開発部門の中を潜っていってQAが居るような形になっていて、ビジネス部門との距離が若干遠めなんですね。 もちろんだからといってプロダクト品質とかビジネス側面がどうでもいいと思っているわけではないです。
ただ、今時点での自分の考えでは「まず身近な開発者と一緒にプロセス品質よくしていこう」というところからやっています。
なので、施策として出てくるのが開発プロセスにおける取り組みの可視化やガイド設定などになってます。
講演の中であまり回収していない「胸を張って」のところ
胸を張ってQAエンジニアやテストエンジニアだと言えるような自身の仕事をどうつくっていくのか、一緒に考えてみましょう。
にあたる部分、あまり回収してないです・・・。
これは、上で触れたピーターの法則と絡めて、
- QAの範囲は広いんだから、自分で仕事をつくることで「これが自分の仕事だ！」と胸を張って言えればそれでいいじゃないか
- どうせスキル不足はみんな同じだし
といった趣旨の話をして、エモ寄りにすることも途中までは考えていました。
が、聴講者層がそこまで若手中心でもないよなということも考え、エモみは抑えたトーンにしたり、ピーターの法則あたりを削ったりという判断をしました。 結果的にQA経験10年以上の方もゴロゴロいる場だったようなので、あながち間違ってはいなかったように思います。
ただ概要の回収がしきれなかったのはすみません、ですね。
選択しなかったB案
講演全体の話の持っていきかたとして別の案も考えていました。
それは、QAエンジニアとして仕事をつくるのにテスト会社で培ったスタイルをフル活用した話！という内容です。 実際の講演時には口頭でちらっと触れたにとどまりましたが、課題設定などQAの仕事をつくる部分はテスト会社での仕事の取り方・立ち回り方を社内でやったりしていて、かなり活きていると思っています。
テスト会社→事業会社、という人もそれなりにいますし、また興味を持っている人が居るのも知っています。そのため、仮にこの話をしても役に立つ人はいるだろう、とは思っていました。
ただ、今回基調講演なのでよりスコープ広めにとることを選択しました。
miisanや平田さんの講演内容とどう分けようと思ったか
自分以外の講演者がmiisanと平田さんだということは事前に伺っていましたが、それぞれが何を話すか共有したり、事前に講演者間で話をしたりということはありませんでした。
参加者の皆さんと同じ、イベントページを見て知った形です。（予稿集ももらってないので、本当に当日聞いて「うおー面白い！」ってなりました。）
そういった状況だったので、講演内容に関して被らないように、という点はエスパーするしかありませんでした。
自分と、miisan平田さんとの間ではたぶん被らないだろう、と思っていたので（おふたりの間ではけっこうかぶる率高そうということで気にされてたようでしたが）、正直あまり意識せずに自分の講演内容を考えました。
ただ、勝手な予想としてお二人とも事例に関する話題が多めになるだろうと思っていたので、私の講演の中では事例の割合を半分くらいにとどめて、前半と終わりはもう少し一般論や前段の広い話をするように、はしました。
事例の話を濃いめにして三者三様のを比べてもらう、のも面白そうではあったのですが、色々思うところあり今回は事例分を薄めました。このあたりの話はこぼれ話その3として別の記事にしますね。
当日の情報交換会や打ち上げなどできかれたこと
情報交換会や打ち上げなどで色々ご質問いただいたことについて、回答を残しておきます。
自動化はあまり武器として使わなかったか、違うところをがんばったのか
講演冒頭で触れたように、私もわりと「テスト自動化の人」としてやってきたので、一人目QAとして仕事をつくるにあたって自動化でグイグイ押さなかったのか、という質問と理解しました。
結論としてはその通りで、自動化を押し出すことはせず、より狭義のQAに近い動き方を選択しました。
これは単純に自分がテスト自動化が好き・得意だからといって全部そちらに寄せていくのは良くないと思ったのが一つ。 それから、せっかくQAやるんだから、経験ない施策でもチャレンジするいい機会だ、と考えたのがもう一つです。
ただ、自動化を全く使わなかったわけではありません。入社時点でmablが導入されていたので、まずは「そのmabl運用自分巻き取りますよ！」と手をあげて、自分の仕事にしました。 そして、各開発チームにヒアリングする際などに「テスト自動化ツール契約済のがあって、もし興味あったら説明とかデモとかできますけど」という形で、やりとりのきっかけとして自動化を活用しました。
また、そこで興味もってくれたチームに対しては実際に自動テストを入れていきました。 このときも、テスト自動化を推進するうえでの正論（目的を明確にして自動化すべし！シナリオ作りすぎない！など）は強く主張せず、もちろん後でデメリットが大きいところは防ぎつつも、一旦は開発チームのやり方に合わせて比較的自由度を持ってつかってもらうことを優先しました。
このように、QAとしての自分が「相談持ってくとちょっと良いことある」と思ってもらえる材料として自動化を使いました。
TMMiとかTPI NEXTとか使わなかったのか
QAクライテリア、に関する話でTMMiやTPI NEXTでなく自前で作ったのはなぜか、という質問もいただきました。
これもGood Questionで、考えました。最初。ただすぐ脳内却下しました。
というのも、いろいろヒアリングしていくなかで、
- たとえばTPI NEXTあてたら結果があまりよくなさそうだな、と思った
- そもそもプロセスが固まっていないから当然
- 外から持ってきた仰々しいものが受け入れられる文化かどうか不明
という、要するに懸念のほうが大きかったからです。
ある程度内部の実態に即したものを自前で作ったほうが受け入れてもらいやすいのではと考えた、のがTMMiやTPI NEXTなどを使わなかった理由です。
クライテリアで赤（できていない、という判定）ばかりになったりしないの？
これは上記のTMMiやTPI NEXT使わなかった理由と関連しますが、赤ばっかりにならないように作りました。 つまり、各チームにヒアリングして大体何ができていて何ができていないかの雰囲気レベルでは掴んでいたので、全体平均およそ60%くらいの達成度になるようにQAクライテリアを設計した、というのが実態です。
ダメなところばかり指摘されてもやる気にならないですが、かといってご機嫌取りをするつもりだったわけでもありません。 ちゃんとできているところを、そのとおりに可視化することも大事だと考えました。
記事いっぱいかいてるけどどうやってるの
講演内容と直接関係ないことも質問いただきました。（ぜんぜんウェルカムです）
記事とかいっぱい書いてるよね、と言っていただいたのですが、これはたぶんイメージ戦略もあります。とネタばらしするとあまり戦略みがなくなるのですが・・・
たくさんアウトプットしているように「感じさせる」ことって意外と難しくなくて、ある短期間頑張るだけでイメージを持ってもらえたりするんですよね。
たとえば私はJaSST Kansaiの講演準備もあって、５，６月はほとんどWebメディアの記事を書いていません。が、それ以前に月4本とか書いていた時期があったので、「いっぱい書いている」というイメージを持ってもらえているようです。
なので、おそらく思われているよりはいっぱい書いていない、です。実は。
ただそれだと質問の答えになっていないので真面目な回答もすると、単純に日々記事を書いている（＝時間使ってる）というのが答えで、日々家事などが終わった23時から書いてます。
あとは沢山書いているとだんだんペースが早くなったりやり方がつかめてきたり、ガーッと書き上げたものに対する校正コストが低くなったり、はあるかもしれません。 （このブログは個人ブログなので、JPEG撮って出しならぬMarkdown書いて出しです！）
緊張してなさそう、どのくらいで慣れるんですか
発表に関して、緊張してなさそうと言っていただくこともあります。
緊張は間違いなくしているのですが、緊張をやわらげようとかコントロールしようみたいなことを考えなくてよくなった、が正確かもしれません。 緊張はしているけれどもそれはさておいて、で話せるというイメージですかね。
具体的に＊回登壇したら平気になりました、みたいなのはなく・・・
ただ、経験が効くのは間違いないです。
一度100人の前での発表を経験していれば、50人の前での発表も「やったことあるし」という気持ちで落ち着いて臨めるようになります。 また、回数をこなすと「場に慣れる」のに加えて「思っていたよりみなさん優しい」ということがわかってきます。
つまり、緊張はしつつも前に立って喋れば、終わってから「よかったです」とか「役に立ちました」とか言ってもらえるので、前も良い反応してもらえていたし今回もきっとなんだかんだ大丈夫だろう、という安心感が芽生えてくるのは大きいと思います。もちろんそれで油断していい加減な発表したらダメですけど。
発表が上手い下手の前に、雑にやってるか・その人なりに努力して臨んでいるかは聞き手に必ず伝わるので、そこさえ間違えなければきっと大丈夫、と思ってます。
最後、本会参加者の皆さんへ
ここがこの記事の一番大事なところです。
基調講演させてもらって、前に立って話していて、非常に、とても、すばらしく、話しやすかったです。し、私自身話していて楽しかったです。
もちろん実行委員のみなさんやスポンサーの皆さんの尽力あっての会なわけですが、いち講演者としては聞き手の皆さんにまず感謝したいです。
こちらが話しているのに対して、うなづいたり、わかるわーという顔をしてくれたり、くだらない冗談にもニヤッとしてくれたり、という方がたくさんいて、聞いてくれている方のそういった反応は講演する側には全部見えてるので、本当に助かりました。ありがとうございます。
「QAの仕事をつくる」という話をしましたが、「JaSSTの空気をつくる」のはほかでもない参加者の皆さんで、話す側からすると参加者の皆さんのつくった空気は最高でした。時間巻き戻してもう一回やりたいくらいです。
ということで繰り返しになりますがありがとうございました！