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

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

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

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

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

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

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

社会適応能力の低下

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

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

良い面もある

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

ワークライフバランス

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

集中維持

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

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

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

まとめ

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

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

References


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

| @労働
仕事面で 2017 年を振り返ると、いろいろやったけど自分でなんか作ったというのはほとんどない。 人のふんどしで相撲をとっていた一年(転職してからは半年強)だと言える。SaaS として提供されて...

仕事面で 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 のパクりであるような雰囲気を醸成していきたい。今後ともよろしくお願いいたします🙏🏻

YAMAP

| @労働
プログラマーの種類、いろいろあると思う。ハッカープログラミングが楽しくて、コードさえ書ければあとは何でもいいという人。OSS プログラマー1 と似てるけど、 OSS が楽しくてコードを書いてる人...

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

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

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

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

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

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

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

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

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

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

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

関連してそうな記事

| @労働
Qiita:Team エントリのレベルが高いCEO や CTO 、プロダクトマネージャーの書く Qiita Entry のレベルが高く、 Qiita:Team のタイムラインがはてブのホッテント...

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 さんのスライドをご覧ください。

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

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

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

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

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 Pl...

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 とクライアントの間のデータの流れを一方向にしたかった

図

感想

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 ロゴ入り手ぬぐいが欲しい人、僕のアイコンのステッカーが欲しい人はお気軽にお越しください。