seri::diary

日常

今回の転職活動の雑感

はじめに

2021年10月から2022年2月にかけて転職活動をしていた.

今回の転職ではいつもと違い10社近くのカジュアル面談を受け6社に応募した. また,珍しく採用に関するwebサービスを使用したり,初めてCoding test対策を行ったりもした.その雑感をまとめておく.

転職活動の結果

10社ぐらいカジュアル面談という形でお話を聞かせていただき,6社選考に進んで4社からオファーをいただいた.

どれもいいポジションだったので非常に悩んだのだが,以下の2軸に基づいて判断した.

  • 今後5年後ぐらいに自分がなっていたい姿から逆算して最適なポジションであるかどうか
  • オファー内容のポジションに納得できるかどうか

転職活動中に関わったみなさまにはお礼申し上げます.

希望したポジション

今回自分は以下のようなポジションを探していた.

  • Softwareでのビジネスをメインとしている企業での勤務
  • ICとして主にBackendに関わる
  • People managementは入社後も行わない
  • 大規模なBackendシステムに関われる
  • 大量ユーザ,データ,トラフィックのいずれかの要素を持つサービスに関われる
  • Microservice architectureを採用しているもしくは移行の予定がある

キャリアパスとして今後5年間はICでいたかった.5年という期間に深い意味はないが,単純に今やりたいことと技術的に伸ばしたいことを全てやり終えるには少なくとも5年間は必要だろうという見積だったのでそのように区切った*1.その後はもしかしたらPeople managementをしているかも知れないし,Backend以外の分野で引き続きICとして働き続けるかも知れない.その時になったらその時点の状況を考慮して考えればいいと思っている.

いずれにせよ「入社したら5年間はこいつに何らかのManagement roleではなくICをやらせておいても良い」と判断してくれる企業を求めていた.そのため「最初はICでもいいが,いずれは必ずPeople managementを伴うEngineering managerへの転向を求める」という方針の企業は一切選考に進まなかった.

転職のために使用した採用媒体

いつもは採用媒体は使わず直接応募するのだが,今回は広く可能性を探ってみようと思い転職ドラフトYOUTRUST を使ってみた.

ただ,結論から言うと結果的にはこれらのサービスで得たオファーはすべて辞退してしまい,結局いつものように直接応募した企業からもらったオファーにサインする結果となった.とはいえ,せっかくなのでそれぞれのサービスを使ってみた感想を以下にまとめてみる.

転職ドラフト

感想としては一番最初のカジュアル面談の段階で企業側と報酬の話ができるのがとても良かった.

転職活動ではある程度選考が進んでから条件面の話をするのが日本だと一般的だと思うのだが,過去に最終面接直前で条件面のミスマッチが発覚したことが何度かあった.そういう経緯もあって,今回は最初から条件面を合意した上で選考に進められる転職ドラフトを使ってみたのだが,これが思った以上に良かった.選考に進むかどうかの判断をする上でも条件面は重要なのでその点を最初にクリアにできるのはとても安心感があった *2

また,「企業側はスカウトする段階で報酬を提示しなければならない」という制約により企業側は必然的に候補者のレジュメを精読することになると思われるが,そのおかげか転職ドラフト経由でのカジュアル面談はとてもスムーズだった.もしこれが狙い通りならば,企業側と候補者の双方の利益につながる良く出来た仕組みだと感じた.

あと,最後に転職ドラフトに登録してみたのはもうかなり前,6年近く前だと記憶しているが,その頃はオファー金額が500-600万円程度の案件が多いように記憶していた.しかい今回は普通に1000万円超えの案件があり,候補者のランキングを見てもそれぐらいのオファーをもらってる候補者は少なからず存在しているようだったので全体的に相場が上がっているようだった.なので今の転職ドラフトはjunior classだけでなくsenior classのSWEの転職活動にも使えるレベルになってきていると感じた.

結果的には転職ドラフト経由で選考を受けた企業は全て選考を途中辞退するかオファーを断ってしまったのだが,報酬が重要な要素になる転職では使ってみると良いのではないかと思った.

YOURTRUST

日本版LinkedInといった感じで,転職意向のステータスを変更するとそれが企業の採用担当者に通知され,プロフィールを見た企業からスカウトがやってくるという感じである.YOURTRUSTを利用しているユーザ層が主にスタートアップに関心が強いユーザが多いのか,もらったスカウトメールも多くがスタートアップからのものだった.

自分が知らなかったスタートアップから多くスカウトメールをもらったので「こんなサービスがあったのね」と勉強にはなったが,今回希望していたポジションに近いものが無かったため選考へは至らなかった.今回はガチガチのearly stageのスタートアップは転職先としてはあまり想定していなかったのでそもそもミスマッチだったかという事情もある.

今回の転職活動での気付き

Coding testは対策が必須である

選考を受けた6社中3社で事前にオンラインでのCoding testがあった.難易度は初見で解ける簡単なものから,ある程度競プロをやってないと解けないだろうなというのものまで様々だった.自分はオンラインですぐ採点結果が明らかになるものについてはすべて満点だった*3.満点じゃないと選考をパスできないのかどうかはわからないが,点数を取れるのなら取れるにこしたことはない.

自分の過去の転職ではCoding testには苦い思い出しかなかった.例えば,設問について質問した結果,面接官から「そんなことも知らないのか」「そんなこと聞いて良い訳がないだろ」みたいな反応をされて険悪な空気になったり,うーむうーむと悩んでいる自分と苦々しい顔をしてその様子を眺める面接官という何とも言えない空気に逃げ出したくなったりした.当然ながらほとんどCoding testに受かったことがない.恥ずかしながら,過去に内定をもらった企業はすべて選考にCoding testを課さない企業ばかりであった *4

そういったこともあってCoding testには軽くトラウマがあり,今回ばかりは何としても突破するために選考を受ける前に2ヶ月ぐらいかけて対策した. 対策といっても基本的にLeetCodeの問題を解いただけである *5.以前も趣味で少し解いていたが,今回はまずEasyを100問ぐらい解いて問題に慣れてから実戦用としてMediumを100問ぐらい解いた.解いた,といってもMediumになると初見で完答できない問題の方が多かったので,そういった問題についてはDiscussionを読んで考察した上で自分で回答を書いたり解けなかった理由をまとめたりする作業がメインだった.Discussionを読んでもすぐには理解できず数時間をかけた問題もあったりした.なので1日に1問しか進められない日もあった.

また,競プロの基礎的な定番問題の復習としてアルゴ式の問題も解いた.特にDPは苦手だったので改めて勉強することで理解が深まり実装の自信もついた.

algo-method.com

あとは解法を丸暗記しないと無理だと判断した難問については実装をゼロから書く練習を繰り返したりもした *6.ちなみにHardレベルの問題は出題されたら諦めることにしてMediumレベル以下の問題で点を稼ぐ作戦とした *7

解けなかった問題は自分なりに考察を書いてesaにまとめていた

他の対策として,今回はCoding testに使う言語をこれまで競プロで使っていたC++からPythonに変更した.Pythonはそこまで得意な言語という訳でもなかったが,C++に比べると記述量が少なく済むため補完が一切効かない上に独自キーバインドのオンラインエディタ上でも書きやすいのと,最近はPythonで競プロの問題を解説してくれるブログも増えて勉強しやすくなっていた為である.

これらの対策をした結果Coding testで落ちることは無かったので,対策した成果は出たと思う.以前は雰囲気で書いていたPythonもLeetCodeやHackerrankなどのオンラインエディタ上でも何も見ずにかなり書けるようになったし,普段業務で書くコードの時間および空間計算量に以前よりも敏感になった気がする.

また,先人達の以下の記事も参考にさせてもらった.

qiita.com 1kohei1.com en9.hatenablog.com en9.hatenablog.com zenn.dev ichi.pro

System design interviewも準備しておいた方がいいが業務経験があればそこまでビビる必要はない

System design interview(もしくはそれに類する試験)が3社で行われた.だが,これについては大した対策はしていなかった.以下の本を一通り読んで問題の傾向や気をつけるべき点を確認した程度で,あとはぶっつけ本番で何とかなった.

この本で繰り返し強調されていた候補者向けのアドバイスは,「System design interviewは候補者がリードしなければならない」という点だった.候補者が議論をリードして面接官に積極的に質問をしながらすすめる事が重要であると書かれており,この辺は実際に意識して行った.時間配分も,普通の面接なら面接官がやってくれるところをSystem design interviewの場合は候補者に委ねられるケースがある書かれていたので,自分もその記述に従って最初に試験時間を尋ねて時間の使い方を決めて宣言するところから始めた.

他にもBack of the Envelope Calculation *8をやれとか色々と面接テクニックが書かれていたが,基本的には自分が普段業務でやっているdiscussionをやれば良いのだと判断して特に気負わずにいつもどおりにやった *9

6社同時に受けると毎日のように面接がある

一番忙しかった時は1日に面接を2回ハシゴした日もあり,かなり多忙になってしまったため受ける社数を減らすか面接の時期をずらした方が良かったと反省している *10

ただ,オファーレターの期限は一般にそこまで長く無いので日程をずらしすぎると泣く泣くオファーを断らなければならなくなる可能性もあり難しい所である.無職になっていれば無理が効いたのだろうが,無職になってから転職活動をするほど度胸がなかったため,急いで業務を片付けて早めに仕事を切り上げたり朝の9:00から面接を入れてもらったりして何とか調整した.現在は自宅でリモートワークなので仕事を終えた5分後に面接を受けたりすることも出来たので助かったが,これが普通にオフィスに通勤してたらこういう受け方は無理だっただろうなと思う.

希望年収は自分に嘘をつかずに伝えた方が良い

今回受けた企業はどれも選考の早い段階で希望年収について質問された.これまでの転職ではなかったことだったので少し驚いたが,素直に現職での金額と自分が欲しい金額を伝えた.その結果として,一社を除き希望年収よりも高い金額でオファーを出してくれた.多少年収が下がっても仕事にやりがいがあれば良いと考える人もいるかも知れないが,過去に未練を残したくなかったので前職の給与以下のオファーは一切受けないつもりだった.それで条件に合うオファーが出なければ自分の実力不足と割り切るつもりだった.

マネージャーやリーダーの経験がないと判断されるとマイナス評価につながる会社が存在する

自分は過去にtech leadやteam leaderといった肩書がついたことは一度もない.それでも,過去には設計をまるっと全部やったり,project manager達とスケジュールについて調整したりといった仕事は必要に応じて(つまり他にやる人がいない状態なら)自然とやっていたし,自分が主導して社内の複数の部署の人にかけあってプロジェクトを手伝ってもらったことは過去に数回ある.これらの振る舞いはベンチャーに勤務するSWEとしては当然やるべきことだと思っていたし,特にアピールすることもないかなと思ってこちらからは聞かれない限り言わなかったりした.

しかし,それがマイナスに働き,他社のオファーの中で一番低い金額となった企業があった.事前に伝えいてた希望給与よりも低かったので,オファー面談時にそうなった理由を尋ねた所,上述のようなリード経験がないと判断したためだったと回答があった.リード経験の有無なんて面接中に一度も質問されていないのだが,職務経歴書に明示的に書かなかった自分が悪いということで今後の反省としたい *11

自分の評価は企業によって差が大きい

前述のような結果となった企業があった一方で,オファーをもらった他の3社からはProjectのリードや技術面でTeamのリードが出来るICのSWEとして評価していただいたようだった.前述の一社の評価の件で若干凹んでいたのだが,割合で言えば高く評価してもらった企業の方が多かったので救われた気持ちであった.ちなみにオファー金額は最低金額と最高金額とで400万円ぐらいの差があった.

オファー内容は,面接官のスキル,面接官との相性,面接時の会話の流れ,自分の自己PRスキル,その会社の人事評価制度などの多くの要素が関係してくるため,数をこなしてみないとうまくいくかどうか全く分からないなと感じた.オファーが出るかどうか,自分にとって良いオファーが得られるかどうかは上述のような自分で制御できない要素にも依存しているため,自分が制御できる要素を使って最善を尽くすしかない.そう考えるのが精神衛生上良さそうだという結論になった.

過去には同時に1社か2社しか選考を受けずに転職していたが,実際にはかなり危ない橋を渡ってきたのだなと今にして思う. 今までは自分の自己評価はかなり低く,オファーが出ると熟慮せずに快諾してしまう傾向があった.今回複数の企業を同時に受けてみたことで,この行動はかなりリスクが高いものだったと実感した.

いずれにせよ,今回の転職で『自分はそれなりに評価してもらえるSWEなのだ』という自信が得られた.この事実だけでも苦労して複数社を同時に受けただけの価値はあったと思う.自分は馬鹿だからやってみなければ何事もわからないのだ.生涯勉強である.

おわりに

今回の転職活動はポツポツとカジュアル面談を受け始めた頃から数えると約5ヶ月に及ぶ長期戦となった.

この5ヶ月間誰にも打ち明けずに1人の力だけで乗り切らなければならなかったため,精神的に厳しい時もあったが,結果的には納得できるオファーを得られたので苦労の甲斐があったのではないかと考える.

転職ドラフトは思っていた以上に体験が良かったので,最初に条件面でのマッチングをクリアしておきたい人にはぜひともおすすめしておきたい.Juniorクラス向けの500万-600万円ぐらいのポジションが多い印象だったが1,000万円超えのポジションも普通に来たのでSeniorクラス以上の転職でも使えるのではないかと思う.YOURTRUSTはEarly stageのスタートアップの採用担当者から直接お声がけをいただけたのでEarly stageのスタートアップへの転職を強く検討している人に向いてそうである.

この記事が誰かの転職活動の参考になれば幸いである.

*1:People managementをしたくない理由は単純に今やりたくないからと,仮に今People mangementをやり始めたら自分で手を動かす時間が減ってストレスになるのは目に見えていたため.

*2:普通にカジュアル面談に申し込んでいきなり報酬の話をするのって結構ハードル高い気がしてるんだけど自分だけだろうか

*3:すぐに結果が分からないものについてはサンプルケースと自分で考えたテストケースが全て通ることを確認して提出した

*4:全然関係ないけど新卒の面接のグループディスカッションでも候補者にガチ議論をしかけた結果落ちまくって,結局グループディスカッションがない企業から内定をもらってそこに入社した思い出がある

*5:LeetCodeを使ったCoding test対策の是非についてはここでは議論しない.なお今回の転職活動中に「これまんまLeetCodeで見たやつだ!」という問題には1問も遭遇しなかった.

*6:Linked Listのmerge sortの実装とかを繰り返し練習したがちょっとやりすぎた感もあった.GAFAレベルの外資を受けるんなら必要だったんだろうけど.

*7:もちろんHardクラスの問題が解けないせいで一発アウトという事態もあり得たが,Hardまで完璧に対策しようと思ったら働きながらだと半年コースになりそうだったので諦めた.

*8:ストレージのサイズとかネットワークのトラフィックなどのちょっと計算すれば分かる非機能要件を手計算で求めること

*9:この本自体はSWEとしての業務経験がない人がSystem design interviewを突破するための対策本という位置づけなんだろうなという気がした.普通にSWEとして業務してれば「そんなの普段からやってるじゃん」みたいなことが面接用のテクニックとして色々書かれていた.

*10:面接を受けた翌日に自社の面接官をしている時もあって不思議な気持ちになった.

*11:ただ「tech leadやteam leaderの肩書じゃなかったけどそういうmoveを自然とやってました」みたいなのが選考する側にリード経験として認められるかどうかは不明.こういうの,どうせ選考する側のさじ加減なのであまり真面目に考えない方が精神衛生上いいかも知れない.単に受ける企業の評価制度と自分のキャリアの相性の問題のような気もする.

SWE歴8年目にして初めてスクラムを経験したのでその所感を述べる

はじめに

SWEとして仕事をし始めてから8年目にして初のスクラム開発を経験した.6か月ぐらい経ちその間に2チームでスクラムを経験してきたので所感を述べる.

自分が経験してきた開発手法

過去にいたチームでは,世間一般で言われるスクラム開発*1ではなく

  • 毎日チーム内で進捗を確認(いわゆる朝会の運用)
  • チケットはカンバンで管理

の2点だけを採用した開発プロセスだった.チームによって「タスクを誰が決めるか」「機能要件と非機能要件のベロシティのバランスをどう取るか」といった細かい点は異なっていたが,基本的には上記の2点だけは必須で行い,あとは割と自由,という感じの開発プロセスを複数の組織で経験してきた.2013年~2020年ぐらいの話である.

今のチーム

2021年にjoinしたチームは教科書どおりのスクラムをやっていた.自分は上述のような「なんちゃってスクラム」みたいな開発経験しかなく,自主的にもちゃんとしたスクラムを学んだことがなかった.そのため,今の組織にjoinした当初は「ストーリーポイントで相対見積もりをする」とか「すべてタスクの優先順位はチーム全員が合意して決める」みたいなプロセスを見た時に正直面食らった.これまでやっていたなんちゃってスクラム開発の延長ではなく,全く新しい手法としてスクラムの価値観をinputしていく必要があった.

スクラムやってみた所感

あらゆることが明文化されている

スクラムに関する所感として,まず感じたのは開発経験が浅いメンバーでもチーム活動に参加しやすいという点だった.スクラムではあらゆるプロセスのやり方が明示的に決められているため,「暗黙の了解で何となくやる」ということがなくなる.そのため成果が属人化しにくいと感じた.リファインメント,プラニングといったイベントですらそれぞれに進め方やゴールが決まっている.組織によってどのようなプロセス・ゴールを設定するかは異なると考えられるが,スクラムはとにかくあらゆるプロセスを明示的に定義することを重視していえるように感じた. また,明文化されていることでSWEとしての経験の差を埋めることができる.「経験10年ぐらいのSWEなら大体何となく知っている」暗黙知に依存すること無くチーム活動が出来るため,経験が少ないSWEでも1メンバーとして参加しやすい気がする.これはチーム間の知識の共有という点でも有効だと感じる.

ストーリーポイントによる相対見積についてはちょっと疑問がある

見積についても相対見積を採用している場合は基準となるチケットをもとに見積もれるので,経験が少なくても見積自体はしやすいと感じた.

ただ,チケットを担当して実施するSWEの力量に応じて実際にかかる工数は異なってくる訳だが,そのギャップをどう扱うかはいまだによくわかっていない.

一般的には見積で各チケットに設定したストーリーポイントの合計と実際に消化できたチケットのストーリーポイントの差が大きくならなければとりあえずは良いらしいのだが,この辺のベロシティの評価方法についてはまだ良くわかっていない. また,実際にチケットに着手する人の力量に応じてかかる時間は異なってくる訳だが,この力量の差はストーリーポイントには反映されておらず,ストーリーポイントがそのスプリントのキャパシティを示す指標として機能しているかは謎である.それでもスプリントを重ねることで「1スプリントで大体これぐらいはできる」という目安としてうっすらとキャリブレーションされてきたので,チームのキャパシティを示す基準になりつつはある.もう少し時間が経てば変わってきそうな気がする.

合意を取らないと何もできないので何でも人と話す必要がある

スクラムの原則は「合意していないことはやらない」だと理解している.これまで述べてきた通り,知識の属人化やスキル差を埋めるための知識共有という目的を考えれば理に叶っている.

一方で,「なんでも合意が必要」という成約は,毎回何かアクションを行う度に多大な合計形成コストを払わねばならないということでもある.

例えば,プラニングで合意に至らなかったチケットがそのスプリントで着手されることはない訳だが,自分としてはどうしてもそのチケットがそのスプリントに必要だと確信したとする.実際大したコストもかからないし手持ちのタスクを全部やっても間に合いそうな気がする.でも合意していないからそういうことは出来ない.正しい手続きとしては,ステークホルダーを全員集めて同期的もしくは非同期的に議論して合意を取らなければならない.例えば1 スプリントで終わる軽いリファクタリングについては,今までいた組織では個人の空き時間で自由にやることが比較的許されていたため,個人でスケジュール管理ができていれば何の問題にならなかった*2.しかしスクラムとなると話は別で,すべてが「チーム」で「合意」されている必要がある.しかも実施したタスクはすべて可視化されていなければならない.よって,個人のスケジュールが空いたならチームで合意したバックログの先頭のタスクをやらなければならないし,勝手にベロシティに計上されないタスクをやることは許されない.そしてリファクタリングといった非機能要件系チケットと新たな機能開発といった機能要件系チケットの優先順位を1つの軸で優先度付けるのってすごく難しい訳で,今いるチームだと機能要件が優先される.KRに定量的な「1 Quoterにおけるリファクタリングチケット数の割合」みたいなものが入ってなければそうなるのが当然である*3

この点についてはどの程度スクラムに準拠するかという程度問題の気がするが,本当に教科書どおりにやるとこういうことになるらしい.スクラムって厳しいのな.

ただ,自分にとってはあまりに厳しすぎると感じたので,自分から提案してベロシティの10%は自由にバックログから取っていいという合意を得た.

おわりに

スクラムの「何でも明文化」するところは合理的だと感じたし,これまで自分がベストプラクティスだと考えていたものと合致している. 一方で,相対見積における個人の生産性の差の排除やチームの合意形成コストの高さついてはまだ課題を感じている. ただ,少なくとも2021年現在,自社開発をしている日本国内の組織においてはスクラムを採用しているチームが増えていると感じているので*4,今後の開発手法のデファクトスタンダードとしてスクラムは広まっていくだろうと考えられる.そのため今苦しくても苦しんでスクラム開発に慣れていくコストは無駄ではないと考えている.

*1:何が正式なスクラムなのか分かってないが,本記事では「POとScrumMasterがいる」「スクラムイベントを全部やっている」「割り込みは禁止」「チームで合意したこと以外は勝手にやっちゃダメ」「ストリーポイントは相対見積でプランニングポーカーで行われている」「ベロシティを毎週計測する」みたいなスクラムの教科書に書いてある手法に則ったスクラム開発を指す

*2:前職では手が空いている時に限り2週間までは好きにやれ,2週間を超えそうな場合はちゃんとDesignDocを書いてチームを説得せよ,というルールだった

*3:逆にこれをKRに入れてみるのは案外アリな気がしている

*4:同業者の知人との会話などからそう感じた

2020年は色々な意味でリスタートの年だった

総括

仕事

細かい仕事をかなりこなしており,あまり目立った成果は何も残せなかったと思う.プロジェクトを転々としながら,最後に残ったピースを埋める仕事を淡々としていた,という印象である.

人出が必要なプロダクトの環境マイグレーションとかのinternalなタスクを多くこなしていたので,会社としては重要なタスクである一方,会社の事業に与えるインパクトは小さかったと認識している.大企業ではないがスタートアップでもない,という規模の会社で働くのは初めてなせいか,個人のSWEとしてどういった成果や立ち回りが求められるのかを手探りで働くような1年だった.また初めて外国人のマネージャの下で働いたが,常に言語の違いによる壁は感じていたので,来年以降はそういった障害も乗り越えなければならない.

技術的にはインフラ系の仕事が多かった.具体的にはTerraformのconfigを更新したり社内独自の設定ファイルを更新すれば済んでしまうものがほとんどだった.一方で,production環境のためにAWSを触った経験がほとんどなかったため,イチから勉強しなおす良い機会にもなった.あとAmazon ECS on EC2を多用するプロジェクトに参加していたためECSには大分詳しくなった.ネットに出回っている情報のほとんどがFargateを前提としていてEC2クラスタを自前で運用するパターンのパブリックな情報がほとんど無かったため,いつか役に立つかもしれない.

上記のようなインフラ仕事を多くこなしていた関係で,今年はアプリケーションのコードは大して書いていない.Kotolin + DropwizardのWeb APIのメンテ,RubyでちょっとしたスクリプトRails applicationのメンテ,JavaでECS APIを叩く処理などを書いたが,前職時代と比べると圧倒的にコードを書いていない.プロダクトのフェーズが全然違うので当然であるが,運用改善がメインになるとこうもコードを書く機会が減るものかと少し驚いたりはした.要するに,前職はプロダクトの機能が足りなくて次から次へとコードを書いてデプロイする必要性が高く,一方で現職はビジネスに必要な機能は一通り揃っているのでそれをステーブルかつスケーラブルかつ低コストで運用できるようにマイグレーションする必要性の方が高い,というのが自分の見解である.あくまで自分がいるチームが関わっているプロダクトはそのように見えた.

プライベート

勉強

今年はcovid-19で自由に行動できずにストレスが常に高い状態だった.そのせいもあってか独学での勉強の成果は早々に諦めた.元々図書館やカフェで本を読んだり作業するのが好きだったのだが,それらが一切できなくなるストレスは想像以上だった.基本的には仕事を問題なくできているだけえらいと思うことにした.

今年はかろうじて深層学習のオンラインコースを修了するのが精いっぱいだった.現場で使えるディープラーニング基礎講座というJDLA認定講座を受講して修了した.すべてオンラインで,3カ月ぐらいかけてすべての講義と課題を修了させた.内容的には「ゼロから始めるディープラーニング」の内容が半分,残り半分がオリジナルといった感じだった.「ゼロから~」は最初の巻を読んでいたので知っている内容がほとんどだったが*1,GAN周りについてはほとんど知識がなかったので良い勉強になった.この講座は基本的な機械学習線形代数情報理論の知識が前提になっているためか,他社のコースに比べて少しは安くはなっているようなのだが,それでも模試込みで30万円近くしたので何ともしてもE資格に合格しなくてはならない.

あとは競プロもやっていたが,情けないことに時間の確保が難しくて7月ぐらいから中断している.今年中の茶色脱出を狙っていたのだが,思っていた以上にcovid-19の影響は大きかった.

趣味

勉強の代わりといってはなんだが,Overwatchを本格的に再開した.2020年12月31日現在でレートは以下の通りである.

f:id:serihiro:20201231202052p:plain

基本的にタンクとサポートしかやっていない.今年の5月時点ではタンクもサポートもたまにブロンズに落ちするぐらいのレート(1500~1600付近)だったので,そこから考えれば成長はしているようだ.

反省用にプレイ動画をYouTubeにアップしている.最近はゆっくりボイス入れて適当に編集したりもしているがいい気分転換になっている.

www.youtube.com

各月の出来事

1月

プライベート

大学院

  • 修論を提出した
  • 修論を発表した

2月

仕事

  • 今の会社で働き始めたが入社即リモートワークとなる
  • いきなり自分しか日本人がいないzoom mtgに放り込まれて死ぬかと思った

プライベート

  • 株価が世界的に下落していたので積み立てNisaとWealthNaviを始めた

3月

大学院

  • 修了した

プライベート

  • 15年振りにケースからWindows PCを組んだ
  • CourseraのMLコースを始めた*2

4月

プライベート

  • 新アカウントでOWを本格的に再開するがヒラタンが即シルバー落ちする
  • ジャンプ連載中のチェンソーマンが面白くなり連載を追うためハンターハンター連載時以来のジャンプ電子版の購読を始める

5月

プライベート

6月 - 7月

何の記憶もない

8月

プライベート

  • 深層学習のオンラインコースの最終課題をクリアし,無事修了する
  • 自分の振り返り用にYouTubeでOWの動画配信を始める

9月

プライベート

  • OWでタンクゴールド
  • このころから在宅勤務が嫌になってきてストレスが溜まっていた

10月

プライベート

  • ほとんど覚えていない
  • 本をたくさん買った気がする

11月

仕事

  • 在宅勤務がつらくなった旨を会社側に相談して週3日のオフィスワークを再開する
  • その結果体調は改善した
  • 一方でこの時期仕事は忙しかった

12月

プライベート

  • Go Toトラベルで長崎に行き,念願だったカピバラとの対面を果たす

www.youtube.com

仕事

  • 一区切りついた

*1:過去に書評も書いた https://serihiro.hatenablog.com/entry/2016/12/22/000000

*2:7週目まで課題を終えたが8週目でとん挫して以来止まっている

仕事のストレスを緩和するのに有効だった行動

在宅勤務やストレスフルなプロジェクトが原因で,今年の9月〜11月の間はストレスが高い状態が続いていた.その結果,仕事に集中できなくなったり,軽い入眠障害に陥って心療内科に通ったりしていた.それらの症状は複数の対策によって緩和され,現在は問題なく労働している.

本エントリでは,今後のために自分が行った対策をメモしておく.以下,効果が高かったと思われる順に記す.

  • 週3日オフィスに出社して勤務する*1
  • 6時間以上寝る
  • 昼休みは近所を散歩する
  • 週2日ぐらいスタバに行ってコーヒー飲みながら本を読む
  • 食費を気にせずに食べたいものを食べる*2
  • 予算上限を決めずに欲しい物を買いまくる*3
  • 自分の感情の起伏とその原因分析を文章に残す
  • 無限に独り言を言って自分の思考を整理する
  • 自室を掃除する
  • 気が済むまで無限にFPSをやり続ける

*1:会社と交渉して週3日までのオフィス出社の許可を得た

*2:Uber Eatsを活用した

*3:マンガをkindle大人買いしたりiTunesで曲をダウンロードしまくったりした

楽しめるものがなくなった

気がつけば趣味らしい趣味がなくなってしまった.

かろうじてFPS(OW)は続いているのだが,趣味と言われるとどうなのかという感想になる.ランクマでの一定の目標を持ってやっているとはいえ,どこかのコミュニティに所属している訳でもなく,野良で一人黙々とランクマを回し,たまにプレイ動画をYouTubeにアップロードしているだけである.そのような活動を趣味と呼べるのかどうか甚だ疑問である.10年以上前にFPSのクランに所属して夜な夜なクラン内で紅白戦をしたり他クランとの試合をしていた時期があったが,あれはそれなりの時間と労力をつぎ込んでおり,かつ人との交流もあったことから趣味と呼ぶに値する活動だったのではないだろうか.

FPS以外だと,過去に6年間ぐらいアマチュアマンドリンオーケストラに所属していた時期があった.クラシックギターのパートだったのでこの間はクラシックギターが趣味だと言えた.クラシックギターだけで見ればその前にも大学のクラシックギターのサークルに所属していたので,結構長い間やっていた趣味と呼んでも嘘にはならないだろう.しかし,今はどこのオケにも所属しておらず,プライベートでも一切弾いていない.住んでいるマンションは楽器禁止だし,近所に練習場所を確保しにくい地域に住んでいる.そもそも純粋に音楽をやるモチベーションも無くなってしまった.

趣味プログラミングも気が付くとほとんどやらなくなってしまった.今は仕事以外でコードを書く機会がほとんどない.つい1年前まで狂ったように謎のOSSを量産していたり半年前まで競プロもやっていたはずなのだが,何かもう何もする気がしなくなってしまった.せいぜい機械学習Computer Visionの本を読む程度で,コードは数式の定義を確認したりするのに使う程度になってしまった.

どうしてこうなったのか理由は分からない.今は何をやっても「心から楽しい」と思えなくなった.「少しは楽しい」はそれなりにあるが,すぐに空しくなる.鬼滅の刃のテレビシリーズも劇場版も観たが,その話題性に反してどこかで観たような要素の詰め合わせ*1に「一回観たら二度と観なくていいや」という気持ちになった.ジャンプ連載中のチェンソーマンも読み始めたころは純粋に楽しめていたが*2,今は惰性で読んでいるに過ぎない.

*1:ジョジョの1部と2部を足して0.15をかけたものに3部に0.7をかけたものを足したような感じ

*2:しばらくレゼ編の喪失感を引きずるぐらいにはハマっていた

自分の強みらしい強みが30代半ばにしてようやく見えてきた

tl; dr

自分の年代,つまり30代半ばでプライベートで新しいことを継続して勉強できているのは「自分の強み」と捉えていいようだ,という話.

本編

自己啓発本とかを読むと「自分の弱みと強みを知りましょう」といったアドバイスがよく書いてある.

弱みを列挙するのは自分にとって簡単だ. 怠けやすい.飽きやすい.ダメそうになるとすぐ諦める.現状維持を極端に嫌がる.頼んでもないのに上から目線でアドバイスしてくる人をすぐ嫌いになる*1.よくこんなんで会社員をやっているなと思うぐらい弱みは沢山ある.

一方で強みを列挙するのが昔から苦手だった. 20歳を過ぎてから,ストレングスファインダーとかで自己分析をする機会は何度かあったが*2,そこでハイライトされた項目が自分の強みかというとなんとなく納得できないものが多かった.
自分で過去の経験を振り返ってみても言語化できなかった.これは自分の経験の範疇でだが,仕事において誰かから褒められたことがない.社会人を通算9年+やってる*3にも関わらず,自分の上司的な人から何か自分の特徴について褒められたことがない.上司から好かれないタイプの人間だからかも知れない.逆に上述したような弱み+αはさんざん言われてきた.しかし,褒められたり長所を指摘された記憶は全くない.過去に勤務していた企業の社長に「お前はいつかどこかのベンチャーのCTOになりそうだ」と言われたことはあるが,それは長所でもなんでもなくただの「特性」に過ぎない*4

そもそも強みとは何か?weblio辞書で検索してみても,いまいち良くわからない.しかし,「同じような属性の人間があまり持っていない武器」と考えれば多少は心当たりがあった.それはほぼ趣味でやっている勉強である.2020年3月で大学院を卒業して日常から研究活動がすっぽりなくなってしまったため,CourseraのMLコースを受講したり,せっかくなのでE資格も取りたいと思ってディープラーニングのオンラインコースの受講をしていた.最近では画像処理エンジニア検定エキスパートの勉強をしている.新しいなにかを勉強するのは自分にとっては自然な行動で,大学院入学前にも数ⅡBレベルの高校数学を勉強し直して数学検定2級を取ったりしている.その前は,具体的な資格ではなく新しいプログラミング言語フレームワークの使い方を勉強している時間が長かったような気がする*5

こういう勉強を苦だと思ったことはなかった.もちろん好きでやっていたので苦ではないのは当然なのだが,こういう行動を取れる人は,自分の同業者かつ30代半ばという狭いクラスタにおいては,どうも珍しいタイプであるらしいということが分かってきた.

同年代の同業者と話をすると,プライベートの時間で何か自分が知らないことを継続して勉強しているのは自分以外にほとんどいなかった.例えばE資格を取るためにディープラーニングの講習を受けたとか,TOEIC/TOEFLで具体的なスコアを達成するために英語を勉強しているとか,オンラインのコースで高校数学を勉強しなおしているとか.そういう人は自分が20代の頃は身近に結構いたものだが*6.しかし,どうも30代半ばになるととてもレアになるようだ.もちろん,自分と同年代で自分よりも沢山資格を取りまくっていたり,競プロでめちゃくちゃ結果を出してたり,自分よりも何倍も技術書を読んで知識が豊富だったり,国際会議にガンガンに論文通している化け物みたいな人や,起業してCxOをしている人,などなど,何人も知っているので,自分が同年代の中ですごいとは全く思っていない.とは言え,平均値よりはマシな方なんじゃないかな,程度の感触を得つつある.

何が言いたいか分からなくなってきた.とにかく,もし今自分がどっかの会社の面接を受けるとして,そこで自分の強みについて聞かれたら,

  • プライベートの時間を使って業務とは関係ないけど何かを継続して勉強していて
  • それぐらい新しいものを覚えることに関してはモチベーションはあるし
  • 取得した資格や業務経験によってその成果も客観的に示せるよ

ぐらいのことは言ってもバチは当たらないんじゃないかな.
30代半ばにして初めてそういう発見をしたよ.散々色んな人にボロクソに言われて否定されてきた自分の人格と人生だけど,少しは自分で自分を肯定できそうな要素を見つけたよ,という話.

*1:上から目線でアドバイスできる人は,自分よりも会社における立場が上であることが多いので本来であれば仲良くしておいた方が得することが多いと考えている.

*2:不思議なことに20歳の頃にやっていたPCを教えるバイトでもやったことがある

*3:2009年4月に学部卒で就職から無職になることなく働き続け,2018年4月-2020年3月は大学院にいたので11-2=9年

*4:なお,経営にも関わるタイプのCTOポジションには全く興味がない

*5:例えばRubyRailsを独学で覚えて自作webサービスPHPからRubyにmigrationしたりしていた.

*6:一番すごいと思った人だと,フルタイムで働きながら公務員試験を受けようとしているやつがいた.

プロダクトは運用フェーズの方が圧倒的に長いという事実とどう向き合うか

現職を含め,これまで3社の自社サービス企業*1で働いてきた*2

1社目ではメインのプロダクトがすでにサービスインしていた.主要な機能は大体完成しており,徐々に新規ビジネス案件のプロジェクトが減って運用フェーズに移行し始めるタイミングだった.最初の仕事は社内向け管理画面のちょっとした修正とかだったと思う.当時,20代半ばの若手で経験も少なかった自分は,そういう最後まで残っていた重要度の低いタスクを担当していた.入社して半年ぐらいでデカい新規開発プロジェクトを担当した後は,本格的にチームの人数が減り始めて運用フェーズに移行していった.

2社目では入社時点ではサービスインはしていたものの,割とやった方がいい残タスクが結構残っている状態で,バグも結構残っていた.自分の入社直後の仕事は,開発体制の見直し,バグの可視化,バグつぶしがメインだった.別にそれをやってくれと言われた訳ではないが,まずは体勢を整えないと安心して仕事ができなさそうだったのでそれまでの知見を活用してどんどん改革していった.それまで雑多にWeb APIをリリースしていたのが,決まった曜日,決まった時間帯の週1回になったのは自分がそう決めたからである.ただ,それらを片付けて綺麗にした途端,ビジネス要件的にはもう十分といった感じになってしまい,割とヒマになってしまった.幸いにもその後いくつか難しめのプロジェクトも経験できたが,やがてビジネス起因のタスクは発生しなくなり,Web API本体のリファクタリングバグフィックスやライブラリのバージョンアップ,それもやり切ってしまうと社内データ分析基盤の整備や他プロジェクトの手伝いに精を出していた.それが最後の1年間ぐらい続いた.

3社目は現在の会社だが,サービスインしてからの時間はこれまで経験した会社の中では最も長い.現在所属しているチームでは運用をいかに安定させ,内部コンポーネントリファクタリングにより開発コストを低下させる作業に注力している.自分の場合,現在は自社サービスのコンポーネント間だけで使われるプロダクトを改善している時間が大半を占めている.

これまで経験して思うのは,ゼロベースで新規にプロダクトやcustomer facingな機能をゴリゴリ開発しているのはほんの一瞬で,その後は長く運用フェーズが続くというライフサイクルである.運用フェーズが長く続いているというのは,言い換えればビジネス的に成功している,もしくはクローズするほどひどくない,等のポジティブな事実を示している.そのため,経営視点で見れば良い状態だと言える.実際,自分の収入も運用フェーズが長いプロダクトの企業ほど改善されてきている気がする.

ただ一方で,運用フェーズが長いと技術的に新しいことを試す機会が減る,やることが同じことの繰り返しになって単調になる,という事実と向き合わなければならなくなる.

技術的に新しいことを試す機会が減ること自体は,収入を得続ける点においては問題ではないと考えている.例えば,同じ会社の同じプロジェクトに居続けるなら,同じ技術を使って仕事を続けていてもすぐに問題になることは少ないだろう*3.実際,自分も前職では2年3カ月の間ずっとRailsのWeb APIのメンテナンスを続けていたが,それで仕事を失いそうになることはなかった.その前はJava + Springだったが同様である*4

一方,「やることが同じことの繰り返しになって単調になる」問題は,未だに自分にとって深刻な問題として残っている.多分,一般的なソフトウェアエンジニアと比べても自分は相当な飽き性なんだろうと思う.もしくは,プライベートで楽しみを見つけることが下手で,仕事に楽しみを求めすぎてしまっていたことも原因の一つであると考えている*5.先に書いたように,プロダクトはいずれ運用フェーズに移行する.Webサービスは永遠のベータ版*6なんて言われていた時代があったが,本当にそうだろうか.足りないものを片っ端から作らなければならない,毎日のようにコードを書かなければならない,そんな夢の日々は一瞬で終了する.ベンチャーで働くソフトウェアエンジニアというのはそういう生活をしていると想像する人もいるのかも知れないが,そんなフェーズはどんなプロダクトでも一瞬だと思う. *7

この傾向はAWSやその他便利なサービスを活用することで近年さらに顕著になっていると考えている.インフラエンジニアがいなければherokuに重課金すれば十分で,サーバを持つにしても当然のようにIaaS*8で,メールを送信するのに自前でメールサーバ立てるなんてのは大抵の場合は不要で外部サービスに丸投げすれば十分で,GitHub ActionやCircle CIでリッチなCI/CD環境を最初から低コストで整えて開発をスタートできる*9.バックエンドエンジニアがいなければFirebaseで代替してフロントエンドだけを開発すれば場合によってはサービスインも可能な時代で,もはや自分のようなほぼWeb API開発だけを専門としてきた人材は,自社サービスを運営するベンチャーにとって必ずしも必須ではないと考えている*10

このような状況下で,自分は今後どうすればいいのかと頭を抱えることが増えた.今後も同じ問題に遭遇したら,これまでのように「開発フェーズ」にあるプロダクトを作っているベンチャーを探して転々とするのか,勝負する領域を変えて長く戦える場所を探すか,できることを増やして*11運用フェーズに入っても開発を続ける機会を生み出す別の能力を身に着けていくか.何が正解なのか分からないが,このままだと過去と同じことを繰り返すだけになってしまう.転職自体はそこまで苦ではないが,いい加減それ以外の手段も持ち合わせていきたい.

*1:この言い方もう死語かも知れないけど,いわゆる受託開発専門じゃない会社を指している.

*2:なおSIer + 受託開発も3社経験している.

*3:2年7カ月以上同じ会社にいたことがないダメ人間なので実態は良く分からない.けど別に4年いようが5年いようが,会社がメインで使っている技術スタックが変わらなければ本人の技術スタックが変わらなくてもすぐにその人の評価が下がる,プロジェクトにありつけなくなる,といった事態は起きないのではないだろうかと考えている.

*4:ソフトウェアエンジニアとしての評価と使える技術の幅はそこまで比例しないものである.

*5:反省してプライベートでいくつか何の役にも立たない個人プロジェクトを積極的にやるようになったのはつい3年前からの話だ.

*6:https://gigazine.net/news/20060823_beta/

*7:なお自分はWindows NTの開発記である「闘うプログラマー」やFaccebookの立ち上げ時期の様子について書かれた「フェイスブック 若き天才の野望」に出てくるデスマ話が大好きで,なんで自分はこれらのプロジェクトに参加できなかったんだと読む度に悔しい気持ちになる.

*8:これも死語かも知れない.AWSとかGCPとかAzureの仮想サーバ等の計算リソースを指す.

*9:昔はJenkinsってやつを社内で飼ってた企業が多かった.

*10:これが自分が仕事辞めて大学院に進学した理由でもある.https://serihiro.hatenablog.com/entry/2018/04/23/213418

*11:例えば今年に入ってからDLを中心に機械学習を勉強している.最近は畳み込みフィルタを適用する本来の意味について知りたくなってComputer Visionの勉強も始めた.