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

Slide 1

Slide 1 text

コードを書く隙間を見つけて生きていく技術先達エンジニアに学ぶ思考の現在地 Online Conference 2024-04-16 @fujiwara 藤原俊一郎

Slide 2

Slide 2 text

自己紹介 @fujiwara (X/Twitter, GitHub, Bluesky) 面白法人カヤック SREチーム ITエンジニア歴25年(今年49歳) ISUCON 優勝 4回 ISUCON 運営(出題) 4回

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

OSS 代表作 ecspresso 730 Amazon ECS デプロイツール github.com/kayac/ecspresso 2017〜 ECSサービスとタスク定義の管理(IaC)/デプロイを行うツール lambroll 309 AWS Lambda デプロイツール github.com/fujiwara/lambroll 2019〜 Lambda関数(とFunctionURL)の管理(IaC)/デプロイを行うツール今ではどちらも国内で多くの企業で使われているツールに成長したが元々は自分用に(仕事で)使うために作ったもの

Slide 5

Slide 5 text

みなさん、コードを書くのは好きですか?

Slide 6

Slide 6 text

コードを書いていたら大人になっていた 1985年(10歳) MSXを買ってもらう中学・高校マイコンBASICマガジン世代打ち込んだり投稿したり 1994年大学進学情報工学科へ 1998年(23歳) 就職してWeb業界へ当時はインフラもバックエンドもフロントも区別がなかったのでなんでも書いた 2011年(35歳) カヤックに転職(2社目) この時点で25年、物心ついてからコードを書いてない時期はほぼない 2014年(49歳) 今でもほぼ毎日なんらかのコードは書いているこのまま老人になりたい

Slide 7

Slide 7 text

大人になっても好きなコードを書き続けるために

Slide 8

Slide 8 text

大人になっても好きなコードを書き続けるために「ITエンジニア35歳定年説」は過去の話というか俗説書ける仕事がある場所にいて、能力があれば書く仕事はある「場所」…これは探しましょう「能力」これをどう鍛えるか

Slide 9

Slide 9 text

SRE という仕事 SRE = Site Reliability Engineering (サイトを安定させるためにはなんでもやる) なんでも = インフラの構築構成、CI/CD、監視や可観測性 DBのクエリ改善、チューニング、アプリケーションコードの問題調査、レビュー各種EoL対応、オンコール… つい細切れ・リアクティブな仕事になりがちリアクティブとプロアクティブを適切にバランスを取りたいリアクティブ = 自分じゃないところから降ってくる仕事プロアクティブ = 自分が主導権を持てる仕事

Slide 10

Slide 10 text

「組織の信頼性のマインドセット:Google SRE の知見」より引用^1 Google での観察によれば、組織の信頼性には 5 つの基本的段階があります。それらは不認識、受動的、積極的、戦略的、先見的という典型的組織モデルに基づいています　　不認識→受動的→積極的→ 戦略的→先見的これは『信頼性』の話だが、そうでない場面でも使える考え方では

Slide 11

Slide 11 text

自分がオーナーシップを持てる場所をさがすどうしても既存のソフトウェアを単に組み合わせるだけでは上手くできない (できなくはないが無理が生じる)場面はある → コードは書かざるを得ないそこで…… 「その場限りのコードを書き捨てて仕事を済ませよう」(リアクティブ) よりも「他のプロダクトでも同じ悩みが生まれるかも」 →「同じ悩みを汎用的に解決できるものを作り出そう」(プロアクティブ) こういうチャンスを生かしたい

Slide 12

Slide 12 text

たとえば HashiCorp Terraform, Vault, Consul, Vagrant, Packer など大物ソフトウェアは有名だがそれらに組み込まれている小さい部品も単体OSSになっている go-retryablehttp 自動リトライとexponential backoff付きHTTPクライアント golang-lru インメモリのLRU Cacheライブラリ go-version SemVerの解析ライブラリ小さくて使い勝手が良い道具を自分らで作って公開している

Slide 13

Slide 13 text

コードを書くか書かないか「コードはできるだけ書かない方がよい」それはそう。書いたものは資産にも負債にもなる「できるだけ既存のツールの組み合わせでなんとかしたい」それでよい運用ができるならもちろんOK 「このツールだけで全部完結させたい」 (趣味なら好きにすればいいけど仕事では) ひとつのツールに拘りすぎないほうがよい適切な道具を適切に使う、必要なら道具も自分で作るのがプロフェッショナル

Slide 14

Slide 14 text

隙間家具OSS マネージドサービス、コンポーネントだけでは不便があるときそれらの隙間を埋めて便利にするものマネージドサービスが時間とともに成長して不要になったら取り外す(ことも念頭に)

Slide 15

Slide 15 text

Glueではなく隙間家具(単体のソフトウェア)にする理由 Glueなコードはプロジェクト固有の事情に密結合しがちあるプロジェクトのリポジトリの中に置かれるコードの責任分界点が曖昧他のプロジェクトにコピペ(fork)されがち → 固有の事情(コピペ先の事情)によって改変されてだんだん別物にあるプロジェクトで行われたバグ修正が行き渡らない

Slide 16

Slide 16 text

単体ソフトウェア/ライブラリとしてOSSにする各プロジェクトに依存するコードは入らない(入れられない) 一般的なユースケースに対応できるようにインタフェースが整理されるプロジェクト固有の事情と一般的な事情を分離して設計と実装をするようになる bugfixはバージョンアップで適用できるノウハウも統一できる複数プロジェクトの運用が楽になる

Slide 17

Slide 17 text

ただし不適切な境界を持つ / 実装 / 抽象化をしたソフトウェアはすぐに負債化するわざわざ作るなら上手く作る必要があるどうしたら上手く作れるか…

Slide 18

Slide 18 text

https://speakerdeck.com/twada/quality-and-speed-aws-dev-day-2023-tokyo-edition

Slide 19

Slide 19 text

自分で設計したシステムをメンテする経験システムをシンプルに作ってシンプルに保つ力は経験で得るしかないひとつのプロダクトを… 1. 設計して 2. 実装して 3. テストして 4. リリースして 5. 導入して / 既存プロダクトと組み合わせて 6. issue対応やバグfixをして 7. (寿命を終えるところまで) 面倒を見る大きなシステム、ビジネスのメインプロジェクトでこの経験を積むのは難しい

Slide 20

Slide 20 text

『自分の庭』を作る既存のソフトウェアの組み合わせだけではうまくできない時に作る「隙間家具OSS」は『自分の庭』小さいのでいくつも作れる (練習になる) なくても何とかなるけどあると便利 (失敗したら使わない、戻す) 成功してもいつか取り外すことも念頭に作る (そのための設計を考える) 使い始めたらメンテはしていく (要望の取捨選択も含めて) コードはできれば書かない方がいいでも、鍛えておかないといざという時にうまく書けない

Slide 21

Slide 21 text

いろいろなコードを書く経験は無駄にならない

Slide 22

Slide 22 text

ISUCON 11 (2021年)

Slide 23

Slide 23 text

ISUCON 11 本選「学内システム」がテーマ Zipをオンデマンドで生成してダウンロードする機能がある初期実装は zip コマンド呼び出し (一般的に)外部コマンドを呼ぶのは効率が悪いため、言語内で実装したほうがよい Goでzip生成するコード…「 lambrollで書いたことあるわ」 10分で書いたコードで一発通過 (ただし、このzip自体は競技全体のスコア要素の1/10ぐらい?)

Slide 24

Slide 24 text

圧縮zipだったら負けていたらしい(後日判明) zip.Store (非圧縮)を指定してCPUコストを削減したのがスコアに効いていた

Slide 25

Slide 25 text

ライフステージの変化 20代後半〜30代前半結婚はしたが子供がいなかった夜は好きにコードを書いていた平日夜のイベントや勉強会にも自由に参加 30代後半子供が生まれてから一変 5年ぐらい、自宅ではほとんどコードを書けない時期平日の勉強会は参加できない、土日は家族

Slide 26

Slide 26 text

Year GitHub Events Graph 2012 115 息子誕生 2013 151 2014 495 2015 393 寝かしつけに消耗毎日寝かしつけに2時間掛かるので自宅では何もできない時期

Slide 27

Slide 27 text

Year GitHub Events Graph 2016 392 2017 639 ecspresso 開発開始(11月) 2018 590 2019 732 息子小学校入学イベント・勉強会参加休日は年2回だけ(YAPC, ISUCON) 平日夜、少しコードが書けるようになってきた

Slide 28

Slide 28 text

Year GitHub Events Graph 2020 1,070 コロナ禍 2021 1,043 2022 1,593 2023 1,459 朝のため平日夜は早寝する(のでコードは書かない) コロナ禍で外に飲みに行かなくなった → 金曜夜にしながらOSS開発するように土日も多少は余裕ができるように

Slide 29

Slide 29 text

最近の public contributions public repoのみでこんなかんじ平日は日中(仕事中)コンスタントに最下段=土曜日(実際は金曜深夜) 飲みながらOSS活動をする習慣土日はほぼなしいろいろやることがある

Slide 30

Slide 30 text

仕事中に(好きな)コードを書くなんだかんだで仕事している時間が一番長いであれば、仕事中に好きなコードを書けるのが一番効果的何かを構築・改善・運用するのが好き → 仕事中に発生したちょっとした不満を、立ち止まって考える「これ単体のツール・ライブラリを作ったら解決できるかな…?」余暇時間が使えなくても、(うまくすれば)仕事中に技術力の維持も向上もできる

Slide 31

Slide 31 text

fujiwara-ware いろいろ全部「仕事中に困ったこと」を解決するために書いた(ので半分仕事、半分趣味) cfft CloudFront FunctionsのテストとCloudFront KVSの操作を便利にするやつ ecspresso Amazon ECSデプロイツール lambroll AWS Lambdaデプロイツール ecsta Amazon ECSのタスク操作を便利にできるツール tracer ECSタスクの一生を全部まとめてみるやつ

Slide 32

Slide 32 text

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を表示してくれる

Slide 33

Slide 33 text

伝播するミームと伝わっていくもの『隙間家具OSS』(自分が作った用語) 初出吉祥寺.pm 16(2018/11), AWS Dev Day 2019でも発表 (当然)それまで誰も使っていなかった用語だが、かれこれ5年も言い続けていると…

Slide 34

Slide 34 text

地味に広まってきたかも…?

Slide 35

Slide 35 text

地味に広まってきたかも…? クラウドアプリケーション 10の設計原則「Azureアプリケーションアーキテクチャガイド」から学ぶ普遍的な原理原則 https://book.impress.co.jp/books/1122101082

Slide 36

Slide 36 text

自分が育ててもらった ○○-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... これらを実際に使って仕事をして、思想、設計、実装… いろいろな面で育ててもらった感がある

Slide 37

Slide 37 text

Webサービスやゲームの寿命は短いよほどヒットしない限り、数年で寿命が尽きるものが多い (そもそも目的からして短命なサイトなども多い) クローズしてしまうとスクリーンショットぐらいしか残らないことも多いエンジニア人生の方が全然長いエンジニアの人達になんらかのミームを残せたら個々の仕事よりも世の中に何か残せるんじゃないか隙間家具OSS、ISUCON……

Slide 38

Slide 38 text

歳をとってからでもパフォーマンスが伸びる 2019年健康診断の結果がヤバいのでダイエットを始めるウォーキングとレコーディングダイエット 2020年 1年で10kg体重減。ウォーキングが物足りなくなってランニングを始めた (それまで45年間、学校の体育以外の運動経験ほぼなし) 楽しくなってハマった

Slide 39

Slide 39 text

2020/09 ランニングを始める 2021/12 ハーフマラソン 1:44:51 2022/12 フルマラソン 3:34:58 2023/11 フルマラソン 3:28:33 (市民ランナーの上位10%程度) いまでも月間200km、週4回程度

Slide 40

Slide 40 text

歳をとってからでもパフォーマンスが伸びる (よく言われることですが)人生で今が一番若いこれまで運動経験0でも、ちゃんと練習したら3年で上位10%までいけた理論を本で学ぶ→実践→タイムや各種数値で効果検証を繰り返すエンジニアリングと同じ要素があるランニングはメトリクス/モニタリングマニアにお勧め

Slide 41

Slide 41 text

まとめコードを書くのが好きなので、ずっと書き続けられる仕事をしたいプライベートな時間は有限(特に家族が増えると貴重)なので日々の仕事でコードを書きつつ技術力を伸ばしていける場所と方法を探す自分は先達からの影響を受けて成り立っている、あとにも何かを残せたらいいな歳を取ってからでもパフォーマンスは伸びます