マンガ・ロジスティクス・エフ

漫画とロジスティクスとFの話をします

株式会社オープンロジを退職します

2019/08中旬ぐらいで退職します。

だいたい1年8ヶ月ぐらいかな。 骨を埋める覚悟でいたので、こんなに早く退職することになって自分でもびっくりです。

なんの会社?

物流プラットフォーム「OPENLOGI」を提供するスタートアップ企業です。

https://www.openlogi.com

なにしてたの?

直近ではQAエンジニアをやってました。 新機能やバグフィックスなどに対する手動テストや、CodeceptJSを使ったリグレッションテスト自動化などを行っていました。

入社間もない時期は、フィールドエンジニア的にいろんな倉庫を回ったりもしていました。主に現場からのヒアリングとトラブルシューティングトラブルシューティングというのは例えば、

  • 「倉庫の隅のほうにWi-Fiが届かないからなんとかしてほしい」
  • 「プリンタから印刷されないんだけどどうしたらいいの」

みたいな問い合わせが現場から来たときに、リモートで調査・対応したり、それが難しいときは現地に飛んで調査する感じです。

Webの技術を使ってる会社で、ハードウェアやネットワークのトラブルシューティングをやる経験ってかなりレアだと思うので、非常に面白かったです。

なんで辞めるの?

端的に言うと、ロジスティクスよりテスティングのほうに興味が向いてしまったからです。

話すと長くなるので端折りますが、自分はもともと非エンジニアの物流畑出身で、物流の泥臭い部分を大いに嫌い、同時に愛してやみませんでした。 そんな自分にとって、物流スタートアップというフィールドはとてつもなく魅力的でしたし、入社時点では

「ワシの生きる場所はここしかないんじゃ、倉庫がワシの全てなんじゃ」

ぐらいの勢いでした。

それがまあ、いろいろあってQAをやることになり、仕事の幅を広げるためにアウトプットしたり勉強会に参加したりしてるうちに

「ヤダ……テスティング奥深い……」

ってなってしまい、そっちを専門にやっていこうと思ったのが動機です。

あと、まあ、なんというか、根っこの部分ってあんまり変わらないんですよね、物流もテストも。 特にいわゆるテスト実行の部分とかって、誰でもできる単純作業みたいなニュアンスで語られることが多く、物流業界と同様労働集約型の世界です。 そのへんをうまいこと解決して、テスティングをよりクリエイティブな仕事にしていきたいなーという方に情熱が向くのは、自分の中ではあんまりズレてない感じがあります。

もちろん、オープンロジで自社サービスの品質を高めまくるという選択肢もあったし、そうするつもりだったのですが、ご縁とかタイミングとかそういうアレで一旦お別れすることになりました。

さよならオープンロジ、そしてさよならストックオプション

紙切れになっても一応持っておきます。記念に。

ぶっちゃけ、なんかあったんでしょ?

ネガティブな理由はあんまり無いです。

強いて言えば給料が上がらなかったことぐらいですかね。 こればっかりは自分の力不足なのでどうしようもないです。

ただ、世の中全般に言えることですが、その会社で培った実績よりも、他社での経験のほうが評価されやすいのはなんとかならないもんかなと思います。

楽しかった?

楽しかったです。本当に。

楽しめた一番の理由は、カルチャーフィット、これが何よりだと思います。

趣味にしろ仕事にしろ、自分が好きだと思うものをチームメンバーも好きだと思っている、という価値観の一致は、(陳腐な言い回しですが)「自分らしく」働く上でとても大切な要素です。 それがあるからこそ自分は楽しく働けたし、チームのパフォーマンスに貢献するよう努力できました。

そんなわけで、趣味の合う人が多かったのはすごく良かったです。 おれはサイクリングと漫画とディック・ブルーナムーミンとPKDが好きなのですが、こんなニッチかつ幅広い趣味嗜好でも、社内を見渡せば必ずどっかしらに話の合う人がいました。 部分的に趣味の合う人(例えばヒロアカが好き、とか)に会うことはこれまでもあったのですが、自分の趣味嗜好全部について話せる人間が居る会社ってなかなか貴重です。

あと、物流が好きなメンバーが多かったこともうれしかったです。 前職以前のエンジニアは割と「言われた通り作ります」な人が多かったのですが、オープンロジのエンジニアはむしろ「俺自身がドメインエキスパートになることだ」ぐらいの勢いで物流にコミットしている人が多く、入社当時はPMとテックリードが専門誌を読んで談笑している、みたいなシーンもしょっちゅう見かけました。

(他方、自分が物流業界に居たころは、同僚も上司も物流には一切興味が無く……正直つまんなかったです)

子育て中のメンバーも多く、情報共有が盛んだったのも凄くありがたかったです。 Slackに #baby というチャンネルがあり、そこで我が子の写真をシェアしあったりして、子供好きには眼福でした。

Slackの話が出ましたが、Slackを中心にしたオープンなコミュニケーションが、自分はすごく気に入っていていました。 社内のあらゆる議論、あらゆる雑談をウォッチし、参加できるというのは、前職までのメール文化と比べて凄く新鮮でしたし、議論と決断までのプロセスが可視化されているというのは、決定に対する納得感を得る上で大変良いものだと思いました。

組織の成長と共に、ガイドラインの制定がなされたり、発言に気を遣わないといけないシーンも増えてきたのですが、これからもこのオープンさだけは失わないように大切にしてほしいと思っています。

成長できた?

技術的に成長できた部分も多いのですが、一番成長できたのはエンジニアとしてのマインドセットです。 優秀で経験豊富なエンジニアに囲まれてることは、こんなにもプロ意識を高めるものなのか……と思いました。

  • バージョン管理をする
  • ライブラリのバージョンを定期的に上げる
  • ドキュメントを残す
  • 分かるまで調べる/質問する
  • テストを書く
  • 技術的負債を返済する
  • エラーログを監視する
  • 負荷を監視する
  • インシデントに全力で対応する
  • OSSに貢献する

上記に挙げたようなことは、当たり前と言えば当たり前なのですが、これを当たり前にこなしていける文化を作るのは凄く大変だと思います。 それを作り上げてきたメンバー全員を、自分は大いにリスペクトしています。 小手先の技術よりもはるかに、エンジニアとして大切なことを学ばせてもらいました。

あと、地味なんですが、QAだからと言って特別扱いせず、徹頭徹尾エンジニアとして扱い、言い訳を許されなかったのは、凄く成長の糧になりました。 ざっくり言うと、DockerやGitは使えて当然、コードは読み書きできて当然、スタックトレースは追えて当然、みたいなレベル感です。 良く、QAとエンジニアの間に壁がある、みたいな話を聞きますが、オープンロジに限って言えば無かったのではないかなと思います。 だってどちらもエンジニアだものね。壁の作りようがない。

厳しくもあり、一方で質問や失敗に寛容で、わからないことややらかした時に気軽にヘルプを求められる環境も整っていました。 #dev-newcomer という、質問専用のチャンネルがあったのですが、newcomerという名前とは裏腹に、CTOすらこのチャンネルで質問しているというのはなかなか面白い光景でしたし、質問へのハードルを下げてくれました。

最後になんかいいたいことある?

冒頭にも書いたのですが、それこそ5年10年と働き続けて、みんなと上場を見届けることを夢見て働いてたので、辞めるのは結構、いや相当寂しいです。

みんな、体に気をつけて頑張ってね。上場記念パーティーには呼んでね。

これからどうするの?

某社でSETをやります。

社名、伏せる必要はなさそうだけど、入社前なんでなんとなく伏せとく。気になる人は直接聞いてね。

余談

送別会の幹事を自分でやりました。

f:id:tsuemura:20190807000318p:plain

イジメとかではないです。はい。

Codesandboxがとても良いという話

つい先日、都内で開かれていた初心者向けReact講習会に参加した際、開発環境として CodeSandbox が推奨されており、使ってみた所大変良いと感じたので紹介しておきます。

どんなものか

フロントエンド用の開発環境を秒でブラウザ上に構築してくれるやつです。 どのくらい秒かというと、本当に秒。ユーザー登録すらいらない。

  1. https://codesandbox.ioにアクセスする
  2. 右上のCreate Sandboxをクリック
  3. 使いたいフレームワークを選択

この3ステップだけで、Reactならcreate-react-appが、Vueならvue-cliでinitした感じのやつがクラウド上に構築され、かつブラウザ上で編集できるようになります。

良いところ

  • 繰り返しになりますが手軽にイチから環境構築できるので、Qiitaとかで見かけたサンプルコードをちょっと写経してみるときのハードルが低くなります。
  • 作成したサンドボックスを共有できます。講習会などで予め作成したコードを元に話をしたい場合、サンドボックス上でコーディングしてURLを配布すればOKです。

イマイチなところ

  • ライブエディットには対応していないので、複数人で同じサンドボックスを同時編集して、モブプロぽくすることは出来なさそうな感じ。
  • コマンドラインが使えないので、gulpなどのタスクランナーを走らせることは出来ません。Webサーバも立ち上げられないので、サーバサイドまで含めたWebアプリは作れません。この辺は既存のクラウドIDE(Cloud9とか)の方が向いてますね。
  • エディタがMonacaエディタ固定らしく、使い慣れたエディタがある人にはややストレスかも。VSCode使いの方にはよく似たサービスで https://stackblitz.com/があります。

個人的には上に書いた写経の例のように「ちょっと時間があるから勉強しよう」くらいの気持ちのときにちょうどよいサービスだと思っています。 あと、Chromebookしか持ってなかったりとかすると、こういうブラウザベースの開発環境は貴重ですね。今後も育っていって欲しい分野ですー

転職しました(2年ぶり3度目)

大学卒業して7年、何度か転職を繰り返し、こないだ3度めの転職をして4社目に入った。 最初の転職のときはなかなか仕事が決まらず1年半くらい転職活動を続けていたが、2回目以降はコツを掴んできて、1ヶ月足らずで内定まで進めるようになってきた。 色々と見えてきたことなどもあるので、備忘録代わりに残しておく。

最初の会社の話

新卒で入った。当時文房具が好きだったので文房具の問屋に入社して、酒が飲めなかったので営業にはならず倉庫管理部門に所属した。 基幹システムはいわゆるオフコン、黒背景に緑色の文字が煌々と光っている画面を見て「マトリックスかよ」とひとりごちたのを今でも覚えている。

そんな会社には4年くらい勤めた。倉庫での仕事は暑かったり寒かったりキツかったり汚かったり給料安かったり(残業代が出なかった)大変だったが、 なんだかんだで長続きしたのは、カイゼン系の仕事が自分には合っていたからかもしれない。 マトリックスみたいな画面にも慣れて、Excelマクロで作ったデータをVBScriptで基幹システムに自動入力したりとかして楽していた。

辞めたのは単純に仕事がキツかったのと、なんか報われない感じがしたからだ。 物流部門はコストセンターだ。誰よりも早く来て、誰よりも遅く帰っても、それで売上が上がるわけではない。 営業ばっかり評価されて、自分は評価されないのが不満だった。営業の新卒よりボーナスの比率が低かった時には上司に食って掛かった。

新しい職場はなんでもいいから楽な仕事にしたい!と思っていたんだけど、そう思っているうちは全然仕事が見つからなくて、 今までの経験を活かして新しい物流にトライしたい!と気持ちを切り替えたら面白いくらいスムーズに転職先が決まった。 軸足を定めるというのは大事なんだなと思った。

入社から一度も有給を使ったことがなかったので相当溜まってたはずだが、すべては消化できず、1ヶ月分くらい使った。 休みの間は、学生の時に取りに行かなかった車の免許を取りに行った。 教習が休みの日は、妻が仕事から帰るのを待って、一緒に夕飯を作って食べた。

次の会社の話

転職先は国内最大手の運輸業…の子会社のSI業…のやっている3PL部門という、説明が非常に難しい会社だった。 運輸業向けのシステムを作ってる会社がロジスティクスをやってるんだから、さぞや素晴らしいシステムを使っているのだと思っていたが、 その期待は初日で裏切られた。Accessだった。COBOLもあった。平和島の、6フロアもある広大な倉庫で、全体を管理するシステムは無く、それぞれの顧客ごとにスクラッチで構築したシステムが動いていた。入出庫予定は内線で荷受けのおっちゃんに伝えていた。 俺は泣いた。

俺はこの会社で初めて、真の「悪循環」というものを見た。 冒頭で「クソブラック」と評したが、恐ろしいのは会社自体は非常にまともで、立派に見えるのだ。 営業は受注に応じてインセンティブが支給される。倉庫は過重労働撲滅のために残業時間を抑制している。 サービス残業防止のために、入退館システムとタイムカードが連動しており、就労時間の過少申告が出来ないようになっている。 当然のように残業代は100%支給される。非の打ち所のないシステムだ。

だが、この素晴らしい仕組みも、マネジメント層がクソであることで一瞬で陳腐化するのだ。 なにしろ仕事が多いのだ。営業は仕事を取れば取るほどインセンティブがもらえるので、バンバン仕事を取ってくる。 難易度が高い仕事ほど他社は嫌うので受注しやすい。顧客ごとにアレンジされた、様々な流通加工案件が押し寄せてくる。 対して、倉庫は売上が上がる前から人員を増強するわけには行かないから、どうしても案件量に対して人員は不足傾向にある。残業時間はどんどん増えてくる。

そして、労基署の出番である。課長が労基署に出頭しお叱りを受ける。 課長は労基署に怒られたくないので、「なんとか今月の残業時間は45時間以内に納めてくれ!」と部下にお達しを出す。 だが、どうみても無理なのである。先月は80時間以上残業しており、今月の受注量は先月比2倍なのである。160時間残業しても足りないのである。 営業からは「課長の言うことなんて無視無視!どんどん残業して!」と言われる。だが残業すると課長から怒られる。完全に詰んでいる。

そんなわけで、気の弱い社員から順に、入退館システムをうまーくごまかしてサービス残業する羽目になるのである。そういう悪循環である。

そういうのに嫌気が指していたところに、妻が妊娠したのをきっかけに職探しを始めた。 1回目の転職活動で大体コツはつかめていたので、結構スムーズに内定が出た。 軸足は大事だ。俺の場合、物流とITが自分の軸にあるのが割と明確になっていたので、そこらへんをアピールした。

最終出社日に終電を逃して、会社に泊まって翌朝そのまま次の会社に出社した。眠かった。

次の次の会社の話

先に言っておくとウルトラホワイトだった。富樫の原稿より白かった。無無明亦無も真っ白の驚きの白さだった。 社員数10人に満たない会社で、コンサルみたいなことをしていた。給料は今までで一番高く、勤務時間は今までで一番少なかった。 リモートワーク可能だったので、子供が生まれたばかりのときは良くリモートで仕事していた。 社会人になって初めて、会社にウォーターサーバーがあるのを体験した。コーヒーも飲み放題だった。天国かと思った。

結局この会社も、自分のわがままで2年くらいで辞めてしまったのだけど、本当にいい会社だった。 ただ、変な話だけどこの会社は自分の軸に合ってないというのを長らく感じていて、そのギャップを埋めきれず、辞めてしまった。

次の次の次の会社の話

2週間くらい前から、物流系のITスタートアップに遅まきながらジョインして楽しくやっています。 入社初日から「エンジニアなのにITリテラシが低いね!」とマサカリを飛ばされて首が吹っ飛ぶ一歩手前です。

『アジャイルプラクティス』を読んだ

ここ2年くらい事業会社の一人SEをやってたんですけど、そんな生活に嫌気が差して11月から某物流系スタートアップに転職し、エンジニアチームの一員となりました。 なにしろチーム開発の経験が全然無いもんで、色々勉強することが多いなーと思っていたら、上司から「これ読みなよ」と渡されたのがこちら。

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

以下、簡単ですが所感をまとめておきます。

アジャイルとは「テクニック」ではなく「習慣」

アジャイル開発におけるテクニック、例えば「テスト駆動開発」なんかはそれ単体で議論できるほどのボリュームがあり、Web上の情報も含めて様々な所で触れることができる。 本書の中でもいくつか取り上げられているが、具体的な実践方法についてはほとんど書かれていない。

代わりに、開発の中で陥りやすいエクスキューズを「悪魔の言葉」として、 その習慣を取り入れるべき理由を「天使の言葉」として、 習慣を取り入れることで得られるものを「こんな気分」として紹介している。

「テクニック」はあくまで「テクニック」であり、実践するかどうかは各自の自由。 だけど、習慣として身につけ実践するとこんないい事がありますよ、ということを紹介するスタイルになっている。

オープンなコミュニケーションと共有

誤解を恐れずざっくり要約するならば、アジャイルな習慣とは * コミュニケーションを中心に置く * 課題とコードを共有する * 問題を先送りにしない ということだと理解した。

中でも、コミュニケーションは一番大切だ。 何しろ一番心に響いたのはエピローグ直前の最終第45節「みんなに知らせる」の、この一文だった。

悪いニュースを最後まで伝えないでいるということは、マネージャーや技術主任に「自分のことを事細かく管理してください」と頼んでいるようなものだ

エンジニアに限らず、大抵のチームで同じようなことは起きてるんじゃないだろうか?現に、自分も何度か「悪いニュースを伝えない」ことでやらかしたことがある。 だから、アジャイルでは毎朝スタンドアップミーティングを開き、日々各メンバーが一日やるべきことを手短に説明する場を設けたり、 Wikiやブログに自分の取り掛かっている作業やつまづいていることなどを「発信」する。

今のチームでもこの習慣は実践していて、毎朝カンバンの前に集まって朝会を開いて、自分が今日やるつもりのことを話したり、 Slackに”分報”チャンネルを各自作って、やっていること、やったこと、つまづいていることなどを都度発信している。

ちなみに、自分が大昔にいた(ITとは無縁の)職場では、朝会とは偉い人が話すのを部下が黙って聞く場だったり、失敗したことを報告して叱責を受ける「公開処刑」の場だったので、 「アジャイルを採用している職場では朝会をやっています」というようなことを耳にする度、「まじかよアジャイル最低だな」と思っていた。 (今は全然そんなことはない)

すべてを環境のせいにするつもりはないけれど、自分がよく「悪いことを抱え込んで後回しにしているうちに取り返しがつかなくなる」最悪の失敗をしてきたのは 上に書いたような良くない習慣がチームにはびこってたせいなのかもなと思った。

気に入った言葉

フィードバックをコーディングする

ユニットテストについての説明。文中では、従来的なprintデバッグとの対比で、

(デバッグのための)スタブコードを消さずに保存しておき、自動的に走らせ続けるんだ

との記載がある。 「これまでと何一つ変わったことはしていない、ただ洗練させただけ」ということだろう。

僕自身、人にTDDを説明するときは「チェックリスト2.0」なんて表現を使っていた。 プログラミングに限らず、仕事をする前にはチェックリストを作って、抜け・漏れがないか確認するものだ(トイレ掃除ですらそうだ)。 そのやり方をエンジニア目線でアップグレードしたのがTDDなのだ、と理解している。

ミドルレンジChromebook2機種比較レビュー (ASUS C302CA vs SAMSUNG CBPlus)

SAMSUNG Chromebook Plusを数ヶ月ほど使っていましたが、いろいろ使いにくい部分があってASUS Chromebook Flip C302CAに買い替えてしまいました。 同時期・同価格帯で発売された2機種をいまさらながら比較レビューしていきます。

TL;DR

  • エンジニアのサブ機にはC302CAがおすすめ
  • 非エンジニアのメイン・サブ機にはCBPlusがおすすめ

理由は後述していきます。

C302CAの良いところ

キーボードが打ちやすい

実は、昔購入したZenBookのキータッチが控えめに言ってクソだったため、ASUSのラップトップにはあまり良い印象が無かったのですが、ことChromebookに関しては、ASUSはしっかり作ってくれているようです。打ちやすいです。

筐体がガッチリしている

膝の上などでもたわまず打てます。代償として若干重いです。

Core m3搭載

開発用サブ機として使う場合、Linuxデュアルブートして使うことが多いと思いますが、ARM系プロセッサだとVirtualboxが動かなかったりして悲しい思いをします。 また、前の記事でも書きましたが、CrossOverというアプリを使うとChromeOSネイティブでSteamを動かしたりも出来ます。便利です。

CBPlusの良いところ

軽い

C302CAと比べて、持った感じが明らかに軽いです(実重量でもいくらか軽いんですが)。

電子書籍が読みやすい

ディスプレイ比率が3:2なので、漫画など固定レイアウトの電子書籍を見開きで読むのに適しています。

電車で使いやすい

横幅がかなり抑えめなので、電車で使っても横の人に迷惑を掛けにくいです(掛けにくいだけです。混んでるときは控えましょう)。

Chromeロゴが抑えめ

これはもう完全に好みのレベルですが、Chromeロゴが白黒でシャレオツです。

ChromebookでSteamを動かしてUNDERTALEがプレイできた

f:id:tsuemura:20171019225045p:plain

知っている人も多いと思うが、最近のChromebookではAndroidアプリが動作する。 そして、「Crossover」というAndroidアプリを使うと、Android上でWindowsアプリを動作させることが出来る。 つまり、ChromebookWindowsアプリを動作させることができる。

www.codeweavers.com

ただし、動作させるには以下の条件を満たすことが必要。

  • プロセッサがARM系でないこと
  • Androidアプリが動作すること

Wineベースで動いているらしい。

f:id:tsuemura:20171019225635p:plain

C302CAでオープニングのみ動かしてみたところ結構モッサリであった。若干音飛びもする。