天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

スクフェス福岡2024で登壇できることになりました

表題の通り、スクフェス福岡2024で登壇できることになりました!

話す予定のセッション

confengine.com

「今日はほんとうにいい話を聞けたなあ.........で、どんな話聞いたんだっけ...?」 自分が勉強会やカンファレンスに参加をし始めたとき、毎回困っていたのが、たくさんの学びを得た気がするはずなのに少し時間が経つとほとんどすべてのことを忘れてしまっており、残っているのは自信がないぼんやりとした記憶だけになっていることでした。

学んだことを活かそうにも、具体的な話が覚えられていないので、勉強会やカンファレンスに参加したことで新たに解決できるようになっている問題は少ないままで、勉強会やカンファレンスに参加できたことに後悔はないものの、何かしらのもどかしさを感じている状態でした。

そんな状態を打破すべく、勉強会やカンファレンスへの参加を重ねながら試行錯誤を繰り返し始めました。色々な試行錯誤を繰り返していったのですが、試行錯誤の中で自分が特に着目し始めたのは「推し活」でした。

自分自身、それまで誰かを推したりした経験はなかったのですが、「推し活」をしている友人が「推し」の発言やライブで起きたことに対して驚異的な記憶力を発揮していることに気が付き、「推し活」している状態を再現して勉強会やカンファレンスに取り入れることができれば、得た内容の多くを記憶に保持しておけるのではないか?と思い至ったのです。

そう考えた自分は、「推し活」をしている友人に話を聞きながら、「推し活」をしているときに起きていることを見つけ、勉強会やカンファレンスで再現できるようにトレーニングを繰り返しました。

レーニングには1年以上の月日がかかってしまいましたが、結果的に自分でも驚くほど人の話や起きた出来事が覚えられるようになり、今では1日参加したカンファレンスで2000文字分書き起こせればよかった記憶が、30000字以上書き起こせるようになりました。 本セッションでは、自分がしてきたトレーニングの内容や「推し活」をヒントにした人の話を聞く技術をお伝えすることで、みなさんがカンファレンスや勉強会で得られた学びを保持し続けるようになることを目指します。

なぜ福岡で話そうと思ったのか

1つ目の理由は、カテゴリとしてOtherがあるカンファレンスは意外と少ないので、そこを狙ったというのがあります。ちょっと他のスクフェスとは違った話ができて差別化?にもなるのかなというのと、プロポーザルのAccept確率が上がる可能性があるということが頭にありました。
2つ目の理由としては、RSGTで色々な人になんで人の話をそれだけ覚えていられるのか?と聞かれたことで、一定興味を持ってくれる方が増えてきたのかな?と感じだしたことが挙げられます。飲み会でも4回ほど今回のプロポーザルにかするような話をして、そこで皆さんそこそこ面白がってくれたかな?と感じたので、今回のタイミングでプロポーザルとして出してみようと思いました。
最後の理由としては、ようやく話しても説得力があるくらいのスキルを手に入れられたと自分自身が思えるようになったことが挙げられます。

Accept通知を受けたときの心境

3つのプロポーザルを出していたのですが、自分が想定していた以上にlikeの差がついていたので、Acceptされるとしたら昨年と同じまさかAcceptされるわけないと思っていた福岡シリーズではなくこのプロポーザルかなあと考えていたので、昨年に比べると驚きはなかったです。

また、Acceptいただけたこと自体がものすごく嬉しかったのですが、現地でぜひ登壇してほしいと言っていただけたことは更に嬉しさが増す要因でした。
プロポーザルの内容的にも、現地を盛り上げることができると思っているので、聞いていて学びがあることはもちろん、場が盛り上がるような発表にもできたらいいなと思っています。

今回チャレンジしたいこと

上に書いたこととも近いのですが、今回は現地に呼んでいただけたということもありので、エンターテインメントとしても楽しめて、現地が盛り上がるような発表をしたいと思っています。
その上で、聞いた人が自分と同じ期間(一年)トレーニングを積めばスキルの再現ができるような発表を目指します。

おわりに

昨年に引き続き、福岡では普段スクフェスで話すような内容とは違うテーマでお話することができて、とても楽しみです。

なお、どこかしらでは話そうと思っていたこともあり既に発表準備はスタートしているのですが、内容がぜんぜん20分で収まらず、最初のピンチを迎えています笑

開発エンジニアから DevOps エンジニアへ ! ~ SLO ってなんだ ?に参加してきた

aws-dev-live-show.connpass.com

以下のイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の様子

開発エンジニアからDevOpsエンジニアへ興味が移った理由

直近はフルスタックエンジニアなど幅広い範囲を担当しているエンジニアの需要が高まっていることと、ビジネス書でもアジャイル開発が取り上げられるようになっていることから、DevOpsへの興味が支援しているクライアントでも湧いているというお話がありました。

また、クラウドサービスの登場でインフラの民主化が起きたことで、技術的にも組織的にもDevOpsが実践できる土台が構築されたのも大きいということでした。

SLI/SLO

はじめに、SLOサービスレベル目標の書籍を参照して、SLI/SLO/エラーバジェットの紹介がありました。具体的には、

  • SLI…メトリクスで特定される計測値
  • SLO…目指すべきSLIに対する目標値
  • エラーバジェット…SLIがSLOに対してどういう影響を及ぼしたのかを計測する手段

という定義の紹介や、SLI/SLOは定期的にアセスメントしていく必要があるというお話がありました。

サービスを提供している以上、ユーザーが正常に使える状態を定義しておく必要があり、その目標の一つとしてSLI/SLOが重要であるという話がありました。

概念自体は昔からある一方で、サービスがSNSで簡単に評価されるようになった直近では、満足できなかったシステムの悪評はあっという間に流布されてしまうため、直近注目を集めている概念だと考えているということです。

何からはじめるとよいのか?

システムと体制の両面からアプローチが必要だということでした。

アプローチの内容としては、サービスが動いているかの外形監視からスタートした後、リアルユーザーモニタリングをしていくのが重要だというお話がありました。メトリクスとしては、すでにとっている数値(status)の中で特にユーザーに近いところから使っていけると良いのではないかということです。(ただし、ストアの評価点数やユーザーの満足度などといった定性評価が絡むようなメトリクスは運用が難しい点に注意)

全体を通した感想

メトリクスの例として定性評価が絡むようなものをSLI/SLOの運用に組み込んだ話は、初めて聞いたので面白かったです。

DevOpsエンジニアの話の部分は今ひとつ普通のエンジニアや会で言葉として出ていたフルスタックエンジニアとの定義の違いが分からなかったので、もう少し話を聞けると個人的には嬉しかったです。

2024年1月のふりかえり

恐ろしいことに2024年1月が終わったので、ふりかえりをしていこうと思います。(嬉しいことに、ここ数年の1月はRSGTでバタバタして大体いつもあっという間に終わる気がしちゃいます)

月のふりかえり

仕事

昨年から関わらせていただいているプロジェクトは変わらないのですが、すごい雑に言えば実装段階に今月からは移っていきました。

既存の自分の知識や経験を活かしながらやれるところもありつつ、その中で色々新しく勉強させてもらうことも多くあって、プライベートとのバランスもうまく取りながら楽しく仕事ができていると思います。

学んだことに関してはどこかのタイミングで話したり整理できたらと思うのですが、プロポーザルを書くとなるとあんまり適切なスクフェスが浮かばないので、ブログとかに整理しようかなあと考えています。

社外活動/自己研鑽

ざっくりと記録をまとめると、

  • 読書14冊(前月+10冊)
  • 勉強会参加59回(前月+16回)
  • 動画/Podcast22本(前月-30本)
  • 論文47本(前月-66本)

でした。

RSGTの登壇内容からの発展で洋書の技術書を読む機会が増えた一方で、発表内容に関しては先月でほぼほぼ固まっていたため読んだSurvey数は大分減りました。(先月は発表内容を固めるためのSurveyを大量に読んでいました)

勉強会は徐々に参加数が戻りつつあるのですが、参加しているコミュニティは一時期と比べると半分くらい入れ替わりがありました。
学術的な研究をし始めているコミュニティだったり、これまで自分があまり参加したことがない分野の勉強会に参加できているのは個人的には良いことだと思っているので継続していきたいです。

一方で、(後述しますが)走れなくなったことで動画やPodcastの視聴本数は大分落ち込みました。

プライベート

子供のhalf birthdayや年始行事に加え、宿泊が伴う外出が3件(7日)あったので大分濃い印象がある月でした。

家族と改めてゆっくりと話す時間が取れたり、小さい子供がいる中で自分がカンファレンスやコミュニティ参加を継続していくための実験に手伝ってもらうことができたりして、本当に家族には頭があがらない想いでいっぱいです。

一方で、親に重い病気が見つかってしまったり、昨年からばたばたと巻き込まれていた騒動に悪い動きがあったりといった出来事もあって、プライベートで頭を悩ませられる時期はまだまだ続きそうだなあというのも残念ながら感じる一ヶ月でした。

一年でやりたいことに対してのふりかえり

翻訳

まだ具体的な内容を書くことはできないのですが、出版社の方にアプローチし、翻訳本の出版に向けて一歩を踏み出すことができました。

また、昨年から続けているチームでの翻訳は継続できており、ようやく折り返し地点も越してきたので、活動を地道に継続していきたいと思います。(このチーム翻訳に関しては、今月は今後ペースアップしたいかや翻訳に向けてのモチベーション確認も改めてできたので、非常によかったです)

登壇(プロポーザル)

RSGT2024での登壇を無事に終えてきました。
また、スクフェス福岡にプロポーザルを3本出しました。

すべてのカンファレンスにプロポーザルを出すかは家族とも要相談なのですが、少なくともスクフェス〇〇にはプロポーザルを出せたらいいなあと思います。

コミュニティを立ち上げる

ここは下準備を少しだけ前半で進められましたが、後半は完全にスタックしてしまいました。

色々実験をしてから(ステップを踏んでから)やりたいと思っているので、来月すぐにできることはないと思いますが、春頃には何か立ち上げることを目的に準備を進めていこうと思います。

また、自分が一人で立ち上げているわけではありませんが、今月はスクフェス金沢の立ち上げがスタートしたので、来月以降引き続き頑張っていきたいと思います。

続けていることに関して何かしらの単位を変える

単位を変えたにあたるのかは怪しいところですが、今月のパーソナルコーチングをきっかけに、これまではなんとなく気分が乗ったときにやっていたことを毎日やるように行動変容できたことがありました。

これまでも継続してきたと言えることに関しては、幾つか単位を変える候補は洗い出せたのですが行動にまでは移せませんでした。
単なるサボタージュだとも捉えられるのですが、そもそも単位を変えることで狙う効果のようなものが曖昧で、今ひとつやるべきかどうかに踏み切れなかったのが理由です。

1年間運動を継続する

前半は毎日走っていたのですが、1/20頃に膝を負傷してしまい、しばらく走れなくなってしまいました。怪我はつきものなので仕方居ないのですが、新年早々走れなくなってしまい残念です。

運動習慣は継続できていて、毎日自重トレーニングをしたり近所にあるプールで1時間泳いだり、家族と出かける日は4時間くらい歩いたりしています。

国際カンファレンスに参加

ここはまるで進展がないです。来月は、どの国際カンファレンスに参加するかを考えてみようと思います。

子供がまだまだ小さく、家族で海外へというのもあまり現実的ではないので、最初はオンラインで参加できる国際カンファレンスを探すのかなーと思っています。

アジャイルカフェ@オンライン 第47回に参加してきた

agile-studio.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

天野さん木下さん家永さんのお三方がアジャイル実践者のお悩みに答えていくイベントです。今日のテーマは、「開発進捗が芳しくない場合にスクラムマスターがやることは?」でした。

会の様子

前提整理〜芳しくないとは?〜

まず、開発進捗が芳しくないとは何か?という話をしていきました。

  • リリースバーンダウンチャート通りに進んでいない
  • 毎スプリント、次のスプリントにPBIが持ち越しされている

などが状況として挙げられるのではないか?という話が出ていました。

チームが問題に気づくためにどうすればよいのか?

透明性を上げることが一つの方法として挙げられるということで、例えばリリースバーンダウンチャートを毎日記録したり、ベロシティを定期的に計測することが重要だというお話が出ていました。

チームが問題に気づいているが行動しない場合はどうすればよいのか?

上記のような施策を取って問題に気がついた場合、どういうことをするのか?という話が次に出ていました。

最初のステップとしては、皆でリリースバーンダウンチャートやベロシティを見て、プランニングのタイミングで「このままでは終わりそうにないよね」といった問題提起をまずすることが重要だということでした。

ただ、問題提起をするだけでは悪い言い方をすれば「ただ言っているだけ」の人になってしまうため、そこから施策を打っていくことが重要だということです。

ありがちな問題に対する施策

問題提起をした後の行動例として、パターンごとに話がありました。

リリースバーンダウンチャートが最初から基準線の上

予定通り着地しないことが分かっているのに放置されていることが問題であり、これは、

  • 希望的観測が常にされている
  • 何が何でも全部やりたいという気持ちがある
  • エンジニアとして「できない」を言いたくない
  • 調整コストが高すぎる

といった原因が考えられそうだということです。

そのため、外部ステークホルダーやPOとの調整をしたり、希望的観測ではなく実績に基づいて根拠ある判断をしたり、一旦立ち止まってチームで話す時間を設けるのが良いということです。

リリースバーンダウンチャートが徐々に基準線から遅れてくる

ベロシティが下がってきているのであれば、その原因を考えて仮説を立てることがまずは必要だという話が出ていました。

典型的な原因としては、技術的負債の蓄積やバグの数の増加、問い合わせの数の増加などが考えられるということです。

原因ごとに対策を打っていく必要がありますが、完成の定義を強くしていくことは一つの対策として取れるというお話がありました。
他にも、純粋な技術スキル不足を解消するために研修を実施したり、外部のプレッシャーを和らげることも方法の一つだということです。

会全体を通した感想

透明性を上げるために取る施策がベロシティやリリースバーンダウンチャートというのは少し意外でしたが、何も取っていないチームであればはじめの一歩としては十分効果があるものなのかな、とお三方の実践経験を聞いて感じました。

そもそもの話をしながらも聞かれた問題に対して真摯に回答している様子は非常に勉強になりました。

QAエンジニアがスクラムマスターに憧れてしくじった話に参加してきた

distributed-agile-team.connpass.com

今週も分散アジャイルチームの会に参加してきたので、会の様子と感想を書いていこうと思います。

スライド

speakerdeck.com

会の様子

nacoさんから発表があったので、以下に様子を書いていきます。

スクラムとのなれそめ

今までWFのプロセスしか経験してこなかったため、最初は宇宙語を話しているように聞こえたそうですが、Agile Testing Condensedを読んだりしていく中で出てきた思想やアジャイルの考え方に共感し、ぜひやってみよう!と思い立ったそうです。

更に、nacoさんの想いがスクラムマスターに後押しされ、これまで「これやってみたい」が通ったこともない中で話が通ったことも非常に嬉しく、よりやってみたい気持ちが強くなったということでした。

スクラムマスターとしての一歩としくじり

こうして一歩を踏み出したnacoさんは、まずPSMを取得したそうで、これがきっかけで無事にスクラムマスターとしての一歩を踏み出せたということです。

しかし、ふーんという反応はもらったもののそこまで反響は大きくなかったうえに、スクラムマスターが何をやるのかまだそこまで分かっていなかった中でスクラムスクラムマスターに関する説明をしたことで、説明の解像度が荒い部分があり、自分で自分の首を締める結果になってしまったそうです。

スクラムをやりたいと思っていないチームの誕生

スクラムマスターやっている自分がかっこいい!という気持ちもあった影響で、スクラムをやりましょう!から入ってしまい、なぜスクラムをやるのか?という部分が疎かになってしまい、スクラムをやりたいと思っていないチームが誕生してしまったということでした。

また、スクラムをやるにあたって、既存のものを置き換えたり変えようとしすぎた点もよくなかった可能性があるというお話でした。

そのため、どんなチームになりたいのかやどうしてやりたいのかを聴いてみながら、小さいことから始めるようにしてみることを心がけたということです。

スクラムチームの中でスーパーマン化していくマネージャー

責任感が強く色々チームをよくしようとしてくれるマネージャーが、どんどんスーパーマン化してしまい、マネージャーと話すためのMTGを設定するようにしたということでした。

そこで、マネージャーの想いを聞き出し、これまでマネージャーがやっていたイベントのファシリテートをスクラムマスターに移すことができたそうです。

進まないカイゼンと質問責め

カイゼンがなかなか進まず、チーム外部からもnacoさんに対してどうしたらカイゼンできるのか質問が殺到してしまい、思考停止状態に陥ってしまったそうです。

そこで、鳩さんアイコンのメンターさんに相談したところ、「全知全能の神がいるなら何を相談したいですか?または何を代わりにやってほしいですか?」と質問されたそうで、ここでスクラムマスターを伴走してほしいという自分のニーズを言語化できたということでした。

スクラムチームの解散

最終的にスクラムチームは解散してしまうことになったそうですが、ここまで色々な苦労をしてきたnacoさんは正直肩の荷が下りた部分もあったということでした。

ただ、次にスクラムマスターにチャレンジする機会があればやりたいし、しくじりを学習として次に活かせるようにしたいという話も出ていました。

質疑応答&皆からのコメント

発表の後は質疑応答がありました。

コミュニティと出逢ったのはいつか?

nacoさんはスクラムとの馴れ初めの時点でスクラムコミュニティには出逢っていたということでした。

最初はスクフェス新潟がきっかけで、そこに誘ってくれたのはメンターさんだったそうです。

スライドに登場するのがパンダの理由は?

ドクロを書こうと思ったけれど意外と難しくパンダになったということでした。

スクラムが一般用語で構成されていない理由

一般的な用語を聞くと、なんとなくわかったような気になってしまうため、あまり英語でも馴染みのない言葉を使い、その用語に対する共通理解を研修などで揃えるためにスクラムは作られているため、宇宙語と思ってそのまま放置したり曖昧な理解で進んだりせずにチーム内で用語理解を揃えるところからスタートしてほしいという話がありました。

しくじりと学習の違い

同じしくじりをするのが何回目か?で、しくじりか学習かが決まるという話が出ていました。

メンターの方は伴走してくれていたのか?

nacoさんががんがん質問をしていったこともあって、ほぼ伴走に近いようなことをしてくれたということでした。

スクラムマスターに後押しされたはずなのに、スクラム用語なんもわからない...とチームがなっていたのはなぜか?

スクラムマスターをやってみなよと言われたのは転職をする前で、転職したと同時にスクラムマスターになったため、チームではスクラムの認知がまだなされていない状態だったということでした。

会全体を通した感想

全部手書きのスライドというのははじめてで、一枚一枚に釘付けになりました。
発表するのが初めてで緊張されているという話があったのですが、発表からは全然そんな感じは受けず、丁寧に話しながら見事に展開を作り込んでいる印象を受ける発表ですごかったです。

Target Audienceとしていたスクラムマスターにはじめて取り組む人にはぶっ刺さりそうな発表で、非常によかったです。

オブジェクト指向のこころを読む会 Vol.3に参加してきた

yr-camp.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

タイトルの通り、オブジェクト指向のこころを読んでいくイベントです。

今日は第3, 4章を読んでいきました。

会の様子

第3章の感想

最初に、第3章で問題として提示されている優先度の付け方に関しては、実際の現場でも起きそうだし、これなら変更に強いと言い切れるようなよい実装方法がぱっと思いつかないなという話をしていきました。

また、3.5に関しては、オブジェクト指向を使えば変更に強い設計ができるというつながりがやや雑な気がするという話や、現在の状態を持つというのは具体的にどういうことなのか?という話をしていきました。
3.5には、フィーチャーを整理したクラス図もあったのですが、この後の展開からしてフィーチャーを抽象化するのはいいアイデアではないという話が出てくるので、この図がなんであるのか?という話になり、ベンダーが提示してきたものであり理想を書いたクラス図に過ぎないのではないかという話で落ち着きました。

第4章の感想

最初にクラス図を見たときに、「これはフィーチャーが増えていくにつれて組み合わせ爆発が起きそうで明らかに拡張しにくそうだけど、なんでこの本はこの解決策を提示しているんだ...?」と思ったので結果的には肩透かしを食らったという話が出ていました。

また、直感とは?という議論になり、言語化できるものだけど現時点ではできていないことで直感だと思う場合(循環的複雑度が高いなど)と、純粋なコードの美しさといった言語化も難しい場合の2パターンがありそうだよね、という話をしていきました。美しいコードでは、凄腕のエンジニアが美しいと感じるコードの話(専門知識や複雑なアルゴリズムを駆使しないと解けないと思っていた問題を、数行で解決してしまう)をしていきました。

第3章の応用問題に関して議論

「ジオメトリに関しては、v1にしてもv2にしても抽象化できるが、フィーチャーレベルだと属性も責務も違うので、そもそも抽象化できるようなロジックがないため」というのが回答として出てきました。

同じ「図形」だからというレベルの根拠での抽象化は危険だよねという話や、実際の現場で近い場面に出くわした話の共有などがありました。

第3章のあなたの意見に関して議論

ユビキタス言語は作っても消えやすい(定着しにくい)というのと、ユビキタス言語は部署が変わると使えなくなることに注意しないといけないという話が出ていました。

第4章の応用問題に関して議論

「ジオメトリレベルで抽象化を実施し、スロットレベルでV1, V2に対応するクラスを作った。凝集度が低く結合度が高いコードになっており、フィーチャーが増えた際の拡張が大変なため、妥当な実装方針ではない。」というのが回答として出ました。

第4章のあなたの意見に関して議論

1に関しては、同意する意見が多く出ていました。

自分たちが働いている現場は不確実性が高い状態なのを想定していることや、知識を蓄えた後の自分の方が賢いからというのが理由としては挙げられていました。

その後は、本書の時点での「詳細に踏み込む」とは具体的にどんな行動を指すのか?という話になり、

  • ベストな変数名にこだわる
  • 実現するアルゴリズムを考える
  • DBのテーブルのカラムの設定を考える
  • マイクロサービス化を考える

というのが例として挙がっていました。

2に関しては、かなり微妙なラインだという話が出ました。

発想のスタートが直感で、その直感をみんなで深掘りして回答を導き出すというのはいいことだし実際にやる*1けれども、直感を理由に改修や方向転換を迫られるのは非常に厳しいという話が出ていました。
併せて、自分自身が違和感を持った+違和感の理由が直感しかない、という場合は、(直感ではなく理由を言語化することは試みる前提で)違和感があることをはっきりと言わないといけないよなあというのも話として出ていました。

会全体を通した感想

今回もまだ実装部分の話は少なく、早く本題(?)であるデザインパターンの話に移りたいという声もありましたが、結局議論は盛り上がり、今回もイベント終了時間をオーバーして話をしていました。

特に直感の部分は大分話が盛り上がっていて、本書の主張に理解は示しつつもなかなか従いずらい側面はあるんだなあというのを実感しました。

*1:特にドメインエキスパートの意見などは参考にすることが多い

大人のソフトウェアテスト雑談会 #196【避雷針】に参加してきた

ost-zatu.connpass.com

今週もテストの街葛飾に行ってきたので、会の様子と感想を書いていこうと思います。

スクフェス制覇

一年の間で各地で行われている全てのスクフェスを制覇した人はいるのだろうか?という話を聴いていきました。

自分はさすがに2023年は制覇できていないのですが、川口さんやkiroさんはなんとなくどのスクフェスにもいる印象を持っています。

メタラー区長

区長が実はメタラーだったという話やなぜメタラーになろうと思ったか(&メタルバンドを組もうとしていたのか?)を聴いていきました。
しれっと体力が必要なアピールをしていたり、いつもどおりマウントを取っていました。

肝心の内容に関しては、何を言っているのかさっぱりわかりませんでした笑

スーツ

とあるカンファレンスに参加するにあたって、参加する場合はスーツを着る必要があると聞いて、エンジニアがざわざわしていたという話を聴いていきました。

参加者の皆さんも(オンライン区長を除いて)声を出していた方はほとんどの方がスーツをずっと着ていないらしいしなんなら持っていない人もいるらしいですが、カジュアルスーツとかバケーションスーツがあることを考えると、もはやジャケパンもスーツだと言っていいのでは?という話も出ていました。

ゴジラ-1.0

godzilla-movie2023.toho.co.jp

ゴジラ-1.0を見てきたRyoさんから話がありました。

とても好きな作品だったそうですが、現実に転用してあれこれ考える映画というよりも、画面の中で起きている面白い話だと解釈しながら見る分には非常に楽しいということでした。

全体を通した感想

自分の知識がなさすぎて何を言っているかよくわからない話が前半のメタラーやスーツの部分では多かったのですが、チャットもZoomもいつも通り盛り上がっていて、いつも通りのテストの街葛飾でした。