| @WWW

先日書いた Day One のバックエンドで障害 - portal shit! について、 Day One のヘルプページで詳細を説明する記事が掲載されていました。

Help Guides

Help Guides

The Day One Help Guides are designed to help you with tutorials, tips, and documentation for the Day One journal app.

help.dayoneapp.com

ウェブアプリケーションエンジニアの皆さんが読むと参考になるのではないかと思い、翻訳の可否をたずね許可をもらったので翻訳します。

2018 年 5 月の Day One 障害報告

執筆者： Paul Mayne （訳注：Day One の創業者）
今週更新（訳注：障害復旧日の午後に公開されました）

2018 年の 5 月 7 日から 10 日にかけて、 Day One は重大な Sync サービスの停止に陥りました。ユーザーの皆さんから堅牢な Sync サービスを期待されていることはわかっていますし、この出来事は我々の基準を満たすものでもありません。何が起こったのか、そして将来にわたってどのようにこの問題を回避していくかをユーザーの皆さんにお伝えしたいと思います。

簡単なまとめ

5 月 7 日にハードウェア障害が発生し、最初の Sync サービスの停止が発生しました。バックアップデータが不完全だったことが原因で、 5 月 8 日の Sync サービスの復旧処理中、一部のユーザーのアカウント ID が既存のユーザーのものと重複してしまいました。結果、一部の新規登録ユーザーは他人の記事を見ることができる状態となっていました。問題に気がついてすぐに Sync サービスを再び停止させました。対象のユーザーは 106 人で、これは我々のユーザー全体の 0.01% よりも少ない値です。

現在、 Sync サービスは正常に復旧しており、記事が他人に見られることはありません。近日中（訳註：すでにリリース済みです）に意図せず共有されてしまった記事を削除するアップデートを提供します。

End-to-end の暗号化を施していた記事は今回の事故の対象外です。

いかなる偶発的な個人情報の漏出も信用を毀損するものであると我々は認識しています。この不幸な状況にあって我々は、正直に状況を説明することが最善だと思っていますし、また信頼を回復するために全力を尽くしています。今回、個人情報の流出被害にあった 106 人のユーザーには終身の Premium メンバーシップを無償提供し、それぞれ個別に連絡を取っています。自分たちにできるあらゆることを行ってみなさんの信頼を回復していきたいと思っています。

障害の詳細

5 月 7 日月曜日、 Day One の社員が DB サーバーでハードウェア障害が発生していることに気がつきました。問題のあるサーバーをデータベースクラスターから取り除く作業とデータを残りのサーバーに分散する作業を始めました。

データの分散処理に失敗します。これが最初の障害です。すぐに Sync サービスを復旧させたかったため、新しいデータベースクラスターを作成して最新のバックアップデータを読み込むことにしました。新しいクラスターがセットアップされ、バックアップが読み込まれました。

5 月 8 日火曜日の早い時間に復旧処理が完了し、 Sync サービスを再開しました。当初は順調に動いているように見えました。しかし数時間で「自分の記事ではない記事が見える」という問い合わせが何人かのユーザーからありました。これは由々しき事態であり、我々はすぐに Sync サービスを再停止し、これ以上被害が拡大しないようにしました。

この時点で、問題と対応方法の調査を行う間、 Day One Sync を無期限に停止する旨をソーシャルメディアに投稿しました。何が原因なのか、何が起こっているのか、そしてもう問題が起こらないと確信できるまで Sync サービスは再開できませんした。

5 月 9 日水曜日の午前、問題の根本原因を突き止めました。復旧処理に用いたバックアップデータが不完全だったのです。記事データは完全なものでしたが、ユーザーアカウントデータに欠落がありました。具体的には、 3 月 22 日よりも後に作られたユーザーアカウントデータが含まれていなかったのです。その結果これらのユーザーはログインすることができていませんでしたし、特定の記事データが意図せず他人から見えてしまうという問題につながりました。

それぞれの記事データベースは “accountID” というフィールドを持ち、どのアカウントがその記事の所有者であるかを判断しています。全ての記事データは正しく復旧されましたが、ユーザーアカウントデータはそうではなかったため、データベースに所有者が存在しない記事ができてしまいました（例えば “My Travel Journal” という記事は 123456 というアカウントのものだったとしましょう。しかしそのアカウントが存在しなくなってしまったということです）。新しいユーザーアカウントの ID は連番で作られます。復旧されたデータは最新のユーザー情報を含んでいなかったため、 5 月 8 日に新規登録したユーザーは本来よりも小さな値の ID で登録され、既存のユーザーアカウントと重複することになったのです。その結果、これらの新規ユーザーはすでに存在する他人が書いた記事を読めるようになってしまったのです。

5 月 8 日の問題が発生していた期間のうちに、 326 アカウントが正しくない account ID で作成されました。その 326 個の ID のうち、 106 個が別人によって書かれた既存の記事データに結びついていました。 2018 年の 3 月 22 日から 23 日に作成されたアカウントは他人から記事が見られる状態になっていたということです。それらは account ID 1104506 から 1104831 の人たちでした。

現在のところそれらの記事のうちどれくらいが end-to-end の暗号化処理をされていたかはわかっていませんが、 end-to-end の暗号化をしていた記事は今回の問題でも他人に見られることはありませんした。

水曜日の調査の後、元のデータベースでデータの分散処理に失敗する問題を解決することが最善の選択肢だと判断しました。いくつか設定ミスがあり、データベースの負荷が高まる原因になっていることがわかりました。この負荷が原因でデータの分散処理が失敗していました。

水曜日の午後、この問題を修正し、元のデータベースクラスターで分散処理が正しく完了することを確認しました。しかしエンジニアチームとサポートスタッフが万全の態勢で臨めるよう、 Sync サービスの再開を木曜の朝まで遅らせることにしました。山岳時間で 5 月 10 日木曜の午前 8 時、 Sync サービスは再度有効化されました。

同期サーバーには大量の待機処理があったため、それらの処理が終わるまでは少しパフォーマンスに問題があるかもしれませんが、なるべく遅延が発生しないように対処しています。

今後どうするのか？

意図せず共有されてしまった記事を削除する機能が入った Day One.app のアップデート（バージョン 2.6.4 ）をすぐにリリースします（訳注：すでにリリース済みです）。このアップデートをインストールすると、未ログイン状態のユーザーの端末からは非公開の記事はすべて削除されます。対象ユーザーはアップデートのインストール後 30 日以内に Day One アカウントにログインすることが必要で、このログインをもって Day One.app はログインユーザーを記事の所有者であると認定し、記事を復元します。 Day One.app は影響を受けるユーザーに対してこの変更内容を通知します。

今後、同様の問題が起こらないように、近々以下の改修を同期サーバーに対して施します。

  1. account ID の新規作成時、すでにその ID で記事が作成されていないかをチェックします
  2. 新規の account ID に対しては、連番の数字に加えてランダム生成された二桁の数字を末尾に付加することにします。将来、同じような問題が発生して連番 ID が若返ってしまったとしても ID の衝突が起こる可能性は非常に小さくなります。
  3. いくらかのユーザーアカウントがバックアップ対象から除外されてしまう問題を修正します。

他人に記事を見られてしまった 106 人のユーザーに対しては真摯に謝罪します。対象のユーザーには終身 Premium メンバーシップを提供するとともに、その他懸念点がないか個別に連絡をとっています。今回、大規模な情報流出は起こっていません。第三者がデータベースに侵入したということもありませんし、すべてのデータは我々のサーバーで安全に保管されています。しかしながら 106 人のユーザーの我々に対する信頼は失われてしまいました。信頼は獲得するものであり、与えられるものではないということを承知していますし、再び皆さんからの信頼を取り戻せる機会を得たいと思っています。ユーザーの皆さんには 2017 年 6 月にリリースした end-to-end の暗号化機能を利用することを推奨します。この機能は今回のような事故やその他の問題があったときにもあなたの個人情報を保護します。

今回の障害で Sync サービスを利用できなかった間、辛抱して下さったユーザーの皆さんに感謝します。皆さんが Day One を使って大事な思い出を記録していることを理解しています。今後、よりよくしていくことをお約束します。信頼を回復するため、全力を尽くします。

— Paul

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

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

🚨 Docker & ECS 化追跡 24 時

🚨 Docker & ECS 化追跡 24 時

ブログを Docker 化して AWS ECS で運用するようにした。なぜ Docker 化したか仕事で Docker を使う機会が増え知見がたまってきた仕事では Production 投入はで...

portalshit.net

動機

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

⛓TF-IDF で関連エントリーを表示

⛓TF-IDF で関連エントリーを表示

cho45 さんの以下の記事を参考に関連記事を表示するようにしてみた。 TF-IDFとコサイン類似度による類似エント...

portalshit.net

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

  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 で普通に動かす（コンテナ化しない）
  • 関連記事表示のバッチ処理のみコンテナ化することにした

| @散財

五円玉と五十円玉

真似して書いてみます。

キャッシュレス生活2018 in 京都 - 『言葉を吐く』

キャッシュレス生活2018 in 京都 - 『言葉を吐く』

結論 2018年の日本において100%キャッシュレス生活は厳しい 京都ではなおのこと厳しい しかし実際的な満足度は非常に高い 財布の中身 クレジットカード SMART ICOCA キャッシュカード (デビットカード) (EX-IC) (オフィスのカードキー) 普段はクレジットカードを使う。最近、ローソンではクレジットカードを店員側で端末に挿入せず客側で挿入するようになって、良い改善だと思う。 あとは交通手段としてSMART ICOCAを使っている。Apple Pay/Suicaモバイルはスマフォからチャージできてたいへん便利そうでうらやましいけど、iPhoneを選ぶつもりはないしおサイフケータ…

d.aereal.org
キャッシュレス生活2018 in 京都 - hitode909の日記

キャッシュレス生活2018 in 京都 - hitode909の日記

フレスコ(スーパー)でクレジットカード使えるようになったのが革命 そのおかげで最近あまり現金に触れずに過ごしている 平日はほぼ現金触れずに暮らすことが可能 家でご飯食べている 買い物する場所はコンビニかフレスコかドラッグストア，いずれもクレジットカード使える 会社の裏のサンドイッチ屋では使えない 金曜日や週末は飲みに行く 店でカード使えたら払わせてもらって，同席した人たちから現金を調達することで，なるべくATMに行く回数を減らしている 金曜によく行く天ぷらバルではカード使える 週末はだいたいデンエンかサイゼリヤに行く学生みたいな暮らしをしている．デンエンではカードが使える．サイゼリヤは使えない…

blog.sushi.money

キャッシュレス済み

Apple Pay

大手資本が関与しているものは基本的に Apple Pay （ iD ）で払っている。めっちゃ快適。

  • コンビニ
  • ドンキホーテ
  • カルディ
  • ドラッグストア
    • ココカラファイン
    • マツモトキヨシ

カード払い

  • 酒のやまや
    毎週末酒を買いに行ってるやまやは Edy が使えるが、 Edy のポイント還元率はしょぼいのでクレジットカード払いしてる。やまやはドコモの d ポイントも貯まるのでカードのポイントと d ポイントでマイル乞食がはかどる。
  • ジュピターコーヒー
    カルディのパクリみたいな店でコーヒー豆を買うときにカード払いする。交通系電子マネーで払えるがポイントが付かないのでカード払いしてる。
  • 昼食
    普段は弁当なので昼飯に金を使わないが、稀に弁当を準備できなかった日は会社近くのスーパー（ SUNNY ）でカード払いする。
    マイル乞食したいのでカード払いできない飲食店に入って食べるということをしなくなった。
  • コストコ
    もう会員証が失効したけど行ってた頃はわざわざコストコ用に Saison Walmart American Express カードを作って払ってた（コストコは提携カードブランドでないとクレジットカード使えない）
    いまは提携カードブランドが AMEX から Master に変わってる

その他

  • ガソリン
    Esso で Express 給油。 Speedpass で Apple Pay 並みに高速に金が払える。
  • 高速代
    ETC カードで払う。
  • 税金
    去年までは楽天カードから nanaco にチャージしてポイント還元を受けながら納税してた。固定資産税と自動車税合わせて年間 14 万くらい。
    今年から楽天カードが nanaco チャージにポイントを付与しなくなったので SEVEN CARD を作って nanaco チャージして払う方法に切り替えた。
    nanaco は税金を払うのにしか使わずセブンイレブンでも買い物は基本的に Apple Pay （ iD ）で払う。

キャッシュレス未完

  • 自宅近辺のスーパー
    どこもカード払いできないのでちまちま現金払いしてる。
    福岡のスーパーでカード払いできるのはサニーか西鉄のレガネットか高級スーパーのボンラパスくらいだと思う。
  • 近所のコーヒー豆屋、パン屋、飲食店
    個人商店ではカード払いできない。現金での買い物は極力したくないので結果的に本当に気に入っている店でしか買い物しなくなった。

所感

守銭奴なので基本的に快適性や利便性は二の次で、ポイントが貯まることを重視している。なので交通系電子マネーか Edy のみが使える店では電子マネーを使わずカード払いするしカード払いできないなら現金払いしてる。中途半端に残高が分散するのが嫌なのでチャージ式の電子マネーは nanaco だけ使うようにしてる。それも税金の支払いにしか使わない。一時期は Apple Pay で払うのが面白くて iPhone の Mobile Suica を多用していたけど ANA VISA カードによる Mobile Suica チャージではポイントが付かないことを知って使うのをやめた。

ベストエフォートキャッシュレス化のおかげでデカい財布いらなくなって Bellroy のカード入れに非常用現金数千円を畳んで忍ばせてあとは小銭入れと Apple Pay 付き iPhone だけ持ってうろついてる。 Bellroy のカード入れはめっちゃ薄いので身軽になって嬉しい。

Apple Pay やその他の支払い方法で挙げた ETC カードや Speedpass 、 nanaco も結局はクレジットカードが終端にあり、大意ではクレジットカード払いであると言える。これがネックになってキッャシュレス決済に店側の負担（決済手数料）が発生して大手資本以外でキッャシュレス決済が普及しない遠因になってる気がする。カード決済は個人商店だと 4.5% くらい決済手数料を持ってかれる。 Square とかを使ってもせいぜい 3.25% （ JCB に至っては 3.95% ！）までしか落ちないはず。電子マネー決済も似たり寄ったりだと考えられる。クレジットカードを介さないキャッシュレス決済が普及したら手数料が下がり個人商店でも導入できて便利になりそう。

ちなみに中国人観光客が多いキャナルシティ博多では普通に中国人が WeChat Pay だか Alipay だかで QR コード払いしてるので、同じように外国人観光客が多く利用する中洲の屋台なんかの方がスーパーや個人商店よりも先にキャッシュレス化されるかも知れない。

福岡ではまだまだ完全キャッシュレスな生活を送ることは難しいが、頑張れば現金を使う機会を結構減らすことができる。現金は飲み会の割り勘とか祝儀・不祝儀を包むためだけに存在するようになるかもしれない。

東京の富裕なエンジニアのお二方にも書いてもらえたみたいだった。

キャッシュレス生活2018 in 東京｜すらいむ

キャッシュレス生活2018 in 東京｜すらいむ

真似して書いてみます。 ・キャッシュレス生活 2018 in 福岡 - portal shit! ・キャッシュレス生活2018 in 京都 - 『言葉を吐く』  ・キャッシュレス生活2018 in 京都 - hitode909の日記 普段の持ち物はiPhoneとマネークリップのみで、よく使う順にiD・Suica・クレカ（ビックカメラSuica）です。 iD Amazonカード付帯のものをApple Payで使ってます。クレカ直引き落としで残高気にしなくて済むのが便利。よく使うのはここら辺。 ・コンビニ ・書店 　・Book1st、啓文堂、ツタヤあたりで使える

note.mu
note ご指定のページが見つかりません

note ご指定のページが見つかりません

note.mu

| @Mac/iPhone

iMac 5K

三井住友 VISA カードで払うと 12 回まで分割手数料が無料だったのでそれで買った。税込み 25 万くらい。 SSD だけ 256GB から 512GB に変えた。あとはキーボードを Magic Keyboard の US 配列にした。マウスは Magic Mouse 2 を選んだけど正直使いづらい。 Magic Trackpad 2 にすればよかった。キーボードを売って Magic Trackpad を買おうか検討中。 MacBook Pro 2009 の方はデータを抜き取ったらメルカリに出そうと思う。 2 〜 3 万くらいでは売れそう。

MacBook Pro の Touch Bar なしのやつとどっちにするか迷ったけど、最近はアイフォ〜ンが進化してて帰省や旅行に Mac を持って行かなくなった（雑な日記書きやインターネット閲覧などはアイフォ〜ンで事足りる）。ほとんど家で使ってるだけ。仕事で必要なときは会社から借りてる MacBook Pro を使うので私物は据え置き型で良いなという結論に至った。同じくらいの値段ででかい 5K ディスプレイが手に入るなら iMac の方が良い。

CPU を Core i7 にしなかったのはミスったかなと思ったけど全く問題無く快適に動く。普通にコードを書いて写真を整理する程度であれば Core i5 で問題無いと思う。ディスプレイでかくて解像度高いのがなによりすばらしい。 MacBook Pro + 外部ディスプレイを使うのよりも省スペースになり机を広々と使えるのもよい。ディスプレイが一枚なので首を左右に動かす負担もなくなる。

メモリを増やしておこうと思って、いまはちょっと値段が高いが 16GB のやつを 2 枚 Amazon で注文した。これでまた 8 年くらいは粘りたい。

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

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

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

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

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

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

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

前書いてた記事の続き。

🏭 Docker を Production 投入するメリットを考える

🏭 Docker を Production 投入するメリットを考える

仕事で開発中のシステムで、 master ブランチに Pull Request が Merge されると自動的に AWS ECS に構築した社内向けの確認環境にデプロイが行われるような仕組みを導...

portalshit.net

Kaizen Platform 時代は Naoya Ito さんの以下の記事にあるような感じで deploy してた。 Slack 上で hubot に話しかけると deploy 用の Pull Request が作られていい感じに deploy フローが始まる。

GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー

GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー

少し前までアプリケーションのデプロイと言えば capistrano などをコマンドラインから叩いてデプロイ、みたいなことをやっていたが、最近は少し様子が違うのでそのやり方、KAIZEN platform Inc. での事例を紹介する。 GitHub のイベントを契機に CI as a Service にデプロイを担当させる GitHub で Pull Request を送って開発するのが前提になっているのは以前にも紹介した。最近は Travis CI や CircleCI などに代表される CI (Continuous Integration) as a Service があって、CI も自分…

d.hatena.ne.jp

これがめっちゃ良くて、現職場でも導入したいと思ってたので今週ちょっとやってみたところ deploy できるようになった。

実際のデプロイフロー

まず Slack で hubot （ 山の会社なので tengu という名前にしてる）に話しかける。すると hubot で GitHub の API を叩いて deploy 対象の Pull Request を取得し、それぞれの Pull Request ごとに commit をグルーピングして、 deploy 対象の Pull Request の Author にメンションするかたちで master ブランチから deployment/production ブランチへの Pull Request が作成される。

tengu deploy 1

最近 Slack の GitHub Integration がアップデートされて、 Webhook の通知がいい感じに飛んでくるようになったので Slack 上でどんな内容が deploy されるのかが一目瞭然となる。

実際に作成される Pull Request は以下のような感じ。この Pull Request を Merge することで CircleCI 上で deploy 用のビルドが走る。その辺は Naoya さんの記事で書いてあるのと同じ。

tengu deploy 2

いま作ってるやつは AWS ECS で運用しようとしてるので、 cap deploy ではなく手製のシェルスクリプトで以下のことをやっている。

  1. deploy 用のコンテナイメージをビルド
  2. AWS ECR にコンテナイメージをプッシュ
  3. プッシュしたイメージを利用する Task Definition を追加し、 ECS のサービスを更新 ecs-deploy というシェルスクリプトでやる

以前の記事にも書いたが「 CircleCI が落ちてたら deploy できないじゃん？」というツッコミが入ったため CircleCI が落ちていても deploy できるようにシェルスクリプト化してあるので、手元からおもむろに bin/deploy production とかやっても deploy できる。

ちなみにこのフローを実現する .circleci/config.yml は以下のような感じ。

jobs:
  deploy:
    docker:
      - image: docker:17.05.0-ce-git
    steps:
      - checkout
      - setup_remote_docker:
          docker_layer_caching: true
      - run:
          name: Install dependencies
          command: |
            apk add --no-cache py-pip=9.0.0-r1 jq curl curl-dev bash
            pip install docker-compose==1.18.0 awscli==1.14.38
            curl -s https://raw.githubusercontent.com/silinternational/ecs-deploy/ac2b53cb358814ff2cdf753365cc0ea383d7b77c/ecs-deploy | tee -a /usr/bin/ecs-deploy && chmod +x /usr/bin/ecs-deploy
      - run:
          name: Execute deployment (Docker image build, push to ECR, create new Task and replace container)
          command: |
            case ${CIRCLE_BRANCH} in
              "deployment/dev" | "master" )
                DEPLOY_ENV="dev" ;;
              "deployment/production" )
                DEPLOY_ENV="production" ;;
            esac
            bin/deploy ${DEPLOY_ENV}

workflows:
  version: 2
  production-deploy:
    jobs:
      - deploy:
          filters:
            branches:
              only:
                - deployment/production

Chat deploy のよさ

deploy フロー・ deploy 状況が可視化され、民主化されることがよい。昔ながらのローカルからの capistrano による deploy の問題点は deploy の特権化を招いてしまうことだと思う。 ○×さんしか deploy 用の踏み台サーバーに ssh できないので一々○×さんに deploy をお願いしないといけない、というような状況はよく分からない遠慮や序列を招きがち。 deploy フローが自動化されていることでチームに入ったばかりの人でもさくっと deploy が行えるというメリットもある。

deploy の履歴が Slack 上と CircleCI 上、また GitHub 上に Pull Request として残るのもよい。ひとくちに deploy といっても schema 変更が伴う場合は作業ログの共有やコミュニケーションをどこかで行う必要があり、その場所として GitHub の Pull Request が使えるのがとてもよい。 YAMAP で作った deploy スクリプトではそこまでやってないが、 Kaizen Platform の deploy スクリプトには deploy 用の Pull Request 本文に動作確認用のチェックボックスを作って、チェックボックスにチェックが入れられるまで cronbot が二時間おきに deploy 対象の commit author に Slack 上で動作確認を促す、というような仕組みまであった。

今後 YAMAP でもどんどん deploy フローを改善していって Merge ボタンを押したあと寿司を食ってれば良いような状態[1]にしていきたい。

ちなみに上記の chat deploy を実現するためには GitHub App を作っていろいろやる必要があって、その辺は Kaizen Platform で同僚だった t32k さんの以下の記事が参考になった。

チャットデプロイしたい2018 - MOL

チャットデプロイしたい2018 - MOL

タイトルの通り、チャットデプロイしたい。

t32k.me

書いてあるフローはほとんど Kaizen Platform のやつと同じでちょっとウケた。いやでもそのくらい完成されてる仕組みだと思う。この割とイケてる deploy フローを体験してみたい人は僕が勤めてる YAMAP の Wantedly をご覧下さい。資金調達しており割と積極的に採用中です。

[1]: Terraform + GitHub + CircleCI + Atlasを利用してAWSの操作を自動化した - Glide Note http://blog.glidenote.com/blog/2015/02/18/terraform-github-circleci-atlas-aws/

| @労働
[B! リモートワーク] リモートワークのストレス | POSTD

[B! リモートワーク] リモートワークのストレス | POSTD

この記事に対して146件のコメントがあります。注目されているコメントは「寂しがり屋と真面目君はリモート向いてない」、「リモートワークって、ペアプロやモブプロが推奨されるアジャイルや、少人数で効率よく検証・開発のサイクルを回すリーン的な働き方と相性悪いと思ってる。」、「たまにリモートにするぐらいが丁度良い派」、「7割はチャットの下手さが理由だと思う。対面での会話が得意すぎるとも言うが。」などです。

b.hatena.ne.jp

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

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

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

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

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

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

社会適応能力の低下

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

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

良い面もある

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

ワークライフバランス

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

集中維持

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

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

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

まとめ

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

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

References

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