リモートワークを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

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

軽減税率制度について思うこと

ブリ会議2019の懇親会で、酔った勢いでToyama.rbの年末LT大会でやった軽減税率の話を再演した。

法律施行の10月まで使える鉄板ギャグみたいな扱いをしていて、軽減税率芸人になりつつある。が、正直なところ本当にこれはギャグみたいな話じゃないの?って思っているのも事実。

なんだかな〜?と思っている点がいくつかあるので、思考整理も含めてまとめてみたい。

注意点

私は法律の専門家でもなんでもない。ただの一般人のプログラマとしての視点で考えたときに、おかしいな〜、って思った部分を書いている。そのため、その筋のプロが見たら「それは違う」という点があるかもしれない可能性も理解している。けど、これは個人のブログなのでそういうもんだと思ってほしい。

軽減税率とは

特集-消費税の軽減税率制度 | 政府広報オンライン によると、

社会保障と税の一体改革の下、消費税率引上げに伴い、低所得者に配慮する観点から、「酒類・外食を除く飲食料品」と「定期購読契約が締結された週2回以上発行される新聞」を対象に消費税の「軽減税率制度」が実施されることになりました。

とのこと。これを前提として書いている。

対象外品目の判断基準が複雑

ニュースとかでも言われているので知ってる人も多いと思うが、対象品目の判断基準が非常にややこしい。対象外品目として挙げられているのが

だが、ケースバイケースで判断しないといけないものが非常に多い。

実際に、個別事例のQ&A資料が公開されており、80以上のケースがひとつずつ記載されている。

消費税の軽減税率制度に関するQ&A(個別事例編)|国税庁

施行前の段階ですでにこれだけのパターンが出てきているのであれば、施行後にはもっと混乱を招くのではないだろうかと思ってる。

ちなみに個人的に一番面白いと思ったのは、「映画館のポップコーンが外食かどうか?」というやつ。答えとしては

  • 基本的には8%(軽減税率対象)
  • だが、売り場の前に座席などを設けた場合には対象外になる可能性がある
    • 飲食させるためのスペースとして設けた場合には軽減税率対象外(10%)

こんなもんわかるかよって感じである。

酒類・外食などの対象外品目に該当するか?ばかり考慮されていることにそもそも違和感がある

上記の個別例の資料では、内容の殆どが「これは酒類か?」「これは外食か?」といった内容のQ&Aとなっている。

あらかじめ対象外品目の種類を設定したからだと思うが、そもそも軽減税率は大前提として低所得者に配慮する観点から」実施されるものだったと理解している。

実施するのであればそこが一番重要で、様々な判断基準の中心にならないといけないような気がしているのだが、結果としては誰が見ても「???」な判断になってしまうものが多い。

パッと思いつくようなものでも、

  • 水道水 = 飲食専用じゃないから10%(軽減税率対象外)
  • ワンコインでお店で食べる牛丼 = 外食なので10%(軽減税率対象外)
  • かぜ薬 = 10%(軽減税率対象外)
  • 超高級な食材や金箔をリッチに使ったお弁当をテイクアウト = 8%(軽減税率対象)

などがある。

低所得者に配慮する観点から」という前提で考えると明らかにおかしいのは誰が見てもわかるが、最初に「酒類・医薬品・外食・ケータリング」といった大前提を決めたうえでそこに該当するか?という判断基準ですべてを考えてしまっているため、明らかに無理が出ている。

そもそも飲食料品が軽減税率対象で8%になるが、所得が多ければそれだけ飲食料品にかけるコストも高いことが多いだろうし、それらも一律で8%になってしまうのであれば、果たして誰のための軽減なんだろう?と思ってしまう。

新聞が軽減税率対象である話

これはもうなんというか、アレですよね。

言うまでもない。

適格請求書における免税事業者の負担の話

軽減税率が施行されるのと同日に適格請求書というものが導入される。 コレ自体に関する詳しいところはここでは触れない。

適格請求書等保存方式の導入について|国税庁

だが、

  • 「適格請求書発行事業者」でなければこれは発行できない
  • 課税事業者でなければ「適格請求書発行事業者」にはなれない

という点だけは気になっていて、現状では売上が1000万以下の事業者は消費税納税が免除されるが、上記の通り、課税事業者でなければ適格請求書というものは発行できない。

これの何が問題なんだろう?という話だが、請求書を受け取った側が消費税を納税する際、仕入れにかかったぶんは控除出来るが、これが適格請求書であることが条件になる。

https://www.nta.go.jp/taxes/shiraberu/zeimokubetsu/shohi/keigenzeiritsu/pdf/300416.pdf

大企業などが従来の免税事業者から従来の請求書を受け取った場合、仕入れ分を控除できないので、本来より大きな消費税を負担して納税しないといけない、といった状態が発生する。

これは完全に損なので、免税事業者側から見ると「あっ、適格請求書発行できないなら取引やめますね」って言われて契約が終わってしまったりするかもしれない。

これはあきらかにアレなので、免税事業者も申請をすることで適格請求書発行事業者になることができるが、それはすなわち課税事業者になるということなので、今度は消費税の納税義務が発生する。

つまり、

  • 適格請求書を発行できないためのリスクを受け入れたまま免税事業者で居続ける
  • 今まで不要だった消費税の納税を行って課税事業者になる

のどちらかを迫られることになる。つらい。

結局、中小企業などが損をする形になるように見えるので、これでいいのか?と思ってしまう。

結局の所

軽減税率制度の根底にある思想とかそのものは理解できるが、現状ではなんのためにこれを実施するのか?というのがブレブレに感じるし、そのために皆が多大なるコストを払わないといけないのは割に合わない。

世の中を無駄に複雑にするのはやめてほしいな、という思いが強い。「無駄」というのが問題で、もちろんすべての事象が1か0かで表現できるとは思っていないが、1か0かに出来るものはそちらに倒したほうが、そこにかかるコストを他に使えて有益じゃないだろうか。

今の形では本来の目的である低所得者への配慮という点が満たせないだろうし、いっそのこと一律10%とかに上げてしまったほうがわかりやすいし皆幸せじゃないかなと思ってる。(それはそれでどうなんだっていう話もあるんだろうけど・・)

なおエンジニア的な話をすると、システムにおける改修コストもべらぼうに高いと思う。消費税率が5%から8%になったのとかとは違う次元。サマータイムの件も思い出すが、基本的にITわからない人たちが色々決めているんだろうな、と思うと色々と不安しかない。

以上。

なお

これを書いたのは、サマータイムなどと違って自分の仕事に直撃する人の割合が小さめなので、あんまり騒がれてはいないように感じているため、問題意識を世の中のエンジニアに一人でも共有しておきたいな、って思ったのがある。

もし意識せずマズいこと書いてて、どこかに怒られたら消します。

終わり。