| @労働
『リモートワークのストレス | POSTD』へのコメント

『リモートワークのストレス | POSTD』へのコメント

この記事に対して147件のコメントがあります。注目されているコメントは「寂しがり屋と真面目君はリモート向いてない」、「リモートワークって、ペアプロやモブプロが推奨されるアジャイルや、少人数で効率よく検証・開発のサイクルを回すリーン的な働き方と相性悪いと思ってる。」、「たまにリモートにするぐらいが丁度良い派」、「リモートワーカーなんだけどストレスや健康には十二分に気を使っている。通勤が無くなった分とにかく運動をする。そして、決して働きすぎ無いことが重要。日本の通勤は満員電車がデフォだから、それがないのは大きい」などです。

b.hatena.ne.jp

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

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

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

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

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

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

社会適応能力の低下

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

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

良い面もある

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

ワークライフバランス

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

集中維持

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

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

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

まとめ

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

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

References

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

| @労働

仕事面で 2017 年を振り返ると、いろいろやったけど自分でなんか作ったというのはほとんどない。 人のふんどしで相撲をとっていた一年（転職してからは半年強）だと言える。SaaS として提供されているツールを導入したり、 OSS の分析ツールを導入・構築したり、会社の仕組みを調整したりしてただけだった。各ライブラリを作ってくれた人には感謝しかない 🙏🏻

組織方面

  • チーム横断の定例 MTG 働きかけ
    • 人が増えて「あの人何やってるかわからない」「仕事を横からいきなり依頼される」などの問題が出てきたため、チーム横断の定例ミーティングを開催してお互いの状況を確認したり依頼しそうなことがあれば前もって共有するように
  • 全体ミーティングフォーマット整え＆司会業
    • かつては社長が考えていることを聞くだけの場だったが、チームごとに資料を作ってみんなで発表し、議論をする場に変えた
  • Slack 導入
    • Slack に変えるまでも別のチャットツール使ってたけど、平アカウントでは大したことできず、窮屈な感じがした
    • Slack は平アカウントでも外部ツール連携したり API 使ってなんかやったりできて便利
    • ベンチャーには平社員でも必要なことをやれるようなシステムの方が向いてると思う。 Slack はデザインだけじゃなくてそういうところが優れている。フラットで雰囲気が明るい。使うのが楽しくなる。
  • Kibela 導入
    • Wiki と Blog 、 Board （ Group ）の概念がちょうどよい。 Qiita:Team で厳しかったところが解消されている。
    • Kibela 導入以前、情報共有は Issue Tracker に何でも書いてる感じだったが、 Issue Tracker は Issue Tracker なので close することができない問題を扱うのに向いていない
    • タスクには落とし込めないけど社内で見解を表明しておきたい事柄を社内ブログに書いて問題意識をみんなと共有する文化を構築できた
    • Kibela は PlantUML で図を書けるのがとにかくすばらしい。込み入った処理フローをシーケンス図にすることで設計・実装がはかどる。
  • HRT について説く
  • OKR 導入
    • OKR を設定してやっていきましょうという風にした
      • とはいえ自分は HR の専門家ではないのでちゃんと運用して行くにはそういう人に入ってもらわないと厳しいと思ってる

エンジニアリング方面

  • t_wada （テスト文化根付かせ）業
    • No Test, No Merge
  • CI が回る仕組み構築業
    • テストコードは別の人が書いてたけど回せてなくて fail しっ放しになってたので気合いで通るようにして CircleCI で Pull Request ごとにビルドするようにした✌🏻
  • Pull Request テンプレート導入
    • どんな問題を解決する Pull Request なのか、何をやったのか、完了条件を明記する✅
  • Pull Request レビューフォーマット提案
  • gitignore されていた Gemfile.lock をリポジトリに突っ込み業
    • Gemfile でバージョンが固定されてた😢
  • Embulk で分析用データ書き出し業
  • autodoc で API ドキュメント自動生成の仕組み構築
  • Git Flow から GitHub Flow へブランチ戦略変更
    • 1日に何回もデプロイするような製品はこっちの方が向いてる
  • Rubocop 導入＆ .rubocop.yml 番人業
    • 👮🏻‍♂️
  • CircleCI から勝手に deploy される仕組み導入
  • docker-compose 導入
    • Docker は使われてたがクラスターの管理は手運用だったので docker-compose 使うようにした
  • AWS ECS 導入
  • 社内 Gyazo 導入
  • Redash 導入
    • 経営陣しか数値に関心を持ってなかったので全員が見るように毎朝 Slack に KPI を通知するようにした
    • 複雑なクエリを組んでテーブルごとに値を集計しているだけでは見えてこない値を追えるようになった
    • 独自に KPI/KGI を設定して Growth Hack に取り組むエンジニアも
  • リードレプリカ作ってデータ分析がやりやすくなる仕組み導入
    • RDS で Multi AZ にはなっていたがリードレプリカがなく重いクエリを投げられなかった
    • 複雑な JOIN クエリも書けるようになりデータ分析し放題
    • 来年は BigQuery とかも使えるようにしてさらに分析が捗るようにしたい
  • Itamae でプロビジョニング（ Linux アカウントの管理）
    • Itamae 一発で Linux アカウント追加できるようにしてサーバーサイドのエンジニアしか DB にクエリを投げられない状況を改善
  • cronbot 導入
    • 他人が作ったスケジュールも更新できて便利
    • KPI 通知は redashbot と cronbot を組み合わせて実現
  • iOS と Android のダウンロード数自動取得
    • iOS 側はタイムゾーンがずれる、 Android 側は更新が異常に遅いという問題があるものの、ある程度の目安となる数値が毎朝自動で Slack に通知されるように
  • お問い合わせがあったときに Slack に通知する仕組み導入
    • お問い合わせはカスタマーサポートの人が一手に引き受ける感じだったけどみんなが関心を持って見るようになった
    • カスタマーサポートの人からエスカレーションされる前にエンジニアが回答
    • 不具合あったときはいち早く対応可能に
  • Ruby app の前段に CloudFront 導入
    • app サーバーへのリクエストが半減
    • Nginx でキャッシュしきれてなかった静的ファイルを CloudFront でキャッシュするようになり爆速に
  • サイト全面 HTTPS 化
    • CSS/JS が並列で配信されるようになり爆速に

自分でまともな OSS を作れないことにコンプレックスを感じていた時期もあったが（ OSS コミュニティでの活動が評価軸となるような職場では全然評価されない）、自分が作れなくても他の人が作ってくれるので、それをいかに組み合わせて有効活用し、価値を生み出せるかに注力すればいいかなぁと思うようになった。

もちろん、 OSS 使っててバグを見つけたり不便なところあったら改善する Pull Request なんかは出していきたいと思ってる。ただ自分は頭がよくないし、抽象的な思考は苦手で個別具体的なコードを書くことしかできないので、自分で OSS を生み出すことは諦めて個別具体的な事象に特化してやっていく方が自分的にも世の中的にも幸せだよね、という風に割り切れるようになった。

こういう割り切りができるようになったのは Kaizen Platform で仕事する機会を得たからだよなぁと思う。 OSS への考え方に限らず、コードを書く部分以外で組織を変革したりだとかオペレーションの仕組みを変えたりだとかは全部 Kaizen Platform で学んだ気がする。1年11ヶ月と短い期間だったけれど、いまの自分の血となり肉となっていると思う。

Kaizen を辞めたときの記事で以下のように書いてたけど、いまのところ失敗を糧にしていい方向に向かってるのではないかと思う。

Kaizen でのリモートワーク失敗経験をどう今後の人生に生かすか。以下のツイートを繰り返し眺めながら悔い改めていきたいと思う。

— Kaizen Platform という会社について - portal shit!

というわけでいまは YAMAP という会社で働いています。元同僚の pyama86 さんに比べたら知名度では全然負けててミジンコみたいなもんだと思うけど、そのうち逆転できるようにプロダクトの完成度を高めていって pyama86 さんの方が YAMAP のパクりであるような雰囲気を醸成していきたい。今後ともよろしくお願いいたします🙏🏻

| @労働

プログラマーの種類、いろいろあると思う。

  1. ハッカー
    プログラミングが楽しくて、コードさえ書ければあとは何でもいいという人。
  2. OSS プログラマー
    1 と似てるけど、 OSS が楽しくてコードを書いてる人。カンファレンスで登壇したり、技術ブログを熱心に書いたりする。
  3. プロダクト指向プログラマー
    開発だけでなく事業の方向性にも口を出したい人。社長が死んだらいつだって代替ができる、というような気概の人。
  4. サラリーマンプログラマー
    プログラミングは仕事のためと割り切っていて、余暇には一切コードを書かない人。

1 〜 4 のどれか一つに綺麗に分類できるというものではなく、 1 かつ 3 とか、 3 かつ 4 とか、複数にまたがる人もいる。

職業プログラマーになりたての頃、サラリーマンプログラマーしかいない環境で働いて早くそこを抜け出したいと思っていた。プログラマーは会社の最下層で、プロジェクトマネージャーや営業が偉かった。プログラマーの人たちは仕事のために仕方なくプログラミングしてた。

それが嫌で余暇でもコード書くような人たちがいる職場に移ったけど、そこではハッカーや OSS プログラマーがよいプログラマーの代表とされていた（と思う）。自分もそういうのを目指し OSS カンファレンスに登壇したり技術的に中身のあるブログ記事を書いたりしたいと思ったけど、なかなかよいコードは書けないし、結婚して所帯を持つと町内会の草むしりや廃品回収、町内の運動会のテント設営、審判にかり出され、またあるときは子どもの幼稚園に夫婦そろって呼び出されて「お前らは夫婦そろって人間の屑以下だ、心を入れ替えるか幼稚園を辞めるかどっちか選べ」と説教されるなど多忙を極め、勉強会で話したりブログ記事を書いたりということが難しくなった。

一時期は自分は凡人プログラマーなんだろうなぁ、かつて忌み嫌っていたサラリーマンプログラマーと同じなのかなぁ、と将来を悲観していた。この頃は技術的な伸びしろがなくなって学ぶことに対する意欲が失せてしまっていた。

ただ、仕事で失敗プロジェクトを担当してつらい目に遭うことが多く、チームで仕事することだとか、失敗からどう学ぶかとか、その手のことに関してはそこそこ知見が貯まっていった。どうすればチーム開発はうまくいくのか、どういう風に情報を共有すればいいのかなどなど。業務改善のためにちょっとしたスクリプト書いたり、ぶっ壊れて動かなくなってる hubot スクリプトを直したり、 CI のセットアップを頑張ったりと、エンジニアチーム全体の生産性を上げるような落ち穂拾い業務みたいなタスクも好きだった。

いまは自分はチーム開発プログラマーなんだろうなぁと思う。ハッカー気質は皆無じゃないけどそこそこ、 OSS へのコントリビュートも気が向いたときに、プロダクトのことを気にする気持ちもある。どれも中途半端で単独では生産性高くないけどチームで仕事をするときに効能を発揮するタイプ。こんな風に自分が適している役割が分かると仕事がやりやすくなるし、目指すべき方向性のようなものが明確になって将来のことを考える上でも役に立つ。

ベンチャー企業で働く場合は自分のマインドやスキルセットが会社のステージにフィットすることも大事だと思う。もともとはベンチャー企業でも成功して上場しているような会社だとデプロイ時にハンコリレーなどがあってやるべきことをやるべきときにババッとやるのが難しい。そういうのは自分には向いてない。一方で起業したばかりの小さなスタートアップも、自分のような最初から綺麗なコードを書こうとするプログラマーはきっとフィットしない。起業したばかりのスタートアップでは自分たちの事業が社会から求められるかどうか不透明なので、そんな状態でテストがどうだとか CI がどうだとかチーム体制がどうだとかを言うようなプログラマーは必要ない。汚くてもクソコードでもテストコードなんて存在しなくてもいいからとにかく金を生み出すコードを素早く書ける人が向いている。

その意味でいまいる会社は創業当初の価値仮説の検証は済んでいて、これからいかに事業を伸ばしていくかというステージに入っているので、ちゃんとテストを書いたり、 CI を導入して継続的インテグレーションに努めたり、デプロイをいい感じにしたり、情報共有ツールを導入したり、開発チームの組織体制を云々したりといった部分で価値を発揮しやすい。

一握りの本当に優秀なソフトウェアエンジニアってのは受託会社だろうが事業会社だろうがベンチャーだろうが大企業だろうがどこにいたって価値を発揮できるのかもしれない。しかし自分のようなすべてにおいて中途半端なプログラマーは、自分に何ができるのかを理解し自分を必要とする規模とステージの会社を見つけてそこの門を叩くのがよいと思う。もちろん、事業に共感できるとか、チームメンバーとの相性も大事だけど、事業に共感できてもチームのメンバーがいい人ばかりでも、会社の規模やステージが自分を必要としなければ価値を発揮することは難しい。

関連してそうな記事

良いエンジニアの定義

良いエンジニアの定義

今年は転職して働く環境が変わり、自分のエンジニアとしての能力が足りないと痛感させられることが何度もあった。しかしそれは技術力が足りないというよりも、もっとほかのもののように思えた。良いエンジニア...

portalshit.net

| @労働

Kaizen Platform

Qiita:Team エントリのレベルが高い

CEO や CTO 、プロダクトマネージャーの書く Qiita Entry のレベルが高く、 Qiita:Team のタイムラインがはてブのホッテントリのようだった。ブックマークできるもんならしたいという感じ。お金を儲ける仕組みってこうやって作り出されていくんだなぁと思いながら眺めてた。技術顧問の伊藤直也さんが残していった名エントリも結構あった。 Kaizen エンジニア行動指針とか。

SRE （インフラチーム）のレベルが高い

インフラが盤石だった。 SRE は二人しかいなかったがとても仕事が速く、困ったことがあって Slack のインフラ相談チャンネルで相談したらたいてい 3 分くらいで問題が解決してた。

yosudo さんは問題解決能力が高すぎていまは SRE ながら VP of GA （総務部門のドン）やってるし、 glidenote さんは SRE 業務をこなしつつも R&D して新しめの技術をどうやってビジネスにフィットさせていくかを追求したりしてる。

SaaS や IaaS をフル投入したモダンな開発体制

SaaS や IaaS を使うのはかっこいいからとかエンジニアが楽しいからではなく、その方が最終的にかかるお金が少なくて済むし、事業の圧倒的な成長に対応（スケール）できるから。詳しくは yosudo さんのスライドをご覧ください。

Mackerel meetup #7 スタートアップとSaaS

Mackerel meetup #7 スタートアップとSaaS

speakerdeck.com

コードのクオリティが高い

Kaizen Platform も 5 年目に入っているのでプロダクトのコードがレガシー化しているところがあるのは否めないけど、レガシーと言っても本当に悲惨なレガシーコードとは比較するべくもなかった。ユニットテストはちゃんと書いてあるし1、インフラは AWS だし平均的な水準が高い。メインのシステムは Ruby と Rails で構築されていたけど、一部の機能を Go lang でマイクロサービス化したり、ログ集約サーバーは Node.js で構築されていたり、場所によっては C で書いて高速化してあるところもあり、特定の技術に依存するのではなく目的、状況に応じて柔軟に使う技術を選定していくところがこれまでにない感じだった。エンジニアが Ruby しかわからないから Ruby をずっと使いますというような消極的な技術選定ではなかった。

プロダクトマネージャーがいる

プロダクトマネージャー（ PM ）がいる会社で初めて働いた。データ取りとかは PM 自身ががんがん SQL 書いて取るし Domo や Redash などの BI ツールを PM 自身が使いこなしているので「○●のデータを本日 11 時までに大至急抽出してください！！！、！（現在 10 時）」みたいなことを割り込みで依頼されるということはなかった。プロダクトマネージャーは技術、ビジネス、市場、顧客のすべてに精通していてリーダーシップがあり、ミニ CEO のような人たちだと思った。

Kaizen Platform における BigQuery 活用事例 #bq_sushi tokyo #2

Kaizen Platform における BigQuery 活用事例 #bq_sushi tokyo #2

Kaizen Platform における BigQuery 活用事例 #bq_sushi tokyo #2 - Download as a PDF or view online for free

www.slideshare.net

QA チームがいる

PM のほかに QA チームの人がいて、 QA 観点で動作検証したり仕様に指摘をしてくれてめっちゃありがたかった。しかも QA チームの皆さんが優秀。エンジニアが自分で作って自分で動作検証するのではどうしても先入観が入ってしまって検証が不十分になると思う。むかし働いていたブラック企業では午後 10 時まで開発したあと午前 4 時まで自分で作ったやつを動作検証してエクセルエビデンススクショ職人業もこなしてたけどあれは本当に不毛だった。エンジニアが作ることに集中できる環境はすばらしい。

社長が近い

社長室などはなく、 CEO も普通にフリーアドレス席に座って仕事しているので CEO がすごく身近な存在で話しやすかった。会社にいる人たちも CEO に対して従順というよりは、その道のプロの人たちが集まっていて、若い CEO を助けるために一肌脱いでる感じがあった。雇われているというより雇われてやってる感じ。 CEO のことを親しみを込めて「スドケン」と呼び捨てにするし、むやみやたらに上下関係を作って序列通りにひれ伏すのはださいという雰囲気があった。

セールスが強い

こんなに強力なセールスがいる会社で働いたのは初めてだった。砂漠でこたつを売ってくる男の異名を持つ人がいたり。元リクルートの人たちを中心とした精強なセールスチームがいて、大企業からどんどん契約をとってきてた。自分はこれまで中小零細企業とか上場企業でも個人向けサービスをやってる会社でしか働いたことなかったので、こんなに大人っぽいカッチョイイセールスの人たちがいる会社で働いたのは初めてだった。

社員の趣味がエクストリーム

雪山スキーとかサーキット走行とかフルマラソンとか雨が降らない限り毎週末キャンプしてるとか鎌倉に住んで毎朝サーフィンしてから仕事とか、社員の趣味がエクストリームだった。アウトドアでなくても仏像なぞり描きと御朱印集め、囲碁、観葉植物、美食、マイル乞食、不動産運用、マンション管理組合理事など、趣味が中途半端な人がいなかった。

性善説とアンチマイクロマネジメント

社員は悪いことをしないという前提で会社が動いているように思った。承認システムみたいのがあるにはあったけど、新しい SaaS を使いたいときには CTO に相談すればよかった。マイクロマネジメントを嫌う風潮もあり、休みをいつ取るかなどは自由だった。細かいマネジメントをする方が無駄にコストがかかるし、そもそもマイクロマネジメントが嫌いで大企業を辞めてきた人たちで構成される組織だった。

求められる水準が高い

マイクロマネジメントされない一方で、求められる水準は非常に高い。四半期ごとの目標設定と評価面談では、目標として設定したことをこなすだけではマイナス評価となる。目標を達成するのは当然で、求められていること以上の成果を出すことができたかが評価軸だった。

採用フローで期待されていることを説明される

自分が受けた頃は採用にとても時間をかけていて、これこれこういうことを期待しています、ということを丁寧に説明された。 2 回くらい現場の人と面接して最後に重役と面接して「お、キミいいネ、採用！」という感じではなかった。むしろ最初に CTO と話して次に CEO に口説かれ、あとから将来同僚となるエンジニアやプロダクトマネージャーと話すという感じだった。採用フローでポジションや求められる役割について説明があり、入ってから「俺はマネージャーだったのに平で雇いやがって」というような期待のミスマッチが起こりにくかった2。

情報が閉じられていない

会社の売り上げ、状況は公開されていた。毎週金曜朝から行われる All Hands で数字の共有があり、目標に届いていないなどのアナウンスがあった。また隔月で行われる全社合宿（合宿だけど日帰り）でも会社と事業の現状について説明が行われ、社員全員で今後の方向性についてディスカッションを行う文化があった。

仕事をしていく上で、会社の経営状況について知らされていることは重要だと思う。かつて働いていたブラック企業は顧客が自分たちにいくらお金を払ってくれているかを教えなかった（教えたら自分たちが搾取していることが従業員にばれるため）。お客さんがいくら払ってくれているかを従業員が知らないと払ってくれている金額に応じた仕事をすることは難しいと思う。

厳しいなと思うところもあるけど、意欲がある人には機会が与えられる職場だと思う。総じてパワーのある会社だった。

なんでこんなことを書くのかというと、実は Kaizen Platform を先月で退職していた。すべて自分の能力不足が原因で、決してペパボを辞めたときのような積極的な退職ではなかった。前回の退職は前進だったけれども今回の退職はまさに撤退という言葉がふさわしい。なので退職日に合わせて記事を書くことができなかった。

Kaizen では入社早々に障害を起こしてしまったり、アサインされたプロジェクトを頓挫させてしまったりで在籍期間中に大したバリューを出すことができなかった。

ただ Kaizen Platform で働いた 1 年 11 ヶ月は自分にとって非常に貴重な時間だったと思う。リモートワークのおかげでこれまでにない生活をすることができた。家族が忙しいときに家事をしたり子どもの幼稚園の送り迎えをしたり。普通のお父さんではできないようなことができた。

なにより通勤がないのが素晴らしかった。通勤は実際に移動してる時間は 30 分でも家を出る前の身支度が必要だったり、なんだかんだで朝晩に 1 時間ずつ時間を取られてしまう。家族がいる人の場合はこれが自分だけでなく家族の負担にもなる。通勤に取られる 2 時間があれば洗濯や炊事ができる。この 2 時間が生活にゆとりをもたらしてくれていたと思う。

ダイエットにも成功した。糖質制限をして減量したけど、普通に朝から出社して働いていたら食事の準備に時間をかけられず、摂取しやすい炭水化物中心の食事を続けていまもデブのままだったのではないかと思う。

半日休む必要はないんだけど、昼間数時間だけ自分のことに時間を割きたい、用事が終わったらまた仕事しよう、というようなことができたのがとても良かった。病院通いがとても捗った。

こういうの、ワークライフバランスと言ってしまえばありきたりな感じがするけど、ちゃんとワークライフバランスを保つのは尊いことだと思う。

反面、リモートワークにはつらい面もあった。何をやればいいかが明確ではない状態でのリモートワークはとても難しい（参照: リモートワーク）。チームメンバーの意識が統一されていない状況にもフィットしない。何をやるべきかを自分で明確にできる人、遠隔でもリーダーシップを発揮できる人でないとリモートワークはこなせないと思った。自分にはその両方が欠如していた。誰からも管理されない状況で自分でやるべきことを明確にし仕事をしていくのは自分で自分を律することのできる人でないと難しい。サボろうとしているわけではないのに時間だけが経過していくのは非常にもどかしかった。小さい頃から親や学校の先生に「次はこれをやりなさい」、「あれをやってはダメ、これをやってはダメ」と指示監督されてきた人間が突如として管理されない状態で働くのはきつい。管理されて働いているときは管理者に対して不満を持ちつつも、管理されないと全く何もできない自分の不甲斐なさが露わになるばかりだった。

全体として、自分に足りない部分がわかった 1 年 11 ヶ月だった。上に挙げた、リモートワークをうまくやっていくための資質（何をやるべきかを自分で明確にできる、リーダーシップがある）は、オフィスでより良い仕事をしていく上でも必要なものだと思う。また自分のやりたいことに貪欲であるべきことを学んだ。エンジニアだけでなく、セールスやカスタマーサクセスなど違う職種の人と話をしていて感じたことだった。やりたいことがあるのに黙ってもじもじしててもやりたいことは回ってこない。やりたければ相応の準備をした上でやりたいと手をあげないとやらせてもらえない。空気を読まず、遠慮をしないことが良い仕事をしていくために必要だと感じた。

Kaizen でのリモートワーク失敗経験をどう今後の人生に生かすか。以下のツイートを繰り返し眺めながら悔い改めていきたいと思う。

  1. むしろテストコード多すぎて CI が遅くなるのが問題だったけど CircleCI に重課金してテストを並列実行して凌いでた。 ↩

  2. ただしたまに逆のパターンが起こってた ↩

| @労働

Kaizen Chat とは

Kaizen Platform 内でユーザー同士がコミュニケーションを取ることができるサービス。

  • Kaizen Platform のユーザー
    • カスタマー
      Kaizen Platform と契約し、 A/B テストツールや Growth Hacker によるサイト改善のデザイン案を募集
    • Growth Hacker
      募集に応じてカスタマーサイトのデザインを改善するデザイン案を投稿
    • Kaizen Platform 社員
      カスタマーと Growth Hacker の間の調整役

Kaizen Platform 内のユーザーが外部のツールや電話を利用して行っていた伝言ゲーム的なコミュニケーションを置き換えて、直接コミュニケーションを取ってもらうようになることが目標。

サーバーサイド 2.5 人、フロントエンド 2 人で 2 ヶ月くらいで作った。

構成

数多く存在しているマイクロサービスの中の一つとして実装。

フロントエンド

  • React
  • 多分他にもバズワード的な仕組み・フレームワークを使ってる（後で調べて書きます）

バックエンド

  • Ruby 2.3
  • Rails 5
  • MySQL 5.7
  • Sidekiq
  • Redis
  • Pusher (SaaS)

Rails 5 で開発

Rails 5 は Release Candidate だったが利用することに。

リリース直後に Rails 5 出て将来的に Rails 4 から Rails 5 へのアップデートにリソースを割くの避けたかった。（別の Rails アプリを 3 から 4 に上げたときには大変だった…）

Rails 5 で開発して困ったこと

あんまりないが強いて挙げるとすれば以下。

  • 個人的に好きで前職の頃から使ってた gem ( モデル層のバリデーションのテスト書くのが楽になる accept_values_for ) が Rails 5 対応してなかったので Pull Request 送ったりなど
  • ActiveResorces など Rails 5 対応が遅かった gem もあったが github 直接参照して対応版がリリースされたら rubygems.org を見るように変えるなど（普通です）
  • 社内の Rails プロジェクトで共通して使ってる gem を Rails 5 対応させるなど

WebSocket は Pusher (SaaS) を利用

Pusher を使った。 ActionCable 使って自前実装するのは考えなかった。

  • Rails 5 なら ActionCable では？？？？
    • 急なアクセス増などを考えて SaaS を使うことに
    • WebSocket に関してはインフラのことを考えなくてよくなる
    • 無理に自前実装せず、少々金がかかったとしても、外のリソースを利用できるときは SaaS を使う（社風）
      大人の事情で使えない、とかがないのがよい
  • フロントエンド側も Pusher から SDK が提供されており楽できた（はず）

Pusher との通信の詳細

  • CRUD のうち Read だけ Pusher 経由で行う
  • Pusher は Create/Update/Delete も担えるけど Rails アプリと Pusher とクライアントの間のデータの流れを一方向にしたかった

Kaizen Chat Pusher

感想

Sidekiq 速い

  • 社内で初めて Sidekiq を導入したけど速かった
  • Thread で並行処理をするのでスレッドセーフな作りにしないといけない（利用 gem 含む）
  • capistrano-sidekiq が sidekiq 本体と機能かぶってるところがあるのがちょっと残念

マイクロサービス間の通信が課題

  • マイクロサービス間でなるべく疎結合になるように、相手のサービス側の DB を直接参照しないように頑張る（気合い）
  • スピードが遅くなってしまうところはキャッシュする

BFF 的な考え方必要

  • ActiveModelSerializers 使ってると Serializer が乱立して収集付かなくなる
  • Frontend から必要なフィールド渡してもらってそれをシュバッと返すおシャンティな API にしていきたい

今後

  • モバイルクライアントの開発
    チャットなのに携帯電話で返信できないとかダメですよね…
  • 通知の充実
    チャットなのに通知こなくて気がつけないとかダメですよね…
  • 画像ハンドリングの充実
    負荷やジョブとの戦いに突入します。

Kaizen はチャットの会社じゃないので、自分たちがチャットの機能を作ることはどんな意味があるのか、ということを考えながら機能追加していきたいですね。

なお Kaizen Chat は Kaizen Platform にアカウントをお持ちの方でしたらどなた様でも無料でご利用いただけますのでもしよかったら触ってみてください。僕にファンレターを送ることも出来ます。

また Kaizen Platform, Inc. は本日（ 2016-09-08 ）から開催されている RubyKaigi 2016 にブースを出しておりますので CTO （リクルート時代に chouseisan 作ってた）やエンジニアと話してみたい人、 Kaizen Platform ロゴ入り手ぬぐいが欲しい人、僕のアイコンのステッカーが欲しい人はお気軽にお越しください。

| @労働

今年は転職して働く環境が変わり、自分のエンジニアとしての能力が足りないと痛感させられることが何度もあった。しかしそれは技術力が足りないというよりも、もっとほかのもののように思えた。良いエンジニアとは何なのかについて、今年一年で考えたことを書いてみたい。

良いエンジニアとは何だろうか。技術力が高ければ当然に良いエンジニアと言えるのだろうか。そもそもエンジニアに必要なスキルとは何だろうか。技術力がまず挙げられるだろう。良いエンジニアは当然に高い技術力を持っていて生産性が高いはずだ。

技術力に加えて、プロジェクトマネジメントのスキル（以下プロマネ力と省略）も必要なのではないだろうか。これまでの自分の経験を振り返るに、技術的に秀でたエンジニアはプロマネ力も兼ね備えていることが多いと感じる。技術力が高いエンジニアはプログラミングの能力が高いので、組織や開発体制を「プログラム」する能力が培われるのかもしれないが、技術的に秀でた人が必ずプロマネ力が高いわけではない。技術力さえ磨けば良いエンジニアになれると誤解してしまいがちだが、技術力だけ磨いてもみんなから求められる良いエンジニアにはなれないだろう。

ではなぜ技術力に加えてプロマネ力が必要なのだろうか。

一般に、コードを書かずに問題を解決できるならその方がよい。相手に言われるままにコードを書くよりも、コードを書かずに問題を解決できた方が時間も金もかからずみんなハッピーだろう。もしコードを書くとしても最小限の変更に抑えられるのが良いエンジニアなはずだ。技術力が高いだけではこういう発想は出てこないだろうし、真の問題が何なのかを見極め、解決策を考える能力が求められる。

良いエンジニアには先を見通す力も必要だろう。依頼された機能を開発するためにはどんな作業が必要か、どのくらい時間がかかりそうか、誰と調整しないといけないか。

関係者に働きかけ、周りを動かす力も必要だろう。理不尽な依頼が振ってきたときに、その依頼に対して反論し、相手を説得して実現可能なやり方を受け入れてもらわないといけない。

誰かに指示されるのを待たず、自ら動くことが出来る力も必要だろう。仮にプロパーのプロジェクトマネージャーがいたとして、プロマネの指示ばかり待ってコーディングしかしないようでは良いエンジニアとは言えないだろう。

このような、プロジェクトをコントロールし推進する力が良いエンジニアには必要なのではないかと思う。

そんなに何でも出来る人はいないのだから、スクラムをやれば良いのでは、という意見もあるだろう。確かに並エンジニアの集団ではスクラムが有効そうに思える。卓越したエンジニア一人で開発するよりも、数人の並エンジニアによるチームで難しい問題に立ち向かうストーリーの方がおもしろいだろうし個人的には好きだ。

しかしそうやって並エンジニアを寄せ集めても、そこから良いエンジニアは育たないのではないかと感じる。

スクラムチームでエンジニアは、スクラムマスターとスプリント計画、プロダクトオーナーとの「合意」により保護される。自分一人で問題に向き合い、問題を解決する能力がつきにくい。

一方でスクラムを採用していない荒野のような環境では、エンジニアはチームに頼れず、自力で要件を定め、関係者の合意を取り、自らプロジェクトを推進していく必要がある。そのような厳しい環境に身を置くことで、上に挙げたようなプロマネ力が身についていくのではないかと感じる。

これまでの自分のキャリアを振り返るに、以前勤めていた職場はまさに「荒野」といえるような環境だった。誰も何を作るかはっきり分かっていないんじゃないか、いきなり一人で工数見積もりやれといわれても出来るわけないだろう、こんなウォーターフォール開発はやめてアジャイル開発がしたい、こんなクソ会社辞めたい、といつも思っていた。

しかしつらかったのは自分にプロマネ力がなかっただけなのでは、と最近思うようになった。その後入った職場では、つらいこともありはしたものの、スクラム開発のおかげで個人が一人で抱え込んで苦んだりすることなく、チームで協力して開発することが出来た。その中で自分は自分自身の能力を過信したのかもしれない。実際には大してエンジニアとしての力は身についておらず、チーム開発やスクラムをやらない組織で働くことになったときに、自分の能力のなさを思い知らされたのだった。

本題に戻る。自分が良いエンジニアになるためには、技術力も当然足りていないと思うのだけど、プロマネ力を上げていかなければならないと思っている。来年の目標はそのあたりに置きたい。

Shut the fuck up and write some code.

はい。

| @労働

杖立の赤い吊り橋

転職してリモートワーク始めて 5 ヶ月たった。 Basecamp （旧 37 Signals ）の本で読んで夢にまで見てたリモートワークだけど、始めてみると理想と現実は違った。

良かったところは？

リモートワークだと通勤時間がないとかがよくあげられる。しかし自分の場合は福岡に拠点がある東京の会社に雇われていてそこで一人で仕事してるので通勤時間ゼロにはなってない。家で仕事する日もあるけど大体毎日片道40分くらいかけて通勤してる。必要なミーティングさえ外さなければ病院行ったりとか子どもの面倒見たりとかできるのはよい。あと午前中家で仕事して、昼間の空いてる電車に乗って座って仕事しながら出社できるのも良い。ただ仕事に時間の区切りがなかったり家で仕事できるということは、気になる仕事を夜や休みの日に家でやってしまって、フルタイムの社畜に成り下がってしまうリスクを伴うので注意が必要。

さみしいのか？

さみしいとか思うことはほとんどない。所帯持ちなので家に帰ったら嫁さんと子どもいるから全く孤独ということではないし、適度に前職の同僚の人たちと昼飯食いに行ったり酒飲みに行ったりしてる。ただ人と話すのに金かかるようになったの結構痛い。人と会うときは常にどっかに飯食いに行ったり酒飲みに行ったりという感じなので、交際費的な名目で毎月 2 万円くらい飲食にお金使ってる気がする。小遣い実質ゼロ円なので毎月子どもの頃に貯めたお年玉貯金を切り崩してしのいでる。

つらいか？

つらいかと言われればつらい。仕様の確認とか。毎日顔をつきあわせて仕事してたら簡単なことがリモートワークだとかなり難しい。 Slack や zoom などのコミュニケーションツールはあっても、姿が見えないのでいつ話しかければ良いかが分からない。大海原に一人で放り出された感がある。リモートワークできる人は限られてくると思う。

これらの経験を通して、大事だなと思ったことをまとめてみます。

大事なこと（道具編）

道具がリモートワークの質を左右する部分がある。インターネットの回線とかマイクとかカメラの品質を侮ってはいけない。

1. 良いインターネット回線

インターネットの回線悪いと会議してるときに聞こえないことあっても、大人数対一人でやってるとなかなか聞き返しづらい。なので回線はできるだけ太くて安定したやつを使うのが良い。よく分からない Public な共有 WiFi とかはネットを見るのには良くてもミーティングとかには使えない。インターネット回線は独自のものを使い、 WiFi は IEEE 802.11ac が望ましい。 Apple の AirMac Extreme が 50 デバイスまで接続できておすすめです。

2. 良いマイク

Rebuild.fm の初期エピソードと最近のやつを聞き比べて欲しい。 miyagawa さんがマイクにこり始めてからのエピソードの方が圧倒的に聞きやすい。会社でイエティマイクを買ってもらって使ってて、高いからもちろん高性能なのだけど、意外と良いのが iPhone についてくる Apple 純正イヤフォンマイク。高級イヤフォンつけてる人よりも Apple 純正の安いイヤフォンマイク使ってる人の方が声聞き取りやすかったりする。

3. 良いカメラ

カメラ、安いやつ使うと画質ひどい。変なエフェクトかかって真面目な話してるのにふざけてると思われたりして損な感じ。実はこれも MacBook Pro についてる Apple の標準カメラがかなり画質良い。

4. 良いビデオ会議ツール

Zoom というサービスを会社では使っている。複数人通話も無料で使えて Skype よりも便利。画面の共有も簡単。ユーザーアカウント作る必要もない。ほかにエンジニア同士だと appear.in というブラウザだけで完結するサービスを使ったりもする。

良い道具を使うことで避けられる問題は金で解決するのが一番です。

大事なこと（心構え編）

リモートワークをこなす上での心構えと、どんな人に向いていないかについて書きます。

1. 顔つきあわせて話す機会必要

全然人間的な関係が構築できていない状態でいきなりリモートワークやれっていうのは無理がある。人間は対面で話していると表情や身振り手振りなどで相手が冗談を言っているのか怒っているのかわかるものだけど、ビデオ通話越しだとその辺のことがとてもわかりにくい。なのでこの人はこういうとき冗談を言う人だとか、この人はとても怒りやすいとか、そういうパーソナルな情報を対面のコミュニケーションで補完する必要がある。自分は入社して最初の一ヶ月間、東京で仕事してある程度会社の人たちと仲良くなって、そのあとも月一回は東京に行って一週間ほど東京で仕事してる。ようやく最近同僚感出てきた。

2. オフィスにいる人たちの理解

リモートワークをする本人の能力が高ければ当然のことのようにリモートワークできるというわけではない。オフィスにいる人たちの協力がないとリモートワークは成立しない。たとえば職場では、ミーティングにリモートの参加者がいるときにはオフィス内にいるメンバーも全員ビデオ電話越しに話して同じ状況でミーティングに参加し、オフィス内のメンバーだけで議論が進まないように配慮している。リモートで働く人、オフィスで働く人お互いが協力して初めてリモートワークは成立する。

3. コミュニケーション不全を受け入れる

ビデオ電話で会話できるとはいっても、対面で話してたらすんなり頭に入ってくることも、ビデオ電話越しだとなかなか理解出来ない。人間は表情とか身振り手振りでのコミュニケーションが割合に多いということがよく分かる。思ったこと、考えていることを 100% 伝えられないかもしれない、という前提のもとで仕事する必要ある。なので確認はしつこいほど行った方がよい。

まえリモートワークつらい、みたいなことを Twitter に書いてたら、フリーランスで受託開発してる人だったら、顧客企業の担当と十分にコミュニケーションできないとか当たり前だし、リモートワークなんて余裕だと思う、という反応があった。確かにそうかもしれない。人から指示が来るのを待っているだけだと全然仕事が進まない。分からないことがあったらこちらからがんがん聞きにいって、自ら積極的に行動しなければならない。言われたことだけをやるという感じだと普通の会社でも使えない人みたいな烙印押されるけど、リモートワークだとその傾向が顕著になる。自分はこれまでの人生完全な指示待ち人間だったので普通の人以上にリモートワークをつらく感じるのだと思う。

このように圧倒的な当事者意識や頻繁な声かけなど、人間力の高さがリモートワークには求められると感じる。一人で誰とも話さずに仕事するのに逆説的な感じするけど、人とコミュニケーションとるのがいやな人にはリモートワーク向いてないと思う。

ここまで書いたところであらためて Basecamp の『強いチームはオフィスを捨てる』を読み直してみたら、自分が書いてきたことと同じことが書いてあった。リモートワーク、最近はニュースでも取り上げられたりしてサイコーみたいな扱いが多いけど、やっぱりつらい部分もあって、彼らもそのことについて触れていた。詳しくは「リモート時代のマネジメント」の章を読んでください。

まとめると、リモートワーク、本人の適性のほかに、会社自体がリモートワークを受け入れる準備ができていることが重要だと思う。また人とのコミュニケーションが好きではない人には向いていないと思う。むしろコミュニケーション能力高い人じゃないとつとまらない。

休みの日にゼータガンダム見てて、ニュータイプだったらリモートワークをうまくこなせるだろうなって思ってしまった。物理的に離れていても感覚で相手のことが分かるあの感じ。「この感覚、アムロ・レイか」。逆にいうとリモートワークをこなしていくことでニュータイプ特性を開花できるかもしれない。結論としてはリモートワークしたい人はゼータガンダム見てください。君は刻の涙を見る。

この記事はリモートワーク Advent Calendar 2015 の 23 日目の記事だけど二日遅れで書いています。遅れてすみませんでした。