30億のデバイスで走るHonMarkHunt

JavaとJavaScriptと恐竜の絶滅について書いていきます。

株式会社ミクシィに入社して家族アルバム みてねのSREをやります。

はじめに

タイトルのままですが、2022年5月1日から株式会社ミクシィで家族アルバム みてねのSREをやります。

mitene.us

転職しようと思った経緯とか、転職活動した感想とかさらっと書いておきます。

Why ミクシィ

まえおき

一言で表すと「子供が生まれて世界が変わったから」です。

正直、子供が生まれる。という事象がここまで自分の人生に変化をもたらすとは考えていませんでした。月並みですが、本当に子供が可愛くて一挙手一投足のかわいさに幸せを感じており。また、小さいながらに日々どんどん成長を見せてくれる姿にて幸福度のボルテージが夫婦二人暮らしだったときの上限値を毎分天元突破し続けています。

そんなある日、前職(ビズリーチ)の同僚(チャブ)から子供関連のサービスの会社に入社したとLINEがありました。そのサービスは自分もよく使っているものだったので「え〜使ってるよ〜すごい〜」くらいにしか思っていなかったのですが、時間を置いて考えてみると「エッ!!子供向けのサービスやるのめっちゃいいじゃん!!」って思いました。

理由づけ1:作りたいサービスがなかった人生でした

自分は今までのキャリアで「このサービスがやりたい!」と言う気持ちで会社を選んだことがありませんでした。どちらかと言えば

  • どんな技術を使っているか
  • どんな人が働いているか

で会社を選んでいました。 実際振り返ってみても、アドテクをやったり、ECをやったり、HRやったりしてかなりブレブレです。 そんな中、初めて「アッー!自分の子供に関わるサービスをやりたいな!」と言う天啓を得たのが理由の一つです。

理由づけ2:C向けのサービスやったことないお

前回のエントリーにも書いた大変なこと/できないことにチャレンジし続けると言う考え方をすごく大切にしています。

自分は直近の経験でC向けのサービスでエンドユーザーからバチバチリクエストが来まくる。みたいな経験をしたことがありません。これも

  1. 今まで通りSaaS事業をやる
  2. C向けに挑戦する

という2つの選択肢がありますが、より大変な2の「C向けに挑戦する」を選びました。大変なことも多々あると思いますが、今後のキャリアにおいて絶対に大切な経験になると信じています。

ミクシィに決めました

そんな中で色々ご縁があって3社選考を受けさせて頂きましたが、その中でみてねを選ばせて頂いた理由をサラッと書いておきます。

1. 最高の家族アルバム

選考が終わったあと人事の方と何回かフォローアップ面談をさせて頂いたのですが、その中で「自分の子供が大人になって結婚した時に、最高の家族アルバムとしてプレゼントできるように。そこまでサービスを残せるように。皆日々仕事してるんですよ。」とお話ししていただき「え!なにそれ〜すごくいいじゃん」と感激しました。

2. みまもりGPS

mitene.us

家族アルバム以外にも「みてねみまもりGPS」などの製品もあります。自分なりに勝手にこの製品ができるまでのプロセスを勝手に想像してみました。プロフェッショナルな大人たちが集まって、子供のために何ができるか真剣に話し合ってる姿が容易に想像できました。子供のためのサービスをやりたい自分にとってめちゃいい環境だなと心温まりました!

3. 人

面接までのプロセスでチーム方々と何回もお話しさせていただきました。 皆めっちゃいい人たちで(選考受けさせて頂いた会社はもちろんどこもそうでした)前述のできないことに挑戦するという部分に心理的に安全に挑むことができると考えました。 また、SREは人が少ないのでチームとして長期間運用している組織はあまり多くありません。SREの組織としての貴重な経験も詰めそうだなと考えました。

4. インフラ

みてねのインフラはkubernetes(EKS)で運用されています。 k8sの大規模運用の経験もなかなか詰めるものでは無いなと考えました。

(勝手にリンク貼っていくスタイル)

「家族アルバム みてね」におけるAmazon EKSへの移行の取り組み / CNBF 202001 - Speaker Deck

2022年の転職活動メモ

自分が前回しっかりと転職活動したのはビズリーチを受けたときの2018年が最後です。そこから4年ぶりの転職活動で浦島太郎だと感じたのでメモがてら書いておきます。

めっちゃきつい

2018年当時の転職活動は「めっちゃ楽勝〜」というのが記憶に残っています。面接も全部で3回程度で、3回目には内定と条件も提示されるようなイメージで1~2週間で全て完了していました。これは、エンジニアが超売り手市場であり優秀なエンジニアはどこも喉手で欲しい。という時代背景があったためと思われます。

「え?何なら2022年の今の方が売り手市場じゃないの?」と思った皆さん。私もそう思っていました。

3社受けましたがざっとまとめるとこんな感じでした。

  • 最低でも面接は5回
  • 一番多いところは7回
  • 技術試験も必ず有り
  • 内定通知面談も複数回有り

2018年とは全然違いました...。 面接の回数も質問の質もプロセスも何もかも違いました。1社受け切るだけでも大変な労力です。正直3社終わった後はまじで疲労困憊でした。

なぜこんなに過酷になったのか

個人的には2018年ごろは「エンジニア足りない」と言う認識が急速に広まったピークの時期だったのでは無いかと考えます。そして至る所で簡単な採用プロセスで人を採用しまくった結果、ある問題が発生したのではないでしょうか?

それはブリリアントジャークです。

note.com

とにかく人を採用したら「 会社に合わない人組織を乱す人チームとうまくコミュニケーション取れない人 などが組織に溢れ返ってしまい結果生産性が落ち込んだ。」と言う経験を各社がし、業界全体で「コストをかけてでも自社にマッチする人だけを採用した方が、結果生産性は高くなる。」と気づいた。

実際皆さんも、チームに何となくコミュニケーション取りづらい人がいて、仕事しづらいな。と思った経験は一度はありませんか?

それ避けるために面接のプロセスを長くし採用を絞ると言う結果になったのではと考えました。

対策

企業ごとにValueやMissionのようなものがあると思います。 面接のプロセスではそことマッチするかどうか見られていると感じました。

これに関しては面接時点でどうにかなるものではなく、単純に合う合わないの問題なので落ちたからと言って個人の能力の問題ではないと切り離して考えるのが唯一の対策かなと思います。

逆に採用を絞らず2回程度の面接でドンドン人を雇っている企業の方が、後々組織的に大変なことになりそうなので避けた方がいいのでは?と言う気づきを得ました。

(ま、私は3社全部受かったんですけどね、初見さん)

まとめ

みてねやっていくよ!

株式会社ビズリーチを退職しました。

f:id:HonMarkHunt:20220418153410p:plain

はじめに

うす!

HonMarkHuntです!私事ですが先日、2021年4月30日を持って2年半務めた株式会社ビズリーチを退職しました!辞めるまでに色々考えていたことだったり、これからに向けて考えていることだったりを頭の中から外に出すために久しぶりにブログを書くことにしました!

*ていう文章を去年くらいに書いて放置してたのですが、諸事情でQueueが詰まってきたので今更完成させませました。大丈夫、退職エントリーはいつ書いたっていい!大丈夫!

目次

  1. そもそも何故BizReachに入社したのか
  2. 入社してからやったこと
  3. なぜ辞めたのか
  4. 後悔していること
  5. これからのこと

1. そもそも何故BizReachに入社したのか

超ざっくり改めて自分の経歴ですが

2015年 株式会社ラクス 入社
2017年 株式会社ラクス 退社 個人事業主として開業 フリーランスとして株式会社サイバーエージェント 参画
2018年 株式会社サイバーエージェント 退社 株式会社ビズリーチ 入社
2021年 株式会社ビズリーチ 退社 <- 今ここ(ではない)

こんな感じでした。

大体2年スパンで転職をしています。フリーランスとしてしばらくやってましたが、改めてビズリーチ入社に際して会社員に戻ったのはほぼ100%住宅ローンのためです。

honmarkhunt.hatenablog.com

この辺でも書きましたが結婚したので家でも買おうかなと思ったのですが、フリーランスだと住宅ローンの審査がほぼ100%通らないので正社員になりました。(楽天カードの審査も落ちた)

あとは

  • 渋谷の会社
  • 今っぽい技術でwebアプリっぽいこと
  • 立ち上げフェーズやりたい

くらいで考えていたら1社目に受けたBizReachが話聞いてみて良かったのでそのまま入社しました。当時8月くらいでしたので暑くて移動が億劫だったのでもうこれ以上選考を受けたくないと言う気持ちがあったのも覚えています。

2. 入社してからやったこと

入社してからやったことを思い出せる限り書いておきます。

自分はHRMOSという事業に携わることになりました。従業員エンゲージメントをいい感じにするやつです。

hrmos.co

リリースフローの整備

入社して最初は とあるプロダクト の開発に参入しました。後にお蔵入り aka. 凍結になることになるのですが、名前を出していいのかわからないので一旦伏せておきます。

この時は自分が何者かよくわかっておらずフロント(Angular)をやったりバックエンド(scala)をやったりインフラ(AWS)をちょっと触ったりしてました。

その中で特に負を感じたリリースフローの整備を始めました。詳細は省きますがJenkinsを使った定期リリースからCodePipleineを使った自動リリースに変更しました。 このリリースフローはアップデートはありつつも、今もそのまま使われています。中々いい仕事をしたなぁと自己肯定感を上げておきます。

この時の経験からこんな発表をさせてもらったり

www.slideshare.net

この発表が縁でCircle CIさんのイベントを弊社に誘致させていただいたりしました。

circleci.connpass.com

少し話がそれましたので戻ります。

この時はCIの改善と言うタスクをチームのスクラム外でやっていたのでオンタイムに取り組む時間がなく土日にやったりしてました(今やったら大変なことになる)。この時の苦しさから自分の感じる課題感を言語化してチームに理解してもらってチームのタスクに昇華すると言う能力の必要性を学びました。チームから見ると「なんかよくわからんタスクを1人で苦しそうにやってる人」みたいに見えてた気がします。

今思えばですが、当時は全然CIのこととかよくわかってなかったです。やりながらクソハマりながらなんとかかんとか実装していた記憶があります。できないことでも「俺がやります!」というマインドはすごく大事だなと実体験を通して学びました。加えてやります!と言った後にオーバーワークにならないようにタスクをいなしていく能力の必要性も学びました。

1on1の設計と立ち上げ

とあるプロダクト の開発が止まり、新しく1on1の管理ツールの立ち上げチームになりました。こちらはお蔵入りにならず今も販売されています。(買え)

hrmos.co

自分のやりたかった立ち上げの仕事なのでアゲ↑でした。みんなでモデリングをしてDB設計をしてと言う日々を過ごしていたのを覚えています。この際にバックエンド側の根幹の設計と実装の半分は自分が作りました。(もう半分はチャブ)

設計に関しては今も大枠はそのままで動いていて、後に追加される機能も見越してのだったので自分が離れた後もその追加機能がうまく乗っかっていたのでこれもすばらい仕事をしました。(もちろん後で実装を追加したみんなが凄腕だったから)

逆にモデリングの方は失敗してしまいました。 しばらく運用を続けていたらかなり苦しい箇所が出てきたので後に結構長期間のリファクタリングを実施することになりました。

ただ、これは考え方によっては反省だけではなく、最初わからん状態から運用を始めてドメイン知識が増えた分をプロダクトに反映させたと考えれば技術的負債の観点としては割と正しくもあったのかなと思います。難しいね。ただ、リファクタリングの期間が流石に長すぎたのでやっぱり反省です!

「技術的負債」とは何か。原典とその対応策を探る - Publickey

合宿の開催

開発合宿を主宰しました!! テックブログに書きましたので合宿の面白い詳細はそちらをご覧いただければなと思います!

engineering.visional.inc

この合宿については本当の偉業です。今の自分があの時に戻ったとしても、もう一度開催できるかどうか怪しいです。過去を振り返って自分を褒めれる数少ない実績です。そもそも合宿の実績もなく予算や合意や参加者や場所やあれやこれやこれやあれや果てしなく問題が無限に続いていたのを1つづつ潰して行って周りの人にも恵まれました。これは本当に貝瀬さんとマチャと横田さんに助けてもらいました。

ちなみにこの時の自分は合宿に行きたかったわけではなくて、組織の雰囲気やコミュニケーションに課題を感じていてその打開策として合宿を思いついたと言う感じでした。 ここも周りにうまく共有できていなかったので、周りからすると「なんか知らんがとてつもなく開発合宿に行きたがってる漢」に見えていたと思います。課題間が共有できていれば協力者と賛同者が増えてここまで大変な思いをすることはなかったかなあと学びました。

SREチームの立ち上げ

内輪ネタだらけになるので割愛しますが、もの凄い色々なことがあり自分を含めた4人でSREを立ち上げることになりました。

全くの手探りで1から courseraのこのコース をみんなで履修してSREについて学びました。学んだ内容についてはチャブがBIT VALLEYで発表していたので乗せておきます。

www.youtube.com

たまたまチーム4人全員すごくおしゃべりだったので隙あらば最近買ったガジェットを紹介しあったり3Dプリンターで作ったもの見せてくれたりして単純なエンジョイ度ではこの時が一番楽しかったです。SREチームとはなんぞやと言うこととData Dogでどう表現するかなどを学びました。

育児休暇

f:id:HonMarkHunt:20210507135713p:plain:w100

少し本題からそれますが、幸いなことに子を授かりまして2020年2月から半年間の育児休暇を取得しました。

「半年育休とったンゴ」と言うとほぼ100%「え!男の人で育休取れるんだ!いい会社だね!」と言われましたが、育休は国の制度なので会社は関係なく全員取れます。取らないだけです。

実際送り出して頂いたチームの皆さんにはすごく感謝していますが、取れて当然の権利なのであえてここではお礼は言いません。「BizReachでは有給休暇を取って休むことができました!ありがとうございます!」ってここに書くぐらい違和感がある感じがするからです。BizReachでは半年の育休を取得してなんの問題も無く職場復帰して働くことができた。と言う事実だけ置いておきます。

(一度だけ「戻ってきたらチームなくなってて戻れるところないかもね〜。」とは言われました。)

それはさておき復帰しやすいように尽力してくれていたり休職中に僕のツイート見て困ってそうなことを察知して会社にかけあってくれたり制度の枠を超えて助けてくれたみんなには本当に感謝です!!!!!

3. 良かったこと・学んだこと

DiSC

BizReachでは入社時の研修で新卒・中途を問わず1日使ってDiSCの研修を行います。DiSCとはソーシャルでの行動スタイルを4つに分類したものです。ソーシャルスタイルというのもありますが多分大体同じものです。

f:id:HonMarkHunt:20210604230808p:plain
こういうやつね

(詳しい説明やメリットはマコなり社長さんが動画を出されているのでそちらをご覧になってください) 【知らないと損!】相手の「弱み」を一瞬で見抜く方法 - YouTube

今まで仕事する中で人間関係でうまく伝わらなかったり不快な思いをすることがありましたが、相手に悪意はなくただの性質の違いであり、異なる性質の人にそれぞれどう接すればいいのか。ということを学びました!割と当たり前に聞こえますが対人関係でストレスを覚えることがかなり減りましたし仕事以外のシーンでも「うわ、この人めっちゃDっぽいな...要点だけ言って帰ろ」みたいに今後の人生でもずっと使える学びがありました。 また、全員がDiSCの研修を受けているので、自己紹介の時に「〇〇さんってDiSCなんでした?」みたいな会話が日常的に出てきます。

スクラムの学び

私の所属部署ではスクラム開発を導入していました。スクラムに関しては前職で経験があったので「あ〜はいはいスクラムっしょ?オッケオッケ〜」みたいな尊大な態度でやってましたが、過去自分たちがやっていたものが如何にフワッとしたものだったが思い知りました。 できると思いながら初めて失敗しながら方向性を探して結果としてかなり原理的なスクラムに落ち着いたので一連の流れを体験できたのは本当に学びになりました。高坂さんありがとう。 逆に中途半端なスクラムを見てると無性にイライラする体質になってしまいました。高坂さんなんとかしてくれ。

なんとなく方向性

エンジニアになってからずっと悩んでいることがあります。ていうか生まれてからずっと悩んでるんですけど。 1on1やら面談やら飲み会やらでたまに「HonMarkHunt君は、何がやりたいの? or 何になりたいの? or 何を伸ばしていきたいの?」と聞かれることがあります。これは困ります。実は私、これと言って作りたい物もないしやりたいこともないんですよね。

実際、みんなで開発してる時は楽しいしコード書いてる時も楽しいしリリースしてやったー!みたいな時も楽しくていつも楽しいのでこれだ!ってやりたいことがないんですよ なので「フロントエンドでやっていきたい!」とか「機械学習エンジニアになりたい!」とか「HRの負を解消したい!」とか明確な目的意識を持った人を見ると「すごいなぁ」と思う反面焦りを感じていました。

これまでやBizReachでのいろんな体験を踏まえて、大元の問題を解消するための仕組みづくりや、人と話しながら問題を解消していくのでDevOps的な仕事がやってて楽しいしもうちょっと上段の、組織や仕組み作りも楽しいなって気づきました

あと業務領域定期はSaaS界隈で働いていて知見も溜まっているので「SaaS界隈でSREやりながら組織やプロセスにも口出す人」としてやっていこうと思えました。これをなんと呼べばいいのかはわからないのであくまで"なんとなく"の方向性です。

4. 後悔していること

なんかの機会に診断したら自己肯定感が常人の2倍くらい高かったので実はそんなに後悔してることってないんですよね。そんな中でも少し後悔していることを書いて戒めておきます。

挑戦しなかった

BizReachは従業員1,000人を超える大きな会社で、ただただ働いているだけでもいろんな研修やセミナーなど参加できるチャンスがありました。

ちょこちょこ「参加したい人ますか〜?」など聞かれる機会があったのですが、「いや、そんなことより最前線でコード書くっしょ!」という意味不明な現場至上主義な意識で一切参加しませんでした。

今思えば無料で学びを得れるチャンスが転がっていたのでなんでも参加してみればよかったなぁと後悔しています。 特に認定スクラムマスターの研修は名指しで「行ってきたら?」と声かけてもらったんですがやはり現場を優先してしまいました(謎)

もっと仲良くなれば良かった

先ほども言いましたが1,000人以上の仲間がいていろんな経験やバックボーンの人がいました。著しく帰属意識愛社精神が低い私は自分の身の回りの関わる人以外にあまり興味がありませんでした。

せっかくなのでいろんなコミュニティに参加していろんな人と繋がりを持ってもよかったなぁと後悔しています。

5. なぜ辞めたのか

コンフォートゾーン

f:id:HonMarkHunt:20210605011502p:plain:w300

これまで転職を繰り返して、1つのことに気づきました。それは、新しい環境に飛び込むと圧倒的な学びがあると言うことです。

  • 使ったことのない技術に触れる
  • 人間関係を構築する
  • 結果を出して信頼を勝ち取る
  • 外部からの目線で改善案を出す/実行する

など課題が盛り沢山です。これらはいつまでも同じ環境にいると享受できない刺激です。ですが、やはり人間慣れ親しんだ環境からは出たくないものです。

あとの話にも繋がってきますが、私は自分がコンフォートゾーンにいるなと自覚すると抜け出すように心がけています。転職した手はすごく居心地の悪い状態ですが、そこから周りに働きかけてコンフォートゾーンを作っていくまでにいろいろな成長ができます。

リンゴォ・ロードアゲイン

自分の好きなJOJOの奇妙な冒険という漫画にリンゴォ・ロードアゲインというキャラクターが登場します。

dic.pixiv.net

このキャラクターの考えがすごく好きなので最後に簡単に紹介します。

超簡単にいうと「卑怯な手は一切使わずあえて困難な道を選択し、その上で勝利することに価値がある」という持論を持っており、最も困難な方法以外で勝利すると自分にも相手にも「もしかしたら?」という疑念が残ってしまう。という考え方です。 作中屈指の最強能力時間操作系の力を持っていますが、それも戦闘開始前に自分から教えてくれます。(詳しく説明すると大変なので漫画買って呼んでください。)

自分も人生の選択に迷ったときは、必ず「どちらの方が困難か」を考えて困難な方を選択するようにしています。前述の通りコンフォートゾーンを出るか、出ないか悩んだときは抜け出してキャリアを進めるほうが困難な道だと判断したため転職を決意しました。

f:id:HonMarkHunt:20210605131328p:plain

6. これからのこと

今から書くので待っててね

Java女子部 令和だよ!LT大会だよ!に参加させていただいたメモ

概要

javajo.doorkeeper.jp

こちら参加させていただいたメモ。

僕は男性ですが会場提供させて頂いたので後ろの方で見学させていただきました。

*怪しい者では無いです

流れ

13:00~13:15  はじめの挨拶&会場説明&自己紹介
13:15~13:45 ご歓談タイム(集合写真も撮るよ)
13:45~13:55 会場提供LT 株式会社ビズリーチ
14:00~  LTタイム
14:50~  座談会

LT一覧

  1. 最近の悩み
  2. ラムダ式に入門
  3. Scalaの勉強やってみた

最近の悩み

Speaker

twitter.com

memo

  • 転職して様々な開発経験をしたが、当時無駄に思えたことも振り返って考えると学びがったということに気づけるようになった
  • ステージが変わると求められる・必要となるスキルも変わるし、きっとこの先も変わり続ける
  • エンジニアリングのみで飯を食い続けるのは中々大変なのでは無かろうか

kansou

  • 全面的に同じ悩み。つらぽ。

lambda式に入門

Speaker

  • すみません、twitterとかわからず

memo

  • いつかやろうと思っていたが中々lambda式をしっかり触る機会がなかった
  • 新しい現場で目にしたので触ってみた
  • 無名クラスってなんだ?と思ったがよく見たら実は使ったことがあった
  • まずはfor文を置き換えるところからやっていき!

kansou

  • Javaのlambda完全に忘れた

Scalaの勉強やってみた

Speaker

twitter.com

memo

  • 本屋さんに行ったらScalaの本5冊くらいしかなかった
  • Creative Scalaは飽きさせないための挿絵とかが差し込まれていてよかった
  • null安全なだけでJavaよりいいなぁって思った
  • Scalaは頑張れば全部1行で書けちゃうので、SierのStep数で計算は一体どうやるのだろう。。。

kansou

  • 令和だし新しい言語を... っていうのすごくいいマインドだなと思った

まとめ

  • Java女子部の活動方針が明確なのと、参加される方も方針を理解されてから参加している印象
  • 初参加の方も何名かいらっしゃったようですが、運営の方々の気遣いがすばらしく初参加でもものすごく心理的に安全に参加できそう。最後の座談会ではすっかり打ち解けていたようですごいなぁと思った(小並感)
  • Javaやってる方以外でも参加可能なようなので女性の方はぜひ参加してみてはいかがでしょうか!

新宿 Geek Lounge#7 SRE Meetup 行ってきたメモ

shinjuku-geek-lounge.connpass.com

こちら行ってきた。のでメモンヌ。

wifiのpasswordセキュリティーがすごい。

毎度ご飯がすごく美味しそう。

SRE的プラクティスのここがよかった/ダメだった集

speaker

渋谷/オプト (@m4buya) | Twitter

slide

qiita.com

エラーバジェット

  • とは? : 失敗の許容範囲の閾値
  • 定めておくと開発速度うp

とはいえ失敗の合意を取るのは難しい 失敗 < 成果 になるための大人の言い訳が付けれないと実際は難しい。

時間など計算して「ほら早くなっただろう」が示せるとなお良し。

SLO

  • サービス品質の目標値
  • SREは品質をあげる仕事なのでどこまで担保するかを決めておくのはとても大事
  • 担保できなかった場合を定義しておけるとなお良し。

トイル

  • 日々発生するしょうもない仕事を減らそうって話
    • トイルの作業時間は50%以下
  • togglで監視した。togglは良かった。トイルは減らない。そもそもトイル50%ってなかなかならない
  • 俺も測ってみたいけどマインスイーパー50%ってバレるからやらない

toggl.com

オンコール

  • アラート対応
  • サービスが安定してくると緊張感なくなってくる
    • 大事な時にパソコン持ってなかったりするよね

インシデント管理

  • 緊急事態のフレームワーワク(対応方針みたいな?)
  • これは考えておきたい
  • Slack channelとかくらいなら作れそうなので考えておく

ポストモーテム

  • 障害事例のメモ(みたいな感じ?)
  • どいういう時に書くべきか論
  • 見せ合いっこすると楽しい

メモ

  • 優しそうな人だった

VOYAGE GROUPでSREチームができるまでとこれから

speaker

にしごおり (@_nishigori) | Twitter

slide

speakerdeck.com

What is SRE

  • 本を読め
  • 読む

SLOを設定する

  • 「 ADが出ないをなくす!」
    • いろんなケースがあるので定義をしっかりする
  • 計測(モニタリング)大事
    • 私は今Datadogが多機能すぎて何をモニタリングすればいいのかすらわかってない

エンジニアリング

  • SREチームはめっちゃコード書くし1日複数回リリースする
  • Not 専任 But 専門
    • かっこいい、マネしよう
  • developerと壁を作らないように働く

メモ

SLOのあるサービスとないサービスの話

speaker

キン肉マン Takato Horikoshi (@tkt_horikoshi) | Twitter

slide

speakerdeck.com

SLO

  • SLAはservice level agreement => ユーザーとのお約束みたいなもの?
  • SLOがあると ⭐️1 ゴミアプリを回避できる
  • SLOがあっても あぐらをかくと ⭐️1 ゴミアプリは回避できない
  • 最終的に顧客に良い価値を届けることに繋がるのでSLOはとても重要

SLOの選定に向けて

  • ユーザー目線
  • 今にとらわれない
  • 頑張りすぎない
  • たまに見直す

メモ

  • キン肉マン直前までめっちゃご飯食べてた
  • ヘイシャもSLOを定めてみようと思った。
    • 何も思いつかない
  • SLOは四半期に見直す

最後に

飯うま。

f:id:HonMarkHunt:20190312203433j:plain

2018年振り返り

前置き的な

12月。

めっきり寒くなってきた。

肌寒い季節は過ぎ、気づけば最低気温は一桁の日々が続く。皆街を歩く体は丸まり、小さくなった体から精一杯の白い息と愚痴を吐き出す。

クリスマスと連休が近づき、浮き足立つ人々とそれを皮肉る人々。これも毎年のことだ。いつもと違うのは

「平成最後の」

テレビやラジオはこの言葉ばかりだ。

結局は皆いつもと違う何かを見つけたいのだ。毎年毎年同じ日々を繰り返している。そうではない。今年はいつもと違ったのだ。意味のある年を過ごしたのだ。そう思いたいだけなのだ。

俺は今平成最後のポエムを書いている。

なぜ年の終わりにポエムを書いているのか。

そう。Advent Calendarだ。

Advent Calendarとはなにか?

クリスマスまでの日々を1日1日楽しむためのものだ。

どこでどう間違えたのか、エンジニアはクリスマスまで毎日記事を書く。そもそもクリスマスなど28歳にもなれば楽しみではない。別になんら楽しみではない日に向かってお互いに同調圧力をかけながら疲弊しながら記事を書いている。この行為に悲しみ以外のなんの意味があるのだろうか。

突然だが、私は今一つ嘘をついた。

そう。私は28歳ではない。29歳なのだ。

さっき29歳になった。

Happy Birthday to 俺。

おめでとう 俺。

そう、俺は今誕生日当日に Shinjuku.LT アドベントカレンダー を書いている。時間は間も無く丑三つ時を迎えようとしている。嫁は先に寝た。

一体なにをしているんだ 俺。

目を閉じ少し想いを馳せる。

あれは12月に入る少し前だっただろうか「Advent Calenderは気楽に書こう!エモいことでもいいよ!」そう話した日々が懐かしくすら感じる。

目を開け現実を受け入れる。

f:id:HonMarkHunt:20181218022852p:plain

気楽とはなんなのか?

Property-Based-Testing ってなんだ?聞いたこともないぞ?

gRPC なんて全然わからないのにもうMock化の戦略立ててるのか?

俺はそっと「CodePipelineなんか大変だゾォ」という記事をそっと閉じる。タイトルからしてバカの福袋大安売りバーゲンだ。

繰り返す。

俺は今平成最後のポエムを書いている。

ポエムしか書くことがないからだ。

Only ポエム。

ポエム Only。

俺はポエムマン。

さぁ。本編のMAKUAKEだ。

2018年振り返り

毎年Advent Calendarの時期になると今年何やったかを振り返る。大体全く思い出せない。

去年のこととなるともはや不可能だ。全く何も思い出せん。

大した人生を送っていないからなのは明白だが、なんとなく寂しいので1年振り返り的なことを書いて来年以降も振り返れるようにしておく。

読む人の気持ちは全く考えていない。許してほしい。ポエムマンにはこれしかできない。

結婚した

6月に入籍した。

f:id:HonMarkHunt:20181218025102p:plain

「おいおいー!いきなり6月かぁい!」と思ったかもしれない。しかし入籍までの道は以外遠い。両家に挨拶に行き、両親同士の顔合わせを済ませ、必要書類を揃え、日取りを決めなければならない。

さて、多くの場合結婚は人生において1,2を争うビッグイベントだ。しかし、結婚して何か変わったかと言われれば意外と何も変わらなかった。しばらく一緒に暮らしているので役所のDBにCRUDが一回走ったぐらいだろう。

夫の立場でいうことではないかもしれないが、エンジニアと結婚したからといって特に他の職種の人との差はないと思っている。

clown.hatenablog.jp

こんなエントリがある。

何一つ一致するところがない。

割と普通の日々だ。

ただ今までより毎日がちょっと楽しい。

俺ぐらいの徳の低い人生にはそれくらいでちょうといいのかもしれない。

結婚式

9月に結婚式を挙げた。

f:id:HonMarkHunt:20181218031119p:plain

「おいおい〜!また結婚ネタかぁい!」と思ったかもしれない。はっきり言おう。結婚式は想像の10倍過酷だ。大体丸3ヶ月は準備に費やす。長くなるのでここでは詳しく話さないが本当に過酷だ。おそらく夫婦で挑むイベントとしては最大なのではないだろうか。

その分思い出に残ったし、当日は本当に楽しかった。

誤解を恐れずいうと、男性目線だと結婚式なんてやりたくないと思う人が多いかもしれない。俺もそうだった。

ただ当日が終わってみれば「もう一回やりたいなぁ〜」と思った。

ご参考まで。

エンジニアリング的な話をすると式までのタスクをtrelloで管理したりした。友人は招待状をGoogle Formで作っていて、こいつは天才だなと思ったりした。

意外と結婚式はハックできる。

ただハックすることが目的ではないのでそれだけは忘れない方が良さそうだ。

ちなみに結婚式の景品にポエムを渡した。

f:id:HonMarkHunt:20181218032543j:plain

お久しぶりです。ポエムマンです。

転職

10月に転職した。

f:id:HonMarkHunt:20181218032652p:plain

株式会社ビズリーチに入社しました。

厳密に言えばともともとはフリーランスだったので転職というのか微妙なところではあるが、正社員としてjoinしたので転職といえば転職かもしれない。

転職の理由は色々あるが愚痴っぽくなるので割愛。ただ結構ポジティブな理由で動けたのでよかった。

  1. 給与
  2. 作るもの
  3. 働き方
  4. 技術力

この辺を大事にしながら活動した。ちょっとだけ掘り下げておく。

給与

言わずもがな。一人ならまだしも家族がいると「やりたいことがあるから給与減らしてでもやりたい!」という判断は厳しい。そもそもそこまでやりたいこともなかったのでお給金は高ければ高いほどよかった。

作るもの

せっかく正社員になったのだから人のためになるものを作りたい。という気持ちがあった。

以前はインターネット広告関連の仕事をしていたのだが。「これ誰が幸せになるんだ?」と考えて考えていなかったりした。

なんとなくのイメージだが、もし子供ができて大きくなった時に「パパスはこんなサービスを作ってるんだぞぉ!」と、胸を張って言える仕事をしたかった。「パパはインターネットに広告を出してるんだゾォ」といった時に「これ間違えてクリックするからうぜぇんだよ!」と、言われる気がした。

働き方

はるか昔は本番障害で丸三日徹夜で働いたりしてた。

まあエンジニアならよくある話かもしれない。

業務が 忙しくて/楽しくて 家でも仕事をする。

まあエンジニアならよくある話かもしれない。

ただ、せっかくこんな俺が結婚できたのだ。家では待っててくれる奥さんと過ごしたいなあ。と思ってる。なんとなくそのために働いてるし、そのために生きてるような気がする。奥さんと一緒にいる時間を削ってまで働くことはしないと決めた。

簡単にいうと働き方が自由で残業も多くないとこがよかったっていう話。

技術力

上記を満たしていればある種二の次ではあったが。今更Struts1で開発だあ!と言われてもそれは厳しい。今後のことも考えればできれば新し目の技術を触りたいし提案していきたいなぁとか考えていた。

2018年総括

ざっと振り返ると大きなイベントごとの多い年だったなと思う。

エンジニアリング的なところでいうと、なんとなく4,5年やってきたことが(遅すぎるが)繋がってきた気がする。

あの日悩んだことやみんなで話したことや後悔したこととか成功したこと。そういうのが今すごく価値になっている感じしている。まだまだ足りないことは多いが、何が足りないのか足りないことを補うためにはどう学べばいいのか学んだことをどうすればいいのか。それがわかってきた感じがして、今は仕事が楽しい。

Shinjuku.LTもちょっとづつ盛り上がりながらずっと続いている。 なかなか言うタイミングがないのでここで言っておくが、2年前にShinjuku.LTが発足してからしばらくは、自分が未熟で周りに迷惑や不快な思いを与えていたと今すごく思います。本当にすみませんでした。 自己顕示欲の塊みたいな俺に怒りもせず付き合ってくれて2年間以上Shinjuku.LTを一緒に続けてる仲間に改めて感謝。これからもよろしく。

反省点

去年末から 引っ越し -> 結婚 -> 結婚式 -> 転職 と続いていたのでかなりばたついた一年間だった。今人的に一番反省したのはこれ。

f:id:HonMarkHunt:20181218035825p:plain

connpassの勉強会の申し込みが [2017/10 ~ 2018/09] 一年間空いていた。 (connpass以外で行ってたりしたが視覚的にびっくりした)

少し落ち着いたので勉強会参加増やしていこうと思う。

別に勉強会に行けば偉いと言うわけではないが人との繋がりはShinjuku.LTですごく学んだので繋がりを増やす意味でも参加していきたい!

2019年

最後にちょっとだけ来年について。

2019年は積極的に登壇回数を増やしいこうと思う。

やっぱりいいアウトプットになるし会社の宣伝にもなるし繋がりも増える気がしている。

そんな感じ。

now.shとCircle CIで継続的音速サービスリリース

f:id:HonMarkHunt:20181201173532p:plain:w200

この記事は 2018年 Shinjuku.LTアドベントカレンダー の1日目の記事になります!

2日目の記事はこちら =>

vue-cliとNetlifyで始めるお手軽サイトホスティング - Qiita

Shinjuku.LTってなに?って方はこちら => https://shinjukult.netlify.com

はじめに

Shinjuku.LTはコミュニティーのサイトをOSSとして開発しています!

github.com

簡単な構成

f:id:HonMarkHunt:20181201181102p:plain

本日はバックエンドのリリースフローを簡単にご紹介します!

https://github.com/shinjuku-lt/shinjuku-lt-backend

  1. now.shでデプロイ
  2. Circle CIで自動化

1つづつ見ていきましょう!

now.shでデプロイ

zeit.co

now.shって何?

now.shはzeit(ツァイト?)社が作成しているPaaSです。一言で説明すると 「コマンド一つでデプロイできるサービス」 できます。超早いし、超楽です。最高。あと無料です。無敵。

これは個人的な感想ですが、趣味や勉強で開発しているプロダクトであれば現状最高のプラットフォームだと思います。

  • node.js ()
  • static page
  • docker

でできたプロダクトであれば利用できます。

簡単にやってみましょう!

# install now.sh
$ npm install now -g

# 適当にexpressのアプリを作成
$ mkdir myapp
$ cd myapp
$ npm init
$ npm install express --save

index.jsを作成し以下の内容を記載

const express = require('express')
const app = express()
const port = 3000

app.get('/', (req, res) => res.send('Hello World!! from now.sh!!'))

app.listen(port, () => console.log(`Example app listening on port ${port}!`))

念の為起動確認

$ node index.js

$ curl http://localhost:3000
> Hello World!! from now!!

アプリができたので早速デプロイしてきましょう!

$ now
> Synced 3 files (13.25KB) [1s]
> https://myapp-xxxxxxxxxx.now.sh [v2] [in clipboard] [1s]
> ┌ **        Ready               [499ms]
> ├── package-lock.json
> ├── index.js
> └── package.json
> Success! Deployment ready [8s

# 念の為動作確認
$ curl https://myapp-xxxxxxxxxx.now.sh
> Hello World!! from now!!

デプロイが終わりました!!(nowコマンドは初回のみ) こちらがデプロイ後のURLです! => https://myapp-xxxxxxxxxx.now.sh

Circle CIで自動化

now.shを使用してデプロイが完了しました しかし色々問題が残っているので解消しましょう!

nowコマンドでデプロイした後の改善点

  1. チームで安定的なデプロイができない
  2. ドメインが固定されない
  3. デプロイがローカル依存になる

この辺解決しながらCircle CIで自動化していきます。

チームで安定的なデプロイができない

nowコマンドはlocalの~/.now/auth.json中身を見て実行されます。複数人で同一プロダクトを開発する場合かなり厄介です。 また、CIからnowコマンドを実行しようとした場合認証情報がないのでエラーになり、メールでの認証も行えないのでコマンドが実行できません。

$ now -t ${YOUR_TOKEN}

ここからtokenを払い出してloginしていなくても、CI上からでもnowコマンドが実行できます!

ドメインが固定されない

nowコマンドでデプロイすると基本的にはhttps://myapp-xxxxxxxxxx.now.shランダムなURLが毎回発行されます。サービスのURLがデプロイのたびに変わっていたら由々しき事態なので毎回固定しましょう。

$ now alias ${ALIAS_YOU_WANT}

毎回コマンド打つと大変なのでnow.jsonで固定できます。

https://github.com/shinjuku-lt/shinjuku-lt-backend/blob/master/now.json

デプロイがローカル依存になる

チーム開発などの場合にはデプロイのたびにnowのインストールとtokenの共有が必要になります。 GitHubでPRレビューなどした場合は、レビューが終わってマージ後に手動でデプロイ。などのめんどっちいオペレーションが発生します。 せっかくの音速デプロイなので完全自動化しましょう!

GitHubのmasterの変更をtriggerにCircle CI(CIは別になんでもいいと思います)を設定して、環境変数に先ほどのtokenを登録して置くだけでデプロイの自動化ができます!

サンプルで、Shinjuku.LTのバックエンドで利用しているCircle CIの設定を貼っておきますのでご参考になさってください!

https://github.com/shinjuku-lt/shinjuku-lt-backend/blob/master/.circleci/config.yml

version: 2
jobs:
  build:
    docker:
      - image: circleci/node:8.9

    branches:
        only:
          - master

    working_directory: ~/repo

    steps:
      - checkout

      - run:
          name: install now
          command: sudo npm i -g --unsafe-perm now

      - run:
          name: deploy asap now!!
          command: |
            now shinjuku-lt/shinjuku-lt-backend --public -t ${ZEIT_TOKEN}
            now alias -t ${ZEIT_TOKEN}

最後に

now.shとCircle CIで無料で高速デプロイする方法を紹介しました!ちなみにnow.shは最新バージョンの2.0がリリースされており。現在移行作業中です。

now.sh 2.0 を利用中の場合は本記事の内容が正しく動作しない場合があるかもしれませんのでご注意ください。

第一回 scala.rookies 行ってきたメモ

https://connpass-tokyo.s3.amazonaws.com/thumbs/44/51/4451eef882af829ea79ef2bbd3a62ae9.png

こちら行って来た

scala-rookies.connpass.com

「初心者向けscalaの勉強会/登壇場所があってもいいんじゃない?」「無いなら作ろう」ってことで開催したらしい。最高。

アジェンダ

  1. 運用を続けていくためのScalaの書き方(仮)
  2. Query API 試行の旅 (仮)
  3. 未経験からscala始めるときの天国と地獄(仮)
  4. OrderingとOrdered
  5. 未経験でScala案件投げ込まれて無事生還した話
  6. 怖くない!implicit!
  7. 実践Scala入門が読みたくなるようにプレゼンさせてください

運用を続けていくためのScalaの書き方(仮)

登壇者

twitter.com

  • ホテルのロビーからリモートで配信
  • 実際scalaで運用してみて、メンテナンス向上、バグ削減しやすい書き方

モナドトランスフォーマーは外部に出さない

DBとかのトランザクションは積極的に例外吐く

  • 音声途切れてよく聞こえなかった
    • 悲C
  • 例外でロールバックされるから素直に例外投げたほうが見通しがいいって話っぽい
  • この辺はある程度ORMのライブラリに依存する話?

副作用は無理に型で表現しない

  • ちょっとわからなかった

DBやクライアントの返却地の型をそのまま使い回さない

  • 自動生成便利だけどアプリレイヤーで使用するものは自前で作ろう!って話
  • 変更に強くなるからっぽい

感想

  • リモート音声と視力の悪さと頭の悪さであんまりわからんかった。あとで資料見たい。

Query API 試行の旅 (仮)

登壇者

twitter.com

  • Datastore(DB, API)の境界線をどうやってscalaで表現するかって話
  • レイヤードアーキテクチャ
    • 低レイヤの方の制約を強くする
    • 今日はRepositoryの話
  • 結構今のプロダクトの構成に似てる気がする
  • Resource(= Repository) + Queryで柔軟に表現できるっぽい
  • 実装されたQuery、どれが呼ばれるかってどうやって判定するんだろう
  • 初耳 https://monix.io/
  • 非同期処理いい感じらしい

未経験からscala始めるときの天国と地獄(仮)

登壇者

twitter.com

  • cdコマンドも知らなかったけど1年間scala学んで困ったこと
    • すごい頑張ってる感じがしてすごい
  • 成長環境が用意されている感じと伸び伸び学んでる感じがしていいなーと思った
  • よくわからないって人前で言えるのは中々いいことな気がする
  • 一緒に頑張ろうって感じがした

OrderingとOrdered

登壇者

twitter.com

資料

  • case classをソートしたい
  • Orderingをimplicitにできる
  • 勢いあって面白かった

未経験でScala案件投げ込まれて無事生還した話

登壇者

twitter.com

  • scalaだけが仕事の全てでは無い
    • たしかに
  • scala.yokohama行ってみたい

怖くない!implicit!

登壇者

twitter.com

資料

www.slideshare.net

実践Scala入門が読みたくなるようにプレゼンさせてください

登壇者

twitter.com

  • Scala実践入門買おう