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

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

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

脊柱側湾症とはなんぞや

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

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

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

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

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

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

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

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

ただ、

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

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

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

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

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

〜30分後〜

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

私「!?」

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

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

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

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

手術の内容

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

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

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

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

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

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

手術を受けることにした

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

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

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

手術日まで何をしたのか

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

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

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

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

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

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

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

手術日前日(入院)

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

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

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

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

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

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

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

手術日以降

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

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

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

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

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

術後〜手術翌日

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

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

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

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

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

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

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

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

術後2日目

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

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

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

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

術後3〜4日目

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

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

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

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

術後5〜7日目

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

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

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

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

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

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

術後8〜10日目

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

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

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

www.pokemon.co.jp

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

術後11〜14日目

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

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

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

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

術後15日目〜18日目

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

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

術後19日目

退院。

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

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

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

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

術後3週間

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

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

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

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

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

術後1ヶ月〜

今この記事を書いてる。

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

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

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

術後1ヶ月時点での感想

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

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

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

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

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

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

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

個室

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

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

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

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

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

Nintendo Switch

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

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

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

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

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

調味料

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

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

手術費用

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

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

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

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


そういうわけで

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

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

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

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

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

注意事項

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

はい。

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

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

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

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

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

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

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

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

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

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

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

「なんか楽そう」

YESでもありNOでもある。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

性善説のほうが良さげ

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

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

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

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

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

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

増えていくと思う。

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

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

地方には関係ないか?

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

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

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

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

リモートワーク最高?

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

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

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

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


おわり

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

富山県では 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人前が通常の店の4人前ぐらい繰り出されるブリ

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

地方での勉強会を4年間続けるために必要だったもの

※このエントリは 第二弾 地方IT勉強会 Advent Calendar 2019 14日目の記事です。

Toyama.rbという勉強会をはじめて4年経った

私は富山県で、Toyama.rbというコミュティを主催しており、月に1度ほどのペースでもくもく会を中心とした勉強会を開催してます。

toyamarb.github.io

現在このエントリも、もくもく会の中で書いてます。

このエントリ投稿が2019年12月で、第1回のもくもく会を開催したのが2015年の12月なので、まる4年間続けたことになります。

地方勉強会の厳しさ

地方で勉強会を続けるには様々なハードルがあります。

  • 会場の確保
    • 都会のように勉強会支援に積極的な企業は多くない
  • 参加者が少ない
    • そもそも「勉強会いくぞ!」という人の絶対数が少ない
  • ネタが続かない

勉強会をはじめたものの、続かずに消えていくケースもあるようです。

なぜ4年も続いたのかを考えてみる

いまとなっては毎月第2土曜日になると当然のようにもくもく会を開催していますが、あらためて「なんでこんなに続いたんだろう??」と考えてみると、色々と気づきがありました。

「開催する」を最優先のテーマにしていた

Toyama.rbで私が一番重要視しているのは「開催する」ことです。 他にも「できるだけ手を動かして学びたい」とかも思ってはいるのですが、大前提としては開催することに重きを置いています。

開催日時は固定化する

これはお隣である石川県のkanazawa.rbを参考にした点です。 参加者が予定をつけやすいように、開催日時を固定化しており、 Toyama.rbの場合は毎月第2土曜日の午後と決めています。

特に家族がいる場合などは、突発的に勉強会があっても予定を合わせづらいものです。

定期的に決まったサイクルで開催されていれば、参加者としてもわかりやすくなります。

とにかく「開催はしてるんで!」というスタンス

Toyama.rbの紹介をするときに「参加者が私一人だとしても会場はあるんで!」とよく言ってます。 もし私が都合がつかない場合、他のメンバーに主催をお願いして継続開催しています。 実際にはそれでも都合がつかず開催できなかったことが1〜2回ほどあったのですが、 「毎月やってるToyama.rb」というイメージが大事だと思っています。

基本的にテーマは絞らない

Toyama.rbは、基本的にもくもく会が中心です。

もくもく会って何? - NAVER まとめ

Rubyコミュニティではあるのですが、このもくもく会Rubyへの縛りは一切ありません。

f:id:mugi1:20191214135339p:plain
Toyama.rbの紹介時に使っているスライド

もちろんテーマを絞ったほうが、ディープな話ができるなどメリットもありますが、そのぶん人を集めるコストが上がります。 「なんでもオッケーですよ!」というスタンスでやってるので、わりと初心者の方も参加してくれています。

がんばらなくても開催できるようにする

もくもく会の特徴としては

  • 準備はほぼ何もいらない
  • ひとりでもやれる

といった特徴があります。とにかく会場を抑えて行けさえすれば開催できます。

これが重要で、主催者だって仕事やプライベートが慌ただしいこともありますし、 なんならあんまりやる気が出ないときだってあるでしょう。

基本的なイベントを準備が不要なものにしておくことで、「とりあえず開催する」ということも可能になります。

そんな中で、たまに色のついたイベントを混ぜることで、程よい頑張りと刺激でコミュニティを継続できていると思います。

とにかく続けたから出来ることもある

そんなこんなでゆる〜く続けてきました。

先日、初回から参加してくれている@kunitooをオーガナイザとして、富山Ruby会議が開催できました。 私はあくまでもスタッフの一人としての参加でしたが、「こういった大きいイベントをやろう」と切り出せる場を提供できていたことが何より嬉しかったです。 Toyama.rbをはじめて数回のタイミングでそういった話は現実味はなかったと思いますし、長く続けてきたからこそ実現に繋がった部分があったかな〜と(個人的に)思ってます。

まとめ

そういうわけで、地方で勉強会をやる一つの戦略として「がんばらずにとにかく開催する」という方法もあるよ、というお話でした。

次回、 第二弾 地方IT勉強会 Advent Calendar 2019 15日目は、同じく北陸である福井県のふくもく会のお話のようです。

地方勉強会としてはさらに先輩にあたるので、たのしみですね!

「レガシーフロントエンド安全改善ガイド」を商業出版します #技術書典

※2019/11/8: 無料サンプルと目次を記事内に追加しました。

f:id:mugi1:20191105233030j:plain:w400

2019年4月に開催された技術書典6で頒布した「レガシーフロントエンド安全改善ガイド」ですが、このたびインプレスR&D社さまより商業版を刊行することになりました。

自分が商業版の技術書を書く日が来るとは思わなかったのでビクビクしています。

nextpublishing.jp

表紙イラストは同人版と同様、鍋料理さんに描いていただきました。「安全な感じで!」という相談から、カワイイ工事現場が仕上がりました、とても気に入ってます。工事現場本と呼んでください。

タイトルに「迷わない!困らない!」という強気ワードが付いててちょっぴり恥ずかしいですが、迷わず困らない内容になってる・・はずです!

同人版との違い / 加筆・修正した点

紙の本で比較すると、ページ数が110ページ程度→200ページ超と大幅に加筆しています。 同人版のときは印刷費用なども怖くてあえて書かなかった部分がたくさんあったのですが、それらもすべて盛り込んだ結果、大変なことになりました。

すべてのコードをTypeScriptベースに変更

同人版では、改善後のコードはBabelを利用したESNextのコードとしており、TypeScriptについては「かなり流行ってるし、こちらもオススメだよ」程度に触れていました。

しかし、「これからレガシーフロントエンドを改善するのであれば、選択肢としてTypeScriptを無視するのはありえないだろう」と考え、すべての改善後コードをTypeScriptを前提とした形に変更しています。

結果的には、サンプルコードを含めたすべてのコードを書き直すことになって死ぬかと思いました。

TypeScript導入に関する章を追加

全コードがTypeScript前提となったので、TypeScript導入に関するセクションも追加しています。主にツラい環境への段階的な導入にフォーカスを置いています。

  • どういった設定から始めたらよいのか
  • 型定義で落ちる部分はどう対処したらいいのか
  • anyとどう向き合えばいいのか

といった、既存コードベースに導入する際に困る点を詳細に書いたつもりです。

全体的に解説部分と実践編とで分離

同人版は、一冊を通してサンプルコードをひたすら書き換えていくような内容になっていました。 これはこれで写経とかもできて楽しかったのですが、読む本としてはツラいものがあるだろうな〜と思っていました。

そこで商業版では、各章ごとに基本的な解説を用意した上で、章末尾に実践編として同人版のようなサンプルコードの書き換え例を紹介する形としています。

情報だけざっと読みたいんじゃ〜〜、という方は各章の前半部を見てもらえればOKですし、さらに深く理解したい場合には、1章ずつ実践編をこなしていくことで、同人版と同様に手を動かして書き換えの流れを追うことも可能になっています。

ESLint/Prettierの章を追加

  • そもそもなぜLintツールが必要なのか?
  • 段階的に導入するためにはどうしたらよいか?

といった点をがっつり書いています。 TypeScriptと組み合わせた場合のtypescript-eslintの導入も紹介しています。

Vue.jsに関する説明も掘り下げ

本書後半では、jQueryなどで書かれたレガシーコードからの書き換え先として、主にVue.jsを取り上げて紹介しています。

同人版ではひたすらサンプルコードを書き換えつつ紹介していましたが、レガシーコードとは根本的な考え方が異なり困惑する部分も多いかなと思ったため、簡単なモーダル表示なども例にあげつつ、同人版よりかなり掘り下げて書いています。

その他

他にもさまざまな加筆・修正が入っています。

  • パッケージ管理ってどうしたらいいのか
  • サーバサイドでレンダリングされるテンプレート依存のコードへのテストをどう書くか
  • 改善完了後にどうしたらいいか
  • などなど...

(足しすぎてもはや自分でもよくわからない)

どんな方にオススメか

次のような方が想定読者です(本書内に書いてある内容と同一です)

  • レガシーフロントエンドから脱却する現実的な方法を知りたい
  • モダンなツール・ライブラリーのメリットや導入方法を知りたい
  • 改善作業における心構えやノウハウを知りたい
  • 改善作業をしたいが何から手をつけたらよいかわからない
  • 実践的に手を動かしてモダンな技術要素を学びたい

JavaScriptを利用したフロントエンド開発における基礎的な部分の説明は省略しています。DOM などのピンと来ない場合には少し難しいかもしれません。

無料サンプル

1章までの無料サンプルです。なんとなくの雰囲気はわかるかもしれません。

目次

目次も以下に載せておきます。いっぱい書いたな..って気持ちになりました。

第1章 改善の前に 
  1.1 改善作業に伴うさまざまなリスク 
  1.2 改善で得たいものは何か? 
  1.3 「安全」な改善とは 
  1.4 リスクを軽減する 

第2章 レガシーコードを理解する 
  2.1 いきなりコードを変更しない 
  2.2 DOMの扱いで分離する
    - Write/書き込み
    - Read/読み込み
    - Event/イベントハンドリング
  2.3 理解を記録として残す 
    - 資料化して残す 
    - コードコメントに残す 
  2.4 自分の理解度を確認する 

第3章 パッケージ管理 
  3.1 手動によるパッケージ管理は大変 
    - バージョン管理のコスト 
    - 依存ライブラリーの取り扱い 
    - 環境の再現 
  3.2 パッケージマネージャー 
  3.3 npmの導入 
  3.4 dependenciesとdevDependencies 
  3.5 npxによるコマンドの実行 
  3.6 実践編:パッケージ管理 

第4章 テストコードを用意する 
  4.1 変更前の挙動をテストコードで保証する 
  4.2 E2Eテスト
    - Jest と Puppeteer による E2E テスト 
    - ブラウザーを起動して E2E テストを目視で確認する 
    - テストはモダンに書く 
  4.3 ビジュアルリグレッションテスト 
    - jest-image-snapshot 
    - threshold(しきい値)の調整 
    - reg-suit 
  4.4 スナップショットテスト(HTML)
    - HTML ベースのスナップショットテストの位置付け 
    - E2E テストの範囲 
  4.5 テンプレートがサーバーサイドに依存するケースへの対処 
    - JavaScriptのRead/Writeに注目したテストを書く
  4.6 実践編:テストコードを用意する 
    - E2Eテスト
    - ビジュアルリグレッションテスト
    - スナップショットテスト 
    - npm-scripts の登録
    - テストコードの準備完了 

第5章 ESLint/Prettier
  5.1 コードの記法による潜在的なリスク 
  5.2 人の手によるチェックの限界 
    - 見落とす 
    - 人によって好みが出る 
    - 指摘する・されることの心理的な負担
    - 解決策→機械にやらせよう! 
  5.3 ESLint 
    - ESLint の導入 
    - 公開されている ESLint 設定を流用する 
    - ESLintを少しずつ適用する 
    - 一度すべて無効にして1ルールずつ有効化する
    - --fix オプションが機能するものから対応していく 
    - 対応できない箇所 
  5.4 Prettier 
    - Prettier の導入 
    - 設定のカスタマイズ 
    - ESLint と併用する 
    - 自動整形によるコードへの影響 
  5.5 実践編:ESLint/Prettier
    - 一部ルールの無効化 
    - グローバル値への対処 
    - ESLint/Prettier の導入完了 

第6章 TypeScript
  6.1 TypeScript 
  6.2 型の恩恵 
  6.3 TypeScriptかECMAScript(Babel)か 
  6.4 完全な型定義はとても大変 
    - 最小のコストで最大の恩恵を得る
    - anyと上手に付き合う
  6.5 TypeScriptのセットアップ
    - --init で生成される tsconfig.json
    - その他の変更したほうがよいオプション
    - 最終的な tsconfig.json のサンプル
  6.6 ライブラリーの型定義 
    - 公開されている型定義を利用する
    - 独自で型定義を用意する 
    - 基本的には any で推論されるが...? 
  6.7 グローバルの値の型定義 
  6.8 TypeScript ESLint 
    - ESLint と TSLint 
    - typescript-eslintの追加と設定
  6.9 実践編:TypeScript
    - テストコードを TypeScript 化 
    - TODOアプリ本体のコードをTypeScript化 
    - TypeScript ESLintの追加
    - TypeScript 化の完了 

第7章 モジュール分割 
  7.1 小さく切り出す 
  7.2 モジュール管理とモジュールバンドラ 
    - TypeScript とモジュール管理 
  7.3 webpackのインストールと設定 
    - watchモードでwebpackを起動する
  7.4 ライブラリーをnpmパッケージへ移行する 
  7.5 コードを分割する 
  7.6 実践編:モジュール分割 
    - webpack の導入 
    - jQuery を npm パッケージ利用に置き換える
    - Read 部を切り出す 
    - Write 部を切り出す 
    - モジュール分割の完了
 
第8章 Vue.js(セットアップ) 
  8.1 DOM が中心であることのデメリット 
    - 複雑化しやすい 
    - データと HTML の関連が不明瞭 
  8.2 宣言的テンプレートと状態管理へ 
    - Vue.js 
  8.3 Vue.js のセットアップ 
    - SFC(Single File Components) 
    - SFC のビルド設定 
  8.4 Vue.js と TypeScript を組み合わせる 
    - Vue.extend 
    - クラススタイルコンポーネント 
  8.5 Vue.js DevTools 
  8.6 Vue.js の基本知識 
    - コンポーネントの基本的な構成要素
  8.7 実践編:Vue.js(セットアップ編)
    - SFC のビルド設定 
    - 動作確認 
    - Vue.js のセットアップ完了 

第9章 Vue.js(移行の予備知識) 
  9.1 移行時に発生しやすい問題 
    - イベントバインドのタイミング 
    - DOM 書き換えの競合 
    - 非同期の DOM 更新 
    - 空白文字による差異 
  9.2 目指すべき理想構成 
    - 責務の閉じたコンポーネントの集合体にする 
    - 単方向データフロー 
    - データの集約 

第10章 Vue.js(移行編)
  10.1 Read/Write/Event との対応 
    - Read 
    - Write 
    - Event
  10.2 シンプルな Write 部から切り出す 
    - コンポーネントへの切り出し 
    - Vue.js とレガシーフロントエンドコードとの連携 
  10.3 Publish/Subscribeモデル(EventBus)
    - EventBus は一時的な措置 
  10.4 Vue.observable 
    - 段階的に移行しつつデータを集約する
    - Vue.observable を安全に使う 
  10.5 Vuex 
    - Vuex を使うかどうか 
  10.6  DOM をデータで表現する 
    - 入力フォーム 
    - 連続した類似要素 
    - 表示・非表示の切り替え 
  10.7 切り出したコンポーネントに親子関係を作る 
  10.8 実践編:Vue.js(移行編) 
    - テストコードについて 
    - Write 部の切り出し 
    - Vue.observable データストアの作成 
    - DOM をデータで表現する 
    - Vue.js 化に伴う問題に対処する
    - Write 部の撤廃 
    - Read 部の Vue.js 化 
    - 単方向フローを構築して全体を整理する
    - データストアをどうする? 
    - 最終的な状態

第11章 リリースまでを安全に
  11.1 レビュワーの負担を下げる 
    - 改善作業のレビューはつらい 
    - レビューボリュームを小さくする
    - 確認してほしい観点を明確にする
    - 資料化を怠らない 
    - ペアプロ・モブプロ 
  11.2 改善するスコープを決める 
  11.3 トラブル発生時のダメージを軽減する 
    - ロールバックを想定する 
    - ピークタイムのリリースを避ける
    - 小さく進められないときにも有効

第12章 改善できた、次はどうする?
  12.1 時と共にレガシー化は進む 
  12.2 日々改善を続ける 
  12.3 機械的に改善可能な環境を整える 
    - テストコード作成の習慣化 
    - CI 環境を整える 
    - Dependabotによる依存ライブラリーの更新
  12.4 改善作業は終わらない 

というわけで...

技術書典6のときに、物理本が完売してしまって買えなかった方もいたのが心残りでした。 この本が一人でも多くのレガシーフロントエンドで悩む方の助けになれば嬉しく思います。

パワーアップした「レガシーフロントエンド安全改善ガイド」をよろしくお願いします🙏

富山Ruby会議開催前のよもやま話

f:id:mugi1:20191029234042p:plain

2019/11/03(日)に北陸初の地域Ruby会議となる、富山Ruby会議が開催されます。

toyamarb.github.io

私は主催者というわけではないですが、メインスタッフの一人としてせっせとお手伝いをしています。

富山県Rubyコミュニティが無いことを知り、Toyama.rbを始めたのが2015年の12月。そこから、小さいながらも毎月もくもく会を中心とした活動を続け、2019年10月の(台風で中止になった)活動で45回目となりました。

そんな中、第1回から参加してくれておりToyama.rbの運営にも協力してくれている @kunitoo さんが「富山で地域Ruby会議をやりたいです!」と提言してくれたので、同じく第1回から参加の @noboru_i さんと共に、メインスタッフとして支える形で開催に向けて色々と準備を進めております。

数年前はコミュニティすら存在しなかった地元富山県で、超豪華なスピーカーをお招きして地域Ruby会議を開催できることになったというのは、なかなかに感慨深いものが...

富山Ruby会議のテーマ

テーマはRubyと富山を楽しみ知ってもらう」です。

県外の方には富山を存分に楽しんでいってもらえるといいかなと思います。ブラックラーメンを食べる時だけは覚悟してから行ってください。

そして...

富山 or 北陸のかたへ

富山の方には「Ruby」そのものを知ってもらいたいと思っています。

単純にRubyというプログラミング言語を勉強していけというイベントではありません。Rubyという言語の可能性とそれを支える人やコミュニティがどういったものかを富山Ruby会議を通じて一人でも多くの方に伝えられたら嬉しいなと思ってます。

そのため、当日のセッション内容も非常に間口の広い内容になっています。

招待講演となる松本宗太郎さんの「型なし言語のための型」と伊藤淳一さんの「○○からRubyへ」の内容の違いが特に象徴的ではないかと思います。(私も超聞きたい)

主催の自分が言うのもアレですが、富山にいてこれだけのイベントを今後やれるかどうかはわからない部分もあるほど貴重な機会ですので、悩んでいる場合にはぜひ参加してみることをオススメします。

ちなみに...

もし富山を含む北陸圏の方で参加を悩んでいる方がいた場合、次のような理由なのかな〜と勝手に予想しています。

  • Ruby?普段はJava or .NET or C#しか触らないからな〜
  • 勉強会とか参加したことないしな〜
  • 会社で行けって言われる研修とかつまらないし、そんなのだろうな〜

当たらずとも遠からずではないでしょうか。 というのも、これは数年前の自分がこうだっただけで、ゴリゴリにJavaを中心とした受託の仕事をしていましたし、勉強会みたいなものは存在も知りませんでした。

それが数年たった今はRubyを使いつつリモートワーカーとして仕事をしています。(最近はTypeScriptしか書いてませんが)

色々考えてみると、今に繋がる大きなきっかけの一つは4年前に兵庫で行われたRubyプログラミングキャンプに思い切って参加してみたことです。

mugi1.hateblo.jp

勉強会に1回も参加したこともないのに、とりあえず兵庫まで乗り込むという、今考えるとぶっ飛んだ行動してるなって思う節もありますが、確実にあそこから色々人生が変わったな〜という実感もあります。

ただ「Rubyを学んだからこうなった」と直接思っているわけではないです。もちろんRubyは間接的に自分を助けてくれましたが、一番大きかったのはRuby界隈に存在する人やコミュニティの空気に触れたことで、富山にいただけでは得るのが難しい考え方や姿勢を学ぶことができたことかなと思います。

よく地方と都会でのITの技術格差みたいな話題を耳にします。 もちろん地方では勉強会も少なくてトレンドを追うだけでも一苦労ですが、何よりも「技術たのしい!!たのしい!!」みたいな空気感を浴びる機会が少ないことが一番致命的な問題に感じています。興味ない人のほうが多数派なんですよね。

私は兵庫まで行きましたが、今その刺激のある空気感が富山に来ようとしています。これは参加するしかないですね!!!

ということで、影響は小さいかもしれませんが、富山Ruby会議を通じて少しでも地元に良い影響を与えることができたら嬉しいなって思います。

そしてここからは正直な話

と、ちょっとエモいようなことを書いていい感じの話のような雰囲気を出してますが、結局のところ「細かいことはいいから富山Ruby会議参加してくれると嬉しいです!!!!」というだけなのでよろしくね!!!

toyamarb.connpass.com

ちなみに本編の参加ももちろん嬉しいですが、懇親会もぜひ参加するといいですよ!このお店のお鮨は美味しいよ!!!

toyamarb.connpass.com

※なお、懇親会会場のお店からは少なくとも30人でという話で貸切になっているところが、現状27人ほどなので、マジでこちらもみんな来てほしい。メインスタッフのお財布事情の危機かもしれない。(切実)

技術書典6で「jQuery to Vue.jsで学ぶ レガシーフロントエンド安全改善ガイド」という本を出します #技術書典

1章のみを無料サンプルとして公開しています。

タイトルのとおり、4/14の技術書典6で「jQuery to Vue.jsで学ぶ レガシーフロントエンド安全改善ガイド」という本を頒布します。

技術同人誌というものを初めて書いていますが、せっかくなら一人でも多くの方に見てもらえると嬉しいので、宣伝させてください。

f:id:mugi1:20190312232505p:plain

表紙イラストは鍋料理さん(@yaminaberyouri)に描いていただきました!めっちゃステキ。

目次

  • 1-4章 : 改善のための心構えやレガシーコードの理解、着手前の準備について
  • 5-7章 : サンプルコードをjQuery to Vue.jsに実際に書き換えていく具体例
  • 8章 : コード以外の面で改善をうまく進めていくための話

のような構成になっています。 (なお現在校正作業中なので、内容は多少変わる可能性があります。)

f:id:mugi1:20190312234156p:plain:w400 f:id:mugi1:20190312234207p:plain:w400 f:id:mugi1:20190312234218p:plain:w400

どんな内容?

表紙はとってもカワイイですが、私がここ2年ほどやってきたフロントエンドの改善経験がベースになっているため、中身はゴリゴリに現実的な話になっています。

jQuery to Vue.js とありますが、内容の本質は「安全なレガシーコードの改善」です。 安全とはデグレを減らすといった意味合いもありますが、何よりも心理的安全をどう確保しながらリファクタリングを進めるかについて、心構えや準備に加え、テストコード・コード分割・レビュー戦略など、様々な観点からのアプローチを紹介しています。

そして、jQuery to Vue.jsを実際に書き換える流れを段階的に追っていくことで実践的に学べるようになっています。

Vue.jsに限らず、流行りのフレームワーク・ライブラリを導入しようとしたときに、ゼロベースでの構築方法の情報はたくさん見つけることができますが、稼働しているリアルな現場に投入するための情報というのはあまり存在せず、実際やろうと思うとかなり苦労します。

というより、実際私がめっちゃ苦労した(している)ので、その経験から、どのようにやれば心臓をバクバクさせながらの恐怖のリリースをせずに済むのかをまとめています。

  • レガシーなフロントエンドコードに困っている・困りそう
  • フロントエンドのリファクタリングに興味がある
  • 改善作業についてのノウハウを知りたい
  • Vue.jsを導入しようと思っているがどうしたらいいかわからない
  • Vue.jsを手を動かしながら学ぶチュートリアルが欲しい

といった方にオススメです。

頒布数

現在悩み中です。100-150くらいを予定していますが、様子を見て増減したいと思います。


というわけで、よかったら当日買ってもらえると嬉しいです!

/ @mugi_uno

※なお、一瞬だけマルチカーソルの本を書こうかと思ったのは秘密です。