少人数の新規チームでAI駆動開発を1ヶ月半実践してみた

こんにちは。Gaudiyでバックエンドエンジニアをしているryio1010です。

突然ですが、皆さんの開発チームは何人構成でしょうか？

私の所属する新たに新設されたチームは、PdM、デザイナーが0.5人(他PJと兼務)、エンジニアがフロントエンドとバックエンド各1人です。

Gaudiyの他の開発チームはPdMとデザイナーそれぞれ1人、エンジニアが4-5人ほどのチームが多いので、従来よりも少ないチーム構成となっています。

詳細は後述しますが、そんな構成のチームの中で私たちに与えられたミッションは、「AIをフル活用して、他チームと同等のパフォーマンスを出す」というものでした。

従来のやり方にとらわれない自由な開発が許されている環境で、ここ1ヶ月半ほどAI駆動開発に本格的に取り組んできました。

この記事ではこのミッションのもと「AI駆動開発」に取り組んでみて得た学びや、実践と試行錯誤の過程をお届けします。

1. なぜAI駆動開発を始めたのか

チームが発足した当初、Dev代表からこんなミッションをもらいました。

デリバリーする機能の開発が最優先だが、それを担保した上でAIをフル活用して従来のやり方にとらわれない自由な開発の仕方を模索してほしい。 AIをチームでどう活用できるかを考えてほしい。

エンジニア一人当たり4万円/月まで会社負担でAIツールを自由に利用できる福利厚生も整備されてきており、これまでももちろんエンジニアは個人としてAIツールを開発に取り入れていましたが、改めてチームとしてAIを利用した上での開発フローの確立をしたいという意図がありました。

フロントエンド・バックエンドエンジニア各1名という構成で、AIツールの活用を前提としたチーム作りは、ある程度チームとして戦略立ててAIを使っていかなければ個人で使用していた以上の成果を出すことは難しいだろうと考えていました。

そこでまず、チームとして使うAIツールの選定から始めることにしました。

2. チームとして実践したこと

実践内容	詳細
AIツールの統一	• ナレッジの共有や蓄積のしやすさを重視 • その他のツールは各自の責任で自由に利用可能
MCPサーバーの活用	• filesystem MCPで別リポジトリを参照 • 社内Go共通実装リポジトリのMCPを活用 • その他MCPの活用
AI Daily Sync	• 毎朝5〜10分のカジュアルな情報交換 • フロントエンド・バックエンドの異なるアプローチを共有

チームとして取り組むという観点から話し合った結果、ナレッジの共有や蓄積のしやすさ考えてメインで使うツールはなるべく統一したほうがよいだろう、という結論になりました。

CursorやChatGPTなどいくつかのツールを試していたとき、ちょうどClaude Codeがサブスクプランで使えるようになり、世間的に盛り上がりを見せていたタイミングでした。

そこで私たちのチームは Claude (Code/Desktop) をメインとし、設計の壁打ち相手やClaude以外の視点を入れる目的として Gemini を併用するスタイルに落ち着きました。それ以外のAIツールについてはセキュリティーなどは考慮しつつも各自の責任で好きなものを開発に利用することとしました。

また、MCPサーバーも積極的に活用しました。filesystem MCPで別リポジトリを参照できるようにしたり、別チームが開発を進めていた社内のGo共通実装リポジトリの MCPなども活用し、開発を進めていきました。

そしてツール以上に効果的だったのが、毎日実践した「AI Daily Sync」です。これは朝会の前にほんの5〜10分、AIについてカジュアルに情報交換する時間です。

「昨日Gemini CLIを試したら、結構良くて…」 「CLAUDE.mdの管理、どうしてる？」

フロントエンドとバックエンドの開発の取り組みについては後述しますが、両者では使うツールも違えば、AIへのアプローチも細かい部分では異なっていました。だからこそ短い時間でのsync会が、次の取り組みへのヒントになることも多くありました。実際にCLAUDE.mdの管理方法やdocsディレクトリの構成の再検討などを実践する機会となりました。

何より「それいいね！他のrepoでも試してみよう」と、互いの知見を取り入れることでAI活用の知見をチームとして高められた点が特に良かったと感じています。

また毎日話す機会を作ることで、各人が自然とAIについて調査する時間を意識的にとるようにもなっていました。この取り組みは今でも続けています。

Syncの内容をSlackでシェアしてる様子

3. ドキュメント駆動開発を軸にする

AI駆動開発を進めていく中で、どのAIツールを使う上でも共通していることがあると感じていました。

「AIのパフォーマンスは、インプットされるコンテキストの質で決まる」

AIに質の高い仕事やアウトプットをしてもらうには、私たちが質の高い情報、すなわち「ドキュメント」をコンテキストとして整備して与えてあげることが不可欠だと感じています。ドキュメントがない場合とのアウトプットの質にかなり差があることはこれまでのAIを活用した開発でも感じていた部分でした。

実践を通して私たちは以下の理由からAIと協働する時にはドキュメント駆動開発を導入した方が良いと考えるようになりました。

3-1. 共通認識としてのドキュメント

開発において最もコストがかかるのは、後から発覚する仕様の認識齟齬による手戻りだと感じています。ドキュメントを起点に開発を進めることで、そのドキュメントをもとに仕様の確認ができるため認識齟齬を減らすことができています。

何を作るべきか、なぜ作るのかが明文化されるため、開発者間はもちろんAIとの間でも認識がズレるリスクを大幅に低減できました。また実装の前にドキュメントのレビューを行うことで、各人が共通認識を持った上で適切なコンテキストのもとでAI開発を行うための土台になっています。

実際のドキュメントの一例

├── docs
│   ├── 01-requirements　★要件定義書など
│   ├── 02-architecture　★ドメイン設計・データ設計など
│   ├── 03-api-reference　★各RPCの仕様書
│   ├── 04-development　★開発ガイドラインなど
│   ├── 05-decisions　★ADR

3-2. 「とりあえず実装」からの脱却

ドキュメントを作成する過程は、要件や設計の曖昧な点を強制的に洗い出すプロセスでもありました。

「とりあえず実装しながら考えよう」という進め方では見落としがちなエッジケースや考慮すべき点を事前に特定できるため、結果的により具体的なプロンプトをAIに与えることができるようになり、AIが生成するコードの質を向上させることができたと感じています。

3-3. チームの生産性向上

AIのために整備を進めたドキュメントはAIだけのものではなく、むしろチームにとっての資産になります。

新しいメンバーが参加した際、コードを隅々まで読まなくてもドキュメントを読めばプロジェクトの全体像や過去の意思決定（なぜこの技術を採用したのか等）をキャッチアップできます。

そして何より「AIに正確に指示を出すため」という明確な目的が、これまで後回しにされがちだったドキュメント作成のモチベーションになっていると感じています。

結果として、ドキュメント駆動開発は「AIのため」ではなく、「チーム全体の開発プロセスを最適化する手法」であるという結論に至り、この開発手法を導入しています。

4. バックエンド開発 with AI

ここからはバックエンド/フロントエンドそれぞれでの取り組みを簡単に紹介します。

バックエンド開発はAIとの協業を成功させるために、まず「AIが迷わず、最高のアウトプットを出せる土台をどう作るか」という点から考え始めました。

4-1. AI駆動開発の3つの指針

AI駆動開発を始める前に、AIと開発するための3つの指針を考えました。

ドキュメント駆動

「3. ドキュメント駆動開発を軸にする」でもご説明した考え方です。AIのパフォーマンスはインプットされるコンテキストの質に大きく左右されます。人間とAIが同じドキュメントを「共通のコンテキスト」として参照することで、双方の認識のズレを防ぎ、精度の高い実装を目指しました。

テストファースト

AIは高速なコード生成は可能ですが、人間が見ればすぐに気づくような単純なミスや、考慮漏れなどのハレーションを起こすことが少なくありません。AIの生成物を盲信せずに必ずテストで品質を担保することを目指しました。

DDDとレイヤードアーキテクチャ

ドメイン駆動設計（DDD）の考え方を取り入れ、責務を明確に分離するレイヤードアーキテクチャを採用しました。これにより、各レイヤーのインターフェースを定義すれば、AIが実装を並列で進められるようになることを目指しました。

4-2. Claude Slash Commandsを利用した標準化

上記の指針を、日々の開発作業に落とし込むためにClaude Slash Commandsをベースとした開発フローを実践しました。AIへの指示が個人のプロンプトスキルに依存するのを防ぎ、「誰がやっても同じ品質」の開発の「型」を作りました。

コマンド	目的	実現される効果
implrpc	RPCエンドポイントの実装	• ドキュメント存在確認を強制（仕様書がないと実装不可） • テスト駆動開発（TDD）の徹底 • analyze → 人間実装 → implementの段階的実装
commit-ready	コミット前の品質チェック	• モック生成・フォーマット・Lint・テストを順次実行 • エラーが完全に解決するまで継続的にAIが修正 • コミットされるコードの品質を一定以上に保証
create-pr	PR作成の自動化	• PRテンプレートに従った一貫性のあるPR作成 • 修正内容に適したPRタイトル・説明の自動生成 • セルフレビューコメントの自動追加

implrpcコマンド

RPCのエンドポイントを実装するためのコマンドです。実行時にまず対応するRPC仕様書の存在を確認し、「ドキュメントをもとに必ず開発する」というルールをコマンドで強制する仕組みです。またドメインレイヤーや各レイヤーを繋ぐInterfaceは人間が主導して実装することでAIによるハレーションを減らすようにしています。

# Implement RPC

**このコマンドの目的**: テスト駆動開発）手法に従って新しいRPCエンドポイントを実装します。

## Overview

Implement a new RPC endpoint following strict TDD (Test-Driven Development) methodology.

⚠️ **IMPORTANT NOTICE** ⚠️

Always carefully consider before executing commands from this file. Before implementation, verify:
- The RPC specification is clearly defined
- You understand the impact on the existing codebase
- You understand the Test-Driven Development process

## Arguments

- `rpc_name` (required): The name of the RPC method to implement
- `phase` (optional): The execution phase - "analyze" (default) or "implement"

## Prerequisites (MANDATORY)

**→ For detailed implementation standards, refer to the following sections in `coding-standards.md`:**
- RPC Implementation Standards
- Documentation Standards
- Test-Driven Development (TDD)

### Mandatory Pre-implementation Checklist:

1. **Verify RPC Specification**
2. **Study Project Documentation**
3. **Validate Proto Definition**
4. **Reference Existing Implementations**
5. **Check Auto-generated Files**

## Execution Modes

This command operates in two phases:

### Phase: "analyze" (Default)
When executed without phase argument or with `phase=analyze`:
- Analyzes the proto definition
- Provides guidance and templates for human implementation
- Shows examples of interfaces and tests to write

### Phase: "implement"
When executed with `phase=implement`:
- Reads human-written code from Phase 1
- Executes three parallel implementation tasks
- Generates complete implementation based on interfaces

## RPC Implementation Specification

Based on the provided `rpc_name` argument, the command will:

### RPC Details
- **RPC Name**: `{rpc_name}`
- **Functionality**: {Analyze proto definition to determine functionality}
- **Proto Messages**: {Extract Request/Response types from proto definition}

## Implementation Process

### When phase="analyze" (First Execution)

The command will:

1. **Review Documentation** (MANDATORY)
2. **Analyze Proto Definition**
3. **Generate E2E Test Implementation**
5. **Provide Implementation Guidance**
6. **Output Templates and Implementation**
   **E2E Test Implementation** (`test/e2e/{snake_case_rpc_name}_test.go`):

### Human Implementation Phase (Between Commands)

**After reviewing the analysis and AI-generated E2E tests, humans should implement:**

1. **Layer Interfaces**
2. **Domain Layer** (if new domain concepts are needed)

### When phase="implement" (Second Execution)

**After human implementation is complete, the command will:**

1. **First, review all documentation** (CRITICAL)
   - **MUST** re-read docs to ensure implementation follows project standards
   - **MUST** verify patterns match architecture documentation
   - **MUST** check RPC specification in `docs/03-api-reference/{snake_case_rpc_name}.md`
   - **MUST** follow patterns from `docs/architecture/` and `docs/technical/`
   - **MUST** ensure all implementations align with documentation

2. **Then execute parallel tasks following strict TDD methodology:**

#### Parallel Task 1: Interface Layer Implementation (RPC Handler) - TDD Process
**MANDATORY TDD Steps:**
1. **FIRST: Write failing unit tests**
2. **SECOND: Implement minimal code** to make tests pass (green phase)
3. **THIRD: Refactor** while keeping tests green

#### Parallel Task 2: UseCase Layer Implementation - TDD Process
**MANDATORY TDD Steps:**
1. **FIRST: Write failing unit tests**
2. **SECOND: Implement minimal code** to make tests pass (green phase)
3. **THIRD: Refactor** while keeping tests green

#### Parallel Task 3: Infrastructure Layer Implementation - TDD Process
**MANDATORY TDD Steps:**
1. **FIRST: Write failing unit tests**
2. **SECOND: Implement minimal code** to make tests pass (green phase)
3. **THIRD: Refactor** while keeping tests green

commit-readyコマンド

コミット前に必ず実行する、品質チェック用のコマンドです。mock生成、フォーマット、Lint、テストを順番に実行し、問題があればAIが可能な範囲で自動修正まで行います。これにより、コミットされるコードの品質を一定以上に保ちます。

# Commit Ready

**このコマンドの目的**: コードをコミットする前に、フォーマット、リント、テストのチェックを実行してコードベースを準備します。

## Overview

Prepare the codebase for commit by running format, lint, and test checks. This command runs the essential pre-commit checks to ensure code quality and correctness before committing changes.

## CRITICAL REQUIREMENTS

**IMPORTANT**: This command MUST execute ALL of the following commands in order:
1. `make gomock`
2. `make fmt`
3. `make lint`
4. `make test`

**MANDATORY**: The command MUST continue fixing all lint and test errors until they are completely resolved. Do not stop at the first error - continue iterating and fixing issues until all checks pass successfully.

## What this command does

1. **Generate mocks** (`make gomock`) - MUST be run first to regenerate all mock files ensuring they're up to date with current interfaces
2. **Format code** (`make fmt`) - Formats all Go code using goimportz and gofumpt
3. **Lint code** (`make lint`) - Runs golangci-lint to check for code quality issues
4. **Check test coverage** (`make coverage`) - Generates test coverage report and ensures adequate coverage
5. **Verify test implementation** - Checks that all layers have proper tests:
6. **Run tests** (`make test`) - Executes all tests with race detection

## Execution Order and Error Handling

The commands are executed in this specific order:
1. `make gomock` - ALWAYS runs first to ensure mocks are up to date
2. `make fmt` - Formats the code (including newly generated mocks)
3. `make lint` - Checks code quality
   - If lint errors are found, fix them and re-run `make lint`
   - Continue fixing and re-running until all lint errors are resolved
4. `make coverage` - Checks test coverage
5. `make test` - Runs all tests
   - If test failures occur, fix them and re-run `make test`
   - Continue fixing and re-running until all tests pass

**IMPORTANT**: Do NOT stop at the first error. Keep fixing issues and re-running the failed command until it passes, then continue with the next command.

## Prerequisites

- All source code files should be saved
- Docker should be running (for Spanner emulator during tests)
- No ongoing file modifications

## Output

The command will:
- Show formatting results
- Display any lint issues that need to be fixed
- Display test coverage report with percentages per package
- Identify any missing tests or low coverage areas
- Run the full test suite and report results
- Indicate if the code is ready for commit

## Exit behavior

- If any step fails, the command will stop and show the error
- Only when all checks pass is the code considered commit-ready
- Fix any reported issues before attempting to commit

## Common issues and solutions

### Mock generation issues
- **Outdated mocks**: If interfaces have changed but mocks haven't been regenerated, tests will fail
- **Missing mocks**: New interfaces need mock generation before tests can be written
- **Solution**: Always run `make gomock` before committing to ensure all mocks are up to date

### Lint errors
- **godot**: Comments should end with a period
- **gofmt**: File formatting issues (automatically fixed by `make fmt`)
- **goimports**: Import organization issues (automatically fixed by `make fmt`)

### Test failures
- Check test output for specific failure details
- Ensure all mocks are properly configured
- Verify database schema is up to date

### Coverage issues
- **Missing E2E tests**: Check that all RPC endpoints have corresponding tests in `test/e2e/`
- **Low use case coverage**: Ensure all use case methods have unit tests with both success and error scenarios
- **Missing converter tests**: Add tests for all conversion and validation functions
- **Repository coverage**: Verify integration tests cover all repository methods

### Format issues
- Usually auto-fixed by `make fmt`
- Ensure consistent indentation and import grouping

create-prコマンド

開発が完了した際にcommitからPRの作成までを行うコマンドです。PRのテンプレートを参照し、修正内容にあったPRを作成します。

# Create PR

**このコマンドの目的**: CLAUDE.mdのルールに従ってプルリクエストを作成し、レビューコメントを追加します。

## Overview

This Claude Code project command creates a PR following the rules in CLAUDE.md and adds a review comment.

## Functionality

1. Ensures commits follow Semantic Git commits convention using `npx git-cz`
2. Checks current branch changes using git commands
3. Creates PR following CLAUDE.md PR creation rules:
4. After PR creation, adds self-review comment:

## Implementation

This command is executed internally by Claude Code, not as a bash script. When invoked via `/create-pr`, Claude will:

1. Use `npx git-cz` for creating semantic commits if there are uncommitted changes
2. Run `git status`, `git diff`, and `git log` to analyze changes
3. Use `gh pr create` with proper template structure and semantic title
4. Add review comment using `gh pr comment`

## Commit Convention

All commits must follow Semantic Git commits format using `npx git-cz`:

- **feat**: A new feature
- **fix**: A bug fix
- **docs**: Documentation only changes
- **style**: Changes that do not affect the meaning of the code
- **refactor**: A code change that neither fixes a bug nor adds a feature
- **test**: Adding missing tests or correcting existing tests
- **chore**: Changes to the build process or auxiliary tools

PR titles should match the primary commit type and scope.

## Prerequisites

- Changes must be pushed to remote branch beforehand
- Must be executed from a branch other than main
- Ensure commits exist before execution
- GitHub CLI (`gh`) must be configured and authenticated

これらのコマンドを整備したことで、「AIにどう指示すればいいか迷う時間」がほぼゼロになりある程度実装の型を作ることができました。

4-3. コンテキスト管理と役割分担

またAIの能力を最大限に引き出すため、コンテキスト管理や役割分担も工夫しました。

ドキュメントとコンテキストの分離・整備

AIに与える情報は質だけでなく量も重要です。要件定義からDB設計・ADRなど、必要だと思ったドキュメントはまずAIにたたき台を作らせ、人間がレビューする方針で網羅的に整備しました。 またコンテキストファイルは役割を分け、AI向けのCLAUDE.mdはAIの理解度・精度が高い英語で、人間が主に参照するドキュメントは可読性を重視して日本語で管理しています。

AIと人間の役割分担

アプリケーションの核となるドメインロジックや、レイヤー間の繋がりを定義するインターフェース部分は人間が主体となって実装するようにしています。重要な部分の実装をAIに全て任せてしまうとどれだけ適切にコンテキストを与えることができていたとしても、手戻りが大きくなるリスクがあるためです。

5. フロントエンド開発 with AI

(この章はFEのAI駆動開発を推進したエンジニアのhan sanに寄稿いただきました。)

フロントエンド開発は、バックエンドとはまた違ったアプローチでの開発を実施しました。

5-1. 目的ごとのツール群とMCPサーバーの活用

フロントエンドではより細かく用途によるAIツールの使い分け、MCPの活用を行いました。

• メインツール: Claude (Code/Desktop)
• 自動化・サブツール: GitHub Copilot Agent
• 壁打ち・相談役: Gemini Pro

特に開発効率を大きく向上させたのが、MCPサーバーの活用です。

• context7: OSSのドキュメントなどを参照させ、Mantine UIのようなライブラリの正しい使い方をAIに学習させる。
• playwright: AI自身に画面を操作・確認させ、E2EテストやUIの動作確認を行わせる。
• figma: デザインデータからUIプロパティを直接取得させ、デザインと実装の乖離を防ぐ。

5-2. 2つの開発パターン

日々の開発では、タスクの複雑さに応じてAIへの指示の出し方を2つのパターンで使い分けていました。

パターン1: シンプルなタスクは「直接指示」

「テキストのvariantを変えてください」や「実装に合わせてStorybookのケースを増やしてください」などは直接指示でも十分期待通りの結果を出せます。

パターン2: 複雑なタスクは「Opus 4で計画、Sonnet 4で実行」

一機能の実装計画を立てる場合はまず思考能力の高いClaude Opus 4に「フロントエンドのエキスパート」として詳細な実装計画を立て、その計画をClaude Sonnet 4に渡してコーディングを行います。 Opus 4 はセッションあたりのトークン上限が Sonnet 4 より小さいため、コスト効率の観点から「計画＝Opus 4」「実装＝Sonnet 4」と使い分けています。計画の精度が高ければ、実装品質は Sonnet 4 で十分に担保できます。

5-3. AIと協働するための工夫

並列作業の実現

Git worktreeとClaude CodeなどのAI CLIツールを組み合わせることで、複数の、ターミナルセッションで作業を同時に進められることができます。これによってエンジニア一人で複数のタスクを分担処理でき、作業の効率化を図ることができました。

エンジニアがUIデザインまで担う自由度

UIライブラリで構築された管理画面の実装を行う際、Context7 MCPを活用することで、AIがUIライブラリの仕様を把握でき、一貫性のあるモダンなUIを迅速に作成することができました。

6. 見えてきた課題と今後取り組みたいこと

AI駆動開発を本格的に実践したからこそ、現実的な課題も見えてきました。ここでは、私たちが直面した主な課題と、今後どのような取り組みをしていきたいと考えているかについてお伝えします。

6-1. AIレビューの限界

私たちは当初、コードレビューもAIが行うことで開発がうまく回るのではないかと考えていました。しかし、1ヶ月半試行錯誤した上での正直な感想は、「どれだけpromptを改善しても、レビュアーとしてはまだ物足りない」というものでした。

以下は試したAIコードレビューの一例です。

AIツール	手法	結果
Github Copilot	PRのレビュアーに入れることによる自動レビュー	typoの修正や部分ごとの実装の修正提案はあるが、PRコード全体でのレビューは難しい。
Devin	slackでのコミュニケーションによるレビュー	PR全体でのレビューは可能だが、設計思想やドメインを理解した上でのレビューは難しい。
Claude Code Action	カスタムプロンプトによるGHAを使用した自動レビュー	プロンプトのチューニングも行ったが、Devinとほぼ同じ結果であった。PR全体でのレビューは可能だが、設計思想やドメインを理解した上でのレビューは難しい。

AIはコーディング規約違反や単純なロジックミスといったレビューであれば問題なく対応できます。しかし、私たちがレビューで本当に求めているのはそこだけではありません。

• この設計は、半年後の機能拡張に耐えられるか？
• ビジネスのドメインルールを正しくコードに反映できているか？
• パフォーマンス上の懸念や、よりシンプルな代替案はないか？

こういった背景知識や将来のプロダクト展開までを考慮した「設計の妥当性」に関するレビューは、やはり経験を積んだ人間のエンジニアが行う必要があると感じました。

この経験から、あくまで我々がトライした条件下の中ではありますが、人間によるコードレビューは品質を担保する上で今後も不可欠であると感じています。

6-2. コンテキストを十分に与えられない分野でのコード生成

AIは一般的なWeb開発の知識は豊富ですが、特定のデータベースでの最適化などはそのままでは難しいのではないかと感じました。

特にSpannerのような比較的新しいDBを扱う上で例えば、

• interleaveで親子関係を設計したテーブルに対する、効率的なJOINクエリ
• クエリの実行計画を考慮した、パフォーマンスの最適化
• Spanner特有のトランザクション管理やインデックスのベストプラクティス

といった内容はAIが生成するコードだけでは不十分なケースが多くありました。

6-3. 「AIの実装しやすさ」と「人間のレビューしやすさ」のジレンマ

アーキテクチャの選定においても、課題を感じる部分がありました。例えば今回バックエンドで採用したレイヤードアーキテクチャは、責務が明確に分離されているため、AIに対して「このレイヤーを実装して」と指示を出しやすく、並列でのコード生成も可能という点で「AIフレンドリー」と感じたため採用しました。

しかしその一方でコード量が増加し、人間のレビュー負荷が高まるというデメリットも生じました。例えば一つの簡単な機能追加のために、各レイヤーの複数のファイルにまたがって変更が必要になり、レビュー時に全体像を把握するのが難しくなっていました。

AIの生産性を最大化するアーキテクチャと、人間が保守・レビューしやすいアーキテクチャをどう両立させるかは今後より実践を重ねていきたいと思っています。

6-4. 今後取り組みたいこと

今回AI駆動開発を実践してみて、これからチームとして取り組んでいきたいことがいくつか見えてきました。今後はチームとして特に下記2つを意識してAI駆動開発に取り組んでいきたいと考えています。

1つ目は、開発の専門領域を超えた動きをしていくことです。 フロントエンドとバックエンドそれぞれの領域でAI駆動開発の実践によってAIを利用した開発の型が定まり、AIを活用することで専門でない分野のキャッチアップも容易になってきています。

そのため「フロントエンドだから」、「バックエンドだから」と役割を限定せず、互いの領域をどんどん越境して助け合えるようにしていきたいと考えています。少数チームであってもAIを活用することでお互いの領域の手助けをし合えるチームにしていきたいです。

2つ目は、開発に閉じない動きをしていくことです。 今後はこれまで以上にエンジニアも企画や要件定義の段階からどんどん首を突っ込んでいきたいです。

AIと開発することでこれまでよりも確実に開発スピードは上がってくると思っています。そんな状況の中で、「どう作るか」だけでなく、「なぜ作るのか」、「何を作るのか」から一緒に考えていけるようにしていきたいです。

7. おわりに

それぞれの開発フェーズでAIと人間の役割をまとめてみました。

開発フェーズ	AIの役割	人間の役割
設計・計画	アイデアの壁打ち、たたき台作成	要件定義、アーキテクチャの最終決定
実装	定型コードの生成、並列実装、翻訳	複雑なビジネスロジックの実装、設計判断
テスト	単体テストコードの生成、E2Eテストの実行	テストケースの設計、仕様に基づいた検証
レビュー	Lint、コーディング規約の自動チェック	設計の妥当性評価、拡張性・保守性のレビュー
ドキュメント	テンプレートからの生成、議事録の要約	仕様の明確化、全体像の記述

今回は私たちなりのAI駆動開発という取り組みを紹介させていただきました。この記事が同じようにAIと共に新しい開発の型を模索している皆さんの何かしらのヒントになれば幸いです。

Gaudiyでは私たちと新しいことに積極的に向き合って新しい型を作っていく仲間を積極的に募集しています！この記事を読んで、Gaudiyの開発スタイルに少しでも興味を持ってくださった方、ぜひ一度カジュアルにお話ししませんか？

ご応募、お待ちしています！

site.gaudiy.com