インフラエンジニアとしての成長の秘訣は“ポジティブやじうま”精神！

「新規サービスのインフラ構築」と、「既存サービスの運用・保守」、そして「旧環境の移行」の3つが今の主要なミッションです。SREグループは、2017年の10月にインフラグループからSREグループに名前が変わりました。SRE（Site Reliability Engineering）とは、Googleが提唱している新しい方法論で、コーディングやソフトウェアエンジニアリングによって、システム全体の性能やセキュリティなどを高めようとする活動全般を指すものです。

ひとことで言えば、サイトの信頼性を上げるためのチームですね。SREを採用することで人的なコストを下げると同時に作業ミスをなくし、パフォーマンスやセキュリティを一律にすることで、サービス全体のレベルを上げることができます。

実は、昔の同僚がオールアバウトに入社していて、誘われたのがきっかけです。いろいろ話を聞いていると、当時はまだ知名度もなかった「GCP（Google Cloud Platform）」を2年くらい前から採用していると聞き、あえてGCPを選ぶスピリッツと、それに追随するエンジニアの高いメンタルに惹かれましたね。

サービスの量も圧倒的にAWSの方が多かったし、日本語のナレッジも雲泥の差。GCPをやるなら英語のドキュメントを読まなくてはいけないので、わからないことがあれば自分たちで解決するしかない。こんなに壁が見えているにもかかわらず、そこへ突っ込むなんて、すごいなと思いました。そんなエンジニアたちの中で揉まれたら自分のスキルアップにつながるのではないかと思い、転職に至りました。

「あのでっかいサイトをどういう風に切り分けて運営しているんだろう？」というのは、パッと見で想像できなかったのですが、実際に入ってみると見えていなかった部分の技術がいろいろ見えてきて楽しいですね。負荷を分散させるために、カテゴリで分けて管理しており、GCPを使っている理由はここにあったのかなと思いました。

私自身、MySQLの経験はそれなりにあったのですが、SQL Serverの経験がほとんどなかったので、「SQL Serverって何なの？」というところからスタートせざるを得ませんでした。それに、SQL Serverのバージョンが極端に古すぎて、どうやっても同一のバージョンでは遷移できないということで、アップグレードによる弊害を読みきれないのは大変でしたね。

あと、データ移行に関しても、バージョンが古すぎて推奨されているやり方が使えないものがあって、非常につまずきました。結果的にうまくいったから良かったものの、本当に正しい手順だったのかどうか確信が持てず、かなり最後まで四苦八苦しました。

それは全然気がつきませんでしたね（笑）自身のメンタル的には、そんな追い詰められた感覚はありませんでした。「ダメなら、こっちでやればいいか」くらいなもので。最後に手がなくなったときには少し焦りましたが、上長の寺門さんが別の方法を提案してくれたりして、「まだ行けるわ」と。周りがいてくれたから、なんとかなったところも多分にあると思います。

確かに、きついプロジェクトは何度か経験してきましたね。自分にとって一番辛いのは、不完全なものをリリースする事です。例えば、以前いた会社で大きなシステムの移行プロジェクトを担当したことがあったのですが、そのときは明らかにクリティカルな問題があることが分かっていて、リリースの期日の延長を提案したものの、マーケティングの都合上「無理です」と言われちゃって。“絶対に爆発するのがわかっていて、なおかつ爆発の規模が読めないまま出す”というのは、メンタルにきますね……。