punchdrunker.log

2019年に仕事でやった事

仕事がgithub中心に回っているので、closeしたPRの一覧を眺めて2019年をふりかえります。

frontend

自分は大したことはしていないが、PCブラウザ用の実装が必要になり、1、2ヶ月間くらい集中してreact + redux + typescriptを書いていた。reduxは話でしか聞いたことがなく、概念を知っていただけだったので、実際に書いてみてどんなものかが理解できた。

夏以降は継続的に実装することもなくなったので、今はvue.js + nuxt.jsを使ってfirestoreのデータをいじる実装を勉強している。小規模開発ではvueの方が小回りがきいて楽に書ける気がするので、今のところvueの方を気に入っている。

iOS

大きめの仕事はあまり無いけどUIWebViewからWKWebViewへの移行を一気にやった。ちょっと調べればハマりポイントがたくさん出てくるが、それでも苦労するくらい大変だった。1度のリリースで全部うまく行ったわけではなく、2、3度のリリースで調整していって、何とか意図する通り動いてくれている。

また、古い画面でテストもほとんど無かったので、MVPパターンぽい構造にして各種入力に対して適切に振舞えるかのテストを書けるようにした。

Android

2019年はすごくAndroid出来る人が横に居たので、その人に甘えてAndroid以外のタスクに時間を割いた。大きな仕事はしていないが、minSdkVersionを21に上げた事で、リソースやスタイルまわりを整理した。

本業以外ではAndroid Live Coding Session という、ライブコーディングをメインにした勉強会を実施してみた。会社内外からゲストを迎えて、写真を共有するアプリをその都度ゲストの好みで実装していくという内容。

集客は少なめだったけど、参加者の熱量は高く、面白いイベントだったと思う。しかし年の後半から業務タスクが増えてきたこともあり、企画に割く時間が作れないまま自然消滅してしまった。

Rails

Androidよりも書いていたかもしれない。管理画面の使い勝手があまり良くないまま放置されていたので、小さなプロジェクト化してエンジニアやCS担当者が使いやすいように改善していった。このフィールドで検索したいとか、本番環境で実行してるコマンドをボタン1つで終わらせるとか、そういうやつ。放置されてた系のタスクは超簡単なのにめっちゃ便利になることがあったりして、やってて結構面白い。

Firebase

FirebaseはもともとFCMとAnalyticsくらいしか使っていなかったが、RemoteConfigやCloud Messaging、In App Messagingなどの導入を進めた。それまではリモート側の制御するものはちょっとしたものでも自前のAPIで何でもやってしまう事が多かった。しかしちょっとした変更の為にテストを回したりデプロイする必要があるのが嫌だったので、ユーザーごとのカスタマイズがそれほど細かくなく、変更の即時性が重要でないものはRemoteConfigなどに任せることにした。

Firebaseに限らず最初にツールを導入するのは心理的なハードルが高い。それに当初POから上がってきたRemoteConfigで出来そうなタスクの仕様は割と複雑で、それをFirebaseでやるのは気が重いというのもあった。

実際RemoteConfigの積極活用は最初はメンバー受けが悪かったが、Firebaseで出来る範囲で実現可能な事をまとめ、POや各部担当者に説明し、アプリ内の誘導バナーみたいなものは今はRemote Configで動いている。スケジューリングも出来るので、休日にデプロイする必要もない。しかし条件が複雑になると変更作業もその分複雑になるのでデメリットもある。ただ、リバートは簡単にできるので今のところ大きな問題は起きていない。

Feature Toggle / Trunk Based Development

4年前はエンジニアが6名しかないチームだったが、いまでは17名もいる。これまではアプリもサーバー側もgitflowベースのブランチ運用をしてきてとくに問題も無かったが、昨年くらいから数ヶ月に渡ってfeatureブランチが複数存在するようになり、conflictの手間が問題になり始めた。そこでFeature Toggle + Trunk Based Developmentの導入を提案した。

こう言うと自分が全部やったみたいな表現になってしまうが、実際には、アプリでフラグを設けて、デバッグ時だけ機能が有効になるようにしましょう、という提案をしただけで、あとは他のメンバーが良い感じで実装してくれた。フラグをリモートから操作するのも簡単だが、App Storeのレビューガイドラインではアウトなので、iOSではローカルのフラグをデバッグ画面で切り替えられるだけに留めている。

現在大きめの機能のtoggleを使いながらAPIのQAを進めようとしているところで、その際はgit flowではなく、Trunk Basedなブランチ運用を試しているところ。初めてのことなのでどうなるか判らないけど、多分大丈夫では?くらいの雰囲気。ここら辺の話は別途勉強会でまとめて発表予定。

転職の練習

これは2、3年くらいの周期でやっている活動なので、会社を本気で辞めたいと思っているわけではない。このくらいの周期で転職活動をしないと、自分は職務経歴書が更新できないので、しょうがなくやっている。あと面接の受け答えも久しぶりだと良い感じに回答できなかったりするので、定期的にやる必要がある。そしてもし良い条件のオファーがあったらそれは受けると思う。

ただ今回の転職活動で思ったのは、現状の待遇がかなり良い方らしいということ。途中から相手の顔が引きつってくることもあった。裁量労働や業務時間の扱いだったり、海外カンファレンス参加へのサポート、有給20日が自由に使える事など、総合的にはかなり現職の待遇は良いことを実感した。

またヨーロッパへの転職活動も試してみて、こちらは惨敗。一度エージェントとオンラインで面談したっきり、現状のスペックと希望年収で望みはなさそうだった。年収を抑え、フリーランスとして活動すれば風向きは変わったかもしれないが、現状ではそこまでの熱量で海外勤務したいわけではないので、もうちょっとちゃんと考えて努力を重ねる必要がある事を実感した。

これからのキャリアパス

こないだ久しぶりに学生から就職先を選ぶ参考にするため、これまでのキャリアについて聞かせて欲しいと言われたので、未経験からプログラミングを勉強し、これまでやってきた事、節目ごとに考えた事を紹介する機会があった。

人それぞれ色々考えてるのだろうが、自分の場合は都度面白そうな事をそれなりに真面目に勉強したり、本を読んだりすることはあるけど、基本的には行き当たりばったりで生きている。だがせっかくの機会なので、ちょっと申し訳ない気持のまま自分の経験についてなるべく誠実に話した。

会社選びの基準とかも聞かれたが、正直どこの会社行っても色んな人と知り合えるし、学校のクラス分けくらいの感覚しかない。学校と違うのは自分の意思で別のクラスに転職できることくらいか。合わなければ辞めれば良いし。だけどそういう感覚を持つようになったのは確かに最近のことで10年前はそんな事思ってなかったので、社会人経験を積んで考え方も変わったんだと思う。

再現性がありそうなポイントで言うと、ピークを越えて赤字転落した会社で働くのは辛い事が多いのでやめた方がいい。色々な制約が強くなり、選択肢も狭まる。優秀な人もどんどんいなくなる。その反面、よくわからない博打的な人事が発生したり、しまいには自分の仕事に全然集中できなくなるのでおすすめしない。

あと、基本的に他人は何の責任も取ってくれないので他人のアドバイスを頼りにしないで自分で考えて行動する事が大事だということ。出来る人は出来るし、出来ない人は出来ない。それはしょうがないことだ。