コードを書く隙間を見つけて生きていく技術/Findy 思考の現在地

先達エンジニアに学ぶ 思考の現在地 Online Conference
の発表資料です
https://findy-code.io/events/v7KebEabaBDzh?fr=event_20240416

Transcript

1. コードを書く隙間を見つけて生きていく技術 先達エンジニアに学ぶ 思考の現在地 Online Conference 2024-04-16 @fujiwara 藤原俊一郎
2. 自己紹介 @fujiwara (X/Twitter, GitHub, Bluesky) 面白法人カヤック SREチーム ITエンジニア歴25年(今年49歳) ISUCON 優勝 4回 ISUCON 運営(出題) 4回
4. OSS 代表作 ecspresso 730 Amazon ECS デプロイツール github.com/kayac/ecspresso 2017〜 ECSサービスとタスク定義の管理(IaC)/デプロイを行うツール lambroll 309 AWS Lambda デプロイツール github.com/fujiwara/lambroll 2019〜 Lambda関数(とFunctionURL)の管理(IaC)/デプロイを行うツール 今ではどちらも国内で多くの企業で使われているツールに成長したが 元々は自分用に(仕事で)使うために作ったもの
5. みなさん、コードを書くのは好きですか?
6. コードを書いていたら大人になっていた 1985年(10歳) MSXを買ってもらう 中学・高校 マイコンBASICマガジン世代 打ち込んだり投稿したり 1994年 大学進学 情報工学科へ 1998年(23歳) 就職してWeb業界へ 当時はインフラもバックエンドもフロントも区別がなかったのでなんでも書いた 2011年(35歳) カヤックに転職(2社目) この時点で25年、物心ついてからコードを書いてない時期はほぼない 2014年(49歳) 今でもほぼ毎日なんらかのコードは書いている このまま老人になりたい
7. 大人になっても好きなコードを書き続けるために
8. 大人になっても好きなコードを書き続けるために 「ITエンジニア35歳定年説」は過去の話というか俗説 書ける仕事がある場所にいて、能力があれば書く仕事はある 「場所」…これは探しましょう 「能力」これをどう鍛えるか
9. SRE という仕事 SRE = Site Reliability Engineering (サイトを安定させるためにはなんでもやる) なんでも = インフラの構築構成、CI/CD、監視や可観測性 DBのクエリ改善、チューニング、アプリケーションコードの問題調査、レビュー 各種EoL対応、オンコール… つい細切れ・リアクティブな仕事になりがち リアクティブとプロアクティブを適切にバランスを取りたい リアクティブ = 自分じゃないところから降ってくる仕事 プロアクティブ = 自分が主導権を持てる仕事
10. 「組織の信頼性のマインドセット:Google SRE の知見」より引用^1 Google での観察によれば、組織の信頼性には 5 つの基本的段階があります。それらは 不認識、受動的、積極的、戦略的、先見的という典型的組織モデルに基づいています 　　不認識→受動的→積極的→ 戦略的→先見的 これは『信頼性』の話だが、そうでない場面でも使える考え方では
11. 自分がオーナーシップを持てる場所をさがす どうしても既存のソフトウェアを単に組み合わせるだけでは上手くできない (できなくはないが無理が生じる)場面はある → コードは書かざるを得ない そこで…… 「その場限りのコードを書き捨てて仕事を済ませよう」(リアクティブ) よりも 「他のプロダクトでも同じ悩みが生まれるかも」 →「 同じ悩みを汎用的に解決できるものを作り出そう」(プロアクティブ) こういうチャンスを生かしたい
12. たとえば HashiCorp Terraform, Vault, Consul, Vagrant, Packer など大物ソフトウェアは有名だが それらに組み込まれている小さい部品も単体OSSになっている go-retryablehttp 自動リトライとexponential backoff付きHTTPクライアント golang-lru インメモリのLRU Cacheライブラリ go-version SemVerの解析ライブラリ 小さくて使い勝手が良い道具を自分らで作って公開している
13. コードを書くか書かないか 「コードはできるだけ書かない方がよい」 それはそう。書いたものは資産にも負債にもなる 「できるだけ既存のツールの組み合わせでなんとかしたい」 それでよい運用ができるならもちろんOK 「このツールだけで全部完結させたい」 (趣味なら好きにすればいいけど仕事では) ひとつのツールに拘りすぎないほうがよい 適切な道具を適切に使う、必要なら道具も自分で作るのがプロフェッショナル
14. 隙間家具OSS マネージドサービス、コンポーネントだけでは不便があるとき それらの隙間を埋めて便利にするもの マネージドサービスが時間とともに成長して不要になったら取り外す(ことも念頭に)
15. Glueではなく隙間家具(単体のソフトウェア)にする理由 Glueなコードはプロジェクト固有の事情に密結合しがち あるプロジェクトのリポジトリの中に置かれる コードの責任分界点が曖昧 他のプロジェクトにコピペ(fork)されがち → 固有の事情(コピペ先の事情)によって改変されてだんだん別物に あるプロジェクトで行われたバグ修正が行き渡らない
16. 単体ソフトウェア/ライブラリとしてOSSにする 各プロジェクトに依存するコードは入らない(入れられない) 一般的なユースケースに対応できるようにインタフェースが整理される プロジェクト固有の事情と一般的な事情を分離して設計と実装をするようになる bugfixはバージョンアップで適用できる ノウハウも統一できる 複数プロジェクトの運用が楽になる
17. ただし 不適切な 境界を持つ / 実装 / 抽象化をした ソフトウェアはすぐに負債化する わざわざ作るなら上手く作る必要がある どうしたら上手く作れるか…
18. https://speakerdeck.com/twada/quality-and-speed-aws-dev-day-2023-tokyo-edition
19. 自分で設計したシステムをメンテする経験 システムをシンプルに作ってシンプルに保つ力は経験で得るしかない ひとつのプロダクトを… 1. 設計して 2. 実装して 3. テストして 4. リリースして 5. 導入して / 既存プロダクトと組み合わせて 6. issue対応やバグfixをして 7. (寿命を終えるところまで) 面倒を見る 大きなシステム、ビジネスのメインプロジェクトでこの経験を積むのは難しい
20. 『自分の庭』を作る 既存のソフトウェアの組み合わせだけではうまくできない時に作る 「隙間家具OSS」は『自分の庭』 小さいのでいくつも作れる (練習になる) なくても何とかなるけどあると便利 (失敗したら使わない、戻す) 成功してもいつか取り外すことも念頭に作る (そのための設計を考える) 使い始めたらメンテはしていく (要望の取捨選択も含めて) コードはできれば書かない方がいい でも、鍛えておかないといざという時にうまく書けない
21. いろいろなコードを書く経験は無駄にならない
22. ISUCON 11 (2021年)
23. ISUCON 11 本選 「学内システム」がテーマ Zipをオンデマンドで生成してダウンロードする機能がある 初期実装は zip コマンド呼び出し (一般的に)外部コマンドを呼ぶのは効率が悪いため、言語内で実装したほうがよい Goでzip生成するコード…「 lambrollで書いたことあるわ」 10分で書いたコードで一発通過 (ただし、このzip自体は競技全体のスコア要素の1/10ぐらい?)
24. 圧縮zipだったら負けていたらしい(後日判明) zip.Store (非圧縮)を指定してCPUコストを削減したのがスコアに効いていた
25. ライフステージの変化 20代後半〜30代前半 結婚はしたが子供がいなかった 夜は好きにコードを書いていた 平日夜のイベントや勉強会にも自由に参加 30代後半 子供が生まれてから一変 5年ぐらい、自宅ではほとんどコードを書けない時期 平日の勉強会は参加できない、土日は家族
26. Year GitHub Events Graph 2012 115 息子誕生 2013 151 2014 495 2015 393 寝かしつけに消耗 毎日寝かしつけに2時間掛かるので自宅では何もできない時期
27. Year GitHub Events Graph 2016 392 2017 639 ecspresso 開発開始(11月) 2018 590 2019 732 息子小学校入学 イベント・勉強会参加 休日は年2回だけ(YAPC, ISUCON) 平日夜、少しコードが書けるようになってきた
28. Year GitHub Events Graph 2020 1,070 コロナ禍 2021 1,043 2022 1,593 2023 1,459 朝 のため平日夜は早寝する(のでコードは書かない) コロナ禍で外に飲みに行かなくなった → 金曜夜に しながらOSS開発するように 土日も多少は余裕ができるように
29. 最近の public contributions public repoのみでこんなかんじ 平日は日中(仕事中)コンスタントに 最下段=土曜日(実際は金曜深夜) 飲みながらOSS活動をする習慣 土日はほぼなし いろいろやることがある
30. 仕事中に(好きな)コードを書く なんだかんだで仕事している時間が一番長い であれば、仕事中に好きなコードを書けるのが一番効果的 何かを構築・改善・運用するのが好き → 仕事中に発生したちょっとした不満を、立ち止まって考える 「これ単体のツール・ライブラリを作ったら解決できるかな…?」 余暇時間が使えなくても、(うまくすれば)仕事中に技術力の維持も向上もできる
31. fujiwara-ware いろいろ 全部 「仕事中に困ったこと」 を解決するために書いた(ので半分仕事、半分趣味) cfft CloudFront FunctionsのテストとCloudFront KVSの操作を便利にするやつ ecspresso Amazon ECSデプロイツール lambroll AWS Lambdaデプロイツール ecsta Amazon ECSのタスク操作を便利にできるツール tracer ECSタスクの一生を全部まとめてみるやつ
32. ridge LambdaのFunctionURL/ALB/API Gateway処理をGoの標準httpモジュールで書ける lamblocal GoでLambdaでもCLIでも動くような1つのバイナリを作るのに便利なユーティリティ tfstate-lookup Terraform tfstateを取得してparseして中身を見るCLI/ライブラリ go-amzn-oidc Amazon ALB OIDC認証で渡されるJWTを検証する ecrm Amazon ECRを安全に掃除してくれる riex 買っている/もうすぐ期限が切れそうなReserved Instanceを表示してくれる
33. 伝播するミームと伝わっていくもの 『隙間家具OSS』(自分が作った用語) 初出 吉祥寺.pm 16(2018/11), AWS Dev Day 2019でも発表 (当然)それまで誰も使っていなかった用語だが、かれこれ5年も言い続けていると…
34. 地味に広まってきたかも…?
35. 地味に広まってきたかも…? クラウドアプリケーション 10の設計原則 「Azureアプリケーションアーキテクチャガイド」から学ぶ普遍的な原理原則 https://book.impress.co.jp/books/1122101082
36. 自分が育ててもらった ◦◦-ware 沢山あるけど、たとえば kazuho-ware 奥一穂(@kazuho)さん Q4M, h2o, Starlet, Server-Stater... kazeburo-ware 長野雅広(@kazeburo)さん GrowthForecast, Proclet, Log::Minimal... djb-ware Daniel J. Bernstein.さん qmail, daemontools, djbdns, setlock... これらを実際に使って仕事をして、思想、設計、実装… いろいろな面で育ててもらった感がある
37. Webサービスやゲームの寿命は短い よほどヒットしない限り、数年で寿命が尽きるものが多い (そもそも目的からして短命なサイトなども多い) クローズしてしまうとスクリーンショットぐらいしか残らないことも多い エンジニア人生の方が全然長い エンジニアの人達になんらかのミームを残せたら 個々の仕事よりも世の中に何か残せるんじゃないか 隙間家具OSS、ISUCON……
38. 歳をとってからでもパフォーマンスが伸びる 2019年 健康診断の結果がヤバいのでダイエットを始める ウォーキングとレコーディングダイエット 2020年 1年で10kg体重減。ウォーキングが物足りなくなってランニングを始めた (それまで45年間、学校の体育以外の運動経験ほぼなし) 楽しくなってハマった
39. 2020/09 ランニングを始める 2021/12 ハーフマラソン 1:44:51 2022/12 フルマラソン 3:34:58 2023/11 フルマラソン 3:28:33 (市民ランナーの上位10%程度) いまでも月間200km、週4回程度
40. 歳をとってからでもパフォーマンスが伸びる (よく言われることですが)人生で今が一番若い これまで運動経験0でも、ちゃんと練習したら3年で上位10%までいけた 理論を本で学ぶ→実践→タイムや各種数値で効果検証 を繰り返す エンジニアリングと同じ要素がある ランニングはメトリクス/モニタリングマニアにお勧め
41. まとめ コードを書くのが好きなので、ずっと書き続けられる仕事をしたい プライベートな時間は有限(特に家族が増えると貴重)なので 日々の仕事でコードを書きつつ技術力を伸ばしていける場所と方法を探す 自分は先達からの影響を受けて成り立っている、あとにも何かを残せたらいいな 歳を取ってからでもパフォーマンスは伸びます