hokkun blog

技術の話をメインに、たまに糖質制限の話とか色々したい予定。

新卒から６年半ソフトウェアエンジニアとして働いた会社を退職します

タイトルの通りです。しばらく長い文章を書いてなかったのでここまでのキャリアの振り返りでも書いてみよう。

就活

2014年冬から2015年春にかけて就活の時期だった。

当時の就活の資料を見てみると(Evernote に几帳面にしっかり残していた;今は Notion に移行したが)、企業を選ぶ基準としてこんな事を言っている。

問題解決を行う上でできるだけユーザの目線に立ちユーザの課題ベースでテクノロジーを駆使することを大事にしている企業

当時の自分は BtoC のテック企業を中心に応募をしていた。そういう意味では、技術はユーザのために使ってなんぼである、という考えは今も変わらないなと思う。現職もとい前職は当時すでに国内ユーザ数がかなりのところまで来ており、そういう意味では最高の選択のひとつだった。

当時はすべて合わせて８社にエントリーして４社から内定をもらっていた。すごい。

うち２社は外資系で、ソフトウェアエンジニアとしての採用ではなかったのでやめた。エントリー自体は勉強がてらしたが、やはりキャリアの最初はものづくりでスタートすべきだと考えたというところが大きい。

残る２社の中でこの会社を選んだ理由はいくつかあるが、成長度の傾きが急峻な方を選んだ、というのは一つ大きい。もう一つの内定先はある事業で当時安定した利益があり比較的運用フェーズのような感じに大学生の自分には映っており、どうせ数年で移り変わる業界に行くなら今はこっちだろう、ということである。まあ当然民間企業である以上利益を求める必要があり運用フェーズだけの会社なんてないことは後々気づくのだが、まあそれはそれで。

まああとは普通に待遇とかもあったけど、この辺は生々しいので飲み会とかで。。

研修

2016年春に新卒として入社した私を待っていたのは様々な研修であった。当時の新卒は全職種合わせて 30-40 人程度で割と仲のいい同期だったと思う（今も職種問わず交流がある）。

最初は全職種共通でビジネスマナーなんかを学んだあと、ハッカソン演習、そしてエンジニアだけの研修と進んだ。

テーマは「メッセージングアプリの実装」。当時は開発系のエンジニア同期は 10 人に満たなかったので、2 チームに分かれて演習が進められた。今とは少し趣が異なるが、HTTP 利用禁止で、TCP の上に独自のプロトコルを実装するという面白い制約があった。

当時の hokkun は R&D っぽい開発しかやっていないうえチーム開発も初めてだったので pull request なにそれおいしいの状態であった上、ウェブ開発やクライアントアプリの開発もほとんど素人だったのでここは非常に苦労した覚えがある。今でこそソフトウェアエンジニアで新卒入社を目指す大学生はみんなウェブ開発のアルバイトやインターンシップを経験している（イメージがある）が、当時は 2022 年の状況ほどではなかった（はず）。サーバ側の MVC/MVP といったアーキテクチャパターンやクライアントアプリの UI スレッドとその他のスレッドがイベントでやり取りするようなパターンなどなどなどのウェッブ技術は、main 関数にダ〜〜っと実験のコードが書かれているプログラムしか読み書きしていなかった私には青天の霹靂といった様相だった。周りの同期がとてもできてあまりに辛かったので当時人事に半泣きで相談に行ったのを覚えている（マジ）。

とはいえ、優秀な同期が設計をだいぶやってくれたので、それに従ってコードを書いていく作業自体は共同開発感があってとても楽しかった。

この研修でソフトウェアエンジニアといえども莫大な勉強しなければならない領域が広がっていることをよく知ることができた。下記は一年目の私が書き始めてすこーしずつ書き加えていた記事だが、序文から当時の辛さをうかがい知ることができる。

qiita.com

最初の三年半 - ゲームプラットフォーム

入社研修を終え、最初に配属されたのはゲームのプラットフォームを開発する部署である。ゲームと言うと Unity とかセッションサーバとか特殊な技術が必要な感じがするが、あくまで「プラットフォーム」なので、ゲームに必要な周辺機能を提供する、というところが正確なところか（最近では GBaaS*1 や MBaaS *2 という表現もある）。 なので、ここでは標準的なウェブ開発の一通りを体験したと思う。

この部署は比較的海外のメンバーが多いのもあってか、全社的な技術スタックから少しずれていたりしたのも面白かった。メインの DB には HBase が原則として使われており、メタ情報は Mongo をラップした独自のアプリにキャッシュしていたり(この辺は同僚のこの記事 に詳しい。)と少し癖のある感じだった。逆に RDBMS はあんまり利用していなかったので SQL をギョームで全然書いていなかったのはちょっと惜しい。

コミュニケーションとしては非常に面白いチームだった。日本のチームだけでも割と毎日のようにランチへでかけていたし、コロナ前から数拠点でのビデオ会議は当たり前で、出張も多くあった。外国への出張では現地の同僚に大量のお酒を飲まされでもてなされ、何度千鳥足になったことか・・。とはいえコロナ禍を迎えて久しい今思い返すと、あれがあったからこそ離れていてもいわゆる仕事の調整的な部分がうまく回っていたんだろう。今でもプライベートで当時のチームのメンバーとはやり取りをしているし、社会人としてのいろいろを学んだ。

在籍後半はリードとしての振る舞いも求められ、会議のファシリテーションやモックアップの作成など幅広い業務を体験できたのは今思うと幸運だったかもしれない。

当時の私の仕事は以下のテックカンファレンスでの発表資料などで垣間見ることができる。

www.slideshare.net

www.slideshare.net

最後の三年 - Data Management Platform

2019 年の秋に DMP の開発チームに異動した。社内異動が比較的に自由にできるようになる制度が始まっていたので、スムーズに異動できた。DMP とは Data Management Platform の略で、広告を始めとする BtoB 向けサービスにおけるデータの利活用を行う機能の集合体、的な存在である。

いわゆるクリックやコンバージョンの計測に関するパイプラインや、カスタムオーディエンスと言われるターゲティングのための機能開発を行っていた。データドリブンな仕事なのでウェブの API や画面を開発するというよりは Kafka のコンシューマをゴリゴリ書いてつないでいく、というような仕事がメインだった。

この部署では比較的全社共通スタックを用いていて、MySQL/Redis を中心に大きなデータは HBase を併用していた。また、前述の通りデータパイプライン的な側面の強いコンポーネントの集合なので、Kafka はヘビーに使っていた。しかし、会社に専門の Kafka 運用をやっているチームがいたので割と安心して気軽に使えたという側面は大きい (この辺は この記事 が面白いだろう)。

このチームでの面白さとしてはやはり、数分でも止めれば大きな利益損失につながるなどちょっとしたミスが大きな事故につながる可能性がある緊迫感を体験できたということが挙げられる。なので比較的あらゆる変更を本番にデプロイする際はできるだけ安全サイドに倒していく試みを少しずつ取り入れていった。CI/CD 周りは改善点も大きかったため、自分の在籍時には少しずつ潰すような改善を取り入れていった。長期的に発露する問題も多く、アラートの対応周りもある程度システマティックに対応できるような仕組みを構築するようにしていた（今別の同僚によってさらに進化もとい深化をしているところだ）。

もう一点、法律や業界の動向について常にアンテナを貼っておく必要があったのも面白かった。個人情報保護法は最近大きな改正があった*3し、Apple の ITP や Google の Privacy Sandbox など、広告や B2B プロダクト周りはエンジニアが追っておくべき方面が（技術以外にも）とても多い。

詳しくは、以前採用イベントで話した資料をおいておく。

logmi.jp

転職活動

2022 年に入ってから少しずつ社会勉強がてら転職活動を始めた。

今の会社をやめるぞ！という意思があったわけではなく、文字通り経験のためというところが大きかった。なので、ヘッドハンターに連絡をしてみたり、いろんな転職サイトに片っ端から登録してみたりした。最初の就職活動時の BtoC をやるぞ！という夢がなぜか最初の会社では叶わなかった（もちろん自分の選択によるところも大きいのだが）ので、事業会社かつ toC のサービスを展開している会社を中心にアプライした。事業のドメインも非常に重要で、自分がユーザ目線であんまり興味ないサービスを開発していると割とすぐ飽きるというのは経験として感じていた。

また、ソフトウェアエンジニアリング一本では飽きそう＆より上のレベルの人たちに勝てないと思った*4ので、機械学習をやっている会社の話を聞いたり、ソリューションアーキテクトと呼ばれるようなお客さん相手にシステム設計のお手伝いをするような役職の話を聞いたりもしていた。とはいえ、まだ若い（はずな）ので一旦はまだコードを書く仕事をしたい、サービスを作りたいと思い、プロダクトコードを書くソフトウェアエンジニアの仕事を続ける方針で探した。また、コミュニケーションの不自由さをなくしたいという気持ちとエンジニアリング以外でなにか尖ったのものがほしいという気持ちもあり、グローバルな職場を求めて英語環境の会社５つにエントリーした。実際は外資系（かそれに近い環境）かつアプリのバックエンドエンジニア職となると、あまり選択肢がなかったというのが正直なところである。

いわゆる外資テック系の面接の準備は一通りやった。中でもこのサイトにはかなりお世話になった。

www.techinterviewhandbook.org

以下は箇条書きでインタビューの感想。

  • コーディング試験対策は自分では結構やったつもりだったが、やはりまだまだ LeetCode の Middle を割とスラスラ解けないと厳しいかな、というのが率直なところ。アルゴリズムの勉強はもっと早めにやっても良かった。
  • コーディング試験でも結局 naive な solution から英語でコミュニケーションを取りながら optimize する能力を求められているので、そこも英語力は割といるなと思った。よって次機会があれば mock interview を必ず受けようと思っている。 こんなサイトやこんなサイトがある。
  • 大学生の就活活動と違って平日は仕事があるので、割と何社も受けてると普通にきつい。本当に行きたい会社数社に絞ったほうがいいかも。
  • 久々に基本的なデータ構造とかアルゴリズムをガッツリ復習してると、ギョームの時も前より時間計算量や空間計算量に気をつけるようになったのでいい影響があった（気がする）。
  • 大手外資系やメガベンチャーをメインで受けていくなら基本的には（少なくとも日本の）ヘッドハンターにお願いするのは不要かなと思った。自分の知らない会社を知る、とかなら意味がありそう。
  • どこいってもいわゆる behavioral interview がある。過去の経験を英語で simple かつ effective に話す必要があるので、事前準備は必須。いわゆる STAR メソッド*5で整理しておくと良い。この辺 Amazon の採用サイトの情報量がすごいのでぜひ読んでほしい。

www.amazon.jobs

あとこんな感じで色々諸々整理したりしてた。えらい。

最後に

ということで、欲しい物リストです。

www.amazon.jp

*1:Game Back-end as a Service

*2:Mobile Back-end as a Service

*3:https://www.ppc.go.jp/news/kaiseihou_feature/

*4:この辺の話もなんか込み入ってくるので飲み会とかで...

*5:Situation, task, action, result - Wikipedia

数学図鑑〜やりなおしの高校数学〜 補章&すべての感想

数学図鑑〜やりなおしの高校数学〜 第一章・第二章 - hokkun blog

数学図鑑〜やりなおしの高校数学〜 第三章・第四章 - hokkun blog

数学図鑑〜やりなおしの高校数学〜 第五章・第六章 - hokkun blog

これらに引き続いて最後のポストになります。

補章 - 複素数平面（数III）

複素数そのものは僕も高校生の時に習ってるんですが、複素数平面・極形式は最近の学習指導要領の変更で入った（正確には「また」入った）分野ですね。一応電気系出身なので述べておくと、回路解析などには必ず必要な知識になります。複素数平面のところでは回転移動が掛け算で表せるというところ重要なポイントになります。演習問題の京大の問題はちょっと自分には難しすぎた。。

さて、3/1 に目標から1日遅れでなんとか解き切りました。何度か言及したように、平面図形に関連する単元を始めとして省かれている単元も存在しますが、自分の目的（＝機械学習の理論の部分へ再入門する）を考えると最低限である解析の基礎、確率・統計の基礎、線形代数の基礎このあたりを復習できたのでよかったかなと思います。まあ、網羅的に学びたい場合同じ著者の

ふたたびの高校数学

ふたたびの高校数学

をおすすめします。

一点だけ、最初のレビューでも書きましたが、挙げられている例・例題が少しわかりにくいものが多かったかなあと思いました。対象読者が社会人〜であることからか、少し実践的な題材を取り上げているのかなあとも思いますが（例えば対数関数の演習問題になっているガラスの反射率の問題など）、もう少し数学的な本質だけの理解で解ける問題がいいなあと思った。まあここは好き嫌い分かれそう。

さて、今度これを買ったので今月末目標で読み切りたいです。

人工知能プログラミングのための数学がわかる本

人工知能プログラミングのための数学がわかる本

数学図鑑〜やりなおしの高校数学〜 第五章・第六章

数学 機械学習

さて、調子が良いので連日の更新。今日は数B・旧数Cでならう数列、ベクトル、行列について。

前回の記事はこちら↓ hokkun-dayo.hatenablog.com hokkun-dayo.hatenablog.com

本はこちら↓

数学図鑑: やりなおしの高校数学

数学図鑑: やりなおしの高校数学

第五章 - 数列（数Ｂ)

いろんな数列→公式の暗記ゲーという印象を受けちゃう、けどしかし、シグマ記号初めとしてこれも大学以降の数学のド基礎になる単元というイメージ。また、数学的帰納法も証明の手法の基本中の基本なのでしっかり抑えたい。今回の目的を考えると、二項間漸化式・三項間漸化式の解法なんかは理解さえしてれば十分だろう。

第六章 - ベクトル（数Ｂ）＆行列（旧数Ｃ）

  • 6.1 ベクトルの基礎
  • 6.2 ベクトルの加法と減法
  • 6.3 ベクトルの内積と外積
  • 6.4 位置ベクトル
  • 6.5 ベクトル方程式
  • 6.6 行列の基礎と演算
  • 6.7 行列と方程式
  • 6.8 １次変換

思った以上に忘れていた。。画像処理・機械学習を抑えるために最も関係のある単元なのに。。ベクトルという言葉は実は多義的で(ベクトル - Wikipedia)、高校で習うベクトルは特に断らない限り空間ベクトルのことである。ベクトル方程式なんかは久々に見てほ〜と唸ってしまった。

ところで、各単元のことを思い出すにあたって、以下のサイトを参考にさせてもらった。

examist.jp

こちらの、平面図形に関する部分が面白い。

通常、図形問題の解法は大きく次に分類される。 1. 幾何的に解く（数A平面図形） 2. 三角比・三角関数で解く（数I三角比、数Ⅱ三角関数） 3. ベクトルで解く（数Bベクトル） 4. 座標平面で解く（数Ⅱ図形と方程式） 5. 複素数平面で解く（数Ⅲ複素数平面） どの解法も一長一短で、それぞれにメリット・デメリットが存在する。

なるほどー。確かにいろいろな解き方がある。5番なんかは我々の頃は学習要領の範囲外であったが。

行列については簡単な扱いだった。まあ積の計算とかできればいいのか。あとは固有値・固有ベクトル。

数学図鑑〜やりなおしの高校数学〜 第三章・第四章

数学 機械学習

さて、今日は数学図鑑の第三章・第四章について。実は先日、すでに　補章（複素数平面）まで含めて一周し終わったところだが、記憶を掘り起こしながらメモ。 前回の記事はこちら↓ hokkun-dayo.hatenablog.com

本はこちら↓

数学図鑑: やりなおしの高校数学

数学図鑑: やりなおしの高校数学

第三章 - 関数（数I 、数II）

  • 3.1 関数の基礎
  • 3.2 ２次関数
  • 3.3 三角関数
  • 3.4 指数関数
  • 3.5 対数関数

何やるにしても基本になる一変数関数の様々な形についての章。高校数学をすべてさらおうと思うと、ここはかなりのボリュームになりそうだが、この本はかなりコンパクトにまとまっていた印象。三角関数の周辺には様々な公式があるが、これについてはまあ完璧に覚えてなくても単位円からなんとなく導出できればよさそうだ。まあ、そうでなくても定理の証明を追える程度で一旦は満足しておくことにする（ほんとはだめそうだが。。例えば加法定理の厳密な証明は東大での出題が過去にあって難しい）。

第四章 - 微分・積分（数II、数III）

これから進んでいく予定の解析学の基礎を成すセクション。しかしこの分野、原理をなんとなく理解していても、実際の出題に歯が立たないことが多い気がする。自分が高校生の時もそう思った気がする。例えば、本書の中でも出題のある平均値の定理を使う問題は、「平均値の定理を使う」ということにさえ気づけばかなりスムーズに解法が見えるものの、それに気づくまでが慣れを要する。また、不定積分などは天下り的に使う「テクニック」的な部分も多くて苦手だったのをよく覚えている。しかしそれらの中でも、

あたりは基本としてすっと出てくるようにしておきたい。

さて、この後は数列、ベクトル、行列と数B・旧数Cへと進むわけだが、お気付きの通り、数Ⅱあたりの図形と方程式等幾何は大きく省かれている印象。また、多項定理、部分分数分解や相加平均・相乗平均などを扱う章もない。高校数学を趣味として学びたい人にとってはこのあたりの内容は面白いと思うので、もう少し網羅的な本でやったほうがいいかもしれない。

Flask の logger が日本語を正しく表示しないのでハマった

表題の通り。Qiita に書こうと思ったが、もしかしたらしょーもないことなのかもしれないのでブログにします。

今 Flask でちょっとした Web アプリを書いているんだけど、Python 3 になっても Python のマルチバイト文字の扱いにハマってしまった。 デバッグでログを吐いている部分で、日本語が正しくファイルに出力されていないことに気づいた。

...
# 正しく表示される 
current_app.logger.info("This is not a Japanese message.") 
# 何も表示されない！
current_app.logger.info("これは日本語です")
...

Flask の logger は要は Python 標準のloggingライブラリを使うので、loggingのドキュメントを見てみる→16.8. logging.handlers — Logging handlers — Python 3.6.4 documentation

FileHandlerは、ファイルを開くときにエンコードを指定するようになっていることが分かる。単にビルトイン関数のopen()を呼ぶ。open()のドキュメントを読むと、

encoding is the name of the encoding used to decode or encode the file. This should only be used in text mode. The default encoding is platform dependent (whatever locale.getpreferredencoding() returns), but any text encoding supported by Python can be used. See the codecs module for the list of supported encodings.

とある。利用しているサーバで local.getprefferedencoding()を実行すると・・あれ？UTF-8が帰ってくる。。

しかし、一応FileHandlerのコンストラクタにencoding='utf-8'を追加すると、、動いた・・なぜ・・。

とりあえず、FileHandler を利用する際はencoding='utf-8'を指定しようと思います。理由がわかったら追記します（誰かおしえて）