たった一人の監視から、DevOpsの土壌を作る一歩目とは。900社の採用管理を支えるSREが語るチームの変化
採用管理システム「HERP Hire」とタレントプール管理システム「HERP Nurture」の累計導入社数が900社を超え、サービスの信頼性がこれまで以上に求められています。今回は、HERPのインフラを支えてきたhiroqnさんtaketo957さんに、HERPでのSREの取り組みについて聞きました。
聞き手・執筆：久野美菜子（@nokuuun）
プロフィール
hiroqn（ひろきゅん）
創業初期からHERPの開発に携わるメンバー。飼っている猫が.zsh_historyに暗号文を残していくのが悩み
Twitter：＠hiroqn
taketo957（たけと）
2021年8月よりHERPにSREとして入社。犬の鳴き声がKrispを突破してしまうのが悩み
Twitter：＠taketo957
サービスをほぼ一人で支えた黎明期
ー まずは現在のHERPのSREチームのミッションと組織体制について教えて下さい
hiroqn（ひろきゅん）：
もともとサービスの信頼性を担保しようみたいな気持ちはHERPの黎明期から存在はしていて、それこそ創業期からいた私やryota-ka（＠ryotakameoka）などが自発的に手を上げてやっていました。
本格的に始動したのはtaketo957がはいった2021年8月頃からなので「こっからっす！！」という感じでやってます。正直、ミッションとか言うほどの状態じゃないんでなんで、SRE本（https://sre.google/books/）に則ってひたすら実践していくのが喫緊の目標ですね。
taketo957（たけと）：
組織体制としては、現在はhiroqnと私の2名体制でやっておりSREのメンバーは増やしたいと思っていますが、SREが主体ではなく、開発メンバーも含め会社全体でサービスの信頼性を担保できるようにするというのが目指している理想の姿です。
ー hiroqnさんはHERPの開発初期からSRE周りのことをされてきたと思うのですが、具体的にはどのような取り組みをしてきましたか？
hiroqn（ひろきゅん）：
まずHERP Hireβ版のリリース後、監視に取り組みました。当時、アプリケーションの運用経験があるメンバーが少なく、サービスの不安定な状態に四苦八苦していたのでDataDogを使って監視を導入しました。
他にはCI/CDに取り組んで、GitOpsできるようにArgo CDを使ってデプロイフローを整えました。マイクロサービスアーキテクチャだったのでオブザーバビリティを上げるためにも、2019年頃にはIstioを導入しました。
DevOpsの初手は開発者の運用への関心を高める定例会
ー その後taketo957さんが入社されてからSREがチームとして機能し始めたかと思うのですが、そもそもtaketo957さんはどういう経緯で入社されたのですか？
taketo957（たけと）：
hiroqnや代表の庄田さんとは、私が大学院生だった頃からお付き合いがあり、どこかのタイミングで一緒に働きたいなとは思っていました。前職の株式会社はてなには新卒から5年半インフラエンジニアとして在籍していたのですが、to Cのサービスでの経験をある程度積んだらto BのSaaSに関わりたいなという思いもあったので、キリのいいタイミングでHERPに入社することにしました。
ー to BのSaaSに関わりたいなと思ったのは何かきっかけがあったのですか？
taketo957（たけと）：
何か大きなきっかけがあったわけではないのですが、技術的に求められるものがto Cとは違いそうで、技術面での好奇心があったのが一つ目の理由です。あとは、ユーザーからのフィードバックをより得やすい環境で開発したいという思いもありました。そういった意味でも技術が面白そうでユーザーとの距離が近そうなHERPには惹かれました。
– はてなとHERPでは事業形態はもちろん、規模もフェーズもかなり異なるかと思いますが、SREとして特にどういった部分に違いを感じましたか？
taketo957（たけと）：
基本的な部分はhiroqnがやってくれていたので、基盤的な部分は思った以上に整っていたのですが、一方で運用を回すところは伸びしろがあると感じました。運用に関する知識を開発者側であまり持てていなかったのも一因ですが、当時はそもそも運用は開発者の責任範囲外という認識が強く、運用そのものに対する関心も低かったのだと思います。
hiroqn（ひろきゅん）：
そうですね。信頼性のためにコストを割くことより開発してリリースすることが優先されすぎて、そういうカルチャーになってしまった感じがしますね。当時はユーザーさんからの連絡が対応の基準になってしまっていて、連絡がきて初めて問題として取り組む、という後手後手の対応になりがちでした。
ー 特にサービスの黎明期だと、スピーディに開発を進めたいという欲求が強くなりそうです。このような状態から、DevOps的な土壌を耕していくにはどのような工夫があったのでしょうか？
taketo957（たけと）：
SREで基盤を整えた後は、開発チームでも自発的に監視できるように週一で運用面の確認をするミーティングを取り入れました。以前はhiroqnが一人でダッシュボードと睨めっこしていたのですが、開発者自身もミーティングで見ることで数値の肌感が得られてきたかなと思います。
hiroqn（ひろきゅん）：
最近はSREの土台である監視に、開発者が主体的に取り組むように変化してきました。開発側のruicc（＠ruicc）さんが運用観点を元々もっていて「開発チームでもちゃんと監視しよう！」という空気をATI※を持ってつくってくれたのもありがたかったっす。
※圧倒的当事者意識。HERPのバリューのひとつとして「ATIで動く」がある。
ー 開発者に運用に入ってもらったり、開発とSREの橋渡し的な方に動いてもらうことで、DevOpsの実現を目指してきたのですね。
前回のスクラム導入のnoteでも「全体の目線が合わせが大事」という話があったと思うのですがDevOpsの構築でもまさに同じことが言えるかもと思いました！
SREもDevOpsもまだまだここから…！！
ー taketo957さんは転職してから半年ほど経ったと思うのですが、仕事の進め方やカルチャーに関して前職とどのような違いを感じましたか？
taketo957（たけと）：
仕事の進め方としては、やりたいことを自由にやらせてもらえるのがありがたいですね。ピラミッド型の組織だと、上に話を通すまで数ステップ必要なところが、HERPはかなりフラットなのでアクションに移しやすいなと感じています。
あとは採用している開発言語のひとつがHaskellと特殊で、AWS周りやTracing周りに公式にサポートされたライブラリもなかったりするので、他の会社に比べ関与する範囲が広いのが楽しいですね。他の会社がやってることを単に移植するだけでは上手く行かないところも多いのでやりがいを感じます。
ー 最後に、HERPのSREチームのこれからの展望や、こんな人に来てほしい！という希望があれば教えて下さい。
hiroqn（ひろきゅん）：
これからSLI/SLOをサービスに導入しようという段階なのですが、体制としてはまだ2人でリソースも足りてないので、組織をつくること自体に取り組んでいける人ですかね。究極的には、SREがいなくても開発チームで運用を回していける組織を目指しています。
taketo957（たけと）：
ペルソナとしては、技術的興味が高くて、どちらかというとリサーチャー気質を持った人が楽しめるポジションかなと思います。SRE自体の経験はあまりなくても大丈夫です。例えばこれまでバックエンド中心にやってきたけど、ちょっと新しいことやりたいなと思ってる方や、技術領域の知見をもっと深めたい人におすすめです。
hiroqn（ひろきゅん）：
性格的には人間性の喪失を恐れない人、カオスなアプリケーションに深くダイブできる人ですかね。また課題をストレートにコミュニケーションしてくれる人のほうが個人的にはやりやすいですね。
カジュアル面談歓迎！
転職の予定がない場合でも、HERPではカジュアル面談を歓迎しています。
過去の開発組織の記事はこちら
HERPの採用情報
プロダクト開発の求人一覧はこちらから。
https://herp.careers/v1/herpinc/requisition-groups/84aec4e1-19c7-4268-b62a-027470d1ebd9/?utm_source=note&utm_campaign=note_article
採用サイトで、カルチャーデックなど組織の情報を公開しています。
GitHubでエンジニア向けの採用資料も公開しています。