「動いていて当たり前」こそ、刺激があって面白い。ラクス × メタップスのメンバーが語るインフラエンジニアの魅力
企業の情報システムにおけるハード面やネットワーク面を支える存在として、必要不可欠なインフラエンジニア。「システムは動いていて当たり前」の世界だからこそ、なかなかその重要性が理解されず、トラブルが発生した時は「インフラチーム、しっかりしてくれよ」とネガティブな視線を送られてしまう。そんな日の目を浴びにくい職種でもあると言えます。
今回はそんなインフラエンジニアの魅力を語るべく、メタップスのSREエンジニアが、中小企業向けクラウドサービスを展開するラクスのインフラエンジニア2名にお話を伺いました。
自社サービスのインフラ担当だからこその、楽しさややりがいはどこにあるのか。ざっくばらんに語っていただきました。
目次
プロフィール
インフラ開発部 大阪インフラ開発課
インフラ開発部 大阪インフラ開発課
マネジャー / SREエンジニア
非エンジニアからのインフラチーム配属
山北：まずは、おふたりのご経歴から教えてください。
野々村：2014年にラクスに入社したのですが、それ以前は全くの畑違いで、調剤薬局の運営会社で3〜4年、新規店舗展開やその運営などをしていました。
入社後は、問い合わせ管理システム「メールディーラー」の保守運用を1年半やった後に、現在までメールマーケティングサービス「配配メール」と、メール配信サービス「クルメル」の保守運用をしています。
戸成：僕は2016年に新卒入社して、現在で5年目です。
情報系の大学を出たわけではなく、新卒研修中の配属発表でインフラ配属と言われ、インフラの「イ」の字も知らないところから始まりました。
OJT担当のおひとりが野々村さんでして、今は同じく、「配配メール」と「クルメル」の保守運用をしています。
山北：おふたりとも、もともとは非エンジニアだったんですね。同じチームということで、チームの構成と役割も教えてください。
野々村：体制としては、リーダー 1名、サブリーダー1名、メンバー5名の計7名チームでして、私はリーダーとして、チームメンバーの仕事の進捗管理をしています。
戸成：僕はメンバーとして、基本的には期初に割り当てられた案件の対応や運用で発生したタスクを消化しています。ときどき、共同で進めているタスクとして後輩のタスク管理をすることもあります。
あとは、割り込みの運用タスクやアラート対応は随時行っています。
「秘伝のタレ」的な設計をドキュメント化していった
山北：次に、現在採用されているサービス基盤についても教えてください。オンプレですか？それともクラウドですか？
野々村：ほぼオンプレですが、一部でAWSも使っています。割合でいうと9:1くらいで、オンプレではVMwareとNutanixを使っています。
山北：開発言語は何を使っていますか？
野々村：配配メール・クルメルのアプリケーションはPHPで動いていますが、インフラチームが運用で利用しているスクリプトにPython、Perlを利用しています。
山北：あとは、監視周りは何を使っているのでしょう？
野々村：Zabbixを使っていますね。
あと最近、構成管理としてAnsibleを導入しました。社内を見渡すと、たまに「秘伝のタレ」的な設計が出てきてしまったりするので。
山北：なるほど。秘伝のタレ関連でお聞きしたいのですが、これまでの業務の中で苦労したエピソードがあれば教えてください。
野々村：もともとは別のメンバーが今のシステムの保守を担当していたのですが、ある時、急な形で辞められることになって、引き継ぎがほとんどありませんでした。
引き継いだはいいものの、ドキュメントベースで残っているものがほとんどなく、色んな設定を掘り起こしてドキュメント化していったのが、個人的に苦労したエピソードですね。
山北：保守あるあるですね。戸成さんはいかがですか？
戸成：ちょっとレイヤーが違う話として、どれだけメール配信環境を整えても、配送先の都合やポリシーによって、メールが届かないこともあります。要するに、IPレピュテーションがあって、判断も受け手側のシステムによるので、解決できないこともあるわけです。
でも、エンドユーザーとしては、同じ「配信されない」なんですよね。そういったお問い合わせについて細かく調べたりするのは、日々苦労している部分でもあります。
野々村：帯域はボトルネックになりやすいですね。
帯域が枯渇したのであれば値で取れるので、Zabbixで取ってそこから対策しますが、配信先キャリアの都合上で、例えば配信ブロックの検知など把握できない場合もあります。その場合は、スクリプトで細かな条件を設定して監視・検知ができるようにしていますね。
山北：実際にインシデントや課題が発生した場合は、どんな形で対応されているのですか？
野々村：基本的には、社内用の「楽楽販売」でレコード登録して、1つずつ暫定対策と恒久対策を潰していってます。
社内の風当たりが強かったところから
山北：おふたりが担当している「配配メール」は2007年リリースと伺っています。他にもラクスさんは歴史のあるサービスが多いと思いますが、技術的負債とはどのように向き合っていますか？
戸成：インフラ部分に関してはあまり…。ただ、先ほど野々村が言っていた通り、昔からあるスクリプトのドキュメントが残っていない、といった苦労はしています。属人性の問題ですね。そういった暗黙知は随時なくしていくよう情報共有に力を入れています。
あと、最近はPerlをPythonに置き換える、ということをしています。
野々村：サービス運用をする上で、シェルでは難しい部分があったので、2〜3年前に社内でPython勉強会をはじめて、そこからPerlからPythonへの置き換えをできるところから進めています。
山北：なるほど。インフラって、なかなか表に出てこないと思うのですが、ラクスさんの社内でインフラチームの大変さは理解されている感じですか？
野々村：最近までは知られてなかったという認識ですね。やってることは目に見えなくて、出てきたと思ったら障害かよ、ってところだと思います。風当たりは結構強かったのが正直なところですね。
定期的な上長との面談の中で、目に見える障害だけが目立ってしまっていることを率直に伝えました。そこから、事業部門に対して、インフラでの取り組みの発信を強化していっています。
インフラもちゃんとやってくれている、という認識が醸成されてきていると感じています。
山北：そんな日の目を浴びにくいインフラエンジニアをやっていて、モチベーションが下がったり、キャリアに迷ったりしたことってありますか？
野々村：「動いていて当たり前」がメインで、且つ開発のように目に見える成果物があまりないので、正直なところモチベーションは下がりやすかったですね。特にインフラってプライベートで開発しにくいので、個人学習がモチベーションの向上に繋がりにくいところもあると思います。
僕の場合は、フルスタックができるようになれば、という気持ちでプログラミング言語を学習したりしてモチベーションを保ったりしていました。
戸成：なりたい姿はあまり考えたことがないのですが、エンジニア云々は関係なく、興味を持ったものに近づいていけば、なるようになるのではないかと思っています。
サービスの成長を「自分ごと」として感じることができる
山北：インフラエンジニアとして働き始めた時に「なんでこれやってるんだろう」と思ったけれど、後からその意味や必要性がわかった、みたいなことってありますか？
戸成：現在進行形で対応中ですが、先ほどお伝えしたAnsibleによる構成管理ですね。以前はサーバの設定変更などは、コマンドやスクリプトでもいいのではと思っていたのですが、配属された頃と比べてサーバの台数が倍くらいに増えたんですよね。コードによる構成管理があることで運用負担が削減されたと感じています。
野々村：僕の場合はWBS（Work Breakdown Structure）の作成ですね。最初は「何回、WBSの報告の機会があるんだ」と思っていましたが、今ではプロジェクトを進める上でWBSを作成してのタスク実施は、自分の強みにもなっています。自分のスケジュールも管理できるようになりました。
山北：いいですね。先ほど苦労エピソードを伺いましたが、逆に、今までで業務の中で一番面白いと感じたエピソードも教えてください。
野々村：一番苦労したエピソードに付随しているんですが、インフラエンジニアとして入って1〜2年で保守運営を管理する立場になって、確かにドキュメントがなくてしんどい面もあったのですが、それがあったからこそ今の自分があります。今振り返ると面白かったなと思います。
また、ドキュメント化して暗黙知を減らすことで社内の生産性向上への寄与も出来たのではないかと思います。
戸成：OSのEOL（End Of Life）の対応で、OSのバージョンアップを行ったことです。バージョンごとの違いを調べたり動作検証したりと1つずつやっていったのですが、ほぼひとりで出来たことに自分の成長を感じました。
これが5年間の上積みかと。できるようになるのは面白いです。
山北：今の話と関連して、自社サービスのインフラを担当していることで感じるメリットも教えてください。
野々村：裁量をもって、業務を行うことができるところですかね。あと、サービスの成長を「自分ごと」として感じることができるのも、自社サービスインフラならではのメリットだと感じます。
戸成：同じサービスを長く担当することで分かっていくことも多いです。自分たちでサービスの課題を深堀りして、解決まで持っていくことができる。仮説検証ができて、しっかりとPDCAを回していけるのも、良いところかなと思います。
ちゃんと自分の考えを可視化して、仮説を立てる
山北：ここまでお話を伺って、業務を行うにあたってはマインドセットも大事なのかなと思いましたが、日々大事にしているマインドを教えてください。
戸成：自分が大事にしているのは、本番環境を直接操作することもあるので、とにかく慎重に行動することですね。それにプラスして、周囲の人とはコミュニケーションをとって関係を良くしておくことも大切だなと。何かあったとき、ひとりでは解決できないことも多いので。
あとは、ちゃんと自分の考えを可視化して、仮説を立てることも大事だと思っています。そうじゃないと、自信をもっての対応ができないなと思います。
山北：自信をもっての対応って、ある程度の知識と経験も必要だと思うのですが、例えば配属前にそのあたりの教育ってされているのでしょうか？
野々村：新卒入社後は4〜7月まで全体研修をして、そのあとは各部で個別にやっています。インフラチームの場合は7月から12月まで座学と実習、年明けからはOJTです。ロジカルに考える練習として、週1で振り返りとそのフィードバックもしています。
戸成が入社した翌年からこの仕組みがスタートしました。
山北：ということは、戸成さんはこういう流れではなかったと。
戸成：そうですね。ややぶっつけ本番的なところはありました（笑）
もちろん、開発環境で検証したエビデンスはありますし、本番環境はダブルチェックで進めていくのですが、何をしたら壊れるのか分からなかったので、本当に恐る恐るでした。
山北：でもエンジニアって、そういう環境を経て成長していく部分もあると思うんですが、その辺、野々村さんはどう感じますか？
野々村：確かに、たたき上げの方がトラブルに強いような印象はありますね。ただ一方で、研修フローがある方がフィットしている人もいて、この辺りは人による部分もあるかなと思っています。OSSを中心に自分たちで構築から運用まで行うのに必要な知識を、最初から広く身に付けられるので、うらやましい面はあります。
個人的には、インフラエンジニアのスキルって、プログラミングみたいな職人芸的なところはさほど必要ないと感じていて、それよりも、ものごとを関連づけて考えたりする力の方が大事だと思っています。
日の目を浴びるのは基本的には問題が起きたとき。表に出ないのは名誉
山北：改めてとなりますが、日の目を浴びる機会が少ないインフラ領域に感じている使命を教えてください。
野々村：先ほどもお伝えした通り、インフラチームがやってることは、理解されにくいことが多いです。でもその裏で、OSのEOLとか、どうしてもやらねばならないことはあるわけです。
動いていて当たり前、を実現しているという自負はありますね。
戸成：日の目を浴びるのは基本的には問題が起きたときなので、表に出ないのは名誉なのかもしれない、と思っています。
山北：インフラならではの面白さを、社内の他の部の人に伝えるとしたら、どうでしょう？
野々村：どんなレイヤでも幅広く触れる機会がある、ってところですね。経験があってこそ解決できる問題に向き合えることは楽しいです。
戸成：障害が発生したときに、原因調査から原因特定までできると、気持ちいいなと感じます。もちろん、障害発生自体はモチベーションが下がる要因なので、なくすべきではありますが。
あと面白さとは違いますが、業務でインフラを触っていると、あとはコードを書ければフルスタックエンジニアに近づけるので、ここもメリットかなとは思っています。
野々村：僕も一緒ですね。
山北：ありがとうございます。最後に、おふたりの今後の目標などを教えてください。
野々村：まさに今戸成がお話したことと一緒で、インフラ運用は書籍での学習だけでは難しい部分があるので、インフラ経験があることを活かしてプログラミングを学習することで、フルスタックになれたらいいな、と思い続けています。
今は、4年前のPython勉強会がきっかけで、自分でも何かしらのWebサービスを作りたいなと思っていて、個人的なレベルですがちょこちょこ勉強を進めています。
戸成：遠い将来のことは考えていませんが、まずは問題解決能力に長けて、仕事で人に頼られる人間になれればと思っています。
ちなみに私も、そのPython勉強会に参加していて、個人的な趣味としてWebサービスの構想があって、休みの日に勉強したりしています。
山北さんから今回のインタビュー内容についてコメントいただきました。
ラクスさんは昔からのサービスが多い中で、システム的な課題やセキュリティ面など、いずれも自動化が求められる中で、そこにきちんと取り組まれているのが良いなと感じました。
インフラエンジニアはサービスを支える「縁の下の力持ち」。無くてはならない存在です。成果が見えにくいなど大変なこともありますが、お互いに頑張りましょう！
編集後記
インフラ関連のトラブルは、それこそ原因と考えられる要素がたくさんあるので、仮説構築力が試されることになります。最悪の場合、サービスを止める事にもなるがゆえに、スピードとの勝負になるところもあって、ハードな仕事である反面、解決した時の安堵感ややりがいは非常に強いのだろうと感じました。
ラクスのインフラエンジニア、熱いです！
取材／文：長岡 武司