私「ファッ!?!?」まさか試用期間中の当時はジュニアと言われてもぐうの音も出ない私という人材を貴重なお金を使って出張させたりしないだろうとたかを括っていたので、大急ぎでパスポートを作った記憶があります。2017英語もろくに聞き取れず、開発のスピード感についていくのに必死だった。思えばこの経験がきっかけで必死に英語を勉強し始めた気がする。英語をそこそこ習得したそこそこ、と称した文脈としては以下の通り。英語しか喋れない同僚と仕事をすることができるようにはなったしかしながら多少生産性は落ちる一方で学問的な観点ではほぼ成長していない、と捉えることもできる「コミュニケーションの手段としての英語」だけを頑張ってきたので例えばTOEICの点数はおそらく入社当時から大きく変わっていないし覚えてる単語数にも大きな変化はない。会社で一緒に働く英語話者と仕事をしたり、海外カンファレンスで登壇者に聞きたいことを聞き出すだけの英語は身についた。SpeakingとListeningは身についたかなと思う。これは多少言い訳ではあるのだが、社会人で英語に限らず何かを勉強するって相当難しい。そもそも週5で労働していて週2日しかないうえに学習したことを反復して毎日活かせるわけでもないので学生の頃よりは圧倒的に勉強したことが身につかない。私もUS出張直後は参考書を買って勉強しようと試みたが結局挫折してしまった。それでもここまで英語が喋れるようになったのは、会社の補助でオンライン英会話をほぼ毎日、就業直後のまだ気力があるタイミングでオフィスで受けられたこと。実際にリアルの会話をする機会が社内に溢れていたことに限る。それだけだと英語力は頭打ちになるし、実際今はなっていると思う(余談だが、日本に住んでいる外国人の英語はめちゃくちゃ優しいと思う、日本人が英語が苦手なことを無意識に知っている)。それでも自分がコミュニケーションを取りたい優秀な人に人の力を借りずに話せるのはこれから先もかなりアドバンテージだなと思う。入社当時から今も変わらない文化として、アウトプットしてるものにはインプットの機会を与える、というのがある*1。そのため、というわけではないが自分の力を磨いたり常にベンチマークできるように内外問わずアウトプットをしてきたおかげか、国内外問わず様々なカンファレンスに会社の援助を受けて参加させてもらった。以下は私が会社に参加させてもらえた海外カンファレンス達。2017の参加権を得て、初めて参加のチャンスが転がってきた時のことが印象的だったのをよく覚えてる。私は性格上、自己評価も低いし何事も遠慮しがちなので当時のCTO(@sotarok)に顔色を伺うように「私なんかが行ってもいいんですかね...?」っといった感じで相談した。したら「行ってもいいけど、行きたいの?」というような感じで私自身の意思みたいなのを確認されて、若手意識じゃないけど自分は未熟だから許可を取らなきゃいけないとか、100%のリターンが無いとお金のかかる行動を起こしてはいけないみたいな無意識の遠慮がスパンと消えた記憶がある。それからはチャンスがあったら自分の頭でコストとリターンも考えつつ、一人の開発者としてどうしたいのか、行ったらどうなれる可能性があるのかとかも考えられるようになった。CTOはもちろん、当時行って来いと背中を押してくれたチームメンバーの人にも心の底から感謝しています。メルチャン立ち上げ2017年の7月にメルカリチャンネルというサービスを立ち上げたのですが、初期の開発からその後、約1年ほど運用をしていました(※2019年7月にクローズ)。2017sota1235.hatenablog.com当時の思い出は書き出すと本当に長くなるしまとまりもないので箇条書きで書くと素早く、最低限の品質で出す開発を経験できた全く触ったことのなかった技術スタックに触れることができたよかった副産物として、それを外部にアウトプットすることでいいつながりも増えたプロダクトのことを死ぬ気で考え抜いて開発の立場からできることを考える、という入社した際に目標にしていたことを肌で体験できた私には「これが無いと生きていけない」というなにか(Webサービスじゃなくても何でもいい、なにか)を作るというのが人生の目標のうちの1つなんですが、メルチャンではそれを一定、叶えることができたと実感できたのがよかった。実際に作ったものに対して利用してるお客様から生の反応がもらえ、ときには対面でフィードバックをもらうこともできました。クローズまで面倒を見ていたわけではないものの、半永久的にお客様を幸せにし続けることができなかった、という点は未だに悔しさもあるので来世で頑張りたい。採用へのコミット一時期ではありますが、採用プロセスに参加させてもらってました。それに関する自分のアウトプットは振り返ると本当に反省が多いのですが、それまでエンジニアリングやプロダクト作りにしかフォーカスしていなかったので、人にフォーカスしなければいけない採用は非常に刺激的な経験でした。今振り返るとああできたらよかったのに、というタラレバだらけなので次の場所でもチャンスがあったら頑張りたい。個人的な目標としては再現性のある採用がしたい...。LeadというRoleを任せられていた。Lead業に関して語りたい人はぜひ飲みに行きましょう。やってみて実際どうだったかなと振り返ると、学びもつらいことも同じくらいあったなと思う。自分はパーソナリティ的に人に頼るとか任せるということが本当に苦手なので人をうまく使えなかったり、頼ることができずに自分で自分自身に負荷をかけて自滅することがかなり多かった。そんな感じで自滅してパフォーマンスが落ちたり、いわゆるやらかしをやってしまったことも多々あるが、それでも率直なフィードバックをくれ続けた上長や支えてくれた同じチームのエンジニアたちには本当に感謝しかないです。それのおかげか、慣れてきてからはうまく負荷分散をしたり少し視点を引き上げて、自分がどうなるかより自チームがどうなるかを考える癖がついたのはよかった。なったらそうなったでまた次の壁があったりするんですがそのあたりはメルカリにいる間に解決できず仕舞いなので次の場での宿題としたい。WebDB+Press執筆参加した若干裏話なのかもしれないけど、これはメルカリにいて「あいつ、設計周りうるさいらしい」みたいな感じで誘ってもらえた故に得られた機会でした。楽しかったな、でも執筆は本当に大変でした。Rearchitect2018年に元のチームを離れてからはずっとWebの作り直しチームにcommitしていた。speakerdeck.com今まで取り組んだ仕事の中でぶっちぎりで抽象度が高くて、一番最初のステータスは「今のWebをいい感じのアーキテクチャに作り変えたい」ぐらいの粒度だった。「なるほど?」となるわけで、初期は必死に変数集めをしていた記憶がある。現状のシステムはどうなってるのか作りかけの新システムはあるのか、あるならどういう感じなのか会社のアーキテクチャ方針はどうなのかプロダクトとしての方向性はどうなのかWebチームの未来像はどうなりたいのかビジネスとバランスを取った時のスピード感はどうなのかこんなことを必死に考えてた。考えて問題を整理して解きほぐして分解して、最終的に出てきた「n年後のチーム、1年後のチーム、今の状態」の引き算をして、現実的な戦略に落としていった。この過程が本当に暗中模索だし五里霧中だし、意思決定に迷い続けた記憶がある。迷い続けて周りにいる自分より圧倒的に強いエンジニアたちに相談しまくった。思えば毎日が意思決定の連続で胃に穴が空きそうなことを決め続けていたと思う。そのおかげで技術的な意思決定を一定の品質を担保しながら最速でやること、決めきれない意思決定では未来を見据えて極限までリスクを減らした上で意思決定することができるようになったと思う。2018このあたりの能力は抽象度が高い課題でありながら決定権の大部分を会社が移譲してくれたからこそ身につけられたものだと思う。(私が把握してる範囲では)対外的に発表してませんが、メルカリWebのトップ画面は新しいアーキテクチャで動いています。https://www.mercari.com/jp/たった1ページに1年半かかってしまった(これは私の実力不足)けど、非常に難易度の高い要求を会社の荒波に揉まれながらも世に出すところまでこぎつけられたのは間違いなくチームメンバが優秀だったおかげです。私はなぜかチーム運だけは異常にいいと自負しているのですがこの先、自慢できる最高のチームのうちの1つに今のWebチームは間違いなく入ると思います。僕より強いBackendマンで興味ある人いたら声かけてください。絶対おもしろいと思わせる自信ある。ISUCON9の運営やったこればっかりはタイミングが合わないと参加できない活動なので本当に参加できてよかった。sota1235.hatenablog.comその他いろいろSplathonに参加できたのはよかった、もう参加できないと思うとさみしい収入は引くぐらい上がった、たぶんこの先5年は同じ給料もらえないと思うし、環境も本当によかった。同じ給料、待遇、環境で働ける会社は当分ないだろう、欲しいなら作らないとだめだろうくらいに思ってる障害対応力が異常についた、障害を起こしてしまっている、という裏返しでもあるが自チームでなくともある程度舵取りできるところまで成長できたのは本当によかった上場をリアルタイムで経験できたのはエモかった3年間で露骨に集中力が落ちてきた、年齢に反比例してパフォーマンスが下がらないための工夫を考えないとまずい仕事じゃないけどRoppongi.js立ち上げたりした。復活の噂があるらしいので乞うご期待サービス立ち上げてコード書きまくってそれなりに評価してもらっても俺は弱いという感覚は全然抜けない、もっと強くなりたい...その他Twitterから見つけた微笑ましい思い出たち異国の地で心を落ち着かせるためにtweetしてる様子。2017当時は言えなかったけど、社内賞をもらって実はかなり喜んでた様子。2018有志のファンにより出張の様子がトゥギャられたやつ。togetter.comヘルニアで入院してる図。2018会社の開発合宿で温泉宿行ったのにヘルニア手術直後で温泉入れない図。2018チームメンバーに飲み会でかけられた温かい言葉。2018アイデンティティを確立した様子。次の職場、という切り口で言うと特に決まってないです。副業しながら適当にのんびり過ごす予定です。フリーランスになるのか、というとそういうわけではなくまぁ色々考えてはいるんですが焦って決めずにのんびり考えようという気持ちです。いうタイミングをpublicにすると飲みに行きましょう、とか弊社遊びに来ませんか、みたいなのがたくさん来がち(とか言って来なかったら馬鹿にしてくれ)だと思うんですけど、前述の通り当分はのんびりマイペースに過ごしたいので興味がないものとか知らない人とかからのそういうコミュニケーションはしばらく放置しがちだと思います。決まったらまた雑に報告できると、特にメルカリでお世話になった人にはまたこれ頑張りますと言えたらいいなぁ。一緒に働いてくれた方は内外問わず、本当に3年間お世話になりました!またいつかどこかで。*1:今も変わらない文化と言ったが、昔と比べると規模が大きくなってるので能動的に自分のアウトプットをアピールしないと承認は降りづらくなってると思う。いえ普通にやってたら認めてもらえると思う。10:00近況報告Tweet広告を非表示にするもっと読むコメントを書く2019-12-312019年振り返り去年sota1235.hatenablog.com見返すと何も達成してなくて笑ったサマリライブ行きまくったISUCON9の運営に参加したMP減って休職した登壇しなかった副業始めたライブ行きまくった昔から音楽が好きで若い頃の一時期はライブハウスに通う日々を過ごしてたのだけど社会人になってからはあまり行ってなかった。時間が経つにつれて名前を知ってるバンドが解散したりメンバーチェンジしたり、亡くなってしまうことが増えてきた。去年はそういうのが多かったので年初に「人生で一度は見たいバンドのライブに全部行く」という目標を立てた。結果、一回見て満足するどころかもう一回見たくなるし対バンやフェスで見つけた新しい推しのライブにも行き始めてしまって芋づる式にライブ本数が増えた。scrapbox.io上に全部書いたが実に47本のライブに参加した。来年もたぶんいっぱい行く。ISUCON9運営に参加したsota1235.hatenablog.com学びが深かった。MP減って休職した9-11月の間、MPが減って休職してました。邪推されるのもめんどくさいんであんまopenにしてなかったんですが今は元気に復帰してるのでお気づかいなく...!意外と休んでも人生どうにでもなるんで死にかけてる人はみんな休んでほしいなと思ってます。登壇しなかった去年は割とカンファレンスや勉強会で登壇する機会が多かったんですが今年は仙台PHPカンファレンスの一本だけでした。理由として発表準備に時間をかけるよりインプットに時間を割きたかったのと、単純に飽きもなくはないです。今年それなりにいろいろ勉強できた気がするので来年はちょいちょい話したいですね。副業始めた以前も副業をしてたことはあったのですが、今年は技術アドバイザーなるものを副業として始めました。開発者としてでなく、アドバイザーとして副業をするのは初めてなので結構不安もあるのですが今の所それなりにうまく行っているんじゃないかなぁと思います(少なくとも頂いてる対価と同等以上の価値を出せてると信じたい)。アドバイザーとなると基本的には自分が持つ知識やノウハウを価値として提供し続けることになるのですが、提供する一方で私自身も学びになることがとても多く、楽しくやれています。このあたりも機会があれば言語化したい。社会人になって5年経ち少々人生に飽きが出てきた感覚があるのでaikoのライブと同じくらい熱中してやれる何か(仕事でも仕事でなくても)を見つけられたらいいかなぁと漠然と思ってます。今年もいっぱい迷惑をかけてみなさんに助けられた年でした、来年も引き続き助けてくれたら嬉しいです。ポエムISUCON9に参加した方、本戦までお疲れさまでした!今年のISUCON9では運営として予選の作問に携わり、フロントエンド周りを担当しました。その際に得た知見や実装なりの話を雑に書こうと思います。話で出てくるソースコードは全てここにあります。github.comExcuse個人としての雑記です本業フロントエンドエンジニアではないので詰めが甘い部分がかなり多いです本業フロントエンドエンジニアからのマサカリ待ってますISUCON運営として作るフロントエンド、という視点で書いていきます願わくば未来のISUCONフロントエンド担当者に届けあとは講評や解説は公式Blogで出してるのでそのあたりをぜひ読んでください!isucon.netあとはBackendやベンチマーカーの実装に関しては@catatsuyさんの記事とGitHubのコードを合わせて読むことをオススメします。medium.com私とISUCON私自身のISUCONとの関わりはこんな感じです。ISUCON5から毎年参加している毎年予選落ちで地団駄を踏む去年は覚悟を持って望んだものの予選落ち、ビール禁止を決意するといった感じでした。今年ももちろん再挑戦、悲願の予選突破を目指そうと思っていたのですが自分の会社に作問が回ってきたのでこんなチャンスなかなか無いだろうと思い運営として参加しました。Application(SPA)を採用しました。私自身、以前にSPAを作ってからかなり年月が経ってしまっていたのと、今回は多少小回りが効かないとしても動くことが最優先だったのでcreate-react-appを利用しました。丁寧にテストを書く余裕はないだろうと想像できていたのでなるべくエンバグしないようTypeScriptも導入しています。create-react-app.devcreate-react-appを最後に触ったのは2年ほど前だったのですが、その時よりもかなり使いやすくなっていて最高でした。reload、transpile等々動くのは楽だしソースコードと設定周りが強く依存し合うこともないので個人的に重視している捨てやすさも十二分にあるなという印象です。UIを導入しています。他に使ってるものは興味あればpackage.jsonを覗いてください。以下の点を方針として立てました。Backendのテンプレート移植の負担をなるべく無くす競技者がアプリケーションを理解しやすいフロントエンドを作る機能が理解しやすい壊れたときに原因がわかりやすいフロントエンドでデバッグしたいときにやりやすいBackendのテンプレート移植の負担をなるべく無くすISUCONでは例年、多くの参加者が楽しめるよう複数の言語実装を提供しています。言い換えるとブラウザで開くと全く同じに見えるアプリケーションを複数種類の言語で実装するということです。その際、コストとして大きいのがHTMLレンダリング周りの移植です。Backend側での実装移植はよほど言語に依存した実装にしていなければ難しくないですが、テンプレートエンジンは言語やライブラリによって機能の差異が多く結構大変です(※過去の運営をやったわけではないですが、一緒に運営をした人の体験談から想像するのは難くなかった)。基本、Backend側はHTTPのAPIを提供するのみ、HTMLのレンダリングはブラウザ上でする、という方針になりました。競技者が機能を理解しやすい今回のアプリケーションは一言で言うならば椅子のフリマアプリでした。近年は様々なフリマアプリが使われるように身近に感じられるようになりましたが、とはいえ競技者全員が直感的に機能を理解できるとは限りません。今回は配送機能や決済機能周りはAPIのI/Fや仕様書のみから全てを読み解くのは容易ではなかったので、フロントエンドの画面を触ることでそれぞれのAPIの存在意義や機能を理解できるよう心がけました。このあたりは以下のissueで議論しました。興味があれば覗いてみてください。github.com壊れたときに原因がわかりやすい参加したことがある方はよくわかると思いますが、ISUCONでは初見のアプリケーションを壊さずにドラスティックに書き換えていく必要があります。その過程で起こる問題として意図しないエンバグやその原因調査です。フロントエンドではこのあたりにすぐに気付けるようにし、原因調査のヒントとなるようにすべきです。それにあたり以下のような方針で実装しました。Tool等を見ずに知ってもらうためにこのような構成にしています。RouterをReduxにつなぎこむためにsupasate/connected-react-routerを利用しました。Routerでページ遷移が発生した際に@@router/LOCATION_CHANGEというActionを発火させます。このActionを見ることで例えば「商品ページから別ページへ遷移したら商品ページのstateを初期状態に戻す」といったことが可能になります。私のState管理の実装は以下のようになっていました。Routerのページ遷移アクションが発生したらデータとローディングステータスのstateをリセットしかし、このActionは同じページ間を遷移する場合にも発火してしまいます。Componentはレンダリングされない(既にされている)のでデータfetchは走らないというバグが発生しました。対応策として、@@router/LOCATION_CHANGEが発火したら遷移前のpathと遷移後のpathを比較し、違う場合のみカスタムActionを発火するmiddlewareを実装。それをもとにState制御することで解決しました。GitHub同一Routeで異なるpathへの遷移時のState管理がうまくいかない先程の実装で十分かと思いきや、まだカバーできないパターンがあります。/items/:item_idというRouteがある際に、/items/8から/items/9へ遷移したパターンです。ComponentのgetDerivedStateFromPropsメソッドを利用しました。}上記のnextProps.match.params.user_idには例えば/users/:user_idというRouteにアクセスした際に:user_idに入る任意の値が入ります。これにより同じRoute間の遷移、かつ違うpathでも正常に動作するようにできます。Colorやfont-size等をglobalで統一して管理したいときに便利なTheme機能があります。v4-3-3.material-ui.com今回も色の調整等でこの機能を利用していたのですが、特定のページの一部コンポーネントにスタイルが適用されないバグがありました。themeを同じテーマを使って行うというハックでバグを回避しました。thanks今回、きちんとSPAを作り込むにあたり主にデータローディング周りの設計に結構悩まされたのですが、私のggり方が悪いのか体系的に解説したいいドキュメントや記事を見つけられませんでした。自分で車輪を再発明するしかないかと諦めかけましたが、藁にもすがる気持ちで@hiroppyのソースコードを読みにいったら抱えてた疑問や迷いに対する答えが全てありました。書いたコード読みに行ったら一発で解決。2019最後にISUCON9予選に参加して競技を楽しんでくれた皆様、メルカリの出題チームのメンバー、そして運営の皆様、本当にありがとうございました!来年は(きっと)参加者として予選参加して本戦に行きたいと思います。ポエムISUCON8に出場して予選で散りました。isucon.net@kazeburoさんと@masartzさんとそたぶろるっつという名前のチームで一緒に出場しました。後半、少し追い上げるも予選突破ラインに遠く及ばず...。fail地獄がつらかった。やったこと私は主にアプリケーションを見た。言語はNode.jsを選択しました。去年に引き続き凡ミスが多かったローカルでアプリ環境を作るという選択をしなかったので本番デバッグすることが多く、効率が悪かった他チームが「30分で作れなかったらやらない」という基準で取り組んで、作れたと言ってて時間で区切るのは賢いと思ったTypeScript実装だったので実装が堅牢だったかというと必要最低限の型付けしかなかったので思い切って最初20分くらい、コールドリーディング&型付けに投資もありかとおもった特にSQLの返り値周りはなんの値がどう加工されてるのか読み解くのに苦労したやろうと思ってやらなかったがInspector立ち上げてデバッグするのもありだったpm2立ち上げた後から設定入れるのが面倒でやらなかったがやるべきだった。判断ミス後半、ほとんど何もできなかった予約/キャンセルエンドポイントとずっとにらめっこしてたがどうすれば改善できるのかわからなかったわからないならわからないで割り切って、きな臭いSQLを丁寧にチューニングしていくとかできることはあったはず正直、failの絶望感に打ちひしがれてる感が強かった(本戦出場チームもこのあたりは同じだったらしい)pm2の使い方はもっと調べておくべきだったinspector付きで立ち上げるとかloggingとかこのあたりは仕事で触る機会もある可能性あるしISUCON問題の復習で丁寧に触っておくまとめ仮にもハイトラフィックなアプリのBackendを1年半やっての敗北なので強い気持ちで1年間修行します。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。