SREってどんな仕事？社内のエンジニアに7000文字インタビュー【求人情報あり】
- 社内のこと
- 2019.10.25
- かいたひと：ゆかと
SRE職の役割は「サイトの信頼性と開発者のproductivityを向上させること」なんですって！なにそれかっこよすぎる！
どうしてSREが必要なのか、どういう信念で仕事をしているのか、そしてどのような実績を刻んできたのか。具体的なエピソードもたっぷり聞けましたよ！「SREのおかげで2ヶ月かかっていたリリース作業を1時間にできた」って凄くないですか？
はじめましての方は「弊社＝株式会社ポッケ」の1つだけ覚えてから読み始めてください💁
- SREの在り方は十人十色
- 弊社のSREの業務内容
- 自社コンテンツ事業の会社でSREの手法を取り入れるとメリットだらけ
- SREが弊社に必要だ！と気付いたきっかけは“つらさの自覚”
- SREチームが大切にしているのは「歩み寄りの精神」
- SREになりたい！と思ったら、まずは「やってみる」
- 弊社のシステムグループがいま抱えている課題
- 弊社で楽しく働いて世の中を笑顔にしたいSREさんを募集しています
- 弊社のSREさんたちにとってのSREとは？
インタビューに応じてくれたのはこの2名です💁
- システムグループ SRE keiさん
- システムグループ SRE junさん
――さっそくですが、ブログのサムネに使うお写真を撮らせてください。
keiさん：さっそくだけど、私たち顔出しNGなんですよ。笑
――尊重します！
とワイワイガヤガヤしていたところ、代理でこちらの2名がお写真に応じてくれました💁
- インタビューの立ち会いに来ていたこぼりさん
- 近くの席でインタビューの野次馬をしていたよこちんさん
※こぼりさんはこのあとのインタビューにちょいちょい登場してくれます
※よこちんさんは写真撮影のあとに自分の業務に戻りました
（あれ？この2人がお顔を隠す必要性とは？🤔🤔🤔）
SREの在り方は十人十色
keiさん：最初に伝えておきたいんだけど、前提として、SREの動き方や目標など諸々の事柄は企業やチームによって異なっています。だからあくまでも“ポッケでやっている事”として紹介していきますね。
――了解です！
弊社のSREの業務内容
――ポッケのSREさんたちは具体的に何を作っているんですか？大人の事情で書けないんでしたっけ？
一同：んーーー……
――具体性が守秘義務に敗北……ッ！
こぼりさん：マイクロソフトさんに私たちのプロジェクトを取材してもらったこともあるからいいんじゃないかな？
“なんちゃってアジャイル” から “本質的なアジャイル” へ――ベルシステム24 はどのようにして開発体制を変えたのか? – Microsoft Customers Stories
――それ読みました！突然のマイクロソフトさんにびっくりしました。
keiさん：その取材の内容は今回話すこととも繋がっているので、まだ読んでいない方は先にそちらからどうぞ！
――宣伝ありがとうございます！リンクをしつこく置いておきますね。こちらです。
keiさん：話を戻すと、私たちSREの主な業務は2つ。
- サイトの信頼性を日々向上させる
- 開発者のproductivityを向上させる
1つめは、サイトの死活監視をはじめとする監視業務や、スケーラビリティ、耐障害性を考慮した環境の構築や保守、アプリケーションや基盤のパフォーマンスチューニングといったことをしています。
2つめについては、私たちSREを含めたプロダクトチームではアジャイルをベースとした働き方をしているので、顧客に素早くバリューを提供するために開発者のproductivityの向上を支援しています。
開発者がプロダクト開発に集中できるように、SREは安全で容易にリリースできるリリースパイプラインなどの仕組みの提供をしたり、コードのビルドをはじめとする自動化の支援、マイクロサービス化の支援などを行なったりしています。
――というのを総勢何名でやっているんですか？
junさん：今は2人体制ですね。自分たちで価値を定義し、より良いプロダクトを届けられるよう支援を行っています。
――今日はフルメンバーでのインタビューですね。お忙しい中ありがとうございます！
junさん：チームが発足した当初はメンバーは1人で、人数が増えた時期もありましたがプロダクトとして機能ファーストの意識が強くSREに注力できずにまた1人に戻ってしまう……など混沌としていました。ですが徐々にアジャイルな働き方が定着しプロダクトチームの成熟度が上がってきたことで、メンバーの中からSREの必要性を感じて参加者が増えて現在の体制になったんですよ。
自社コンテンツ事業の会社でSREの手法を取り入れるとメリットだらけ
※読者に説明すると、弊社はWebサービスやスマートフォンアプリなどのコンテンツを企画・制作・運営するのを事業としている会社です。
――SREはポッケにとってこんなにも良いんだよ！ということを自慢してほしいです。
keiさん：この3つでどうでしょう。
- 繰り返し作業の自動化を図る
- 突発的に起こる障害に備えられる
- 開発vs運用が無くなる
――「1. 繰り返し作業の自動化」って「トイル」っていうやつでしたっけ？
keiさん：そうですね！人手でやらなくていい作業を見極め、ムダを省いていくことは重要ですね。
――弊社の仕事は手作業で真心を込めることができるタイプじゃないんで、こういう考え方は大切ですよね。
keiさん：時間を割くべきなのは「本来やりたいことの実現」のためです。トイルを減らすべく日々の業務を振り返って、自動化できるところは自動化していっています。
――「2. 突発的に起こる障害に備えられる」。どうしてSREさんがいると突発的に起こる障害に備えられるんですか？
keiさん：SREの仕事のひとつが「突発的に起こる障害に備える」っていうことなんです。「備えあれば憂いなし」じゃないですけど、よく例えられるのは「防災訓練」ですね。地震はいつ起きるか分からないから訓練するじゃないですか。
junさん：SREはシステムの信頼性を上げるというミッションを持っています。信頼性を上げる＝万が一落ちてもすぐに回復できる。SREが居れば落ちたときに戻すルートを用意しているので、落ちちゃっても「一旦戻しといたからゆっくり調査してね～」ってことができます。一般的によくある「原因調べなきゃ！やばいやばい！」とはならない。
keiさん：っていうのをちょっと格好よく言う！笑
――お願いします笑
keiさん：今、我々のプロダクトは徐々にクラウドに適応したアプリケーションに作り変えています。クラウドネイティブってやつですね。なんでかというと、元々オンプレミスの時（会社の中で動かしている時）は「壊さないように…」って扱ってたんです。対してクラウドのものってすぐ壊れるんですよ。笑 「壊れた時にどうするか」「壊れることを前提として修復・回復する」というのがSREのエンジニアリングのマインドですね。
――かっこいいです！！！
keiさん：かっこいいでしょ。笑
――頼れる存在！そして最後の「開発vs運用が無くなる」って永遠の課題だと思っていたんですけど、無くせるんですか。すごく「そもそも」のところを聞いている気がしていますが……。
keiさん：それがSREだから。。笑
――振りでした！
SREが弊社に必要だ！と気付いたきっかけは“つらさの自覚”
――SREという職種は弊社の中では比較的新しい職種・ポジションですよね。関わりが薄い部署には一体なんだか知らない社員もいるかもです。
keiさん：1年くらい前に必要性を感じてスタートしたので、そうですね。
――必要性。そう感じたのはどんなことがあったからですか？
keiさん：私たちが“いま作っているもの”の“前身”まわりで「運用つらしんどい」があって……
――「つらしんどい」っていう言葉いいですね。Slackの絵文字を作っておきます。えっと、傷口をえぐるようで申し訳ないんですけど、「つらしんどいエピソード」を詳しく聞きたいです。
keiさん：表現が雑になるかもしれないという前置きの上で噛み砕いて説明をすると、“前身のシステム”にはマンパワーが必要だったんです。どういうマンパワーかというと、夜間や休日の監視が必要だった。息が長いシステムなのにその事態は非常に「しんどい」ですよね。当時我々はアプリを作りながらシステムの運用をしていたので、運用に時間がかかる→作ることに集中できない……の悪循環で、それがつらくて。
junさん：運用の部分のつらしんどいについては同じ気持ち。“運用”と呼んでいいか分からないけど、“前身のシステム”はシステムを提供したときの監視の部分をあまりやっていなくて。やっている目視でログを見て「あー、大丈夫だね～」程度だったから……。
junさん：信憑性の高い監視を入れたくて＝エンジニアリングでどうにかしたかったんです。
DevOpsとSREの違いは○○○に注目
keiさん：そして最初はDevOpsチームとして始めたけど、今はSREチームとしてやってます。
――ああ…それ…SREはDevOpsとはどう違うんですか……調べたんですが世の中のみんな言ってることが異なるんですよ……。
keiさん：いまいちわからないですよね……でもSREの動きや目標など諸々の事柄は企業やチームによって異なるから……
――そうでした。弊社での役割について教えてください。
keiさん：よく言われているのは、プログラムに例えると、DevOpsが「インターフェース」で「SRE」は実装なんて言われていますよね。
DevOpsは思想とかカルチャーなんかを含んでいるのですが、SREはその思想やカルチャーを具体的にエンジニアリングでどう実現するかまで踏み込んでいると我々は解釈しています。まぁDevOpsを実現するための専門のエンジニアリング手法と捉えています。
ここで先ほどの「最初はDevOpsチームとして始めたけど、SREチームになった」につながります。
プロジェクトがスタートした直後は、プロダクトのローンチ前でまだ運用フェースではありませんでした、DevOpsを実現するにあたり、こうしていこう！みたいな指針的なものはあったのですが、具体的に誰が、どのように、どうするまで落とし込めていませんでした。この頃はローンチ前ということもあり、DevOpsの思想やカルチャーをチームで育むことが重要だったため、あまり具体的なところに時間はさかずまずこれらに注力していました。
ローンチが近づくにつれてやはり現実が見えてくるので、より誰が、どのように、どうするが重要だなと感じるようになってきました。今まで漠然とSREって必要なんだろうなと思っていたいのですが、これやらないとDevOps実現できなくない？となってSREを始めることを決めました。
――開発の人たちと運用の人たちで「せーの、DevOpsやるぞー！」では上手くいかなかったですか？
keiさん：うまくはいっていましたが、やはり足りないところだとかぼやけた部分は多かったと感じましたね。
SREで手ごたえを感じた事例
――この記事を載せている場所は企業ブログということもあるので(?)、弊社でのSREの仕事で手ごたえを感じた事例を教えてください。
こぼりさん：あれはすごいよ。Datadogを導入してみんなに発表したときのあの手応えはすごかったんじゃないかな。
keiさん：監視基盤を作って、それを基にプロダクト開発チームとコラボレーションしながらシステムをより良くする、ってところが文化として少しずつ根付いてきてます。導入だけじゃなくてコラボできた、ってのが手ごたえですかね。「これから良くなっていくんだろうな！」と感じ始めてます。
こぼりさん：あれも話そうよ。バリューストリームマッピングした時にリリースのところにほとんど問題がみつからなかったのはSREの力ですよ。
junさん：あぁそうですね。
keiさん：「リリースエンジニアリング」。“前身のシステム”だとリリースの信頼性が低かったんですよ。我々の取り組みで高くなったので、そこは効果があったかなと。
こぼりさん：これまでリリース準備に2ヶ月かかってたのが最短1時間で出せるようになったの。とんでもないことだよ。
――ひえー！すごい。
SREチームが大切にしているのは「歩み寄りの精神」
――SREさんたちに限らず、いくら最先端のやり方を学んでも実現できなかったら意味ないですもんね。精神論ではないですが、教科書に書かれていなさそうな心構えみたいなことってどのあたりなんでしょう。
keiさん：いわゆる伝統的なシステムのチームの形だと、1つのプロダクトの中で目指すものは同じだとしても、関わるチームそれぞれで役割とやり方が異なっていますよね。ということは必然的にそれぞれが守りたいもの（譲れないこと）なども違う。これを歩み寄りの精神を以って、砕いて関わっていきたいんです。
――語彙力があれですけど、優しい心の持ち主じゃないとできなくないですか。すごいです。
keiさん：まぁ難しいですよね。笑 自分のところを守ろうとして他とのコラボレーションが上手くいかないってことなので。切り込んでいかないとですねー。
――では未来の話を。ポッケのSREさんは将来的にどうなっていきたいですか？
keiさん：この3つ。
- 存在でポッケの仕事に関わる社員みんなの精神までも安定させたい！
- 数字を追いかけていく！
- 最終的には、組織のスケールにエンジニアリングで貢献していきたい！
「みんなの精神安定剤になりたい！」はさっきした話の感じですね。
――もうなりつつあると思います！ 次の項目の“追いかける”のは何の数字ですか？
keiさん：また前身のシステムの話になっちゃうけど、安定して動いてない・気持ちよく使えていないシステムで、でも「じゃあどうしたら良いか」にうまく繋げられていなかったんです。抽象的だったんですよ、「なんか安定してないよね」「なんか気持ちよくないよね」と。それをシステム稼働率という“数字”に落とし込むと「○○％が安定してないんだね」って分かるじゃんー！って。これからも「可視化」していきます。
――次の「組織のスケールにエンジニアリングで貢献していきたい」とは？
keiさん：内部の話です。コンテンツが成長していくとメンテナンスのコストが増えていきますよね。コンテンツがヒット→人員を追加→システムも大きくなります。サービスが大きくなると「x軸：規模 / y軸：つらい」のグラフが直線じゃなく二次曲線的になるんですよ。どんどんつらくなっていく。組織のスケールアップに耐えられるようにSREが日々メンテナンスやエンジニアリングしていけるようになりたい！
――おねがいします！
keiさん： 支えてるばかりじゃあれなんで、いいコンテンツを作っていってください笑
――がんばります！（※インタビュアーの私は制作の部署です）
SREになりたい！と思ったら、まずは「やってみる」
――「自分もSREの仕事をやりたい！」と思ったら、どんな準備をすればいいんでしょう？諸々が現場によるとのことなので、お二人はどうやったかを教えてください。
keiさん：まずは、本家の書籍を読むことですね。
O’Reilly Japan – SRE サイトリライアビリティエンジニアリング
――電子書籍版なら4,224円(※執筆時の価格)から！
keiさん：論文もありますよ！ただ読むだけじゃなくて、読んで得た知識を元に小さく部分的でもいいので試してみることですね！
keiさん：あと、これは我々もまだまだなところが大きいのですが、SREの業務はソフトウェアエンジニアリングであるため、ソフトウェアエンジニアリング、コンピュータサイエンスをはじめとした多岐にわたる知識が必要になります。最初から全部できる人はいないので、これもちょっとずつでも学習することが重要ですね。
――MicrosoftのHackfestに足を運んでいたというのはどのくらいの時系列ですか？
keiさん：これはSREを始めるずっと前の話ですね。まだDevOpsの文化すら無い状態の時からです。詳しくは記事を読んでみてください！
――ほんとだ……DevOps体制を築く前の話って書いてありました。。
keiさん：「SREは企業によって様々」という特性については、他社のエンジニアと積極的に交流することが効果が高いと思います。我々は「SREラウンジ」というコミュニティのイベントに足を運んだりしてます！いろんな会社での「つらしんどかった！」を別の会社のエンジニアと意見交換し、視野を広げる会です。必要性を感じたので交流している感じですね。
junさん：さっき「DevOpsとSREは何が違うの？」って話があったと思うんですが、「DevOpsを実現するのがSRE」です。そもそも私たちはDevOpsの時点で「ポッケのDevOps」をやっているのでポッケのものしか見えてないんです。「こういう形もいいんだな」とインプットするために行ってみるの良いですよ。
keiさん：行ってみると苦労話が多いんですよ！リーダー職の人がいっぱい来るのでDevOpsは組織とか文化にフォーカスするんですけど、いろいろ見えてきて味わい深いです。
junさん：個人的に発見としては、私がSREチームに赴任したときって「開発者の安心感」はそこまで考えていなかったんです。「運用がしんどいから自動にしたいな」が強かったんです。でも他の会社でそういう話をしている人がいて、「それ！うちもやろう！」って思ったので刺激を受けたというか。
こぼりさん：取り組みが「自動化」だけだとその時だけ「あぁ～ありがたいなぁ」と思って、いずれそれが普通になっちゃう。本来目指すべきところはそうじゃないよねー。
弊社のシステムグループがいま抱えている課題
――そもそも今回なんでSREさんにインタビューしたかというと、世の中にお知らせしたいことがあるんですよね？
keiさん：平たく言うと、エンジニアリングの範囲が広いんで、2人だと限界を感じ始めているからです！
――お二人のような超人が揃っているのにまだ手強い敵(?)がいるのですか…?!
keiさん：SREって様々なバックボーンを持っている人が多いのですが、我々はアプリケーション開発者出身ですので、インフラやネットワーク、データベースに近いところにいたバックボーンを持つエンジニア様がここにいたら更に助かるなぁと思うんです、切実に。
keiさん：某○NE PIECEに例えると、今のポッケのSREには“戦闘員”ばかりなの。“航海士”“コック”とかがいないの。笑
――今日イチで分かりやすい例えをありがとうございます＞＜
それではお待たせしました、ここからは求人情報のコーナーです💁
弊社で楽しく働いて世の中を笑顔にしたいSREさんを募集しています
……なんかやらせっぽいくだり！いいえ本当です！書いてる人もインタビューを受けている人もうちの会社の人です！！！
いきなり面接とか重いから話を聞きたいなぁ。みたいなご連絡も大歓迎！
あと、既にいる2名とバックボーンがカブっていたらダメなわけではないのでご安心ください…！
それでは！「我こそは✋」というSREさんからのご応募をお待ちしています🤗
↓弊社公式サイトの採用情報ページへどうぞ↓
https://www.pocke.co.jp/recruit/joboffer/job-sre/
最後はこの質問で。
弊社のSREさんたちにとってのSREとは？
junさん：凄く抽象的なやつでもいいですか？「心理的安全性をエンジニアリングで担保する人たち」なのかな、って思ってます。
こぼりさん：綺麗にまとめたなぁ
junさん：やることいろいろあるんですけど、全部「安心して使ってもらえる」「安心して開発に集中してもらえる」ってのが根底にあると思うんで。それかなって。
――keiさんもどうぞ！
keiさん：大体同じです！笑
こぼりさん：これ以上足しようがないくらい綺麗にまとまってたよね笑
keiさん：じゃあ別の視点から。「飽くなき探究心」！要は「安心してもらう」ことってそこだけで終わりじゃないんですよね。その先があるからやる。満足せずに探求するのが大事かなって思ってます。
――お二人ともさすが！そういうやつ欲しかったです👏👏 ありがとうございました～！
- ゆかと
- ポッケ入社は2012年・ゆとり世代のホームページ屋さんです。https化でいいね数がリセットされて悲しいので再いいねください。すきなもの→「電源」「Wi-Fi」「記録をする」
