きょんさん怖い

(出囃子)

adventar.org


(枕)

えー、毎度ばかばかしいお笑いを一席申し上げます。
世の中には「怖いもの」というのがございますな。幽霊、高所、あるいはスプリントレビュー。人それぞれ怖いものは違うもんでして。

(本編)

ある日のこと、いつものアジャイルコミュニティの常連たちが集まって、酒を飲みながら「何が怖いか」という話をしておりました。
「おい、お前は何が怖い?」
「俺か? 俺はAckyさんだな」
「えっ、Ackyさん? あの人はニコニコして楽しそうじゃないか」
「それが怖いんだよ。あの無邪気な顔をして、とんでもなく鋭いことを言ってくるだろう? 『なんでそうなんですか?』って純粋な目で聞かれると、心臓が止まりそうになるんだ」
「なるほど、無邪気な鋭さか。お前はどうだ?」
「私はびばさんですね」
「びばさん? 優しい人じゃないか」
「いやいや、ふりかえりの時だよ。あの人が腕を組んでこっちを見てると、『それ、本当にKPTですか?』『本当に問題に向き合ってますか?』って厳しいことを言われそうで……背筋が凍るよ」
「違いない。そっちの隅で震えてるお前は?」
「……お、俺は、のりっくさんだ」
「のりっくさん? 何されたんだ?」
「何もされてねぇ。ただ……存在が怖い。そこにいるだけで圧倒されるオーラがあるんだよ」


みんなが「あるある」と頷いている中、一人だけ涼しい顔をして茶をすすっている男がいます。
「おい、さっきから黙ってるが、お前には怖いものなんてねえのか?」
「へっ、Ackyさんだのびばさんだの、そんなもんが怖くてエンジニアやってられるかってんだ。俺にゃあ怖いもんなんて何もねえよ」
「強がりを言うなよ。本当はあるんだろ?」
「ねえよ。phpカンファレンスだろうが、XP祭りだろうが、testingOsakaだろうが、どこへでも行ってやるよ」
「へえ、気に食わねえ野郎だ。じゃあ、本当に怖いものはないんだな?」
男は少し言いよどんで、ガタガタと震えだした。
「……実は、ある」
「ほら見ろ! 一体何が怖いんだ?」
「……きょんさんが、怖い」
一座は顔を見合わせた。「きょんさん?」
「ああ……きょんさんは怖い。いろんなところにいて、なんでも知ってるんだ。アジャイルも、テストも、プロダクトマネジメントも……すべてお見通しだ。それに、批判的な意見もすごく率直に言ってくるだろう?」
「まあ、確かに鋭い指摘はするな」
「しかもだ! 優しい口調で教えてくれるんだよ。みんな尊敬してる。尊敬してるんだけど……本当に怖いんだ! あの笑顔で『ここはこう考えるといいですよ』なんて言われると、自分の底の浅さを見透かされたようで……ああ、思い出しただけでスクラムフェスに行くのが怖くなってきた! もうダメだ、俺は向こうの部屋で布団かぶって寝る!」
男はそう言うと、隣の部屋へ逃げ込んでしまいました。
残された連中は顔を見合わせてニヤリとしました。
「へへっ、あいつ、きょんさんが怖いと言い出しやがった」
「いつも偉そうなこと言ってるからな。ここらで一つ、目にもの見せてやろうじゃないか」
「どうするんだ?」
「決まってるだろ。あいつの部屋に『きょんさんの登壇動画』を流し続けて、枕元には『きょんさんの書いた記事』を山積みにし、極めつけに『きょんさん本人』をZoomで繋いでやるんだ」
「そいつはひでえ! 早速やろう!」

連中は手分けして準備を整え、男が寝ている部屋にきょんさん(の知見)を充満させました。

そして、Zoomをオンにする。
「……ん? なんだこの気配は……」
男が目を覚ます。
「うわあっ! きょんさんだ! こっちにはアジャイルコーチのきょんさん、あっちにはシステムアーキテクトのきょんさん! 画面の中からもきょんさんが話しかけてくる!」
外で聞いている連中は「ざまあみろ」と大笑い。
「ほら、怖がってる怖がってる!」
ところが、部屋の中の様子がおかしい。
「あぁ、怖い! なんて鋭いフィードバックだ! 怖い! ……でも、この指摘は的確だ。うまい!」
「うわあ、こっちのサーベイの結果も怖い! 怖いけど、腹落ちする! 栄養になる!」
「もっとないか! もっと怖い話はないか!クリストファー・アレグザンダーは、質と生命力が宿る「構造」を追求し、その本質を追求する15の生命特性を定義したんだ!それを実現するためにパタン・ランゲージという生成的なプロセスを提唱して、このプロセスを通じて、小さな変化を積み重ね大きな変化を起こし、人間が良いと感じる「生き生き」とした「構造」に宿る真の秩序を創出していると主張している!この思想は、ソフトウェアデザインパターンという考えを発端として、XPをはじめとするアジャイル開発の源流となる考え方に大きな影響を与えたとされているんだ!こういった背景を踏まえてきょんさんはパタンランゲージの現代化が継続的に起こっているグローバルなトレンドを追いつつ、それをソフトウェア工学界隈で上手く扱う必要があるという問題意識を説き続ける第一人者として、啓蒙している。ああ、この知見の深さがたまらなく怖い! 私の解釈だと、アレグザンダーは「普遍的な質(善いものといえるかも)」「生命のような生成する何か」そしてこれを人間として、実践的に「作る」ことをパターンとしてあくまで実践的に残したことは、今後我々がさまざまなシステムを作っていく、あるいは品質文化というものを考えるにあたって示唆的なものだと思うんだ。ただ、私自身はまだ腹落ちせず、現実に当てはめて考えられていないところがあって、すごく難しいと感じています。そうやってきょんさんのブログとか見ると、何年も前からnature of orderを読んでたりして、きょんさんの底知れなさには感服するしかないと感じてむしゃむしゃ(知識を吸収する音)」
外の連中は驚いた。
「おい、あいつ怖がってるふりして、きょんさんの知見を吸収してやがるぞ!」
「騙された! あいつ、本当はきょんさんの言ってることが大好物なんだ!」
連中は腹を立てて、部屋の戸をガラリと開けました。
「おい! 貴様、きょんさんが怖いなんて嘘をつきやがって! 俺たちを担ぎやがったな!」
男は満足そうな顔で、パンパンになった頭(知識)をさすりながら言いました。
「へへっ、あまりに学びが多くて、つい夢中になっちまった」
「この嘘つきめ! お前が本当に怖いものは何なんだ!」
男はニヤリと笑って、こう答えました。
「このあたりでそろそろ、nacoが怖い」
(おあとがよろしいようで)

お前はテスト計画書を書け 〜テストエンジニアのキャリアに対する閉塞感を打ち破る簡単な方法

ネットミームで「お前は東大に行け」というのがありますね。

私はこう言いたい時があります「お前はテスト計画書を書け」。

 

「バカとブスほど東大に行け」という言葉が元ネタです。

 

なら私もこう言います「自信がないならテスト計画書を書け」

 

テスト計画書とは、ただ単にスケジュールの検討ではないです。

 

「このコンテキストでどんなテストが必要か」を検討するものです。

 

あなたの現場にテスト計画書はありますか?

 

ないのならば書きましょう。

 

別に誰に見せなくてもいいです。ただ「考えた」という経験が、テストエンジニアとしてのあなたの経験値を引き上げます。

 

この経験は転職の際の面接対策にもなります。

 

あなたが今テスト計画書を書く立場ではなく、今後そうなりたいと思うならば、

 

「本来こうあるべきだと思ったが現実はこうだった」「そうなったのはこういう制約だからだ」

 

という話ができると思います。

 

私はあなたのその感性や言語化を強く評価します。

 

「今の会社ではやりたくないが、やりたいプロダクトがある」

 

それならなおさらテスト計画書を書いてください。

 

まずは手元のメモ帳とかで書いてみるといいでしょう。

 

それベースにをgithubでもzennでもnoteでも書いてみてはいかがでしょうか。

 

わかるエンジニアなら、その状態で書いたテスト計画書が完璧であるかどうかより、テスト計画書を作る過程でどのように考えたかを評価するはずです。

 

「テストの実力をつけたい」と思っているお前。

 

テスト計画書を書け。

 

メモ帳でいい。

3行でもいい。

ふせんでもいい。

 

なんなら「書」である必要すらない。

思考過程を録音するだけでもいいだろう。

 

お前はテスト計画書を書け。

 

俺も、書く。

 

この記事は「ソフトウェアテスト・QAの小ネタ Advent Calendar 2025」2日目の記事です。

qiita.com

初心者テストエンジニアを卒業するためにおすすめしている7冊の本-2025

はじめに

この記事は株式会社カオナビ Advent Calendar 2025の1日目の記事です。

テストエンジニアの"初心者"の定義

テストエンジニアの初心者とは、実はJaSST21Kyusyuであきやまさんが言及しています。

www.jasst.jp

私は中級者にあたるのですが、初心者であるテストエンジニアたちに「こんな本を読んだらそろそろ中級者への道が開けるよ」という観点で紹介したいと思います。

「これを読まないと中級者ではない」、「ゴールとして書かれているJaSST nanoの発表ができない」というわけではありません。

ただ、初心者卒業したいな〜くらいの人におすすめしたい本を7つ紹介します。

今回選ぶ7冊は2025年時点で私が考えるセレクションです。

テスト本

体系的ソフトウェアテスト入門

最初に紹介するのは現在絶版となっている可能性が高い書籍で恐縮ですが、内容は古びていません。図書館や電子版などを利用するといいかもですね。

もし見つけられたらぜひ読んで欲しい一冊です。

初心者から中級者にさしかかるころ、おそらく「テストマネジメント」という言葉を意識せざるを得なくなっていると思います。

テストマネジメントの知見が得られる本は正直少ないです。

 

そんななか、IEEEに採用されたテストマネジメントを体系的に学べる本となっています。

出版は20年以上前ですが、テストマネジメントの普遍的なエッセンスは現代のコンテキストにおいても変わらず応用可能です。

 

中級者となれば、現代と違ったコンテキストからエッセンスを抽出し、理解することができるようになっているはずです。

ぜひ、IEEEで制定された技術的背景を理解して、「ただ技術を実践する」ではなく、「必要に応じて課題解決する」という、もう一段視野を広げた活躍をして欲しいと思います。

Effective Software Testing

洋書です。すみません。

開発者視点から見たソフトウェアテストの考え方や手法について体系的に学べます。

中級レベルになってくると、例えばひとつのテストレベルだけでなく、全体から考える必要があります。

時にはプログラマー目線でのテストの知見が必要になることもあります。

そういったときに、この本を読んでみて、プログラマーとしてどのようなテストができるのか、プログラマー目線で、どのようなテストが効果的なのかを想像できるようになってほしいです。

そうすれば、開発者と協働できる、一段上のテストエンジニアになれると思います。

品質本

ソフトウェア品質知識体系ガイド

BOKです。すみません。

"ソフトウェア品質保証"という分野において、例えばJSTQBで扱っているテストはごく一部だと知ることができます。

中級者となれば、さまざまな現場や現象に出会うと思います。

そんなときに、この本を頭に入れておいて、「どんな状況でこんな技術を使えばいいんだ」とインデックスを作っておくことに役に立ちます。

 

また、可能であればJCSQE試験に出ないような序文やエッセイじみた文章も読んで欲しいです。

そこにはソフトウェア品質保証の本質が詰まっています。

データ指向のソフトウェア品質マネジメント

中級者のテストエンジニアは飯塚先生の本をはじめとした日科技連の本は大抵目を通していると思います。

それらをきちんと理解した上で、また「データ」というものに触れるのもありだと思います。

 

ソフトウェア品質保証において、特にいわゆるテスト界隈ではメトリクスについて否定的な人も少なくありません。

私も同じように感じる部分もあります。

 

一方で、データという事実を用いた意思決定についてはテストエンジニアとして向き合うべきだと考えます。

 

この本ではデータと品質の結びつきをどう考えるか、その試行錯誤が見て取れます。

ソフトウェア開発

Googleのソフトウェアエンジニアリング

Googleのソフトウェアエンジニアリングが常に正しく、どんな現場でも適切ということはないですが、一つのケーススタディとして、ソフトウェアエンジニアリングで考えておくべきモダンな考え方が記載されていると思います。

テストや品質の接合点も多く、初心者から中級者に上がる過程で必ず押さえておきたい本だなと思っています。

入門 継続的デリバリー

DevOpsが当たり前になった時代ですが、それでもCDの重要さとその技術的背景について知っておくことは、テストエンジニアとして学んでいく上で極めて重要になります。

特にCI/CDが開発に何をもたらし、何のために存在するのか。

CI/CDと自動テストは同時に語られることが多いです。

その時、CI/CDの背景を理解し、制約を認知した上で自動テストを計画することは非常に重要です。

 

CIは開発における当たり前となりつつありますが、重要なインフラでもあります。

しっかり理解しておくことを推奨します。

作る、試す、正す。

中級テストエンジニアになったころには、アジャイルといった考えにもある程度触れていると思います。

そんな中で、より深く「仮説検証」であったり、「我々は何を作るべきなのか」自体を考えるプロセスに習熟する必要が出てきます。

「誰かに言われた仕事をする」「何かのカタを守る」という段階は過ぎているかもしれません。

そんなときに、どのように仮説を描き、試していくのか、これらについて考える必要があると感じ、この本を推薦しました。

さいごに

私は中級になりたいテストエンジニアに対してテスト本は2冊しか紹介しませんでした。

これには個人的な思いがあって、あえてそうしています。

「テストのことばかりではなく、もう少し隣り合った領域も見ておいた方がいい」ということです。

私はソフトウェアエンジニアとなって7年くらい経ちましたが、一見繋がっていないような知識が現実に適用したときにつながることがあります。

そんなとき、私は「楽しい」と思っています。

これは私が7年もエンジニアを続ける原動力になっていますし、私はみなさんにそれを体験して欲しいと思っています。

ただ知識をつけてスキルを伸ばすのではなく、そういった現場の日常での発見や気づきはエンジニアだからこそたくさん体験できる宝物だと思っています。

それは「知識と知識のつながり」で簡単に起こりうると考えています。

 

さいごのさいごに

ソフトウェアテスト読書マップにはたくさんのテスト本があると知れるのでぜひ見てください!

docs.google.com

ほんとのさいごに

あきやまさんのゴールだとJaSST nanoで登壇しないと中級者になれないと知ったので、近々復活させたいです。

 

テスト自動化カンファレンス2025予告: 設計原則「関心の分離」からPage Object Modelを学ぼう

はじめに

テスト自動化カンファレンス2025に採択されました。ありがとうございます!!

testautomationresearch.connpass.com

前回やったと同じように、Confengineの「プロポーザル」形式で発表内容を事前に公開します。

これは現状作っているスライドの内容から作ったもので、実際に提出したプロポーザルの記述と異なる点をお気をつけください。

ただ、当日発表する内容はプロポーザル記述に沿った内容を踏まえたもので、だいたい同じです(だと思っています)。

「こういうプロポーザルを出したから採択される」でもないですし、「こういうプロポーザルを出さないと採択されない」でもないです。

この記事を出す意図は、事前に私の発表を、スクラムフェスと同じくらいに完全ネタバレしておくことで、聴講者の方の理解を深めたり、期待を揃えることです。

設計原則「関心の分離」からPage Object Modelを学ぼう

Overview

「AIが書いたから安心」といってE2Eテストコードを書いている人、ヤバいです。

WebのE2E自動テストにおける代表的なパターンであるPage Object Model (POM) は、ソフトウェア設計における重要な概念である「関心の分離」や「単一責務の原則」を実現したものとなっています。

しかし、昨今の生成AIの普及により、POMの構造を単に模倣した「ポチョムキン理解」によるコードが大量に生成されるようになったと考えています。

これらのコードはPageとテストで分離されているように見えます。

しかしながら、本質的な設計原則を欠いているため、修正コストがかかったり、テストの内容が不明瞭なテストが大量に生成されるという深刻な問題を引き起こしています。

 

テスト自動化エンジニアのみなさんとこの問題を共有し、一緒に対処する方法を考えたいと思っています。

 

本セッションでは、具体的なコードのアンチパターン(Page Object内でのアサーション、巨大クラス化など)に指摘を入れながら、POMとソフトウェア設計の基本原則である「関心の分離」「単一責務の原則」の関係を掘り下げます。

「設計思想を理解すること」の重要性と、それによって発揮できる「批判的なレビュー能力」を養うことを目指します。

Outline/Structure of the Talk 

  • 導入:生成AI時代のテスト自動化現場で起こっていること 
    • 敏腕リーダーの指示と生成AIコードの単純受容によって生じる現場の課題提起。
    • 「修正が終わらない」「何をテストしているかわからない」の原因。
  • 根源への回帰:普遍的な「設計原則」の説明
    • ソフトウェア設計原則(SWEBOK参照)の定義。
    • 核となる原則:「関心の分離」と「単一責務の原則」のテスト自動化における解釈。
  • POMの解説とアンチパターン考察 
    • POMの本来の目的:「テストの関心事(What)」と「ページの関心事(How)」の分離。
    • 生成AIが陥りやすい「ポチョムキンPOM」の解説。
    • 具体的なアンチパターン事例(Page Object内のアサーション、巨大クラス、密結合など)とその問題点。
  • テスト自動化エンジニアとして我々はどうしていくか
  • まとめ 

Learning Outcome

本セッションに参加することで、参加者は以下の知識と能力を獲得できます。

  • Page Object Modelの単なる構造ではなく、その背後にある「関心の分離」の設計思想を深く理解できるようになります。
  • 生成AIが生成したE2Eテストコードに含まれるポチョムキンPOMを見抜き、そのコードが保守性の低いアンチパターンであると指摘・修正できるようになります。
  • テストコードのレビュー時、「なぜこのパターンを採用すべきでないのか」を設計原則に基づいて言語化できるようになります。

Target Audience

  • 生成AIを利用してE2Eテストコードを書き始めた/書こうとしているテストエンジニア。
  • 自動テストコードのレビューをしていて、「何かおかしい」と違和感を持ちつつも言語化できていないエンジニア。
  • テスト自動化のデザインパターン(POMなど)を、より高い保守性と汎用性をもって活用したいと考えている全ての方。

Prerequisites for Attendees

  • Playwright、SeleniumなどのWeb E2Eテスト自動化ツールがあると知っていること
  • テスト自動化におけるPage Object Modelがあると知っていること
  • ソフトウェアエンジニアリングというものが存在することを知っていること

QAの私がpmconf2025大阪で感じたPMとの違い

はじめに

これは個人的に心に浮かんだ内容を言語化するものであり、QAやプロダクトマネージャー(以下、PM)というロールを一元的に定義するものではありません。プロダクトマネージャーカンファレンス2025大阪に参加して感じた、個人的な(いい意味での)違和感を言語化してみます。

2025.pmconf.jp

PMとQAの類似点

私は普段から、PMとQAは近しい存在だと思っています。

この意見に対して、QAを単なる「テストの担い手」と捉えると遠く感じると思います。

 

しかし、例えば品質を「顧客満足」と定義し、QAエンジニアはその実現を目指す人々だとして捉えれば、QAとPMは同じ目的を共有していると考えます。

また、TQMの分野では事業継続自体も顧客満足の達成の一部と捉えます。

今回pmconfに参加して、やはり「我々は同じ目的でここにいる」という思いを改めて強くしました。

語られ方の違い:可能性と不確実性

一方で、セッションを聞く中で「語り口」に違和感、違いがあるとも感じました。

あくまで私の観測範囲での印象ですが、両者には次のような違いがあるように思います。

「PMは未来の『可能性』を最大化し、QAは現在の『不確実性』を最小化する」

もちろん、これには異論があると思います。

リスク管理もPMの仕事だ」「未来志向のQAもいる」という意見はあると思います。

実際にそういった友人はたくさんいます。

私自身がテストをバックグラウンドに持つQAだからこそ、過度にリスク管理(不確実性の排除)にフォーカスして聞こえているのかもしれません。

 

ただ、私自身はこの気づきについて、PMとQAが違った専門性やマインドを持ち協働していくことのヒントになると、前向きにとらえています。

おわりに

今日まで私は「PMとQAは同じだ(同じであるべきだ)」と思っていました。

しかし今は「違うからこそ我々は一緒に補い合える」と思っています。

PMが可能性を広げ、QAがその不確実性を潰していくという専門性の違いがあるかもしれません。

この「違い」があるからこそ、互いにサポートし合い、より建設的で強いプロダクト作りができるのだと考えました。

Tokyo Test Fest 2025に受付として参加してきました

はじめに

Tokyo Test Festに参加してきました。

tokyotestfest.com

とにかくエネルギーに満ち溢れていて、元気をもらえるイベントだと感じました。

昨年に引き続き、会場の雰囲気、セッション、廊下で交わされる会話など、すべてがポジティブなエネルギーとして渦巻いていました。

「英語」が生むサウンドとハーモニー

このカンファレンスの共通語は「英語」です。

今回は日本語トラックと英語トラックがあったのですが、この二つを聞いて気づいたことがあります。

飛び交う英語には、日本語にはない多様な「アクセント」や「イントネーション」があるということです。

私はこれを「サウンド」として捉えました。日本語にはないさまざまな音が混じり合う空間そのものが、新鮮であり、サウンドとして非常に心地よかったと感じることができました。

昔、面白半分でMesut(メスト)氏に「聞いてみる」という企画をした時のことを思い出しました。

JapanTestCommunityとTokyoTestFestに対する疑問に全部答える会 - connpass

この時、メスットは「ハーモナイゼーション」という言葉を強調していました。

これはもちろん、異なる背景を持つ人々が交流することによって起こる新たな価値のことです。

ただ、日本語と英語が混ざり合う空間でのサウンドとしてのハーモニーが、ある種Tokyo Test Festを象徴していると感じたのでした。

英語が得意じゃなくても堂々としよう

私はXやSlackなどで「英語に自信がないけど参加している」とポストしました。
あれは実は、昨年Tokyo Test Festに参加していたからこそ言える、冗談のつもりでした。

もちろん、英語を自由自在に使える方が、何倍も楽しめるのは間違いないでしょう。

しかし、「英語が得意じゃないから」という理由で、この熱量の高い空間に参加することをためらう必要はまったくないと、私は思います。

「この空間を共有したい」「一緒に学びたい」という意志があるなら、堂々としていればいいと思います。

英語が得意じゃなくても、Tokyo Test Festは、その意志を尊重し、その人の持つ多様性を受け入れ、歓迎してくれる場だからです。

受付で感じた「多様性」

今回も私は受付のボランティアを担当していました。
そこで感じたことに、強烈に心を打たれました。

受付スタッフのボランティアメンバーの多くが、「名簿に書いてある日本人の参加者の漢字が読めない」人がいたのです。

これは「準備不足」のイベントだった、などという話では断じてありません。 全くの逆です。

日本語の読み書きがネイティブではない。そんな状態であっても、これだけの熱意を持って、「あえて日本で」「国際的なカンファレンスを」実現している。全力で動いている人たちがいる。

その事実、その熱意に、私は深く心を打たれました。

一昔前、こうした動きは「グローバル化」という言葉で語られていました。
しかし、私があの場で感じたのは、もっと生々しく、温かい「多様性」そのものでした。

さまざまな背景を持つ人々が、イキイキと活躍できる空間。
その理想を実現するための「手段」のひとつとして「グローバル」がある。 Tokyo Test Festは、まさにそれを体現していたと感じます。

おわりに

Mesutに誘われたので、来年から正式なスタッフとして参加したいと思います。

ただ、今回の体験を受けて、この熱意を、この素晴らしい場を、これからも全力でサポートしていきたいと強く思いました。

もし、この記事を読んで、この思いに共感してくれる人がいたら、ぜひ私に声をかけてほしいです。

来年、あの熱量の中で一緒にこの「場」を作っていきませんか。

かけだしQAの壁(LT会)@QAブリッジに参加してきました

はじめに

以下に参加してきました。

qabridge.connpass.com

私は先輩QAとしての責務を果たすべく、例のお菓子を配ったのですが、ブログも書こうと思ったので書いておきますね。

このコミュニティは、「最も参加ハードルの低いQAコミュニティ」をコンセプトに掲げています。
その言葉通り、今回のイベント「かけだしQAの壁」では、「今日が社外イベント初参加です」という方が多かったのが、印象的でした。

参加してみて、QAブリッジにおける巧みな仕掛けと、私が感じるコミュニティの本質的な価値に通じるものがあると気づきました。

「先輩」という役割

今回、イベント参加時に「駆け出し」と「先輩QA」という役割があえて明示されていました。

私は「先輩だから教えなければ」とは思わないようにしました。

むしろ逆で、「自分から話すのではなく、まずは彼ら(かけだしQA)の話を聞こう」「求められた時だけ、自分の経験を答えよう」という、「聞くに徹する」スタンスを取りました。

これは、私が駆け出しの時に感じていた「壁」そのもので、「自分の話を聞いて先輩QAに説教されたらやだな」と思っていたことを思わないように、できるだけ肯定的なリアクションをするようにしました

イベントはLT(ライトニングトーク)だけでなく、対話の時間が意図的に作られていました。

そこでは「教える」先輩と「教わる」初心者、という一方通行の関係は生まれていなかったと思います。

「聞く」スタンスの先輩の存在が、結果として「何を言っても大丈夫だ」という場のハードルの低さを作り、参加者一人ひとりが主役となって「話せる場」として機能していたように思います。

「初めて」の方々が、萎縮せずに自分の悩みや経験を率直に口にできていたのは、この構造がうまく働いていたからだと感じています。

「生きづらさ」と「引き返せる」自由

少し個人的な話をします。 私は、「社外に出たらとにかくいい」「コミュニティに参加すべきだ」といった、一元的な意見にはあまり賛同しません。

ですが、会社という「内側」とは違う「社外」という場所が、日々の業務で感じる「言語化できないモヤモヤ」や、時に「生きづらさ」にまで繋がるような悩みに対して、前向きに向き合うヒントを与えてくれる場であることは確かだと思っています。

そして、社外コミュニティの最大の強みは何か。

それは、「違うな」と思ったら、明日から参加しなくても誰にも怒られないことだと思っています。

「引き返せる自由」こそが、「最も参加ハードルが低い」ことの正体だと思っています。

合わなければ、そっと離れればいいと思っています。