こんにちは、技術部 技術基盤グループの kmsnです。
先日 Tamachi.sre で「Issueを見極める信頼性」というテーマで登壇しました。 本記事では、登壇内容をもとに、SREとして日々の業務の中でどのように「本当に解くべきIssue」を見極めているか、その考え方と実践についてまとめます。
なぜこのテーマを書こうと思ったか
日々の運用や改善活動に取り組んでいると、多くの課題に直面します。 しかし、それらすべてを同時に解決することはできません。
限られた時間とリソースの中で、「どのIssueに向き合うべきか」を見極めることは非常に重要だと感じています。
私自身、コスト最適化や運用改善に取り組む中で、表面的な問題と本質的なIssueは異なるということを何度も経験してきました。 最初は「とにかく改善する」ことに集中していましたが、次第に「どの改善が本当に価値を生むのか」を考えるようになりました。
本記事では、そうした経験から得た「Issueを見極めるための考え方」についてまとめます。
「Issueを見極める」とは何か
無数に存在する問題の中から、解決することで未来が変わる「本質的な課題」を選択して、そこにリソースを集中することです。
そのために意識している軸が5つあります。
-
【構造】 症状ではなく、裏側にある仕組みを捉える
表面上のエラーログを消すのではなく、「なぜそのエラーが起きうる構成になっているのか」というアーキテクチャやコードの構造に目を向けます。
-
【継続性】 一過性のノイズか、未来に続く課題か
たまたま一度起きただけの事象にリソースを割きすぎていないか。今後も繰り返され、積もり積もって大きな損失を生む「継続的な痛み」を優先して解決します。
-
【根本改善】 対症療法を捨て、再発の芽を摘む
再起動して直すのは「運用」ですが、再起動しなくて済む仕組みを作ることが重要です。仕組みそのものをアップデートし、同じ問題が二度と起きない状態を目指します。
-
【価値】 「量の解決」から「価値の創出」へ
解決したタスクの数（量）に満足せず、その改善が「ユーザー体験」や「チームの開発生産性」にどれだけ寄与したか（価値）で、優先順位を判断します。
-
【学習】 仮説検証を回し、小さく進化し続ける
最初から完璧な正解を求めすぎず、最小限のコストで試してフィードバックを得ます。その学びを次の改善に活かす「学習のループ」こそが、不確実な運用現場における正攻法です。
では実際の現場ではどうだったのか
ここまで述べてきた「Issueを見極める」という考え方を、私はコスト削減の取り組みを通じて深く意識するようになりました。 入社当初の私は、「一刻も早く目に見える成果（バリュー）を出さなければならない」という焦りの中にいました。
前職での経験を武器に、EC2やRDSのReserved Instance（RI）適用、未使用リソースの削除、インスタンスサイズの最適化など、 「すぐに実行できて、確実に数字が出る施策」をがむしゃらに積み重ねていたのです。
しかし、改善を続ける中で、ある根源的な疑問が芽生えました。 「この工数をかけた削減は、事業にとって本当に意味があるのだろうか？」
必死に時間を費やして、月に数万円のコストを浮かす。
それ自体は正解に見えますが、SREのリソースをそこに投下し続けることが最適解なのか、疑問を持つようになったのです。
そこで私は、単に「削れる場所」を探すのをやめ、「なぜコストが増え続けているのか」という構造の観察から再スタートしました。
EC2やRDSの最適化で削減できる額は限られています。コスト構造を見直すと、最もインパクトが大きいのはCloudFrontでした。しかも、それは一時的なスパイクではなく、使用量とともに膨らみ続けている傾向がある。アーキテクチャに起因する継続的な課題であることも明らかでした。
こうした観察を経て、次に向き合うべきはCloudFrontだという判断に至りました。
ただし、CloudFrontの構造的な課題に対応するには相応のリソースと時間が必要であり、現時点では一旦中断している状態です。それでも、「どこに本質的な課題があるか」を明確にできたこと自体が、次の優先事項を見極めるうえで確かな前進だったと感じています。
まとめ
今回のコスト削減の取り組みを通して再認識したのは、改善の質を左右するのは「解決したタスクの数」ではなく、「どのIssueを選択したか」であるということです。
入社当初は「とにかくバリューを出す」ことに追われていましたが、立ち止まって構造を見ることで、「次に取り組むべき本質的なIssueを見極められた」ことを実感しました。
「Issueを見極める」という視点を研ぎ澄ませながら、持続可能で信頼性の高いシステムを追求していきたいと思います。
オマケ 未経験からの Kubernetes → EKS 移行
最後に、少しだけ入社直後のエピソードを紹介します。
入社して間もない頃、Kubernetes 上で稼働していたサービスの一部機能をEKSへ移行するタスクに関わる機会がありました。 当時、私はKubernetesの実務経験がなく、Join から1週間ほどで対応する必要があり、正直かなりのプレッシャーを感じていました。
このとき強く感じたのは、ペパボの開発・運用文化の良さです。
新しくJoinしたメンバーであっても、早い段階から実践的なタスクに関わる機会が与えられます。 ただし、決して一人で任されるわけではなく、チーム全体で支えながら進めていく文化があります。
分からない点はメンバーに相談しながら進めることができ、構成や仕組みも実際に触れながら理解を深めていくことができました。 結果として、無事に機能移行を完了することができましたが、それ以上に「チームで進める」という文化のありがたさを強く感じた経験でした。
入社直後からこのような環境で挑戦できることは、とても恵まれていると感じています。
発表資料
本記事の内容は、以下の登壇資料をもとにしています。