ITエンジニアと一口に言ってもフロントエンド、サーバーサイド、インフラ、QA、マネジメント……など、ポジションやキャリアにはさまざまなルートが。使う技術やツールはもちろんのこと、面白さや考え方も異なります。「なぜ、どういうきっかけでその道に進むことになったのか」「何がやり甲斐なのか」には、人それぞれの答えがあるものです。
いろいろな人から自分なりのキャリアの選び方を伺うことで、テックの世界の知見を共有する企画「みんなの"◯◯エンジニアになった理由"が聞いてみたい!」。
今回はKINTOテクノロジーズ株式会社 あわっちさんがDBREになった理由を、LT形式で発表していただきました。
自己紹介
KINTOテクノロジーズという会社でDBRE(Database Reliability Engineering)をしているあわっち(@_awache)といいます。
2007年、新卒で楽天株式会社にアプリケーションエンジニアとして入社し、その後、DBAやインフラエンジニアを経験しました。
楽天でエンジニアとして働きながら会社のCSR活動の一環で、いろいろな学校でeコマースの授業をさせてもらっていたのですが、当時、3年生になった生徒たちが社会に出るとき、学校の掲示板に貼られた中から就職先を探していたんですね。それを目にして「HRの会社に行きたい」と思い、2018年にVisional株式会社(株式会社ビズリーチ)に転職。このときにDBREと出会いました。
CCoE(Cloud Center of Excellence)の立ち上げもしたのですが、まったく分からなかったので、Jagu'e'r(Japan Google Cloud Usergroup for Enterprise)というコミュニティーに参加して学ばせていただき、『DXを成功に導くクラウド活用推進ガイド』という本では先進事例として紹介していただきました。
また、「僕が教えていた地域の子たちが高校卒業後、すぐに必要になるものはなんだろう」と考えると、自動車なんですね。それで次は車に関係するところに行こうと考え、2022年にKINTOテクノロジーズ株式会社に入社しました。
DBAへの転身、DBREとの出会い
先ほどお伝えしたように、僕はもともとアプリケーションエンジニアでした。DBAに対しては「めちゃめちゃ怖くて近寄りがたい人たち」という印象を抱いていました(笑)。
しかしある時、「データセンターの移設に伴いHDDがSSDに交換されたら、それだけでボトルネックがデータベースサーバーからアプリケーションサーバーに切り替わる」という出来事があって。アプリケーションの肝はデータベースがどれだけ早くレスポンスを返せるかにあると痛感し、この出来事に強烈に未来を感じてDBAに異動しました。db tech showcaseでの登壇をきっかけに、MySQLのコミュニティーにも参加するようになりました。
その後、Visionalに転職して、特定サービスのDBAを担当。半年たったとき「横断組織を作るから」と言われて異動したのですが、そこにはDB系のエンジニアが僕しかいなくて。そもそも何をやればいいのかが分からず、目標設定から始めることになりました。
自分のやりたいことを整理していくなかで「データベースを要因に、事業戦略をあきらめてほしくない」「成長につながる基盤を作りたい」といったことを考えていたのですが、なんだかDBAっぽくない発想だな、と。
「自分が横断組織のDBAを担当すると、ゲートキーパー的な役割になりそうだ」というイメージを抱いていました。そうすれば、アプリケーションエンジニアに対してドメイン知識がない状態でレビューなどをすることになり、ハレーションも起こるだろう。組織全体に対して人数が少ないポジションだから、開発に求められるスピードにもついていけないかもしれない、と感じていました。
そしたら、とあるDBAの方と話しているときに「いやそれはDBREでしょ」と指摘されて。なんだそれはと思い、『Database Reliability Engineering』というオライリー本を購入。パラパラめくっただけで「すごい本だ」「これが自分の目指すべきところだ」と感じて、写経することにしました。
ちょっと脱線するのですが、僕はけっこう写経するんです。書かないと理解できないタイプで、本質を理解したいときは無心ですべて書き写して図もなるべく自分で再現する。当時は英語版しか出ていなくて大変だったのですが、全部写経して全部翻訳してやれ、という感じでした。
そうして自分なりに理解して「これから横断組織の中でどうやって動こうか」と思い描いていたことが、僕にとってのDBREの入口になりました。
しかし、最初にやったことは何かというと、データベース関連の仕事がしたい一心で「データベースまわりを良くしないと、こんなに簡単に落ちるんだよ」という気持ちから、F5で自社の主力サービスを落としてしまう、という(笑)。
この一件を知った当時のCTOは、スロークエリ撲滅のために新機能開発を半年間ストップすることを決めました。翌日、僕はビクビクしながら出社したのですが、周囲も「いい機会になった」「きっかけをくれてありがとう」と意外と好意的に受け入れてくれました。
こういったことをブログに書いてみたら「DBREってなんだ?」という反響があり、初めて実施したDBRE関連のイベント「そーだいなる DBRE Night」にも、100人ちかい人たちが集まりました。
さらにCCoEを経験し、現職へ
それから2年ほどして、CCoE組織のマネージャーを担当することになりました。僕のいた横断組織はクラウド、データベース、SREという3つの領域に分かれていて、クラウドを見るチームのマネージャーも兼任することになったんです。
ただ僕はデータベース屋さんだったので、クラウドについてちゃんと理解できているわけではありませんでした。初めのうちは、マネージャーになる以上は自分で全部できるようになろうと頑張っていたんですけれども、やはり自分がボトルネックになってしまいました。
でも、チームメンバーたちがめちゃくちゃ優秀だったので、背中を預けて自分の役割をマネジメントのほうに振り切ったら、生き生きとやってくれて。『DXを成功に導くクラウド活用推進ガイド』では「コミュニティの中でもっとも進んでるCCoE」という風に評価していただけて、自信になりました。
KINTOテクノロジーズへの転職には、いろいろな理由があります。最初にお話した通り、次の事業ドメインは自動車にしようと思っていたことが1つ。僕には「自分のいる組織が最高になったタイミングで転職しよう」という考えがあって、本の中で評価してもらえたことが1つ。
楽天時代に僕の課長だった景山さんがKINTOテクノロジーズにいて、「いま楽しいの?」「その楽しさ、うちで再現してよ」と言われたことも理由の1つです。挑戦状かなと思って、引き受けました(笑)
DBREの楽しさ・頑張りどころ
オンプレが主流だった時代は、ソフトウェアエンジニアの人たちはサービスの稼働率を守る、成長促進するための開発をする。DBAはデータベースという箱物の管理をする。役割が重なる部分もありますが、そんな分担の仕方だったと思います。
しかし、AWSやGoogle Cloudといったパブリッククラウドでは、箱側で箱物管理を担保してくれます。そこではソフトウェアエンジニアとパブリッククラウドをつなぐハブになることが重要だと考えていて、そのためには従来のDBAの領域を超えたさまざまな技術も貪欲に学んで、使っていく必要があります。
自分たちでもアプリケーションをめちゃくちゃ書くし、いい感じの開発手法やチーム運営を突き詰めていける。こういったところも、DBREの面白いところかなと思っています。
一方で、データベースの肝となる知識は、10年前からあまり変わっていません。CCoEの立ち上げで2年間のブランクができた後も戻ってこれましたし、CCoEの思想をうまく取り入れて、新しいDBREの形を作ることができました。
Visional時代は「みんなの役に立つツールを作って、プラットフォームを作っていこう」という方向性が強かったのですが、KINTOテクノロジーズではCCoEの思想を取り入れて、「プラットフォームによって、みんなが幸せになるにはどうしたらいいのか」「何も気にしなくても会社のガバナンスなどにも対応できるし、スケールするような組織構成にするにはどうしたらいいか」といったところを目指しています。
CCoEはゲートキーパーというよりもガードレールに近く、「この枠内であれば、セキュリティやガバナンスは守られている。ここまでなら好きになっていいよ」と自立を促すことを大きな使命として持っています。例えるなら、街の交番のおまわりさんでしょうか。『名探偵コナン』のコナンくんのように、天才的なひらめきと超人的な身体能力で解決するのではなく、平和なときは普通に立っていて笑いながら挨拶するくらいの感じだけど、何か事件が起こったときには現場に駆けつけて一緒に解決していくようなイメージです。
DBREやCCoEのあるべき形は、人それぞれだと思っています。まだあまり認知されてないからこそ、自分なりのやり方を追求していける楽しみは大きいんじゃないかなと。