"That's not SoC 2 compliant"
日本語訳
# 「それはSOC 2に準拠していません」
私たちはこれまで、自分たちの働き方について多くのことを共有してきました。「AmpでAmpを作る」こと、orbs、機能の廃止、そしてプルリクエスト（PR）を使わないこと。そして、最も多い反応は、AIのワークフローや、その時々の流行りのループグラフ・エンジニアリングについてではありません。それは、次のようなものです。
「えっ、プルリクエストを使わないんですか？ mainに直接プッシュするんですか？ どうやって？ それではSOC 2に準拠していませんよ」
実は、準拠しています。
プルリクエストをスキップすることは、最初のコミットから意図的な選択でした。それは私たちの開発手法の大きな部分を占めており、継続的にリリースできる理由でもあります。
そのため、SOC 2の取得に向けて動き出したとき、私たちはその疑問をそのまま監査人にぶつけました。「それにはPRが必要ですよね……？」と。
SOC 2はプルリクエストを要求していません。要求しているのは、リスクについて検討することです。
これが、私たちが得た本当の答えです。監査人、そしてSOC 2そのものは、想像以上に柔軟です。私たちの監査人はPRを求めたのではなく、私たちの変更プロセスがどうなっているかを尋ね、それに適合する一連のコントロール（管理策）を一緒に構築してくれました。
Trust Services Criteria（信頼サービス基準）には、gitやプルリクエストについての記述は一切ありません。求められているのは、変更が「承認され、テストされ、許可され、記録されている」ことです。プルリクエストは、それを実現するための一つの手段に過ぎません。
私たちが最終的に採用したコントロールは以下の通りです：
* **mainはビジネス機能に従う**: Ampのエンジニアは誰でもプッシュできます。そして、Ampのほとんどはエンジニアです。しかし、アクセス権を持つ人の割合よりも、誰がなぜその権限を持っているのかを正確に説明できることの方が重要です。
* **すべてのコミットの作成者が検証可能である**: これにより、mainへの変更の責任の所在が明確になります。
これらは決して特殊なことではありません。しかし、単に工程を一つ削っただけの標準的なプロセスとも違います。これは意図的に設計されたシステムであり、監査人に対してPRワークフローと同じものを提供しています。
そして、いいえ、コードレビューもリストには入っていません。基準には「二人目の人間がdiff（差分）を凝視しなければならない」とは書かれていません。
私たちは20人規模で、そのほとんどがエンジニアであり、全員がコードに近い場所にいます。小規模で高い信頼関係があることは私たちの強みであり、不要なプロセスのためにそれを手放すつもりはありません。コードを書くスピードが速いとき、遅いプロセスこそが実際の待ち時間になってしまいます。もっとも、2,000人規模の企業が全員にmainへのプッシュを許可すべきだとは言いません。
規模が拡大したときに考えるべきは、リスクについて考えることです。なぜなら、リスクは企業内であっても一様ではないからです。Ampは顧客向けのプロダクション・ソフトウェアであり、私たちはこの方法でリリースしています。一方で、大企業における多くのコードはそれよりもリスクが低いにもかかわらず、すべての変更が、その企業が運用する最も恐ろしいシステムに合わせて調整された、全く同じプロセスを経ています。
そして、それを解決するために会社全体を刷新する必要はありません。一つのシステムを選び、こう問いかけてみてください。「ここでプルリクエストが実際に管理しているリスクは何だろうか？」次に、それらを管理する他の方法はないだろうかと考えてみてください。
その答えは、必ずしもプルリクエストである必要はないのです。
原文（英語）を表示
We’ve been sharing more about how we work: building Amp with Amp, orbs, killing features, no pull requests. And the most common reaction isn’t about the AI workflows or whatever kind of loop graph engineering is flavor of the week. It’s this:
Wait, you don’t use pull requests? You push to main? How? That’s not SOC 2 compliant.
Except it is.
Skipping pull requests was a deliberate choice from the first commit. It’s a big part of how we build and why we can ship continuously.
So when we started working toward SOC 2, we took that question straight to our auditors: “you need PRs for that… right?”
SOC 2 doesn’t require pull requests. It requires that you think about your risks.
That’s the real answer we came away with. Auditors, and SOC 2 itself, are more flexible than you might assume. Ours didn’t ask us for pull requests; they asked what our change process was, and worked with us on a set of controls that fit it.
The Trust Services Criteria never mention git
or pull requests. What they ask for is that changes are authorized, tested, approved, and recorded — and pull requests are just one way of doing that.
Here are the controls we landed on:
main
follows business function: every engineer at Amp can push, and most of Amp is engineers. But the percentage of people with access matters less than being able to explain exactly who has it and why.main
, which makes the author on every commit verifiable.main
.None of this is exotic. But it isn’t the standard process with a step deleted, either. It’s a system designed on purpose, and it gives an auditor the same thing a PR workflow gives them.
And no, code review isn’t on the list. The criteria don’t say a second human has to stare at a diff.
We’re 20 people, mostly engineers, and everyone is close to the code. Being small and high-trust is our advantage, and we aren’t going to give it away for a process we don’t need. When writing code is fast, slow process becomes what you’re actually waiting on. But we’re not going to pretend a 2,000-person company should let everyone push to main.
What does scale is think about your risks, because risk isn’t uniform inside a company either. Amp is customer-facing production software, and we ship it this way. Meanwhile, plenty of code at bigger companies carries less risk than that, yet every change goes through the same process, calibrated to the scariest system the company runs.
And you don’t have to overhaul the whole company to fix that. Pick one system and ask: “What risks are our pull requests actually managing here?” Then ask how else you could manage them.
The answer doesn’t have to be pull requests.