ツナワタリマイライフ

日常ネタから技術ネタ、音楽ネタまで何でも書きます。

入社してから2年半

12/20 で2年半経った。

前回

blog.chaspy.me

なんかもうまた全然違うところまで来てしまった感があるし、はるか昔に感じるな。成長しているとも言う。

相変わらず挑戦と失敗をさせてくれる組織とマネージャーの @yuya-takeyama に感謝している。

振り返り

Platform Development の Lead

Application Platform, つまり Kubernetes のことだが、それの重要度は非常に高いし、SRE Team はこれをビジネス要求や開発者のため、もしくはサービスの信頼性のために適切に進化させていく必要がある。

特に詳しい @d-kuro に力を借りながら、Kubernetes 関連のことを話す Weekly Meeting をはじめて、Roadmap を引き、自分自身で今後の進化の重要な一歩と言える EKS への移行を実現しきった。

quipper.hatenablog.com

また、この延長でこのとき感じた課題を解決するために Cluster の Canary Switch も実現。総じてクラスタ切り替えはかなり楽になった。

quipper.hatenablog.com

この分野に強い知見を持つ @int128 が入社するまでには移行をやりきるぞ!という気持ちで、(実際は入社前には間に合わなかったけど)やりきった。影響範囲も大きく、技術的な不確実性も高かったプロジェクトだった。特に自分は kube-aws で管理していた自体の Kubernetes Cluster 切り替えを1度もやったことなかったので時間かかったり失敗したことも多くあったが、学習しながら完遂できたのはよかった。

Global Cluster の切り替えを行ったあと、Japan の分は @int128 にやってもらい、オンボーディングが終わったあとは彼にこの分野の Lead をおまかせした。

その後は System Component の GitOps 化、それに伴う renovate による component upgrade の簡易化、Nginx Ingress の部分導入など凄まじい進化を遂げている。

quipper.hatenablog.com

EKS は本当に"第一歩"だったんだなぁ、と終わってみてようやく思う。当時は kube-aws のサポートが追いつかず Kubernetes が EOL になってしまうから、と後ろ向きなモチベーションだったが、やはりやってみてわかることはたくさんあるね。

Infrastructure / Service Cost Management の Lead

あんまり大きな声では言えないが、Infrastructure / Service Cost に関してこれまであまり"ちゃんと"やれてなかった。

夏頃に @motobrew からこの Cost に関してヤバいのではと警笛をもらってから、できることから少しずつ実現している。

quipper.hatenablog.com

まだ道半ばで、適切な目標を持ち、分析をし、定量的に振り返る体制作りはこれからではあるが、Monthly で振り返り、着実に前に進めていると思う。

Global Development Team との関係強化

これはもう本当に悔しいし悲しいしつらいが、Global で大きい障害を起こしてしまった。何がつらいって「わかっていた」のに何もできなかったことだ。まぁそれは僕個人が悪いわけではないが、数日は落ち込んだ。

それをきっかけに、Global Developer との Meeting の機会がとても増えた。

また、それとは別に、当時は「やることが多すぎて優先度がつけられない」ということに悩んでいた。そこで彼ら彼女らが何が課題かを吸い上げるために、あるいは情報が流れてきやすくなるための関係構築のために、Global Developer との 1on1 を行った。

「定期試験」によるスパイクアクセスに対応するためにコンポーネントを開発し、Engineering で解決できたのも、そもそもお互いで会話して、関係性ができていたからこそだと思うので、ずいぶん前に進んだし、自分としても良い経験になった。そもそものきっかけが Business Owner の @naotori と話したことだったりもするので、コミュニケーションによって問題を解決できた。

quipper.hatenablog.com

ブログ記事化はしてないが、12月には Android Developer と一緒に Locust による Loadtest を実施した。望んだ結果が手に入ったわけでもないし、コミュニケーションの課題は依然残るものの、問題の質が変化したというか、前だったらお願いすらされなかっただろうし、頼ってもらえるようになっただけ進歩かなぁなんて呑気に考えている。

いずれにせよ着実に前には進んでいる実感はある。まだまだ道半ばなので継続して関係作りはしていきたい。

Team / Project Lead

まぁ上でいろいろ Lead したと書いてはいるんだが、5月に Lead Software Engineer のジョブタイトルがつき、Team / Project の Lead をしている。主にコミュニケーションのデザインやファシリテーションをしたり、Retrospective であがってきた Problem に対する Try を積極的に取ったりなんたりで貢献できていると思う。

次の半年

ちょっと今回は"意識"/"心意気"みたいなことを宣言してみる。

レバレッジの効く仕事をする

ちょっと抽象的ではあるが、やる仕事をしっかり見極めたい。というのも、本当にやること、やれることは無限にあるし、仕事の難易度もかなり難しくなってきている。Team や Project を Lead しながら Individual Contributor としても貢献し続けるためには、そのインパクトを最大化するためにどういった投資をするかという意識を常に持たないと、(自分が)疲弊したりチームに混乱を招きかねない。

本当にやるのか、なぜやるのか、どうやるのか、こういったことを今まで以上に見極めたい。

また、自分が得意としているコミュニケーションによる問題解決能力を特に存分に活かして、Japan / Global 両方の組織に貢献したい。

成果にこだわる

これはこれまでも意識をしていたことだけど、とにかく成果を出すこと。話はそれからだということ。1つ前のことにも関連するが、それで世界がどう変わったのか、ということを常に意識すること。かけた投資に対してインパクトを最大化すること。そのためにエンジニアリングの力を存分に活かすこと。これに今まで以上にこだわり続けたい。

クオリティにこだわる

自分に明確に足りてないことでいえば Software Engineering ... Programming による課題解決の部分である。お前それが仕事だろと毎年ずっと突っ込んでいるが、事実そうだから仕方がない。

やった仕事を「終わらせる」ことも大事だが、Delivery と Quarity を両立してこそ Professional だと思う。ちゃんとクオリティを出すことを目指したい。このあたりは模範的な同僚が多くいる幸せな環境なので、見習いながら食らいついていきたい。

Global Product Team に貢献する

引き続き SRE としては Global も担当範囲である。また、Global Product Development において Site Relaiblity の重要性は相対的にも増してきている。Site Reliability Engineering の実現のためにはコミュニケーション能力が必要不可欠である。引き続き関係性を構築するとともに、英語でガンガンコミュニケーションを取って、チームと、世界を変えていく。"世界の果てまで学びを届ける”ために、貢献できるポジションにいるのでしっかりやる。

ビジネスを理解し、エンジニアリングでビジネスに貢献する

成果にこだわることにも関係するが、それがどのようにビジネス価値を生むのかを常に考える。そしてそのためにはビジネスを理解する必要がある。もちろんコストも関係する。インフラコスト、ビジネスインパクトを考え、ビジネスを前に進められるエンジニアリングを行いたい。そのためにステークホルダーとのコミュニケーションは引き続きやっていきたい。

おわりに

^の心意気を実現するためには英語とか技術とかあれこれいるので、それについていけるようにやっていく。

おしまい。