こんにちは、ツクリンクでSREエンジニアをやってるida.です。
ツクリンクでは2023年からアドベントカレンダーをやっています。そんな中「今年も実施しようよ！」ということでカレンダーが立ち上がったので、2年連続2回目のトップバッターをやらせていただくことになりました！（昨年のアドベントカレンダーはこちらです。）
ツクリンクのアドベントカレンダーではエンジニアだけでなく、デザイナーやコンテンツ企画運営のメンバーも参加してくれてるので気になるものがあれば全部見ていってください🙇
そして、一発目の記事として何を書こうかと考えてましたが、SREチームの紹介と来年に向けてやっていくことについて書いていこうと思います。
ツクリンクのSREチームについて
ツクリンクではエンジニアリンググループの中にSREチームが存在し、チーム名の通りシステムの信頼性向上を目的として活動しています。
2年前にSREチームを立ち上げてからやってきた内容については以下の記事にまとめていますので、ぜひご覧ください。
上記の記事でも触れていますが、SREチームでは活動を6つの柱（信頼性の維持・インフラ監視、セキュリティ対応、障害対応、コスト最適化、サービス・開発効率化、インフラ開発）に整理し、それぞれにKPIを設定して取り組んでいます。
また、小中規模の組織ではよくある構成かもしれませんが、プラットフォームチームやセキュリティチームの役割も兼任しており、責任範囲としては広い方だと思います。
SRE年間ロードマップを通して年間の目標を作成
SREチームを立ち上げて1年ほどは、タスクが山積みだったこともあり、タスク管理だけを行いながら日々対応していました。しかし、方向性や優先度がチーム内でうまく共有できずいくつかの失敗がありました。
そこで2年目からはSREの年間ロードマップを作成し、やるべきことや方向性を可視化することにしました。これには以下のようなメリットがありました。
- SREチームのタスクを上長や他チームに共有でき、説明のベースにできる
- やるべきことや方向性が明確になり、脱線しにくくなる
- メンバーの目標設定・管理が容易になる
特にチーム開発ではロードマップで全体方針を示すことで全体にやるべきことや方針やスケジュール感を共有でき、円滑に開発を進めることができるようになったと思います。
2026年も上長と相談の上、会社の全体方針とも照らし合わせながらロードマップを作成して来年の目標を定めているところです。
来年の計画を立てるために中長期の計画を立てる
私ごとですが、今年の春にIPAのITストラテジスト試験を受験して合格しました。その勉強を通じて、中長期計画の大切さを実感しました。
これまで1年単位で方針を決めて年間のロードマップを作成してきましたが、いざ年単位で振り返るとまだ方針がブレていたり、優先度が適切でなかったと感じることがありました。これを最小限に抑え、最短で目標を達成するには、3年後、5年後の目標を立てて逆算することが重要だと気づきました。
そのため今回から中長期の計画を立てつつ、そこから逆算して2026年のロードマップを作成していっています。
2026年のSREの目標
さて、本題です。来年やっていきたいことを紹介していこうと思います。
1年間安定稼働
SREチームなので、サービスの信頼性担保は最も重要な使命です。2025年のサービス稼働率は、このままいくと目標としていた99.9%を達成できる見込みです。
来年も引き続き安定稼働に努めていきます。また、後述のタスクを通じて、サービス稼働率以外の指標（レスポンスタイム、MTTR、エラー率など）も高めていく予定です。
インフラのリアーキテクチャ
2025年からいくつか着手していますが、2026年もインフラのリアーキテクチャは継続的に進めていきます。
対象となる部分は、歴史的背景で現在の構成に至っているものや、新しい技術・サービスの登場により効率化できるようになったものなど様々です。それぞれ投資効果を見極めながら、優先度をつけて対応していきます。
全てを書ききることはできませんが、主要な取り組みとして以下を予定しています。
レスポンス改善
プロダクトの成長とデータ量の増加により、レスポンスが遅くなっている部分が存在します。
これまでも継続的に対応してきましたが、Datadogでの監視を通じて指標の悪いリクエストを洗い出し、引き続き改善していきます。特に、ユーザー体験に直結するエンドポイントを優先的に対応する予定です。
DB負荷軽減
現在、DBでアプリケーションの一部のログを保存しているテーブルが存在し、ログの肥大化によりスロークエリの原因になっています。
このようなログデータをAmazon S3などのクラウドストレージへ移行することで、DB負荷を軽減し、サービスの安定性を向上させます。
データ連携基盤の再構築
各クラウド間やSaaSへのデータ連携フローが複数存在しますが、必要になった都度構築されたもので、全体的には最適化されていません。また、プロダクトの成長と比例してデータ量も増加しています。AWS Glueや最新のETLツールなど、データ連携サービスも進化してきているため、現在のニーズに合わせて基盤を再構築していきます。
リアーキテクチャは単純に構成が変わるだけでなく、パフォーマンス、コスト、信頼性、業務効率とあらゆる面でメリットがあります。しっかり優先度を見極めながら対応していきたいと思います。
AI活用によるDX推進
AI時代に乗り遅れることなく、業務効率化をしっかり進めていきます。
開発面では、CursorやGitHub Copilotなどのコーディング支援AIにより、かなり効率化されてきました。しかし、アラート対応をはじめとして、まだマニュアル作業が残っている領域は多く存在します。具体的には以下のような領域でAI活用を検討しています。
運用業務の自動化・効率化
- アラート初動対応の自動化: 過去のアラート対応履歴を学習させ、一次対応を自動化
- ログ分析の効率化: ログからAIが異常パターンを検出し、根本原因の特定を支援
- 社内問い合わせ対応: 社内から各事業部の問い合わせに、AIチャットボットが対応
プロダクトへのAI適用
業務効率化だけでなく、プロダクトへのAI適用についても検討・提案していきます。ユーザー体験の向上につながる機能を、開発チームと協力しながら実現していきたいと考えています。
その他検討したいこと
以下の項目は来年実施できるかは不明ですが、しっかり検討を進めていきたいと考えています。
ネームバリューや流行に飛びつくのではなく、意図を理解し、組織の現状を踏まえた上でベストな対応を検討していきます。
SRE文化のイネーブリング
SREチームだけでなく、開発チーム全体でSREの考え方を共有し、組織全体でサービスの信頼性向上に取り組む文化を作りたいと考えています。
現在はSREチームがハンドリングしている領域が多いですが、開発チーム内で完結できた方が全方面にメリットが大きい項目も存在します。
イネーブリングのメリット・デメリットをしっかり検証しつつ、効果があるものは取り入れて、組織全体で信頼性の高いサービスを作り上げる文化を醸成していきます。
AWS ファンデーショナルテクニカルレビュー（FTR）
ツクリンクは今年からAWSパートナーネットワーク（ソフトウェアパス）に加入しました。ソフトウェアパスでは、AWS ファンデーショナルテクニカルレビュー（FTR）に通過することでAWS認定ソフトウェアとなることができます。
FTRとは、AWSのベストプラクティスに沿って構築・運用できているか、AWSの専門家にレビューしてもらうプログラムです。
認定によるベネフィットもありますが、何よりも堅牢な構成にアップデートできることが最大のメリットだと考えています。昨今のセキュリティ脅威から守り、障害時の迅速な対応を実現するためにも、意義のある取り組みです。
現在もこれらの対応は行っていますが、ベストプラクティスと照らし合わせて再度見直しを行い、サービスの可用性を継続的に向上させていきます。
おわりに
今回は2026年に向けたSREチームの計画について書いてきました。
中長期の視点を持つことで、日々の業務がどのような目標につながっているのかを明確にし、チーム全体で同じ方向を向いて進んでいけるようにしたいと考えています。
2025年はSREチームの最大の目標であるサービス稼働率99.9% という目標を達成できる見込みです。来年はさらに一歩進んでよりプロダクトのグロースに貢献できればと思います。
また、技術的な取り組みだけでなく、組織全体でサービスの信頼性を高めていく文化作りにも注力していく予定です。
Discussion