前回
半年ごとに書いていたのに1年開いてしまった。てへ。
一言で言うと、この1年は次の飛躍のための助走期間だった、と評価している。するしかないとも言う。
まずアウトプットベースで振り返る。
Blog
この1年で書いた会社ブログはわずか3本。
Talk
意外と多い。8本。
How to add a new lint to tflint-ruleset-aws · GitHub
何をしていたのか
9月までは前1年と変わらず Lead Software Engineer。10月からは Engineering Manager になった。
コードで問題を解決すること
1月 - 3月の間は Prometheus Exporter を中心に、Go をひたすら書いていた。Go に限らず、コードで問題を解決すること、をひたすらやっていた。
もともとコードを書くことが好きで好きでたまらないというタイプではなく、業務上でも機会が多いとも言えない状況で、「必要な時に高いクオリティでコードを書く」ためにはコードを書くしかない。（自明）
いろいろ書いたが、今でも役に立っているものはいくらかあるし、自分にとってコーディングは「苦手なもの」から、書けば書けるな、という感覚を持てる程度にはなった。（得意とは言っていない）
毎日書く、みたいなことは多分難しいが、それでも今後も定期的に、少なくとも1年に1度は最新技術のキャッチアップも兼ねて、集中してコードを書く期間というものは設けていきたいと思う。
aws config complience 違反のものを metric として送ることができるので、dashboard で眺めたりアラート設定したりできるようになった。MFA 違反のひとを捕らえるのに今でも役に立っている。
metrics-driven / fact-based で問題に向き合うこと
上記のネタに関連するが、Quipper のバリューの1つであり、あらゆるものを metrics 化してコントローラブルにして、事実ベースで問題に向き合うということを、それができていないところにコードを書き技術で解決する、というアプローチが幾分かできたと思う。
Platform を Product として考えること
6月ぐらいから Platform as Product ということについて考えた。考えただけで特に大きな成果が出たとかではないんだが（Output として登壇はした）
自分たちがやっている仕事、作っている Platform が何のために、誰のためにあるのか、その接続が少なくとも自分の中で明確になったことは大きかったように思う。
この時学んだ Product Management は今でもかなり活きている。また、Technical Product Manager との会話も増え、業務もより円滑に進むことができたと思う。
技術戦略を考えること
4月から立ち上がった技術戦略グループの、DevOps Working Group の Lead をやったことで、DevOps - SRE が実現する手段の1つである、デリバリーの高速化とサービス信頼性をコントローラブルにする取り組みを開発チームと密に連携して課題に向き合うことができた。
この活動によって、プロダクト開発部全体として、DevOps という観点でどういう部分に課題があるのかをより解像度高く知ることができ、かつ SRE Team としての優先順位づけのインプットにもなった。
DX Criteria の実施もその一環だった。
チームをより Sustainable にすること
としてのビジョン・ミッション・バリューは EM の yuya-takeyama が整えたのは大きかった。
それ以外にも、特に4月以降は新メンバーの加入が（嬉しいことに）多く、人が変わっても、むしろ人が入ることでより強くなるチームに進化してきているように思う。
具体的には Retrospective。前からも隔週で行ってきたが、単に書いてしゃべるだけ、だったものから、振り返り自体の振り返りを取り入れ、型に囚われることなく、よさそうな提案はまずはやってみて、ダメならやめる、みたいなことを気持ちよくやることができている。かける時間に対して得られるベネフィットは当初に比べてかなり大きくなってきている。
Working Agreement。働く上でのゆるい合意のようなものを数ヶ月に一度やっている。これにより期待値を擦り合わせることができるし、新メンバーにとってもカルチャーを掴むのによりやりやすくなるし、多様な価値観を受け入れられる土壌になっていると思う。
その他 Daily Standup, Alert Handling, Cost check などルーチンワークをチームでまわすということは1年前、2年前から比べるとはるかに良くなった。これは提案、実行、フィードバックをくれるメンバーのおかげである。感謝。
(Engineering Manager として) 期待値を合わせること
わずか3ヶ月間。やったこととしてはいろいろあるが、重点をおいたのはこの点かなと思う。かなり丁寧にやったつもりだ。
これまで所属していたメンバーで仕事ぶりや個人としての信頼関係はそれなりにあるとはいえ、マネージャが変わるというのはそれなりに身構えてしまうものだと思う。
Engineering Manager README を書いて、何をどれぐらいするのか。しないのか。期待してもらうのか、メンバーに何を期待するのか、ということを書いて、個別に話した。
ミッション設定は本人の Will をもとに、身につけていってもらいたい能力や現状の課題という背景と合わせて言語化し、さらにそれをツリー形式で可視化することでメンバー同士の期待値も明らかにした。
今後はメンバー間の期待値をよりわかるようにする場を設けたり、マネージャへのフィードバックをもらえる仕組みなんかも作っていきたいと思う。
今後やること
EM という成果は3ヶ月という短いスパンで出るものではなく、半年でも多分短い。成果がないことに焦る必要はないが、それでも時間がかかるからこそ種まきはなるべく早くやったほうがいい。
Product Security Engineering Team の立ち上げ
現在 Job Description を書いてコードテストを仕上げているところ。
Product Security Engineer とは、SRE が Reliability を Engineering で Product Team に実装していくのと同じように、Security を Engineering で組織に実装していくポジション。
横断組織であるが、横断の Security 課題を解決したり、単にそれっぽいセキュリティ施策を導入するのではない。
1月中には JD 公開予定です。
プロダクト開発組織をより Sustainable にする
組織開発ともいう。組織課題を解決するともいう。それで目指したいことは Sustainable にするってことかなと。
そのために、コーポレートエンジニアリング的なツールを（セキュリティ的な観点入りで）整備したり、エンジニアのキャリアパスを整備したり、EM 自体が育成する・される環境を作ったり、ミッションマネジメントをより洗練させたりしていく。
ビジネスにエンジニアリングで貢献する
去年も掲げていたけど、できていなかったというか、助走期間だった。
プロダクト開発部がいくら SLO を定めてみても、それにより機能開発と非機能開発の優先度が「数値」によって、異なる職種を通じて話し合い、変更されうる状態になっていない。
そこを変えに行く。
そのために、技術戦略グループのマネジメント/リードをして、技術的負債をコントロール化に置く活動を支援したり、自己診断能力を開発できるようにして現状把握できるようにしたりして、機能開発 - ビジネス開発と同じだけ、非機能開発や技術的負債解消活動にも説明責任が果たせるようにしていく。同じものを見て、異なるストーリーを持つ人々と、1つの目的を達成できるようにする。そのために組織も技術も両方見て世界を変えていく。
今のところは、これが無理だと諦めた時に転職を考えるのかなと思ってます。これをやれると思ってるうちはがんばります。
おわりに
楽しくやりましょう。今年もよろしくおねがいします。
