00:03
バンクーバーのエンジニアへようこそ。バンクーバーのエンジニアは日本時間で毎週火曜日に更新している、北米圏のテック業界やライフスタイルなどについてお届けする番組です。
実況をお届けするのは私たち2人。サンフランシスコのスタートアップでシニアテックリードエンジニアを務めるゆうやと、
エンジニアの海外進出をサポートする企業、フロック代表のセナでお送りしております。
今回もスペシャルなゲストがいて、前回ベルリンの話をしたじゃないですか。
もう多分前回じゃないけどね。前回じゃないかな。前にベルリンの話をして、あの話結構好評なんですよね。
そうですね。前回話したときにね、サウンドクラウドのSREの方ですってご紹介したらね、SREってなんやねんみたいな質問も何件か来たんですよね。
なのでちょっと今日は改めてっていう感じですか、SREってどういう仕事っていう話をちょっと僕らも含めていろいろ勉強させてもらおうかなと。
やっぱりヨーロッパも人気ですし、さらにはサウンドクラウドっていうのも結構気になるところですし、もっと言えばSREってなんなの。
さらにさらに言うとモバイルエンジニアからSREになった方で、その辺もすごく気になるなというのがありますね。
間違いない。距離はチェンジ的にインフラからなる仕事みたいなイメージがすごく強かったけど。
そうですよね確かに。
その辺もちょっとね、いろいろ話し聞きながら勉強させてもらおうかなと。
はい。
はい、ゆうせいさんよろしくお願いします。
よろしくお願いします。
よろしくお願いします。
さっきまでね、実は大下さんとちょっと時間10分前くらいに入って、機材テストとついでにSREってお互いこういう仕事だと思ってるっていう話をしてたんですよ実は。
結構そこでも衝突があって。
あれSREってこういう感じじゃないのみたいな。
やっぱ特に言われるところってやっぱりDevOps、SREってそもそもDevOpsからの派生みたいなイメージでやっぱりできた職業だというふうに僕は認識してたんですけど。
結構ね、やっぱりこれってDevOpsの仕事なのか、これはSREが今やってる仕事なのか、そもそも中小とかちっちゃい会社で必要ない仕事なのかとかって結構いろんな疑問が僕ら浮かんできちゃってて。
そうなので今日で改めてちょっとお話いろいろ聞ければなと思うんですけど、どうでしたっけ大下さん、さっき結構SREの部分でいろいろこういう感じの仕事だよねっていう話してましたよね。
しましたしました。
で、その中でよくわかんなかったのは、単純にやっぱDevOpsとの違いですよね。
ね、間違いない。
僕らの認識でDevOpsっていうのは開発をスムーズにするために開発するみたいなことがDevOpsかなと思ってて。
例えば自動化とかデプロイの自動化とかビルドの自動化とかそういうのに当たると思うんですけど、それイコールSREなのかなって僕も思ってたんですよ。
03:01
なんですけど、さっきちょっと調べてみると半分はDevOpsで半分は何か違うことをやるのがSREだみたいなことをWikipediaに書いてあって、その辺って何なのかなっていう疑問あります。
なので、担当職員にSRE、ゆうせいさんどういうお仕事サウンドクラウドされてるのかってちょっと聞いてもいいですか、とりあえずは。
そうですね、いやなんか前回と違ってだいぶ硬い話題なんで。
いやすいません。前回が言える過ぎた。
ちょっと若干緊張してて、2回目なんで順レギュラーも狙って。
順レギュラーも狙っていきましょう。
爪跡を残さないとと思って、すみません。ちょっといらない話をしてしまいましたけど。
そうですねSRE、定義確かにすごい難しくて、でもDevOpsの一種ではあるんですよね。
DevOpsをどうやってやるかっていうのをGoogleがこうやって私たちはDevOpsをやってますって言って世の中に出したのがSREなんですよね。
で、当然それはGoogleがどうやってるかっていうことではあるんですけど、いろんな会社が真似してって言われますけど、その中からいろんなアイディアを取り入れて各社SREをやってるっていうのが現状で。
で、多分今のフェーズとしてはGoogleはこうやってるんだけど、自分たちはでもこうやるよねみたいな。
そこからちょっとバリエーションがあったりとか、取捨選択をしっかりして自分たちなりのSREをやってるっていうような状態なんで、本当に会社のフェーズとか技術スタックとか文化とかによってやってることっていうのは違うと思います。
たださっき自動化っていう話が出たと思うんですけど、DevOpsの一つのテーマとしてそういう繰り返しの作業をなくさないといけないっていうのがあって、
それと同じ流れとしてインフラっていうのを例えばコードで管理、Kubernetesみたいにアプリケーションのデプロイっていうのをソフトウェアレイヤーで自動化していくっていう技術がどんどん出てきている中で、
インフラエンジニアがソフトウェアレイヤーをもっと触らないといけない、自動化のためにコードを書かないといけないっていう流れもあるので、
SREっていうと結構コードも書けないといけないっていうイメージもあるのかなと思います。
DevOpsもコードを書かなくちゃいけないっていう点だと結構似てるところやっぱりあるかなと思っていて、さっきの例えばKubernetesだって結局今までだとDevOpsの人たちがやっぱり構築している内容だったのかなっていうふうに思っていたんですけど、
そのあたりもやっぱりSREが今後は構築していって、そういうDevOpsの人たちも運用管理だったりっていうのがしやすくする。そこも結構仕事の一環っていうふうになってきているイメージなんですかね。
そうですね。僕のお話をすると、Kubernetesを触っている時間っていうのが一番長くて、
なんでKubernetesを触らないといけないかっていうと、一つはマネージドのサービスKubernetesを使ってなくて自分たちでクラスターを作っているので、
06:00
クラスター自体の管理っていうのをもちろんアップグレードしたりとか、メンテナンスしたりっていうのがもちろんあるっていうのも一つあるんですけど、
それと同時に社内のオペレーションっていうのをKubernetes上で、オペレーターって仕組みがあるんですけど、コードを書いてKubernetes上で実行するみたいなイメージだと思っていただいたらいいんですけど、
例えばこういうYAMLを定義して投げるとこういうことをしてくれるソフトウェアを書いてKubernetes上にデプロイすると、
それをしておけばデベロッパーは例えばこういうMySQLのクラスターが欲しいみたいなYAMLファイルを書いて投げると、
もちろん汎用的なものもあるんですけど、社内でそれぞれ設定が違ったりとか構成が違ったりするんで、
その社内独自の構成の知識っていうのをコード化して自動化すると。
開発者からするとYAMLファイルを投げたら勝手にいろんなことが起きるんだけど、その部分を作ってるのは例えば自分たちのケースだとSREのチームだったりするみたいなことがあるんですよね。
なるほどね。結構それだけ聞いてるとデベロッパー側、デベロップメント側に対しての自動化っていうのに結構注力しているご職業なのかなって思うんですけど、
やっぱりDevOpsって言われるくらいだからオペレーション側、要するに運用側の部分に対してもかなり意識しなくちゃいけない職業ってイメージもあるんですが、
その辺りもやっぱりKubernetes側で管理運用は整理されるのはデベロップメント側だけじゃなくてその運用側の方もっていうふうなイメージですよね。
そうですね。それが自動化っていうところではあるんですけど、
DevOps自体は歴史的に言うと運用と開発の境目っていうのをなくすカルチャーですよね。
デベロッパーが自分たちが運用できないコードを運用に投げて、運用は例えばよく読めないコードをとりあえず動かすみたいな。
それをやっていくとテンションとしては開発側はとりあえず早く動かしてよってなるし、運用側としては怖いんでこういう手順書を作ってこういうステップを踏んでみたいなことをやってくださいみたいなどんどん秘伝の手順書ができていってみたいな。
リリースマニュアルみたいなのとかがあって会議みたいな開いてこれリリースオッケーですみたいな反抗するみたいな。
そういう流れがある中でそういうのをなくしてデベロッパーと運用側の垣根をなくしてコミュニケーションをもっと円滑にしましょうっていうそういうカルチャーだと思うんですけど、
その中で自動化っていうのも一つ大事な柱ではあるんですけど、それと同時に人間の部分、じゃあどうやったらコミュニケーションが円滑になるかっていう人間の部分もやらないといけないんで、
09:01
そっちの方はどっちかっていうともっと泥臭い、例えばどうやってインシデントをレビューするのかとか、そもそもインシデントが何かっていうのを定義するとか、
インシデントをどうやってモニタリングするみたいなかとかっていうところもあるんで、
そういうカルチャーとか社内のコミュニケーションの部分っていうのも推進していかないといけないっていうところもあるんで、
そういうその人間の部分とソフトウェアの部分とっていうのを両方やってるので、外から見ると定義がよくわからんかいろいろやってるみたいな感じになりがちだとは思いますね。
いや間違いない間違いない。だから結構SREのこといろいろ、僕調べたって言ってもGoogleが提唱してたのが2017年多分くらいかな、
その時出してた本みたいなやつ軽く見ただけなんですけど、やたらとコミュニケーションの部分に対して言及されてる記事が目立って、
あんまりないじゃないですか、エンジニア職種でね、デベロッパーじゃあやりましょう、それでコミュニケーションの部分こんなすごく大事だからスキルとして大事だよみたいな。
そこがSREの部分になるとね、なんかSREに必要なスキル7000みたいなやつとか見ると、
だいたいコミュニケーションスキルがトップとかもしかにセカンドくらいに来て、そういう意味があったってことですよね。だから。
結構やっぱりあれじゃないですか、想像しにくい部分って結構ありそうだなと今の話聞いて思ってて。
間違いない。
なんですかね、実際にそれを業務でやったらどうなのっていうのはやっぱり気になるところですよね。
うん、確かに。だから業務でっていう話をしていいのであれば、大下さんともさっき話してたんですけど、やっぱり結構大きい会社に属する職業なのかなとやっぱ思ってはいて、
やっぱりそもそもリリース当初というか、すごく間近というかしてすぐくらいのスタートアップって呼ばれるような会社で、そもそもDevOpsがうまく回っているっていうところもまだまだ少ない段階とか、
シード段階の会社とかやっぱりそうかなと正直思うし、結構SREっていう業種を雇ってるところもね、日本であったとしても結構大きいところばっかりだと思うんですよ。
ゆかりさんとか、あとはどこだ、フリーとか。だからやっぱりね、ちょっとアジェンダっぽいところにも書かせてもらいましたけど、基本的にはそういう大組織でやっぱりワークする職業って思っているんですが、それって正解なんですかね。
正直その定義自体で言うと、サイトリライアビリティっていうことなんで、サイトの運用、信頼性に関わる部分を何でもやるっていう意味では、多分どのフェーズの会社でもできることはあると思うんですよね。
たださっき話したみたいに、コミュニケーションの部分っていうのもすごい、コミュニケーションの課題っていうのも解決しないといけないっていう点で言うと、やっぱりそのすごい初期のスタートアップって、
例えばエンジニアと、例えばもうCEOがもうべったりくっついてて、でもうその通貨の中でやっていってみたいな。で、何て言うんですかね、なんかそのナレッジの共有とかがそもそも必要なかったりとか、
自分たちの運用してる人と開発してる人が全然別れてなかったりとかっていうフェーズっていうのもあるし、インシデント対応する人がもう本当にそもそも一人で開発して一人で対応してるみたいなケースとかも全然あると思うんで、そういうフェーズだとわざわざそういうポジションを作らなくてもいいんじゃないかなと思うんですけど、
12:19
やっぱりその開発チームが複数出てきたりすると、その中でオーナーシップをどうするのみたいな話とか、共通部分の基盤っていうのをどうやって開発していくのみたいなのとか、そもそもインシデント対応のフローっていうのはどうなってるのみたいなやっぱり話が出てきたりするので、そういうタイミングで何かしら近しいポジションっていうのが必要になってくるんじゃないかなと思いますね。
なるほどね。まあ確かにね、結局リアリティするっていうだけのワードだけチョイスすると、それはどこの会社でも必要やろうって思うし。
確かに。
うん。なんだけど、まあそこを意識すること専用の人がじゃあどのフェーズで必要かって話ですよね。
そうですね。
大島さんとことかはじゃあ雇わないですか、SRE。
いや、めっちゃ欲しいですよ。
やっぱそうなんだ。
やっぱめんどくさいことが全部僕がやってますし、まだまだマニュアルなこともめっちゃ多い。やっぱそういう専属の人欲しいですけど、やっぱそれって正直一番最後になっちゃうかなと思うんですよね、順番的には。
なるほど。
これなんか僕からの質問になっちゃうんですけど、例えば大島さんとかだと僕のイメージだとサーバレスとかの知識があって、
実際プロダクションでもガンガン使ってるのかなっていうイメージがあるんですけど、そういう例えばサーバレスとかマネージドの環境の人からして、今SRE欲しいなって思うのはどういうところなんですか、どういうところがネックに感じるんですか。
具体的に言うとサーバレスで構築していても、例えばサーバレスのラムダファンクションをまとめるサーバレスフレームワークっていうのを使ってるんですよ。
そういうのもやっぱYAMLとか書いてコンフィグ書かないといけないし、あとはドメインつけるかつけないかとかもあるし、結構あるんですよね。
実はサーバレスにしたってやっぱり全部は自動化できないというか、けど僕らはサーバレスフレームワークっていうのを使っていて、ある程度デプロイとかビルドとか自動化できるんですけど、やっぱりそこで例えばコードデプロイとかコードビルドとか使わないといけないですし、それやっぱ書かないといけないんですよね、設定ファイルを。
構成管理のところで人がたくさんいるっていうことですよね。
そうですね。
運用ってなると、例えば障害がそもそも起きることがあるのかとか、キャパシティの部分で特別何か作業が発生したりとかっていうのはあるんですかね。
キャパシティに関してはやっぱりその辺はサーバレスの強いところで、オートスケーリング基本的にはしてくれるっていうのがいいところですね。
15:04
なんですけど、インシデントに関してはもうこれはどこまでやるかなんですけど、正直僕らはカスタマーサポートから連絡が来たら直すっていうぐらいですね。
そこまでできてないですね、ちゃんとモニタリングとかは。
改めてというか初めてその辺の話聞いたけど、それ今大島さんは全部一人でやってるんですか、ちなみに。
一人で見てるんで、やっぱりその辺も本当はやりたいんですよ。やっぱりインシデントがあった時に、例えばAPIが正しく動いてるかとか常に監視するとかやりたいんですけど、そのリソースがないし、それをやるんだったら多分もう少し新機能を開発するとかやった方がいいですよね、このフェーズだと。
なるほどね、なるほどね。だからやっぱある程度ちっちゃい会社というかね、スタートアップって呼ばれるような会社さんでも本当にいた方がいいのは間違いないんですよね。
見て欲しいですけど、でも多分そのバグが起きる可能性っていうのも、例えば1ヶ月に1回とか、わかんないじゃないですか、それって。だからそこにお金をかけるっていうのがスタートアップ的に難しいんですよね。
そうだよね、間違いないよね。
そうですね、やることが無限に湧いてくるフェーズっていうのは、そんなに序盤の方ではないと思うんで、その感じわかりますね。逆に自分の今の会社の状態とかってなると、いくらでも働こうと思えば働けるぐらいいくらでも何でも出てくるんで、
そうなってくると本当にもういくらでも人欲しいっていう感じになってきますけど、スタートアップでしかもマネージドのサービスたくさん使っててとかってなると、確かにもう多くても1人いればなんとかなるかなっていう印象はありますね。
あとはさっきやっぱりおっしゃってた部分で、デブ側とオプス側のコミュニケーションコストを減らすっていう話はやっぱりすごく大事だと思うから、結局はそういう人数がそもそも出てこないとコミュニケーションのコストなんかも見えてこないだろうし、そういう意味でもある程度中規模、終盤というか大下さんの言うところのもうちょっと後半の側でっていう話はメイクセンスするところではありますよね。
でもね、多分それ業種とかにもよると思ってて、僕の業界ってeコマンスなんで、決済とかオーダーの部分は僕らはショピファイに全部任せてるんですよ。
だからそこのインシデントは見なくていいから、本当に機能的な部分、例えば郵便番号をバリゲートするAPIが動いてるかどうかだって正直ちょっとそこが壊れたとしても、ちょっと何人か買えないぐらいなんです。
なんですけど、例えばその業種が金融系のサービスとかだったら結構クリティカルだと思うんですよ、動かないっていうのは。
いや、終わるよね。
だからそういう業種は早めにそういうSREの人を入れてるのかもしれないですね。
なるほどなるほど、確かに確かに。
それは本当におっしゃる通りで、僕は今サウンドクラウドという会社で働いてますけど、そういうものすごいクリティカルなサービスでは生活する上ですごいクリティカルなわけではないですし、そもそも基本的にC向けのものなので、
18:04
そういう意味では、例えばGoogleがやってるようなSLI、SLO、SLAみたいな、例えばインシデントが、そもそもこれぐらいの可用性が必ず担保されていて、
もしそれを下回ったときにどういうアクションを取らないといけないのかみたいな、ユーザーに向けて、例えばこれ以下の可用性だった場合はこうしますみたいな取り決めをちゃんとやらないといけないみたいな、
そういうことが書いてあるんですけど、じゃあ僕たちがそこまでやらないといけないかっていうと、そういうことは全然なくて、
本当にざっくり、うちの会社の場合だと99.9%の時間、コアのサービス、普通に音楽はちゃんと聴けて、トップページがちゃんと表示されてみたいな、
そういうことが99.9%の時間行われていれば、とりあえずOKとするぐらいのざっくりとした取り決めしかないんで、
やっぱりビジネスの形態とか、どれぐらい生活にクリティカルかっていうところで、どこまでやるかっていうのは、全然各々自社選択するのかなって思いますね。
いや、面白いな。今まで本当にSREで仕事をこっち、しかも海外でっていう人ってほぼいなかったから。
一人もいないですか?
一人もいない。そう、だから聞くこと聞くことが結構新鮮というか、ああ、そういうもんなんだっていう。
だいたいフロントエンド、バックエンドの人はたくさんいるけどっていう感じですか?
そうですね。身の回りの話だけしていいんだったら、もう本当にフロント7、7、8割多分超えてるくらいで、
バックエンドかあちらほらいるかなっていうので、最近でもクラウドエンジニアが少し増えたかなっていうイメージくらいですか。
だから本当にSREで一本で職業としてこっちで仕事してますっていうのは、ほぼ聞いたことないですね。
バンクーバーのエンジニアでは皆様からのご相談やご質問をお待ちしております。
Podcastを聞いている方はPodcastページの概要欄のTwitterアカウントへハッシュタグ、シャープバンクーバーのエンジニアを加えてご連絡ください。
バンクーバーはカタカナのエンジニ、まではひらがな、一番最後のヤだけ漢字っていうちょっと難しいハッシュタグになりますが、ぜひご連絡いただければと思います。
または番組ウェブサイトの問い合わせフォームからもご質問を送信できますので、概要欄のURLからご連絡ください。
具体的な業務内容に関してはさっき言っていただいた感じですかね。サーバー用意したりとか。
ほぼずっとKubernetesを触ってるっていうのも正直意外ではあったけども、やっぱでもそうなるのか。
具体的な名前を挙げるとTerraformとかも使ってますか。
そうですね。要するにKubernetesのクラスターは自前で管理してるっていうことなんですけど、僕たちは。
そのKubernetesが動くためのサーバーっていうのは何かしらの方法でプロビジョニングしないといけないと。
21:03
で、Terraformを使ってKubernetesのノードとかをAWS上なり自分たちのデータセンターなりに立ち上げて、
そのサーバーが立ち上がったら、細かいこと言うとシェフとかも使ってるんですけど、何らかの方法でサーバーが立ち上がってKubernetesのノードに勝手になってくれるところまでは行われると。
なるほどなるほど。
デベロッパーから見ると、Kubernetesを触ってるっていうのはもうマネージドだろうが、自社のKubernetesのクラスターだろうが、Kubernetesに対してYAMLファイルを投げてるっていうのはもう一緒なので。
なるほど。
こういうのを結構プライベートクラウドみたいな呼び方するんですけど、社内の開発者からするとKubernetesをやってればいいだけなんで、
っていうとちょっと語弊があるんですけど、基本的にKubernetesと関わってる。
例えばKubernetesに対してやるだけなので、クラウドって触ってるのとそんなには変わんないんですよね。
なるほど。
だから自分たち専用のクラウドを社内に構築してるみたいなイメージがあるんで、それでプライベートクラウドって呼んだりしますね。
へー面白い。プライベートクラウド、それって造語じゃない?別にサウンドクラウドだからそう呼んでるわけじゃないですよね。
いや結構よく聞く単語だと思いますね。
言ってしまえばKubernetes上にサーバーレスのシステムを構築することもできて、
そうすると社内のエンジニアが使うサーバーレスの仕組みをKubernetesで作りましたみたいなこともできたりするんで、
そうなってくるともちろん人的なコストもかかるし色々知識も必要になってくるんですけど、
それができるんだったらコスト面でパブリッククラウドを使うより安かったりっていうようなメリットもあるので、
頑張って自社専用のクラウドを作るみたいな、オープンなテクノロジーを使って自社専用のクラウドを作れば、
エンジニアから見るとクラウド触ってのと別に変わらないんでっていうような文脈がありますね。
そういうことか。ちょっと今僕勘違いしたんですけど、
AWSとかを全く使わずにKubernetesがプライベートのクラウドになっているってことなんですね。
そうですね。今の自分の会社の話をすると、歴史的にはもともとオンプレミスのデータセンターだけがあって、
そこにディザスターリカバリー用にAWSも使い始めたみたいな感じなんですけど、
リカバリーだったんですか。
そうですね。ただ実際AWSの方には常時大体10%ぐらいのトラフィックが行っていて、
ほとんどはデータセンター、自社のデータセンターでさばいているみたいな感じですね。
例えばAWSに障害が起きたりすると、もうそっちの方はトラフィック全部切って、
全部自分の方のデータセンターの方に流せば、AWSが動いていない間でもサービスを提供できるみたいな。
24:02
なるほどね。今もですか、オンプレでずっとやってるって。
そうですね。特に別にそこを変えないといけないっていう。
もちろん定期的にもっとクラウドに移行するかみたいな話は出るんですけど、
今のところあんまりそういうのはなくて、ほとんどオンプレで。
プラスAWSもマネージドのサービスは全然使ってなくて、
本当にコンピューターです。EC2とかS3とかは使ってるけども、
本当に単純にノードとストレージを普通にとして使ってるだけって感じですね。
なるほどね。ほぼ依存はしてないんですね。
そうですね。ただ、今、例えばサウンドクラウドだと、一応ユーザーは世界中にいて、
トラフィック自体もいまだに世界で100以前後ぐらいのトラフィックはあるんですよね。
世界のウェブサイトの中でも。
データセンターはEUにあるんだけど、ユーザーはアメリカに多いみたいな。
そういう事情があって。
今僕がやってるのは、実はカナダに新しくAWSのデータセンターを作るっていうのをやっていて、
僕は今、実はAWSのCA Central1と格闘してるんですけど。
こんなところで意外な繋がりが。
カナダに新しいのができるんですか?データセンターが。
そうですね。AWSのCA Central1っていうカナダのゾーンにEC2のノードを立ち上げて、
そこに新しいクワネテスのクラスターを作るっていうのを今やってます。
カナダって、ぶっちゃけアメリカに置いた方が早いじゃないですか?物理的には。
GDPRっていうのがEUはありますよね。個人データの保護の。
クッキーのやつですね。
日本から見るとEUのサイトにアクセスするとめっちゃ鬱陶しいバナナが出るみたいな、それぐらいの感じだと思うんですけど。
EUの会社からするとそれはもう絶対守らないといけないし、各社の社内に専門の人がいて、コンサルみたいな人がいて相談できるみたいな感じになってるんですけど。
カナダの方がGDPRに遵守しているEU外の国のリストみたいなのがあって、カナダとか日本はそこに入ってるんですよね。
で、USはそこに入ってなくて、無理ではないんだけど、多分ビジネス上のリスクがカナダの方が低いみたいな判断がされました。
面白い。それすごい面白いな。なるほどね。
じゃあもしかしたらデータセンター新たに作ろうぜっていう案件があるとしたら、ワンチャンカナダの方がUSより適してるかもねっていう議論が生まれるかもしれないってことですよね。
27:06
そういうのは全然あるんじゃないかなと思いました。
そうそう、スピード的なことだけ考えないと確かになんでUSで起こらんのみたいな感じで思ったけども。
なるほどなぁ、ビジネス系のそういう裏事情があるんですね。
でもそのヨーロッパのGDPRって、こっちだとあんまり意識しなくてもいいから、結構ヨーロッパのエンジニアさんって大変そうだなと単純に思いました。
そうですね、対応してた人はやっぱりその時期はすごい大変そうでしたね。
だってウェブサイトに単純に絶対モーダルみたいなポップアップとか入れないといけないじゃないですか。
あれによって本当はモーダルとかポップアップって一番マーケティングで入れたいやつなんですよね。
サインアップしてくれとか、そういう感じだからそれを使えないんじゃないかな。
逆に言えばそれで慣れるのかな。
完全にユーザーに対してワンステップを与えることになってるから、いいか悪いかって言われるとそれは悪いに決まってるわけで。
UX的にね。
UX的にね、言えばね。
いやでもそうだよな、だからGDPR、バンバン言われた当初は何年前でしたっけ?4年?5年?
その当初とかもうどうなるんだってすごい業界内にニュースになって、戻っていろんなサイトがクッキーのバナー入れ出して、一個文化変わっちゃいましたよね、あれで。
でもヨーロッパとかEU圏内って絶対あるってことですね。
そうですね、ちょっと次のあれに行っちゃってもいいですかね。
これちょっと就職関連、SREの。マジで知識がないというか、まず探したことがないのでどのぐらいボリュームがあって、何を見られるのかなとか。
例えばなんですけど、ポートフォリオってどうやって作ればいいのかなみたいな。
インフラ全般に言えることじゃないですか、インフラだけの話はもちろんないんだろうけど。
基本やっぱりSREとして私就職活動したいですって、実績何見られるのとか。
ちなみにそれこそ担当職員に聞きたいところで、ゆうせいさんはどうしてSREとして採用されたのかって話で。
僕はすごい珍しいケースだと思うので、正直あんまりその汎用的なアドバイスはできないなと思うんですけど。
そういうつもりで聞いていただけたらと思うんですけど。
僕自体は元々モバイル開発者として今の会社に入って、入ってから僕も元々バックエンドをやりたいなみたいな思いはあったんで。
社内でややフルスタックっぽい働き方をしてたんですね。
徐々にバックエンドの方に軸足を移していきたいなみたいな思惑でやってたんですけど。
そういう中で社内でいわゆるSREのポジションが空いて、社内でも公募がかかってちょっとバックエンドも飛び越してインフラになっちゃうけど、
ちょっとやってみたいなって思いがあったんで、とりあえず応募してみたいな。
30:02
会社によるんですけど、うちなんかは社内のトランスファーのプロセスっていうのは結構はっきりプロセスは決まってて。
もう向こう受入先のマネージャーがオッケー出したらもう行ってもいいよみたいな仕組みになってるんで、
社内の外部向けにやるインタビューをちょっと簡素化したやつを受けて、一応なんとかなりそうだねみたいな感じで入れてもらったみたいな感じなんですよね。
なるほどね。じゃあ会社一回入ってから転勤というか転校というか。
そうですね。中でジョブチェンジしてっていうことですね。
なるほどね。それがサウンドクラウドの時ですか?それともその前?
現職でです。現職で本当に1年半もいかないかな。1年数ヶ月前ぐらいですね。
なるほどね。もしかしたら前回お話いただいたら申し訳ないですけど、サウンドクラウドで最初入った時っていうのはジョブタイトル的にはモバイルエンジニア?
そうですね。iOSエンジニアとして入ってます。今の会社には。
これはやっぱり難しいところで、例えば新しいことをしたいんだけど、新しいことを始めると同時に仕事を変えちゃうと、やっぱり就職も難しいっていうのもありますし、給与交渉も難しいんですよね。
僕の場合はやっぱりシニアで入れるポジションでとりあえず入って、もちろんその時に既にiOSをやらないと決めてたわけではないんですけど、
でもシニアで入れるポジションでやっぱり応募して、会社によると思うんですけど、社内でジョブチェンジがあった時に同じ開発者っていうタイトルだったら、その中で給与レンジがあって下がったりとか、ポジションが下がったりすることってあんまりないと思うんですよね、正直。
そうですよね。実際雇った時の給与レンジも向こうももちろん知ってるわけだし。
大きな会社になればなるほど、エンジニアリングのスキルっていうのが特定のプラットフォームに依存しないものになっていくと思うんですよね。もちろんちゃんとコミュニケーションができるみたいなのとか、コンピューターサイエンスの知識が最低限あるみたいなのとか、そういう風にかなり抽象的な感じになっていくんで、
ジョブチェンジしてもそんなにそこでネガティブな評価をくらわないっていうのは正直ありますね。
なるほどね。そういう流れだったのか、知らなかった。
それでもいい方法ですよね、マジで。
いい方法だというのとプラス、大きいところだからならではない方法だなっていうのもちょっと思いますよね。
そうですね、例えば小さい組織で入って、もう今一刻も早くこのポジションのエンジニアが欲しいという人が入ってきて、他のことやりたいですって言って、すぐやらせてもらえるかって言うと確かにちょっと怪しいですよね。
まあまあ、公認にしろ何にしろそれはね、雄生さんが多分ツールに当たっての次の同じことをする人を公認か、見つけなくちゃいけなかったらしい。
33:06
そのリソースをすぐ用意できるかって言われると、やっぱりある程度大きい組織に限られる話なのかなと思ったし。
なるほどなあ、そうか、社内ジョブチェンジ的なやつやったのか。
でも、これから野党とかしてるじゃないですか、そのSREチームに入って、そういう時にポートフォリアとかリファレンスとか面接とかでどうやってやるのかなっていうのがあるんですけど、逆の立場で。
そうですね、自分もちろん受ける側も社内でやってますし、その面接、人取る側の面接っていうのももちろんやったりすることがあるんで。
それに、少なくとも僕の経験から言うと、ポートフォリオっていう概念はあんまりないですよね。
やっぱりフロントエンドの人とかみたいに、例えばウェブサイトでこういう作品がありますみたいなのをバンってやってみたいなのはやっぱりあんまりなくて。
OSSとかめちゃくちゃやってる人は別かもしれないですけど、普通の人からするとインフラエンジニアで目立ったポートフォリオを作るっていうのはあんまり効かない気がしますね。
僕が採用する側としても、そういうところで高い評価されるような人っていうのはあんまりいなくて、
どっちかっていうとやっぱり面接でのパフォーマンスっていうのが基本、一番重視されるっていう感じはしますね。
やっぱりそこで見るのは、もちろん過去の経験っていうのもありますし、よくあるシステムデザインインタビューっていうのがあると思うんですけど、
USの会社とかでもそうだと思うんですけど、リートコードみたいなやつとシステムデザインインタビューと両方あって、
うちはリートコードみたいなのはあんまりないんですけど、システムデザインインタビューはあって、本当によくある、例えばツイッターを作るんだったらどうしますかみたいな、
そういう感じのやつですよね。そういう中で、例えばこれぐらいのユーザーがいて、これぐらいのトラフィックが見込まれてみたいな、
例えば一つのツイートあたりメタデータ入れて、例えばこれぐらいの容量になるから、例えばストレージはこれぐらい必要そうみたいなのとかをどんどんコミュニケーションする中で決めていって、
もしユーザーこれぐらい増えたらどういうところがボトルネックになると思いますかみたいな、そうするとメッセージ級をこれ使わないといけないとか、
データベースのスケーリングをここで考えないといけないみたいな、そういう話をしていって、大体この人これぐらいの経験があるんだなみたいなのが分かるっていう。
そういうことですね、なるほどね。
よくインフラ系の人たちとかがレジュメ上に自分の全職でこういう経験をしてきました、それは例えばこういう規模のトラフィックのあるサイトの運用管理やってるインフラ作ってて、
36:06
こういう時にスケーリングして、こういうテストケースユースケースがあるから私は経験者ですよみたいな文章でパーって適当に書いて、適当じゃもちろんないんだろうけどちゃんと書いて、
それ見てインフラでちゃんと経験積んでる人なんだって言って、全職で電話してみたりとかしてリファイナンスチェックとりあえず適当にやって、
確かにこの人はちゃんとワークしてる人だったねっていうことで、面接っていう流れって昔からそれはあったかなと思うんですけど、
SREの場合も基本的にはそうやって、最初はとりあえずレジュメとかその辺の情報から、この人ちゃんとできる人かなっていうのはフィルタリングして、
あとのやっぱりコアになるところは基本は面接の方で全部チェックするっていうふうなイメージですかね。
そうですね、SREだとやっぱりコードを全く書けないっていう人はやっぱり採用されにくい傾向はあるので、
一応コーディングの面接もあるんですけど、ただコーディングの面接の結果が悪くても、もっとシスワード系のバックグラウンドがある人とかだったりすると、
ゼロだと多分ダメなんですけど、コーディングちょっとイマイチだったけど、例えばめちゃくちゃシステムデザイン強いねとか、
データベースの知識むちゃくちゃあるねとか、Linux本当に詳しいねみたいなのとかっていう人もやっぱりいたりするんで、
そういう人はもちろん全然チャンスがあるし、結構人によってどこにスパイクがあるかっていうのがやっぱり全然違うんで、
そこはやっぱりその面接じゃないとわからなかったりしますね。
まあそうですよね、なるほどね。
いや面白いな。だから結構ね、フロックというか僕らの周りってそういう海外就職もちろん主体レスでがすごく多いし、
そういう人たちってじゃあ過去の実績的に海外就職した人イコールなんかねフロントとかウェブ系の人が多いから、
やっぱりそっちをとりあえず見る傾向にはあると思うんですよ。
で、ビザの交渉とかのことまで考えたらやっぱりスタートアップの方がなんだかんだ言ってビザ交渉はしやすい。
それ多分北米圏のあるあるだと思うし。
だからなかなか今までってそのSREとかそっちの方に視野がやっぱり広がってた人たちって結構少なかったと思うんですよね。
だからもしねワンチャンそういうSREっていう職業、言うてまだ新しいジョブタイトルだと思うし、
今後やっぱりどんどん注目されていくのであれば、もしかしたら今後ねそれこそ日本からちょっと飛び出て、
SREっていうジョブタイトルで海外就職を目指すぞっていう人たちも出てきたら面白いなぁとは思うんですけど、
日本人で雇ったことって郵政さん以外っています?ちなみに。
原職ですよね。原職ちょっと把握してないんですけど、僕以外日本人がそもそもいるのかな。
ちょっと最近入った人とかだといるのかもしれないですけど、
少なくとも僕が入った時は自分より前にその日本人がいた形跡っていうのがないんで。
そこは正直わかんないですね。
逆に例えばSREとして就職の面接とかもさっきされてるって言ったじゃないですか、
39:05
どういうバックグラウンドの人が多いとかってなんとなくの傾向って見えます?
僕みたいなのは本当にいないですね。全然いなくて、
やっぱりさっき話したみたいな資産系の人とか、
周りに社内ITとかを最初やっていて、
ちょっとずつ例えばLinuxの知識とかがついてきたりとか、
自動化の知識とかネットワークの知識とかがついてきて、
もっとDevOps寄りの仕事をするようになってみたいな人とかもいたりしますね。
なるほどね。
一体こういう人が多くて。
あとはそうですね、バックエンドやってたけどインフラ結構詳しいみたいな人とかもいたりするかもしれないですけど、
フロントエンドからってことはあんまり滅多にないですね。
考えにくいっちゃって考えにくいですね。
そうするとやっぱりそうか、資産系でやっぱり実績ある人か、
それかインフラ強い人かっていうのが、
ちょっと次のステップとしてSREをっていうイメージが強いってことですよね。
そうですね。SREは本当によく言われてるのが、
どうやってなったらいいかよくわからないタイプの仕事だっていう。
いや間違いない。イメージってか想像がつかない。
昔から言われていて、
僕もやっぱりそのたまたま社内での点積がうまくいったっていうだけで、
やっぱりじゃあ他どうやったらなれただろうっていうのはあんまりよくわかんないんですよね。
ただやってみて思うのは、
とにかくカバーしないと範囲がいない、
カバーする範囲がめちゃくちゃ広いんで、
全部できる人っていうのはそんなに求めてなくて、
そういう人もたまにいるんですけど、
基本的にはやっぱりさっきも話したみたいに、
例えば社内のカルチャーの部分とかっていうのにやらないといけなかったりするので、
実はコミュニケーションめちゃくちゃ強い人がすごいワークしたりするケースとかもあるし、
あとはデベロッパーの気持ちがよくわかるみたいな。
デブチームとのやりとりが上手な人とかも必要だし、
もちろんその一方で構成管理めっちゃ詳しいとか、
AWSめっちゃ詳しいとか、そういう人も必要だしみたいな感じなので、
SREになりたいってなって全部やろうとすると都合にくれると思うんですけど、
ちゃんと強みがあって、
ちょうどチームがそういう人を必要としているみたいなフェーズだと、
どういう人でもチャンスは実際はあるのかなと思いますね。
面白いなぁ。
ちなみにさっきの話の続きかもしれないですけど、
モバイルからインフラにそもそも移ろうと思ったきっかけとか聞いてもいいですか?
大丈夫です。
モバイルのエンジニアのシニア以降のキャリアって難しい。
42:02
フロンテイント全般もそうかもしれないですけど、
やっぱり例えば僕なんかだと8年、
インフラ、SREになる前に8年ぐらいモバイル開発とかやってて、
成長曲線的にもすごい鈍化してきて、
もちろんまだまだやることはあるんだけど、
目に見えた成長っていうのも減ってきて、
その一方でフロンテイントの知識って結構ガンガン変わるんで、
結局またキャッチアップし直さないといけないんだけど、
自分の汎用的なスキルとしてはそんなに伸びしろがあんまりないんじゃないかなみたいな感じがありますよね。
どっかでそういうタイミングが来て、
年齢のアドバンテージっていうのも技術が時々バーンって変わるんで、
もちろん積み重なってくるものもあるんですけど、
結局でもこれ今、例えば今だと宣言的UIみたいなのが流行ってますけど、
このパラダイムでいきなり入ってきた人と今から自分はキャッチアップし直してみたいな、
自分の方にそんなアドバンテージあるの?みたいな。
なくはないんですけど、
でも新しく入ってきた人ももちろん全然チャンスがある。
敷居が低いといえば低いし、
結局でも長くいる側からするとどうやって自分のポジションを守っていくかっていうところでは結構難しいんですよね。
なるほど。
それが一つあるのと、
もう一つは自分がステップアップしていく上で、
カバーできる範囲を広げていかないといけないと。
例えば本当にわからないです、ゴールがCTOなのか、
BP of Engineeringなのか何かわからないですけど、
例えばどんどん上に登っていくんだとすれば、
多分インフラが見れなくて、
それでかつエンジニアリング組織全体にやいや言える人にはなれることあんまりないだろうから、
そうするとインフラとフロントエンド両方わかって、
例えばシステム全体が一気通貫である程度理解できてて、
っていう人になれば、
CTOとまでは言わないですけど、
例えばアーキテクトみたいなのとか、
プリンシパルエンジニアみたいなのとかっていうのになれる道があるかもしれないなみたいな、
そういう思惑でしたね。
めちゃくちゃ勉強になる。
これだってもう共感の嵐だと思う正直。
いやだってそうだよな、
そういう目線で言うんだったらやっぱりあれなのかな、
逆つくんだったらやっぱり今新規参入しようとね、
エンジニアとして新規参入しようとしている人たちがインフラがなかったらフロントから入るっていうのは、
ある種正解なのかな結局。
最近思うのはやっぱりみんな目先の一番先の部分の、
例えばリアクト使えるとか、
APIデザインできますとかっていうところにフォーカスしがちなんですけど、
45:03
実は開発ってもう少し深いところにあって、
シニアとかそれこそさっき言ったようにCTOとかになるので、
もう少し深い全体を見れる、
それこそ何ですかね、
計算機科学的に何かを解決できるとかっていうのが求められてくるんですよね。
そこってやっぱり頭打ちになっちゃうから、
確かにそのね、
雄生さんは多分推奨とか本も出してますし、
結構極めたんですよね、
多分そこである程度。
だから他に行くっていうのはめちゃくちゃいい選択肢だなと思いましたね。
なるほどな、
だから全エンジニアが多分一度考えることになるかもしれない道ってことですよね。
そうですね、モバイルエンジニアのやっぱりシニア以降のキャリアっていうのは、
みんなフロントエンド全般悩むんじゃないかなと思いますね。
でもそれあんまり考えてない人多いと思うんですよ。
なんかリアクトだったら、
なんかリアクトめっちゃ詳しくなりたいとか、
なんかフロントエンド最前線張っておきたい、
まあそういう人はいてもいいと思うんですけど、
みんなそれやってると確かにそれで技術2,3年で変わるし、
正直それ知ってるってどうなのって感じですよね。
そうですね、例えば95%わかるところから、
例えば99%まで詰めるそのコストっていうのはすごい高いんで、
そういうそこのギリギリの知識が必要となる領域ってもちろんあるんですけど、
でもそうじゃない人の方が大半なんで、
やっぱり長くやってその分だけのバリューが出しにくくなっていくっていうのは絶対あると思うんですよね。
さっきおっしゃったみたいに、
多分そういう意味ではフロントエンドの方が多分入っていきやすくて、
インフラの人って年齢層ちょっと高い印象がありますね。
多分30から40とかぐらいの人がやっぱりボリューム層としてたくさんいて、
多分フロントエンドだと経験年数10年未満とかの人とかっていうのが結構いっぱいいたりするイメージがあるので、
どっちがいいとかってことはないんですけど、
やっぱりインフラの長くいる人とかって本当に機関技術の知識がすごいあるんで、
本当にLinux詳しいとか、そもそもハードウェアの知識あるみたいな人とかってなってくると、
そこの技術ってあんまり変わってないんで数年で、
数十年で。
確かに確かに。
だからそういう人、例えば20年とか30年エンジニアリングやってる人っていうのがバリューが出せる領域っていうのは、
そういうところにオノズとなってくるっていうのはやっぱあると思いますね。
いやー面白いな、結局そうだよな。
エンジニアとしてのキャリアアップっていう部分で本当悩むとこですよね、おそらく。
でもインフラエンジニアは確かに年齢層高いなって思うな。
そういうところにあるのか。
ダサン的にやってたのは知らなかったです。
多分みんなそうなんですよね、多分。
多分バックエンドある程度行って、
その次っていうのを考えたときに、
さっき言ったようにアーキテクトとかになれるのはそこなのかなと。
すごいな、深いな本当に。
この話めちゃくちゃいいですね。
48:00
いや多分刺さる人めちゃめちゃ多いんじゃないかな多分。
初心者には全然刺さんないと思うんですよね。
何言ってんのみたいな話だったら。
でも初心者からするなら逆にあれじゃない?
後押しになるんじゃないですか?
盲目的に先輩に言われたからフロントから入ってるけど、
私のキャリアはこれでいいのって言う人も多いし。
逆にやっぱりバックとかインフラから入りたいんですけど、
私っていう人もたまにいるから、
そういう人からすると、ちゃんと経験積むの大変よって話になるかもしれないし。
難しい話ですね。
いい話が聞けた。
そんなどうかな、あと何かあったっけ。
最後に聞きたかったのが、
SREのやりがいって何なのかなっていうのを聞いてみたいですね。
デメリットでもあるんですけど、
まずプラットフォームとかを作る。
社内での開発者が使うプラットフォームを作るっていう側面も結構大きいので、
やっぱり社内にユーザーがいるっていうのは結構経験としては面白いんですよね。
モバイルをやってた人間からすると。
もちろんエンドユーザーが見えなくなるみたいな、
もちろん見ないといけないんですけど、
現実的にはエンドユーザーはちょっと遠くなるんで、
やっぱりそこが見えないっていうフラストレーションを感じる人もいるかもしれないですけど、
一方でメリットとしてやっぱり社内にユーザーがいて、
自分がやった仕事っていうのがすぐ社内で使われるみたいな。
やっぱりそこのフィードバックのサイクルっていうのは早いんで、
それはやっぱりすごくやりがいがありますよね。
自分が例えば社内のプラットフォームこういう風に改善しましたみたいな、
これ欲しかったんだよねみたいな話がすぐ上がってくるっていうのはやりがいがあります。
もう一つは、これも結構フロントエンドとの対比になるんですけど、
やっぱり定量化しやすい結果が上がってきやすいっていうのが一つあって、
フロントエンドだとデータを見て、
例えばコンバージョンがどうなったみたいなのとか、
そういうのを見て定量化することはあると思うんですけど、
ただいろんなファクターがあるんで、
一概にこのUIを実装したからこの数字がイコールこれですみたいなのとか、
っていうのは言えないこともあると思うんですけど、
一方でインフラって結構この変更を入れたことによって、
こんだけトラフィックが減りましたみたいなのとか、
こんだけデータがセーブされましたみたいなのとかって、
バンって数字として見えるじゃないですか。
なのでやっぱりこれをやりましたって、
これをやってこういう結果が出ましたっていうストーリーはちょっと作りやすいっていうのはあるんですよね。
だからそこを数字が見えるっていうのは結構やりがいいかなと思います。
51:00
それもいい意見ですね。
フロントエンドっていろんな要素があったりとか、
そもそもUXって計測が難しかったりするじゃないですか。
確かにね。
そこで先が見えなくてフラストレーションたまる。
特にこういう業界だと、
例えばビジネスの人が勝手にこじつけて、
これはこうだみたいな感じで試作を出してきて、
無理な機能とか変な変更を入れられたりすることって結構多いんで、
それ嫌だっていう人結構多いと思うんですよね、フロントエンドエンジニアは。
例えばその序盤に話した僕だと、
例えば新しいデータセンターを、
データセンターとかKubernetesのクラスターをユーザーにもっと近いところに作りましたってなると、
例えばユーザーからのレイテンシーっていうのがそのまま下がるはずなんですよね。
そういうのとかっていうのが、
例えばしかも取れるデータも多いじゃないですか、バックエンドって。
こんだけのトラフィックがあって、
こんだけの人がこれくらいのレイテンシー下がりましたみたいなのとか見えたりする、
みたいなのをやっぱり嬉しいですね、単純に。
なるほどね。
一方でエンドユーザーの体験がすごい気になるし、
そういうのが大好きだっていう人もいると思うので、
そういう人をフロントをやるのが天職なんだろうなって思いますね。
間違いない。
SREのさっきの話にあった、
エンドユーザーの顔も一応見えなくちゃいけないって話あったじゃないですか。
その度合いってやっぱりフロントに比べるともちろん弱くはなると思うんですけど、
SRE側がエンドユーザーのことを意識するタイミングって、
具体的にはどういうタイミングがあるのかなって一瞬思いはしたんですけど。
これ結局リライアビリティをやってるんで、
システムが稼働してないってなった時に、
実際に気づかないといけないのは自分たちなんですけど、
ただシステムが稼働してないっていうのがどういう状態なのかっていうのは、
フロントエンジニアじゃないと分かんないんですよね。
例えばこのマイクロサービスが落ちたら、
一体ユーザーからは何が見えるのかっていうのとかっていうのは、
ちゃんとユーザーの経験とバックエンドが何してるかっていうひも付けができてる人しか分からないんですよね。
ダッシュボード上で、
例えばこいつが、このサービスが500をこんだけ履いてるみたいな、
それは言えるんだけども、
じゃあサービスの影響範囲は何ですかってなった時に、
そこ結構ギャップがあるんですよね。
だからそういう意味で、ユーザーを見てるんだけど見てないみたいな、
そういう状況になりがちっていうのが伝わりますか。
なんとなく。
数字上はおかしいことが起きてるんだけど、
でもそれが本当にユーザーにとって何が起きてるかっていうのを理解するのはまた別の話だし、
逆に数字上は全然いいんだけど、
54:01
実はユーザーの体験がめちゃくちゃ悪いみたいなケースもあると思うんですよね。
確かにね、なるほどね。
そういう意味では、日々の業務の中で本当はユーザーを向いてるはずなんだけど、
でも実際に直接自分たちがやり取りしてるのは、やっぱり数字だったりデータだったりするんで。
それだけ聞くと結構難しい初期業だなって思いますよね。
いやー深いっすねそこも確かに。
違いない。
やり取りしなくちゃいけないのは目に見えるユーザーというか、
実際にデベロップメントする方々なんだろうし、
でも意識するところとしては、そういうエンドユーザーの行動だったりとか、
一応どういう画面が映ってどういう行動に至るのかっていうところの想像はできなくちゃいけないっていうことだと思うから、
なかなか大変だなっていう。
単純にそれって開発サイドというか、アプリケーションを開発してる人と争いも起きそうだなと思う。
ね。
俺はちゃんとやってんだよ、俺はちゃんとやってんだよみたいな感じで、
その辺ちゃんと協力しないと、お互い見てる数字が違うから、そういうのは起きそうだなと思いましたね。
そうですね。だから基本的にはやっぱりサービス開発を円滑に進めるっていう前提で物をやらないといけなくて、
そこが一番の目的であるべきだとは常に思いますね。
なるほどね。だから開発効率だけにフォーカスしちゃうと、またエンドユーザーをないぐらしろにしちゃうしみたいなところで、いろいろ難しいですね。
開発効率が良くなることで、エンドユーザーに対してのデメリットがあっていうのは、どういうリンクがあったのかな?
例えばなんですけど、やっぱり目に見えて成果が見える方が、僕のイメージなんですけど、いいかなって。
そうなったらやっぱり社内にいるエンジニアのために、例えば開発しやすいようなコマンドを作ってあげるとか、仕組みを作ってあげる、
例えばスラックのインテグレーションを作ってあげるとかって、フォーカスした方が近いから成果って分かるじゃないですか。
そうした人たちが喜んでいる様子とかも分かるけど、実はそれが一番大事なのって、実はサームのクラウドを使ってくれるエンドユーザーじゃないですか。
間違いないね。
そこに直結しているかどうかをちゃんと測らなくちゃ本当はいけない。
でもこじつけはできそうじゃないですか。
例えばスラック上でのコミュニケーションが5分かかっていた部分が1分に短縮されます。
であればその短縮された時間によってさらに新開発の部分に時間が割けますとかって、何とでもこじつけできるんじゃないですか。
逆にこじつけができるからこそ怖くて、開発者のためだけにやってあげようみたいな感じで変な風になっちゃうかもしれないのはありそうなんですよね。
なるほどね。
それを言われてしまうと確かにそうだな。
だから正観して全体を俯瞰してみるみたいな視野が必要だなって。
やべえ、俺無理かもしれない。
俺マジで無理かもしれない。
57:00
そこはやっぱり組織の評価制度の作り方とかっていうのにも関わってくるなと思うんですよね。
やっぱり社内にユーザーがいると、社内では成果を発表しやすいですし、自分がやったことっていうのを他の人が言わなくても勝手に知ることになるんで。
例えばCIとかをやってる人とかもそうですけど、例えばCIメンテナンスしてますと。
でCI落ちたら開発できなくなるんで、CIが動いてるっていうことはすごいみんなにとって大事なことじゃないですか。
でも頑張ってればすぐ分かるみたいな。
そういう人が自動的に評価されやすくなっていいのかみたいな。
もちろんその人の頑張りも評価されないといけないんだけど、
例えばフロントエンドの人は社内の人に自分がやってることの大事さを伝えるためにもうちょっと努力しないといけないことがあったりすると思うんですよね。
そこの部分をちゃんと組織の評価制度がちゃんと吸収できるのかなみたいなのとかっていうのは、僕はすごい、その両方をやった身としては結構気になると思いますね。
答えなさそうだなって思うんですけど、サウンドグラフドは実際その辺ちゃんとワークしてるんですか?
まあその評価、いわゆる360度評価みたいな感じでやってるんで、
当然そのちゃんとその人を選べば自分がやってることの評価っていうのはしてもらえるんで、
そのなんか狭いグループの中で偏った評価がされるみたいなことはあんまりないと思うんですけど、
ただそのエンジニアリング組織全体でその自分がやった仕事を誰が知ってるのかみたいな目線で見ると、
そのやっぱフロントエンドの人っていうのは自分がやった仕事のユーザーが組織にいないんで、
そこを宣伝するのってちょっとコストかかるなって思いますよね。
間違いない間違いない。
社内ミーティングとかで多分発表しなくちゃいけないでしょ。
こういう効果があってこういう成果が出たから、だから私の仕事に意義があるって話でしょきっと。
いやーそうだよね。
まあ確かにそこをだからまあいちいちやらなくちゃいけないっていうのをコストと見るのか、
正当な評価をしてもらうための必要手段だと見るのか、
なんか文化におよるんだろうなぁと思うし。
なるほどね。
深いっすね。
深いね。
いやー面白いなぁしかし。
いやーあのもうユウセイさんはこのポッドキャストの技術担当っていう。
勝手にそう言って。
勝手に毎回お願いしよう。
やっぱ話してる内容とかがすごく深くて。
いやー間違いない。
感心します毎回本当に。
本当にありがたい限りですわ。
こういうお話なかなかね金払ってでもやっぱり聞きたい人いるだろうし。
いや本当ですよね。
すごいいい話。
だから僕とかまさにシニアで、
たぶん同じような立場だったと思うんですよね。
1:00:01
フロント何年かやってっていう。
だからちょっとSREになろうかなと思いましたもん。
本当ですか?
ちょっと単純すぎない?大丈夫?
単純ですけどね。
大丈夫?
でもねそうよね。
もう影響受けまくりですね。
でもそうよね大島さんもねここ最近本当になんかやっぱ大手行った方がいいのかとかさ。
うんうん。
結構やっぱりそのキャリア的なやっぱり悩みっていうのはむしろ抱えてるフェーズだろうし。
そうなんですよね。シニアはシニアなりにやっぱりその頭打ちきちゃうから、
次のなんかあるんですよね確かに。
そうだよね。
あのまだユウセさんには紹介したことないけど、
ここのポッドキャストのじゅんじゅんレギュラークエストのコウヘイさんっていう人とかね、
あの人なんかもその人はこっちでシニアエンジニアとしてって言うで、
アメリカの方にも本社がある会社で働いてるんですけど、
やっぱ同じで天井がとか、キャリアの次がとか、
やっぱりそういう話ね。
シニアはシニアで本当悩んでるよねみんな。
そうなんですよね。ある程度まで行っちゃったらもう同じというか。
確かにね。やっぱそうか。
でもさっきね、それこそユウセさんの口からちょっとちらっとCTOとかって言葉が出てきたけれども、
やっぱあれですか、次もしもキャリアチェンジすることがあるとしたら、
もしかしたら次はスタートアップとかのCTOとかそういうのもあるかなってユウセさん自身は考えたりするんですか?
そうですね。機会があったらやってみたいなとは当然思いますね。
やっぱりシニア以降でステップアップする先ってなると、
本当にそういうもっと組織全体を見るようになるか、
特定の技術を以上に深掘りするか、
もう本当に給与を求めて超でかい会社に入るかみたいな、
そういう選択肢しか数字上改善していく上ではそういうことしかないんで、
これ例えばシニアのまま他の会社に同じ規模の会社に入ってってなったら、
本当に水平移動してるだけなんで、
やっぱりそうなってくると、もちろんこがましいですけどCTOみたいなのは選択肢としては当然持ってたいですよね。
そうですよね。その時には結局今までの経歴というかキャリアとして、
フロント側というかモバイルデベロップメント側もずっとやってたし、
バックエンドもやってたのかな。
今SREとして社内を向けた運用開発ももちろんやってたし、
包括的に私はできるからっていうのを武器にして、
CTOとかそういうポジションもいけるであろうっていうのが理想にはなってくるって感じですよね。
聞いてる人で声かけてくれる人がいたらよろしくお願いします。
全然います。絶対います。
だってそもそもスタートアップだったら、まずモバイルでアプリ出したりとかもあるじゃないですか。
で、インフラもわかってたら全部できるじゃないですか。
間違いない。全部できるじゃないっていう。
1:03:00
そうですね。やっぱりこれはもうジレンマで、いろいろ経験を増やしていくと、
全部のシナジーがある場所を見つけるのがどんどん難しくなってくるんですよね。
モバイルがわかって、インフラがわかって、
僕らだと例えば英語と日本語がわかりますみたいな、
これ全部揃う職場があったら多分結構いい待遇があるかもしれないけど、
そういうところでそんなにないだろうから、
じゃあ何をやったら自分のスキルセットが全部一箇所に揃うのかみたいな。
すごいレアなケースですよね。どっちにしろね。
そうですね。そういう意味では1個の技術をむちゃくちゃ深掘りした方が、
特定の会社でスキルを伸ばしていくみたいな、
わかりやすいキャリアはそっちの方が歩みやすいのかなと思ったりもするんで、
ここは一応一旦ありますよね。
そうですよね。間違いないよな。
いやー難しい。キャリアの話はいつもあれですね。ゴールが見えないですね。
そうですね。正解もないし、さらにもっと言えばキャリアだけじゃなくて、
ご家族とかも関わってくることなんでね。
なかなか一人で決めづらいっていうところもありますよね。
いやー面白かった。
また次回お願いしたいですよね。
間違いない本当に。また聞きたいことが。
ありがとうございます。
今日はSREについての話をしました。
聞いてみました。どうですか?大島さんだいぶメイクセンスする感じでした。
結構SREって周りにいないって知ってましたけど。
そうですね確かに。やっぱりちょっと派手じゃないんですよね。
なんかやっぱ派手なのってフロットエンドのところだったりして、
その表に出てる人もそういう人が多いから、
なんかやっぱり最初に目指さないところかもしれないんですけど、
そういう深い知識とかって重要だなと思いますね。
間違いない。キャリアとしてっていう部分で見ても、
やっぱり最初に目指すべきじゃないだろうしね、そもそも。
正直やっぱり社内でDev側なのかOps側なのかっていうのを回ってみて、
で実際にどのところに問題点があるかっていうのが分かんないと、
そもそもその運用のサポートだったりとか、
そういうツールだったりとかの提案もできないだろうし。
そうですね、まさに。
だから結局やっぱり今日雄生さんがおっしゃっていたように、
やっぱりシニアとしてというか、フロント側からもしくは開発側からの
次のステップとしてっていうので、深みを出すためというか、
次のキャリアを目指すための1個のステップとして、
やっぱりおそらく目指すっていう人も出てくるのかなという風に思うので。
そういう選択肢があるよっていうのが知れたのも、
今回すごく大きい収穫だったなと思うので、
1:06:02
今後SREとして海外就職する人がこのPodcastを聞いたっていうのがきっかけで
100人くらい出ると。
いいですね。
出るかな?分かんないけど。
そんな感じで、そういった職業の話を聞くことができて面白かったですね。
ありがとうございました。
ありがとうございました。
ありがとうございました。
