アプレンティスで2回目のチーム開発を体験させていただきました。
期間中に私が考えていたことや、チームへ貢献したことについて書いていきます。
1.アプレンティス チーム開発について
本来であれば複数チームがアプリを開発し、プレゼンによって結果を競い合うハッカソン形式でしたが、受講生が減少したことから1チームのみが発表を行う形式となりました。
2.役割やメンバーについて
今回はチームを統合した結果5名での開発を行いました。
メンバーのほとんどはフルタイムで働いており、実装期間が1週間であることから、効率的に開発を進める必要がありました。
私は他のメンバーよりも学習が進んでいたことや、アプレンティスと並行して実務を経験していたことからテックリードのような役割を務めさせていただきました。
主にコードの品質を高める実装方法の提唱や技術に関する相談に乗るなど、技術的な面でチームを率いることで開発を円滑に進められるよう貢献しました。
まずは制作したアプリについてご紹介します。
3.開発したアプリについて
アプリの概要
画像生成AIを使用した4人同時対戦を行うゲームです。
指示されたお題に対して画像生成AIにプロンプトを入力し、
最もお題に近い画像を生成できた人が勝利するというものでした。
開発の背景
開発の背景ですが、近年はプロンプトエンジニアリングという言葉が生まれるほどAIを活用する能力の価値が高まっています。
そこでプロンプト作成をゲーム化することで、遊びながらプロンプト作成の技術を磨けたら面白いのでは？
という考えから開発することに至りました。
ゲームの流れ
流れとしては、はじめにニックネームを入力し、部屋を作成するか参加するかを選びます。
4人集まるとゲームが開始され、お題に対してプロンプトを考えて入力
すると画像が生成されるので、
自分以外で最もお題に近いと感じる人へ投票し
最終的に票数の多かった人が勝利するというものでした。
使用技術
フレームワーク：NextJS
主要言語：TypeScript
フロントエンド
・React
・Jotai（状態管理）
・shadcn/ui（共通コンポーネント部）
バックエンド
・NextJS API Routes
・VercelKV (Redis uptrash）
サードパーティAPI
・OpenAI DALL-E（画像生成）
・DeepL （プロンプト英訳）
設計資料
ワイヤーフレーム図(設計段階)
Reactコンポーネント設計図
ディレクトリ構造
続いて担当したタスクについて述べます。
4.開発期間に担当したこと
全体スケジュールの作成
全体の進捗を確認する必要があると考えたため、ガントチャートによる全体スケジュール作成を担当しました。
一回目のチーム開発ではアプレンティスの課題がある週は時間が確保できなかったため、今回は該当期間の進捗を低く見積もることで、前回よりも精度の高いスケジュール作成ができたと感じます。
CodeSandboxによる検証環境の構築
画像生成に関しては懸念が多く存在したため、早い段階でデモ用のコードを実装してどのような挙動になるかを確認する必要がありました。（生成待ち時間や、思い通りの画像を出力できるかなど）
そこでCodeSandboxを使用して検証環境を構築し、OpenAIのAPIを使用した待ち時間やプロンプトによる挙動の変化などを事前に検証することで、設計段階で多くの懸念を取り除くことができました。
また、プロンプトが英語でないと精度が低いという情報を得られ、テキスト翻訳用APIが必要であると早期に気づくことができました。
Reactコンポーネント設計図の作成
過去にReactのコンポーネントの全体設計を甘く見積もったことでProp Drillingによって苦労した経験があったので、Reactコンポーネントの関係性を記述した設計図を作成しました。
これにより全体の構図をメンバーに共有できたり、実装する前にコンポーネントを最適に分離できるなど、React部分の開発を進めるうえで役立ちました。
ディレクトリ構造/ファイル命名規則の提案と整備
特にNextJSではディレクトリでルーティングを行うため、該当のファイルには処理を記述しないように分離して設計しました。
また命名規則を作成することで命名に一貫性を持たせ、規則性のある構造を維持するよう心掛けました。
Gitのリポジトリに記述しておき、変更があった場合には修正を行い最新の状態を維持しました。
今回のアプリではやや過剰だったと感じましたが、メンバーがファイルの保存場所で迷うことなく円滑に進めることができたので、整備する価値があったと感じます。
デバッグ環境構築とメンバーへの説明
フロントとバック両方でデバッガーを動作できるように、Next公式ドキュメントを参考にデバッグ環境の構築し、メンバーへ使い方の説明を行いました。
今回はWindows,MacだけでなくUbuntuでアプレンティスに参加しているメンバーがおり、それらの端末でデバッガーを動作させる必要がありました。
しかしUbuntu環境で動作させることが難しく、断念してしまったことは悔いが残ります。
フロント・バック 双方のサンプルコード作成
フロントエンドとバックエンドではファイルを細かく分割していたため、先にサンプルコードを実装しておくことで、メンバーが参考にしながら開発できるよう準備を行いました。
コード側でも解説が必要だと思っていましたが、ディレクトリ構造と合わせてメンバーが自力で理解してくれており、アプレンティスに参加しているメンバーのレベルの高さを改めて実感しました。
git issues + milestoneによるタスク管理の提案と整備
実装期間のタスク管理について、オープンソースソフトウェアのリポジトリをいくつか閲覧したうえで、タスクの管理方法を参考にしました。
Notionも選択肢の一つだったものの、Git上で管理したほうがコードに合わせて更新しやすく、メンバーから使ってみたいという意見があったことからGit上で管理する方法を選びました。
この提案はかなり成功したことの一つで、コードの状態と残りのタスクを把握するうえでとても役立ちました。
Reactコンポーネントにおける関心の分離の提唱
関心の分離について、例として以下のようなコードがあります
ハイライトされている行で、別ファイルに定義した動作部分をインポートしています。
これにより今回のファイルでは主にreturnによる描画用のコードを記述していることが分かると思います。
メリットは主に2つあり、再利用が可能になること、ファイルが肥大化しないため読みやすくなることなどが挙げられます。
開発が終わるころに一部実践できていないコンポーネントが発生してしまったことは心残りですが、メンバー全員の技術力を高めることができたことは嬉しく思います。
APIの設計/実装とエンドポイント作成
フロントを開発するメンバーの負担が最小になるように、フロント用のエンドポイント実装も含めてAPIの設計と実装を担当しました。
反省点として、コードだけでは伝えられる情報に限りがあるため、ドキュメントの作成も行うべきだったと感じます。
5.反省点
最悪の事態を想定すること
今回の開発を通じて最も反省したことは、最悪の事態を想定しておくべきだったということです。
発表の直前までは何度も正常に動作していましたが、本番になると最後の処理がエラーで動作せず、プレゼンで発表しきれなかったことは非常に悔しい経験となりました。
特に重要な場面で準備を怠らないことは、この出来事を教訓に心掛けていきたいと思いました。
負荷の分散
前提としてメンバーによってチーム開発に割ける時間にはばらつきがありました。
そこで進行に必要なタスクは担当できる人が可能な限り担当していましたが、これにより一部のメンバーに負荷が集中してしまったことは反省すべき点でした。
タスクを細かく分けて負荷分散を行うなど、チームとしての生産性を高めるためにまだまだ改善できる点があったと感じました。
6.まとめ
今回のチーム開発は前回よりも多くの失敗や学びがありました。
チーム開発は終わり、特に強制されていませんが一緒に開発をしてくれたメンバーとは今でも毎週集まっています。メンバーは全員思いやりがあって本当に居心地のいい場所です。
このような機会を作ってくれたアプレンティスと、一緒に開発を乗り切ってくれたチームメンバーには本当に感謝しかないです。
アプレンティスとしての残り時間はわずかですが、メンバーと一緒にベストを尽くしていきたいと思います。
ご一読いただきありがとうございました。