概要
このブログでは、Amazon Q Developerを活用したチーム開発をした際に、もっとこうすればよかったなと感じた部分を振り返ります。Amazon Q Developerを使ったことがない方や、これからチーム開発を始める方の参考になれば幸いです。
私自身が個人的に感じた振り返りなので、他の方の意見や考え方もあると思います。あくまで一例として参考にしてください。 こんなのもいいよ！という意見もお待ちしています！
【この記事で得られること】
- 生成AI活用チーム開発の初期設計で外せない3ポイント
- 構成テンプレ・スコープ宣言・仕様ドキュメント化の具体的効能
はじめに
こんにちは！カスタマーサクセス部 CS1課の圡井です！ みなさん、Amazon Q Developerなど生成AIによる開発支援ツールを活用していますか？ お恥ずかしながら私は「コードでわからないところをちょっと聞く」程度の使い方で、生成AIを「フル活用」できていなかったと思います。
そんな私は現在「AWS Next Generation Engineers Leaders Dojo (ANGEL Dojo) 」というプログラムに参加しています。 ANGEL Dojoとは、AWSユーザ企業とAWSパートナー企業が協力し、3か月の期間でユーザ企業の課題を解決するシステムを構築しながら内製化を促進することを目的としたプログラムです。
私たちのチームは、ユーザ企業4名、パートナー企業3名の計7名で構成されており、週に2日のペースでオンラインミーティングを行いながら開発を進めています。メンバーの中には、業務上システム開発に携わらない方もいるため、約3か月という短期間で開発するために、生成AIを活用して開発を進めることにしました。
いろいろ工夫しながら行っている開発も終盤に差し掛かってきたため、一度振り返ってみて、より効率よく開発をスタートするために、私が感じた「こうすればよかったな」という点を紹介します。
チーム体制や開発するシステムについて
参考までに、私たちのチーム体制や開発しているシステムについて簡単に紹介します。
チーム体制
私たちのチームは以下のような体制で開発を進めています。
- ユーザ企業
- 普段開発に携わらない：3名
- 社内の中～大規模システムの開発経験がある：1名
- パートナー企業
- AWSインフラ上で動く小～中規模システム開発経験がある：1名（私）
- AWSインフラ構築が主で普段開発に携わらない：2名
開発するシステムについて
私たちのチームが開発しているシステムではフロントエンド、バックエンド両方を開発しています。略図は以下です。
開発ディレクトリ構成
開発するシステムのディレクトリ構成は以下のようになっています
開発序盤のディレクトリ構成：
root/
├── my-app-frontend/ # Reactフロントエンド資材
│ └── ・・・
└── my-app-backend/ # AWS Lambda内のソースコードなどバックエンド資材
└── ・・・
チーム開発でこうすればよかったと感じたこと3選
私たちのチームが開発を進める中で、こうすればよかったなと感じた点を3つ紹介します。 これからチーム開発を始める方や、生成AIを活用したことがない方の参考になれば幸いです。
1. 開発テンプレートを定義しよう！
開発を始める前に、コードのテンプレートをしっかりと定義しておくとよかったなと感じました。 フロントエンドであれば、Reactのコンポーネントの構成や、APIエンドポイントなど外部情報の格納方法、バックエンドであれば、データベースのスキーマや、APIのレスポンス形式などを定義しておくと、開発がスムーズに進むと思います。
フロントエンドの場合、Reactのコンポーネントの構成を例とします。 Reactのデフォルトのコンポーネント構成は以下のようになっています（一部省略）。
REACTデフォルトの構成：
my-app/ ├── .git/ # Gitリポジトリの管理データ ├── .gitignore # Git追跡除外設定 ├── README.md # プロジェクト説明書 ├── package.json # 依存関係とスクリプト定義 ├── package-lock.json # 依存関係の詳細なバージョン情報 ├── node_modules/ # インストール済みパッケージ ├── public/ # 静的ファイル └── src/ # ソースコード（開発用ファイル）
Q Developerに問い合わせながら開発を進めていくと最終的に下記のような構成になりました。
初期 → 最終構成の差分：
my-app/
├── .env.development # 開発環境用環境変数
├── .env.production # 本番環境用環境変数
├── scripts/ # デプロイ・ビルド用スクリプト
└── src/ # ソースコード
├── assets/ # 画像・フォントなどの静的アセット
├── api/ # API通信層
├── components/ # 再利用可能なUIコンポーネント
├── config/ # 環境設定・定数
├── data/ # 静的データ・モックデータ
├── hooks/ # カスタムフック
├── models/ # データモデル定義
├── pages/ # ページコンポーネント（ルーティング単位）
├── services/ # ビジネスロジック層
├── styles/ # スタイルシート
├── types/ # TypeScript型定義
└── utils/ # ユーティリティ関数
チーム開発では、各々ローカル環境で開発が進められます。そのため、生成AIにコーディングを依頼する際に、自動的に様々なディレクトリやファイルが生成されてしまい、統合した際に同じ機能を有するコードが複数存在してしまうことがありました。
着手前に「推奨ディレクトリ構成」「コンポーネント配置規約」「環境変数の置き方」「APIレスポンス標準形」「データモデル命名」などをテンプレート化しておけば、後から散らばった構造を統合するコストを大幅に減らせたと思います。
2. 自身の役割を的確に指示しよう！
生成AIに対して、自身の役割（特に開発スコープ）を的確に指示することが重要だと感じました。 チーム開発では、各メンバーが異なる機能を同時に開発します。例えば、閲覧画面や投稿画面などです。それぞれの機能に対して明確な指示を出すことで、生成AIがより適切なコードを生成しやすくなります。
例えば、閲覧画面を開発するフェーズを考えます。 この画面は機能A、B、Cの3つの機能を持っているとします。 あなたは機能Aを作成する役割を担当したとします。 そして、生成AIに対して以下のように指示を出します。
指示例（改善前）:
閲覧画面を作成してください。要件は以下です... - 要件1 - 要件2 - etc.
このように指示を出すと、生成AIは閲覧画面に必要なコードを生成します。 ですが、機能A、B、Cの全てのコードが生成されてしまう可能性があります。 そのため、以下のように「自身の開発スコープ」を明確に指示します。
指示例（改善後）:
閲覧画面のうち「機能A（〇〇表示）」のみを担当しています。 前提： - 機能B/Cは別メンバー - ルーティングは既存 BrowserRouter 利用 要件（機能A）: 1. ～ 2. ～ モックデータで実装し、API層は仮の関数を返す形でお願いします。
生成AIは機能Aに必要なコードのみを生成します。こうすることで、チーム全体でのコードの重複や意図しない競合を防ぎ、効率的に開発を進めることができます。
3. ドキュメントを充実させよう！
開発を進める中で、ドキュメントの充実が重要だと感じました。 特に、フロントエンドの接続先APIの仕様や、バックエンドのデータベーススキーマなどを明確にドキュメント化しておくことで、チーム全体での理解が深まり、開発がスムーズに進むと思います。
今回の開発では、バックエンドのインフラ構成はIaC化しておらず、手動管理しています。その代わりに今後のIaC化やCICDの自動化を見据えて、Lambda関数のコードを関数名フォルダごとに分けて管理していました。 これだけでも、フロントエンドのメンバーが接続先APIの情報を把握しやすく、生成AIも的確なコードを生成しやすくなりました。
初期のディレクトリ構成：
my-app-backend/ ├── lambda-function-A/ # Lambda関数Aのコード │ └── lambda_function.py ├── lambda-function-B/ # Lambda関数Bのコード │ └── lambda_function.py └── ・・・
開発をすすめていく中で、my-app-docsというドキュメント用のディレクトリを作成しました。この中には、Lambda関数などAPIの仕様書やデータベースのスキーマ、プロジェクトに関する重要な情報をまとめています。
このように、フロントエンド・バックエンドのソースコードには表れない情報をドキュメント化しておくことで、生成AIの精度も向上し、チーム全体での理解も深まります。
現在のディレクトリ構成：
my-app-backend/ ├── lambda-function-A/ │ └── lambda_function.py ├── lambda-function-B/ │ └── lambda_function.py my-app-docs/ ├── api-spec.md ├── db-schema.md └── naming-conventions.md
（番外編）Q Developer Proを活用しよう！
Q DeveloperはAWS Builder IDにサインアップ（無料）するだけで利用を開始することができますが、開発のためにいろいろ問い合わせていると、あっという間に無料枠の上限に達してしまいました。もしそういった場合は、Q Developer Proを検討してみるのもよいかもしれません。
Q Developer Proの比較ブログも公開していますので、ぜひ参考にしてください。
まとめ
- 開発テンプレートを定義しよう！
- 開発を始める前に、コードのテンプレートをしっかりと定義しておくとよい
- 自身の役割を的確に指示しよう！
- 生成AIに対して、自身の役割（特に開発スコープ）を的確に指示するとよい
- ドキュメントを充実させよう！
- ドキュメントの充実が重要。特に、フロントエンドの接続先APIの仕様や、バックエンドのデータベーススキーマなどを明確にドキュメント化しておくとよい
今回は、Amazon Q Developerを活用したチーム開発を振り返り、こうすればよかったなと感じた点を紹介しました。今回はAmazon Q Developerで開発しましたが、他の生成AIツールを活用する場合でも同様のポイントが当てはまると思います。
生成AIを活用したチーム開発は、まだまだ試行錯誤の段階ですが、今回紹介したポイントを参考にして、より効率的で効果的なチーム開発を実現できればと思います。
圡井一磨(執筆記事の一覧)
23年度新卒入社しました。最近は自炊にはまっています。アパートのキッチンが狭くて困ってます。
