00:04
皆さん、こんにちは。London Tech TalkのKen Wagatsumaです。
イギリスのロンドンで、ソフトウェアエンジニアとして働いています。
このポッドキャストでは、Yosuke Asaiさんと一緒に、海外転職や最新の技術トレンドについて話していきます。
Yosuke Asaiさん、今日もよろしくお願いします。
お願いします。
今日は、Site Reliability Engineer、通称SREと呼ばれるこの職種の実態について、Yosuke Asaiさんと一緒に深掘っていこうと思います。
最近よく、「SREって何してるの?」と聞かれることがよくあります。
インフレやサポートエンジニアなど、難しい職種の方から、「どうやったらSREに職種転換できるの?」という相談も受けることも結構あって、
Yosuke Asaiさんは、僕も2人ともSREとして働いているから、
お互いの過去の勤務先を合わせるとか、
4つの異なるチームの経験が多分今日話せると思うので、
それぞれのチームとか、求められるスキルについて比較しながら、
SREと職種の実態について、リスナーの皆さんの理解が深まる助けになればいいかなと思っています。
じゃあ、まずだけど、SREになったきっかけからちょっと話そうか。
そうですね。
Yosuke Asai?
はい。
僕は最初、キャリアでいうと、モバイルエンジニアから始めて8年ぐらい前に、
フルスタックになって、バックエンドエンジニアになってなってたんですけど、
やっぱりバックエンドエンジニアとしてアプリケーションレイヤーを書いていると、
ネットワークレイヤーとか、データベースレイヤーとか、
もっとインフラ寄りに興味が出てきたんですよね。
はい。
そこで、SREっていうのは、
半分ぐらいコーディングスキルも求められるし、
インシデント対応力も求められるしっていうことで、
バックエンドエンジニアからインフラをより詳しくなるためには、SREっていうのは、
割とこう、職種転換しやすいキャリアチェンジかなと思ってて、
当時の上長とか、自分の上司とかに相談してたんですけど、
ちょうどそのときに、同じ会社の別のSREのチームのリーダーからうちに来ないっていう、
はい。
お声掛けを嬉しいことにいただいたので、
それでSREになったっていうことで、
つまり、僕がSREになりたくて周りに言っていたっていうのと、
タイミングがあって、飽きが出たから呼んでくれたっていう、
その二つが、タイミングが合わさってSREになった感じだね。
うん。
岡田さんは?
はい。
自分は、自分前職で、一応Javaエンジニア兼サポートエンジニア的なことをやってたんですけれども、
03:06
うん。
その中で、AWSをどんどん活用していこうっていう流れがあって、
自分はすごいAWSのサービスに興味があったので、かなり自主的に勉強をしていて、
それこそ、もっとAWSの仕事をしたいっていうふうに、ちょっと行ったりしていたところで、
DMSとか、AWSのDMSってサービスがあるんですけど、そのサービスのメンテナンスとかをちょっと任せてもらったりとか、
そのインフラ寄りの仕事を任させていただけるようになってきて、結構クラウドサービスを触るの楽しいなみたいなと、
心から入っていきましたね。
で、転職活動をしたときに、SREとかDevOpsっていう職種が結構、自分の今のスキルの中でやりやすい仕事というか、転職しやすいところではあったので、
それを元に転職したっていう感じがあります。
なので、社内移動を少ししたのと、転職をしてっていうので、SREになれたっていう感じですかね。
そっかそっか。明確に鞘さんの中でSREになったって瞬間はどっちですか?
社内で移動したときに、インフラとしても結構済みつつ、自分的にも対外的にもSREというジョブタイトルが付いたのは転職のタイミング?
転職後ですね。最初はやっぱり結構中途半端というか、バックエンドの開発もしつつ、ちょっとインフラも触るみたいになっちゃったんで、CICDとか。転職後になります。
そっか。じゃあお互い結構似てるね。モチベーションとかなりたいなという気持ちがあって、徐々にしかし仕事を見つけていって、それを社内転職とか転職をきっかけに変化したって感じか。
はい。
うん。
で、僕らが多分SREを経験してきたチームとか企業規模も結構違うと思うんだよね。
そうですね。
まず僕はじゃあとりあえず羅列してみると、最初にSREを始めたところが、日本の上場企業のクックパッドだったんだけど、グローバル部隊のSREでした。
うん。
で、注意点としては、日本のエンジニアリングにはSREを始めた。
はい。
で、日本のエンジニアリングにはSREがいて、ちょっと時期によって名前、呼称、呼び方が変わってたんだけど、そのことは完全に別のグローバルの方のSREだった。
僕は日本の方のクックパッドのSREは経験してなくて、で、グローバルに多分当時100人から150人くらいかな、全体の人員がいて、その中のエンジニアチームの中のSREっていうのを経験した。
うん。
開発者の数でいうと、例えば数十人とか。
はい。
06:00
100人以下って感じですかね。
そう、ちょっと正確な数字は分からないけど、150人のうちのいくつかって感じだと思う。
はい。
SREのチームは当時、5人から7人上下してたから、そのくらいの規模感でやってて。
はい。
で、先に全部羅列しちゃうと、で、その次にイギリスの現地企業のデータベースを作ってるクラウドの会社に入りまして、
はい。
全体として700人くらいいる会社で、スタートアップなんだけど、シリーズF。
はい。
なんで、もうほぼIPO直前みたいな感じの会社で。
うん。Fっていうのもあるんだっていうくらい住んでますね。
そうなんですけど、日本だとあんまり聞かないよね。A、シリーズAから始まって、Cグラウンド、A、B、C、D、E、Fだから。
うん。
Fまで行かずにIPOしちゃったりするところが多いので。
はい。
マザーズとかだと、たぶんCDくらいで行くのかな。
うん。
そう。で、そこで、エスカレーションチームとしては7人かな、やってた。
うん。はい。
で、きなこが今働いてる北米の会社で、IPOもしてる、上場してる大きな会社なんだけど、今は最近組織改変があったっていうのもあるんだけど、全タイムゾーンで30人以上。
うん。でかいですね。
でかいですね。
で、僕らの会社で持ってる1つのアプリケーションに対して30人以上で見てて、タイムゾーンが4つ分かれてる。で、過去のエピソードでも何回か話したんだけど、タイムゾーンが4つに分かれていて、僕が働いてるのはロンドンに在住してるから、イミア、ヨーロッパとかのタイムゾーンで、他にドイツとかオランダから働いてる人がいて、イミアのタイムゾーンで言うと7人。
うん。うん。
うん。
うん。
うん。
なんか、これを全てアメリカとか、APAC含めるともう30人以上って感じになってる。大規模な、大所帯のチームですね。
うん。
うん。
うん。
うん。
滑落された感じ、その2つ目の会社は人数規模に対してSREが少ない感じがしました。
うん。
うん。
うん。
そうなんだけど。あとちょっと詳しく話すんだけど、やっぱSREという職種ではあるものの。
はい。
実態としてどこまで何を求められてるかっていうのを結構、人によって違う。
うん。
はい。
うん。
うん。
うん。
うん。
ここの会社ではSRE業だけしてればいいんだけど
もうちょっと小さい会社では
プラットフォームエンジニアリング的なところとか
DevOpsも求められたりとか
というところで最初に経験したCookpad Globalと
2つ目のNeo4jっていうシリーズウェブの会社では
人数規模は一緒だったんだけど
求められたことは全然違うっていう感じですね
そこをちょっとアウトデフコントできたい
ぜひ
畑井さんのところのカルチャーとかチームサイズとか
09:00
自分は今も暗号通貨の取引所としてやっていて
社員数でいうとおそらく100人くらいだなと思ってます
SREのチームとしては4人のチームでですね
サービスとしても一応グローバルのサービスもあるんですが
基本的には
基本的には日本が今は多いので
日本に対しての責任を持つっていうところが
結構強いかなと思ってます
やっていることとしては本当にクラウド上で動かしているものの
ほぼ全てを責任を持つっていう形で
CICDであるとか
あとはデータベースとか
品種に対応とかその辺を全部やっているっていう感じになりますね
なるほど
だからお互い含めて4つの違うチームだよね
はい
SREって実際何してるのっていうところを深掘っていきたいんだけど
はい
まず先に僕の考えというか経験というか自分を話すと
SREって何って聞かれたときに答え方が2つありますと
1つはGoogleが提唱したSREの定義から話し始める
説明し始めるスタイル
SREって言うとねGoogleという会社があってみたいな
SREという職種を作ってみたいな
SREの定義はみたいな
リライビリティエンジニアリングとはっていう
話し始める方法が1つ
もう1つは実態から話し始める方法
それはSREって言っても一括りにしても
会社によって全然やってることが違うなと思ってて
SREって一種バズワードになっちゃったところもあるから
このスタートアップではぶっちゃけ
フルスタックエンジニアかけるインフラエンジニアだよね
みたいなのをSREって括ってるところもあれば
ちゃんとGoogle名にのっとったような信頼性高額のやつを
やってるところもあればっていうことで
なのでSREとは何かって答えるのは結構難しくて
SREのジョブロールに惑わされずに
その会社が本当に何をやってるかっていうのを知らないと
例えばSREに転職で職種転換する人とかだと
結構サプライズがあったり
思った通りにいかないっていうのもあったりするかなとは思ったりするね
確かに
本当に幅広いというか
話によってやっぱり全く違うなっていうのを
前回の話をしても思ったので
12:01
そうなんだよね
大まかに分けるとよくあるスコープが5つあるかなと思ってて
まず1つがインシデントマネジメント
障害が起こったときに障害の自己分析したりとか
あと障害が起こったときにオンコール対応するってやつ
2つ目がDevOpsエンジニアリング
3つ目がプラットフォームエンジニアリング
例えば分かりやすい例で言うと
Kubernetesクラスター社内ツール作ったりとか
社内ツールのための社内プラットフォームを実装して作ったりとか
例えばKubernetes使ってたらKubernetesのバージョン管理したりだとか
はい
社内のデベロッパーに向けたプラットフォームを作っていくとか
はい
4つ目がセキュリティ
5つ目がオブザーバビリティエンジニアリング
メトリクス、ログ、アラート
それを収集する一連のオブザーバビリティのツール
例えばPrometheus、Kurafanaとか
AWS使ってたらCloudWatchみたいなところの基盤を実装したりメンテナンスするっていうところ
あるかなと思ってて
僕の例で言うと最初のCookpad Globalはそれほぼ全部やってて
途中から別でセキュリティエンジニアというロールができたので
セキュリティの部分は割とゲイティエンジニアに外出ししたり
日本の方でできる人がいたから
彼らがグローバルも一緒に見てくれたっていうのもあるんだけど
割と幅広く見れた感じで
はい
それが転職すると
次のNeo4jの時にはSREチームの他にプラットフォームエンジニアリングっていうのがあったんですね
そこがプラットフォームエンジニアリングとかDevOps的なことを吸収してたから
Neo4jの時のSREは割とインシデントハンドリングと
あとはオブザーバビリティのツールの実装とかメンテナンスがメインだったっていう
そこが結構大きな違いでした
うん
人数少なくても回していたっていうのがあったんですね
そう
だからSREは7人って言ったけど
6、7人だったけど
プラットフォームチームにも7、8人くらいいたので
それを合わせると15人くらいの
中規模のサイズになってたかなって感じ
はい
それが今の働いてる北米の大きな会社になると
ほぼインシデントマネジメント専門っていう感じになって
僕らの他にセキュリティチームもいれば
オブザーバビリティエンジニアリングチームもいれば
プラットフォームエンジニアリングチームもいる
プラットフォームエンジニアリングチームの中も
REDIS専門部隊がいたりMySQL専門部隊がいたり
ハスカス専門部隊がいたりってなるので
15:01
僕らはもうインシデントハンドリングだけって感じになってるね
だからSREで僕のタイトルはずっとここで全部一緒なんですよ
サイトリライビリティエンジニアってことで一緒なんだけど
実際は全然違うっていうところが一つありますね
全然違う
かなり細分化されてるんですね
やっぱり大きい会社になると
渡井さんはどうかな
そうですね 自分のところだと
たぶんケンさんが挙げてくれた5つの例のうちの
プラットフォームエンジニアリングはそんなにやってないので
それ以外はほぼやっているのかなっていう感じも含めて
セキュリティもそうですね
セキュリティエンジニアの方が
いろいろいるんですけど
こちらでもやらなきゃいけないところがあるんで
両方やってるっていう感じです
それぞれやっているみたいな感じのところがあります
やっぱりチームとしては他にプラットフォームのチームがいるわけでもなく
ないのでクラウド上で起きる
すべてのことを対応していくって
クラウド上って言ったらわかりにくいですけども
要はコンソールに入って作業するようなこととかは
ほぼすべて自分たちのチームでやっているという感じになりますかね
データベースも見るし
リリースとかの管理もするし
あとはCICDも見るしっていう感じ
かなり幅広いんで全然手が回ってないところはあるんですけれども
そういう状態です
そうすると僕の最初のチームと近いってことですね
手広く見なきゃいけない
そうなってくると下選択とか深みを出すっていうのが難しくなってくるんで
すごい人手が欲しいなっていう感じになりますね
そこで人手が欲しいなって言ったときの人手っていうのは
例えばKubernetesに詳しい人とかデータベースに詳しい人っていう
スペシャリティをある程度持った人で構成したいっていう感じなのか
もうちょっと幅広く持ってる人を単純に頭数増やしたい
どっちかというとジェネラリスト寄りなエンジニアを増やしたいっていう感じで言うとどっちですか
でも今自分のチームで言うとKubernetesに詳しい人がそんなにいないので
スペシャリストが多いので
言ったらそれはそれですごいありがたいですね
なのでKubernetesの専門性がある人がいたらすごい嬉しいです
じゃあ構造としては明らかにKubernetesという知識を必要としている技術領域があって
18:02
そこがちょっと欠けてるっていう感じかな
そうですね
全然違うね
やっぱり同じ職種で作ってしまっていいのかっていう気がして
やっぱりプラットフォームエンジニアとか
一応そういうジョブタイトルもいますけども
そんなにメジャーではないというか
まとめてされていったりしていることも多い気がしてて
データベースとかもさ
僕はデータベース好きでデータベースの会社働いてたからわかるけど
突き詰めようと思ったらかなり深いところまで行くじゃないですか
はい
データベースの例えば採算のところだとどれぐらいのスキルを求められるの?
まず何使ってるの?
Posgre使ってて
EC2の上で動かしているのとRDSの上で動かしているのそれぞれあって
課題としてはやっぱりEC2であるやつのメンテナンスが大変なので
例えばバックアップとかを
特別なツールを使ってやったりとか
ディスクの拡張とかを見ていただきゃいけないんで
そういうのをRDSに動かしたいみたいな課題があって
そのアップグレードとか
マイグレーションのやっていくみたいなのは結構ありますね
一方でチューニングとかはそんなに知識がやっぱりないんで
できてないところはありますね
もっと詳しい人がいれば
もっと最適なデータベースの管理ができるので
コストを減らしたりとかできるのかなみたいな思いますね
そうなるよねSRAがデータベースを持つと
データベースはケンさんの会社では専門のチームが
マイスキルのチームがあるんですよね
今はね
最初のチームとかはまさにそんな感じで
優秀だったからできるんだけど
とはいえやっぱりデータベースばっかりやってるわけにはいかないから
そうですね
時間を空けないんで深く潜れないっていうのがちょっと悩みではありますね
そうなんだよね
CICPとかも本当そうで
割と会社によってはSRAが全部レスポンシビリティを持ってやってるところもあれば
割とこう
どっちかというとそのアプリケーション側の
デリバリーとか物質が上がってくるところなんで
アプリケーションの中で持ってるところもあったりして
そうですよね
確かに
そのところは知らしいと思うんだけどねSRA
開発チームがやっているところも一番
例えばテストとかをちょっとCIDメンテしてもらうとかは
やってるところはあるんですけど
21:02
それ以外の部分やっぱCDとかは特にSRA以外はやりますね
そうだよね
なんか中で
Io
ちょっと
そうですね
けんさんの
そうですね
職種というか
仕事の幅が
結構狭まったと思うんですけど
その中で何ですかね
問題なさというか
もっとこういうのやってみたいなっていうのは
感じたりするんですか
ああ
狭まったからってこと
そうですね
はい
例えばじゃあ他にデータベースチームがいるからデータベースやりたくなかったのっていう
そういう話だよね
そういうことですね
うん
あのね
結論から言うと
そのインシデントマネジメントに注力できて良かったと思ってるし
実はそれが僕が目指してた職種転換でもあるんだよね
これはあの転職の時にもう聞いてて
人によってはこういうのあんまり書かないよっていうのを聞いてて
はい
で何でかっていうと
SRAに求められるシキルって技術で区切ると今話したように
データベースもあってネットワークもあって
デバッグスキルもあってっていう話してたよね
でもう一つのソフトスキルも色々求められると思ってて
はい
ステークホルダーマネジメントとかプロジェクトマネジメントとか
あとこうインシデントってこうハイステークになりがちというか
こう割となんかみんなイライラしがちなところで
うまくこうメンバー間の連携を取りながら課題解決に向かっていくような
ファシリテーションスキルとか
はい
そういったチームをこううまく回してくれるような
こううまく回していくためのソフトスキルとかコラボレーションスキルを
身につけたいなって思ってるんだよ最近ここ2、3年ぐらい
データベースのスペシャリストになりたいっていうよりは
こうなんだろうね
仕事に求められるコラボレーションコミュニケーションスキルを
平均以上に上げていきたいっていうのがあってね
これを考えると実はその今のインシデントマネジメントに注力できるっていうのは
今のこの僕のタイミングにとって最適なSRIに
1年の職場で
確かに
そうっていうのがあるので
浅井さんの答えに関して言うと
つまりイエスだね
ソフトスキルというところでイエス
それに注力してるっていう
はい
ちなみにそのコラボレーションスキルとかコミュニケーションスキルみたいなのを
高めていきたいって思ったきっかけはありましたか
そうだね
これちょっと
話し始めると長くなっちゃいがちなのが
すごい短く頑張ってまとめるね
お願いします
何かの技術に特化する
例えばデータベースのNeo4jのエヴァンジェリストになりたいより
24:04
僕はもともと技術的に
理論的好奇心がフラフラしちゃう人間で
はい
例えば技術だけじゃなくても他いろんなことに興味が出ちゃうんですよね
はい
それをそういった自分の
品質パーソナリティを尊重した生き方になりたいなと思って
もともとはNeo4jとかのコミュニケーションスキルになりたいとか
何か特定技術の第一人種になりたいっていうのがあったんだけど
はい
いろいろ自分と対話したり考えたりキャリアを悩んでいると
そうじゃなくて自分っていろんなものに興味があるから
ジェネラリストとしてのSRBの
心を見つけていきたいなってなった時に
何か技術に特化できるよりは
いろんな人といろんな知識をこういう交流しながら
チームで成果を出せる
スペシャリストよりスーパージェネラリストになった方がいいな
自分に合うなって思って
それを目指した時にその当時の自分にかけてたのは
もう20代はもう技術しか時間かけてこなかったから
ソフトスキル
コラボレーションとかだなって気づいて
だからそっちを頑張っていきたいなって思ったっていうのが答えです
素晴らしいですね
これまでは20代のスキルをやばらしにかけて
生かしつつコミュニケーションをさらに伸ばせるっていうのが
かなりハマっててすごいいいなって思いました
そうですね
自分が40、50になった時にイメージした時に
ネオ4Jの世界第一人者になっていることより
なんかいろんなインターナショナルな
いろんなカルチャーの背景とか国籍バックグラウンドもらった人と
社会にインパクトを残せるプロダクトに関わっている方を
ような自分になりたいなと思ってます
うん
いいかな
チェック分析がすごいできてますよね
できた
チェック分析がそんくらいできたらいいなって思ってますね
できないからこそそこに今注力してる感じなんだよね
うん
そうそうそう
だからSREに求められる違いは
いろいろあるねって話をしたところで
はい
まずそもそもSREとDevOpsとの違いはっていうところで
浅井さんがね
以前に挙げてくれるところがあるんだけど
ここももうちょっと拭きたいなと思ってて
はい
いや僕も全然正直分からないっていうのがあって
SREの探求っていう本を読んだときに
著名人多分20人とか30人くらいが
SREとDevOpsの違いについてしゃべってるんですけど
27:00
それぞれ結構言ってることが違くて
面白いなと思ったんですけど
やっぱり自分がいいなと思うのは
Googleさんが提唱している
Class SRE Implements DevOpsっていう考え方が
ありますね
振りくれるのかなと思ってて
DevOpsっていうのはそもそも概念で
開発者とオペレーションチームの障壁を取り除いて
よりコラボレーションしていくみたいな考え方
より安定的なサービスを提供していこうみたいな
そうだと思うんですけれども
それを実際にエンジニアとして実装していくというか
実現していくのがSREみたいな考え方だと思っていて
それは分かりやすいなと個人的に思っています
一部のリスナーの方に補足すると
Javaで言うことで
Javaとかのゲームで言う
DevOpsっていうインターフェースがあって
一言で言うなら
JavaのClassの一行目の定義
Class SRE Implement DevOps
DevOpsっていう
確かにね
これよく聞くね
正解とか全くない気がしてるんですけど
ケンさん何かありますか?
こう思ってるみたいな
そうだね
SREのカンファレンスってよくあるじゃない
SREコンプがさ
そこ行ってて
なんかよくあるのが
どんどんどんどん話していくと
哲学的というか
SREとは何かみたいな
SLAを通してビジネスにどう価値貢献するのかみたいな
割とそういったふわっとしたところを
信頼性工学とか技術を
総動員して
明らかにしていくっていうのがSREの醍醐味なのかなと思って
今本当に浅井さんが言ってくれたように
そこの手法としてDevOpsを使うのか何なのかっていうのは
それがチームによって違うよって思ってて
だからそのクラスSREインプリメント
何かインターフェースの
インターフェースはDevOpsのこともあれば
チームによっては
ラバビリティエンジニアリングもあれば
プラットフォームエンジニアリングもあれば
そのインプリメントの後にくるインターフェースって
チームによっていろいろあるのかなと思ってて
だから自分の入ったチームで
どのインターフェースを実装していく必要があるのかっていうのが
分かる必要があるし
それがSREに求められてる
ことなのかなと思ってる
だからSREとしていろんなチームで
活躍していくっていうか
仕事を楽しんでいくために必要なのは
いい意味で自分のことを変えていける
フレキシビリティ
いろんなインターフェースを実装していける
30:01
学習に対する貪欲さとか
なのかなと思って
いやーすごいしっくりきました
なんかいいですね今の
その例でちょっとアナロジーとして使うと
例えばじゃあ僕のMySREというクラスがありますと
そのMySREクラスは僕はNeo4jで
グラフデータベースが大好きなので
MySREクラスに
I love Neo4jっていうメソッドを定義しましたとね
自分のクラスにいろいろ
自分の好きなメソッドとかプロパティを
どんどんどんどん持ってしまうと
今後新しいインターフェースが来たときに
同じメソッドがあったときに
自分のクラスがオーバーライドしてしまいますよね
自分の過去に得たスキルが
例えば過去10年かけて得た知識に
後ろ髪を引っ張られるというか
それで違うインターフェース
違う求められている要件じゃないところに
無理やり当てはめようとしてしまう
そうじゃなくて
自分が過去に得た経験とかうまくアンラン
アンランっていうのはその学習の反対だから
うまく忘れていって
新しい現場に入ったときに
その新しいインターフェースを装着しなきゃいけない
そこで求められているメソッドを正しく
実装していくことの方が
過去10年付き合った自己流のメソッドよりも
大事なんじゃないかなって思ってる
ちょっと伝わったか分からないけど
いやすごい伝わりました
なんかすごいし
やっぱり本当に技術の変化とかも早いし
それこそSREっていろんな業界でもやっていけるんで
業界の違いとかもある中で
どうやって自分が適応していくかみたいなところ
アンランっていうのが
好きになってくるんですね
これは僕が最初SREになったときに
その当時のリーダーだった人に
もらったアドバイスでもあるんだけどね
はい
それを大事にしてて
はい
インターフェースが変わっても対応できるようにって
そうそうそう
なんかそこら辺の思いをこの前ノートに
なんかジェネラリストとしてのSREローみたいなのちょっと書いて
今本当に話したところなんだけど
これもちょっと小ノートに貼ろうかなと思ってるんだけど
はい
ちょっと自分もこれ拝見したんですけど
これもすごいしっくりきましたね
自分のロールモデルなのかなっていうくらいに
なんかすごいありがたい話でした
そうそうだから好奇心がコロコロ変わるからチーム変えたり
チームが変わらなくても
会社とかビジネスの状況変わるじゃない
33:01
そうすると実はインターフェースが変わるから
新しく実装しなきゃいけないインターフェースを喜んで
今まで実装したメソッドを捨ててプロパティを捨てて
新しいインターフェースを実装していけるとか
僕みたいな好奇心の向き先がコロコロ変わる人に
ゲネラリストとしても合ってるし
はい
そういう意味で喜んで器用貧乏になろうというか
技術の世界で
そんなこと思ったかな
地域の積み上げみたいなところは結構大事なイメージありますけど
それよりもやっぱり地域をいかに育てていくかというか
新しいところにいかに対応していくかみたいなところが
大事っていうのがやっぱり面白いですね
そうですね
もちろんコンピュータサイエンスのベースの知識は必要だと思うんですよね
ソフトスキルもベースのコラボレーションスキルとか
そういうのがあった上でもちろん話をしてるんだけど
その上に乗っかってくる変わりやすい知識というか
どんどん判断していかないといけないっていうところがありそうですね
そう
かつそこから先に効率的に働いていくためには
いろんなインターフェースを実装していくと
共通部分が出てくるじゃない
はい
例えばKubernetesとかMySQLみたいな技術にあったときに
そこを一つ抽象レイヤーを上げて考えてみると
共通化できる構造ストラクチャーとかシステムっていうものがあると思うんだよね
はい
でそれを
例えばコンポーザブルな形で
別の自分流のツールボックス
別のクラスとして切り出して
そのMySREクラスが使うっていうのはアリだと思うんですよ
例えばMySQLとRedisとGraph Databaseっていうインターフェースを実装しなきゃいけないときに
それらに求められる共通の知識として
例えば分散データベースをスケーラーブルに運用していくスキルっていうのが
一つ抽象があると思うんだけど
じゃあその
Distributed Database Skillsみたいな
コンポーザブルなスキルを別のクラスとして
自分の中でツールボックスとして持って
必要に応じてそのMySREクラスから使うっていう
そうすることによって新しいインターフェースに出会ったときに
全部またゼロからフルスクラッチ実装しなきゃいけないことを避けられると思うんですよね
はい
だからそれは割と自然にやってる人は多いと思ってて
例えばその一つのプログラミング言語を学んだときに
Rubyに詳しくなった人が
新しくPythonを覚えるのって簡単じゃないですか
それは何でかっていうと
文法の違いさえ覚えればいいので
あとPythonWay
PythonicWayを覚えればいいので
Rubyを初めてプログラミング言語を学ぶときにやった
コンピュータショナルシンキング的なところとか
36:00
あとはデータ構造アルゴリズムは知ってるから
そこのベースとなる共通の知識
ツールボックスがあるから
その差分だけやればいいということで
インターフェースを全部一から
全部リソースしていく必要もなくて
共通化できるところはどんどん共通化していける
っていうのが一つあると思う
確かに
その抽象的な部分を
なんですかね
うまく考えていって
この知識はまた次に持っていけるように
ちゃんと覚えていこうとか
いう風に考えられたら
より成長も早いのかなっていう
気がしました
聞いてて
うん
なるほど
はい
いやちょっとそろそろ時間も来そうだから
こんなところにしようかなと思うけど
はい
最後に感想とかありますか
いや本当に毎回勉強になるなっていう
面白いね
はい面白い
今回のエピソードのタイトルは
じゃあクラスSRAインプリメンツDevOpsですか
これいいです
いつもタイトル考えるんだけど
確かにそうですね
いい気がします
うん
いや面白いネットを持ち込んでくれてありがとう
いえいえこちらこそありがとうございます
うん
いやでもなんかはい
ぜひSREになりたい人がいたら
本当に聞いてくれたらコメントしてくださると嬉しいですね
こういうの聞いて
違うよっていうコメントとかも欲しいですし
やっぱりそういういろんな視点からの
意見がいただけたら嬉しいですね
嬉しいよね
はい
今も今後ゲストの方が
SREの方に呼ぼうとしている人で
SREの方も何人かいらっしゃるから
おーいいですね
そういう時に
お前らのあの回帰だけど全然違うわ
みたいなこと言ってもらって
全商法的に新しいアイデアをどんどん利用していきたいね
はい
楽しみだな
ええ
はい
こんなところかな今日は
そうですね
はい
じゃあありがとうございました
ありがとうございました
