サイボウズのフロントエンドエキスパートチームに入った

リモートワーク 転職

今月からサイボウズに入社し、フロントエンドエキスパートチームのメンバーになった。

有休消化期間＆GWでたっぷり眠る生活を続けていたので社会復帰できるか心配だったが、なんとかなってる。

blog.cybozu.io

よくある感じで数ヶ月は試用期間扱いで、それが終わってからブログに書こうかなと思っていた。ただ、試用期間中所属を隠すとなると、チームの活動内容のひとつに「発信」があるにも関わらず数ヶ月間なにも発信しない気かお前という話になってしまうし、そもそもそんな気持ちで仕事するの良くないよなという考えに至り、書いちゃうことにした。

なぜ

チームの存在は以前から知っていて、特にYouTubeでやってるフロントエンドマンスリーはよく観ていた。

最初は「ほ〜ん、すごい人たちがおるもんやな〜」ぐらいに思ってたのだが、フロントエンドを探究・研鑽しつつレガシーを改善するというテーマにも立ち向かっているのを知り、個人的にも本を出したくらいにはフロントエンドの脱レガシーには思い入れはあったので、なんとなく通ずるものは感じていた。

同時に自分自身は「このままだと良くないなぁ」という漠然とした不安みたいなものがあり、今思えばコンフォートゾーンってものへの危機感だったのかもしれない。

ぼんやりと「一緒に仕事できたら何か少しは役に立てる部分があるかもしれない」「つよいチームなので自分も成長できそう」「とはいえ自分で通用するのかな」とかを考えていたころ、偶然にも元同僚の身内に社員の方がいることを教えてもらい、その方に繋いでもらってカジュアル面談を受けることができた。本当に超絶感謝しています。

カジュアル面談にチームのほぼ全員が現れたのにはビビったが、採用に対してチームで真摯に向き合ってる証拠だと思えたし、実際に話せたことで想像していた以上に魅力に感じた。

そのあとは採用に応募し、なんやかんやあって今にいたる。

なお個人的に5年以上地域RubyコミュニティであるToyama.rbを運営しており、Rubyコミュニティ主催者がRuby書かなくてええんかという話だが、冷静に考えると自分はここ1年ぐらいのもくもく会ではRustとJSしかやってないし、そもそも内容を縛っているコミュニティではない。RubyもRailsも今でも好きだから問題ない。問題ない！！！

入ってみてどうか

社風

まずサイボウズという会社の風土にいい意味で驚くことが多い。自由度が高く、現場の裁量がとても大きい。これだけの規模の会社でこれを実現できているのは衝撃を受ける。ここまで辿り着くまでいったいどれだけの血と汗と涙が流れたのだろう..。

ただ、自由であることは同時に各々が考えと責任を持って行動する必要があるため、ぼんやりと決められた仕事をするのを期待していると死ぬことになりそう。

チーム

フロントエンドエキスパートチームについては、予想通り「すごい人たちの集まりやでぇ..！！」となってる。各々が何かしらで特出した領域を持っている印象。そしてみんな良い人。

チームの活動範囲は広く、組織横断的なチームなので関わるプロダクトも多い。そして社風もそうだが、チーム特性上さらに自由度が高く、何らかの目的意識を見つけて自主的に動いていく必要がある。

今のところはまだ特に何も色を出せてない焦りを早くも感じるが、自分は地に足をつけて泥臭い改善作業を時間かけて倒すみたいなところが力を出せる部分だと理解しているので、焦るよりも少し長いスパンで考えて成果に繋げることができたらいいなぁと思う。ひとまずは今までやってきたことを信じて頑張っていきたい。

今後

この機会なので今までやれてなかったことも取り組みたい。OSS活動と英語かなと思う。特に英語は信じられないぐらい貧弱なのでやばい。社内制度使ってレアジョブを始めることにしたので、ちゃんとやるぞ。

ちなみに

すぐにサイボウズに応募しようと決めたわけではなく、数ヶ月間で多くの企業のカジュアル面談を受けた。ご対応頂いた企業様・担当者様ありがとうございました。

あらためて、リモートワーク可能な会社がめっちゃ増えたんだなぁと実感した。

4年半前に転職活動をしたときは、富山からフルリモート可能な会社を探すのは非常に困難だった覚えがある。コロナによる影響だとは思うが、地方在住勢にとっては選択肢が増えるのは人生の幅が広がるのでとてもありがたい。4年半前に同じ転職が可能だったか？と言われると自信はない。

自分への戒めとして、地方に住んでいることを言い訳にすることがないように今後も頑張っていきたい。

おわり。

雑談用Shownoteの作成・共有サービスをつくった

チュートリアルじゃなくて、ちゃんと何か作って試しておかないとな〜という技術がたくさん自分の中で累積していたので、次のようなサービスを作って公開した。

shownotes.vercel.app

概要

雑談・1on1・リモート飲み会・勉強会などで、話したいネタを事前に作成・共有しておき、会話時には再生する形で1つずつネタを提示してくれる。

いまのところShownote自体の作成はGoogleログインを必要としているが、作ったShownoteの閲覧や雑談トピックの追加みたいなところはURLさえ知ってれば誰でもオッケーにしてる。

ログインしたらボタンを押せばShownoteの雛形が作れる。

f:id:mugi1:20210505225118p:plain

Shownote自体には自由に雑談テーマを追加できる。これはURLさえ知ってれば誰でもできるので、一緒に話したい人に事前共有しておける。

f:id:mugi1:20210505225358p:plain

実際に話すときは、追加順 or ランダム再生で、１個ずつトピックを表示してくれる。

f:id:mugi1:20210505225707p:plain

一応一定間隔でPollingしてるので、同じ画面を見ている人では表示が同期されるようになってる。5秒ほど開けてるので、同時に見ると少しラグとかズレがあるのは勘弁してほしい。websocketとか使えば良かったのだが、あんまりそのへんで頑張りたくなかったので雑にApolloClientでPollingとした。

f:id:mugi1:20210505230611g:plain
Pollingでなんとか同期している図

話してる時間をそれっぽく計測しているので、最後に一番盛り上がったトークテーマがどれだったかとかが表示される。

f:id:mugi1:20210505230454p:plain

なお一応公開しているが、使う人がいるかはわからなかったので現状以下の制約がある。

  • PostgreSQLがHerokuのフリープランなので10000レコードでサービスが死ぬ
  • アプリ自体がVercelにデプロイしてるので、DB接続で若干ラグがある

もし使う人がいるようであれば追々解消させる予定だが、誰もいなければ何もしない。

使った技術要素とそれらへの所感

次のようなものを使ってる

3画面しかないのに完全にオーバーキル構成である。 実現機能を考えればどう考えてもFirestoreとか使った方が10000000%良いのは最初からわかっていたが、これは仕事ではないので、そんなことより自分が勉強目的に使ってみたいモチベーションで使いたいものを全部入れた。問題はない。

Next.js

かなり昔のバージョンでチュートリアル的なことはやったことがあったが、改めてちゃんと何かを作ったのは始めてかもしれない。

普段Vueに慣れ親しんでいた身としては、ReactというだけでTS親和性が高くてとても良かった。また、next/image での画像最適化など、痒いところに手が届く感もあり、Vercelを使ったのでデプロイの簡単さも抜群だった。

一応部分的にSSRも採用したが、これは実際にプロダクション導入する場合は慎重に検討すべきところだな〜と改めて感じた。 Next.js側自体の推奨としても、認証が必要なページでのSSRとかはいらないよね？？みたいな話もあったりするし、どうしても複雑化するので、サービスとして何を重視するのかとちゃんと向き合うのが最初にすべきことかもしれない

とはいえ、トータルの開発体験としてはとても素晴らしいものだった。新規で何か作るなら積極的に採用するよなぁというのも頷ける。

Prisma

今回このサービスを作った発端のモチベーションは「Prisma使って何か作ってみたい!!!」だったので、強引にPrismaを採用した。簡単に説明すると、Node.jsで動くORMです。

最近まで仕事でRailsを使っていて、今もRailsは好きなのだが、何が好きかというとActiveRecordの操作感に尽きるな〜と思ってる。（色々細かいことやりだすと大変なんだけども）

PrismaでのDB操作はかなりそれに近い感覚があり、prisma.user.findFirst(...) のような形でデータを取得できる。そして何よりも、それらを全てTypeScriptで型安全に操作できるのがとても良い。

また、現在はPrismaにはMigrationの仕組みが備わっていて、全体の主軸となる *.prisma に書かれたスキーマ定義をもとに、変更時には差分をMigrationとして抽出することができる。今回のような趣味レベルで使った範囲では特に困ることもなく動作したし、Migrationファイルの内容もただのALTER文が書かれているだけなので、SQL読める人なら内容も簡単に理解できて、編集しようと思えば編集できる。

全体的にかなり使いやすい印象。今後大きく流行っても全然不思議じゃない。

Nexus

APIはGraphQLにしたが、バックエンドにはNexusを使ってみた。

GraphQLでAPIを構築する際には Schema First か Code First の選択肢があるが、Nexusは Code Firstのフレームワークに該当する。

Schema First と Code First のどちらを良しとするかはサービスの規模感やチームの方針によって変わるため一概には判断できないと思うが、個人的には Code First のほうが全体の記述量が減ることが多いので好み。

ただ、Nexusにしたのは好みだけが理由ではなく、Prismaとの相性が良いのもある。 nexus-plugin-prismaというNexus用のプラグインが存在しており、たとえば「Bookモデルの中身を返すクエリ」を作るときに、Prismaが生成しているモデル情報をもとにレスポンスを定義することができる。

これの何が嬉しいかというと、DBが変わるとそれに伴ってNexusが生成するGraphQLスキーマも変化するので、そこからGraphQL Code Generatorを通せばクライアント側での型不整合なども全部チェックできるようになる。

なお、DBモデルをそのままクエリとして露呈するとか危ないでしょって最初は思ったが、公開するフィールドは明示的に指定したもののみに限定されるため、意図せず公開されるみたいなことは無く、そのあたりも問題なかった。

DB⇄APIサーバー⇄クライアントの全てが型定義で一貫してチェックされるのはとても快適で、DB変更時にクライアント側の変更が漏れたりするようなケースは開発中に一度も無かった。

Redux (Redux Toolkit)

Reduxをちゃんと使ったのは5年くらい前で、とてもツラかったような記憶があったのだが、Hooks対応なども経てとても良くなったと聞いたので試してみた。

結果としてはかなり使いやすくなってた。Redux Toolkitがとても良かった。昔Reduxでストレスに感じてたのは、やりたいことに対して手数があまりにも多すぎる点だったが、そのあたりが綺麗さっぱり解消されてる感覚があった。

これだけ使いやすいなら、下手にオレオレ状態管理するよりかは、何も考えずにとりあえずRedux採用したほうがトータルのコストは下がりそう。

まとめ

チュートリアルだけ過去にやった技術も多かったが、実際に小さいアプリケーションを作ってみることで得られる知見はとても多かった。モノを作って学ぶのは大事だな〜と改めて感じた。

ちなみに、今回のサービスのアイデアとしては「Clubhouseでのアジェンダ共有ができるといいかな〜」というのがあったが、先にClubhouseが瀕死になってしまった。

とはいえ中途半端で終わるのは悲しいので気合いで作り切った。完走するのは大事。

サービスとしては公開しておくので興味があれば使ってみてください。 https://shownotes.vercel.app/

不具合とか機能要望とかあれば @mugi_uno まで。

おわり

退職

退職

正確にはまだ在籍中だが、約4年在籍していたMisoca(→今は合併して弥生株式会社)を2021年4月いっぱいで退職する。4/16が最終出社日だった。

いま思い返すと色々やったなぁという感じ。主にフロントエンドのモダン化に力を注いでいた。とはいえ、バックエンドも日常的に触ってたし、採用に関わらせてもらう機会もあった。貴重な経験を多く積めて、考え方的な部分では今後一生使えるものを学ぶことができたと思う。Misocaで働けて本当によかった。

大変お世話になりました。ありがとうございました。

なぜ

フロントエンドを仕事でやっていて、改めておもしろいな〜と感じるようになり、もっとフロントエンドに浸かれる環境で仕事をしたいと考えたのと同時に、研鑽できるよう、さらにチャレンジできるような環境に身を置きたくなった。また、今までやってきたことが、さらに大きい規模でも通用するのか試してみたい気持ちもある。

次

そういうわけで、5月からは某社のフロントエンドチームでどっぷりフロントエンドをやっていく予定です。

以前から遠目で見てすごいな〜って思っていた方々と一緒に働くことになるので、 自分がついていけるのか不安になってますが、これまでの経験をもとに頑張りたい。

そういうわけで例のリスト置いておきます。

https://www.amazon.jp/hz/wishlist/ls/29597IU52BIZ6?ref_=wl_share

RBSからTypeScriptに変換するGem (rbs2ts) を作ってる

Ruby3.0 からは、型定義を処理するための rbs gem が同梱されていて、これは外部の *.rbs ファイルに記述した内容に従って、Rubyコードの型チェックを可能にしてくれる。

github.com

最近、この RBS の型定義を TypeScript の型定義に変換できないかな〜と思い、 rbs2ts という gem を実験的に作ってる。

結構荒削りなので、細々した部分での挙動は正直怪しいが、ある程度それっぽく動くようになったので公開してある。

rubygems.org

github.com

Gemのいまのところの挙動

いまのところ次のような変換ができる

Alias

RBS

type TypeofInteger = Integer
type TypeofFloat = Float
type TypeofNumeric = Numeric
type TypeofString = String
type TypeofBool = Bool
type TypeofVoid = void
type TypeofUntyped = untyped
type TypeofNil = nil

変換後TypeScript

export type TypeofInteger = number;

export type TypeofFloat = number;

export type TypeofNumeric = number;

export type TypeofString = string;

export type TypeofBool = boolean;

export type TypeofVoid = void;

export type TypeofUntyped = any;

export type TypeofNil = null;

リテラル

RBS

type IntegerLiteral = 123
type StringLiteral = 'abc'
type TrueLiteral = true
type FalseLiteral = false

変換後TypeScript

export type IntegerLiteral = 123;

export type StringLiteral = "abc";

export type TrueLiteral = true;

export type FalseLiteral = false;

Intersection, Union

RBS

type IntersectionType = String & Integer & Bool
type UnionType = String | Integer | Bool

変換後TypeScript

export type IntersectionType = string & number & boolean;

export type UnionType = string | number | boolean;

Optional

RBS

type OptionalType = String?

変換後TypeScript

export type OptionalType = string | null | undefined;

Array, Tuple

type ArrayType = Array[String]

type TupleType = [ ]

type TupleEmptyType = [String, Integer]

変換後TypeScript

export type ArrayType = string[];

export type TupleType = [];

export type TupleEmptyType = [string, number];

Record

RBS

type RecordType = {
  s: String,
  nest: {
    i: Integer,
    f: Float
  }?
}

変換後TypeScript

export type RecordType = {
  s: string;
  next: {
    i: number;
    f: number;
  } | null | undefined;
};

クラス

クラスっていうかメソッド。これが一番やばい。 これであってるのかホントに

RBS

class Klass
  attr_accessor a: String
  attr_reader b: Integer
  attr_writer c: Bool

  def required_positional: (String) -> void
  def required_positional_name: (String str) -> void
  def optional_positional: (?String) -> void
  def optional_positional_name: (?String? str) -> void
  def rest_positional: (*String) -> void
  def rest_positional_name: (*String str) -> void
  def rest_positional_with_trailing: (*String, Integer) -> void
  def rest_positional_name_with_trailing: (*String str, Integer trailing) -> void
  def required_keyword: (str: String) -> void
  def optional_keyword: (?str: String?) -> void
  def rest_keywords: (**String) -> void
  def rest_keywords_name: (**String rest) -> void
end

変換後TypeScript

export declare class Klass {
  a: string;
  readonly b: number;
  c: boolean;
  requiredPositional(arg1: string): void;
  requiredPositionalName(str: string): void;
  optionalPositional(arg1?: string): void;
  optionalPositionalName(str?: string | null | undefined): void;
  restPositional(...arg1: string[]): void;
  restPositionalName(...str: string[]): void;
  restPositionalWithTrailing(arg1: string[], arg2: number): void;
  restPositionalNameWithTrailing(str: string[], trailing: number): void;
  requiredKeyword(arg1: { str: string }): void;
  optionalKeyword(arg1: { str?: string | null | undefined }): void;
  restKeywords(arg1: { [key: string]: unknown; }): void;
  restKeywordsName(arg1: { [key: string]: unknown; }): void;
};

モジュール

RBS

module Module
  def func: (String, Integer) -> { str: String, int: Integer }
end

変換後TypeScript

export namespace Module {
  export declare function func(arg1: string, arg2: number): {
    str: string;
    int: number;
  };
};

インタフェース

RBS

interface _Interface
  def func: (String, Integer) -> { str: String, int: Integer }
end

変換後TypeScript

export interface Interface {
  func(arg1: string, arg2: number): {
    str: string;
    int: number;
  };
};

作ろうと思った動機

GraphQL Code Generator べんり！！

最近、ちゃんとGraphQLを使う機会があり、GraphQL Ruby によって出力されたスキーマファイルを元に GraphQL Code Generator で TypeScript 型定義に変更し、それをフロントエンドで利用するスタイルで開発していた。

この体験が非常に良くて、ある程度のバックエンド側の変更であれば、フロントエンド側への影響は TypeScript の型検査で拾うことができ、名前をタイポしてましたみたいな悲しい不具合はほぼ防げてた。

RESTつらい

GraphQLでの型の体験を味わうと、逆に次のようなものをなんとかしたくなってくる。

これらは、フロントエンド側でインタフェースを独自で型定義すれば、受け取った後についてはある程度検査できるが、あくまでも独自定義なので、当然バックエンドの変更に対して自動で追従することはできなくて、人力でなんとかする必要がある。

GraphQL以外の方法

全部GraphQLに置き換えちゃえばいいじゃん、というのがまず思い浮かぶストレートな解決策なんだけど、まあそれはほら、大変ですよね。

また、別のアプローチとして OpenAPI や gRPC を利用する方法もあるはず。gRPCなんかはそこまで詳しくないので的外れなことを言ってる可能性はあるが、すでに存在するAPI群に対して後追いで適用するには少しハードルが上がるものかな〜と思っている。 もちろんゼロから構築できるのであれば積極的に導入を検討してもよさそう。（楽しそうだし）

今回は、自分自身のリアルな課題への対処として、段階的にかつコスト低く徐々に保護される範囲を広げていく手段がほしいなぁと考えてた。

RBSからいけない？

というわけで、RBSが使えないかな？と思ったのが発端。

REST用のレスポンスはPresenterクラス的なもので構築してたりするので、バックエンドではそれを RBS 型定義でチェックした上で、その RBS から TypeScript の型定義が出力できれば、現実で稼働しているAPIを大幅に変更することなく、型定義の恩恵だけいい感じに受けられるのでは？？という発想。

今後

まず自分が使わなければな..と思っている。 ドッグフーディングとは 意味/解説 - シマウマ用語集

一応出力されてる型定義は TypeScript Playground にペタッとしてエラーになってないことは確認してるけど、実際に使い物になるかは本気で使ってみないとわからんなという気持ちになってる。

ともあれ、実は何気にちゃんとRubyGems作るのも初めてなので、結構楽しい。 RBSのsyntaxとかを見るとまだまだサポートできていない部分がたくさんあるので、ちまちま更新していきたい。

脊柱側湾症の矯正手術をうけた

雑記

タイトルにある通り、脊柱側湾症と呼ばれるものの矯正手術を受けて、最近ようやくまともに活動できるようになってきた。

似た症状でどうしようかな〜って思ってる人のためになるかもしれないので、色々と記録として残しておく。

脊柱側湾症とはなんぞや

簡単に言うと、背骨が横に曲がっている病気。

普通の人はこう f:id:mugi1:20201109161908j:plain

自分はこうなってた f:id:mugi1:20201109161940j:plain

手術を受けることになるまでの経緯

まず、毎年健康診断を受けており、その際のレントゲン検査で毎回「側湾症」と記載されてたので、自分が側湾症であることは知ってた。

自覚症状は無いの？と言われるとバッチリあって、

  • 壁に背中がぴったりつかない（右の肩甲骨より上がつかない）
  • 肩の高さがよく見たら違う
  • 横腹に若干の張りを感じる
  • 両腕を無意識に前に伸ばすと長さが違う

みたいな感じで、冷静に考えると普通ではない。

ただ、

  • 健康診断の総合判断的にも「経過観察」的な扱い
  • 普段の生活では特別支障がない
  • 「側湾症」記載の健康診断結果出しても住宅ローン審査でも特に影響もなかった

といった理由から、致命的ではないと思って特に気にしてなかった。

が、ある頃から、腰のあたりに若干の痛みというか違和感を感じるようになり、整形外科に向かう。

私「湿布とかくださいよ〜」

先生「じゃあレントゲン撮ろうね〜」

〜30分後〜

先生「これは手術しないと多分だめだね〜」

私「！？」

そして意図せず大学病院への紹介状を手に入れた。

後日大学病院で診察を受け、次のような説明をされる。

  • 結構曲がってる
  • 手術しないと改善されることはまずない
  • が、手術しないと突然何か起きて死ぬとかもないので、経過観察も一つの選択肢
  • おそらく今後もゆっくりと症状は進む
  • さらに年齢が上がってからの手術のほうが大変で負担は大きい
  • 腰への負担が大きいため、放置するといずれ痛みが出てくることが予想される
  • 曲がり方が綺麗なので、比較的手術リスクは低め

なお、特に「コレが原因で発症します！」とかは無く、思春期の子供に特発的に発生することが多いらしい。自分の場合はその際に発見されずに大人になってから色々と支障が出てきた、みたいなケースだった。運が悪かったと。

手術の内容

手術内容を先生に聞いたら細かく丁寧に教えてくれた。自分は医者でもなんでもないド素人なので細かいことまではわからないが、だいたい次のような内容だった。

  1. 背中開く
  2. 背骨にボルト埋める
  3. ボルトをワイヤーで繋ぐ
  4. ワイヤーをガッとやっていい感じにまっすぐにする
  5. なんか色々とグイッとして歪みを直す

「俺の背中、ガッとしてグイッとされるんか...!!」 と考えたらなんか面白かった。

なお、術後数ヶ月はコルセットを巻いて生活する必要があるとのことだった。不便そうだけど、背骨ガッってやってるんだし、そりゃそうだよなって感じはした。

「手術にリスクあるの？」と聞いたところ、人間が行う手術である限りは完全にリスクゼロとは言い切れず、可能性の話でいうと、神経がダメージを受けて麻痺が出たりみたいなことも有り得るとのことだった。

とはいえ、電気信号のモニター？（よくわからん）とかでのチェック体制などもあって、現実的にはほぼ無いらしい。

手術を受けることにした

家族とも話したりして色々と考えた結果、手術を受けることにした。

手術を受けずに経過観察と言えば聞こえがいいが、つまるところ先延ばしにしてるだけな感じもしたし、若いうちにやったほうがええだろうなという判断。

お仕事に関しては１ヶ月ほど休職することになるが、長い人生を考えたらまあ仕方ない。

手術日まで何をしたのか

術前検査を色々と受けた。大体2ヶ月間で5~6回くらい通ったかも？

  • CT
  • MRI
  • レントゲン
  • 採血

などがメイン。MRIは爆音の中で30分以上放置される。ガードのために装着したヘッドホンから延々とジブリのサウンドトラックが流れててシュールだった。

また、「貯血」というのをやった。輸血用の血液を事前に自分の体から抜いておくものらしい。400ccを2回にわけて、合計800ccほど抜かれた。鷲巣と闘うアカギが頭をよぎる。

血を作るのに青魚を食べるといいですよと言われていたが、偶然にも同時期に釣りにハマっており、大量に釣れるアジを食べまくっていた。きっと濃い血になっていたことだろう。

なお、最後の検査はPCR検査だった。コロナのアレです。

インフルエンザ検査の綿棒を鼻の奥でスクリューされる版って感じだった。ちょっと痛かった。

手術日前日(入院)

手術の前日から入院した。

とりあえず昼のうちにシャワー浴びとけと言われた。最期に身を清めておくわけか..とか考えてた。

また、翌日の手術〜退院までの一通りの流れを改めて説明された。

このときはじめて手術直後の姿をイラストで見て、1日後には

  • 人工呼吸器
  • 全身管だらけ
  • 何日かは自力で寝返り不可
  • 常時痛み止め注入

になるという現実を改めて知り「あっ、やっぱやめときます！！お疲れ様でした！！」って言いたくなったがグッとこらえた。

「入院中は暇だろうし、PC持ち込んでコードでも書いてよう！！」とか考えて実際持ち込んでいたが、この時点でもう無理だなって察した。

手術日以降

絶食状態で手術室に自力で歩いて移動する。部屋の前で妻に見送られた。

手術室の中はテレビとかで見るような部屋ですごかった。「ほんものだ！！」ってなってた。

手術室に入りベッドに横になる。ベッドがなんか暖かかった。

あとはもう点滴を繋がれて「いまから麻酔入りますよ〜」と言われたぐらいで記憶は終了してる。全身麻酔自体は初体験ではないので驚きはない。

目が覚めたらもう自分の入院部屋のベッドだった。事前にイラストで見た姿そのものになってた。管だらけ。

術後〜手術翌日

間違いなく人生で味わった中でMAXツラい時間だった。背中から腰にかけて、信じられないぐらい痛い。

肩や腰を少し動かそうとしてみたが激痛が走るので「あっ、これ動いたら死ぬやつだ！」と察してあきらめた。

痛さで死にそうなときには超強力痛み止め（モルヒネとかそういうやつ？）を点滴から少し入れられてだいぶ楽になるが、同時に急激な吐き気に襲われるという、痛みか吐くか選べみたいな状態なのもキツかった。

また、自力で体を動かせないが、ずっと同じ姿勢でいるとそれはそれで圧迫されて痛くなるので、ナースコールして寝返りをお願いする必要があった。だいたい1時間に1回ぐらい。

そんな感じで丸1日間ぐらいは瀕死な感じでベッドの上で過ごしていた。夜も寝れるわけがなく、ただただ耐えてた。

なお、手術翌日にコルセットを巻いて状態を起こすのにトライしたが、死を感じて諦めた。

なお全然関係ないが、事前にSwiftUIの勉強がてら作っていて入院日当日に申請したアプリが、このタイミングで審査をパスした通知がきていた。

「こ…このタイミングで…、ぐふっ」って感じだった。小さなお子様がいる方はぜひお試しください。

術後２日目

ようやく痛み止めの効果が痛さを超えるようになってくる。

めちゃくちゃ痛いのに変わりはないが、なんとか上体を起こすこともできるようになり、少し人間の姿に戻る。

ただ、体は相変わらず管だらけ。背中から出ている管から延々と血みたいのが出てるのがコワイ。

動けないためエコノミー症候群のリスクがあるとのことで、両方のふくらはぎあたりをエアーで自動モミモミしてくれる装置とかもついてて、体の自由度はほぼ無い。（とはいえ自由でも痛くて動けたものではない）

術後３〜４日目

歩行器を使ってギリギリ歩けるようになる。「これが大地か…！」という気分。

また、体からすべての管が抜けて、寝返りも自力でできるようになった。

自力で寝返りしたり、3歩ほど歩くだけで看護師さんがめっちゃ褒めてくれるので、世の中ぜんぶこんな感じならいいのになって思った。

そして病院食のマズさが際立ってくる。背中と腰は痛いが、味覚や内臓にはなんの影響もないので、なかなかキツかった。酸っぱい茹でた大豆みたいなやつは凄かった。

術後５〜７日目

術後検査（レントゲンとか）に歩行器を使って自力で歩いて行けるぐらいには回復する。

また、同様に病院内のコンビニに行けるようになる。病院食で味覚が飢えていたため、醤油やらアイスやらをめっちゃ買う。

そしてシャワーを浴びていいですよとお許しが出る。毎日お風呂に入る人間が一週間近く禁止されると、かなりのストレスになるということを身を以て知り、テルマエロマエを思い出していた。シャワー最高！！

なお、歩けても上体を少しでも捻ったりすると激痛が走るのはまったく変わらず、着替えなどのタイミングで "下半身のみでまっすぐ腰を下に落とす"、"腕力だけで上体を起こす" といったことが求められる。

リングフィットアドベンチャーを半年以上続けてて良かったと実感する。

一方で、夜になると高熱が出る日々が続く。手術後にはよくある話らしく、わりとしんどい。

術後８〜１０日目

相変わらず痛いが、どういう姿勢をとれば痛みにくいかが慣れでわかってくるので、1日を過ごすのが多少楽になってくる。

そうなると、ベッドの上で横になったまま暇を感じ始める。とはいえ、体を長時間起こし続けるのはキツいので、MacBook開いてコードを書こうという気は１㍉も沸かなかった。

そして僕はガラル地方のポケモンチャンピオンを目指して旅に出ることになった。

www.pokemon.co.jp

横になったままでもプレイできるSwitchは偉大。

術後１１〜１４日目

歩行器を使わずに徐々に歩けるようになり、痛み止めが効いてる間はだいぶ楽に過ごせるようになってくる。

なお、このタイミングで身長を測る機会があったが、術前と比較して１センチ以上伸びてた。曲がってたものがまっすぐになったわけだから、そりゃ伸びるよなって感じ。

この歳になって身長伸びるとは思ってなかった。

そしてガラル地方のチャンピオンになった。ダンデさんはかっこよかった。

術後１５日目〜１８日目

当初は術後１４日ほどで退院予定だったが、採血などの結果が芳しくないため、数日間退院が延期になった。かなしい。

ロスタイム的な入院生活で、この間は体感的に痛みなどの変化もなく、さほど特筆すべきこともない。ただ生きていた。

術後１９日目

退院。

ハァハァいいながら気合で歩いて、妻に車で家まで送ってもらう。途中に線路でガタガタなったときに背中がとても痛かった。おのれ線路。

不思議なもので、自分の家で私服を来ているだけで気持ち的にだいぶ楽になった。自分のベッドと枕というわけで夜もわりと眠れた。家最高！

そして飯が最高に美味しい。味がする。

翌日にマクドナルドのハンバーガーを食べたが、「人類はこんな美味いものを食べてたのか…！」って思った。

術後３週間

家で起きてご飯たべて寝るだけの生活をしてた。

立って動くことはできるが、普通に痛いので、横になってる時間がほとんどだった。横になってたら寝るよね…。

また、退院後の初検査ということで、自力で運転して病院に向かった。めっちゃしんどかった。腰がずっと痛かった。

気合で検査を終えて自宅に帰ってきた後は、ソファに倒れ込んでそのまま１時間ぐらい動けなくなってた。

そして、この日から４日後には復職予定だったが、この結果を経て、休職期間を半月ほど伸ばすことにした。悩んだが、座ってるだけでまだハァハァ言いながら死にかける状態なので、仕事しても役に立てる気がしなかったので妥当だった気はする。

術後１ヶ月〜

今この記事を書いてる。

痛みはあるが、耐えられないレベルではなくなってきた。座ってられる時間がだいぶ伸びてきて、ようやくPCに向かって何か作業ができるレベルになった。

多少の外出も可能になってきたので、家族で鬼滅の刃の劇場版を観に行ってきた。煉獄さんがかっこよかった。心を燃やせ。

手術を受けてよかったか？

術後１ヶ月時点での感想

現状ではなんともいえない。

明らかに体の歪みがなくなったのは自分でもわかるし、人間として正しいフォルムになったのはよかったが、痛みは多少あるし、まだまだ私生活に不都合が多い。

術後１週間ほどのツラさはなかなかすさまじいものだったので、あれを思い出すと気軽に人に勧められるものではない。

ただ、骨の矯正手術の場合は治ったなって感じるには数ヶ月を要するとのことなので、また改めて加筆していきたいと思う。

ちなみに、世の中調べると「側湾症を整体で治す」みたいな情報がやまほど出てくるが、実際のところある程度進行した側湾症は手術以外の方法での完治はありえないらしい。実際手術を受けた感じでも、これだけ厳しいものが外部からグイグイやっただけで治るわけないだろって実感してる。

手術がツラいからといって変な方向に逃げるのはやめたほうがいいだろうなとは思う。

入院中にあってよかったもの・あったらよかったもの

個室

（あってよかったものって言われるとなんか違う気はするが）

病院によるのかもしれないが、自分は生命保険が使えることもあったので、有料の個室を希望した。

結果的にはとても良かった。

夜は発熱やら痛みやらで寝れたものではないので、複数人部屋だとかなりキツかったのではないかと思う。

術後しばらくはトイレやシャワーなども結構苦労するので、個室だとそのあたりもゆっくり使えるのは精神衛生上よい。

Nintendo Switch

横になったまま身動きがとれない時間が２週間ほど続くわけで、痛みはあれども暇は暇。

パソコンなどは姿勢の関係上利用がかなり厳しい。

自分はSwitchを持ち込んでゲームしてたけど、痛みも紛れるしよかった。

タブレットやスマホ的なものでNetflix観てるとかそういうのでも良かったかもしれない。

入院前は「何かの勉強でもしてようかな〜」と考えてたが、実際手術を受けると、「痛くてツラいのになんでこの状態でさらに勉強とかやってれるかよ」としか思えないので無理です。

調味料

これも病院にもよるのかもしれないが、基本的に食事はとても味がない。「焼き目のない焼き魚」という謎の食べ物が頻繁に登場する。

この手術は、特に術後の食べ物には制限などは設けられないので、なんらかの調味料を持ち込むことをおすすめする。ふりかけとかもあるといいかもしれない。

手術費用

無保険だと520万らしい。即死ですね。

ただ日本の健康保険には高額療養費制度というものがあり、月額の医療費が超高額になる場合、所得に応じて一定額までの支払いまでに抑えることができる。

入院で個室希望をしたのと、入院中の食費などは別料金となったので、それらを全部含めるとだいたい30万円くらいの支払いだった。

幸い自分は生命保険にも個別で加入していたため、保険金支払いを加味すると、手出しは数万円で済んだ。

そういうわけで

現状はなんとか生きています。

同じ症状の人がいたら少しでも参考になったらいいな〜と思います。

リモートワークを3年強やって思うところを書き殴ったもの

リモートワーク 富山

諸事情により、近々リモートワークについて自分の私見を述べる機会が発生した。

考えるほどに「そもそも自分はリモートワークについてどう考えている（いた）んだっけ？」と深みにはまっているので、一度ここに全部吐き出してみることにする。

注意事項

すべて個人の意見であり、特定の個人・組織に関しての何らかの意図は一切無いです。また、脳内整理のために書き殴った文章なので色々アレですがご勘弁ください。

なぜリモートワーカーになったか

自社サービス開発をやってみたかったが、富山で思い描くような仕事は難しそうだった。かつ、家庭の都合もあり「単身都会へGO！！」とかは無理だった。

リモートワークという働き方は以前から知っていたので、

  1. 思い描くような仕事ができる
  2. リモートワークでも可

という考えで仕事を探した結果今に到る。やりたいことありきで、「リモートワークをしたかった」わけではない。

現在で3年強リモートワークをしている。

リモートワークでよかったこと

一般的に言われるリモートワークのメリットは自分も感じることができた。

  • 通勤時間から解放される（以前は片道40分くらいで車通勤してた）
  • 静かで集中しやすい

ただ、結局のところ「地元縛りでは辿り着けなかったであろう仕事ができていること」が一番のメリットに感じている。

他にリモート関係で良く聞く話として

  • 家庭の都合にあわせて柔軟に動ける
  • 学習・趣味に充てる時間が増える

などがあるが、これは一部はその通りで、一部は自分は当てはまらないなと思ってる。

家庭の都合にあわせて動いているのは事実なのだけど、これが「リモートワークだから実現しているか？」と言われるとNOだと思う。

これはリモートワークという働き方というより、会社の姿勢によるものが非常に大きく、たとえばリモートワークでもめっちゃ勤務時間長かったら違う世界線になってるはず。

学習・趣味に充てる時間が増えたかどうかは、自分はまったく該当していない。以前から技術的な学習はある程度やってはいるが、そこに費やす時間は特に増えてない。基本的に自分は怠惰で、増えた時間はどうなったかというと、単純にゆっくりのんびり過ごす時間に当てている。悪く言うと特に何もしていない。人間、急に時間が増えたからと言ってそれを有効活用できるかどうかはまた別の問題。

とはいえ、ゆっくり休めることで仕事自体も集中できている感もあるので、悪いことだとは思ってない。

リモートワークで困ること

リアルな場で集まった方が捗るものが確実に存在していて、そこはいつまで経っても解決してない。たとえば、プロジェクトのキックオフや、アプリケーション開発時のざっくりとした全体設計をする際などは、ホワイトボードの前で付箋を片手にワイワイやったほうが絶対早いし、一体感が出る。

また、意識しないと雑談が減ってしまうな〜と感じている。オフィスの廊下で何気なく談笑するみたいな、ちょっとした時間が自分は結構好きだったんだなって後になって思った。

ただ、これは「ほらね、こんなにリモートワーク大変でしょ」ということではなく、どんなものもメリット・デメリットはあるんですよって話だと思ってる。

困るのであれば困らないように工夫すればよいし、いまとなってはそのためのツールやノウハウはたくさんあると思う。

自分が体験したものでいうと、ホワイトボードをmiroやjamboardなどで代替したり、雑談のための時間を作ったり、雑談用Dicordチャンネルを作ったりといった具合。完全に同じ体験とはいえないけど、いくらかマシになる。

世の中のイメージと一致してるところ・違うなってところ

「運動不足になるでしょ」

はい。

そもそも自分は元々運動不足で、リモートワークになったことで、唯一体を動かすための通勤すら無くなってしまった。

ただ、「明らかにこのままでは死んでしまうな」という感じが湧いてきて、ここ半年ぐらいは毎日リングフィットアドベンチャーに勤しんでる。（プランク3000回やった）

改めて考えると、結果的には運動時間めっちゃ増えてるやんという謎現象が起きている。

「子供見ながら優雅に仕事できそう」

だいぶ厳しい。もう少し正確に言うと、可能だが凄まじく生産性が落ちて、やれる仕事が限られる。

コロナ前までは保育園様のおかげで安心して仕事ができていたが、我が家も無事に登園自粛の影響を受けて、在宅で子供を見ながら仕事をしてた。

本音を言うと「まぁ、そうはいってもなんとかなるっしょ〜〜」と思ってたけど、だいぶ無理でした。

とくに、一定の集中を求められる作業がだいぶキツかった。コードを書くのが特に厳しくて、単純なリファクタリングのような作業はできるけど、設計から挑むようなものは途中で声をかけられて思考が途切れてしまい、もう無理だなってなってた。

また、子供が退屈そうにしているのを放置している感にもすごく罪悪感があって、想像の倍くらい疲弊してた。

幸い会社に理解があったのでなんとかなったけど、誤った理解を持っている環境での仕事だったらと考えるとゾッとする。

「在宅勤務なら子供家で見れますよね」という考えは幻想だと思う。

「なんか楽そう」

YESでもありNOでもある。

リモートワークによって得られる恩恵は確かに良いものがあって、お昼休みにゆっくりリビングでテレビ見ながら冷凍食品食べていられるのは快適だな〜と思う。

ただ、仕事面では全然そんなことはなくて、むしろ気を払うところが増える。

たとえば、テキスト上のコミュニケーションでは「わかりません。」とだけ一言だけ書くと「ちょっとわからない部分がある」「全然わからない」「あなたのことが理解できない。」のどれにでも受け取れるわけで、期待通りのやりとりができるように、ひとつひとつの言い回しを気をつけてる。

また、オフィスでは働いている過程が見えるため、成果物がなくても「頑張ってたけどダメだったんだな」と勝手に理解してくれることもあるが、リモートワークだと「成果物なし」で終わってしまうリスクがある。そのため、成果物として何を出せているか or 過程をいかに表現して細かく伝えていくかを意識し続けないといけないな〜と感じてる。

人との物理的な距離が近かったことで省略されていたことを、リモートになると目に見える形にしていかねばならないコストは、ある程度はリモートワーカーのひとりひとりが担う必要がある。

「仕事サボってるかどうチェックすんの？」

「本質的に意味のない疑問である」が答えになりそう。

そもそもリモートワークでサボる人は、オフィスでも仕事してる感出してるだけでサボってる。これはリモートワークに長い間関わっている人と話すとだいたい同じ意見になる。

これはおそらく「仕事 = かけた時間」という発想だと出てくる疑問なのかもしれない。時間をそのまま価値に置き換えていると、「ただ存在するだけで良いじゃん！」という不動産みたいな発想になる。

リモートワークにおいては、人が働いている時間を管理するコスト自体が非常に高いというか、人が働いているかチェックする仕事があるとすれば、それ自体が意味ないなって気がする。

大前提として「自分たちにおける仕事って何？」という発想を持った方がよいのかもしれない。

リモートワークで大事にしたほうがいいこと

リモートワーク / 非リモートワークの壁を減らす

「リモートワークの人」「オフィスの人」みたいな垣根は限界まで減らした方が良い。

たとえば、自分の現在の働き方では全員がリモートワークに関する制限が無いスタイルで動いているが、それでも一応オフィスは存在していて、オフィス数人＆自分リモートみたいな形のミーティングをすることもある。その際は、全員がリモート慣れしているにも関わらず、オフィス側との若干の温度差というか、喋りづらさは発生する。

おそらく意識せずにやってしまうと、オフィスの人だけで喋ってしまってリモートが置いてけぼりと言った状況は簡単に発生する。

リモートワークでは特有の課題が多く発生していくが、「リモートワークの人」「オフィスの人」といった区分けを作ってしまうと、リモートワークの課題は「リモートワークの人の課題」になってしまう。

解決も遅れるし、何なら協調しないと解決できないものもあり、結果的に全体がマイナスになる。

たとえば「オフィス側のマイク品質が悪くてめっちゃノイズが入る」といった場合、リモート側が言わないと永遠に解消されない。逆に、全員がリモートワーク前提であれば、「全員の共通課題」になるため、効率よく解決していくことができるし、共感も得やすい。

一緒に働く人の間で、情報や温度感をできるだけ減らしていく必要があると思う。

リモートワークだけ可能にしてもダメだとおもう

リモートワークは「家やコワーキングスペースで自由に仕事ができるようにしたよ！よかったね！！！」で終わりじゃなくて、全体の制度だったり姿勢も伴っていないと破綻するか、どこかで歪みが生まれてきそう。

たとえば「サボってるかどうかどう判断すんの？」みたいな発想よりかは、「そもそもサボらないような信用のおける人をコストをかけて採用する」「評価の仕組み自体を見直す」といった方向に舵を切る方が健全。

「リモートワーク以外を全てそのままでリモートワークだけやれるようにする」というのはだいぶ無理があるというか、かなりの縛りプレイになるので、高難易度なんだろうなぁと思う。

性善説のほうが良さげ

基本的に一緒に働くメンバーを信用して仕事したほうが捗ると思う。

正直自分は人を疑ってしまうタイプで、街中で向こうから話しかけてくる人はすべて詐欺師だと思えぐらいの感覚で生きている節があるが、いま一緒に仕事をしているメンバーは全員信用・信頼している。

信用しているからこそ、たとえば仕事で成果が出なかったとしても「何か困ってるだろうから助けられないかな？」と思えるし、自分もビビらずに助けを求められる。テキストベースで短い文章でも「これは攻撃的な文章だ」と受け取ることはない。

さらにいえば会社と個人間でも性善説であれば「サボってないか椅子に座っている時間をチェックしよう！！」みたいな方向に発想が飛ぶこともなくて済む。

ただ、人を信じるためには信じられる人とチームを構築する必要があって「はい！！明日からみんなお互いを信じましょう！！」みたいな学級会みたいなことは出来ない。時間をかけて、状況によっては小さいチームから醸成していく必要があるんだろうなぁと思ってる。

今後さらにリモートワークは増えていくか

増えていくと思う。

誰もが知ってる通りコロナの影響で多くの企業が問答無用でリモートワークと向き合うことになっていて、同時に、実際やってみて「なんだ、リモートいけるやん」となったところも多いと予想してる。

コロナで今後どの程度世の中が元に戻ってくれるのかはわからないけど、わざわざ投資した設備や整えた制度を全部は捨てないだろうし、今後も継続してリモートワーク可能になっていくところは増えていきそう。

地方には関係ないか？

死ぬほど関係あると思う。

リモートワークを導入した企業がある程度落ち着いて、次に何があるかを考えると、採用活動の対象が全国に広がっていくと予想される。そうなると地方企業は関係がある無いとか以前の問題で、働く内容や賃金面で圧倒的に好条件を叩き出す都会圏の企業と人材を奪い合う形になる。

そうなると地方企業的は今まで通りの採用活動では人材確保のハードルが上がるため、対策として手っ取り早いのは、地方でもリモートワークで全国を対象に採用することになりそうだなぁと思う。

まあ正直自分がリモートワーカーなので「そうなってほしいな」という気持ちが無いと言うとウソになるけど、そういう未来になったほうが、働く側にとっても居住地に縛られずに柔軟に仕事を選べる理想的な環境になるな〜と思ってる。

リモートワーク最高？

と思われがちだが、自分はどちらかというと「リモートワークしなくていいならしたくない」派。どこでもドアがあったら出社する。ドラえもんはやく。

自分はリモートワークは目的ではなく手段であるとずっと思っていて、「何かを得るためにリモートワークという方法で実現する」という発想は常に持ってる。

もし今後、環境を変えてリモートワークという働き方を検討している人がいれば「なぜリモートワークをしたいのか？」を熟考したほうが幸せになれそう。

決して楽しいことばかりの働き方ではないけど、リモートワーク以外の部分で根本に思っている部分があれば乗り越えていけるんじゃないかなぁと思う。

おわり

BuriKaigi2020主催参加＆発表してきた

富山 勉強会 BuriKaigi

富山県では Tech系のセッションを楽しんでから、富山の本物のブリを楽しむ "BuriKaigi" という何やらコンテキストの理解が難しい名物イベントが例年冬になると開催されている。

BuriKaigi2020 & Ruby

というわけで今年もBuriKaigiが開催された。

toyama-eng.connpass.com

昨年までは一般枠で参加して、酔った勢いで軽減税率をdisるLT*1をするなど自由気ままに楽しんでいたが、今年は主催側の一人として参加した。

BuriKaigiは昨年までは、基本的にはJava系とMS系の2トラック構成だったという認識をしているが、先日開催した富山Ruby会議*2が有難いことに想像を超える大盛況となり、そこからの流れで主催のなぎせさん(@nagise)から「今回はRubyトラックもやろう」というお話を頂いた。

富山Ruby会議では自分はあくまでもメインスタッフの一人という位置付けだったので、「よーし今度は自分ががんばるぞ！」という気持ちで引き受けた。

なんやかんやあって自分も話した

富山Ruby会議はそれなりの準備期間があったので、スピーカー調整をする時間も十分にあったが、今回は引き受けてからの期間が短かったこともあり、枠をすべて埋めることができなかった。（くやしい）

そんな中、Ruby枠で発表して頂いた皆様には心より感謝しています。

最終的には25分が2枠余ったので、同じくRuby枠の調整をしていたふぁらお加藤さん@PharaohKJと私で1枠ずつ話すことにした。

話したこと

自分がそこそこ知見があるということもあり、最初はレガシー改善系の話をしようかと思ったが、つい最近のKanazawa.jsでのLTで同じネタを使ってしまい、しかも予想よりも反響があったので「さすがに同じ話をこの短期間でするのは何か負けた気がする」ということで、まったく別の話を考えることにした。

Vue.jsのwatchやらcomputedやらの仕組みを話そうかな、とかも思い浮かんだけど、参加者層的にフロントエンドの話はあんまり面白くないかもな〜と思ったのと「Ruby枠として調整してる自分が一体何を..!?」というので踏みとどまった。

最終的には、Ruby枠で話す唯一の地元富山県在住のスピーカーは私だけだな、と気づいたこともあり、せっかくなら富山に生きるエンジニアとして、ここまでの数年間を振り返ってみる話をすることにした。（結局Rubyの話をしていない）

「自分の話」を発表するにあたって、資料や話すときに激しく気を使ったのが、なんというか「どうだ！すごいだろう！！」みたいな雰囲気にならないようにする点だった。

自分の話をするということは、自分が過去に何かを選択したときの話をすることになるが、それはつまり逆側の選択をしている人から見ると「それは違うだろ」と感じる可能性もある。

あくまでも "自分のここまでを振り返ったときの個人の意見です" という点に注意して、誰かを傷つけたりすることのないように、かつポジティブな内容になるよう配慮したつもりではある。

なお当初は、「なんやかんやあったけど技術書典出たら本出せて楽しかったよ！！」 的な話をしようと思ってた。ただ、資料を作ってるうちに 「別に技術書典自体が根幹にあるわけではないのでは...??」 と思い始め、自分は一体何をしたんだ..?と考えた結果を自分なりに解釈した結果、深夜に吐き出されたものとなっている。

参加者としての感想

ずっとRubyのセッションが集中しているルームCにいた。

全セッションとても楽しく聞いていたが、個人的に強い関心があったことから、直接DMを送って登壇をお願いした フィヨルドブートキャンプ @komagataさんの話がとてもよかった。富山という遠い地での登壇を快諾頂き感謝申し上げます。

ボンヤリとプログラミング教育的な部分に関心を持っていたのと、ここ最近世の中に漂うエンジニア爆アゲみたいな空気感にずっとモヤモヤしてて、それが自分だけのものなのかを確認したかったというのがあった。セッション内容だけではなく、懇親会含めてお話できて色々とスッキリした。ありがとうございました。

来年以降

BuriKaigiの運営Slackに早くも#2021チャンネルが爆誕していたので、主催者側の一人として来年も頑張ることはとりあえず確定した模様。

発表者としては、「地方エンジニアとしての話を地方でする」というのは一定の需要があるとは思っている。ただ、もし外部から要望を受けたら話すとは思うけど、自分からこういったネタを積極的に持ってくるのは暫く控えようと思う。

こういう話ばかりを続けるのは、胡散臭い自己啓発セミナーの類に近づいてしまう気がするし、そういうのじゃなくて技術的な面で発表して、間接的に地方エンジニアとしてアピールしていきたい。

もし来年も機会があれば、今度は技術ネタで登壇するぞ！と思った。

そんなことよりブリしゃぶですよ！！！

で、そんなことよりもですね！！！

今年のブリしゃぶが本当にヤバかったんですよ。

毎年BuriKaigiのブリしゃぶは絶品なのだが、今年はなんというかレベルが違った。 （なお数年前も同じ会場だったらしい）

f:id:mugi1:20200201200007j:plain
富山の地酒をすべて鍋に突っ込むという狂気

f:id:mugi1:20200201200744j:plain
着火

f:id:mugi1:20200201195428j:plain
１人前が通常の店の４人前ぐらい繰り出されるブリ

めちゃくちゃ美味しかった。 来年も楽しみです！！

*1:https://speakerdeck.com/mugi_uno/xiao-fei-shui-qing-jian-shui-lu-zhi-du

*2:https://toyamarb.github.io/toyama-rubykaigi01/