インフラエンジニアといえば、安定稼働やセキュリティといった「守り」のイメージが強いかもしれません。しかし、コストダウンやDevOpsなど「攻め」を担うのもインフラエンジニアの仕事。
インフラ設計や構築、障害対応、開発サイドとのコミュニケーションなど、やるべきことは多岐に渡ります。

今回はメディアテクノロジー事業本部（MT）でインフラエンジニアを担当する小宮良之に、入社後に担ったミッションや、エンジニアとのコミュニケーションについて話を聞きました。

開発メンバーとの距離の近さがコストダウン成功の鍵に

――2017年に入社してすぐは、コーポレート本部に所属されていました。

はい。コーポレート本部には2020年6月まで3年間在籍していました。主な業務は、社内システムや自社プロダクトのインフラ全般です。
社内ネットワークについては、前任の担当者の整備によって安定していたので、細かい見直しや、中断されたと思われるシステム構成を詰め直したりしました。業務系システムの改変もいくつか担当しましたね。

また、全社インフラの仕事と並行して、事業部のWebサービスのインフラやシステムリニューアルも一部担当していました。

――コロナ禍のリモート対応でも、コーポレート本部が動いていましたよね。

当時は、経営陣の判断が非常に精密で速かったのが印象に残っています。2020年2月末頃と記憶していますが、土曜の午前中に緊急の経営会議が開かれて、私も出席しました。そこでアクションプランが立てられ「月曜から動こう」と決まったんです。

それから1週間ほどで、リモートワークの環境を整えていきました。何をしたのか覚えていないくらい目まぐるしい1週間でしたが、会社の方針を一気に決める経営判断とスピード感にふれたこと、その一員として携われたことは、貴重な経験だったと思います。

――2020年7月に、現在所属しているメディアテクノロジー事業本部に異動されました。異動に至った経緯について教えてください。

メディアテクノロジー事業本部の管掌役員から打診を受けたのがきっかけです。それまでコーポレート本部の業務として、メディアテクノロジー事業本部のインフラも見ていたのですが、まとまった工数をとれず、次の一手が打てない状態でした。

DevOpsについてもずっと宿題を抱えていたので、このタイミングでしっかりプロダクトインフラにコミットしようと考え「ぜひやらせてください」と。

――DevOpsについては、どんな宿題を抱えていたのでしょうか。

ずっと抱えていた宿題は「Appliv」「Appliv TOPICS」の運用工数削減です。異動後に、それまで手作業で20分程度かかっていたデプロイ作業を自動化しました。

すでにほかのプロダクトでCircleCI+CodeBuildやECSなどで自動化は進めていましたが、もう少しシンプルにしようとCodePipelineへ切り替えたんです。そして、コンテナのビルドを含めて10分を切ったので、この方式に着地しました。
それと同時に、サービス拡大を見越してスケーリングの機能も加えました。

――現場のエンジニアリソースを圧縮したわけですね。ほかに取り組んだミッションはありますか。

最大のミッションはコストダウンですね。コーポレート本部のころから相談は受けていましたが、異動後に本格的に取り組みました。現在まで約2千万円の削減に成功し、次の見直しを進めています。

稼働率の低いサーバのサイズダウン、使われていない機能の凍結、一部の機能のサーバーレス化、データベースのスペック見直しとダウンサイジングなど、作業はシステムの要求性能を確認しつつ慎重に進めました。
調査の結果、逆に「このサーバはパフォーマンスを上げたほうがいい」と判断し、拡張したものもあり、コストダウンだけでなく最適化で着地した部分もありますね。

――ほかの開発チームのメンバーとの連携はいかがでしたか。

異動する前に、メディアテクノロジー事業部のメンバーから話しかけられるときは、「コーポレート本部にちょっと相談が…」くらいの距離感はあったのですが、事業部付けのエンジニアになってからは、開発チームのメンバーと活発にコミュニケーションできるようになりました。

近い距離感でより細かく連携して話をできたことが、最終的に大幅なコストダウンにつながったと感じています。

今なら“やりたい放題”、オンプレミス経験のある方は大歓迎

――心の距離感が縮まったことが功を奏したともいえるんですね。

メンバー同士、互いフラットなコミュニケーションがとれている実感はありますね。私も、「どんどん相談してください。いっしょに解決していきましょう」という姿勢で取り組んでいます。

最近は、開発エンジニアの面々が少しずつインフラにふれるようになっていて、「自分でシステムを構築してみたので、チェックをお願いします」など、サポートの依頼を受けることもあります。
「何をどうしたらいいかわからない」という相談ではなく、「勉強してみたけど、○○でつまづいているので教えてほしい」という関係性になりつつありますね。

――開発エンジニアがインフラにコミットするようになると、インフラエンジニアはどんな役割を果たすことになるのでしょうか？

技術的な部分では、垣根がなくなりつつあると思います。ただ、クラウド利用では普段あまり意識することがない、低レイヤーの部分や、ネットワーキングのエッジに位置するCDN技術やDNSサービスなどは、あまりイメージが湧かない人も多い。そのあたりの相談を受けることが多いですね。

ただ、こうしたネットワークの基礎は昔から変わっていませんし、開発エンジニアでも学ぶことは難しくないでしょう。そうなったら、逆に私が開発をがんばろうかと（笑）。

――小宮さん自身の今後の展望について教えてください。

インフラのOKRとして稼働率や削減コストなどの目標値を設定し、これを達成すること、将来的にSRE（Site Reliability Engineering）に取り組むことでしょうか。

SREについては開発やネットワーク、インフラ、セキュリティなど幅広い知識が必要で、今のところ準備段階にあります。チーム内でそれぞれの知識をシェアして、カバーできていければいいですね。

実際、開発のメンバーがインフラを学び始めているように、私も事業部のプロジェクトで開発について教えてもらっています。開発とインフラの垣根を越えた、クロスオーバーな環境を作ることができているのは、素晴らしいことだと思っています。

――これからインフラチームも強化していくそうですが、どんな方とチームづくりをしていきたいですか。

オンプレミスの経験がある方だとありがたいですね。クラウドがどんどん便利になる一方で、その裏側にあるオンプレ環境を知っていることが強みになると考えています。
「そもそもどうしてネットワークがつながるのか」という仕組みや、プロトコルを理解していれば、問題解決の支えになりますし。オンプレミスの経験を活かしながら、日々リリースされるAWSなどの新しいサービスにも挑戦できる環境ですので、キャリアの幅も広がると思います。

あと伝えたいのは、今なら“やりたい放題”ですよと（笑）。システムを安定稼働させる、セキュリティを高める、コンプライアンスを遵守するといった、開発運用体制の見直しや基盤の改善に参加できるタイミングです…という意味での“やりたい放題”ですね。
こういうことがしたい、こういう技術を取り入れたい、という思いを、どんどん提案していただける方とお仕事できるといいなと考えています。