株式会社トレタに入社しました

tl;dr

• 2016年1月に株式会社トレタに入社しました
• トレタは飲食店向けの予約台帳アプリを提供するBtoBの会社です
• オフィスで挽きたてのコーヒーが飲めます

株式会社トレタに入社しました

2016年1月4日より株式会社トレタで働いています。やっていることは今までとあまり変わらず、RailsでサーバサイドのAPIやバッチを書いています。
入社して3週間ほど経って新しい環境にも慣れてきたので、所感を書きつつ会社の紹介をしてみます。

トレタについて

エンジニアにはあまり馴染みのない会社かもしれませんが、飲食店の方がお店の予約を受け付けるためのiPadアプリ/web予約サービスなどを提供しています。
どんなアプリかは以下のムービーを見てもらうと雰囲気が分かるかと思います。

www.youtube.com

トレタに入社したモチベーション

「現場で使う人が使いやすいものを提供する」ことに高いプライオリティを置いて開発することができるという点に惹かれました。
昔自分がSIerにいた頃にやりたかった「使いやすさにこだわって仕事で使うための道具を作る」ということがこの会社ならできるという確信と、BtoBの現場ツールでもUXにこだわるべきという価値観が他のBtoB系のツールにも広まって、仕事の現場で人の手で苦労してやっていることが極力なくなる世の中になって欲しいという自分の思いがいい感じにマッチしたのが大きいと思います。

自分はUIデザイナーでもiOSエンジニアでもありませんが、そういうUIで価値を提供するサービスをサーバーサイドという裏方で支える仕事をしたいと思いました。そういうことに自分が今までためてきたサーバーサイドの知見を活かしたいなと。

なお会社のブログに書いた入社エントリーではもうちょっと詳細に書いてるので併せて参照ください。 toreta.blog.jp

自分の仕事について

• 自分の肩書は「サーバーサイドエンジニア」となっていて、トレタのAPIや、他社サービス連携などのRailsで動いてる部分をなんでも開発するのがおしごとです。
• 入社して日が浅いのでまだ目立った活躍はしてませんが、今動いてるRails appの足回りを整備をしたりBugsnag入れて見つけたerrorをつぶしまくったりしています。
• 今日はshoryukenの練習をしていました。

トレタの開発について

メンバー構成

現時点で正社員のエンジニアは自分入れて10名程度で、

• iOS(Obj-C、一部Swift)
• フロントエンド(AngularJS etc)
• サーバサイド(Rails)
• インフラ
• QA

と役割が分かれています。

• 年齢層は20台後半～40歳ぐらいで、30台半ばが一番多いです。CTO(増井さん)が一番上で、自分(29)は下から2番目ぐらいですかね。
• BtoC webサービス会社から来た人が多いです。
• みんな穏やかで話しやすい人達です。

開発環境

• 開発マシンはMacBookProの13inchか15inchを選べます(keyboard配列もjis/us選択可)
• 動作確認用のiPadも全エンジニアに支給されます。
• サブディスプレイも必要であれば買ってもらえるみたいですが、自分は使わないのでMacBookPro13一台だけで開発してます。
• 開発フローはよくあるGithub Flow
• チャットツールはslack（エンジニアだけでなく全社員が使用）
• doc管理はesa.io, google drive
• 席はフリーアドレス
• エンジニアの多くはオフィスにあるカウンターに集まってスタンディングで健康的に働いており、時々豆を挽いてコーヒーを淹れます。
• エディタはemacs派、atom派の順に多い印象です。
• 稼働時間はフレックスなのでまちまちですが、大体10時～19時ぐらいの人が多い気がします。
• 家賃補助が出るのでオフィス(五反田TOC)の近くに住んでる人が結構います
  • 自分もオフィスまで徒歩10分弱のところに住んでるので徒歩通勤しています。電車のらなくていいのでサイコーです。

オフィス環境についての参考リンク blog.kushii.net

続きはオフィスで

• エンジニア募集しています。
• 弊社エンジニアと話だけでもしてみたいという方はwantedlyからお問い合わせください。

www.wantedly.com

退職しました

tl;dr

• 2015年12月31日付で今の会社を退職します
• 2016年1月1日付で次の会社に転職します（初出社は休み明け）
• 次の仕事については、入社したあとにしばらくしたら別エントリで書きます

おまだれ

• ここ１年半ぐらいwebサービスの受託開発をしていた三十路手前のエンジニアです
• 主にRailsでサーバサイドの開発をメインにやってました

退職しました

• 実際には12月1日から有給休暇していて1ヶ月充電してました
  • 水族館に行きまくったり金沢に旅行行ったりジブリ美術館行ったりerlangやclojureや機械学習に入門してみたり自由に過ごしてました
  • 2週間ぐらい仕事してないと人は無性に仕事をしたくなるのだなという知見を得ました
• 休みの間に栃木の実家から都内に引っ越して一人暮らしを再開しました

何を達成したのか

• リモートワークで受託開発をしました
• エンジニア最大４人ぐらいでやってた案件でリードエンジニアっぽいことをさせていただきました serihiro.hatenablog.com
• ちゃんとしたRailsでの開発、PR駆動開発、ちゃんとテスト書いてCI回しながら開発するスタイルを初めて経験できました
• ある程度大きなRails appの書き方が分かりました
• オレオレ流でぐちゃぐちゃにしか書けなかったrspecがDRYに書けるようになりました
• hubotでメンバーをランダムにアサインするおみくじbot作って社内slackで運用したりしました
• Angular(1.x)何となく書けるようになりました
• 以前から気になっていた企業のエンジニアチームの中に入って一緒にお仕事をさせていただきました
• 自分がコードを書くエンジニアへの道を志すきっかけとなった人とお話させていただく機会をいただきました

なぜ辞めるのか

• 自分の人生で達成したいことを熟考した結果、新卒の時にITの道を選んだ時の原点に戻って、「自分が新卒の頃にやりたかったこと」をできる会社で働きたいと思ったからです
• 具体的には入社エントリに書きます

次なにやるのか

• とあるBtoBサービスの開発に関わります
• リモートワークではなく通常のオフィスワークになります
• 次の職場での仕事が落ち着いてきたら入社エントリに書きます

最後に

大学時代を過ごした岩手県盛岡市、高校まで過ごした栃木県栃木市。
この仕事を続けている限り、これらの場所には二度と住めないと思っていました。（次に住めるチャンスがあるとしたら定年退職した後かなと思っていました）
それが、その場所に住みながらやりたい仕事をさせていただけるという恵まれた機会を与えてくれたのはこの会社でした。
リモートで働くことを続けてこられたのは私の力だけではなく、同僚、お仕事をさせていただいたクライアント様、自分の家族をはじめ、周囲の人の理解とサポートがあってのことです。
この場をお借りして御礼申し上げます。

Re: 転職考えてるんだけど

「転職考えてるんだけど」という相談を業種問わず最近よくされる。なぜかは分からないが、転職に関しては知見豊富なベンリなやつだと見られているらしい。

相談されるのは結構なのだが、なんかこう具体的なアドバイスまで話がいかないで終わってしまうケースが多い。 自分個人がそこまで他の業界に詳しくないというのもあるのだが、話を掘り下げていくと「転職に対する温度感が今は低いよね、やりたいこともないよね、だから急ぐ必要はないよね」という結論になって終わってしまう。

そういう人たちとの会話は大体こんな感じだ。

「ずっと☓☓都/道/府/県にいたから◯◯都/道/府/県で働きたい」

ふんふん◯◯ね。なんで？え、何となく？まぁ私も何となく盛岡に住んでたことあるし、いいんじゃない？

「もうちょっと違う仕事がしたいっていうか」

違う仕事ね。。どのくらい違えばいいの？そもそもどういう変化がほしいの？…あ、まぁ他の仕事のイメージって難しいよね…

「新卒で入った会社にずっといるし、１回くらい転職してもいいかな～というか」

それは分からんでもないけど、給与が安い若手と違って歳もまぁまぁいってるから、職種・業種ガラっと変えるのにも理由がしっかりしてないと難しいと思うよ。うん。私もなんだかんだでずっとエンジニアだから転職できているのもあるし…

「将来特にやりたいことはないんだけどさ」

そうだよね！人生ってわからないよね！（じゃあ転職みたいにハイリスクなことはしない方がいいんじゃない…）

要するに、

• 今の仕事に大きな不満はないが
• 同じことを続けてきていて飽きて
• ついでに私生活にも刺激が欲しい

乱暴にまとめるとこんな感じか。

そういう動機で転職考える人だとこういう話になりがちである（serihiroキャリア相談室の統計による）。

そういう人には、転職を勧めないで、まずは自分が次にやりたいこととか、自分の３年後ぐらいまでのキャリア設計をちょっと考えてみなよ、とか何とか一般論の話になってしまう。もし私がキャリアコンサルタントになったらまともなアドバイスができず間違いなく食いっぱぐれてしまいそうだ。。。

いやでも、実際世の転職というのはどういう動機で行われるケースが多いんだろうか。

転職理由ランキング＜2015年4月～9月＞ 総合 ｜転職ならdoda（デューダ）

上記のリンク先の資料によると、多い順にほかにやりたい仕事がある、会社の将来性が不安、給与に不満がある、残業が多い／休日が少ないらしい。ふむ。割とネガティブ駆動なのな。。

自分の周りのエンジニアは「よりよい環境を求めて」というケースが多い気がする。ブラック企業なので逃げ出した、というのは聞いたことがない。給与はそれなりにもらってるがやりたいことが出来てない、このままいても出来そうにない、という課題設定に対する解として、転職という手段を実行する。
ただ、これって自分の周囲がそうなだけで、全体としては「やりたいこと」が明確で、それに向けて努力して実現できる人というのはそこまで多くないのかもしれない。だからあまり明確な動機というのもそこまで必要じゃないというか、ふわっと転職しても案外なんとかなる。。のか？
分からない。少なくとも自分は、そんな無責任な後押しをしたくないので、堅実に話を聞いていきたい所存である。

堅実さが第一、serihiroキャリア相談室を来年もよろしくお願いします。

なお、過去に以下のような話を書いているので、紅白で知らない人が出てきて暇な時にでもどうぞ。

serihiro.hatenablog.com serihiro.hatenablog.com

2015年総括

2014年版はこちら serihiro.hatenablog.com

tl;dr

• 変化は多いがアウトプットが少ない１年だった
• 来年30歳で節目の年である
• 来年からもがんばるぞい

今年初めて出来たこと

• 高校卒業して以来初めて実家に住んだ serihiro.hatenablog.com

• 初めてchatopsを業務で導入しているプロジェクトに参画した

• 自分がエンジニアになるきっかけになった人と会話した
• クラシックギターのレッスンを受けるようになって基礎からフォームと練習方法を見直した
• マンドリンオケ活動を止めて独奏に専念することにした
• AngularJS(1.x)をプロダクションで書いた
• browserify,grant,gulpのそれぞれの役割と違いと今どれを使うべきなのか、ということを今更ながら勉強した
• １人で平泉・松島旅行した
• プログラミングマサカリ勢の前でjava8を紹介するLTした speakerdeck.com
• clojureを勉強した
• erlangを勉強した
• １人で金沢旅行した
• 東京へ戻って一人暮らし再開した

去年と比べるとチャレンジの少ない１年だったと思う。来年は積極的に新しいことをやらねばならぬ。

今年書いてヒットしたエントリ

多少不満があっても地味な仕事の積み重ねが将来を作るよという老害臭いエントリ。俺も歳だな。。 serihiro.hatenablog.com

指示を受けるだけでなく出す側にも回った知見をまとめたエントリ。実際良い経験になった。 serihiro.hatenablog.com

リモートワーク知見。 serihiro.hatenablog.com

長期目標を持てない自分の話。でもそろそろ30歳だし、仕事においては長期目標持って長い目でやっていかないといけないなとも思ってる。 serihiro.hatenablog.com

今年やろうとしたができなかったこと

• gemを一つも公開できなかった
  • そもそもアイデアが出なかったという向きもあるがいまいちrubyのライブラリを書くことがモチベーションにつながらなかった
• ヴァイオリンはサイレントヴァイオリンでも音がでか過ぎて部屋で弾けるものじゃなかったので断念
• 勉強会LTは結局渋谷javaと社内勉強会でしかできていない。外部に交流を広げることができていなかった。これは来年は是非rubyのコミュニティでも発信できるようにしていきたい。
• アマチュアギターコンクールはレッスンに通い始めて基礎から再学習し始めたこともあって断念した。来年以降は考えたい。
• ギターのレパートリー増加についてはレッスンでやっているエチュードとバリオスのフリア・フロリダしか出来なかった。来年はエチュード系以外にもう4曲(3ヶ月×4)は新たに覚えたい。

来年の展望

• ただの作業エンジニアから脱出してプロダクトの方向性を考えて機能を提案できるようにしていきたい
• erlangを勉強した限りではマイクロサービスに適したエコシステムを持っている（どちらかと言えばOTPが）と感じたのでさらに深掘りしていきたい
• そろそろヤンチャを止めて腰を落ち着けて生きていきたい
• そろそろ老後のことを考えて計画的に貯金をしていきたい
• 運動不足が深刻な体調不良をもたらすことがよく分かったのでジョギングを続けていきたい

Bluetooth + ノイズキャンセリングなヘッドホンBackBeat PROが良い感じだった

この記事は今年買ったもの Advent Calendar 2015の18日目の記事です。

今年買ったノイズキャンセリング+ワイヤレスなヘッドホンBackBeat PROがかなり良い感じだったので紹介します。

なぜ買ったのか

• 片道2時間という長時間通勤をするようになり、以下の問題が発生した
  • それまで使っていたワイヤレスイヤホンのバッテリー２時間では足りなくなってきた
  • 周囲の騒音に晒されている時間が増えてイヤホンだけではしんどくなってきた
• バッテリー持ちの良いイヤホンを新調してもよかったが、もともとノイズキャンセリング商品に興味があったので買ってみる良いチャンスだと感じた

どうやって選んだのか

• ノイズキャンセリングヘッドホンの売れ筋価格帯である2万円前後の商品はコード付きが多かった
• しかし電車の中で使用する以上ワイヤレスがいい
• ノイズキャンセリング + ワイヤレスでそれぐらいの価格帯だとソニーのMDR-ZX770BNが2015年7月当時話題になっていてレビューがメディアに多く掲載されていたが、「品質は価格相当」「ノイキャン＋ワイヤレスなら許せるレベル」みたいな論調が多く、どうも微妙な気がした（店頭で試したわけではない）
• そんな時にBackBeat PROのレビューをたまたま読んだ所、音質もノイキャンの性能も悪くなく、バッテリー持ちは24時間あってヘッドホン使用時にもボタン一つで外部マイクをオンに出来たりとか色々通勤時に便利そうな機能があったので、思い切って購入した。

どこで買ったのか

Amazon

使ってみてどうか

価格は約3万円とソニーのMDR-ZX770BNより1万円弱高かったが、それ相応の価値はあると感じた。

• 音質は3万円のヘッドホンの音かというとその辺は微妙だが、少なくとも電車での通勤時は問題なく使用できるレベル
• ノイキャンはかなり優秀で、特に電車に乗っている時の低音をかなりカットしてくれる。電車に乗っている時にノイキャンをOFFにするとそのギャップにびっくりする
• バッテリーの持ちは非常に良い。往復で4時間使ってもバッテリーは半分も減らない。また、3時間ぐらいの充電でフル充電できる。
• 操作もシンプルで使いやすい。

テキストチャットにおけるコミュニケーションの難しさについて #remoteadvent

この記事はリモートワーク Advent Calendar 2015の13日目の記事です。

tl;dr

• リモートワークにおける主要なコミュニケーション手段は「テキストチャット」
• テキストチャットでなかなか意思疎通ができない時のストレスはかなり大きいが、少しの工夫でかなり改善できる
• お互い思いやりを持ってテキストチャットを使うことでストレスの少ないリモートワークライフを

前情報

• 筆者はwebエンジニアでフルリモートで仕事をしていました
• 普段の業務にSlackなどのテキストチャットツールを使用していました

チャットで全ての業務上のコミュニケーションを賄うということについて

リモートワークをしていると「それで問題は起きないのか？」という質問を今でもいろんな人から聞かれますし、リモートワークを始める前まで自分も疑問視していました。

なので、リモートワークを始める前は、実際の業務はビデオチャットとかを多用して口頭でのコミュニケーションが多いんだろうなーと思っていましたが、実際は業務上のコミュニケーションはテキストチャットで大体何とかなっていました。

エンジニアという仕事は、テキストでのコミュニケーションが多い職種です。仕様はドキュメントに記載され、成果物も一種のドキュメントであるソースコードだったりインフラ作業のログだったりします。だからもともと相性がいい、といえばそうなのかもしれません。もちろん、複雑な仕様を説明したりするときには、テキストや画像だけでは限界があるのでビデオチャットを使います。

質問が難しい

しかし、テキストチャットで長文のやり取りを続けるのは、会話よりもずっと労力がかかります。少なくとも自分は、50文字ぐらいの文字数で伝えなければならないことであればチャットより口頭で会話した方がずっとラクだと感じます。

特につらいと感じるのは１回で伝わらない時で、その場合以下のようなやり取りが行われます。

1. メッセージを送信する
2. 相手からの受信を待つ
3. 相手に意図が正しく伝わらなかった模様
4. 再度メッセージを送る
5. やっぱり伝わらないので再度伝え直す

2の「相手からの受信を待つ」というのは、場合によるがその間何も出来ないということを意味します。

作業を再開しても再開後１分で返事がきてまた中断されるので、この間うまくチャットと自分の作業の間で自分の意識を行き来するスキルが要求されます（あるいはすぐに返事しなくてもいい情報を見極めるスキル）。慣れたとしてもやはり作業を細切れに中断されるのはなかなかにつらいものがあります。 逆もまたしかりで、相手からの質問の意図をこちらが読み違えると同じやりとりを今度は相手にも強要することになってしまいます。普段物理的に会うことが少ない関係で、すぐに口頭でフォローすることも難しいので、こういうやり取りはお互いのストレスの原因になる可能性があると思っています。

具体例として、自分がよく直面したエンジニア同士のうまくいかないパターンのコミュニケーションでは以下の様なものがありました。

エンジニアAとエンジニアBのチャットである。

• エンジニアA「@B これは何でしょうか？ https://github.com/xxxx/yyyy/pull/4169/files#diff-fd8ab12」
  ※URLはgithub上のPRのdiff上のとある行を指定している
• エンジニアB「@A ああ、この修正を入れた意味ですか？それは○○が×××で（中略）△△です。」
• エンジニアA「@B いやそうじゃなくて、□□なのに（中略）という意味で聞いたんですが。」
• エンジニアB「@B ああ失礼しました。それは■■の場合(中略）です。」
• エンジニアA「@B なるほど了解です。理解しました。」

なんてこともない話ですが、エンジニアA→エンジニアBからの質問が1回で正しく伝わっていればやり取りは1往復で済んだはずです。

また、2往復になるにしても、エンジニアB→エンジニアAへ回答する前に、質問の内容に不明瞭な点があるなら一度そこで質問して不明瞭な点を確認することでエンジニアBは2回説明する手間を省けたはずです。

ビジネスメールの基本に解決策がありそう

この問題を解決するためにいろいろ試行錯誤した結果、自分が行き着いたのはいわゆる「ビジネスメールのマナー」でした。（筆者は新卒でSIerに入社していて、当時は社内外のコミュニケーションには主にメールを使っていました）

自分が新卒の時に新卒研修で教わっていたことを思い出すと、以下の３点のことが重要だと教えられました。

• 最初に「相手にどういう行動を起こして欲しいか」を完結に書く
• 1行は長すぎず、かつ過不足無く
• 最後に相手をねぎらうような言葉を入れる

これを元にさきほどのやり取りを改善するならこんな感じになるでしょうか。

<質問の仕方を修正する>

• エンジニアA「@B ちょっと確認したいんですが、この修正はこのPRの別の部分と重複してるように見えたので不要かなと思ったんですが、どうでしょうか？ https://github.com/xxxx/yyyy/pull/4169/files#diff-fd8ab12」
• エンジニアB「@A ■■の場合に(中略）です。」
• エンジニアA「@B なるほど。理解しました。」

<回答する前に質問の意図を明確にする>

• エンジニアA「@B これは何でしょうか？ https://github.com/xxxx/yyyy/pull/4169/files#diff-fd8ab12」
• エンジニアB「@A すみません一応確認ですが、この修正の意図が分からないという質問でしょうか？」
• エンジニアA「@B はい。□□でやってるから不要じゃないかなと。」
• エンジニアB「@A なるほど。それは■■の場合に(中略）です。」
• エンジニアA「@B なるほど。理解しました。」

前者の例はやり取りが1回になって時間短縮になりました。 後者の例ではやり取りの回数は同じですが、エンジニアAが2回説明していない分、エンジニアAの手間は少く、スムーズに回答できるのでお互いのレス待ちの時間も短くなることが期待できます。

このように、ほんのわずかな言葉の使い方次第でテキストチャットでの質問をスムーズに行うことができるようになります。 言われてみれば当然ですが、普段業務で忙しいと省略してしまうような言葉をほんの少し添えるだけでお互いの時間をかなり節約することができます。そのことに気づいてからは私はテキストチャットで質問するとき、される時は常に気をつけるようにしています。

テキストチャットもまたビジネスコミュニケーションである

テキストチャットはメールほど形式張ったものではないのでついカジュアルな文章で書いてしまいがちです。これはテキストチャットの良いところでもありますが、仕事上で重要な事は確実かつ迅速に伝える必要があります。

エンジニアにとっては、設計について議論するとき、コードレビューで指摘するとき、質問るときに発生するコミュニケーションは、すべて仕事上での重要なコミュニケーションです。同じチーム内であれば、「ビジネスメール」ほどの格式張った形式は不要だと思うしそんな文化になって欲しくはないと思いますが、仕事上のコミュニケーションにおいては確実に要件を伝え・伝えてもらえるコミュニケーションスキルを身につけておくべきだと私は感じます。

日報 2015-12-03

午前中にやったこと

• 今年一発目のアドカレを予約投稿して拡散した

serihiro.hatenablog.com

• 引っ越しの荷造り続き
• 艦これ秋イベE-5乙ラスダン

[WIP] Erlang勉強

資料

今日の成果

• [done]第二章 moduleの定義
• [wip]第三章 関数の構文 ガード句まで

log

• InteliJ IDEAにはerlangプラグインがあるようなのでこいつを試すぞ

qiita.com

• repl中のcurrent path移動はcd(PATH)
• erlangをjvm上で動かすerjangという言語もあったとか。。
• repl上でコンパイルするときは compile(MODULE) 又は c(MODULE)
• :tada:

github.com

• 次はマクロだ -define([MACRO],[VALUE])
• 関数節マジ :cool:
• 見た目はメソッドオーバーロードだけど実体はswitch文にちかい
• 引数でパターンマッチだと！許せる！

25> useless:greet(male,"Tarou"). 
Hello, Mr. Tarou!ok
26> 
26> useless:greet(female,"Tarou"). 
Hello, Mrs. Tarou!ok
27> 
27> useless:greet(femal,"Tarou").  
Hello, Tarou!ok

• これ前にnaoyaさんがelixerで処理書くときに呼び出すcallbackを引数の内容で決められるとか言ってたやつかな qiita.com

• erlangのガード句にはユーザー定義の関数が使えない。うーむ