株式会社 mediba を退職します。
note での2本目がまさかの退職エントリーですｗ
2014年4月1日の入社以降、約7年間に渡ってお世話になった株式会社 mediba を、2021年6月末を以って退職し、7月から新しい所属先でお世話になります。
新しい所属先にはまだ正式に JOIN していないので、ここでは社名は出しません。気になる方は Facebook の DM でもください。
5/14(金) が実質最終出社日となりまして、6月末までは有給消化期間となります。(本当の最終は6/30だけど、この日はPC等の返却のみのつもり)
このような時世でなければ海外旅行にでも行きたかったですが、仕方がありません。
せっかくの退職エントリーなので、これまで僕が mediba で経験してきたことなどを書いていきたいと思います。
なぜ mediba に JOIN したのか
前職で同僚だった方が先に mediba に転職していて、誘っていただいたことがキッカケでした。
前職で楽しさを感じなくなってきていたこともあり、年収アップとやりがいを求めて選考を受け、無事に合格・入社したのでした。
何をやってきたのか
前職までは主に Java を使った開発案件に従事することの多いバックエンドエンジニアだったのですが、mediba ではインフラエンジニアに転向します。
当時の mediba はバックエンドに PHP を使ったシステムが多く、自身も当然のようにバックエンドエンジニアとして PHP を書くものと思っていたのですが、前職で少しだけ AWS を触っていたことから、入社初日に当時の上司から「インフラでも良いよね」と言われまして。
入社初日で断る勇気も無く、流されるままインフラエンジニアとしてのキャリアをスタートします。
もともとインフラ領域には苦手意識があり、「サーバー構築？ナニソレオイシイノ？」「ネットワークとか全くわからん」な状態でした。
さすがに当時の上司も気を使ってくれて、最初のうちはインフラの部署で面倒を見ていた共通系のツール(PHP製)を改修したり保守したりしていくことになります。
その後、少しずつインフラっぽい仕事もし始めます。
在籍期間中には以下のようなことを経験しました。
オンプレ → オンプレのシステムリプレイス
これは僕が入社する前からオンプレで稼働していたシステムで、2015年ごろに全面リプレイスする案件がありました。
この案件、本当はリプレイス先を AWS にしたかったのだと思いますが、諸々の事情によりリプレイス先もオンプレでした。
ここでは初めての経験をたくさんします。
・Linux 系 OS (CentOS) のオペレーションやトラブルシューティング
・Web サーバーや DB サーバー等のサーバー群の設計、構築経験
・構成図書いたり Nginx のインストールしたり
・可用性や耐障害性、冗長性を考慮した設計
・DB でクラスタ組んだり負荷分散のために HAProxy 入れたり
・負荷試験の計画と実施
・データセンターに行って直接LAN挿して負荷試験したり
上述の通り、ここで初めてデータセンターに行くという経験をしました。
今となってはクラウドでインフラを構築するのが当たり前になっているので、本当に最初で最後かもしれない貴重な経験でした。
オンプレ → クラウドへの移行(リフトのみ)
当時オンプレで動いていた共通系ツールの1つを AWS へリフトする案件でした。
ここで VPC や EC2 など、AWS の基本とも言えるサービスをいくつも触ることになります。
この案件ではクラウドネイティブに設計し直すことはせず、オンプレ時の構成をほぼそのまま AWS 上に再現する形を取りました。
唯一クラウドっぽいことをしたといえば、このシステムでは MongoDB を使っていて、その冗長構成のため(※1)に Arbiter をシンガポールリージョン(※2)に置いたことぐらいでしょうか。
※1 当時東京リージョンには AZ が2つしか無かったので、AZ 障害が発生した場合でも MongoDB を正常に稼働させるため別リージョンへ Arbiter を配置。
※2 当時は大阪リージョンは疎か、ソウルリージョンもまだ無く、一番近いリージョンがシンガポールリージョンだったため。
オンプレ → クラウドへの移行(再設計込み)
この案件では既存のシステムをクラウドに適した形で再設計し、外部連携のスピードアップや耐障害性の向上を図りました。
ここでは、案件の内容というよりは開発自体の体験がとても良かったと記憶しています。
というのも、それまでの働き方は「インフラエンジニアの仕事はインフラだけ」というような、縦割り感のある開発スタイルが多く、要件や仕様をもとにインフラ設計・構築をしたり、設計済みのインフラを構築するだけだったり、依頼ベースでのタスクをこなすことが多くありました。
この案件はそうではなく、バックエンドやフロントエンドのエンジニアとアーキテクチャについて一緒に検討することはもちろん、ビジネスサイドのメンバーとも要件や仕様について議論したりと、とにかく「プロジェクトメンバーの一員である」という感覚がとても強く、mediba 在籍中のお仕事の中で楽しさとやりがいがダントツに強かったです。
この案件の深夜リリース明けで寝ずに21時頃まで飲みに行ったことは今でも良い思い出です。
SRE のマネージャー
2019年後半、それまで「インフラストラクチャー部」という部署だったものが「SRE 推進部」に部署名が変更になり、「インフラをやる部署」から「(インフラを主戦場に)システムの信頼性を担う部署」に役割を広げた形となりました。
それと同じタイミングでマネージャーを拝命しまして、それまで mediba には無かった SRE という役割を啓蒙推進していく立場になりました。
2020年度にはテクノロジーセンター内における横断組織として「SRE UNIT」に名を変え今に至ります。
参考: medibaを支える技術（2020年度）
マネージャーになって約1年半で、以下のようなことをやってきました。
・O'Reilly の SRE 本 の輪読会の実施
・mediba における SRE の Mission, Vision, Value の策定
・SRE としての部門目標の策定、推進
・一般的なピープルマネジメント
・メンバーのアサイン検討や 1on1 でのメンタリングなど
SRE としてやりたいことはまだ山ほどあります。
それらは後任のマネージャーや非常に優秀な現場メンバーが着実に達成していってくれると信じています。
JAWS-UG への参加
JAWS-UG とは Japan AWS User Group の略です。
AWS に関するエンジニア等が集まっているコミュニティで、勉強会の開催や大型のカンファレンスが開催されたりしています。
運営としての参画はしていないのですが、自身の気になるテーマの支部の勉強会への参加や、人生初の登壇も経験しました。
JAWS-UG との出会いは、間違いなく僕の人生そのものに影響を与えたできごとです。
初心者支部の第1回目 に誘ってくれて、またその後の懇親会に足を運ぶ後押しをしてくれた当時の上司には非常に感謝しています。
re:Invent
AWS 最大のカンファレンスである re:Invent に、ありがたいことに在籍中は4回も参加させていただきました。
2014年に初参加し、2015、2016、2018 と、参加していく度に世間の技術の動向であったり世界のエンジニアの熱量であったりを肌で感じることができ、非常に刺激のあるカンファレンスでした。
ちなみに、2016年の re:Invent については、実は AWS Summit Tokyo のナイトイベントで開かれる「AWS ウルトラクイズ」に優勝し、優勝賞品として re:Invent に無料で参加したのでした。
参考: これがなくっちゃ終われない！JAWS-UG Nightレポート
なぜ転職するのか
先に断っておくと、mediba に不満があったり何か嫌なことがあったから転職するわけではありません。
恥ずかしながら、mediba に入社をした頃の僕は「エンジニアとして働けて年収が上がったらそれで良かった」のです。
しかし、mediba 在籍中の様々な経験から、自分の中で「ちゃんと愛着や熱量を持って事業の成長に寄与したい」という想いが芽生えてきました。
mediba は KDDI のグループ企業であり、au と名のつくサービスをいくつも運営していますが、実は僕自身、過去も現在も、au の回線やサービスをプライベートで使ったことがありません。
これが今回転職を考えた理由です。
そして、愛着や熱量を持つにはどうしたら良いか → 自分でやりたいと思えることなら愛着を持てるだろうと考え、同時に、やりたいことってなんだろうと考えました。
そして、考えて出た結論をもとに、それに合致する事業を展開されている企業さんをいくつか受けさせていただいて、今回のご縁に繋がった次第です。
ほしい物リスト
こういうとき Amazon のほしい物リストを公開する流れがあるのですが、僕の Amazon アカウントではほしい物リストに全然物が入っていませんでした。
意外と思い立ったらすぐ買うタイプのようで、ストックする癖が無かったみたいです。
なんとなくほしい物を探して追加してみたものの、高いものばかりだったのですが、一応載せてみることにしますｗ
それではまたどこかで。
この記事が気に入ったらサポートをしてみませんか？