2つのドア、1つのゲート：EDDを超えたガバナンス
オンボーディングのルールと開発者の摩擦は、しばしば同じ問題のように見えます。しかし、実際には異なります。
開発者が40人にまで増えると、全員に同じトレーニング方法を適用することはできません。AIエージェントに精通したエキスパートもいれば、初心者もいます。全員に対して一律のルールを適用しようとすれば、失敗します。
経験豊富な開発者はルールを無視し、初心者はルールに苦戦することになります。
アプローチを、以下の2つの明確なレイヤーに分ける必要があります：
意識化ツール（Awareness tools） これらのツールは、人が「知っていること」を変えるものです。例として、AIによるレビューコメントやリンティングの警告が挙げられます。これらは受付係のような役割を果たします。何かに気づき、アクションを提案しますが、本人が聞き入れない限り機能しません。
ガバナンスツール（Governance tools） これらのツールは、人が「できること」を変えるものです。例として、ブランチ保護やマージゲートが挙げられます。これらは回転ゲート（turnstile）のような役割を果たします。交渉の余地はなく、要件が満たされない場合はプロセスを停止させます。
間違いは、回転ゲートが必要な場面で受付係を使ってしまうことです。開発者が無視するAIの提案は、ガバナンスではありません。それは単なるノイズです。
これを解決するには、2つの異なるレイヤーを使用してください：
ガバナンス・レイヤー（The Governance Layer） このレイヤーは小規模かつ普遍的です。スキルに関わらず全員に適用されます。保護されたブランチへの直接プッシュの禁止や、必須レビューなどのルールが含まれます。これは信頼の問題ではなく、エージェント主導の変更に伴う高いリスクからコードベースを保護するためのものです。
スキャフォールディング・レイヤー（The Scaffolding Layer） このレイヤーは個人的かつ柔軟です。明示的なプランニングや詳細な推論といったステップが含まれます。初心者は判断力を養うためにこれを多用します。経験豊富な開発者は、成長に合わせてこれを軽減できます。これは年功序列への報酬ではなく、スキルが上がるにつれて不要になるツールなのです。
また、変更そのもののリスクにも目を向けるべきです。シニア開発者が複雑で密結合なファイルに触れることは、ジュニア開発者が単純なユーティリティ関数に触れることよりも大きなリスクを生みます。システムは、単に「誰が」ではなく、「どのコードに」基づいて反応すべきです。
最後に、オーナーシップ（所有権）に焦点を当ててください。AIエージェントがコードを書いたとしても、その結果に責任を持つのは開発者です。レビュー中に、なぜその変更が行われたのかを開発者が説明できない場合、その変更をマージすべきではありません。
人を階層でラベル付けするのはやめましょう。代わりに、各自が自分のリスクを管理できるようなツールを提供してください。
Source: https://dev.to/karlheinz_reichel_7ee08d/two-doors-one-gate-navigating-governance-beyond-edd-5clj
Optional learning community: https://t.me/GyaanSetuAi