2025年4月からCOTENでエンジニアをしている秋山です。社内ではYと呼ばれています。
Vibe Codingの普及により「全員開発者」という構想を目にする機会が増えました。エンジニア以外の職種にも実装業務を担ってもらい、開発効率を高める試みです。COTENでもこの取り組みを検証しているので、得られた知見をまとめます。
結論：プロトタイプを実装してもらう
私たちのチームでは、非エンジニアであってもClaude Codeを用い、既存コードベース上に新機能をプロトタイプとして実装しています。
当初は非エンジニアにPull Requestまで作成してもらい、エンジニアがレビューする開発サイクルも構想しました。しかしコード品質の悪化やレビューコストを懸念し、現状のLLMの性能では開発効率に寄与しにくいと判断しました。
図1. 技術的負債と開発効率（引用：『ソフトウェアアーキテクチャメトリクス』／赤枠・青枠は筆者加筆）
前提として、実装はアーキテクチャ改善とセットで行われるべきと考えています。小さな機能でも実装すればシステムの複雑性が上がり、保守コスト——すなわち技術的負債——は増えます。したがって、システムは継続的な改善によって技術的負債をコントロールする必要があります。
図1は、変更の度に増加する負債に対し、アーキテクチャ改善で保守コストを低く抑え続ける必要を示しています。
まとめると、下記の２点はエンジニアリング経験を要し、現段階のLLMでは代替しにくいため、非エンジニアがプロダクトコードへ直接コミットする運用は断念しました。
(1) 保守コストを最小化する実装（図1の赤枠）
(2) アーキテクチャ改善の是非判断（図1の青枠）
非エンジニアも既存コードベースは変更しますが、担うのはあくまでプロトタイプ実装までです。プロトタイプでユーザー価値を確認できた場合、エンジニアが本実装として組み込みます。
以下、非エンジニアによるプロトタイプ実装を成立させるための環境整備について述べます。
(1) 開発環境をローカルで完結させる
現行コードベースはプロトタイプ用途の歴史もあり、ローカル環境から各種クラウドサービスへアクセスできました。しかし作業の競合防止やセキュリティの観点から、開発環境はローカルで完結させておく必要があります。
ローカルからクラウドにアクセスできる状態だと、Claude Codeの操作経由でクラウド上のデータ削除・設定変更が起きたり、APIキー流出などのリスクがあります。
そのため、Dockerコンテナやモックを活用し、ローカルのみで開発が完結する構成へ移行しています。
(2) デザインシステムを導入する
スタイルはTailwind CSSを採用していますが、Tailwind CSSをベースにしたコンポーネントライブラリであるDaisyUIを導入中です。理由は次の３点です。
- コード行数を圧縮できる
- 採用実績が多く、Claude Codeの出力品質が安定しやすい
- トンマナを揃えやすく、ユーザーテスト時の違和感が小さい
一方で次の課題があります。
- 生のTailwindクラスとDaisyUIクラスが混在しうる
- 色味や余白などの細部が依然としてばらつきやすい
対応として、DaisyUIを薄くラップしたコンポーネント集を用意し、原則その組み合わせだけでUIを構築するルールを整備予定です。
(3) モジュラモノリスを導入する
モジュラモノリスは、１つのシステムを機能単位のモジュールの組み合わせで構成するアーキテクチャです。多くのモノリシックなシステムは何らかのレイヤードアーキテクチャを採用しています。レイヤードアーキテクチャとは、インフラ層やビュー層など技術的関心によってシステムを分割する手法を指します（図2）。
図2. 典型的なレイヤードアーキテクチャの模式図
MVCやクリーンアーキテクチャに代表されるレイヤードアーキテクチャが、システムをレイヤー別に水平分割する手法だとすれば、モジュラモノリスはシステムを機能別に垂直分割する手法といえます。
例えばユーザー管理と通知の２機能があるなら、ユーザーモジュールと通知モジュールを作り、モジュール間は疎結合にします。これによりシステムの複雑性を抑制できます(図3)。
図3. モジュラーモノリスアーキテクチャの模式図
このモジュラモノリスによってClaude Codeの探索範囲を狭めることができます。例えば次のような構成にします。
📁 modules/
┣ 📁 user/
┃ ┣ 📝 index.ts
┃ ┗ 📁 internal/
┗ 📁 notification/
┣ 📝 index.ts
┗ 📁 internal/
各モジュールが提供する機能は直下の index.ts に定義します。さらに内部実装である internal/の参照は .claude/settings.json の permissions.deny などで禁じることで、Claude Codeは index.ts だけを読んでくれます。
これによりプロトタイプ実装の効率が上がり、コードの見通しも良くなります。本実装時にも意図と差分を素早く把握できます。
※モジュラモノリスについては下記の拙記事で詳説しています。
(4) 任意ブランチからプレビュー環境を自動起動する
リモートブランチから自動でプレビュー環境が立ち上がると、エンジニアが介在せずにユーザーテストまで到達できます。私たちのチームでも、PdMがClaude Codeで一定規模の機能をプロトタイプ実装し、社内のユーザーに触ってもらえる状態になっています。
プラットフォームはVercelを利用しているため、ブランチごとの環境立ち上げは自動で行われます。
一点、データベースと外部ストレージはプレビュー環境間で共有しているため、プロトタイプで永続層が必要な場合は、共有のKey-Valueストアに保存する運用にしています。
(5) デプロイ容易性でレポジトリを分ける
近年、モノレポへの移行がトレンドでしたが、Vibe Codingの浸透により、LLMの探索範囲を狭めやすいマルチレポジトリを選ぶ動きも見られます。
どちらが良いかは一概には言えませんが、私たちは「デプロイ容易性」を主要指標としています。理想は、エンジニアが介在せず、非エンジニアが実装からユーザーテストまでを進められる環境です。その実現を阻害しがちなのがデプロイ工程です。
マルチレポジトリはLLMの探索範囲を狭めやすい一方、レポジトリ横断の変更でデプロイ難易度が上がるリスクがあります。例えばフロントとバックエンドのレポジトリを分けると２回のデプロイが必要になり、結局エンジニアがユーザーテストのパイプラインに介在してしまい、開発サイクルが減速しかねません。
「LLMの探索範囲をどこまで狭めるか」「デプロイ対象を可能な限り１つに保つ」はしばしばトレードオフです。このバランスを見てレポジトリを分割するよう留意しています。
まとめ
プロトタイプ実装からユーザーテストまで、エンジニア不在でも回る環境づくりを紹介しました。振り返ると、これらはエンジニアがVibe Codingする上でも有効です。
各取り組みを抽象化すると、目的は次の２つに集約されます。
- LLMの探索範囲を狭め、実装スピードを上げる…(1)(2)(3)
- エンジニア不在でも一定規模の機能変更をデプロイ可能にする…(4)(5)
今後もCOTENでは人文知を社会実装できるよう、開発効率の改善を進めていきます。
Discussion