はじめに
この記事はIT業界未経験の4人(私と同期3名)でチーム開発を行った際に起きた課題とプロジェクトを無事に進行するために奔走した私の記録です。もしあなたが初めてのチーム開発の中で「もしかして私しか把握してないことがある…？」「他のメンバーは今どんな作業をしてるんだろう…？」と感じた場面があるなら、きっとこの記事が役に立つはずです。
想定する読者
- 未経験からIT業界に入ったエンジニア
- これからチーム開発に初めて取り組むエンジニア
1番伝えたいこと
今回の初めてのチーム開発で私が感じた特に重要な2つの教訓を先に伝えさせていただきます。もしこれから似たような取り組みをする方がいたら「そういえばこんな記事あったな」と思い出してもらえればきっと同じ失敗は避けられるはずです。
- 方針やルールを全体で共有・更新しよう
- チーム全体が立ち止まるタイミングを作ろう
開発について
概要
チームメンバー4名で以下のフローチャートの画面から構成される音楽ゲームを制作
プロジェクトリーダーの記事は↓
チームについて
- 4名全員業界未経験、入社1か月の新人エンジニア
- 研修課題としてAWSを利用したフロントエンドとバックエンドによるwebアプリの構築を行った経験あり
- AI(ChatGPT,Geminiなど)を利用してコード作成やエラー解決をしながら学習
開発環境
開発期間は2週間、リモート無しのオフィスでの対面環境
共通環境
PC：Lenovo V15 G4 IRU
OS：Windows11 Pro(24H2)
言語：Python 3.13.4
使用ライブラリ：Pygame 2.6.1
IDE：Visual Studio Code 1.102.0
個人環境
主なAI支援：Gemini
VSCode拡張など：GitHub CLI, GitHub Pull Requests, Gemini CLI
メンバー環境
主なAI支援：ChatGPT
何があったか
様々な課題が次々と発生し、開発が進むにつれ私1人への依存度が大きなものになってしまいました。開発を大きく3つのフェーズに分けてどんな課題があったかとどのように進めたかを以下にまとめています。
開発初期
課題
- チームメンバーで重複する作業
- 画面ごとに違う変数・クラス・mainループ管理
当時の進め方
- 全体MTGでどんなものを作るか簡易的なワイヤーフレームを作成し、タイトルではこんな画面、選曲画面ではこんな画面といった方向性の決定
- メンバーごとに作る画面の振り分け、開発開始
→ ゲーム画面は大変そうだから2人、タイトルとリザルトは簡単そうだから2つで1人など - それぞれワイヤーフレームに沿った形に作成
開発中期
課題
- 分割進行によるリスク
- 統合版作成における手間
当時の進め方
- 今後起こりうる課題の共有と方向修正の提案
このまま全員バラバラに担当箇所だけ進める方針では後半でトラブルがあったら対処できない、今のうちに1つにして作り方を統一していくべき
→ 気づけば流れで私が統合する担当に - メンバーは担当箇所を独自に開発続行、私は途中段階のメンバーのデータから全てつなげて整合性をとった動作する形のものに
→ 統合版ができてもその間に進んだメンバーの進捗を反映するために再度私による更新作業が必要に
開発後期
課題
- GitHubの扱い
- 編集ルールの不足
- 例外の対応
当時の進め方
-
新規体制の提案
今の私が全て統合していく管理方式では限界がある、作業の追いかけっこが永遠に終わらない上に機能や変数も当初の予定から増えてきて1つの統合にかかる時間も伸びてきているので開発を一度区切ってGitHubで管理して負荷を分散したいと提案 -
GitHubへの移行
ディレクトリ構造や変数などをそれぞれメンバーが担当する箇所ごとに独立させた形に構成を変更し、GitHubでの運用開始。共通部分の編集やブランチの運用についてルールの周知 -
GitHub運用
メンバーがそれぞれブランチを作成し、pull requestしていくという開発環境に
例外の対応
- 特定のブランチではpull request後も継続して使われてしまい、途中で想定外の編集がされたためか毎回のpull requestで大量のコンフリクトを処理していた
- 共通部分は編集前に全体に確認し、他に該当箇所を編集しているメンバーがいないことを確認するはずが2人で同時に編集していた
何がダメだったか
自分しかできないタスクを抱え込んでしまった
→ 理解している人 を作る
これを行わないと作業を分担することもできないし、自分が何をしているのかも周りに伝わらないです。今回みんながそれぞれの担当箇所に集中して取り組んでいきましたが、進み続けるより一度立ち止まって全体を理解する時間を作る必要がありました。
改善提案： メンバーの理解を深めるための交流がなかったので簡易MTGのような定期的な予定を作るべきでした。
ルールから外れた運用の処理が頻発した
→ 途中でもルールを柔軟に更新 する
基本的に最初に決めたルールだけでは足りなかったり問題が発生します。その際にルールの追加や適切な変更でその後に問題が発生しにくくすることが重要です。
改善提案： 私と問題発生時に対応したメンバーしか把握していない方針があったので方針・ルールの最新版をまとめて確認できる仕組みを用意すべきでした。
人によって分野ごとの理解度が大きく異なっていた
→ やりたいことや求められることを共有し合う時間 を作る
共有するだけでは理解されずに進んでしまいます。全体で話し合い、理解度を高めあえるような時間が理想です。せっかく今回対面ですぐに話せる環境だったのにそれを生かし切れていなかったです。
改善提案： わからないを気軽に共有して相談・解決・理解できる環境を設けるべきでした。特にメンバーによって理解しているところが違ったため教えあうことで負担も少なく理解度の底上げが行えたはずです。
結論：全員が現状を把握できるようなタイミングを定期的に設けるべきだった
今回挙げた3点のダメだった点には理解や共有といった課題が共通しています。特に、今どういう状況でどのような課題を解決すべきかが十分に理解されずに進んでしまうような場面を減らせれば大きく改善できたはずです。「毎日15時に現状報告をし合う」と決めるだけでも全員で話せるタイミングがあることで相談しやすく、より良い環境づくりができたのではないでしょうか。
まとめ
今回初めてのチーム開発で経験もない中メンバー全員手探りで進行していきました。実際にやってみて直面した様々な課題もありましたが、何とか無事終了することができました。とても大変な2週間ではありましたが、かなり成長することができたと実感しています。
しかし、一歩間違えばプロジェクトの進行が不可能になるような危ない橋を渡る開発は可能な限り避けるべきです。今回は結果的にうまいことまとまりましたが、途中で最初から作り直しや進行不可になっていてもおかしくなかったです。
このような状況を避け、リスクや責任が一人に集中しないようにするためにも、チーム全体での密なコミュニケーションを通じて、メンバー全員の理解と協力を得ることが何よりも大切だと痛感しました。
この記事が、これからチーム開発に挑む皆さんの役に立つ日が来れば幸いです。
Discussion