😑

モダン技術とAIツールに挑戦し学んだ，技術よりも大切な「チームビルディング」の話

に公開
チーム開発
ウォーターフォール
反省
idea

はじめに

今回は，大学の講義で4ヶ月間のチーム開発を行ったのでその体験談を書いてみた．「Go + Next.js」というモダンな技術選定やAIエージェントやCodeRabbitの導入などの技術的な挑戦を詰め込んだプロジェクトであったが，その裏で「チーム開発の基本」という大きな壁に直面することとなった．この記事では，私たちのチームがどのような流れで開発を進め，どこで躓き，何を学んだのかを話していきたい．

プロジェクト概要

担当領域 人数 具体的な役割
PM / Backend / Infra 1名 プロジェクト管理，アーキテクチャ設計，環境構築
Backend / Infra 1名 API開発，DB設計
Backend 1名 ビジネスロジック担当
Frontend 3名 画面実装，コンポーネント設計，通信処理

プロジェクトの始動

2025年10月，弊学の講義であるソフトウェア工学が始まった．各チームの決定は，受講者が3名までの班を組んだ後にくじ引きでそれらの班を合体し，6名程度のチームを構成するものだった．先輩等の助言により，責任感や技術力がある人がすべてを抱え込んでしまうワンマンチーム化が問題となる傾向があったため，私は頼りになる友人と3人でチームを組み，プロジェクト開始に備えた．幸いにもくじ引きで決まったメンバーは全員が高いモチベーションがあるのと同時に成績優秀者が2名も居る恵まれたチーム構成となった．ここで，理想的なチーム構成こそが，後の停滞を招く要因の一つになったのかもしれない．優秀なメンバーへの無意識な依存が結果として，組織運営の機能不全へとつながっていったのではないだろうか．

本プロジェクトのお題

作成するアプリについては，以下のようなテーマが与えられた．

  • 「大学以外のある地域または組織の人々の課題」を解決するソフトウェアシステム．
  • 開発するシステムに何らかのDBMSを含めること．
  • 開発するシステムに複数の計算を含めること．
  • 開発完了後，成果発表までに，チーム外の利用者に使用してもらうこと．

作成するアプリの決定

要件定義を行う前に作成するアプリを決めるために各自が作りたい物をブレインストーミングでアイデアを出した．そこで出た案の良い点や疑問点を話し合い，最終的には1人1票の投票で作成したいアプリを決定した．それが，今回作成した「こじゃんとやまっぷ」だ．このアプリの独りよがりな開発を防ぐため，Googleフォームを用いた市場調査を実施し，大学生や地域住民からの調査結果を基に，解決すべき課題と解決策を結合させ要件を固めていった．ただ「イシューからはじめよ」という本を読んだ私からすれば「何を作りたいか」ではなく具体的な課題といった「何が問題か」という方面からアイデアを考えたいという思いがチームメンバーに言えない中で自分の中で強く響いていた．この時に私は「この開発で後悔が極力無いように自分が思ったことはとりあえず言う」という方向に舵を切ることを決意した．また，一度だけ5時間を超える会議が発生したこともこの方向性を決意した一因となった．当時の司会者は，全員が同じ方向性を向くまで話し合いを終わりたくないという考えだったらしいが，私として必要最低限の時間で効率を高めたいという思いが強かった．これらの思いや感情が強くなりそれ以降は会議の進め方も私主導で始まった．当時はそれで満足だったのだが，会議の短縮と効率化を推し進めてしまった結果，チーム開発が進んでいく毎にチーム内での共通認識がずれてしまったのではないかと思っている．

システム提案書

作成するアプリが決まった後は，どのようなシステムや機能を作成するのかを文書化するためにシステム提案書を作成した．ここで，文書を共有する際にGitHubを用いることにした．実装をする際に必要不可欠であるGitHubの扱い方を皆に覚えてもらうためだ．また，バージョン管理を用いることでファイルが消えてしまったなどの不測の事態に備えるためというのも理由の1つである．班員が各自の担当したTexファイルを作成し，それをGitHubにアップロードしてもらった．ここで，ブランチ戦略やプルリクエストの存在意義を体感してもらうと同時に私にとってもGitHubの扱い方を単なる知識から実際の体験に昇華することができたのは，非常に良い経験だと感じた．

システム提案書で作成した文章の一部

外部設計書

外部設計書では，システム提案書で考案した機能を実装するためにそれを深堀りし，システムとしての挙動を定めた．この段階では特に問題はなく，新しい試みとしてDockerを用いてLatexの環境構築を行い，誰でもこのリポジトリ内でコンパイルを行うことができるようにすることで作業をより行いやすくした．そして，GitHub Projectを用いたタスク管理を導入した．Notionなどの外部サービスを用いてタスク管理を行うことも検討したが，一つのサービスで完結した方が情報が分散しないと考えたためである．これに関しても，誰がどれだけタスクを抱えているのか，どこまで進捗が進んでいるのかを把握するうえでとても便利だと感じた．

外部設計書で作成した文章の一部

内部設計書

内部設計書では，今までのシステム提案書と外部設計書を元に挙動を実装レベルまで深掘りした．この内部設計書の提出日が締め切りがギリギリになってしまい，余裕のある活動を行うことができなくなってしまった．一応，提出日の前に完成日を設けていたのだが，班員たちは「とりあえず，文章を書きあげる」という認識で合ったのに対し，私は「この日に提出できる状態まで進めたかった」という認識の齟齬が生まれてしまっていた．この時点で認識の差を無くすことが最優先であったと深く反省している．また，時間の見積もりについても誤算があったと思う．このころから，次第に雲行きが怪しくなったと感じていた．しかし，サークルやSecHack365といった課外活動，他にも研究室活動や日頃の講義などでこのプロジェクトに対して時間をとって問題を考える暇がなかったため，進行が遅れただけで問題はないだろうと判断し，この些細だが深刻である問題を当時は深く考えることができなかった．

内部設計書で作成した内容の一部

技術とアーキテクチャ設定

内部設計書まで終了し，実装段階に入るため，何の言語を使用するのかを決める必要があった．私としては普通の技術構成では面白くないと考えていたので，モダンな技術を使用することで技術的な面白さと私自身の知見をさらに広げようと考えた．今回開発するサービスの特性上，大量の非同期処理を行うことが予想できていた．そのため，バックエンドではGoroutineにより並行処理が容易かつ高速なGo言語を採用し，フロントエンドでは近年のWeb開発の主流であるNext.jsを採用した．しかし，これらの技術は大学の講義で扱わないのに加えて，開発期間が短く，学習時間が中々取れないために班員に高い学習コストを押し付けてしまった．技術選定においては技術的なメリットだけでなく，チームメンバーの習熟度や学習曲線とのバランスを考慮すべきだったと感じている．

今回，使用した技術構成図

実装と結合

実装フェーズへと移行したものの，未だにAPIの仕様が存在していなかった．私は，フロントエンドとバックエンド両者の共通言語となるAPIの定義を作成することを優先した．これをSSOT(Single Source of Trust: 信頼できる唯一の情報源)とするために，内部設計書で作成したビジネスロジックやコーディング規約等の実装をする上で必要な情報を一元化しようと考えていた．APIの定義だけでは，Swagger等を用いた方がはるかに効率が良いのを分かっていたためだ．しかし，それを作成するための十分な時間が存在しなかった．そこで，最低限のAPI定義のみを記述し，コーディングに移ることにした．すでに残された期間が3週間弱しか無いという緩やかな絶望が向かってきていたためだ．この絶望的な期日に間に合わせるため自力での実装にこだわらず，AIコーディングエージェントを用いることで開発の高速化を行った．さらにレビューでは，フロントとバック両方にある大量のファイルを高速かつ精査するためにAIコードレビューサービスのCodeRabbitも導入した．この戦略は功を奏し，開発速度は劇的に向上したのが目に見えて理解できた．しかし，新たな問題も発生した．実際に作成されたファイルの中身を理解することができていない「理解の負債」が積みあがっていた．アプリが動作しているのは分かるが，どのファイルがどのように作用しているのかが誰にも分からない．コードのブラックボックス化が進行しているのを時間がない私たちは見ていることしかできなかった．さらに致命的だったのは，チーム全体での定例会議を設けていなかったことである．時間がなかったこと，疑問が浮かんだら質問してくれるだろうという考えが実際は，疑問を質問にすることができないという問題が水面下で発生しており，各人が孤立したまま問題を抱え込むこととなった．進捗確認の機会がなく，誰がどこまで進んでいるのかが不透明な状態が続く．そのツケは，プロジェクトの最終局面の結合テストで一気に発覚した．想定していた機能が未完成であったり，APIが未実装であったりなどプロジェクト全体の足並みが揃っていないことが露呈したのである．私は，デモに必要最低限以外の機能全ての開発を中断するという方針をとることでプロジェクト全体を立て直そうと試みた．しかし，私自身にも試練が舞い込んだ．研究室活動である輪講の発表担当とSecHack365の修了発表会である．研究室の輪講参加者とSecHack365のチームメンバーに迷惑をかけるわけにはいかないため，一時的に開発をチームメンバーに託し，両者を最優先として取り組んだ．これらのタスクを何とか切り抜け，プロジェクトに戻ると結合テストが何とか無事に終了していた．この時の私は，チームメンバーに感謝してもしきれなかった．

最終発表会

チームの尽力により開発を終えることができた私たちは，無事に最終発表の日を迎えた．作業範囲の削減により最低限の機能しか動作しなかったが，デモ本番の時にアプリケーションは無事に動いてくれ，安堵したことを今でも覚えている．

チーム開発で発生した課題

今回のチーム開発の問題点として，一番に挙げられたのは認識の齟齬だった．その理由として，話し合う環境が少なかったことや気軽に質問できるような環境ではなかったことだ．Slack等のコミュニケーションツールは存在していたが，質問をする際に何が聞きたくてどのような答えが欲しいのかを明確にする必要がある．しかし，分からないことが分からないからどうやって質問の仕方そのものが分からないといった場合に関しては，Slackでの質問をする難易度が劇的に上がった．質問をする側もなかなか質問できず，質問に答える側も気づくこともできずに対応が遅れた結果としてアプリの完成自体も遅れてしまった．他にも，フロントエンドとバックエンドで人員が分断されていたため，全体での共有をする際に個人的に聞くか全体会議で議題に挙げるしかなかったのが問題だと考えられる．また，各人のスケジュールを全体で共有しておらず，そこでタスクが溜まっているのに作業できる人が少ないなどの問題が発生していた．
さ

振り返り

今回のチーム開発において，私はソフトウェア開発においての開発体験と新しい技術の導入ばかり考えてしまったため，組織での一番大切なコミュニケーションを疎かにしてしまった．今回の開発では，コミュニケーションの重要性を充分理解したため，今後チーム開発を行うときには組織内でのコミュニケーションを密に取りたい．

Discussion