この記事は GENDA Advent Calendar 2025 シリーズ4 15日目の記事です。
私は2023年3月にGENDAに入社しました。あと少しで入社3年となります。
この3年間で組織や働き方に変化があり、その過程で自分の考え方にも変化がありました。
今回のアドベントカレンダーを絶好の機会として、これまでの道のりを振り返ってみます。
1年目
入社当初は、 GiGO ONLINE CRANE というサービスの専任インフラエンジニアとして配属されました。
当時は内製化[1]されてから間もなく、インフラ面の課題が全て洗い出せているわけではなかったため、自分自身で課題を見つけて改善していくことが求められました。
個人目標とプロダクト施策の乖離
当時のSRE/インフラチームの評価軸に従って個人目標を設定し、当面やるべきことは明確になったものの、その時点ではプロダクト開発の全体像がまだ見えていませんでした。
個人目標を達成しようと取り組むうち、ある時期から、自分はチーム全体の動きから外れていると感じるようになりました。
GENDAのプロダクト開発では、事業をより成長させるため、プロダクトマネージャーが施策の計画を立て、エンジニアがその実現に貢献します。
ですが、私の目標はプロダクト側と相談せずに決めたため、「プロダクトとして計画している施策」と「インフラエンジニアとしてやりたい改善」がそれぞれバラバラに存在している状態でした。
もちろん、インフラの改善は機会損失を減らし利益を最大化するために必要なことではありますが、施策に沿って機能開発しているバックエンドエンジニアやモバイルエンジニアとは完全に別軸で動いており、まるで違うチームのような感覚がありました。
インフラの改善はインフラエンジニアだけで完結することは稀で、バックエンドの対応が必要になることが多いです。しかし、自分の目標を事前に伝えていない状態でバックエンドエンジニアの協力を要請すればどうなるか。
当然、プロダクトにはプロダクトの計画があるので、「今はバックエンドエンジニアの方には機能開発に集中していただきたいです」と断られてしまうこともあります。
個人目標を達成するために割り込みでお願いをしなければならない心苦しさから、だんだんコミュニケーションを避けがちになってしまいました。
また、プロダクト開発チームとは別にSRE/インフラのチーム自体は存在してはいたものの、他のメンバーは別領域で業務しており、チームとして同じ課題に取り組むことはほぼありませんでした。
誰とも共通の話題がなく誰とも悩みを分かち合えず、一人で自分だけのタスクをこなす日々は、孤独感のあるものでした。
やってよかったこと
そんな中でも、入社直後にやってよかったことが2点あります。
1つ目は、元々の会議体で用意されていた1on1の枠組みを超えて、プロダクト開発チームのメンバーと1on1をしたことです。
前述の通り私は他のメンバーとは別軸で作業することが多く、いざ垣根を超えて相談したいとき、どうやって声をかければいいか分かりませんでした。加えて、地方からフルリモートで勤務しており、その時点で同僚に直接会ったことがない点も会話のハードルを上げていました。
1on1では「Slackではどんな感じで声をかけたらいいですか？」といった実務的な話から趣味の話までいろいろな話ができ、その後のコミュニケーションのしやすさがぐっと上がりました。
一度じっくり話したことがあるという安心感は予想外に大きかったです。
2つ目は、オンラインクレーンゲームの実際の筐体が動く倉庫[2]へ見学に行ったことです。
オンラインクレーンゲームの画面の向こうでは何が起きていて、現場のスタッフの方がどんな作業をしているのかを見ることで、自分の扱うシステムの解像度が上がりました。
それにより、どんな機能がよく使われるのか、どこが止まるとクリティカルなのか、といった点を把握して監視や運用に活かすことができました。
2年目
調整に奔走
1年目の反省を活かし、2年目は期初に「インフラロードマップ」を作成しました。これは、今期やりたいインフラ改善案と得られる効果、必要な開発リソースをまとめたものです。
インフラロードマップの冒頭に記載した年間スケジュール
その後プロダクトマネージャーとの会議を設け、インフラロードマップとプロダクト側のロードマップのすり合わせを行いました。特に注意したのはバックエンドやモバイルエンジニアのアサイン調整で、プロダクト側の機能開発で繁忙になる時期をあらかじめ共有してもらい、それと重ならないタイミングで他エンジニアの手を借りられるよう調整しました。
この取り組みにより、お互いがお互いの計画に合意し、1年目よりもスムーズに動くことができました。
それから数か月経った頃、想定外の出来事がありました。
Aurora MySQL バージョン2（以下Aurora2）からバージョン3（以下Aurora3）へのDBアップグレードに着手していたときのことです。
元々は機能開発と並行してDBアップグレードを進める想定で、機能開発はAurora2と接続した通常のステージング環境で行い、DBアップグレードに伴う動作確認はAurora3環境と接続した一時的なテスト環境で行っていました。
しかし、これらを並行して進めると双方に問題が発生しうることに気付きました。
- 機能開発側の問題: Aurora2前提で開発するため、Aurora3で動かないおそれがあり、その場合は二度手間で修正が必要になる
- DBアップグレード側の問題: Aurora3で網羅的に動作確認しても、バックエンドのコードがどんどん変わるため、確認結果がすぐ陳腐化する
並行することで逆に全員の作業を増やしてしまうと考え、問題点をドキュメントにまとめてチームメンバーに相談しました。
実際にメンバーへの説明に用いた図。開発してからの修正が二度手間になることを示している
結果的にメンバーの合意を得られて、DBアップグレードの優先度を上げる方向でプロダクトマネージャーが事業責任者に掛け合ってくれたため、機能開発の前にDBアップグレードを終わらせてしまうことができました。
これらの調整に奔走していて、ふと気付きました。
「インフラエンジニアって、思ったよりコミュニケーションの多い仕事かも？」
インフラ的な改善はどうしてもプロダクトの機能開発とは別軸で動くことになるため、それらが干渉しあうときにどう調整して進められるか、は非常に重要なスキルだと感じました。
コミュニケーションの見直し
この気付きから、理想的なコミュニケーション（自分はフルリモートなのでとりわけチャットでのコミュニケーション）について考えるようになりました。
当時、私は社内のSlackに自分のtimesチャンネルを持っており、そこで日々の気付きや感じたことを書いていました。その中には、「わざわざ誰かに言うほどでもないが、あわよくば届くといい」程度の意見もありました。
あくまで独り言であるという体裁ですが、結局その当事者が見て反応してくれるという、構図的にはいわゆる「察してちゃん」になっていました。
自分の振る舞いを見つめ直したとき、こんな察してもらうようなコミュニケーションではだめだ、もっと自分から対話をしにいくべきだ、と感じました。
そこで自分のtimesチャンネルを廃止し、以降は、伝えるべき相手に適切なチャンネルで伝えるという方針に切り替えました。これまで自分のメモとしてtimesに書いていた参考情報なども例外なく、すべて適切なチャンネルに振り分けるようにしました。
その結果、それまでよりもSlack上のコミュニケーションが充実したので、これは良い判断だったと思います。
組織再編による環境の変化
半年が経ったところで大きな組織再編があり、Platform Engineering部（当時はChapter）が発足しました。
この部署は、各プロダクトを支える立場であるEM・SRE/インフラ・QAの3チームを1つにまとめたものです。
プロダクトの機能開発とは少し離れたところから開発を支援するという、社内での立ち位置が似ている人が集まっているため、分野が違っても悩みの性質が似ていて共感しあえる雰囲気でした。また、EMのメンバーとは協力してAWSの管理業務を行うことが多くあり、仲間と一緒に取り組めるうれしさがありました。
このときSRE/インフラチームは自分1人になりましたが、1年目で感じていた孤独感はなくなりました。
このあと徐々に、「1プロダクト専任」から「複数プロダクト横断」の働き方にシフトしていきました。その背景は、2年間でGiGO ONLINE CRANEのインフラが安定してきて手離れが進んだというのもありますが、ハイペースなM&Aによりプロダクトがどんどん増えており、SRE/インフラを1人ずつ1プロダクトにつけるというのが非現実的になってきたのが大きな要因です。
体制の変化。1人1プロダクトではスケールしないため、横断的な働き方にシフトした
3年目
チームが一丸となっている心強さ
SRE/インフラチームの採用が進み、現在は3人のチームになりました。
3人の役割はゆるく分かれていますが、それぞれの作業を他メンバーがレビューしたり、こまめに会話の機会を設けることで、他のメンバーが何をやっているのかをしっかりと把握しています。
チーム内で困りごとがあればすぐに相談する文化が定着しており、私自身も各プロダクトの様子に目を光らせて、必要に応じて他メンバーに「これってどんな状況ですか？」などと声を掛けるようにしています。
3名体制になって間もない頃、SRE/インフラのメンバーで対面で集まり、チームの今後について話し合いました。
- 事業への貢献
- 開発者への貢献
- 自分たちの運用業務の効率化
という3つの軸をSRE/インフラチームのミッションとし、それぞれの軸について、どのような状態が理想かを議論し、優先的に取り組むべきタスクを決めました。
この集まりを最初にやっておいたことで3人の目線を合わせることができ、以降もこまめに会話の時間を設けることでその状態は継続できています。
特に最近よかったことは、AWS re:Inventで発表される最新情報をみんなで持ち寄り、楽しくキャッチアップできたことです。
1人では拾いきれない情報も、他のメンバーが「これ良さそう」と共有してくれることで知ることができ、「何が変わったんだろう？」「どんな使い方ができるだろう？」とワイワイ話せたことはとても楽しかったです。
この楽しさは今まで経験したことがなく、同じ方向を向いている仲間がいるってうれしいな〜としみじみ感じます。
プロダクトチームとの連携強化
「事業への貢献」「開発者への貢献」を実践するため、1〜2年目に私がGiGO ONLINE CRANEでやっていたように、プロダクト開発チームに入り込んでいちメンバーとして課題に取り組もう、という活動を始めました。
最初は、こちらからインフラの改善提案をしたり、プロダクト開発チームからの要望を聞いて対応していました。しかし、インフラの改善よりも機能開発が優先となったり、特に要望が上がってこなかったりで、自分たちはどこで貢献したらいいのかと悩むこともありました。
そんなとき参加したカンファレンスで、他社のSREの方から「自分たちが先に動かないと、他のチームの人にとっては、何を頼めるのか分からなくて何も頼めない」というお話をお聞きしました。これは当時の自分にとって天啓ともいえる言葉でした。確かに、言葉だけで「Datadogの〇〇という機能を使ってみませんか」とか「ダッシュボードを作りませんか」なんて言っても、実際のモノがなければその恩恵を想像できなくて当然です。
そこからは、とにかく行動に起こすことや、まず作ってみるということを実践しました。
例えば、Datadogをトラブル時だけでなく日頃から見て洞察を得られる存在にしたかったため、ひとまず自分が良いと思う形でダッシュボードを作って、フロントエンドやバックエンドのエンジニアに見せました。何もないところからは要望は出にくいですが、具体的なモノがあることで「ここはもっとこうだといいな」「このグラフはなくていいかも」という相対的な要望が出やすくなるのを体感しました。
ありがたいことに、最近は各プロダクトから相談や要望をいただく機会が増えてきました。実績が積み重なってくると、その実績を見てまた他プロダクトからも声がかかる、という好循環ができてきたと思います。
まとめ
この3年間を振り返ると、技術的なことはもちろんですが、それ以上に「組織の中での自分やチームの在り方」を模索し続けていました。これまでの苦悩に思いを馳せると、それらがようやく落ち着いてきたことに安堵します。
しかしここで終わりではありません。変化を続けるGENDAという組織で、求められることは刻一刻と変わっていきます。きっと新たな苦悩が待ち構えていることでしょう。
それでも、自分なりに良い道を考え、頼もしい仲間と議論し、これからも乗り越えていければと思います。
4年目もよろしくお願いいたします！
Discussion