「誰かが作った理想に乗っかるだけではなく、ゼロの状態から『何が理想なのか』を追求していかなくちゃいけない。そういった挑戦がとても面白そうだと感じ、エクサウィザーズを選びました」

「エクサウィザーズ」で活躍する“ウィザーズ”たちを紹介するストーリー。
「インフラこそすべて」の考えのもと、構造や仕組み作りを追求し続けるDevOpsエンジニアの青木さんに、インフラ分野への取り組みや、エクサウィザーズで目指す理想のインフラ環境について伺いました。

海外留学で体験した、「不安定なインフラ」が原因の機会損失

あらゆるプロダクトは「作って終わり」ではありません。多くの方々に使い続けていただくためにも、「安定した運用体制」は欠かせない要素。そんな運用を開発面から進めていくのが「DevOps」の役割です。

DevOpsとは、「Development」と「Operations」をかけ合わせた言葉で、プロダクトの開発に加えて、安定した運用体制や仕組みづくりを行います。

どんなに素晴らしいプロダクトも、動かなくなってしまっては意味がない。

そんな僕を「インフラ分野」へ向かわせた転換点は、大学時代。高校時代までは数学が好きだったので、大学では数学の延長線上にある工学部の電気・情報系に進学します。

勉強する中で、「コードを沢山書くより、抽象的な構造に向き合うほうが好きかもしれない」と気づき、大学院では情報サイエンスに変更。論文に追われる日々はなかなかハードでしたが、海外の相手と共同研究したり、修了間際までジャーナル論文に追われていたりと、いい経験をしました（笑）。

在学中で印象に残っているのは、アイスランドへの留学です。アイスランドはソフトウェア技術が発達しているものの、ネットワーク環境が整っていなかったんです。いいプロダクトがたくさんあることはわかっているのに、なかなかネットがつながらずに使えない経験を何度もしました。「どれだけソフトウェアが良くても、インフラが整っていないと機会損失になる」と感じた瞬間でした。

また、当時はクラウドコンピューティングがまさに流行り始めたタイミングでもあり、ソフトウェアと複数のインフラを連携させるものが増え始めていました。

「ソフトウェア開発が注目されがちだけれど、逆張りとなるインフラ分野へ進んだほうが面白いのではないか？」

そこで、大学院卒業後は、国内でも大規模なネットワークのインフラを支えるNTTコミュニケーションズ（以下NTT）へ就職しました。

「理想形は現場から出てこない」　NTT、楽天で培った自動化の肝

NTTでは、ネットワーク構築・運用周りをひと通り担当。その一環として進めていたのが「自動化」でした。

NTTには、多くのユーザーがいて、その一人ひとりのお問い合わせをコールセンターが対応していたのですが、その数があまりにも膨大なため、回答まで時間がかかってしまうという課題を抱えていました。

お問い合わせの内容は、難しいものから即回答できそうなものまでさまざま。そこで僕が思いついたのが「簡単なお問い合わせに、チャットボットで対応する仕組みづくり」です。

このアイデアをもとに、小規模なところから自動化をスタート。徐々に影響範囲が大きくなり、結果的には「組織として自動化をどう受け入れるか」まで話が発展していきました。小規模に始めた自動化プロジェクトが組織に深く根ざしていく過程は、僕にとってNTTでの印象的な仕事でしたね。

その後、NTTで培った自動化のスキルをさらに深めるため、「自動化エンジニア」としてキャリアを積み、楽天に転職します。OS依存になりがちなネットワーク機器の操作を、YAMLのような汎用的なデータ形式で編集できるようにしたり、オペレーション担当以外でも設定できるようにしたり。エンジニアだけじゃなく、ビジネスサイドを含めた多くの人が運用に関われる土壌づくりをしていました。

NTTと楽天、この2社で自動化に挑んで感じたのは「本当に欲しいものは、現場から一歩引いた位置からこそ見えてくる」こと。

例えば、コールセンターの仕事はお客さまからのお問い合わせ対応など、日々のオペレーションを回すこと。そのため、「こんなものがあったら便利なのに」といった潜在ニーズに気づきにくい。必ずしも彼らが行う業務の延長線上に「理想の機能、状態」があるとは限らず、時にそれは一歩引いた視点でしかわかりません。

そのため、コールセンターなど実際に業務を行う場での運用方法・状態・責任範囲を把握し、「この方法はどう思いますか？」と潜在ニーズに対して仮説をあてながら進めていく必要があります。技術力も大切ですが、コミュニケーション力も同時に大切です。この大事なステップを、NTTと楽天で学びました。

まだベストプラクティスがないMLOpsに挑みたくて

そして2020年に、エクサウィザーズへ入社しました。実は、楽天はとても楽しかったので、転職はまったく考えていなかったんです。でも、お声がけいただいて、カジュアルに話を聞いているうちに、エクサウィザーズでは当時100名規模ですでにDevOpsを重視していること、さらに今後はMLOpsにも力を入れていくと聞き、強く惹かれていきました。

だいたいにおいて、仕組み化や文化形成のような仕事は、構築フェーズを乗り越えてある程度落ち着いた企業の次のフェーズとして取り入れる印象がありました。その点、エクサウィザーズではサービス立ち上げのフェーズからすでにAWSなどを運営するインフラ担当を「DevOps」と呼んでいました。

何より「おお！」となったのは、MLOpsがあること。

例えば、インフラ周りにおけるDevOpsのベストプラクティスは、すでにある程度提唱されており、ある意味で誰かが生み出したベストプラクティスに追従する形での実装がどうしても一定数は発生すると感じていました。

一方、MLOpsは、まだまだベストプラクティスが定まっていない分野です。誰かが作った理想に乗っかるだけではなく、ゼロの状態から「何が理想なのか」を追求していかなくちゃいけない。そういった挑戦がとても面白そうだと感じ、エクサウィザーズを選びました。

面接過程では二つのことが印象に残っています。一つは、技術面での面接時に「◯◯という技術は使ったことがありますか？」より、「例えばこういう場合、どういった技術を取り入れますか？」「この技術を取り入れることを、どう思いますか？」と聞かれたこと。これまでの経験より「これからの考え方」を注目されているようで、強く印象に残りました。

もう一つは、代表の石山さんとの面接時に、プロダクト愛がわかる語り口で、ホワイトボードまで持ち出して図解して説明してくれたこと。熱量の高さを感じました。

現在は、プロダクト開発やリリース、運用に至るまでの一連の流れを担当。プロダクト開発では、MTGにも参加させてもらい、「この設計なら、インフラとの親和性が高い」「ここを変えたほうが運用費を削減できる」など、アーキテクチャ面でのサポートをさせてもらっています。

以前はプロダクト開発がほぼ終了段階になってから運用面を相談されることもありました。なかには「もっと早い段階で相談してもらえたら、運営費を削減できたかもしれない」と思うことも。その点、エクサウィザーズでは最初から一緒に参加できるので、嬉しいですね。

目指すのは、そもそも運用させない「“No”Ops」

僕はエクサウィザーズで、楽天時代からずっとやりたかったことを実現できるんじゃないかと考えているのです。それが、「DevOpsを“No”Opsにすること」。

DevOpsは、運用の効率化を極限まで高める取り組みですが、そもそも「運用しなくていい状態」になるのが一番理想的ですよね。例えば、障害が発生する可能性が少しでもあったら、運用が手を下さなくても基盤側が自ら変わってくれたほうが断然いい！

この話をDevOpsチームのリーダーであるパトリックさんにしてみたところ、とても共感してくれました。この構想自体をチームメンバーと頻繁にしているわけではないものの、「運用しなくていい状態を目指す」「運用を複雑にすることは避ける」価値感は同じのようです。

今後、エクサウィザーズからは、社会課題を解決するためのプロダクトが続々と登場します。だからこそインフラ面は、的を絞ったソリューションではなく、マクロで守備範囲の広い体制を備えておきたい。

インフラの仕組みを考えるうえでの難易度は、影響する範囲が広がるほど高まります。“No”Opsにすることも含め、エクサウィザーズのDevOpsエンジニアとしてインフラ分野を追求し、ゆくゆくは社会課題の構造そのものの改善につなげていきたいですね。

（撮影の時だけマスクをはずしています）

文：福岡夏樹　編集 / 写真：稲生雅裕