すがブロ

sugamasaoのhatenablogだよ

認知負荷の種類と対策と組織文化について

このエントリは、SmartHR Advent Calendar 2023 シリーズ1の3日目です。

これは何

当初、Rubyを取り巻く型情報に関するツールの関係性についてまとめようと思ったのですが、既に良いドキュメントがあり、自分が満足してしまったので別の話題として認知負荷をテーマに筆をとっております。

ツールの関係性については↓のエントリをご覧ください

Ruby 3の静的解析機能のRBS、TypeProf、Steep、Sorbetの関係についてのノート - クックパッド開発者ブログ

閑話休題

認知負荷という言葉、よく聞きますよね。私もよく言いがちでした。しかし、「認知負荷」という言葉をふわふわな認識のまま「なんか大変」という言葉の言い換えにしておくのはせっかくの気づきをフワッとさせたままになってしまうので、正しく概念を理解して、立ち向かえる単位に分割できるとより成果に繋げられると思いませんか?思いますよね。思ってください。

さて、そんな話題については 【増枠!】Developers Meetup 急成長ベンチャーが向き合う「開発生産性」 - connpass というイベントで登壇してお話しさせていただきました。

一方で、タイトルがへちょすぎて内容が想像できないという意見も想像に難くないためこちらで少し補足プラスアルファを書いていこうと思います。

認知負荷 is なに

認知負荷とは記憶に関するモデルのうち「ワーキングメモリ」と呼ばれる、何らかの作業おこなっているときに使用する記憶に関する負荷です。 認知負荷という言葉が位置するもの

そして、その「負荷」にはいくつかの種類があり、それを包括したものが認知負荷と呼ばれるものです。

認知負荷の種類

認知負荷理論として教育心理学者、ジョン・スウェラー氏によって確立された理論で、3つあります

  • 課題内在性負荷
  • 課題外在性負荷
  • 学習関連負荷

それぞれは以下のスライドを見てください

課題内在性負荷の説明 取り組むタスクの難しさによって発生する負荷 課題外在性負荷の説明 取り組むタスクの外側にあり、本質的ではない難しさによる負荷 学習関連負荷 学習するための負荷なので、これが十分に高い状態が望ましいとされる

世の中には私が調べたことより丁寧な資料もあるので、ぜひ併せてご覧くださいませ

www.ipii.co.jp

で、これがわかるとどうなるんだってばよ

ここに書いてあることは認知負荷に私の独自解釈であるため、諸説ある可能性があります。有識者のご意見があればぜひ教えてください🙏

課題内在性負荷 であれば本質的な難しさを減らすことはできないけれど、取り扱うサイズを小さくすることで理解しやすくすることができます。 複雑なロジックを小さなメソッド名に切り出し命名していく、変数名を適切なものに変える、(DDD的な文脈で)ユビキタス言語を利用する、などが挙げられるでしょう。

課題外在性負荷 であれば継ぎ足しで複雑になってしまったif文やループ処理をリファクタリングする、Why Notが正しくコメント化されている、ADRなどによりコードの設計方針を記録として残すなどして、コードを読んでいて「アレ?」となる部分を解消できるようにしていくと良いでしょう。

認知負荷とコードの話は、「プログラマー脳」という書籍がめちゃくちゃ参考になるので、ぜひ読んでみてください

www.shuwasystem.co.jp

これらを推進するには組織文化が重要

ここまで書いてあることは、一般的なエンジニアであれば「まあ個別には気になったら対応するよな」というものも多いでしょう。しかし、これらを「気になった個人」駆動でプロダクト全体に一定の規律をもたらすのはとても難しい*1ため、チームや組織の望ましい振る舞いとして浸透・後押ししている必要があるんですよね。

さらに、組織文化だけではなくプロダクトに対してオーナーシップを持てているか?ということも重要な観点になります。 今この瞬間はちょっと妥協できても、半年後、一年後にこのコードが耐えうるかは考慮できる状態になっていてほしいし、既に難しくなってしまったコードにもきちんと立ち向かえる環境である必要があります。

そういった観点で、こういった文化をより強固にしていくための取り組みは社のテックブログに書きました チーム内にテックな話題を話す場を作っておよそ半年が経ちました - SmartHR Tech Blog

さて、ここまで書いた負荷を減らすという話と似た概念として技術的負債(の解消)というワードがあるかと思いますが、これに関してはさいきん目にした↓の資料が良すぎて血の涙が流れました。

このエントリではどちらかと言えば個人がどのように認知負荷を捉えるか?という話題を書いたのですが、例えば「チームトポロジー」のような組織構造と認知負荷の話もありますし、個人としても組織としても両方で立ち向かっていかないといけないんですよね。つまり、ハサミ討ちの形になるな…

認知負荷の詳細を把握してから問題を見ると、フワフワな課題の輪郭を捉えやすくなる

ここまで書いてきたことは、身も蓋もないことを言うと何らかの課題を分割するためにどのような尺度を使って捉えるかという話でした。 もちろん、「認知負荷」で全ての課題を分類できるわけではないと思いますが、成長していくソフトウェアや組織に携わっていると有用なシーンも多いと感じます。

引き続き頑張っていきましょう。

*1:もちろん、十分スキルフルで少人数なチームであれば労せず達成できる可能性はあります

rustでgemパッケージ内のコードを書く方法のメモ

Ruby 3.2に同梱されるBundlerでは、 bundle gem--ext=rust とすることでrustでgemのコードを書けるようになります。

新しいものはとりあえず触ってみたいので、試してみましょう(完全にn番煎じなのですが、自分用の備忘録です)

事前準備

  • rustのビルド環境
  • Ruby 3.2.0(正確にはBubdler 2.4.0以上)

やってみる

rust_gem_sample という名前のライブラリを作ってみるとしましょう。

$ bundle gem rust_gem_sample --ext=rust
 : # 場合によってはさまざまな質問があるので適当に答える

これで雛形ができる。 作成された rust_gem_sample ディレクトリへ移動し、コードをさらっと眺めてみましょう。

rustのコードはC言語の場合と同じように ext ディレクトリ内に生成される。

$ tree ext
ext
└── rust_gem_sample
    ├── Cargo.toml
    ├── extconf.rb
    └── src
        └── lib.rs

ちなみに、生成されるサンプルコードはこんな感じ

# ext/rust_gem_sample/src/lib.rs
use magnus::{define_module, function, prelude::*, Error};

fn hello(subject: String) -> String {
    format!("Hello from Rust, {}!", subject)
}

#[magnus::init]
fn init() -> Result<(), Error> {
    let module = define_module("RustGemSample")?;
    module.define_singleton_method("hello", function!(hello, 1))?;
    Ok(())
}

define_singleton_method でメソッドが定義されているということは、RustGemSample.hello で呼び出せて、1つの引数を受け取るコードってことですね。

さて、ビルドするためには事前準備が必要なので、以下を修正します(これはrust関係なく、bundle gemした時に必要な一般的なもの)。

  • rust_gem_sample.gemspec
    • TODOをURLっぽい値に書き換えておく(これをしないとビルド時にエラーになる)
  • testを生成している場合、自動生成された test コード
    • デフォルトのコードは失敗するようなコードになっているので、修正するなり消すなりする必要がある

これは余談ですが、久しぶりにgemspecの中身を見て source_code_urichangelog_uri というのが設定できるということを知りました。RubyGemsのドキュメントを見るに、設定しておくとrubygems.orgのサイドバーにいい感じに表示してくれるっぽいですね……?

$ ./bin/setup
$ bundle exec rake

これで無事にビルドできるはずです。

ではお試しで実行してみましょう。

$ ./bin/console
Ignoring rust_gem_sample-0.1.0 because its extensions are not built. Try: gem pristine rust_gem_sample --version 0.1.0
irb(main):001:0> RustGemSample.hello("hoge")
=> "Hello from Rust, hoge!"
irb(main):002:0>

おー、うごいた!

せっかくなのでブログにしてみよーと思って書き始めたのですが、なんか、思ったより何もせず動いてしまった……(いい話)。

2021年に読んだ本

2021年は比較的本を読んだ気がします。

よく考えると、ゲームチェンジが起こったことが影響しているかもしれませんね。

読み切った本

いかにしてアーサー王は日本で受容されサブカルチャー界に君臨したか

アーサー王とかエクスカリバーとか、小さい頃から慣れ親しんでいたけれど、それが日本でどのように受容されてきたかの話。どのように編纂されてきたかも含めて読み物としてめちゃ面白い。それと、「いかにして〇〇は〇〇したか」構文はアーサー王伝説を編纂した「アーサー王の死」の章タイトルに由来しているということを知れたのは結構なアハ体験。

あと、コラムとして本文の途中に差し込まれている侘助さんという方のコラムが完全にオタク特有の早口文体なんだけど読みやすくて、なんというか筆力を感じてすごい。

残念ながらkindle版はないのですが、amazonでも物理本は購入できます。kindle版があればな〜〜と思いつつも、この本は装丁もめちゃくちゃ凝っているので本で購入する方が良い体験を得られると思います。

07-9いかアサ〈ガウェイン〉 | みずき書林

眼の誕生

進化の過程でどのように生物が眼という器官を発生させたかという話。推理小説のような書きっぷりで、表題に到達するまではそれなりに読み進めなくてはいけないけれど、光と生物の関係についてじっくり説明していくので、それはそれで読み物として面白い。

眼が発生するのは光を検知して外敵を発見するなどする光受容体をより発達させていったものという内容が段階を経て理解できる構成になっていて良かったのと、三葉虫が目を獲得していった話とかは読み応えありました。

これも物理本しかなかった。

ユニコーン企業のひみつ

いわゆるスクラムのような1チームで成果を出す規模を超えてしまったときに、Spotifyはどういうアプローチでスケールさせていったか?ということが書いてある。LeSSのようなスクラムチームをスケールさせる手法をとっている場合、おそらくアプローチは異なるけど目指す方向は似てるはずなので、Spotifyがどういう取り組みをしていたかは解像度を高めるための参考になりそうな気がしています。

詳しくはこっちに書いた。

🦄ユニコーン企業のひみつを読んだ🦄 - すがブロ

OKR

OKR、雰囲気でしかわかってなかったので参考になった。とはいえ、エンジニアの評価軸に合わせるの難しいな〜〜とか、今週の目標確認やウィンセッションなどのイベントごともスクラムを取り入れた組織だとコンフリクトしそうだよな〜〜などの感想を得た。杓子定規なOKRとスクラムの併用は難しいだろうなあ(導入するならそれなりに強い意志でアレンジしていかなといけなさそう)というのはググるチラホラ見かけました

エラスティックリーダーシップ

以前読んでいたのを再読した。

エラスティックリーダーシップを読んだ - すがブロ

感想としてはあまり大きく変わらないけれど、当時よりは解像度が高い状態で読めて良かった。

つまみ食いで読んでるシリーズ

手を動かしながら学ぶTypeScript

同僚が執筆したTypeScriptの本。 #手TypeScriptというハッシュタグ流行らせたいんですが、全く流行っていません😭

まだ読み進めている途中ですが、個人的には数年前、当時在籍していた会社でJS -> TSへのコンバートをやったときにこの本があれば……!! という気持ちがあります。

達人プログラマー 第2版

いまさら語ることは無い良本ですが、最近になって読み直したけどやっぱり良いこと書いてありますね。

最初は数々の引っ越しイベントを経て手元に残していた初版を読んでいたのですが、圧があったので2版を買いました(のちに気が付いたんですが、kindle版ではなくどこかのPDF版を購入済みだった)。

アジャイルな見積もりと計画作り

自社ではスクラムをベースとした開発をしており、「これ、どう考えたら良いんだっけ?」というときに見直しています。

Clean Agile

こっちの本はほぼ読んだと思うけど、アジャイルな見積もりと計画作りと同じく、考え方を参考にしたいときに読み直しています。

エンジニアリング組織論への招待

これはまだ読んでいる途中なのですが、2021年の後半はチーム内のチーフというロールをやることになったので1on1をやる機会もあり、メンタリングについて興味があって読んでいます。 これは1on1をやり始めてすぐ読むべきだったな〜〜〜というくらい良い本でした。まだ読みきれてないけど……。

エンジニアのためのマネジメントキャリアパス

どういう内容かはそのっつさんの感想を読むとわかりやすいですが、ひとまず自分の目の前にあるチームのマネジメント文脈ほしさで5章まで読んだ。

自社のチーフというロールはプレイングマネージャーなので、参考や目標に。

これはkindle版が無いのが惜しい

おわりに

読んだマンガとかも書こうと思ったけど分量がめちゃ多くなりそうなのでここで終わります。

といいつつ、いま一番良いなと思っているのを書いておくと、ハイパーインフレーションです(最初はイロモノ的なマンガかなと思ったけど、完全にシリアスな笑いを狙ってきていて引き込まれる良さがある)。 shonenjumpplus.com

RubyMineでよく使ってる機能

この記事は SmartHR AdventCalendar の2日目です。

20代の頃はVimを使っていたのですが、膝に矢を受けてしまいIDEを使うようになってしまいました。

さて、そんなこんなで普段使いしているRubyMineですが、この中でよく使う機能について少し書いてみようかなと思います。

というわけで書いていきますが、ファイルを開くとか検索するとかはメジャーだと思うのでそれ以外について書いていきます。

コードを見ているときに便利なやつ

キャプチャを取得する際のサンプルとしてrubygems.orgのコードをRubyMineで開いています。

cmd + clickで関数ジャンプをした後、cmd + [で戻る

メソッドを探索していて、「今見ているメソッドを呼び出していた部分を読みたい」というときに戻れて便利。

さらに、cmd + ]で戻った状態から進むことができるらしいのですが、何らかのアプリにショートカットが吸われていて使えた試し無し😇

開いているファイルを「Project」タブ内で選択状態にする

読み進めているファイルと同じ階層の別ファイルを開く場合などに、シュッと周辺ファイルを探すことができて便利。

f:id:seiunsky:20211202002036p:plain

「Structure」で概要を見る

単純にメソッド一覧が表示されるだけでも便利なのですが、RSpecなど、テストを書いているときにどのようなテストケースが書かれているか把握するのに便利(RSpecだと階層構造も把握しないとテストの全体像が把握できなかったりするので)。

RSpecに関しては--dry-runを実行するという手もありますが、編集しながら横に表示できるのが便利なんですよね〜〜〜。

f:id:seiunsky:20211202002943p:plain

With Coverageでコードカバレッジを見る

テストを実行するときに、「'With Coverage'」を選択するとテスト実行後にカバレッジを表示できます。 網羅率がどうこうというより、テスト対象としたいコードに対して正しくテストが通っているかを確認するのに便利。

f:id:seiunsky:20211202003130p:plain

便利Plugin

ゴテゴテ入れるのは好きでないので、あまり入れてませんが……。

GitLink

Open in GitHubのショートカットを追加するやつ。カーソルがある行に対応するGitHubパーマリンクが取得できるので便利。

https://plugins.jetbrains.com/plugin/8183-gitlink

Find Pull Request

該当行を変更したであろうPRを探してくれるくん。システム考古学してるとき便利。

https://plugins.jetbrains.com/plugin/8262-find-pull-request

Railways

rails routeをシュッと見る用です。絞り込みもできるので便利。

https://plugins.jetbrains.com/plugin/7110-railways/

SmartHRに入社して1年が経った

めでたいのでハッピーターンをたくさん食べました

これまでのあらすじ

sugamasao.hatenablog.com sugamasao.hatenablog.com

近況

5/1で入社して1年ということになりました。

10年ちょっとぶりの転職なので世の中のエンジニアリングについていけなかったらどうしようかと思っていたのですが、幸いにもWebアプリケーションエンジニアとしてなんとかやれてます(たぶん……)。

今までロクに経験のなかったチームでの開発ってやつを楽しんでます。

SmartHRとぼく

忘れそうなので書いておきます。

認知のきっかけ

2018年

この頃、転職はまだ少し先の話という認識でいました。

少なくとも半年後に転職するとかそういう気持ちではなく、IT業界にありがちな、そのうち転職するとしたら合いそうな会社の目星をつけておこうくらいの温度感ですね。

  • おそらく最初に認知したのはこのconnpassだったと思う
  • もしかしたらRubyKaigiでの宮田さんの話だったかもしれないけど、このRubyKaigiは不参加だったのでTwitterのTLごしにうっすら認知していた可能性がありそう(いまとなってはこの時点で認知していた気がするけど、存在しない記憶の可能性がある)
  • エンジニア向けの体験入社制度ができましたの時に名前だけじゃなくて事業も把握したはず
    • というのも、当時は私自身も半蔵門に勤務していたので、ふつうの出社気分で体験入社できそうだな〜とか考えたりしていたのだった
    • 良さそうな会社という認識はあったので転職する気持ちが高まってたらすぐに飛びついていた可能性はあった

2019年

アラフォーで同じ会社に10年いるのやばくね? みたいな気持ちが高まっており、ワンチャン転職しても良いかもっていう気持ちになってきた年です。

正確に書くと、40歳過ぎてから転職するのヤバそう(転職した時の期待値を越えられなさそう)という気持ちが強く、40歳になる前に−−そして転職に失敗した場合の再転職バッファも考えると今のうちに一度転職しておいた方が良さそうだなみたいな事情です(2019年当時、私は37歳)。

  • Rails DMのランチセッションでSmartHRが会社紹介をしていて、その話を聞いた時かなり魅力的に感じた記憶がある
    • この手のランチセッションって、ご飯食べながらだし、言うても話半分で聞く感じになりがちだと思うのですが、なんかめちゃくちゃ響いたんですよね
      • この時点ではすぐに転職活動するつもりはなかったのですが、時が来たら話を聞きにいこうと思った
  • そのほかにはたらいの話がすごく良さそうに思えて、人が増えていってもちゃんと対処できてそうという雰囲気を感じたのだった

ちなみに、これが響いた様子です(これはさまざまな感情を圧縮した結果のコメントです)

それから

以前の転職活動メモにも少し書きましたが、転職活動は2019/10ころから始めていました。

初手は転職ドラフトで本当に自分自身に市場価値あるんですか……?みたいなところを見つつ、転職ドラフト経由以外に自分からいくつかの企業にコンタクトをとったのが11月末〜12月くらいって感じですね。

SmartHRに関しては、たまたま参加したイベントに人事の方がいらっしゃったのでダイレクトアタックして選考フローに乗せてもらいました(ふつうにHPから応募しようと思っていたので、これは本当に偶然)。

その後、なんやかんやあって、ありがたいことに内定はいくつかいただけたのですが、どの会社も魅力的で本当に迷っており、パーフェクトRuby on Railsの改訂作業を行う精神力が保てなくなったりしました(それはまた別のお話)。

ここまでを振り返ってみると

SmartHR社は転職に対するマインドシェアが高まっている時にちょうどよく認知を高めるイベントがあったのかな〜〜という感じはありますね。

最終的に決断した一手はこれらとは別にありましたが、そこに至るまではやはり「タイミングが合っていた」というのは結構重要なファクターだったかもしれません。

露骨な宣伝

それはそれとして、CTOからのお知らせにあるとおりSmartHRではWebアプリケーションエンジニア(に限らず)積極採用中なので、もし話を聞いてみても良いかなって人がいらっしゃればぜひ以下の資料やエントリーページをみていただければと思います。

会社説明資料はこちら。

speakerdeck.com

以下の採用ページにある各職種の募集ページからエントリーしていただけますが、カジュアル面談のエントリーも可能なので、まずはどんなもんか話を聞いてみようかって場合はそちらを選択していただければと思います。

smarthr.co.jp

露骨な宣伝2

パーフェクトRuby on Railsも何卒よろしくお願いします。

🦄ユニコーン企業のひみつを読んだ🦄

私は訳者お二人のファンなので書いました。まあもちろん、それ以外にも単純にスクラムをもうやっていないという宣伝はシンプルに気になりますよねということでシュッと買って読みました。

ちなみに、オライリーのサイトだと電子書籍版を購入できます。

www.oreilly.co.jp

かんたんな感想

スクラムとかアジャイルとかあまり詳しくないので小学生並みの感想です。

今北産業

  • スクラムをやっていない」isいわゆるSpotifyモデルの話
    • ただ、これはあくまで著者がSpotifyに所属していた時期(2014〜2017)のモデルであって、いまどうなっているかを書いているわけではない
  • Spotifyモデル」is少数チームで迅速に開発をする速度を維持しながらスケールさせるには?という話
  • このモデルを実現させるためには"開発チーム"みたいな閉じた座組みではなく、経営陣を含めた考え方、つまり企業の文化を変えなきゃダメだよねということを述べている

ちなみに、本文の補足を書いてある「訳者あとがき」はインターネット上に公開されているので、購入前に一読してみると良いかもしれません。

https://scrapbox.io/iki-iki/%E3%83%A6%E3%83%8B%E3%82%B3%E3%83%BC%E3%83%B3%E4%BC%81%E6%A5%AD%E3%81%AE%E3%81%B2%E3%81%BF%E3%81%A4%2F%E8%A8%B3%E8%80%85%E3%81%82%E3%81%A8%E3%81%8C%E3%81%8D

感想

Spotifyモデルのことを名前しか知らなかったのだけど、どういう思想のもと作られたものかわかってよかった。 また、これは読めばわかることだけど、「スクラムをやっていない」、それはそうだけど事業規模や会社に合わせて変化させていった結果であって、取り組みはスクラムの知見や経験をベースにしていてスクラムは役に立たなかったとかとかそういう話ではなさそう。

Spofityモデルの話をベースにしているけど、どちらかというと"テック企業になるためには文化を作っていかなくてはいけないんだよ"というメッセージが書いてあるように思えたので、形をまねるのではなく自社がより良い一歩を踏み出すための参考にする感じが良いのかなあ。

👇のような話もあるし、世の中銀の弾丸なんてないのじゃ……(真偽のほどはわかりません)。

https://agile.quora.com/Spotify%E3%81%AF-Spotify%E3%83%A2%E3%83%87%E3%83%AB-%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E3%81%84%E3%81%AA%E3%81%84

ちなみに、Spotifyモデルを見ていてLeSS(大規模スクラム)と似ている*1ようで異なるなーと思ったのですが、お互いに影響を与えたりがあったりしていたんですかねえ。

読書メモ

*1:どっちも企業文化から変えないと価値をデリバリーできないですよねって話は共通してるかな〜とか

2020年のメモ

振り返るほどかっこいい生き方してないのですが、今年は転職があったり書籍の出版があったりしたので、せっかくなのでメモしておきます。

1月

  • 転職活動が佳境に入る
    • 具体的に言うと選考が最終選考に入り、いよいよどこに入社するか決断しなくてはいけない
  • 改訂版パーフェクトRuby on Railsの執筆新体制でリブート
    • @_yasaichi さん、@igaiga555さんを含めた新体制でやっていく気持ちを新たにしたところ
    • 執筆自体は2019年の秋頃から進めていたのですが、現体制では目標となる発売日までには手が足りず厳しい状態だったのでした
  • サイゼリヤで豪遊して近年稀に見る二日酔いになる

2月

  • 転職活動の最終選考が終わり、いよいよどこに入社するか決めなくてはいけない感じになる
    • 決められないおじさんだったので、体験入社やエンジニアの方との会食などを開いてもらうものの、新型コロナの影響で予定が伸びたりしていた
  • 退職手続きなどを進める
    • 今思うと、入社先が決まってないのに退職するの結構スリリングじゃん
  • 改訂版パーフェクトRuby on Railsの執筆が佳境に入りつつある
    • と言いつつ、転職活動などで精神力を使い果たして身が入らず進捗が厳しい状態に

3月

  • 入社先を決定する
    • 入社を決定した一方、内定辞退の連絡をする必要もあり、本当によくしてもらったのでつらかったです
  • 11年近く在籍した会社を退職した(3月の時点では正確には最終出社で、有給消化期間に突入)

4月

  • 無を満喫する(と思いきや執筆や登壇準備で全然ゆっくりできなかった
  • 日本に緊急事態宣言が発令される
  • ホットクックで料理を作ることを覚える
  • Railsエンジニア養成読本をネタに銀座Railsで登壇
  • 改訂版パーフェクトRuby on Railsの執筆が佳境に入る(ガチ)

speakerdeck.com

5月

  • 現職へ入社
    • 1ヶ月以上働かない状態から突然の仕事で身体がびっくりしちゃうね
    • 昨今の諸事情により初手からフルリモート
  • 改訂版パーフェクトRuby on Railsの執筆が終盤に入り、レビューや修正などで大忙し

6月

  • 改訂版パーフェクトRuby on Railsの執筆が終盤に入り、レビューや修正などで大忙し(2回目)

7月

speakerdeck.com

8月

  • 試用期間が終わり無事に正社員になれました。良かったですね

9月

  • RubyKaigi Takeout 2020 感想戦@仮想松本という自社イベントに参加しました

www.youtube.com

10月

speakerdeck.com

11月

12月

  • 憧れのおつかれ🚿に呼んでいただきました
    • 特に、2回目冒頭の「海でも川でも溺れたことがある」という紹介はかなり良さみが深かったです

youtu.be youtu.be

ここまで書いてみて

今年は転職活動をはじめ、人間との関わりが多かった一年でした*1。 その節は大変お世話になりましたが、引き続きどうぞよろしくお願いいたします。

*1:新型コロナの影響がある中、リモートの対応で滞りなくやりとりできてよかった