転職して7ヶ月が経とうとしているので振り返る

こんぬづは、休みの日は100%可処分時間であるという真理に気付いてしまった田中です。

今年の6月にクラスメソッド株式会社からピクシブ株式会社に転職をしました。

dev.classmethod.jp

tanakalivesinsendai.hatenablog.com

試用期間が終わったあたりで「転職してどうよ？」みたいなブログをまとめようと思っていたのですが、忙しい時期が続いてしまって今になっています。

割と整理されない感じで書いていくけど、だいたいこんなことをまとめていきます。

今どんな気持ち？
前職と比較するとどう変わった？
はじめての転職はどう？
会社の雰囲気はどう？
やったこと
悩みとかは？
これからなにやりたい？
さいごに

今どんな気持ち？

f:id:ktanaka117:20181230115401j:plain

楽しい。

そもそもの転職の動機が「to Cのサービスをやってみたかった」「身近なものを開発したかった」だったので、バッチリ叶えられています。

ものごとの優先度はひたすらに変わり続けているけれど、以前からやっている「ブログを書く」「イベントで登壇する」という活動はペースを落としながらも続けられているのでほっとしています。

あと、さらに百合にのめりこめました。

入社直後はSlackに「業務に直接関係ないチャンネル（いわゆる雑談など）は作成しないルール」が存在していたのですが、ルールが変わって雑談もできるようになりました。ということで百合チャンネルを速攻作ってもらって入りました。百合チャンネル、お待ちしています。

inside.pixiv.blog

前職と比較するとどう変わった？

受託開発とサービス開発

前職は受託開発をやっていて、割と単発のアプリ開発のお仕事が多かった。今はサービス開発に従事していて、続きものをメンテして機能開発してとコネコネしています。

継続していてユーザーを抱えているサービスの開発はめちゃくちゃ刺激的です。継続的デリバリーをするし、一つの場所であらゆるものが古くなっていきます。それにどう対処するかとか、適切に新しいものを取り入れていくバランス感覚はどうかとか。自分が持つエンジニア像としてはこういうことを考えるべきだし、考えてると強く楽しく生きていけるような気がしていて良い。

仕事のスタイルの違い、良し悪しが結構あると感じていて、受託だとこういうスタイルで働きやすくて、サービスだとこういう仕事に注力しやすいみたいな。このあたりはうまく言語化できないので、もうちょっとじっくりコトコト煮込んだらまとめます。🍛

趣味にお金を落としまくるようになった💸

周りにサブカルとか趣味に投資しまくっている人が多いので自然と自分もそうなっていっています。

漫画とか同人とかガジェットとか、お金回しているとフレッシュでいられる気がしてます。応援したい作家にお金を落とすのは非常に嬉しいです。

あとはお金の支出に対して、使える時間とのバランス考えなきゃなって思ってるるるる。

イラストを描くようになった🎨

イラストを投稿するサービスを運営する会社なので、「ドメイン理解！」と思って絵を描くようになりました。というかもともと好きだったからやり始めました。

まわりに実際に絵を描いてる人が多くて、かつ理解ある人々が多いので、自分を描く雰囲気に半強制的に置いておけるのが続ける動力になっています。

はじめての転職はどう？

忙しい時期と転職のタイミングをぶつけてはいけない

それはそう。

転職したてはカルチャーに馴染むために社員の人と積極的に絡むべきだし、絡みたいと思っている人間なのですが、忙しさからか、不幸にも黒塗りの高級車に追突してしまう。後輩をかばいすべての責任を負った三浦に対し、車の主、暴力団員谷岡に言い渡された示談の条件とは…

主に本書きと、社外イベントを詰め込んでいたために、今年は忙しかった...。弊社は業務時間後に各自が勝手に集まってさまざまな催しがあるのだけれど、そういうのが放つ放課後感とか部活感に浸っていくべきだったという反省。

忙しさが落ち着いたのが9, 10月ごろで、「仕事に関係しないところでもようやく最近馴染めてきたなぁ...！」と感じてホッとしてます。扱っている領域が領域なだけに、趣味で重なる人と集まれると、仕事でも楽しさや過ごしやすさが増します。

前職の経験が活きている

転職してみて、前職で学んだこととか取り組んできたこと、関わりのあった人から聞いたいくつかの言葉が指針になったりしていることがわかりました。

前職の社長が言っていたアレコレとか
「赤魔道士になるよりも、専門的に掘り進んでいった方が良いかもよ」とか
以前はこういう働き方で動けていたし、もっと自由に考えて動いても良いのかもなぁとか
「あー、そういえばあの人に出世するって言っちゃったなぁ。そういう動きも必要かもなぁ」とか

これらを意識して「こうしよう」で動いているわけではなくて、自分がこういう考えに合っているから、ふとしたときに思い出して、比較対象としての指針になっていることを思い出す感じになっている、のが良いことだなと思いました。

持ってて良かった！社外の友達、コミュニティ👬👫

色々悩みがあったり、疲れ切ってしまったとき無限に精神の支えになってくれた。

転職してこれが厳しい→「わかるー」とか
「今日は頑張ったぞ！」→「よっしゃ肉食いに行こうぜ！」とか
「疲れた...」→「うるせぇ！いいからこの尊い漫画・アニメ早く見て！！！」→「うん！尊い！！！！！🤤」とか

あと初めて遭遇するサービス開発の問題とか判断が相談できる相手が社外に居ると良い点として、具体的な説明は出来ないので、問題を一般化して整理していく過程を踏む必要があることがあると思った。一般化して話をするうちに、自分の中で問題を整理して言語化できるので、勝手に解決に向かう。

会社の雰囲気はどう？

わかり手🙌だらけ

「今期アニメのこのシーンが尊すぎて...」とか。「あの漫画のこのキャラのセリフがめちゃくちゃ好きで人生の支えになっていて...」とか。

アニメ漫画に限らないですが、あらゆるサブカルが前説ナシで通じてしまう。

沼だらけ

f:id:ktanaka117:20181230115744j:plain

こちらを歩けば沼にハマり、あちらを歩けばまた別の沼にハマる。特に金曜の定時後に同好の人々が集まって活動しだすのでヤバい。

以下は実際に発したことのある言葉なんですが、

「えっ！あのゲームをやってるんですか！今度一緒にやりましょうよ言葉です。！」
「えっ！お絵かきをする会があるんですか！iPad買ったので参加します！」
「えっ！Magic: The Gatheringやってるじゃないですか！昔やってたので対戦しましょう！」
「えっ！百合がお好きなんですか！これとこれが好きです！えっ、読んだことある！？良いですよね！！！！！」
etc...

同じタイミングで複数の催しが開催されているときもあるので、早く分身の術を身につけなければいけないと思ってます。

技術のレベルが高い💻

このサービスの開発にとって今必要な技術はどれかを考えるのに余念がないし、続いていくサービスをみんな受け持っているので、継続していくことも考慮にいれてどうかの判断をしていってる。

一人一人が専門性の高いスキルを持って取り組んでいる。トガった人が毎日のようにいろんな技術交換をするし、毎週の社内勉強会ではフロントとかバックエンドとかインフラとか問わずに発表しまくってる。「わからないということがわかった」「なぜそれが人にできるんだ？？？」みたいな発表がたくさんあって面白いです。

サービス開発のレベルが高い

限られたリソースの中でなにを優先して、将来的にはどうするか、手持ちでどうやりくりするか、今この判断はどうすべきか、サービスにとってどう？ユーザーにとってどう？開発者にとってどう？とか様々なもののバランス感覚とかが面白いです。もちろん受託開発とか問わずこのあたりは気にするのだけど、続いていくプロジェクトにおいてどう舵きりするかみんな考えていてつよい。自分にも求められることなので、できるところからやっていっている感じ。

やったこと

入社以来ずっとBOOTHというアプリのiOSエンジニアを担当しています。

ここで書いていくやったことは、「自分一人で全部やったぜ！ドヤァ！」ことではありません。レビューやタスク整理、ここに挙げる開発を自分がやっている間に、他のメンバーが一緒に取り組んでくれたからやれたことでした。このあたりも、サービス開発のバランスを感じることのできた良い体験でした。

設計改善👨‍🔧

今のところ、BOOTH iOSのアーキテクチャパターンはVIPERに寄せるようにしていっています。リリースから一年以上が経過したアプリで規模も大きくなっているため、なるべく細かく責務を分割したくてそうしています。

ただアプリの中のアーキテクチャパターンにも歴史があって、MVPっぽい部分とかMVVMっぽい部分とかが一緒に存在していたりします。幸いなことに、自分と、もう一人一緒に開発をしているパートナーの方は、どのアーキテクチャパターンも共通の理解をしているので、大きな問題にはなっていません。適宜必要になったタイミングでVIPERに寄せた書き方に直したりしています。

いろんなアーキテクチャパターンが一つのプロジェクトに混在している中で整理をつけていけるので、ただひたすらパターン勉強してきてよかったあぁぁぁ！仕事に活かせてるうぅぅぅ！って感じてます。勉強してきたことは価値があったんだと自信になりました。

Singleton撲滅👨‍🔧

↑ではアーキテクチャパターンの設計の話に触れてきましたが、データの持ち方とか同期方法の面の設計でも、見つけ次第メンテナンスしやすい作りに直していってます。

共有範囲の狭いデータをSingletonで管理してしまっていた実装箇所がありました。 Singletonは初期の開発において「ひとまずデータを管理しておける」という名目で使う場合もあるようですが、後からの機能実装でどこでデータが変更されるのか把握しにくい、アプリケーション内のどこからでもデータが取れる性質上、データの誤用を招く可能性があったので撲滅していきました。

フロー同期による限定的な箇所でのデータ同期と、VIPERの各役割に沿った責務ごとのデータ保持によって改善しました。

自動テストの追加👨‍✈️

プロジェクトに参入したばかりの頃は自動テストが全く無い状態（手動テストのみの状態）でした。ちょうど自分が自動テストに対する関心が高かったこともあったので積極的に取り組んでみました。もちろん「やりたいから」だけじゃなくて、必要だったので取り組みました。

入れやすいところ、これから触れていくところ、機能的に重要度の高いところから、設計改善とともに自動テストを追加していっています。

無料ダウンロード商品をダウンロードできるようにした👨‍💻

もともとiOSの機能開発はAndroidより少し遅れていました。これもAndroidではできていたけど、iOSでできていなかった機能のひとつです。

自分も欲しい機能だったので、対応できてよかったです。

有料ダウンロード商品を買えるようにした👨‍💻

入社してから一番インパクトのある機能実装です。ユーザーとしての自分もめっちゃくちゃに欲しかった機能なので、担当できて良かったです。

社内でも、業界でも知見がなかったところで理論立てて実装・説明できた自信のある部分です。カンファレンスなどでも記事が参照されたり、良い反響がもらえたのが嬉しかったです。

inside.pixiv.blog

API環境をランタイムで切り替えられるようにした👨‍💻

これ以前、デバッグやテストをするには毎回環境ごとのビルドをしなければいけなかったのだけれど、デバッグ用ビルドの中で複数の環境をランタイムでそのまま切り替えられるようにしたので、捗りました。

事前承認決済対応👨‍💻

一番最初の決済でユーザーから認可を得ることで、それ以降のPayPalやクレジットカードでの支払いを簡略化する機能です。もともとの支払いフローは毎度毎度Webを経由する必要があって、支払い完了までのステップ数が多かったところで、ステップ数を減らしてよりスムーズに支払いが行えるようにしました。

決済部分の実装は非常にセンシティブなため、PlantUMLでフローチャートやシーケンス図を書いて仕様の認識を合わせたり、それ以降もどんな仕様か振り返りやすくしましたり、工夫しました。

dev.classmethod.jp

iOS 9のサポート終了📱

機能開発に対してコストを集中するために、対応OSをアップデートする必要がありました。厳かに終了しました。

購入完了アニメーションを追加した👨‍💻

つい最近の実装です。これはドヤれる！

Lottieを使って購入完了のタイミングでアニメーションを追加して、購入体験をハレやかに演出してみました。

inside.pixiv.blog

実装時は「自分はUI実装が苦手な人間なんだな...ロジックが書きたい...」とひたすら感じていましたが、いざ出来ると、「出来上がって良かったー！最高のアニメーションだ！」という気持ちが湧き上がって嬉しかった。

UI実装のつらいところは、アプリを実行しないと確認ができないところでした。これを解決するためにPlayground駆動開発の導入を検討しましたが、Presentation Layerのみでモデル分割ができていない現状でワークしなかったので、涙を飲みながらぽちぽち頑張りました。

Playground駆動開発を前提にした設計・責務分良割というアイデアは、かなり筋が良さそうに感じたので機会があれば取り入れてみたいです。

medium.com

悩みとかは？🤔

負債との付き合い方

これは以前悩んでいたことで、今は割と解消されています。

長く続くサービスで規模の大きいものを体験するのは、割と初めてに近いものでした。（経験自体はあるけど、この長いスパンで携わることはこれまでなかった）

既存の設計にひきずられる部分が多分にあったり、かつては良かったが今では正しくない部分、部分的に機能していないコードが存在していたり、「これがいわゆる"負債"というものか！」を実体験しました。

「各所で絡み合うコードをどう改善しようか...」「設計を直すためには自動テストが欲しくて、でも自動テストを入れるには設計を直さなきゃいけなくて...」というよく聞く悩みを抱えました。社内外のエンジニアに色々相談して、実コードと対面することを数ヶ月続けた結果、「これはすぐに解決できる問題ではない。必要なところから徐々に解決させていく問題で、思い悩む必要はない。焦らずやれる範囲でYATTEIKI」というスタンスが良さそうだと気付けました。

この気付きは今後もエンジニアをやっていく上で結構大事なことっぽいと今は思ってます。

体力落ちた

流れる情報の速度についていくとか、周りで起きていることに「対応したいからする」って動きをするためには体力が必要。でも今年は体力を前借りしてその分最大HP値を削るような無理な動きをしまくってしまったので、改善していきたい。

可処分時間欲しい！

趣味や欲望が強くなってやりたいことが増えた。複数ゲームを掛け持ちたいし、絵を描いたり、本書いたり、etc... 毎日続けることで力をつけられることもあるし、仕事の範囲外でしたい挑戦ことが以前よりも増えた。

体力つけたら動ける時間が増えるというのと、別方面の解決を合わせて考えたい。

これからなにやりたい？

設計の話を展開したい👨‍🔧

設計本著者だし。書いただけで終わりでなくて、悩んでいる人がいれば答えられるようにしたり、一緒に悩んだり、身近で活かす必要があると思ってます。これは社内外問わず。

著者とは言ったけど、設計で大事なのは知識だけじゃなくて、共通理解や共通認識だったりするので、そもそも話をする場を作ることが大切そうと思ったりしてます。ぶっちゃけ自分の知識もたかがしれてますしおすし。

あと負債との付き合い方でわかったけど、設計を学ぶと環境に適応する力（パターンで認識する力）がつきそうだと思ったので、サービス開発する人にはさらに大事っぽそうだと感じたから。自分はいくつかのプロジェクトを通して学んできたけど、もっと効率よく身につける方法があったと思っています。たぶん誰かに相談しながらやっていくことが近道なので、受け口になりたい。自分の勉強にもなるし。