はじめに
普段決済事業会社でアプリケーションの開発をフルスタックにしています。2年目になって開発していく中でもやもやしていたことがSREという言葉に出会ってすごくクリアになってたので、それを書こうと思います。
SRE Kaigiに参加して思ったこと
1. アプリケーションとしての負債を残しすぎない
アプリケーション独自の情報を根拠におきる要因をグリップしておく必要があるのかもしれないと思いました。例えば
- CQRSのようなDBの構成をしているからコストが高くなりうる可能性があるとか
- エラーの扱いは、モジュール単位にするとかこういう方針をプロダクトをつくる時点で、決めておくことが必要だなと実務をしていて思うようになりました。
- どんなパッケージ構成でプロダクトをわけるか
- 責務を分けてメソッドを記術する
当たり前ではあるが、こういった観点もアプリケーション側での負債になりうるので、それを限りなくゼロにしていくことが求められているなと思いました。
2. SREという職業を知るということ
こちらの発表を聞いて、プロダクトエンジニアとSREとの間での分断が起きうるのことを認識しました。
SREの業務に口だししないほうがいいのかなと思っていたのですが、そこのバウンダリーをいかに歩むよっていくのかって大事。
無知の知ならぬ「無知の血」なきがします（傷害事件w）。
- SREと呼ばれる人がどんなことをしているか？
- そのうえでどんな情報を見て考えているのか？
この視点を持つことがすごく大事な気がしました。自分は失礼ながらSREという実態を知らなすぎて、登壇者に色々質問したくなってしまっており、幸運にも優しく回答していただきました。
エンジニアリングとしての基礎力って、幅が広いなと思いました。基礎を勉強することは礼儀にも綱がるのだと改めて思いつつ、プロダクトオーナーシップをもってエンジニアリングするということの要求がとても難しく感じました。
非機能に目をむける
どうしても自分のプロジェクトはビハインドしてしまっていました。刷新を早くたたむことが求められてており、ここの視点が足りてないなと痛感しています。
- パフォーマンス
- アーキテクチャ
- 外部に伝わるようなドキュメント整備
このあたりを意識をもって行動したいと思いました。知識もつけながら、アウトプットでぶん回していく力が求められていくため、開発経験が乏しいと苦労するなと実感しました。
結局エンジニアは技術力からは逃れられない
SRE Kaigiの最後のセッションで発言されているのをきいて、身に染みるほど実感しました。結局、顧客の課題を技術要件に落とし込んで実装できるのか？これが如実に求められている気がします。
AIのテクニックである程度できるように納得ところもあると思いますが、製品に対する保証は人間がグリップする必要があって、技術がわかる・コードがかけるエンジニアはどこにいってもなくならないなというのを、座談会で実感しました。
SREは目利きが必要
SLOやSLAをたてるときにシステム固有の情報が必要です。エンジニアの方とコミュニケーションをとって作っていくとききましたが、実際何がちがうかとかどこが同じとか、いろいろ潜ってみないとわからないじゃないのかなと思いました。
目標値は立案できたとしても、実感が薄かったりして、考慮漏れがいくつか発生しそうな感じがしました。
そんな時に思ったのが、1つのプロジェクトに深く潜っただけでシステムの差分ってわからなくないか？
刷新のプロジェクトにジョインできて、一緒にフリーランスのエンジニアの方と開発をしているのですが、訴求力が圧倒的に異なっていることに課題感を感じています。
そもそも、刷新のプロジェクトに関われるのは20代の後半~30代の前半（ある程度経験年数が必要）ということらしいです。（人材業界の人にききました）
転職はリスクがある。といって1つのプロジェクトしかかわらないのもどうかなと思う…副業という選択肢がアリのような感じがしてきました。（ポートフォリオの準備だ）
おわりに
SREの職業はすごく魅力的だし、求められているものと年収も総じて等しいのかなと思います。ただ考えてみると色々なプロジェクトにジョインしてみてシステムの状態を把握する力があると仕事をやりやすいのかなと思いました。
エンジニアのキャリアを決めていくに際して技術力を高めていきつつも、いろいろなプロダクトを見てみることが大事かなと改めて思いました。
コメント