96%即日対応！組織の”潤滑油”として躍動する運用保守のプロたち

OpsGのミッションは、顧客第一の姿勢のもと、安定したリリースを行うこと、そして定常業務の自動化を進めることです。具体的には、お客様からの技術的な問い合わせに対し、他の部署とコミュニケーションを取りながら対応を考えています。特に連携することが多いのは、新機能リリースを管理・調整しているサービス開発部や、既存顧客からの操作に関する問い合わせ対応を行っているサポートオペレーショングループですね。

また、お客様からだけでなく社内の他チームからの技術的な相談に乗ることもありますね。例えば、営業企画から「こんなプランの提案を考えているんだけど、技術的に実現できるか？」といった質問に対して回答したり、情報システム部から脆弱性診断に関してやり取りをしたりなどです。様々な関係者とやり取りしながら、組織内外の潤滑油のような役割を担っているのがOpsGのユニークなところなんです。

目標に掲げているのは運用50%、改善50%の割合で、これは我々が所属する部の名前にも冠している「Site Reliability Engineering（SRE）」の思想に基づいています。運用業務だけでは技術的負債が溜まってしまうため、改善業務も運用と同じくらいのリソースを割いてその負債を解消していこうという考えのもと、同じくらいの割合で力を注いでいます。

ご紹介した通り、我々OpsGは他グループとのやり取りが多いです。だからこそ、我々のところでせき止めてはいけないという考えを持っています。組織間で情報をまたぐ際に発生する摩擦を最小限にして、効率的な流れを実現し続けることがOpsGに求められる役割であり、同時に課題だと思っています。

たとえばSlackで「開発相談所」というチャンネルをつくり、技術関連の問い合わせを受け付けていて、他部署やお客様からの質問に対してできるだけすぐに、解決できそうな人やチームに振ったり、自分たちで回答したりしています。

最近では、「提供されたアクセスログをどう読んでいけば良いのかわからない」という質問を頂きました。

ただ、質問の意図や背景などが抜け落ちており、すぐには答えにくくて。なので、より正確に答えるため、そしてお客様自身も気づいていない本質的な課題を発見するためにも、営業担当からもっと周辺情報をヒアリングしてもらって、その上で回答しました。こういうこともよくありますね。

問い合わせ内容を確認していく中で、具体的な技術レベルの回答が必要になったとき、私にバトンが渡ります。すぐに回答できない時は、開発メンバーと共にロジックを調査して、その結果を意味が伝わるように噛み砕いた上で問い合わせ元に回答します。

96%の問い合わせに対しては、日をまたがずに回答できています。時間をかけて調査が必要なものに関してはその限りではないですが、目標として1営業日以内の解決を目指しています。

私は安全にリリース業務を進めるための調整と、サポートオペレーショングループと連携しての情報整理を主にやっています。月曜日〜木曜日（祝前日を除く）は毎日何らかの機能やサービスをリリースしているので、開発チームと連携しながら、何を、どういった手順で、何時くらいにリリースするかをすり合わせ、安全に進むように調整するのがメインです。

私はお客様から依頼を受けた要望に対して、暫定的に手動で対応することが多いです。サービスの問題であれば飯塚さんに相談し、インフラ側の問題であればインフラグループの人たちと協力するなどして、起きている問題の解決に奔走しています。

私は大きく2つあります。1つ目はプロダクトのインシデント対応や社内で発見された不具合対応に関して、ロジックの修正を行うこと。案件が重なって量が多くなることもあるので、しっかり優先度を決めて順次対応しています。インシデントは急を要することがほとんどなので、開発メンバー・運用メンバーで協力して、迅速にユーザーに届けるように取り組んでいます。

2つ目は、工数削減や自動化進めるためのツール開発プロジェクト「カオナビメンテナンス」ですね。主担当として、毎月1機能のリリースを目標にしていて、スピード感を持って開発しています。これまでに14の新機能を開発してきました。

直近だと、顧客の環境を複製する機能をリリースしました。

テレビゲームで例えるなら、「トライアル版のセーブデータを元に、本製品でニューゲームできるようになる機能」でしょうか。「カオナビ」はお試し機能を無償提供していて、その環境を本契約後もそのまま自動的に利用できるようにするための機能です。

これまではお客様の要望に応じて、私たちがデータを移し替えていました。手動対応だったので、かなりの時間がかかっていたんです。「これを自動化できると助かる……」と思っていたところで、飯塚さんが中心となって設計・開発を進めてくれました。

そうですね。しかも、ヒューマンエラーの発生リスクも抑えられるので安全性も高まっています。

私は効率厨なので（笑）、無駄な作業を減らすことや手作業を自動化することそれ自体にやりがいを覚えます。無駄な時間が減り作業が安全になるわけですから、全社から好評です。

私も、作業を短時間でできるようになることに達成感を覚えますね。あとは問い合わせに対して「どうすれば解決できるか」「難しい要望や問題にどう対処できるか」と考えるのが楽しいです。

私は、カオナビメンテナンスです。リリース毎に効率が上がり、自動化したことでヒューマンエラーが減って、感謝の声ももらえることは嬉しいですね。

私が特にやりがいを感じるのは、お客様の問題が解決する瞬間に立ち会えるときですね。良い解決策や、課題を解消する回答をお返しできたら、すごく気持ちがよいものです。

ただそもそもで言えば、問題は発生すべきではありません。私たちがこのようなやりがいを感じる機会は、少ない方が望ましいといえるかもしれませんね（笑）。

各々自律的に行動できるチームです。だからこそ、本番環境をいつでも触れる権限を渡すなどしているので、個々人の自由度はけっこう高いんじゃないかな。

改善内容も限定しているわけじゃないんですよ。自動化でもいいし、運用リスクを下げることでもいい。対象もOpsGに閉じたものではなく、全体として組織が今よりも良い状態になることを目指してもらっています。

メンバー一人ひとりの得意分野が異なるので、その違いを活かして改善に取り組んでくれれば良いなと。

棚橋さんを一言でいうと「なんでも屋さん」ですね。AWSのことは私よりも詳しく、かつ幅広い知識を有しており、それを活かした改善業務を多くやってくれています。さらに、「カオナビ」の仕様にも詳しいので最前面での顧客対応もしています。

飯塚さんは仕様設計やメンバーマネジメントに長けていて、エンジニア管理や自動化業務のまとめ役を担っています。それでいてプロダクトの知見も多いんですよ。

坂田さんはまだ入社1年以内ですが、丁寧さが際立っており安心して仕事を任せることができますね。他グループとも密な連携ができるので、業務改善面でも期待しています。

運用面の仕事が増え、インフラグループなどと協力して問題に取り組む中で、大事になることが3つあると感じています。「何が本当に問題なのか特定するための確認・ヒアリングする力」「解決に向けて主体的・能動的に自ら行動する力」「自分のスキルや権限では解決できない場合に他の人を巻き込む力」です。

今後もますます求められると思うので、この能力をもっと高めたいですね。

私は、エンジニア以外の業務、例えば営業やカスタマーサポートもできるようなエンジニアになりたいなと考えています。将来的に技術が発展して運用の自動化がますます進んだら、エンジニアに求められるのが、オペレーションへの従事だけでなく、たとえばサービスを考えるといったオペレーション以外の能力にもなるかもしれないと思っているからです。

自動化、効率化を意識した取り組みを進めていきたいと考えています。

やはり、人力では捌ける量に限界がありますし、ヒューマンエラーも発生しますし、リカバリ時に労力を費やす必要がありますから。極論は手動作業をゼロにすることです。

個人としては、組織の連携を含めて生産性を向上させるための環境をエンジニアリングすること。これが長期的な目標です。

そして最後に、グループとしては、「より良い“潤滑油”になるために突き詰めていく」に尽きますね。リモートワークがメインになる中で、グループ・組織外との壁や摩擦が如実に現れるようになりました。それ自体は仕方ないとしても、その壁や摩擦を、組織間連携の仕組みをもっていかにして解決できるか。やりがいを強く感じられるチャレンジを、まだまだ続けていけそうです。