非エンジニアによるDevin開発のためにSREができること

Transcript

1. 2025/9/18 #第3木曜LT会 非エンジニアによる Devin開発のために SREとしてできること 株式会社スマートラウンド 山原 崇史(@shonansurvivors)
2. 自己紹介 株式会社スマートラウンド 執行役員VP of Reliability 山原 崇史 (やまはら たかし)　 経歴等 ・金融系SIer → 銀行 → ベンチャー数社 → 現職 ・SRE / コーポレートIT / セキュリティの領域を担当 ・2023〜2025 Japan AWS Top Engineers 社外コミュニティ活動 ・AWS Startup Community (aws-startup-community.connpass.com) ・Security Compliance Lounge (security-compliance.connpass.com) @shonansurvivors
3. 会社および事業紹介 株式会社スマートラウンド 　2018年設立、従業員数約 45名のスタートアップ ミッション 　スタートアップが可能性を最大限に発揮できる世界をつくる プロダクト 　スタートアップ・投資家間のデータ作成・共有プラットフォーム 　　スタートアップ導入数 7,000社 　　投資家導入数 4,300人 さらなる取り組み（子会社にて） 　未上場株式のセカンダリープラットフォーム実現に向けて準備中
4. セキュリティへの取り組み SOC2 Type2報告書 米国公認会計士協会（ AICPA）の定めるトラストサービス規準に基づき、セキュリティ・可用性・処理の完 全性・機密保持・プライバシーに関する内部統制の適切性および有効性を監査法人が作成した報告書 にてご確認いただけます。 ISO/IEC 27001（ISMS認証） 情報セキュリティマネジメントシステムに関する国際標準規格である ISO/IEC 27001(ISMS)の認証を取 得しています。ISMS委員会やマネジメント（経営層）レビュー、内部監査等を定期的に実施し、情報セ キュリティの向上に組織全体で取り組んでいます。 AWS認定ソフトウェア AWSのパートナーソリューションアーキテクトによるレビュー（ FTR）を通過し、セキュリティ・信頼性・運用 上の優秀性に関して AWSのベストプラクティスに従っていることが確認された AWS認定ソフトウェアと なっています。
5. 本日共有したいこと 前提 • SREやPlatform Engineerは、エンジニアの開発体験や速度を向上させるための 各種Platformを提供 環境の変化 • AIの進化により非エンジニアも開発に参画可能に 得られた気付き • Platformを構築しておくと、非エンジニアもその恩恵を受けられる 可能性あり • 今後は、非エンジニアに利用されることも考慮した Platform整備が求められていく
6. アジェンダ 1. プロダクト小規模改修の事例 2. Terraformコード修正の事例 3. まとめ
7. 1. プロダクト小規模改修の事例
8. AIを用いたプロダクト開発/運用の状況 スマートラウンドでは ... • エンジニア ◦ 多種多様なサービスを状況に応じて使い分け ▪ Claude Code ▪ JetBrains AI ▪ OpenAI Codex ▪ Cursor ▪ Devin 等 • 非エンジニア ◦ Devinの利用が広がりつつある
9. 非エンジニアによるDevinのユースケース • 既存プロダクトの現行仕様調査 ◦ カスタマーサポート等が、エンジニアに質問する代わりに、 Devinに質問する ◦ PRは作成しない • 既存プロダクトの小規模改修 ◦ カスタマーサポート等が、顧客要望などをもとに Issueを起票 ◦ このIssueをもとに、カスタマーサポート等が自ら Devinに実装を指示 ◦ エンジニアのコードレビュー後、問題なければマージ
10. 非エンジニアによる開発時に生じた課題 • ローカル環境での動作確認のハードルが高い
11. スマートラウンドでの標準的な開発フロー 1. Mac上でコードを修正して、 GitHubにPRを作成 2. 以下を並行して実施 ◦ GitHub ActionsでCI実行 ◦ Mac上のローカル環境で動作確認 👉ローカル環境とAWS検証環境の差異は少なく、ローカル環境で大部分の品質は担保可能 3. コードレビューを他のエンジニアに依頼 4. PRをマージし、AWSの検証環境にデプロイ 5. QA実施後、AWSの本番環境にデプロイ
12. 非エンジニアによるプロダクト改修時の課題 • 非エンジニアにはローカル環境での動作確認のハードルが高い ◦ 初回の環境構築 ◦ 環境構築後のトラブルシューティング ◦ 各種の知識がある程度求められる ▪ Git, Docker, asdf, Yarn, Gradle, sh, etc… （他、非エンジニアの PCもMacだがAirなので、エンジニアの Proと比べると非力という課題もあり）
13. smartroundでの標準的な開発フロー（再掲） 1. Mac上でコードを修正して、 GitHubにPRを作成 2. 以下を並行して実施 ◦ GitHub ActionsでCI実行 ◦ Mac上のローカル環境で動作確認 👉ローカル環境とAWS検証環境の差異は少なく、ローカル環境で大部分の品質は担保可能 3. コードレビューを他のエンジニアに依頼 4. PRをマージし、AWSの検証環境にデプロイ 5. QA実施後、AWSの本番環境にデプロイ ローカルを使わずに済む方法に 置き換える
14. PR環境の利用 GitHubのPR単位で検証環境をAWSに構築・デプロイする仕組み。 非エンジニアによるDevin開発が始まる以前から、 SREがPlatformとして構築し、 エンジニアに提供していた。 今回、ローカル環境の代わりに非エンジニアに利用 してもらうことにした。
15. PR環境の構成 • GitHubのPRにコメントするとGitHub Actionsで環境構築（Terraform & ecspresso） • ALBのリスナールールでターゲットの ECSを振り分け
16. 非エンジニアの開発体験や開発速度は向上したか？ 狙い通りにうまくいったこと • 非エンジニアがローカル環境構築をキャッチアップする必要が無くなった ◦ 付随して、エンジニアによるサポートも不要となった 見通しが甘かったこと • 現状のPR環境の仕組み自体が Platformとして未成熟 ◦ 多数のPR環境が作成された場合に、共有のインフラリソースがキャパシティ不足になる ◦ UXが高くなく、非エンジニアにとってはわかりにくい、使いづらい点があった • 種々のトラブルへの対応のため SREのToilが増えてしまった 👉ただし、今回順次根本改善を行なったことで、 Platformとしてより良いものになった
17. 2. Terraformコード修正の事例
18. SREとコーポレートITの体制 • スマートラウンドでは 1チームで運営 ◦ 「SRE兼コーポレートIT」複数名と、「コーポレート IT専任者」から成るチーム
19. IaCの現状 • 現状 ◦ Terraformで管理 ◦ Terraformコード修正はSREで実施（planやapplyは原則としてAtlantisを利用）
20. Atlantis • PRへのプッシュやコメントをトリガーに terraform planを実行 • レビューapprove後はPRにコメントしてterraform apply、成功を確認したらマージ
21. IaCの現状（再掲）と今後 • 現状（再掲） ◦ Terraformで管理 ◦ Terraformコード修正はSREで実施（planやapplyは原則としてAtlantisを利用） • 今後 ◦ コーポレートIT専任者もTerraformを覚え、コードでのインフラ変更を行えるようにしたい そのために... • Terraformコード修正は、Devinを利用 • Terraformのplanやapplyは、Atlantis（だけ）を利用 結果、ローカルへのコードチェックアウトや Terraformインストールの作業をスキップ可能となり、 コーポレートIT専任者は迅速にIaCを体験・習熟開始可能に
22. 3. まとめ
23. まとめ • AIの進化により非エンジニアも開発に参画可能 に • SREやPlatform Engineerが用意する各種Platformは、非エンジニアの開発効率にも寄与 • 適切なPlatformを構築し、より使いやすいものへと磨き込むことは、今後ますます重要に
24. JOIN US! jobs.smartround.com