コンプライアンスと開発スピードを両立する / スマートバンクSREチームの2025年の振り返り

はじめに

こんにちは、ソフトウェアエンジニアの id:shmokmt です。

本記事は、スマートバンク新春エンジニア駅伝の第八区となっております。

第七区はモバイルアプリエンジニアのYoHaさんによる、「「AIモブプロ」が形を変えてチームに定着するまで」でした。

私の所属しているSRE部ではPCI DSSに準拠するための運用設計やAWSを中心としたクラウドインフラストラクチャの運用に携わっております。

今回は、2025年のSRE部を振り返って、チームの変化や取り組んできたことを一部紹介します。

スマートバンクのエンジニアの業務内容が気になっている方の参考になれば幸いです。

人数の増加

2025年はSRE2名が新たに入社し、SRE部は4名体制となっています。また、コーポレートエンジニアも1名入社したため、これを機にコーポレートエンジニアリング領域のタスクに関してはコーポレートエンジニアに委譲する形となりました。*1

2024年まではスマートバンクには専任のコーポレートエンジニアが存在しておらず、SREがコーポレートエンジニアを兼任している状態でした。そのため、新入社員のPCのキッティングからAmazon Aurora MySQLなどのミドルウェアのアップグレード、オンコール、PCI DSSの審査までの幅広い業務をSRE部の2名でこなしている状態でした。*2

足回りを整える

2025年のSRE部を一言で振り返るならば、「足回りを整える」だったように思います。コーポレートエンジニアリングを兼務していた時期は少人数で幅広い業務内容に対応する必要があったため、運用上改善したいが後回しになってしまっている課題が一定存在しておりました。今回は課題の一例とそれに対するアプローチを紹介します。

Terraformの運用改善

2024年までのTerraformは全てのplan/applyをローカル環境で実施する運用を取っていましたが、以下のような課題が存在しました。
- PRをマージしたが、ローカル環境でのapplyを忘れる。
- PRにplanの結果を貼るのが面倒である。
- ローカル環境でapplyを失敗した場合に都度Revert PRを作成するのが煩わしい。

2025年からはSRE部の人数が4名に増えたため、同じtfstateに対する作業を並列で進めるケースが増えてきました。これにより、上記の課題がより顕著になっていました。

それに対するアプローチとして、チーム内で議論した結果としてAtlantisを採用することとなりました。*3

これにより我々が当初抱えていた課題は解決されました。 DevinやClaude Code Actionも実務で使っているため、軽微な修正である場合はエディタを開かずとも作業が完了するような形になっています。詳細は機会があれば別記事で紹介したいと思います。

PCI DSSの運用におけるNotebookLMの活用

SRE部で担当しているPCI DSSの運用作業はドキュメントの照らし合わせ等の地味な作業が全体の多くを占めます。具体的には、複数のPDFやMarkdownファイルを開きながら、各項目がどのPCI DSS要件に対応し、どの社内規定と紐づいているのかを把握する必要があります。これらを照らし合わせた上で以下のような観点でチーム内でレビューをすることがあります。

網羅性

保護するべき情報資産が漏れることなく定義できているか。
対象者は明確であるか。
情報のライフサイクル全体をカバーしているか（作成・保存・共有・廃棄）

実現可能性

現場で実際に守れるルールか（過度に厳しすぎないか）
抜け道や例外が多すぎて形骸化しないか
必要なツールや環境が整備されているか
コストや業務効率とのバランスが取れているか

このような作業を効率化するためにNotebookLMでPCI DSS用のノートブックを作成しています。AWSが公開しているPCI DSSのコンプライアンスガイドや弊社の準拠報告書（ROC）もソースとして含めているため、以下のような質問も回答可能になりました。NoteBookLMの回答を意思決定の材料とすることでSREが本来注力したい運用設計により集中できるようになってきたと感じています。