| @旅行/散歩

アルプス遠征で白馬に行ったとき、福岡からは松本経由で行った。前の記事に書いている通り台風の影響で縦走の予定がピストンとなったため、松本を一日観光する時間ができた。

松本には去年の秋に友達の結婚式で行っていて、そのとき市内を少し観光してすごくいいところだなと思った。前回は帰りの飛行機の時間の都合でできなかったことがいくつかあり非常に悔やまれたので、今回は前回できなかったことをやってきた。

宿泊

泊まったのは花月というホテルで、結構よいホテルのなはずなのにハイシーズンにもかかわらず低価格で泊まることができたが、部屋に入って窓を開けるとこの景色でなるほどという感じだった(これはこれで面白くてテンション上がった)。

IMG_6027.jpg

昼食 1

松本には昼過ぎに着いたのでホテルに荷物を置きに行き、 The Source Diner に行った。ここには前回も来ていて、カウンターの席に座るとお店の人が料理している様子を眺めながら食事することができる。自分も料理するの好きなので目の前で料理してくれるタイプの店はプロの慣れた手さばきが見られてとても楽しい。

DSC_5954.jpgDSC_5960.jpg

物色

あたりをうろつく。ナワテ通り外れの角にあるポーランド食器のセラミカがよくて、以前来たとき器を買うか迷ったが荷物になることや結構高いこと( 21cm の皿でも 3000 円から 5000 円くらいする)、帰りの飛行機まで時間が限られていたことで決心しきれず、買わずに帰ってきてしまった。あとあとこのことが非常に悔やまれて、もしまた松本に行く機会があればセラミカを訪ねて皿を買いたいと思っていた。

買いたい器に目星をつけたが今日は荷物になるので買わないでおく。

コーヒー 1

その後、セラミカの器でコーヒーが飲める喫茶店「カフェあげつち」でコーヒーを飲んだ。この喫茶店は 300 円でコーヒーが飲めてレトロな家具や調度品が飾ってあり休憩にちょうどよい。観光客向けというより地元の人が談笑しに来ている感じ。年季の入った建物を修復して公営の会議スペースとして利用しているようである。

松本城

そこから松本城に行った。前回も今回もお城の中には入らなかった。入り口に「ここから 30 分待ち」というような看板があったが、ああいうのがあると入るのをためらってしまう。

DSC_5962.jpg

お土産 2

夜は会社の仲良しおじさん連中と飲みに行くことにしていたので、ムラマサに行ってお土産を物色した。ここも前回来たときに気にはなったけど時間がなくて素通りしてしまった店(まつもと空港で売ってるだろうと思ってスルーしたら売ってなかった)で、寄らずに帰ったことを猛烈に後悔したので滞在中何度も訪ねて入念に物色した。シュークリームが名物のようだったが旅行者で冷蔵庫に保存することができないのでお店の人にお勧めを聞いて天守石垣サブレを買った。この手のクッキークリームサンド的なお菓子にはあまりテンションが上がらないのだが、帰ってきて食べてみたら確かにおいしかった。

DSC_5978.jpg

飲酒 1

花時計公園の横にある信州ゴールデン酒場に行った。山賊焼を食べたが焼きという名前なのに揚げてあるのにはびっくりした。あと付け合わせキャベツについてくる味噌が完全にう◯こに見えてやばかった。キンミヤハイボールがよいと foursquare の Tip にあったので頼んだらもろに甲類焼酎のアルコールにやられて悪酔いした。

IMG_6024.jpgDSC_5983.jpg

飲酒 2

二軒目はナワテ横丁にある彗星倶楽部という名前の店に行った。両腕にタトゥーを入れたお姉さんがやっててかっこよかった。つまみも全部うまかった。

IMG_6025IMG_6025

さらにもう一軒行ってそばを食べたけど泥酔し過ぎていてあまり思い出したくない…。

朝食

12:50 にバスセンター集合だったので早めにチェックアウトして朝食を食べに行ったが、目当てにしていたおきな堂はモーニング営業を取りやめており路頭に迷ってしまった。二日酔いで勘が鈍っており、ふらふらしながらナワテ通りの適当なパン屋に入ったところいまいちだった…。せっかくよいホテルに泊まってたのだから大人しくホテルの食堂のモーニングを食うべきだった。同僚によると「まるも」という喫茶店が良かったとのこと。

お土産 3

萬年屋というところで味噌を買った。信州味噌はなかなか九州では買う機会がないので面白い。二年熟成の味噌を買った。

IMG_6025

コーヒー 2

この日のメインイベントはセラミカでの器購入だったがオープンが11時なので開店まで暇をつぶす必要があった。朝食のコーヒーがいまいちだったので年季の入った外観だが今風の若い人が載ってそうなチャリンコが停めてある喫茶店に入ってコーヒーを飲んだ。

IMG_6025IMG_6025IMG_6025

セラミカで散財

11 時になり満を持してセラミカに行った。山小屋泊ですっかり朝が早くなったので 11 時はもう夕方みたいに感じる…。皿を三枚とマグカップを買った。グラタン皿も良さそうだったが流石に高すぎた(一万円オーバー)。カード払いしたが二回分割したかったのに何も聞かれず一括で決済されてしまった…。ただ買った皿はとてもよい。何でもおいしく感じる。

IMG_6031IMG_6031

昼食 2

ホテルの近くに有名なそば屋があるようだったのでセラミカで買い物をしたあと行ってみたが、 11:30 オープンで 11:35 に着いたにもかかわらずすでに満席で店の外まで列ができていた。今から並んではバスセンターの集合時刻に間に合わなくなるので仕方なく別のそば屋に入った。この日は暑かったが鴨南蛮が食べたくてだらだら汗をかきながら熱いそばを食べた。

IMG_6025

散策

そばを食べたあと、ホテルに預かってもらっていた荷物を受け取り、ホテル横の湧水場で湧き水をナルゲンボトルに汲んだ。松本は市内各所でこのように水が湧き出ているようである。重いザックを背負いバスセンターまで 10 分ほど歩いた。松本は標高 600m あるとはいえ 8 月の日中は暑く、大量に汗をかいた。

インスタグラムスポット

途中、ふとん屋のたたずまいが良すぎて写真を撮った。ここは去年来たときも見かけて写真を撮ったが、去年は一眼レフを持ってきておらず iPhone でしか写真を撮れなかったことをとても悔やんでいた。

IMG_6025 IMG_6025IMG_6025

感想

松本は岳都や学都、楽都と言われるが、確かにそうだなと思った。北アルプス登山の足がかりとなる街で市内から北アルプスの山々の姿を見ることができる。また信州大学の本部があり旧制高校の松本高等学校もあって学問の雰囲気も感じる。ナンバースクールがあった熊本(第五高等学校)よりも貫禄がある。加えて音楽が盛んなようで、街中に小澤征爾の音楽祭のポスターが貼ってあった。どうやら市をあげて音楽振興に取り組んでいるようである。

生まれ故郷の阿蘇もかつては阿蘇登山の拠点として駅前に旅館がいくつもあり栄えていたが、自動車が普及し日帰りで訪れることができるようになって 90 年代にはそれらの旅館は全て廃業してしまった。松本はきっとその時代から変わらず岳都として栄え続けているのだろう。山の高さや数が阿蘇とは全然違うとはいえ、山岳観光都市として参考にできる点は大いにあると思った。

アルプス登山がてらまた行きたい。

| @WWW

2018 年 7 月 10 日に天神の Fusic 社で開催された Scrapbox Drinkup #5 に参加した。

Nota 社の皆さんが福岡に訪れてユーザーと情報交換するという趣旨のイベントのようだった。 Scrapbox はほとんど使ったことなかったが、 @masui 先生や @shokai さんの発表が聞けるということなので行ってみることにした。

Nota 社のイベント、他社の採用目的感あふれるイベントと異なり牧歌的な感じがとてもよかった。 Nota 社の皆さんも参加者と同じテーブルに座ってピザ食ったりビール飲んだりでざっくばらんな感じだった。

最初にパスタケさんの概要説明的な話があったあと、 @masui 先生や @shokai さんの発表を聞いて「使ってみたい!」という気持ちが強くなり、発表を聞きながら一つプロジェクトを作った。

実は Drinkup 参加前に @ssig33 さんが書いていた Scrapbox についてのブログ記事(ssig33.com - Scrapbox Drinkup #4 にいってきた)を読んでいて「ふ〜ん」くらいに思っていたのだが、実際に利用事例やできることを知って、確かにこれは面白いものだなと思った。

@ssig33 さんが書いている通り、 Scrapbox は単に知識を集めて検索可能にするためのものではなく、コミュニケーションツールだなという感じがする。なので MTG の議事録などを複数人でとって理解が曖昧だったところを確認・補強したりするのに非常に向いてるだろうなと思った。リモートワーク主体のチームが Scrapbox を導入したら MTG の生産性が高まるのではないかと思う。

個人的に Scrapbox に対して良いなと思ったのは以下だ。

  • 共同編集
    複数人で同時に編集できる楽しさ
  • ドキュメント間のリンクが容易
    ハッシュタグやリンクは相互参照される
  • 動画や画像を簡単に貼れる
    コピペで画像をアップロードできる
  • 投稿・入力の敷居の低さ
    枠や升がなく、必須入力やバリデーションなどもほぼほぼなさそう
  • 検索

それぞれはすでにすぐれたツールが存在していると思うが、それが一つのツールですべて使えるようになっているところが便利なのだと思う。

以前アウトライナーについて記事を書いたことがあるが(アウトライナーで文章を書く - portal shit!)、その中で紹介したものに WorkFlowy というアウトラインプロセッサーがある。個人が思考を整理しながら文章を書くのに非常に適したソフトで、 Scrapbox に似ている側面があると思った。

WorkFlowy はアウトライナーからファイルやタイトル、ノードという概念の区別を取っ払い、すべての情報をノードとして扱いツリー構造にしてしまう。おかげですべての情報が容易に検索可能になり(情報がファイルで分割されない)、検索性も向上して知識の保存と参照が劇的にしやすくなる。 Scrapbox では階層構造を作ることはできないが、すべての情報はフラットな空間に書きためられ、それぞれの情報を非常に参照しやすいかたちでリンクさせることができる。

Scrapbox と WorkFlowy が大きく異なる点は、これらの情報を容易に共同編集できるかどうかだと思う。 WorkFlowy は非公開状態がデフォルトで、他者に閲覧を許可したり共同で編集したりするためにはその為に専用のリンクを発行して共有のレベルを設定しないといけない。 Scrapbox はデフォルトが公開状態で(少なくともプロジェクトの参加者の間では)、特に設定することなく情報を共有したり共同で編集したりできるようになっている。 URL は当然ながらドキュメントを作成したタイミングで生成される。わざわざ共有用 URL を発行する必要はない。デフォルトでは URL が存在しないため、 WorkFlowy ではドキュメント間のリンクもしづらい。

このように Scrapbox で初めて得られる文章編集体験というものが確実に存在すると思う。


個人的に作ったやつは会社の G Suite 内の Google Maps にあったランチスポット情報を集約したやつをエクスポートしたもの。Drinkup で @masui 先生が「ヘルプドキュメントの類を Scrapbox で構築したら便利なはず」という話をされていた1のに着想を得た。職場が福岡市の中心部でもマイナーなエリア(旧来の博多の街の中心部だけど天神と博多駅からも微妙に離れていて飲食店が少ない)にあり、食べログなどで探してもあまり有益な昼食スポットの情報が得られないため、これまで社内で情報をストックして共有していたが、この手のものは一社で作るよりも界隈にお勤めの皆さん全体で共有した方が効率がよいはず。 Scrapbox がこの用途にはピッタリなのではないかと思って作ってみた。

Spread Sheet や Google Maps の Data Table による管理では複数人からの情報を良い感じにまとめることができず、多くの人から情報を集める、という点で難があった。 Spread Sheet は入力しやすい UI であるとは言えないので、入力する側に根性や気合い、熱意が求められた。 Scrapbox であればテキストファイルに文章を入力するのと同程度の手軽さで情報を入力していくことができる。入力欄に枠や升があるわけではないので自由気ままに書くことができる。これは書き手にとって大いにストレスの軽減になると思われる。

もし福岡市地下鉄貝塚線呉服町駅周辺のランチスポット情報をお持ちの方がおられましたら以下のページから登録して情報共有しませんか。よろしくお願いいたします。


  1. 実際に Scrapbox のヘルプページは Scrapbox で作成されている。 Scrapbox ヘルプ 

| @散財

契約中のサービス

Apple Music

何度も一ヶ月だけ契約して試しては解約し、を繰り返していたけど、 Circle 2018 に行ったあとに出てた人たちの音楽をまとめて聞きたくなって契約した。全部アルバム買うと 2, 3 万になるのがファミリープランでも 1480 円/月で済むのはいい。人間は音楽を買ってもそのうち聞かなくなる。聞きたい間だけお金を払うのが正解なのかもしれない。

ただ有名ミュージシャンの曲や懐メロのオリジナル版は相変わらず Apple Music にはなくて(カバーはいっぱいある)買わないといけないので注意が必要。ゴレンジャーの曲とか聖闘士星矢の曲のオリジナル版は iTunes Store で買った。

Spotify にしない理由は macOS や iOS との統合された使い勝手を重視しているから。たまに切り替えて使ってみるのもよいかもしれない。

Netflix

深夜食堂を見たくて入ってる。その他、アメリカのドラマも時々見る。電車の中で見たいけど結構エロシーンが多くて困る。イギリスのクッキング対決番組も面白い。とはいえ元とれてる感じはしないので Rebuild で話題になるドラマなんかをさっと見て解約したい。

Amazon Prime

Amazon のクレジットカード( Master )の特典で付いてくる。様々な割引を組み合わせたカードの年会費が 3940 円でプライム年会費と同じ。 Master カードはコストコでの支払いにも使えるようになったので便利。 1% ポイント還元。

Prime ビデオに関しては割と頻繁にラインナップの見直しあってて見たいやつがなくなるので見られたらラッキーくらいのつもりで利用しないと逆にストレス溜まる。

The Old Reader

RSS リーダーの中で最安なので使ってる。検索が厳しい。たぶん全文検索エンジン使ってなくて DB から LIKE サーチしてる気配を感じる。 Inoreader に乗り換えを検討した方がよいかもしれない( Feedly は好きになれない )。

さくら VPS 2GB プラン

このブログを動かしている。まぁまぁ高いが AWS や自宅サーバーで運用するのに比べたら十分経済的。

AWS

Route 53 と S3 、 CloudFront のみ利用している。 毎月 200 〜 300 円くらい。

解約したサービス

GitHub private repo

Microsoft に買われて自分ごときの金なしおじさんが利用料を払う必要もなかろうと思い解約。大したコード上げてなかった。秘密情報的なやつは GitLab に移した。

Flickr Pro

自己顕示欲を満たすために人に写真を見せる、ということがなくなったので解約しようと思っていたが、 2 年おきの更新なのでうっかりしてて 2020 年まで自動更新されてしまった。とりあえず自動更新を停止にした。

iTunes Match

Apple Music に移行したので自動更新を停止した。

| @ブログ

Facebook にウェブサイトの URL をはっつけるとき参照される HTML メタ情報の仕組みに Open Graph Protocol ってのがある。 Facebook に URL を貼ると bot が URL の内容を読みに行ってページの概要や画像を取得し Facebook 内に埋め込み表示するというもの。 Facebook を見ている人はリンク先の内容をクリックする前に概要を把握できるので、リンクをクリックして見たい情報じゃなかった、ということを避けられる。 Facebook が考案して策定した仕組みだけど、 Facebook に限らずいろんなサイトで OGP タグを出力してるし読み込んでる。 Twitter にも似た仕組みあって Twitter Card という。この辺の対応は結構前にやってた。

ただ自分のサイトが OGP タグを提供するだけではつまんないなと思ったので自分のブログにペロッと URL を貼ったときに相手先に OGP タグがあればそれを出力するようにしてみた。こんな感じ。

OGP Preview

しかしここで困ったことがあって、↑でリンクしてる Circle のサイトは HTTPS で配信されておらず、単純に Circle のサイトで og:image に指定されている画像を SSL 化されているこのブログで読み込むと Mixed Content になってしまう。せっかく HTTP/2 で配信していたのに台なしになってしまう。またそもそも og:image は Facebook でシャアされることを想定されていることがほとんどなので、画像サイズがデカすぎていい感じにスクエアに表示するためには CSS の小技を駆使したりする必要があった。

いい感じに解決する方法ないかなと調べていたら良いのが見つかった。

Go で書かれた Image Proxy Server で、 HTTPS Proxy は当然のこと動的リサイズもできる。使い方は簡単でバイナリを落としてきて動かすだけ。 Go なんで ImageMagick をどうしたりとかを考えなくて良い。 そもそも Docker イメージも提供されているので Docker をインストール済みなら docker run するだけでも動く。 めっちゃお手軽。

こいつのおかげで HTTPS で配信されていないサイトの OGP タグを読み込んでも Mixed Content にならずに済むようになった。また og:image は適切にリサイズできるようになった。画像変換サーバーとかは結構難しいやつで個人のブログでこんなに簡単に使えるものだとは思ってなかったので正直ビックリした。

AWS の登場で大企業じゃなくても CDN 使ったり仮想サーバーでウェブシステムを構築したりできるようになった。さらには Go や Docker といった技術のおかげで複数の込み入ったソフトウェアを組み合わせて構築していく必要があったシステムが、まるで jQuery を使うような感覚でポン付けで使える時代になってきている。とても素晴らしい。

ちなみに OGP の取得には open_graph_reader という gem を使っている(昔からある opengraph という gem はメンテナンスされておらず最近の Nokogiri で動かない)。 open_graph_reader の作者が結構 Opinionated な人で、以下のような Anti-featurs を掲げている。

open_graph_reader Anti-features

http://ogp.me/ の仕様に準拠していないサイトのことは完全無視というつくり。個人的にはこういう思想は好みだが、現実問題として使い勝手が悪い。例えば hitode909 さんのブログの OGP タグを取得しようとしたところ以下のようなエラーを出して取ってくれなかった。

スクリーンショット 2018-05-26 10.08.47.png

article:published_time は ISO8601 形式の datetime であるべき、とのこと。はてなブログはかなりシェアが大きくリンクする機会が多いので残念。

| @技術/プログラミング

以前、 AWS ECS で試験運用したことがあったので Docker 化自体は済んでいた。 ECS などマネージドコンテナサービスを使わずに Docker 運用ができないか試してみた。

動機

関連記事の更新処理、諸々障害があって自動化できておらず、 DB を clone してきて手元で実行してサーバーにエクスポートするという運用が続いていた。これを自動化したかった。

二つ問題があって、以下の通りだった。

  1. 関連記事の更新処理時に日本語の分かち書きをする必要があるが、 VPS インスタンスのメモリ上限があり MeCab の拡張辞書をサーバー上でインストールできない
  2. VPS 上で SQLite の算術計算を行うためには追加拡張が必要で、そのためには SQLite をソースコードからコンパイルする必要がある

1 は Docker イメージにして手元でイメージをビルドすれば解決できた。 2 の問題も Docker のなかでコンパイルを行うことで解決できた。

どうやるか

  • nginx.conf の修正
  • コンテナの create
    キャッシュのためにファイルシステムを利用しているのでホストとコンテナで public ディレクトリを共有する必要があった。
docker create \
  -e DATABASE_URL=db_url \
  -e RACK_ENV=production \
  -v /home/morygonzalez/sites/portalshit/public:/app/public \
  -p 3001:3001 --name portalshit -it morygonzalez/portalshit bundle exec puma -p 3001
  • コンテナの起動
docker start portalshit

結果どうだったか

サイトを Docker で公開することはできたが、 docker create して docker start するまでの間、ダウンタイムが発生する。

ダウンタイムなしで deploy するためには deploy のタイミングで Nginx conf を書き換えて service nginx reload する必要が出てくる。個人のブログレベルでそこまでやりたくない。

コンテナを管理するサービス( AWS ECS や Kubernetes )があるんだったら Nginx conf の書き換えなどしなくてもいい感じに deploy できると思うが、こちらも個人のブログレベルで使うものではないと思った。

結論

  • サイトの deploy はこれまで通り cap で行い、 puma はホスト OS で普通に動かす(コンテナ化しない)
  • 関連記事表示のバッチ処理のみコンテナ化することにした

| @技術/プログラミング

会社でプロジェクトのふりかえりをしていて自分でエモ発言をしてしまって結構いい話だと思ったのでブログに書いておきます。

新しいプロジェクトを始めるとき、誰しもナウでモダンなフレームワークや技術を使いたいと思うだろう。しかし、 Qiita でみんながその技術についての記事を書いてるから、他の会社の友だちがそのフレームワークを使っているから、という理由で技術選択をしてはいけないと思う。新しいものを使うな、という話をしているのではない。社内によく知ってる人がいない技術を自分の意思で取り入れるからには「覚悟」が必要だという話。わからない挙動に遭遇したときにフレームワークのソースコードを読んで問題を解決したり、バグを踏んだときに修正する Pull Request を送ったりする気概があるか、という意味だ。自分以外の人がそのコードを触るときのためにユニットテストのカバレッジを高く保つということも「覚悟」に含まれるだろう。

その話をしていたらジョジョの奇妙な冒険に有名な台詞があるということだったので、 Slack で覚悟と入力したらその画像が表示されるようにしておいた。

スクリーンショット 2018-04-26 18.43.39.png

「覚悟」とは!!
暗闇の荒野に!!
進むべき道を切り開くことだッ!

| @労働

リモートワーク別に寂しくないし楽勝、みたいなコメント多いけど違和感あった。リモート楽勝という人はフリーランスとか受託の会社の人なのではないかと思う。自分のブックマークコメントは以下。

激しく同意。雑談したい、家族から家事を頼まれる、オフィスにいる連中から事業理解が低いと責められる、毎日服を着替える能力や通勤電車に乗る能力が失われる、などなど — http://b.hatena.ne.jp/morygonzalez/20180309#bookmark-359971190

「こいつはわかってない」問題

自分の場合は事業会社に所属した上でのリモートワークだった。事業会社(大抵のスタートアップもこれに含まれるはず)の場合はソフトウェアエンジニアにも事業やプロダクトへの理解が求められるので、リモートだとなかなか厳しい部分がある。事業理解は日々の MTG の他、オフィスで何気なく交わす雑談や昼飯の時なんかに醸成されるものだと思うので、リモートだと MTG での情報伝達密度が下がるし雑談や昼飯に至ってはそもそも不可能なので自分自身の事業理解も深まらない。仮にこちらに事業に対する理解があったとしても、それをオフィスにいる連中に伝えることが難しいので結局「こいつはわかってない」という烙印を押されることになる。リモートワークやってて同僚のエンジニアの皆さんとは友好関係を築けたと思うけど、 PM や上司とはなかなか良い関係になれなかった。

家庭内で仕事が軽んじられる

家族がいる人の場合は家族が「こいつ家にいてあんまり忙しくなさそうだから家事を頼もう」ということになりがち。自分の場合は子どもの幼稚園の送り迎え(バス乗り場まで)、幼稚園から帰ってきたあとの子守、洗濯物干し・取り込み、などを頼まれることが多かった。配偶者も仕事をしていて家事を分担する、ということなら当然やるけど、我が家の場合は嫁さんが習い事やヨガで忙しいので家事をやらなければならない、という感じで、自分の仕事は嫁さんの習い事よりも優先度が低いものなのだろうかと悶々とした。

社会適応能力の低下

毎日身支度をする能力、出かけていく能力も確実にむしばまれていく。転職してリモートワークからオフィスワークに切り替えて、朝の混んでる時間の電車に乗る通勤生活を再開してからの数ヶ月間は肉体的にも精神的にも非常につらかった。また家で仕事してると出歩かないので当然に運動不足になる。自分で意識してジョギングしたり体を動かしたりしないと確実に健康を損なう

自分がリモートワークに対して否定的な見解を持っているのは以上のような背景があるのであった。

良い面もある

もちろんリモートワークには良い面もある。

ワークライフバランス

子育てのための一時期や家族の看病が必要な時期には非常にありがたい制度だと思う。ワークライフバランスは非常に良好になる。

集中維持

コード書きに集中したいときにもリモートワークは便利だった。リリース前など、移動の時間も惜しんでコードを書きたいときには朝 10:00 から夜の 24:00 頃まで風呂とトイレと飯の時間以外はずっと仕事してたこともあった。それでも 10 時間は時間が空くので十分睡眠をとることはできる。これも前にブログで書いたような気がするが、いつでもオフィスに仕事しに行ける環境で、自分の裁量で週に数日リモートで仕事をするのが一番満足度の高い働き方になると思う。

地方都市に暮らしながらデラウェア法人で働ける

あとそもそも福岡では前職のような数十億円規模の資金を調達してがつんと成長しようとしているスタートアップの仕事にありつくことなんかは不可能なので、田舎に住んでいても都会のイケてる手法で仕事できてたのはリモートワークならではだったと言える(これも元記事に書いてある)。いまの職場でやってることは前職で身につけた1もの(スタートアップで働くエンジニアのディシプリン的なもの、あるいは技術顧問おじさんの素養)を土台にしているので、これは非常にありがたかった。

まとめ

ひとくちにリモートワークといってもいろいろな形態、状況があるので、↑の記事のブコメのように「リモートとか楽勝じゃね?」というコメントを読んでうかつにリモートワークを始めようとしている人がいたとしたらちょっと踏みとどまってもらいたいし、自分に向いているか、勤務先のビジネス領域・ビジネスモデルなども加味した上で決めてもらいたいと思う。

あとリモートワークだとコードレビューが甘くなりがちではないか、という問題もあるけどそれはまた別の話かもしれない。

References


  1. 当時は自分は全然成長してないと思ってた。こういうのを身につけたんだということはあとから気がついた