ディスカッション中心のイベントSRE Sessionを開催しました

はじめに

開催しました！

sre-lounge.connpass.com

SRE Loungeという、各社SREが取組を共有する、プレゼンテーションメインの勉強会があります。これはこれで貴重な知見がたくさんあるのですが、やはり全員参加で、相互交流ができる会も欲しくなってしまいました。また、SREといっても扱う範囲は非常に多岐に渡るため、特定のテーマにしぼって語り合う会をやりたい！と思い、言い出しっぺに法則で立ち上げました。

テーマ選定

SRE Lounge Slackでアンケートを取った上位2テーマを選択しました。

(Public Chennelのものなので特にふせずにそのまま載せてます）

項目の元ネタはSRE 1st Book / Workbookから僕が適当にかいつまんだものです。

2テーマじゃなくて1テーマでもいいんじゃないか、と迷いましたが、実験的な会だったので読めなかったのと、幸運にもSLOとMonitoringはかなり関連性が強いということもあって2テーマでGoしました

アイデア

実はこの会はCloud Native Deep Diveからインスパイアされたものです。

www.meetup.com

実際、私は#4のMonitoring編に参加してこのイベントのやり方のヒントももらったりして非常に感謝しています。

Cloud Nativeの文脈とSREの文脈は、参加者層が微妙に違うような気がしつつも、共通する部分は非常に多いので、今後とも良いシナジーを出せたらいいなぁと思ってます！

公開後1番乗りでDeepDive主催の @jacopen さんが熱い思いで参加申し込みしてくれて嬉しかったですｗ

Welcome Talk

各テーマごとに、会場を温めることと、語彙の共有、トークのネタとしてWelcome Talkを話していただきました！

YahooのtsukaさんよりSLO

SRE Session #1 from Minoru Tsuka

www.slideshare.net

「誰のためのSLOか？」の一言につきます。この言葉はディスカッションでも多く話されたと思います。

メルカリspesnovaさんよりMonitoring

内容が盛りだくさんで後半巻いてもらったのがもったいないぐらい（再演をどこかで！）濃度がぎっしりの資料でした。RED & USEの考え方ははじめて知ったので非常に参考になりました。

ディスカッション

多いに盛り上がり、司会＆タイムキーパーの僕も熱中して時間がすぎてしまうほど（反省）。

それぞれ20分じゃ足りない感じだったので今後の改善につなげていきたいと思います。

感想

概ね多くのひとからも好意的なフィードバックをいただいており、本当にやってよかったと思います。

SRE本に書いている内容をどの会社も実践できているわけではなく、そのレベルや考え方も様々。それをディスカッションすることで良い点悪い点を議論し、今後のみなさんの実務に結びつく機会になっていれば幸いです。

振り返りと今後

事後アンケートを実施し、たくさんのフィードバックをいただきました。参加者のみなさんありがとうございました。

みなさんのフィードバックのおかげで、次回開催も決定しました！次回は6/5に開催を予定しています。（会場まで決定しており、準備中）

プレゼン形式のSRE Loungeと毎月交互でやっていきたいと思っているので今後もよろしくおねがいします！

最後に会場提供してくれたQuipper... のhiring-supportのみなさんとSRE @motobrewさんお手伝いいただきありがとうございました、この場を借りてお礼申し上げます。

"Graphic Recorder 議論を可視化するグラフィックレコーディングの教科書"を読んだ

読んだ。

Graphic Recorder ―議論を可視化するグラフィックレコーディングの教科書

クローズドでやっている勉強会で友人氏がこれを実践してみたって発表をしていたので読んでみた。

docs.google.com

この本、何が良かったって作者の思想がとても良かったです。

はじめに　より

本書が目指す世界、それは、年功序列、事なかれ主義、責任者不在を打ち破り、凝り固まった後ろ向きな空気に流されずに、どんなに難しくて気まずい関係の会議でも、諦めずに思考停止しない世界です。今もこの瞬間に日本の何万と行われている不毛な会議が、グラフィックでの記録によって前向きな思考と関係性に変えられたら少しずつ世界は変わるのではないか。そんな想いをこめて本書を届けます。

グラフィックレコーディング自体は単なる1手法に過ぎません。しかし、その手法が解決しようとしている問題が、未来が素晴らしいものだなと思いました。そしてまさにグラフィックレコーディングは現状の"会議"の問題を解決しうるツールだと思います。

また、おわりに、でもテクノロジーの進化に伴いグラフィックレコーディングの未来について語られていて、

齟齬の生まれる場所は、複雑で曖昧な感情や関係性の中にあり、音声情報だけでは決して読み取れません。情報の的確な整理はできえも、相手の考えに共感して協力しようと信頼しあえる関係性を生み出すような場づくりは難しいでしょう。そうなった時に、未来のグラフィックレコーダーは、正確性が問われる事実関係は機械に任せて、その分浮いた時間で参加者の一歩先の理想を想像しながら新しい「視点」を提供するようなグラフィックを描くことが、今以上に求められるのではないでしょうか。

と、やはりグラフィックレコーディングの持つ価値は飽くまで議論の活発化・明確化だとわかった上で、そのようなツール・手法が今後も必要になっていくという点を示しています。

グラフィックレコーディングとは

会議を図や絵を用いて内容を整理することにより、

• 一覧性の向上 / グラフィックによる具体化による参加者間の齟齬を最小化する
• 参加者同士という視点から問題対私たちという構図を強制することによる議論を建設的にする

といった効果をもたらす考え方 / 手法です。

グラフィックレコーディングの本質的な点は上記だと私は感じました。

グラフィックレコーディングのある日常

私は一通り読んだ後、絵・アイコンをすばやく・わかりやすく描く技術を伸ばすかと言うと多分やらないと思います。（今は困っていないので）

そもそも私は会議自体そこまで多くないのですが、例えばチーム内で情報の共有をするときはホワイトボードをよく使います。 特に複雑なアーキテクチャの理解や、運用手順の理解をするとき、図は非常に有益です。そういう意味で普段からグラフィックレコーディングを実践していることになります。

（この本がより一般的・汎用的にしていることを理解した上で）私たちソフトウェアエンジニアはおそらくペンで文字を書くよりキーボードで打ったほうが速いと思います。そのため、実際の私たちの現場では「事前に共有事項を絵、あるいはGitHub Issueに（構造化して）書いておく」「実際に話しながら、ホワイトボードに書いたり、GitHub issueに追記したりして会議を記録する」「会議のゴールが達成できたら終わり」って感じの流れが多いです。

本書の例では絵では描ききれない点は文字で補っていましたが、おそらく速度に限界がある（可読性とトレードオフ？）と思っていて、その点はキーボードによる打鍵での文字情報の記録とうまくコラボレーションできればいいなと思いました。

前述の通り、私は仕事をどう行なうか1人で考えるときにノートとペンでまず書きますし、例えば近くのチームメンバーに何か説明するときに使うこともあります。日常的にグラフィックレコーディングを使っていました。名前を与えるということは大事ですね。

おわりに

グラフィックレコーディングという手法にだけ焦点をあてるのでなく、解決したい課題に強くフォーカスして伝えていた点が非常に良いと思いました。この方法で会議を効果的なものにすると同時に、「この会議はなにを解決するのか？」という点にフォーカスしたり、同様の解決ができる別の手法と組み合わせて使ったりして、日本の無駄な会議が減ることを願っています。

2019年1Q振り返りと2Q

なんか1Qどうするの表明もしてないしなんか年始に毎週ブログ書くとかいって書いてないしまぁそんなもんだよね。

1月から3月、冬休み明け気合を入れて、というのもあったし、単純にできることが増えた、というのもあったが、いい意味で忙しくできていたと思う。 仕事を通じて技術的に新しいことを学んだり（特にCDNについて学べた）Vimの勉強会にうっかり参加してVim力をあげたり。 あとは会社ブログに少しずつ出していこうと思っているが、Microservicesの受け入れ準備的なものを子issueに分解して少しずつ進めていっている。

2月はフィリピン・マニラに同僚の結婚式ついでに1週間マニラオフィスで働いて「基本的にすべて一発で英語が聞き取れない」という事実を持って返ったりしました。

結局この3ヶ月で何ら具体的に英語学習に関するアクションができていないんですが、いよいよやろうかなと思えたのはSREConのCFPが通ったことですね。 もともと12月から2月ぐらいにかけてオンボーディングに取り組んでいて、一通り済んだ＆そういえばグローバルメンバーもなんか興味持ってたってことで 英語でサマリまとめてshareしよう、ついでにSREcon出すだけ出そう！と思ったら通ってしまったという感じです。6月シンガポールです。

www.usenix.org

国内ですら大きいカンファレンスの登壇経験ない（小規模勉強会でのLT程度の経験しかない）のにいきなりマッチョなことしてしまったなぁと思いつつ、まぁ順序なんぞないし、前向きに楽しんでいこうと思っています。 Talkは内容だけで審査するため、個人や会社を特定できる情報は書かないでください、とあったのが、公正でいいなぁと思いました。 LTの募集もOpenしてるみたいなので誰か一緒に行きましょう。

We will accept lightning talk proposals starting on Friday, March 22, 2019

英語の勉強ですが、発音を直してもらいながら学ぶ何かをしたいというのと、Listingの訓練をしたい。で、どうするかって感じですが、 後者に関してはSREconの過去の発表を何度も見て聴くというのをやるつもり。YouTubeの字幕機能でなんとか。英語学習に関しても便利な世の中になりましたね。 発表資料どんなもんかな？っていう勉強もかねて。前者はどうすっかな。そういうていで英会話的なsomethingやるしかないな。

Readingは最近を読んだりもしてるけど、技術学習で英語から学ぶ割合を増やすしかないと思う。さいわい日本語でも学びきれないほど豊富に情報があるけれど、やっぱり新しいこと、これからなこと（特にKubernetes, Microservices, Service meshなんか）は英語のほうが早いし多い。こっちをがっと読んでばっと要点をとってくる筋力をつけたいと思う。

とはいえ、英語に懸念がありつつも、大事なのは中身だと思うので、今回SREで実施した内容に加えて、SREを越えて適用するには、みたいなところもトークに入れ込もうと思っています。 なんか各国のエンジニアチームもオンボーディング重要だと思ってるけどどうしよう？って悩んでるみたいで、「おれの取り組み共有するぜー」って言ったら「うちらも悩んでるのだ！Let's join us！」みたいになってグローバルのオンボーディングyatteiki隊に加入してしまったのでこれを活かしてなんかいい感じにTalkのネタ増やしていきたいと思います。

それと同時に、ちょっと2Qはある程度このTalkと今やってる業務にフォーカスする必要があるなぁと思いました。 ついつい興味が散ってなんでもかんでも手を出しがちな性格なので、意図して時間の使い方を制御しよう、と思ってブログを書こうと思った次第。

登壇や発表より、目の前の課題を解決することが大事なことはわかっていますし、組織のことと同じだけ、技術力が大事なこともわかっています。

それでも僕はOSSや、コミュニティのおかげで今のポジションになれたので、今年はコミュニティ活動もやっていきたいと思っています。

コミュニティのおかげでSREを目指すことができたので、コミュニティに恩返ししたいという気持ちがあるっぽい。

— 🤔 (@chaspy_) March 14, 2019

SRE Loungeは運営として携わっていますが、4月はSRE Sessionを企画したり、あと今年中にビックなことができたらいいなぁと画策していたりします。

sre-lounge.connpass.com

技術的には、メタなところではクリーンコード的な視点でちょっと学ばないといけないなぁと思っているのと、 やっぱり作業環境の"速度"(Vim, terminalなど)がまだまだ足りないのでそこは継続的にやっていきたい。 経験が足りないのはどうしてもしょうがないので知識＋目の前の問題を解決しながら学ぶってやっていくしかないね。

おしまい。

"失敗から学ぶRDBの正しい歩き方"を読んだ

読んだ。

失敗から学ぶRDBの正しい歩き方 (Software Design plus)

知見の宝庫。著者の曽根さんが本書を書く理由を「知見を後の世代につなぐため」といったことをおっしゃっていて（Twitterから見つけきれず。。。）本当にありがたいと思いました。この本自体も様々な参考となる本が紹介されていて、さらに次の学びへつなげることができるようになっています。

本書の中では、「フラグの闇」が印象的でした。これまで削除フラグにより論理削除と呼ばれるものはよく見てきたし、特に違和感を持っていませんでした。しかし、クエリの複雑化（かつ、影響が広範囲に及ぶ）、UNIQUE制約が使えなくなる可能性がある、カーディナリティが低くなる、といった理由があげられており、便利なのはわかる反面デメリットもあることを学びました。

そしてメタな考え方として「DBには事実のみを保存する」（＝状態を持たせない）というのが今まで考えていなかった考え方でした。

削除フラグが利用したくなるシーンでも、まず他の方法でできないか検討してからデータベースで状態をもたせるか検討したほうが良さそうですね。

最後に目次をのせて自分の中のINDEXに保存して終えようと思います。

• 第1章 データベースの迷宮
• 第2章 失われた事実
• 第3章 やり過ぎたJOIN
• 第4章 効かないINDEX
• 第5章 フラグの闇
• 第6章 ソートの依存
• 第7章 隠された状態
• 第8章 JSONの甘い罠
• 第9章 強過ぎる制約
• 第10章 転んだ後のバックアップ
• 第11章 見られないエラーログ
• 第12章 監視されないデータベース
• 第13章 知らないロック
• 第14章 ロックの功罪
• 第15章 簡単過ぎる不整合
• 第16章 キャッシュ中毒
• 第17章 複雑なクエリ
• 第18章 ノーチェンジ・コンフィグ
• 第19章 塩漬けのバージョン
• 第20章 フレームワーク依存症

SLO: Service Level Objecive(2) from SRE Workbook Chapter2

blog.chaspy.me

次、Workbookを引っ張ってくる。

余談だが、SREになる前にいろんな(SRE / DevOps / Infrastructure as Codeなどに関係する)本を読み漁っていて、今になっていざ現実の課題に解決する場面になって引っ張り出すというシーンが多くなってきた。とってもいいことだと思う。

ちなみにWorkbookにはSLOに関する章が3つもある。SREのCore Principleなだけある。

• Chapter 2 - Implementing SLOs
• Chapter 3 - SLO Engineering Case Studies
• Chapter 5 - Alerting on SLOs

今回は基本的な実装方針である Chapter2と、それをどう文化的になじませるかのケーススタディを書いたChapter3を流し読みしていく。Chapter 5はMonitoringと組み合わせてのAlertingの話なので、まだ先の話ということでpass。

しかし全章目次とintroとsummeryだけ読んでメモっておいてよかった。

SRE Lounge#6で「The Site Reliability Workbook」について登壇してきました - ツナワタリマイライフ

Chapter 2 - Implementing SLOs

Google - Site Reliability Engineering

. Service level objectives (SLOs) specify a target level for the reliability of your service. Because SLOs are key to making data-driven decisions about reliability, they’re at the core of SRE practices

だいじ

We’ll then cover how to use SLOs to make effective business decisions, and explore some advanced topics.

最終的にはビジネス的な意思決定のためにある。

Our experience has shown that 100% reliability is the wrong target

100%を設定するのは間違っている(reasonableではない)

で、SLIの例をhttpリクエストだとかgrpcだとかであげてくれつつ、最初にSLI/SLOをどう決めて実装したらいいか、といったところで

Your first attempt at an SLI and SLO doesn’t have to be correct; the most important goal is to get something in place and measured, and to set up a feedback loop so you can improve.

に安心感を覚える。

で、はじめるのはシンプル

• SLOを定義したいアプリケーションを決定する
• "users"(enduser)を明らかにする
• そのアプリケーションをユーザはどのように体験するかを考慮する
• 抽象的なアーキテクチャダイアグラムを作成する。
  • key components, request flow, data flow, critical dependenciesを含む

これ、ちょうどいまProduction Readiness Checklistをやってて、そこでarchitecture diagramを書いてってお願いしていて、「何が含まれてればいいんだ？」って考えてたのとほぼ一致してびっくりした。

ここで架空のシステムを例にSLIの設定方法が説明されてるんだけど、こんなにやんの？！って思ってしまった。

Type of serviceとType of SLIの対応表が以下。ただこれだけネタがあると選びやすい気がする。

Type of service	Type of SLI
Request-driven	Availability
Request-driven	Letency
Request-driven	Quality
Pipeline	Freshness
Pipeline	Correctness
Pipeline	Coverage
Storage	Durability

(descriptionは本を読んでね)

で、このSLI Specificationから次はSLI implementationにうつる。

まぁ実装に関してはlogなりmonitoringなりでありものを使ってやればいいしどうしても今の仕組みでは計測できないものがあったとき実装を考えるぐらいでいいのかなぁと思う。この本にもengineering workが少なくて済むもんにしなよと言ってる。

でSLOの計算方法とかはまぁそうやねって感じで。

次にSLOのTimewindowの話。例えば月というか30日でやると、週末の数が違ったりするからweeklyがいいよと書いてある。

long(quater)とshort(week)にはそれぞれ利点があって、4weeksぐらいがだいたい一般的にいいんじゃない？ということでした。計測可能なら全部計測したらいいよね。

そして StakehodlerとのSLOの合意。 - Product Manager - Product developer

Once all of these points are agreed upon, the hard part is done.

これができれば大変な部分は終わったようなもので、この合意が将来に渡ってまた難しくなることがあるよ、と言っている。

というわけで、残りは繰り返し改善していくこととadvanced tipsなので流し読み。

おわりに

SLOの導入の仕方がかなり丁寧に書かれていてよかった。SLOやるぞ！どうすれば？ってひとはこの章の前半部分を読むとよろしい。

鍵はどのSLIを設定し、定めたSLOをステークホルダーと合意する、そのプロセスだと思いました。あとはそれだけに終わらない継続的な改善。

エラーバジェットによる開発と信頼性向上のバランスについて合意を取るのが難しそうですが、ひとまず安定しているプロダクトだとSLOの決定と観察からはじめてみてもいいと感じました。

Chapter 3 - SLO Engineering Case Studies

次回！

SLO: Service Level Objecive(1) from SRE 1st book

SLO, SLO, SLO.

言葉の意味は理解しつつも、実際に身をもって使うことができてない言葉だ。そんなこんなでいよいよSLOちゃんとやりますかねと言ったところでSLOってなんだっけってのを深いレベルでちゃんと理解しないとなと思ったので筆を執った次第。

重たい1st SRE bookを引っ張り出してきた。

1.3.2 サービスのSLOを下回ることなく、変更の速度の最大化を追求する / Pursuing Maximum Change Velocity Without Violating a Service’s SLO

landing.google.com

• 信頼性目標は100%であってはならない
• エラーバジェットを使い切ると新規開発はできない

100%からSLOを引いたものがエラーバジェットである。SLOを下回った場合は、SLOを回復させるための作業に注力する。ただそれだけだ。

エラーバジェットがなぜあるかというと、開発と運用の対立構造が前提にあるように感じる。それを客観的指標で解決しようとしたのがエラーバジェットという考え方だろう。

4. サービスレベル目標 / Service Level Objectives

landing.google.com

結局、SLOというか、SLIをどうやって、それに決めればいいかわからないからもやもやしているのだと気づいた。

4.2.1 サービスの提供者とユーザの関心事

にあるように、すべての指標がSLOになるわけではない。ユーザが何に関心を持っているか。そしてそれによってプロダクトとして何を重要指標とするか。それで決まる。

したがってやっぱりこれはテクニカルに、SREとそのサービスの技術者だけでは決めることができず、プロダクトという単位で決める必要がある。

おわりに

現在、Microservicesを受け入れる基盤ができ、少しずつMicroservicesが生まれ始めている。その中で、テクニカルな（microservices文脈での）サービスに対して、技術的な責任を持つサービスオーナーと、ビジネス的な責任を持つプロダクトオーナーを定めようとしている。（プロダクトオーナーはプロダクトマネージャという言葉でのプロダクトという言葉があるし、言葉の定義はまた変わると思うけど、とにかくmicroservices文脈/単位での技術的責任と、それらを包含し利用するプロダクト/ビジネス責任を定める必要があるが、現状様々な歪があるという状況だ。）

SLOは、この後者のビジネス的責任を負う組織が決まらないと、決めることができない気がする。

Production Readiness ChecklistでStakeholderを決め、Service Owner / Business・Product Owner / SRE とでSLI ・SLOを合意、その共通認識を持って進めていこうね。この基準だけは守るようにみんなでうまいことやっていこうね。そういうのが目指す姿な気がしている。

SREのjob descriptionを眺めてみる（国内編）

海外編があるのかは知らない。

はじめに

最近job descriptionを見直す機会があったので、他社はどうなんだろうとふと思いついたので眺めてみる。

さて企業をどうチョイスするかという問題がある。SREのカンファレンスは国内にはないので、お世話になっているSRE Loungeに登壇されてる企業さんを見てみようと思います。

Indeed

なんか2つあったので新しいっぽい番号のほうをみてみる。

Systems Engineer, Site Reliability Engineering (SRE) / サイト信頼性エンジニア - External Careers

ミッション、サービス規模が書いてあっていいですね。あと24/365対応できるよう、いろんなタイムゾーンにSREがいるようでいいですね。Responsibilitiesもせやなって感じ。

Minimum Qualificationsはあまり厳しくしぼっていなくて、CSの学士か相当のもの、Coding Skill、Linux/Unix OSの経験。

Preferred Qualificationsもまぁせやなって感じで、あまり厳しい感じにはなっていないようでした。

ランサーズ

募集してないようでした！足りているというのはいいことですね。

スタディプラス

教育系ITでトップクラスのトラフィックを支える一人目のSREエンジニアを募集！ / スタディプラス株式会社

1人目🤔

業務内容はわりとしっかり書かれていいですね。stackshareにリンク貼られてる点も。

インフラはAWSとだけしか書かれてないので、AWSで使ってるサービスや、アプリケーションがどこでどう動いているかもかかれてるとなお良いですね。

オプト

募集なし！よいことですね！

ヌーラボ

募集枠・JDは公開されてないようでした。エンジニアは積極募集してるわけじゃないのかな。

ヌーラバーになりませんか？ | ヌーラボ

Wantedly

コーポレートサイトからはたどりつけず。WantedlyなのでWantedlyにのってるかなと思ったらのってました。

インフラエンジニアという名前ですがこれでしょう。

そろそろ就活？まずはインターンで会社の中身を知りたいインフラエンジニアへ - Wantedly, Inc.のインフラエンジニア新卒・インターンシップの求人 - Wantedly

3つの軸いいですね。

- ビジネスの変化や、技術の変化を受け入れるインフラ 
- エンジニアの生産性を上げるインフラ（開発基盤） 
- 堅牢なインフラ

Kubernetes / Istio と使用しているソフトウェアがちゃんと乗っているのも良いです。

あ、これインターンですね。

Wantedly, Inc.の会社情報 - Wantedly からはSREにたどり着けませんでした。募集してないのかな。

Folio

コーポレートサイトからこちらに飛べました。

大規模なFinTechサービスを支えるSRE募集！ - 株式会社FOLIOのインフラエンジニア中途の求人 - Wantedly

我々はMicroserviceとマルチクラウドの世界を描いています。

と重点をおいているテーマがのっていていいですね。

必須・歓迎条件とともに、かなり具体的な使用技術が書かれてあるのもわかりやすくていいです。

freee

freee k.k. Careers - SREエンジニア：eng

【取り組んでいただく課題の例】 がきっちり書いてあって応募者のやる気を駆り立てそうでいいですね。

応募資格の 複雑なWebアプリケーションの開発・運用経験 、複雑なWebアプリケーションってどこからだろう？と気になりました。

ソフトスキルというか、性格面に言及しているのはマッチングを高めそうです。

【下記どれかにピンと来る人歓迎】
・面倒なことは全部自動的にやってもらいたいと思う 
・前例にとらわれず、本質的な価値を追求したい 
・常に新しいことに挑戦していたい 

メルカリ

Mercari, inc. - Jobs: Software Engineer, Site Reliability - Apply online

必須条件が実際の業務に結びついていそうで、簡潔かつ最小限で良いと思います。

メルカリさんはMicroservice Platformとチームが別なんですよね。そこが他にはないので説明があるとなおよさそう。

Gunosy

Backend System/Site Reliability エンジニア(BSE/SRE) | 株式会社Gunosy

Indeedと同じくCS学士が必須に載っていますね。他の必須条件も、クラウド・Infrastructure as Code・パフォーマンスとSREで必要な素養が網羅されていていいですね。

Gunosy事業への共感

をあえてあげているのも他ではみなかった点ですね。

Speee

【デジタルトランスフォーメーション】SREエンジニア / 株式会社Speee

必須・歓迎ともにゆるめに書かれてますね。そのかわり使用技術が細かく書かれているので良いですね。

おわりに

だいたい同じようなこと書いてるなあと思いつつ、会社によって微妙な差異があって面白いですね。個人的には公式のJDが決め手になることは少ないにしても、「応募してみようかな！」って気持ちにさせるには、挑戦できる課題や、細かい使用技術、大事にしている文化等あるとなお良いと思いました。

QuipperではSenior SREを募集しています。

Quipper Japan | 採用情報 | 募集要項