社内に閉じこもっていたエンジニアが社外エンジニアコミュニティに参加するためにやったこと

概要

この記事は食べログアドベントカレンダー2022 の23日目の記事です🎅🎄

はじめまして、食べログシステム本部のDeveloper Productivityチームでテスト自動化ユニットのリーダーをしているSoftware Engineer in Test (SET)のhagevvashiと申します。

1年前の私のように社内に閉じこもっているけど外の世界に憧れをもっている方が、この記事を読んで今日からアクションを起こしてもらえるよう、私が1年間でやったことを3STEPに分けて振り返ります。

これは著者が実施した3つのステップを説明した画像です。

背景ときっかけ - Developer Productivityチームの爆誕とSETへの転身

私は食べログで2018年3月から3年3ヶ月の間フロントエンドエンジニアとしてプロダクト開発やリプレースを行っていました。その間は長らくコミュニティの人になることへ憧れを抱いていました。今だからこそ「飛び込んでみればいいじゃん」と思うのですが、当時はどのように動いたらよいのか全く分かりませんでした。

勉強会での発表の自己紹介で勉強会の運営や研究会、OSSへのコントリビューション、書籍の執筆などの社外コミュニティ活動を伝えてらっしゃる方々を見てシンプルに格好良いと思っていました。格好良いだけでなく、業界での自身の立ち位置を伝えた上で発表を始めると聞いてる側も内容を理解しやすい点は重要ですね。また、発表されている方々やイベントを運営されている方々は他の勉強会や他の登壇者ともネットワークがあるように映っていて、あの中に入るとお互いに切磋琢磨して最新の情報の共有が日々活発にやり取りされているのだろうと映っていました。

そして勉強会の発表内容やブログ記事にはいつも圧倒されていました。発表や記事の一つ一つが聴き手や読み手が何か持って帰れるものがあり、聴き（読み）始めてから終わるまであっという間に感じられました。また、OSSへのcommitやライブラリ・サービスの開発なども一つのコントリビューションだと思います。今でもフロントエンドの技術スタックのことは大好きで勉強会に参加したりしていますが、皆様OSSへのcommitや個人開発の実績をお話しされていて技術力の高さに圧倒されてしまいます。

なぜ飛び込むことができなかったのかと振り返ってみると、自分ができることを伝えるのではなく理想を追っているだけだったこと、独力で1から10まで全てやったことしかアウトプットできないと思っていたこと（得手不得手や役割という考え方が欠如していたこと）、社外エンジニアコミュニティにいる方々を神格化し、自分が話しかけてはいけないと思いこんでいたこと、そのせいでゴールが見えない中一人前になるまでは闇雲にインプットを続けようと思ってしまっていたこと、などが挙げられるかと思います。

そんな私が変わるきっかけとなったのは仕事の進め方の変化でした。3年3ヶ月のフロントエンドエンジニアとしての活動を通してソフトウェアテストに対する漠然とした課題に気づき、解決の一歩目として2019年にJSTQBのFLを取得しました。そのことがきっかけで2021年6月、QAチームの立ち上げで声をかけてもらいSETへと転身しました。（その後QAチームは2021年9月にDeveloper Productivityチームに名前が変わっています。）

SETとして参画した技術部はOKRを使って仕事をしています。OKRを利用している技術部には、小さくてもできたことを伝えて褒め合う文化が根付いていました。「できたことは何か」、「それによって誰がどう嬉しいか」を軸に考えるようになったことで、「自分にできることは何か」、「次の課題を解くためにはこの人に話を聞こう」と思えるようになりました。頭でっかちに理想だけを追うことや独力でやりきることに対する盲目的なこだわりが消え、闇雲にインプットするだけに留まることが減りました。

社外エンジニアコミュニティに参加するためにやったこと

STEP1: 社内で発表〜社外のトークセッション型勉強会へ登壇

これは社内で発表から社外のトークセッション型勉強会へ登壇の説明をこれから開始することを表現した画像です。

チームデモ・社内勉強会で発表

最初から社外エンジニアコミュニティでの活動がイメージできていたわけではありませんでした。SETとして技術部で仕事をするようになってからは、まずはテスト自動化の基盤作りを成功させることに専念していました。また技術部での仕事では、誰にとって何が嬉しいのかを動くもので伝えることの楽しさを覚えて、毎週何かしら動くものをデモすることに没頭していました。2021年9月〜10月頃、社内で隔週で開催しているTabelog Tech MTGでデモ発表を行い、それを見たテックリードの荻野から社外での登壇の提案をしてもらったことがきっかけで社外での登壇を本格的に計画し始めました。まずは成果を作る、そしてその結果社外エンジニアコミュニティに還元できるという流れがあるので、まずは焦らず最初の成果を作り込むところにフォーカスしたことが次に繋がりました。

記事執筆

社外登壇の計画を本格的に開始した当時はテスト自動化の基盤が完成し、テストケースを実装し始めていました。テスト自動化の導入をテーマに、半年後に開催されるDevOpsDays Tokyo 2022を目標に登壇活動をスタートしました。

DevOpsDays Tokyoは毎年200名程度が参加するDevOpsについての国内最大級のイベントで、モブプロの創設者や「リーンとDevOpsの科学」の著者といった海外のDevOpsのソートリーダーが基調講演をしています。このイベントに登壇するためには、発表概要を投稿した上で投票および運営委員の選考を通過しなければいけません。ですので、登壇者として選考してもらうためには過去の実績が非常に重要になります。

発表概要の作り込みと並行して実績作りの1歩目として社外公開の記事執筆を行いました。社内での発表と社外に向けの発表で大きく違う点は、社外向けの内容では再利用できるように事例の抽象度を上げる点です。再利用可能な形にまとめ上げた結果がLearning Outcomeになります。Learning Outcomeを考えることは私にとって初めての挑戦ですので苦戦しました。最初に考えたLearning Outcomeは、発表者視点の表現の多用、「大規模な」や「歴史が長い」という曖昧な言葉の使用、Target Audienceとの一貫性の無さと言った点で、この発表で何を持ち帰ることができるのか分かりませんでした。その後、聴衆に寄り添った表現の使用、曖昧な言葉の回避、Target AudienceとLearning Outcomeの一貫性に気をつけ改善を繰り返した結果が提出済みのものとなります。

＜初稿＞

これは画像です。

＜提出版＞

これは画像です。

テスト自動化の導入をテーマに公開した記事はこちらです。

https://qiita.com/hagevvashi/items/563943f67ce6e29fb934

社外の専門家とのランチMTG・トークセッション形式の勉強会への登壇

登壇実績として最初に社外勉強会へ登壇したのは、freeeさんで定期的に開催しているトークセッション型の勉強会「freee Tech Night」でした。この勉強会への登壇が実現したのは社外の専門家である山口鉄平さんとのランチMTGの場でご提案を受けたからです。食べログのテックリードである荻野からReginal Scrum Gathering TokyoやXP祭りの企画や運営をしている山口さんを紹介してもらいました。

ランチMTGは社外の専門家の方との関わりの一歩目として、私にとっては踏み出しやすかった取り組みです。山口さんとのランチMTGは、技術ブランド強化のためのアクションの相談というふわっとしたテーマでした。ランチMTGで色々とご助言を頂く中で、freeeさんで定期的に開催しているトークセッション型の勉強会に一緒に登壇しましょうとご提案をいただき、『freee Tech Night × 食べログ「何度でも食べたいテスト自動化導入の必勝レシピ」』というタイトルで2022/3/18に登壇することができました。118人の方々に参加頂く勉強会となり、「freee Tech Night」の運営の方や山口さんには大変お世話になりました。

STEP2: 社外の中規模勉強会・大型カンファレンスでの発表

これは社外の中規模勉強会・大型カンファレンスでの発表の説明をこれから開始することを表現した画像です。

中規模勉強会での発表

「DevOpsDays Tokyo 2022」への登壇に向けて発表実績を作るための発表の機会を、社内の全面的なバックアップのもと作ってもらうことができました。食べログのテックリードである荻野が他社のエンジニアコミュニティの方と連携して、300人を超えるエンジニア勉強会（「Test Engineers Meetup #4」）を企画してくれました。

「Test Engineers Meetup #4」の発表は内容が多すぎて早口になってしまった点やカンペを見ていることがバレバレである点が反省点でしたが、この反省点は「DevOpsDays Tokyo 2022」の発表に反映させていくこととなります。「Test Engineers Meetup #4」の発表で用いたスライドはこちらです。（「DevOpsDays Tokyo 2022」で発表するためには内容を大きく変える必要があったので別でスライドを投稿し直しました。）

このスライドの作成過程で様々な問題に直面しつつも改善を繰り返すことでスライド作成のテクニックが身につきました。

課題: スライド一枚一枚にテーマや目的がない → 解決策: まず、発表の概要を1枚で作り、次に、4〜5枚で発表が伝わる骨子となるスライドを作成し、最後に内容をふくらませる
課題: スライドを文章で表現してしまう → 解決策: 文章で表現することをやめ図や表を用い、文字は箇条書きで表現することを意識
課題: 文字サイズが小さく読みづらい → 解決策: 文字の最低サイズを20くらいに決める

＜改善前＞

これは画像です。

＜改善後＞

これは画像です。

大型カンファレンスでの発表

「Test Engineers Meetup #4」での反省点を踏まえ、発表スライドのページ数削減と発表内容の丸暗記を行うことで発表の完成度を上げました。その甲斐あって「DevOpsDays Tokyo 2022」での発表は個人的には満足度が高い発表となりました。「DevOpsDays Tokyo 2022」での発表後、同様のテーマで勉強会での登壇の打診を受けました（第18回 Ques 「スタートアップと品質　〜プロダクトの成長に伴う品質活動〜」、QAエンジニア勉強会～各社の取り組みや課題から学ぶ会～）。一回発表行うと他の勉強会から声をかけてもらいやすいという、登壇にはよい副産物があるということが分かりました。これらの発表で用いた資料はこちらです。（※「DevOpsDays Tokyo 2022」での発表後同テーマで2回登壇しましたがどちらもこの資料を用いました。）

「DevOpsDays Tokyo 2022」に参加した2日間では自身の発表以外に参加者、登壇者との交流も目的としていたのでその結果については後ほど紹介します。

2人での協同発表

Developer Productivityチームではテスト自動化だけではなく食べログの様々な開発生産性改善の取り組みの効果を定量的に捉える取り組みとして「品質ダッシュボード」の導入を進めており、この「品質ダッシュボード」をテーマとした発表の機会を社内の全面的なバックアップのもと作ってもらうことができました。食べログのテックリードである荻野が他社のエンジニアコミュニティの方と連携して、200人を超えるエンジニア勉強会（『緊急Ques 「食べログの品質ダッシュボード」』）を企画してくれました。発表で用いた資料はこちらです。

今回は開発チームのマネージャーである関戸と共同で発表することで、複数人での発表するテクニックを学べました。共同発表という点で私にとって新しいチャレンジであり、それが故に発表者同士が進め方がよく分からない状態に陥り、当初はスライド作成が難航しました。解決方法として ①「DevOpsDays Tokyo 2022」での資料作成経験から発表資料完成までのステップを明確にすること、②互いのアップデート内容がすぐに確認できるCI環境としてOne Driveに結合版資料置き場と、個人の作業場を作ることにしました。

品質ダッシュボードの導入においても社外コミュニティの力を借りることになりました。品質ダッシュボード導入の最初のステップは他社事例の収集です。他社事例収集先として、「Test Engineers Meetup#4」の各発表の調査、「ソフトウェア品質シンポジウム」の発表事例調査、山口さんへのヒアリングを行いました。この発表を通して、3月の「Test Engineers Meetup#4」や山口さんとのランチMTGなどの社外エンジニアコミュニティから品質ダッシュボードの社外事例を仕入れ、それを社内で成果を出した後に事例発表という形で社外エンジニアコミュニティに還元できる流れを体験できました。

登壇した勉強会一覧

私が登壇した勉強会を以下にまとめておきます。

勉強会タイトル	登壇日	参加人数
freee Tech Night × 食べログ「何度でも食べたいテスト自動化導入の必勝レシピ	2022/03/18	118人(オンライン)
Test Engineers Meetup #4	2022/03/30	325人(オンライン)
DevOpsDays Tokyo 2022	2022/04/22(開催期間: 2022/04/21-22)	96人(現地)・172人(オンライン)
第18回 Ques 「スタートアップと品質　〜プロダクトの成長に伴う品質活動〜」	2022/05/19	207人(オンライン)
QAエンジニア勉強会～各社の取り組みや課題から学ぶ会～	2022/05/24	40人(オンライン)
緊急Ques 「食べログの品質ダッシュボード」	2022/09/29	266人(オンライン)

STEP3: 社外エンジニアコミュニティに参加

これは画像です。

先述の通り「DevOpsDays Tokyo 2022」では自身の発表以外に参加者、登壇者との交流も目的としており、この交流の中でDevOpsDays Tokyo実行委員への参加の機会を得ることができました。社外エンジニアコミュニティで活躍している方との交流に対して苦手意識がある自分自身を奮起させるために「10人と名刺交換やSNS交換すること」を目標に設定し、様々な方と交流していきました。様々な方と交流していく中で何名かのDevOpsDays Tokyo実行委員の方ともお話しし、実行委員の荒井さんに社外エンジニアコミュニティ活動に憧れがあることと実行委員への参加方法などを聞いてみたところ、DevOpsDays Tokyo実行委員にお誘いいただけました。Program Committeeに名を連ねる日が来るとは夢にも思っていませんでした。

また、「緊急Ques 食べログの品質ダッシュボード」の懇親会では山口さんやプロセス品質のモニタリングの専門家の方々とDiscord上で交流しました。その交流の中でプロセス品質品質のモニタリングをテーマとした「アジャイルSQC研究部会」という研究会があることを知り、後日正式に参加者募集が開始されたので応募することにしました。1年前の自分ではこのような募集が目に入ることもありませんでしたし、見かけても応募することはなかったでしょう。これまでに成果を作ってきたこと、成果について誰にとって何が嬉しいのか説明できるようになったこと、社外エンジニアコミュニティの方々と交流してきたこと、などが自信につながって応募に繋がりました。

社外エンジニアコミュニティに参加してよかったこと

実績ができた

登壇やイベント運営などの社外エンジニアコミュニティでの活動実績は今後社外で活動する際の自信に繋がりますし、なによりアピールポイントとなります。発表やお手伝いを依頼する時に、その人の実績があれば安心してお願いができますよね。

インプットする情報の質が上がった

社外に出ていくとインプットする情報の質がいきなり変わります。自分で膨大な量の情報から必要なものを選ぶのは難しいですよね。社外に出ていくことで得られるようになる情報は、その道の専門家が選んだ情報なので、鮮度が高く質のよい情報に絞られてきます。

アウトプットの質とスピードが上がった

アウトプットに関してはまだまだ課題だらけです。毎回テックリードである荻野や本部長の京和から沢山の指摘をいただきますし、この記事を書くのにも苦労しています。人前で発表するのもまだまだ緊張します。しかし1年前の自分と比べると、概要を自分で考えて提案することができる点、論理展開が謎な文章が5%程度に減った点、聞き取りやすいスピードで話せるようになった点で大きく変わったと感じています。大きめのカンファレンスで発表概要を提出する時のフォーマットを埋めるのは概要や論理展開を考えられるようになる訓練として最適ですし、発表の練習では録音して自分で自分の発表を客観的に見ることで沢山の気づきが得られます。

社内での成果を客観的に評価できる

勉強会で発表することで、懇親会やパネルディスカッション、SNSでの反応がFBとして得られます。社内では気づくことのできなかったソリューションに気づけたり、優先度の判断を考え直したり様々な気づきが得られるので、客観的に成果を評価できるようになります。

仕事の相談先が同僚+社外の専門家に増えた

新たなチャレンジをする時、社内での相談や勉強会の発表資料などからの情報集のみだと限界があります。それに対して社外の専門家に相談するという選択肢があると一気に仕事がしやすくなります。直接根掘り葉掘り聞いたり、アドバイスをもらうことができるからです。社外の方への相談という点では、ランチ会のところで沢山の方の名前を挙げました。最初こそ荻野のつてで繋いでもらうことばかりでしたが、品質ダッシュボードの導入の相談は1人で勝手に相談したりしていました。

社外活動のチャンスが増える好循環が生まれる

登壇という社外活動から運営や研究会に参加するという新たな社外活動へつながった例として、DevOpsDays Tokyoの実行委員への参加やアジャイルSQC研究部会への参加があります。これらは両方とも勉強会での交流がきっかけでした。別の例としては、月に2-3回行っているDevOpsDays Tokyoの打ち合わせで、業界初心者の私にワークショップや勉強会の情報を教えてくださったりしていて、社外活動がさらなる社外活動へ繋がるよい事例だと感じています。