業務という形式にこだわった理由
技術発信やその他の研鑽ではなく、業務という形式にこだわったのは、座学に偏りがちな私自身の性格を踏まえてのことです。
また、業務形態を問わず、ひとりのエンジニアとして何ができるのかを認知され、裏付ける実績があり、いい形でコラボレーションできる状態でありたいと思うこともあり、Offersに登録して、複業を探し始めました。
詳しい経緯は私のブログ記事「旗を立てる2021年」にまとめています。
小さいスコープで技術選定
最初に取り組んだのは、ツールやコンポーネントの導入でした。最初のタスクということもあって、「xxxというツールを導入してほしい」というタスクベースのものが主でした。
コンテナ管理にKubernetesを選択しており、運用をいかに信頼性高く効率的に行っていくかという課題がありました。それまでの基盤へのコンポーネント導入や移行の設計・実装経験を活かして取り組みました。
Kubernetes Secretの管理には、kubernetes-external-secretsを導入しました。Secretのソース管理はAWS Secrets Managerで行いたいという前提の下で、複数のソリューションの比較や命名規則の議論などを経て導入・移行しました。
本業ではすでに利用しているものの私自身一から導入経験のないものや、異なる方法で解決したものに取り組むことができ、手応えを感じ始めました。
しかし、働きながら大学院でコンピューターサイエンスを学びたいという思いもあり、準備のため複業はいったんお休みさせていただくことになりました。
インフラ防災訓練と課題感の把握
大学院出願が落ち着き、複業を再開したいと思っていたときにSHEさんから再びお声がけいただきました。インフラの防災訓練を手伝ってほしいとのことです。
私が半年ほど離れているうちにチームの状況も変化し、アプリケーションを開発していたメンバーもKuberntesを触ってアプリケーション開発、運用などをするようになっていました。それを踏まえ、Kubernetes関連の設定を意図的に壊し、原因を探り当てて修復する訓練を実施しました。
Linux Foundationが実施するCertified Kubernetes Administrator (CKA)で似たような問題を解いたことがあったためすぐにイメージはできたものの、問題を作るとなると別です。サンプルとなる問題を10ほど準備し、CTOの@akirakironとの議論を経て4つに絞り、実現性を開発環境のKubernetesクラスタで検証しました。
作成した問題候補
▲問題のリスト
防災訓練当日は、参加者にモブプロ形式で取り組んでもらいました。詰まったらヒント出したりしたものの、最終的には想定時間どおりにすべての問題を解いてもらいました。
問題毎になぜその問題を解ける状態であるべきなのか、何に気づきどういうコマンドを使えばよいか、関連するKubernetesの知識などを解説し、手応えを感じていただけたようです。
作問者としては、意図的に壊そうと思っても壊れなかったり、普段行うデバッグ手順を言語化したり、準備に当日の何倍もの時間を要した分、私が一番勉強になったように思います。バックエンドエンジニアからプラットフォーム・インフラエンジニアというキャリアも思わぬ形で活かせました。
また、作問過程でインフラを概観して感じたSRE的な課題や防災訓練で感じたメンバーの加速力・自走力は、つぎに紹介するマイクロサービス化へのチャレンジへの大事なインプットになりました。
> [新着] OffersでSREの副業求人を見る。お気に入りの案件を見つけて応募しよう！
マイクロサービス開発基盤とコラボレーションのしくみ
防災訓練のネクストアクションを議論する過程で、マイクロサービス化にチャレンジしたいという相談を受けました。当時はフルタイムのSREがいなかった中、現実的に可能なのか、可能であるとしたらどのように進めるのがよいかというものです。
もちろんSHEさんの中でもいろいろな選択肢を検討されていましたが、私の本業での経験やメンバーの様子を考慮しても挑戦する価値がありそうでした。そのため、つぎの役割を引き受けながら一緒に進めていくことになりました。
- マイクロサービスの基盤整備のリード
- ロードマップ策定
- 採用
本業ではマイクロサービス自体の開発とその基盤作りを経験し、基盤も常に進化し続けています。その一方で、基盤の0→1の立ち上げ、中長期的なディレクション、チームの一からの立ち上げなどの経験は少なかったため、大きなチャンスを感じました。
しくみの開発
直近では、マイクロサービス間通信をgRPCで行うためのprotoファイルと各言語向けの生成コード管理基盤を一通り整備し終えました。
その後、オブザーバビリティを担保するためにログ、メトリクス、トレーシング、エラーレポートなど、アプリケーション開発者やSREがマイクロサービスの状態を一貫した方法で調査できる仕組みを開発しています。
また、SREのフルタイムメンバーや複業メンバーも増え、いろいろな関わり方のメンバーから構成されるチームでいかに成果を最大化するかも重要度が増しています。この課題を解決するために、@akirakironを中心につぎのようなアプローチを実験しています。
- SREチームのミッションを定める
- ミッションの各領域でみんなで課題出しをする
- アプリケーション開発メンバーと一緒に課題に重み付けをする
- SRE各自が主担当領域を持ち、OKRを定める
- SRE中心に週次でタスク分担・振り返り・プランニングを行いOKR達成を目指す
みんなで行った課題出しと重み付け
▲課題と解決策のリスト
チャレンジングな課題やチームが自律して動けるしくみは、とても魅力的で学ぶことも多いです。しかし、それ以上に多様なメンバーがいかに心地よく力を発揮できるかを考えていただいているのが常に感じられて、長く貢献できたらいいなと思います。
どういう形態であれ、SHEさんにご興味を持たれたら、ぜひこの記事のMeetyから@akirakironに連絡してみてください。
SHEはコミュニティテックで夢の実現を10倍に加速する − 僕たちの技術戦略を語ろう
期待を上回る成果
小さいスコープでの技術選定からはじまった複業は、当初期待していた成果を確実にあげつつ想像以上の好機に恵まれました。
つぎの項目は、提供したい価値として掲げていたもののうち、今年携わったものです。今後も改善しながら継続することで、私が提供できる価値と言えそうです。
- マイクロサービスたくさんあって大変！をどうにかする
- GKEワークロードの管理（今回はEKS）
- そういう系の基盤をこれから作ろうとしているチームのサポート
- マイクロサービス開発・運用を支えるツール開発
- マイクロサービス開発（新しいツール群に準拠するための移行）
- Terraformによるインフラのコード管理
それらに加え、つぎの項目にも貢献していけそうです。
- 採用
- 多様なメンバーから成るチーム作り
- Design docやArchitectural Decision Records（ADR）の導入
- Observability（TypeScript front/back ends、Datadog、AWS）まわり
もしこれから複業に挑戦する方がいれば、技術スタックのマッチングを気にしつつも解決したい課題ベースで議論できるとよいかもしれません。
複業・副業には「時間の切り売り」以上の価値がある
組織固有の制約があるにしても、アプローチが予め決まっていたり、エンジニアの種類・稼働時間ベースで請け負ったりするよりも大きな裁量・価値提供につながる可能性があります。
意図を持って課題解決に取り組めば、複業・副業で揶揄されることもある「時間の切り売り」以上の価値を見いだせるのだと痛感しました。
一方で、最初は小さなタスクで自信をつけたい場合もあるかもしれません。その中で課題を見つけて提案するのもよさそうです。あまり気負わずに、Meetyなどで話してみるとよい出会いがあるかもしれません。もし相談や壁打ち相手が必要な場合は、@toshi0607に気軽にお声がけください。
