ワークフローの罠：スキャフォールディングが「静的な場」になるとき
SchemaBridge Team · 2026-03-12 · DevEx, Product Management, Architecture
開発ワークフローとプロダクトの速度の微妙なバランス。自動化が乗数になるときと、税金になるときを見極めます。
現代のエンジニアリングの世界では、誰もが「エージェント型ワークフロー」と開発者の生産性に夢中です。私たちは単調な作業を自動化し、複雑なものに骨組みを与え、アーキテクチャを強制するためのツールを作ります。しかし、この自動化には影の側面があります。私たちを速くするはずのガードレールそのものが、速度を止めてしまう地点があるのです。これがワークフローの罠です。
ここでは、エンジニアリングの一貫性とプロダクトの速度をめぐる議論と、自動化の「ゴルディロックス・ゾーン」をどう見つけるかを見ていきます。
🛠 DevEx の視点：正気を保つためのガードレール
DevEx の観点から見ると、ワークフローは卓越性のスケーリングのためのものです。厳格なアーキテクチャパターン（Clean Architecture など）に従うプロジェクトでは、「このコードはどこに置くべきか」という認知負荷が大きくなりがちです。
私たち自身の create_api_feature ワークフローを例に取りましょう。これは、エンジニア（または AI エージェント）が API 機能を追加する手順を一歩ずつ案内するチェックリストです。それ自体がコードを生成するわけではなく、分離の哲学を徹底させます。
1. ドメイン層が先：データベースのコードに一行でも触れる前に、ビジネスエンティティとリポジトリインターフェースを定義します。
2. 層の分離：次に Application 層を置き、コンストラクタインジェクションで配線することで、インフラの詳細が純粋なビジネスロジックに漏れ出さないようにします。
3. 品質の組み込み：各層のテストをどこに置くかを明示するため、テストは後付けではなく、最初のステップから機能の一部になります。
私たちにとって、適切に配置されたワークフローは「Pit of Success（成功の落とし穴）」です。正しいアーキテクチャ上の選択を、最も簡単な選択にしたいのです。こうしたガードレールがなければ、プロジェクトはすぐに「Big Ball of Mud（巨大な泥団子）」へと堕落し、どの機能も一点ものになり、安定して出荷できるのは技術的負債だけ、という状態になります。
📈 PM の視点：「機能税」という現実
今度はプロダクトマネージャーの立場に立ってみましょう。PM にとって最も重要な指標は提供した価値です。市場機会やユーザーの課題を見つけたら、素早く反復したいと考えます。
PM にとって、硬直したワークフローは「機能税」のように感じられることがあります。
ユーザーがダッシュボードに単純なフラグを一つ追加したいだけなのに、その「単純なフラグ」のために 4 つのアーキテクチャ層に手を入れ、リポジトリインターフェースを更新し、モックを再生成しなければならない――それも「それがワークフローだから」という理由だけで――となれば、PM は厳しい問いを投げかけ始めます。
- 「5 分で済む UI の変更に、なぜ 4 時間ものバックエンドのスキャフォールディングが必要なのか？」
- 「私たちは顧客からのフィードバックを犠牲にしてアーキテクチャの純粋さを最適化していないか？」
「ワークフローが多すぎる」ことの危険は、好奇心を殺してしまうことです。実験へのハードルが高すぎると、エンジニアは小さな改善を提案しなくなります。プロセス負債の支払いが重すぎると分かっているからです。
⚖️ 「ゴルディロックス・ゾーン」のヒューリスティクス
では、ワークフローが勝ちになるのはいつで、重荷になるのはいつでしょうか。私たちは、いつ自動化し、いつ一歩引くかを判断するために、いくつかの単純なヒューリスティクスを使っています。
1. 頻度テスト
月に一度しか発生しないタスク（例：SSL 証明書のローテーション）なら、文書化されたチェックリストで十分です。1 日に 10 回発生するタスク（例：コンポーネントの作成）なら、単一のコマンドになるまで自動化しましょう。
2. リスクプロファイル
デプロイ基盤やセキュリティプロトコルのような高リスク領域には、厳格なガードレールが必要です。社内の CSS ユーティリティや実験的な UI コンポーネントのような低リスク領域は、できる限り摩擦を少なくすべきです。
3. 「Break Glass（緊急時のガラス割り）」オプション
優れたワークフローには必ず非常口が必要です。エンジニアが手早い実験のためにある層を迂回する必要があるなら、システムは道を完全にふさぐのではなく、（警告付きで）それを許可すべきです。
比較：ワークフロー vs. 素のスピード
| 属性 | 厳格なワークフロー | 高い柔軟性（素のスピード） |
| :--- | :--- | :--- |
| アーキテクチャのドリフト | 低い | 高リスク |
| オンボーディング時間 | 速い（スクリプトに従う） | 遅い（「空気感」を学ぶ） |
| イノベーションの速度 | 線形 | 指数関数的（ただし雑然） |
| エラー率 | 低い（ガードレール） | ばらつきあり |
🚀 結論：神経系としてのソフトウェア
ワークフローは乗数であるべきで、除数であってはなりません。私たちは、自動化が開発者の役に立ちつつプロダクトを窒息させないよう、常に調整を続けています。優れた開発者体験とは、あらゆる摩擦を取り除くことではありません。実際に遭遇する摩擦が、単なる官僚主義ではなく、意味があり、守ってくれるものであるようにすることです。
DevEx と速度のバランスについてもっと知りたいですか？ 私たちのエンジニアリングブログで議論に参加するか、フォローして現代のエンジニアリング手法に関するさらなる知見をお受け取りください。
関連記事：オブザーバビリティ・ギャップ：断片化したログの先へ。ログがシステムの健全性についてあなたを誤解させうる理由について。