概要
以前 社会人10年になったので振り返る(ゲーム業界編) - Qiita が自分の記事の中で好評だったので
今回はその後半について書こうと思う。
生え抜き社員は転職に対するハードルを高く捉えがちで、結局今の環境を我慢して成長する機会を失っている子が多かったので、そんな無駄な時間を少しでも早く解消できるために、転職開始から退職までの泥臭い部分含め伝えられて、少しでも悩む人の後押しになればいいなと思います。
なぜ転職したのか？
子どもができたからです。そしてどうあがいてもお金が足りないし、その会社での働き方は自分ひとりでは良かったけど、家族となるととても健全なファミリーライフを送れる自信がなかったため。
転職活動〜入社初日
転職活動
転職エージェントに初めて依頼。ネットでエントリーっぽいの書いたら後日電話がかかってきて、面談ってなったけど、時間なかったのもあって電話での面談になった。
そこで自分の状況とか、今後どういったことがしたいか、どういったことはしたくないかを伝えた。
エントリーシート準備
証明写真を撮る必要があって近くの駅中で撮りたかったけど、会社が近くて知っている人にスーツ姿で出くわしたくなかったので、
私服で機械の前まで移動し、誰も周りにいないことを確認して証明写真の中に入り、中でスーツのジャケットとネクタイを着て撮った。
なので下半身はジーパンで上が白シャツ＋スーツ＋ネクタイとぶっ飛んだ格好で撮ってた。どうせ下は写らないし。
年齢の割にプログラム歴が長いのが刺さった
他業界／他スキルということもあり、書類審査で9割近く落ちる中、何が刺さったのか知らないけれど、トントン拍子で内定取れた
面接後に何が良かったのか聞いてみたら、年齢の割にプログラム歴が長いのが刺さってたみたい。
面接対策
面接する会社のHPや公開されてる情報に全部目を通し、質問事項などを手帳に書いた。
面接は久々すぎて少し緊張してた。話す内容、質問事項、会社への資料などを手帳に書いてた。
その手帳のことも面接開始と同時に予め伝えてそれを見ながら答えた。
面接
遅刻するといって、スーツ来て会社の面接に行ってた。
移動中が一番ドキドキした。スーツ来てるしとにかく出会わない時間帯に移動してた。
ネットでは辞めると分かった部下や辞めようとした部下には冷たくされるとか記事をみたので、
転職が確実に成功するまでは絶対にバレないようにしなきゃと必死だった。
面接後はいちど家に戻り私服に着替えて出社してた。
次の選考と採用
最初の面接して3時間後に次の選考のメールが来た。
数日後に役員5人と面接の日程だった。
面接時に聞いたけど、既に内定済みで話をしたいために呼ばれたようなものだったらしい
面接後にSPI試験受けたけど、一切なんの影響も受けていない。
なぜそこを選んだのか？
少なくとも子どもを養う責任があったので、安定が欲しかった。
大きめの会社っていうことで安定性もありそうだし、そこに決めた。
もう一つ内定もらっていたけど、外資系で東京支部できたてホヤホヤ過ぎて、一般人の生活を得られるか怪しかった
ブラック臭
ここまで読むとブラック乙ってくらい怪しいけど、今振り返ってみると、残業はあったけど前職の半分以下ぐらいで、休日出社は2回しかしてない。
応募する前にネットの評価を調べたら浮気／不倫が多いと書き込みされてて、嫁にそれを相談したら「平和やな」と言われたからそうなのかと思ってエントリー。
みなしはあったけど少なくて、残業代きちんと貰えて、残業しすぎると上司が人事から怒られて、上司が自分に話しかけてきて、残業解決に貢献していた。
しかし時がたつに連れ、人は異動し、文化は廃れ、私個人にとって色々とズレが生じ始めてた。。。
入社初日
同日入社が自分含めて3人、それぞれ違う職種と違う部署。
退職直前に調べたらまだ会社で働いてた。
自分の所属部署の上司が待機室に来るまで待機してたら、上司は外人だった
（大手はすげえなと思った。でも今思えば1社目もハーフだけど見た目バリバリ外人顔だったわ）
前職の退勤時間と10数時間ばかし異なるため、退勤時間になっても、帰っていいのか不安でそわそわしてた。
入社初日〜初めてのiOSアプリ
前職がWindows/C++しか触ったことない人間だったのに、部署内ではiOS/Android何でもござれのバリバリエンジニアとして天狗も青くなるほどの下駄を履かされてた。。。
配属時はWindowsPCが支給されてた。でも上司からAndroidとiOSどっちやってみたいと聞かれiOSって答えた。
AndroidはGalaxy無印を個人で持ってて、購入当初個人でチュートリアル弄ってイメージついていたのと、Macを触ってみたかったので。
その数日後に自宅用に生まれて初めてMacを買った。じゃないと絶対ついていけないと思ったから。
そう実はOS/言語/プラットフォーム全て完全未経験からスタート。
ひたすら読む、動く、試す
会社ではまだMacが支給されていなくて、何も指示がなかったけど、何も動かないのはまずいと思ったので、
個人iPhoneでAppStoreからアプリを落として、ブラウザ上でsvn管理のコード(objc)を見ながら、アプリを動かして動作確認してた。
で、バグっぽいのを見つけたらブラウザ上でコード見て担当PGに教えてた。
残りはAppleのドキュメントを眺めてた。
自分がObjCに触れたタイミングは丁度ObjC2.0が出たばかりぐらいだったと思う。（記憶曖昧）
前職でも自作参照カウンタに対してインクリメント／デクリメントしてたからMRCでも抵抗はなかったけど、
ARC出てラッキーだったと思う。
初めてのiOSアプリは実はほとんど開発せず、一通りリリースまで体験したら、新規アプリ開発チームに入った。
次はAndroidだった。
初めての新規Android
当時の最低動作保証バージョンは2.2だった。丁度JITが入って動作が多少快適になったあたりかな。
でも内部で保持するファイルサイズ制限がまだ厳しかった時。そして何より各国内メーカーがオリジナルのスマホを大量に出していた時代。
AndroidもJavaもEclipseも分からない状態だったので、また本買って勉強した。
この時のモチベーションは薬やってのかと思うほど高かった。
なので覚え直しになっても苦痛と感じず、好奇心のほうが勝って、知識の吸収速度も自分の能力を超えてた。
この時のアーキテクチャは、前職の神に過去に教えてもらった考えを参考に、レイヤー間を抽象化して疎結合にしてた。
だいぶ後になって後輩にも言われたけど、今思えばクリーンアーキテクチャに似てたかも。
アジャイル開発／新人教育／未経験言語／未経験プラットフォーム
開発スタイルはSMと一緒にアジャイル開発で初体験、OJTとして新人3人見て、未経験の言語やプラットフォームで新規アプリを作っていた。
色々と経験しながら作り上げていくのは、やはり業界は変わってもユーザーのことを考えながら作るクリエイトな部分は変わらずで、楽しかった。
でも少し違うのは、プロダクトバックログにはないストーリーに関連しないものは、例え効果があったとしても作ってもスケジュール外行動になるので評価に繋がりにくかった。
始めて新規iOSアプリ
企画側にiOS版を作りたいと言ったら意外とスムーズに話が進んで、
0からアプリを作るチームに入り。リーダー兼任でiOSをObjCで０からチマチマ作らせてもらった。
しかしテストも審査も通って公開する直前で、案件自体がクローズになって、お披露目せずに終わった・・・
ハードウェア連携アプリ
次は外部会社に依頼して作ったNFCによるハードウェア連携アプリを引き継いだ。
これはとてもいい経験だった。。。
ハードウェア連携の苦悩もあったけど、きちんと理解せずにDDDを導入しアンチパターンが組み込まれると、こんなにも読みにくいんだなと、引き継いだコード読んで思った。
ハードウェアのツラミ
またハードウェア有りきの苦悩としては、ハードウェアが必要最低限の機能のみだったこと。
何かうまくいかなかったり問い合わせがあったときに、ハードウェアが故障しているのか、ミドルウェアがバグがあるのか、スマホのSDKが悪いのか、スマホのプロダクトコードが悪いのか特定がかなり困難だった。
また、スマホ側もNFCのマークと実際の位置がズレてるメーカーもあったり、とある国外メーカーでは、反応すらしないものもあった。
もっとハードウェア／ミドルウェアのテスト動作をソフトウェア側が自由に動かせたり、ハードウェア故障していないか動作チェックをソフトウェア側が確認できるようになっていれば、問題特定がだいぶ違っていたと思う。
iOS版はBLE
iOS版も同様に引き継いだ。ハードウェアとの通信手段はNFCはまだなかったので、BLEを使った。
Android版もBLEの話が出たけど、ただまだ国内でBLE対応機種が出回っておらず、メーカー側も準備できていない状態だったので、どうしようもなかった。
苦労とかそんなことをせずにどうしようもなかった。
iOS版のソースコードはアンチパターンもなくiOS王道パターンで作られていたので、理解しやすかった。結局はお上があるプラットフォームは、素直に従った作りにしたほうが将来的に安定だなと思うようになる。
CocoaPodsの洗礼
あ、一個困ったこととして、CocoaPodsを使われてて、Podfile.lock がコミットされていないこともあり、$ pod install するとCocoaPods のバージョンを上げるようエラーが出て、
バージョンをあげようものなら、ライブラリ側のバージョンも上げるようにエラーが出たり、ライブラリ側がCocoaPodsからダウンロードできなくなってしまっていたりして、再現ができなくて緊急修正版のときに青ざめた記憶があった。
結局同じメンバーの人が、普段からコードやリソースなどのプロダクトデータをマニュアルアーカイブ(zip)してローカルに保存してたことで運良く免れた。
それを気に暫くの間、 CocoaPods は避けるようにしてた。今振り返ってみると、多分使い方を間違えていたんじゃないかなーって思ったりもしてる。
プレイングリーダー掛け持ちはすべきで無い
プレイングリーダーという用語が一般用語か分からないけど、意味は自分でもコードを書きながらメンバーの面倒やチーム運用を行う役割で、チーム内の細かい事情を把握してる必要がある立ち位置だと思っていただければ。
その役割を自分が2つ掛け持つ話が出てしまい、上司からは出来るよと言われてやってみた。結果としては、やるべきではないと確信している。誰一人として得をしない。
上司も結局はスケジュールがうまく進んでいないことになるし、各チーム内メンバーもリーダーに不信感を抱くし、リーダーもヘロヘロになるだけで、一切いいことなどない。
結局は掛け持ちをやめて、一つに絞った。
初のXamarin案件
一つに絞った案件が、Xamarin でクロスプラットフォーム開発でiOS/Androidを開発してた。当時はまだXamarinではなくMono なんとかって呼ばれてた。
このとき始めて C# 4系を触った. 前職の研修時は C# 2系 だった気がする。
その案件自体では、関わったバージョンを最後に自社開発が終わり、新しい案件としてアサインされた。
新しい案件は何を使うか？
次案件もクロスプラットフォームの話が出ていた。企画側としては Xamarin の細かい所に不信感を抱いており、自分の所に検証をしてから決めてほしいと言われた。
そもそもその当時に抱かれていた不信感とは
- クラッシュしてもトランスパイルしてるからスタックトレース意味わかめで、問い合わせなどの障害対応が出来ないケースが多い。
- iOSのバージョンアップ追従が遅く、しかもXamarin用にラッピングされたライブラリはさらにそこから加えて時間がかかるので、新OSバージョンが動かなかったや見た目が壊れている場合などあっても、ネイティブと比べXamarinもXamarinライブラリもバージョン対応が終わるまでプロダクトのバージョンアップ作業が出来ないことに苛立っていた。（個人としてはライブラリの追従は確かに遅いが、XamarinのiOS追従はまだマシだと思う）
- GoogleAnalyticsやAdMobなどメジャーなライブラリはXamarinで使えることが多かったが、国内が公開しているサービスのSDKなどはXamarin版はなくて、結局Xamarinが理由で見送ることもあった（サービス会社に自作ラッピングしていいか聞いても断られた）
そんなこんなで調査することになったが、
- 上司がMicrosoft推し
- 自分がObjective-Cはもういいやと感じていた
- 自分が考えていた設計方法ならXamarinのメリットであるロジカルコード集約できて2つ目プラットフォーム開発時は開発工数が減らせると踏んでいた
- 開発者不足でサーバーサイドは.NETだったのもあり、C#経験者を増やすことでリソース不足をなくせそうと考えてた
こともあって、調査と見積もりして、ギリギリXamarinになった。
もしSwift使っていいならSwift/Androidで開発したかったんだけど、メンバーから出たばかりまだ怖いから止めてくれと止められたので結局対象から外した。
Xamarinの長所
ロジカルコードを1回で済ませられることではない。C#のLINQとasync/awaitが使えること。これに尽きる。
ロジカルコードを1回で済ませようとするとPCLとしてライブラリするなど、プラットフォーム依存ライブラリは全て排除せねばならず、コード書いてるときはロジカルコードを書いていないか常に意識する必要があった。
これに慣れていない若いメンバーなどが入ると、途端にロジカルコードが散らばりカオス化する。
結局はコードレビューの品質をあげるなど開発手法が縛られるし、JavaやObjCと比べコード量を抑えられるメリットも薄れてしまう。
それよりも印象に残ってるのは、C#のLINQによるデータ操作は楽しく、とasync/awaiｔによるスレッド操作が楽だった。
アーキテクチャは模索(オレオレ)
アーキテクチャもWeb寄りのアーキテクチャではオーバーデザインになりやすく、どうも違和感を感じていた。
なのでネットのモバイル系記事をあさりまくって、自分なりに説明が出来る構成にした。
構成を実装に落とすのは、ひたすらコードを書き続ける作業で、案件開始直後は夜遅くまでひたすらアーキテクチャ関連のコードを書いて、メンバーにはそれを使ってプロダクト系コードを書いてもらっていた。
その後、メンバーが増加する前までに開発体制、環境、ガイドライン、アーキテクチャを全て整え、メンバーに説明して、自由に動けるようにしておかしいと思ったらメンバーから発言し、チーム内で議論して決定してた。
失敗したら全部責任は自分が持つから好きにやるように伝え、自分はどちらかというとプロダクトに合わせられないアーキテクチャのメンテナンスのタスクが多かった。
当時の初期メンバーや途中参加メンバー含め、この案件がここ最近で一番楽しかったと言ってくれたので嬉しかったのを覚えてる。
Webアプリ初参加
上の案件のAndroid版に入る前にWeb開発チームに参画した。
人手が足りないということと、自分がWeb側も覚えたいということもあったため。
開発者20+名くらいと、この会社で自分が参加した案件では一番デカかった案件だった。
メンバーは全員社外の人だったけど、凄いいい人ばかりだったので、嬉しかった。人格が整っている人間と何か一緒に作るのは、余計な干渉を気にしなくていいので、凄く楽しい。
人手が足りないということもあり、なかなか忙しかったけど、前の会社に比べれば楽だった。
自チームは平和だったが、他チームで人格が適さない人は、ポツポツと案件からいなくなってた。きっと妖怪の仕業だ。
アーキテクチャ改善チーム
自チームが抱えている担当範囲以外の懸念点や改善点をプロジェクトリーダーに訴えまくっていたら、案件が一旦収束後にアーキテクチャ全体を適正に使っているか管理かつアーキテクチャを改善するチームにアサインされた。
つまり、一部チームのリーダーとしてアサイン後、ひたすらポジティブに動き担当範囲外も手を広げてバグを未然に防いでいたら、案件のアーキテクチャを支えるチームのリーダーになっていた。
当然ながらWeb開発に入ってまだそんなに立っていないので技術が卓越してたわけではないので、社外の出来る人2人と一緒に立ち回っていた。
この二人と一緒に仕事できたのは今でも楽しい経験となっている。本当に良い人達でした。
仕事の出来るいい人は貴重
開発でいい人たちに出会う機会って実は凄く少ないので、もし巡り合えたらチャンスだと思ってどんどん仲良くなって、色々学ぶことを推奨します。
技術・人格・解決力など盗めるものは盗んだほうがいいです。年上の人でしたら子どもが高校生だったり大学生だったりすることもあるので、エンジニアとしてどう生きてきたのかを教えてもらえるのはとても貴重です。
子どもが入院
ちなみにこの頃に子どもが重い病気にかかり長い入院をすることになり色々とライフワークとは何か考えるようになった。
やるぞ！って思ったら異動
このチームでは、重要機能の設計とテスト品質の向上について動いていて、テスト設計があまりにもひどく全作り直しが避けられないレベルだったので、作り直しのロードマップを作って提出・説明し、許可がおりてよし動くぞ！ってときに別チームに異動になりました・・・。
甘く見られすぎな管理ツール統合チーム
- 企画
- 新人1年目
- エンジニア
- 自分
- 新人1年目
- 案件
- 部署が抱える管理ツールの全統合チームの引継
- 兼社外委託への環境作り
- 兼新人教育
- ツールはCSとサービス運用で利用する
なかなか管理ツールを舐めたチーム構成だと感じました。
アーキテクチャのほうもこれまたクセが強く、フレームワークを使わないSPAでした。
話端折りますがCSのコストを大幅削減できる案をだして許可がおりて、よしやるぞ！ってときに、次チームに異動になりました・・・。
新人教育のほうは結果論だけ書くと、企画の子は駒ではなく自律できるように叩き上げ、エンジニアは一人でアジャイルを回せてチームメンバーを指揮できて、一人で動けるようになるまで、つまりリーダーとしてスーパー叩き上げしました。
これは私の成果というより、本人の資質があってこそだと思います。
そのリーダーとして叩き上げた理由というのが、この時既に私が転職活動を開始して、メンバーにもそのことを伝えていたためです。
次チームでは認証関係のチームでしたが、その後辞めたのであまり内容はないです。
オフショアとの連携注意事項
この会社では、オフショア先として中国の人達と仕事することが多く、自分もWeb開発中はよく接していました。
みなさんとてもいい人たちです。ですが文化の違いなどで色々とうまくいかないケースも多いと思います。
自分が見てきた中で確実だなって思ったのは 「一度来日してもらいしばらく一緒に仕事する」 これが確実だと思いました。
なんだかんだありましたが
振り返ると、会社としても福利厚生がしっかりしているし、社員サポートもありました。クラブ活動もかなり盛んでした。
そして私にとって色々ととても成長できるいい会社でした。
唯一の心残りは、自分を採用してくれた二人が私より先にこの会社を去ったため、こんな得体の知れないスキルの自分を採用してくれた恩返しができなかったことです。
そして次の会社へ
なぜ転職したのか、なぜそこにしたのか。
10年以上も仕事をしていれば、価値観も環境も変わりますし変えざる得ない状況にも出くわします。
ここから先は、Qiitaのノウハウとは趣向が変わるので、気になる方はWantedlyの ここ に書いてるのでどうぞ。