[カンファレンス]Battle Conference U30のレポート

## 概要

[Battle Conference U30](https://bcu30.jp/2019/timetable/)の内容&感想まとめです。
30歳以下のエンジニアによるサイバーエージェント主催の参加型技術カンファレンスで、今年で第3回目となるイベントです。
各セッション10分ごとで、最後にブロックごとに表彰されるという形式でした。

##### 関連リンク

 - [connapss](https://battleconference-u30.connpass.com/event/127864/)
 - [#BCU30](https://twitter.com/search?q=%23bcu30)

## 複数プロダクトで利用する共通ライブラリの戦略と運用経験@井上 真吾氏

<blockquote class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">本日の発表資料です。よろしければ投票をお願いします！！<br>複数プロダクトで利用する共通ライブラリの戦略と運用経験 BCU30<a href="https://t.co/87nFbafOrL">https://t.co/87nFbafOrL</a> <a href="https://twitter.com/hashtag/bcu30?src=hash&amp;ref_src=twsrc%5Etfw">#bcu30</a></p>&mdash; れこ | 7/10 TS meetup #2 (@L_e_k_o) <a href="https://twitter.com/L_e_k_o/status/1147380144211841032?ref_src=twsrc%5Etfw">2019年7月6日</a></blockquote>
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

lib, util, common, sharedなど、規模が大きくなるに連れプロダクト内外で似たような共通フォルダで溢れて訳がわからなくことがありがちです。
そういう場合、ライブラリとして公開して管理しようという提案です。

**ライブラリ開発において気をつける点**

1. 使えないものになりがちなので**ライブラリ先行で作らない**。
2. 汎用性がなくなってしまうので**ドッグフーディングしすぎない**。形骸化しがちなボイラープレートは作らず、ベストプラクティス集にとどめておく。
3. アップデートによる情報格差をなくす。 **slack通知の自動化**など行う。
4. １つのプロダクト都合でアップデートしない。**issueを活用**する。
5. **命名規則/型制約/ドキュメント整備/モブプロ**などにより後継メンバーのための学習コストを減らす。

**ライブラリ開発を行なって良かったこと**

- 生産性が上がるライブラリがいくつかできた
- 縦割り感が薄まりチーム間で助け合うようになった
- OSSに貢献するエンジニアが増えた

##### 感想
確かに規模が大きくなるにつれ何が共通なのか、もしくは何が入っているのかわからなくなりますよね。。
パッケージ的な感じなんでしょうか。運用方法についてもっと詳しく聞きたいと思いました。
ライブラリ/パッケージ開発は敷居が高そうなイメージですが、一度慣れてしまえば便利そうです。
OSSのコントリビュータが増えて技術者全体の意識が高まるのもとてもいいですね！
あと何となく[UNIX哲学](https://ja.wikipedia.org/wiki/UNIX%E5%93%B2%E5%AD%A6#%E3%82%AC%E3%83%B3%E3%82%AB%E3%83%BC%E3%82%BA:_UNIX%E3%81%AE%E5%93%B2%E5%AD%A6)を思い出しました。

## JavaScript の AST を扱ってみよう@大原 壯太氏

<blockquote class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">今日話した資料です〜<a href="https://t.co/Hfo8SNvJv5">https://t.co/Hfo8SNvJv5</a><a href="https://twitter.com/hashtag/bcu30?src=hash&amp;ref_src=twsrc%5Etfw">#bcu30</a> <a href="https://twitter.com/hashtag/bcu30_1?src=hash&amp;ref_src=twsrc%5Etfw">#bcu30_1</a></p>&mdash; Sota Ohara (@sottar_) <a href="https://twitter.com/sottar_/status/1147384658436358144?ref_src=twsrc%5Etfw">2019年7月6日</a></blockquote>
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

**AST(Adstruct Syntax Tree)**とは抽象構文木の一つ。
ASTはソースコードをパースして作られるもので、ソースコードの必要な情報を抽出した木構造。
DOMtreeなんかもその一つ。
ESlintやPrettierなどのコード解析やコンパイラの過程で使われる。

ASTはJavascriptで扱うことができる。
**Javascript AST**のデファクトスタンダードは**ESTree**。
パーサーはAcron, Esprima, Babylon, Espreeなどがある。

ASTが使われる一連の流れは以下。
ソースコード->(parser)->AST->(traverser)->New AST->(generetor)->Newソースコード

**AST Explorer**というツールが見やすくて便利。
プレゼンでは、ASTを用いてJavascriptコードのvarをconstに置き換えるというバベルプラグインを作る紹介がされた。

##### 感想
レイヤー低めの話で難しかったです。
個人的にはESlintやprettierの設定するので精一杯なので😖
実務でどういう場面で使うか想定しづらかったので、実際に実務で使用した場面なども聞いてみたいと思いました。
コンパイラとかその辺はブラックボックス化されていて普段は意識しませんが、掘っていくと勉強になりそうです。
コマンド叩いてからソースコードを実行するまでにどういう過程を経ているのかを説明できるとカッコ良さそう（？）

## 行動ログを元にコンテンツを自動分類するための機械学習基盤とデータ整形@左野 寛之氏

<!--
ユーザの分離を試す

データの切り方
鮮度がある
整理されたデータの活用
ユーザ分類
ログ・スナップショット

インフラ
DWH：Redshift bigquery
テーブル設計 dimensional modeling -> fact dimensionに分ける
集計クエリを描きやすい 不必要なさまりテーブルの作成を避けられる

CNN 画像で判定
ユーザを文章、コンテンツを単語
Word2vec 分散表現 skip-gramを使用

ワークフロー step functionで管理
パイプラインの構築入力/出力の整理 chatへ通知
T-sne で2次元に分散氷霧を落とし込む
DBSCAN

意外とやすい
ワンコイン
Apache spark
blazing text

分散表現を得た
次はユーザの分類をしたい
-->

##### 感想
ユーザの分散表現を画像で得る発想が面白いと思いました。
大量かつ整理されたデータが揃っているのは大手ならではの強みだと思います。
インフラをきちんと整備して、しかも費用も意外と安いのはいいですね。
研究途中な感じなので今後の成果を見てみたいです！

## チャットボットプロダクトにおけるリアルなNLP課題@友松 祐太氏

<blockquote class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">本日の登壇資料です<br>チャットボットプロダクトにおけるリアルなNLP課題<br>株式会社サイバーエージェント/アドテク本部/AIメッセンジャーカンパニー/友松祐太<a href="https://t.co/9Qp7OyYsCg">https://t.co/9Qp7OyYsCg</a><a href="https://twitter.com/hashtag/BCU30?src=hash&amp;ref_src=twsrc%5Etfw">#BCU30</a> <a href="https://twitter.com/hashtag/bcu30_1?src=hash&amp;ref_src=twsrc%5Etfw">#bcu30_1</a></p>&mdash; tomomatsu_yuta (@tomomatsu_yuta) <a href="https://twitter.com/tomomatsu_yuta/status/1147419634145976320?ref_src=twsrc%5Etfw">2019年7月6日</a></blockquote>
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

<!--
NLR 自然言語処理
質の高いデータ、FAQの整備

チャットボットの運用の課題
初期設定
顧客とCSとのメールのやり取りの記録からFAQを作成する
実際の使われ方

表記揺れ 
辞書作成を自動化、表記揺れに強いモデル

ユーザの発話に合わせて回答を出してあげる必要がある マイページとログインなど
ログの汚染 ゲーム広告など、質問ではないログの除外 -> スパムフィルタ

AIの賢さ + FAQの整備で質を高める
利用価値は大きい
実プロダクトならではの課題 -> データの質など

-->

##### 感想
実務で機械学習扱うときはデータの収集方法や量や質が課題になることは多いと思います。
データが偏っていたりノイズが多かったりするとモデルが良くても精度上がりませんよね。。
データの質を高めるために自動化するのはとても良い取り組みだと思いました。

発表を聞いて、目的に沿った活動をされているんだなぁと感じてふと思ったこと。
自分も含めて機械学習を行うことが目的になってしまいがちなので自戒を込めて。
機械学習使うまでもなくVBAやRPAや統計で十分な内容だったり、データ収集方法の検討段階で業務フローが改善して課題が解決するなどはよく聞く話なので、目的を見失わないようにしようと思いました。
話は完全に逸れますが、個人的に政府にはAI人材育成する前に役所のIT化や自動化を進めてほしいです。笑
電子国家エストニアを見習ってほしい🇪🇪

## エンジニアがデザインを学ぶことの意義と応用@大木 尊紀氏

<blockquote class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">次の発表資料です！<a href="https://t.co/1Q1l3PLr8C">https://t.co/1Q1l3PLr8C</a><a href="https://twitter.com/hashtag/bcu30?src=hash&amp;ref_src=twsrc%5Etfw">#bcu30</a> <a href="https://twitter.com/hashtag/bcu30_3?src=hash&amp;ref_src=twsrc%5Etfw">#bcu30_3</a></p>&mdash; takanorip (@takanoripe) <a href="https://twitter.com/takanoripe/status/1147395548141371392?ref_src=twsrc%5Etfw">2019年7月6日</a></blockquote>
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

デザインには、グラフィックデザイン・サービスデザイン・Webデザイン・建築デザインなどがある。今回はインターフェースデザインについての説明。

**インターフェースデザイン**・・・**物体と人間の接点**となる部分の設計。コンピュータの性質と人間の活動をどう結びつけるか考える。

インターフェースデザインは**論理的**なものであり感性の世界ではない。
考え方：UIデザイン・ユーザビリティetc..
学術的視点：知科学・心理学・人間工学etc..

**エンジニアがデザインを学ぶ理由**
1. **プロダクトがが良いものか判断**するため。**根拠**を持つことができる。
2. **何を作るべきか**を考えるため。必要なものを見極められ、デザイン的な視点による**説得力**が増す。
3. **共通言語**ができ**コミュニケーションが円滑**になる。デザイナーなどの意図を汲みやすくなる。

キャリアの例としては、そのままエンジニア・デザインエンジニア・プロダクトマネージャなど。

**デザインの勉強方法**
・本を読む
・個人で何か作って見る。雑誌とか名刺とか個人サイトなど。
・専門の人と話す。デザイナーと話してみたり、会議でデザインについて発言してみたり。
・デザインを批評してみる（論理的な根拠づけの練習）。

##### 感想
感性だけでなく、論理的な根拠を持ってデザインを議論できるようになると強いですね。
デザイン勉強しよ。。
勉強したいものがどんどん積み上がっていく😇

### 4歳からプログラミングに夢中な"テックキッズ"が開発したアプリ「今日の洋服何着てく？」の紹介@澁谷 知希氏

##### 感想
4歳からHTMLを触り始めたとのことで、今時のデジタルネイティブ世代に驚きです。
小学6年生の発表で、最初に習い事や好きな科目の紹介があって小学生の頃を思い出しました。笑
ものづくりを純粋に楽しんでる様子が印象的でした。プレゼンもとても上手でした！
プログラミングコンテストで受賞されてるようでした。
[受賞結果発表 | 小学生のためのプログラミングコンテスト「Tech Kids Grand Prix」 | テックキッズスクール](https://techkidsschool.jp/company/release/2018/09/25/techkidsgrandprix-4.html)
このTech Kids Schoolというスクールもカンファレンス主催であるサイバーエージェントが運営しているようです。
月額21000円か・・・出せなくはない。。

## パラレルキャリアがもたらす相乗効果@内立 良介氏

<blockquote class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">話してきたった<a href="https://twitter.com/hashtag/bcu30?src=hash&amp;ref_src=twsrc%5Etfw">#bcu30</a> <a href="https://twitter.com/hashtag/bcu30_2?src=hash&amp;ref_src=twsrc%5Etfw">#bcu30_2</a> <a href="https://twitter.com/hashtag/heyinc?src=hash&amp;ref_src=twsrc%5Etfw">#heyinc</a><a href="https://t.co/eEEgsAIYqJ">https://t.co/eEEgsAIYqJ</a></p>&mdash; Ryosuke Uchitate (@b1a9idps) <a href="https://twitter.com/b1a9idps/status/1147428025039900673?ref_src=twsrc%5Etfw">2019年7月6日</a></blockquote>
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>


**パラレルキャリア**とは、副業とは違って優先順位がない複数のキャリアを持つこと。
2018年、法律が改定され**副業・兼業に関する規定**が新設されたため、パラレルキャリアを始めやすくなった。
また、多様な副業サービスも沢山生まれている。

**登壇者の例**
・正社員/8時間×稼働日/報酬あり
・業務委託/月40時間/報酬あり
・カンファレンス運営/空き時間/報酬なし

**パラレルキャリアを始めた理由**
正社員の現職に不満はないが、様々な環境を経験することによって**スキルアップ**や**テックスキルの客観視**をしたい

**各キャリアの相互作用**
・スポンサー
・開発ノウハウの共有

**パラレルキャリアのメリット**
・プログラミングスキルがつく
・プレゼンスキルがつく
・問題解決力がつく
・会社やフェーズの違いによる施策の打ち方の学び
・人脈が広がる
・固定概念が外れ多角的に物事を見れる
・社外からの刺激を受ける
・様々な角度から社会貢献できる

**パラレルキャリアのデメリット**
・オンラインが多くなりコミュニケーションコストがかかる
・時間・体調管理が必要

##### 感想
どうやって時間管理してるのか気になりました。
他の副業してる人の話を聞いても、ワーカホリック気味で身体を壊した方の話を聞いたり、土日に仕事をすることがしんどすぎて副業を辞めてしまった方の話を聞いたりするので、時間の捻出や体調管理は課題だなーと思います。
週3~4日の正社員があればいいのにと思います。個人的には会社で給料上がるより休みが増える方が嬉しいです。笑

## ログ収集基盤を導入したらエラーログが99%以上削減された話@小芝 涼太氏

<!--
DMM 動画配信事業部
技術負債の返済
ログ収集基盤の構築
モノリシック
サーバを事業ごとに分離

Fluent firehose elasticserch cabana
s3 Athena

エラーログのノイズ
コードの長さ ログの再現
上位を人力で削減

周りを巻き込む
エラーログを事業ごとのslackへ投下する -> 焦り始める
夫妻を数値化してどのくらいやばいか 気づかせる -> 撲滅活動が勃発

アクセスログ
Glue crawler glue catalog Athena redahs  (awsなしで見る)

エラーログ減ったメリット
リリースの品質向上
バグや障害を検知しやすく
布石や主要項目の通知が一般的に

残ってる課題を掘り出す

作るではなく使うことが目的
数値化。可視化で周りを巻き込む
自動化
-->

##### 感想
やっぱ周りを巻き込むのは大事だし、それも一つのスキルだと思いました。
通知したとしてそのままスルーされてもおかしくないけど、ちゃんと拾ってくれる周りの人も良いなと思いました。
そういう雰囲気が出来上がってるのもチームの力だと思います。

## サービスがゼロからN億円規模になるまでに実践した7つのやっていき@菊川 史貴氏

<blockquote class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">発表の資料こちらになります！<a href="https://t.co/f9qYZtKHEQ">https://t.co/f9qYZtKHEQ</a><a href="https://twitter.com/hashtag/bcu30?src=hash&amp;ref_src=twsrc%5Etfw">#bcu30</a></p>&mdash; キクナントカ (@kikunantoka) <a href="https://twitter.com/kikunantoka/status/1147418475402391553?ref_src=twsrc%5Etfw">2019年7月6日</a></blockquote>
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

ギフティのサービスが成長していく中で得た、実践的なノウハウの紹介です。
企業向けのgiftee campaing platformというプラットフォーム、略してGCPだけどAWS使ってるらしいです。笑

**1.プラットフォームを作っていく**
toBだと受託になりがち。他のクライアントも必要としているか？を見極め、汎用的なサービス・プラットフォームとして開発することで大きな利益を生み出すことができる。

**2.小さく初めていく**
想定しすぎず小さく開発、小さく検証することでPDCAを高速に回す。
汎用的にしすぎない。バランスが大事。
「いつか必要かも」の機能はいらない。YAGNI（You ain't gonna need it）の精神。

**3.一つのチームで開発していく**
ビジネスチームとエンジニアで一つのチームで開発していく。
週１の定例や座席を同じ島にするなどコミュニケーションしやすい環境を整える。

**4.プロダクトマーケットフィット達成後はガンガン開発していく**
全力でコミットしていく。開発に集中するため、運用など他の人に移乗していく作業も行う。
サービスは運用が始まってからが本番。

**5.サービスをスケーラブルにしていく**
成長するとサービスを落とせない状態になるため、インフラをいつでもスケールアウト・スケールインできる状態にする。
負荷検証大事。ロック処理やスロークエリに注意。Elastic beanstalkやAWS Auroraなども活用。

**6.定期的にDBの制約を見直していく**
データの不整合をなくす最後の砦はDBの制約。マイグレーション結果を確認し、検知できるようにする。

**7.当たり前のことを当たり前にやっていく**
Linterを適用する。独自のルールはなるべく作らない。
Sentryなどのエラートラッキングサービスで健全な状態を保つ。x日以内に対応/通知など、運用面も考える。
バージョンは最新に保つ。言語・フレームワークなど、バージョンアップするだけでセキュリティ/高速化などの非機能面の恩恵を受けれる。技術的負債を防げる。

##### 感想
実際の経験に基づいた、実践的で具体的なノウハウが詰まっていると感じました。
聞く話はどれも本当にその通りだなと思えることばかりでした。
聞くのは簡単だけど、実際に取り組んで継続していくことは大変なので、小さいことをコツコツやり続けていかないとなと思います。
バージョンアップを怠らずに技術的負債を残さないのはシステムの継続に必要なことだと思いました。

## 30代のキャリアを意識した20代のキャリア戦略@向井 咲人氏

<blockquote class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">本日の登壇資料です🎉🎉🎉🎉🎉<br>20代のみんなに届け〜！<br><br>30代のキャリアを意識した⁰20代のキャリア戦略⁰<a href="https://t.co/C2WSJV0vtN">https://t.co/C2WSJV0vtN</a><a href="https://twitter.com/hashtag/bcu30_1?src=hash&amp;ref_src=twsrc%5Etfw">#bcu30_1</a> <a href="https://twitter.com/hashtag/bcu30?src=hash&amp;ref_src=twsrc%5Etfw">#bcu30</a></p>&mdash; Sakito (@__sakito__) <a href="https://twitter.com/__sakito__/status/1147422834521587713?ref_src=twsrc%5Etfw">2019年7月6日</a></blockquote>
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

**30代を予測しない**
ITの未来は不確定で、会社に依存せず個人にフォーカスした時代になってきている。
個人の力を磨き、不確定な未来に向けて対応できるようにする。
**土台を増やして経験を掛け合わせ**、差別化する戦略を取る。

**1.俯瞰してみる**
**得意なことや経験を客観視**する。転職活動のための**レジュメづくり**がおすすめ。
常にレジュメを更新する。自分を営業する。

**2.自分のブランディング**
ブログ、登壇、SNSなどなんでもいいので**発信する**。情報を流して周りから見れる状態にしておく。
多くの人に知ってもらうことで社内外で声をかけてもらえ、執筆・副業・登壇などの**多くのチャンス**が得られる。

**3.副業や転職をする**
**違う環境に適応する能力**が身に付く。環境がわかることによって**自分の強み**に気づく。
20代であればリスクも取りやすい。異なる環境において**ノウハウの共有**ができる。

##### 感想
公開して人目に晒すことは大事ですよね。
スキルの掛け算で差別化していくのは本当にその通りだなーと思います。
レジュメを常にアップデートする案もなるほどと思いました。

勉強会を聞くだけを脱出して何か一つでも登壇したいです。
それかせめて運営に応募します。PHPかJavaScriptかその辺りでおすすめ教えてください。笑

## サービスメッシュを導入してよかった話@江頭 宏亮

<!--
サービスメッシュ
Win ticket

マイクロサービス
アンバサダーパターン
・共通処理をプロキシに任せる ロギング、負荷分散、サーキットブレーキングなど
Envoyを採用  プロキシ gRPCにも対応 istio
アプリケーションのサイドカーとして利用
マクロサービスを束ねてクラスタを構築・管理してサービスメッシュ

目的：アプリケーション開発に集中
Logging
Service discovery ホストの増減時に自動追加、削除
Load balancing gRPCとRESTリクエストを負荷分散
Connection pooling 
Statistics

目的：火曜製鋼所
Heath check unhealtyなホストを取り除く
Outlier detection 異常発生してるホストを取り除く
Circuit breaking 過剰なリクエストの503 スローダウン、クラッシュを防ぐ
Retry

よかったこと
ビジネスロジックの実装に集中できた
インフラ障害の影響を少なくできた
-->

##### 感想
前提知識がないと難しかったです。
サービスメッシュの概念を知れただけでも良かったです。
マイクロサービス間をサイドカープロキシを経由して接続することで、サービス間の依存関係や情報管理の課題を解決するもので、主にk8sと一緒に使われることが多い
って感じでしょうか。
使ってみてよかった点として、
・ビジネスロジックの実装に集中できた
・インフラ障害の影響を少なくできた
とのことでした。

このプレゼンとは直接関係ないですが、インタラクティブブースでサービスメッシュを紙芝居で説明してくれてる方が面白かったです😊

## TerraformとJenkinsによる外形監視管理の自動化@李 一凡氏

<!--
モニタリング

サービス管理者視点　メトリクス　ログ　プロセスの死活
サービス利用者視点　サービスが使えるか

外形監視 Synthetics
内部監視・外形監視
ユーザアクセスをシュミレートする

内政vs外部ソサービス
外部サービス　マルチ経路、誤検知しにくい、メンテ不要

UptimeRobot 無料 基本機能完備 rest api対応 ssl証明書の監視
課題　SSOがない1ユーザしかログインできない
APIから監視 URLを設定したい　変更記録を残したい

解決策 -> Terraform
コンポーネント
・config
・Provider 各プラットフォームと通信
・Tf.state 状態ファイル

設定ファイルをmoduleか

CIを利用
プルリク -> check -> まーじ -> uptimerobotへ&configをS3へ 

今後したいこと
通知の自動
-->

##### 感想
内部監視はよくしますが、外形監視というのを初めて聞きました。
可用性のためには確かに必要そうです。
具体的な構築の仕方を聞けて参考になりました。

## カンファレンスの所感
登壇する人は入社or転職して1~2年みたいな人も多く、同じような立場の人たちがこうして活躍しているのを見るのはとてもいい刺激になりました。
内容に共感しやすいものも多く、会場の雰囲気も同世代ならではの一体感みたいなのがあり良かったです。
運営の人はみんな平成生まれだったらしいです。笑

こういうカンファレンスって出席したらぐったり疲れること多いですが、各セッション10分くらいでテンポがよく聞きやすかったです。
もっと聞きたいと思えるくらい。
Ask the speakerも用意されていたので、聞きたい人は聞きに行けるような場が用意されているのも良かったです。

プロコンも開催されており、ちょっとだけですが参加できて楽しかったです。
カンファレンス参加者の1/3くらいが参加しており、参加時間自由でセッションを抜け出さなくても参加できる時間帯なのも参加しやすかった要因かなと思いました。

カンファレンスの開始時間が昼からだったのはありがたいです。エンジニアが朝苦手な人が多いのをわかっている・・・？笑
ちなみにわたしは最初の基調講演は寝坊して遅刻したので聞けませんでした😇笑

懇親会では抽選会があり、景品当たりました！嬉しい〜
<img width="768" alt="961FE1A9-1624-42CD-AB3A-D43B80A06F14.jpeg" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140953/63ab8d4e-23d7-1bc8-450f-d2df2d98b5c7.jpeg">

iOSをやらなければ・・・(使命感)
前回の技術書典で売られてたもののようです。
景品は技術書が多く、技術カンファレンスならでは感がありました。

ご飯もスポンサーが手厚いのか豪華で美味しかったです。あげパンとか🥖

全体的に大満足の内容でとても楽しかったです！
運営の方々に感謝！

## 最後に
記事に間違いや不明な点があれば遠慮なくご指摘ください。
また、個人が勝手にまとめてるのでもし載せるのがダメな場合も遠慮なく教えてください。