目次

1. はじめに
 2. 期間
 3. ルール
 4. メンバー構成
 5. 開発の流れ
 6. 振り返り

1. はじめに

私は現在、内定直結型のエンジニア実習 「アプレンティス」 に3期生として参加しています。
未経験からエンジニアを目指していて少しでもアプレンティスに興味がある方はチャレンジしてみることをおすすめします！とても貴重な経験ができると思います！

そのアプレンティスに参加する中で、課題の一つとしてチーム開発を行うことになりました。チーム開発は、3人（もしくは4人）で一つのチームを組み、後述するルールに基づいて一つのウェブアプリを制作するというものです。最終日に各チームが制作物のプレゼンを行い、受講生とメンターは最も良かったと思うチームに対して投票を行います。
投票の結果として、受講生からの評価が最も高かったチームには「Best Student Award」、メンターからの評価が最も高かったチームには「Best Award」が授与されます。

チーム開発期間中は、色々と課題が山積していて途中どうなることかと思いましたが、チームメンバーと協力し合いながら課題を一つずつ解決していきました。そして、あっという間に最終日を迎え、全チームのプレゼンが終了し、投票の結果、、、
なんと、私たちのチームは「Best Student Award」を受賞することができました！！
チームメンバー全員の頑張りが報われた気がして、とても嬉しかったです！

前置きが長くなりましたが、本記事では、チーム開発で学んだことを私なりに整理し、開発に取り組む中で意識したことや、改善点をまとめたいと思います。

2. 期間

チーム開発は、以下のスケジュールで行いました。

期間	内容
12/11(月) - 12/24(日)	アイデア決め
12/25(月) - 1/7(日)	スライド作成、要件定義
1/8(月) - 1/21(日)	設計、タスク出し、環境構築
1/22(月) - 1/28(日)	実装、プレゼン準備
1/28(日) 19:00 - 21:00	プレゼン

上記の通り、開発物の実装は1週間で行わなければならなかったので、実装週までにいかに準備を整えられるかがポイントでした。

3. ルール

下記ルールに基づいてチーム開発を行いました。

『自分たちの役に立つものを開発せよ』がテーマ
使用可能な技術は、HTML/CSS/JavaScript/MySQL/Ruby or PHP のみ　※フレームワークは使用禁止
ローカル（手元のPC上）で動くようにする
プレゼン時間は3分

4. メンバー構成

チームメンバーは私を含め、以下の3人でした。

チーム最年長のFさん。アプレンティスへ参加する以前にプログラミングスクールへ通っていた経験があります。チーム開発も経験していたため、開発を進める上でとても頼りになりました
私と同じく会社員として働きながらアプレンティスに参加しているGさん。仕事との両立はかなりハードだったと思いますが、積極的に開発に参加して下さいました
そして私。会社員として働きながらアプレンティスに参加しています。仕事内容がかなり特殊で勤務中に待機時間があるため、仕事中にもちょくちょく開発をすることができました

私たちのチームは、メンバー全員が実務未経験でした。さらに、私とGさんはプログラミングの経験自体もそこまでなかったため、チーム開発が始まった当初は、本当にこの短期間でウェブアプリを制作することができるのかとても不安に思っていました。

5. 開発の流れ

この章では、私たちのチームがどのように開発を進め、どのような課題に直面し、どのように課題を解決したかをできるだけ具体的に書いていきます。加えて、反省点や改善点についても記述します。

1. 12/11(月) - 12/24(日)　自己紹介/アイデア決め

1-1. 自己紹介

初回のミーティングでは、まずお互いに自己紹介をした後、雑談をしました。アプレンティス主催者の山浦さんから、雑談でお互いのことを知ることで、その後の開発がスムースに進むという話を伺っていたので積極的に会話に参加するようにしました。ここで雑談したことによって、お互いに「全く知らない人」から「少し仲良くなった人」に状況が変化したのはとても良かったと思います。

1-2. ミーティング頻度/日時決め

ミーティングの開催頻度と日時についても決めました。
まず開催頻度については、チーム内に会社員が2人いたこともあり、3回以上は負担が大きく、1回では少なすぎるという判断から2回に決めました。
日時については、まず休日の関係から日曜日に開催することを決め、その後に開催間隔がなるべく均等になるように水曜日に開催することを決めました。
結局、1日を除いて（私の仕事の都合です）この開催頻度と日時は実装週まで変わらなかったので良いバランスで決めることができたと思います。特に、開催日時を固定することによって、後述するプロジェクトマネージャーのタスク管理とミーティングの準備がやりやすくなったと感じています。

1-3. プロジェクトマネージャー決め

プロジェクトマネージャーというのは、その週のチーム開発のゴールを定義し、チームメンバーに役割を割り振り、進捗を管理する人のことです。プロジェクトマネージャーは持ち回り制で、2週間ごとに人が変わります。
初週はFさんが務めてくださることになりました。

1-4. アイデアの持ち寄り

最後に、次のミーティングまでに制作物のアイデアを持ち寄ることに決めて初回のミーティングは終わりました。

良かった点

自己紹介と雑談でメンバーの仲を深めることができた
ミーティング開催日時を固定することができた

改善点

今後のチーム開発の進め方や役割について、初回のミーティングの時点でもっと話し合っておくべきだった

1-5. Notionの導入

2回目以降のミーティングでは、Fさんが万能ツールアプリ Notion を利用して、チーム開発のタスクを管理するスペースを作成してくださいました。Notionは多機能で自由度が高い分、最初は操作に苦労しましたが、頻繁に触れるうちに操作にも慣れてきました。操作に慣れてからは、タスク管理における大抵のことがNotionで完結するのでこんな便利なものはないと思うようになりました。もし、タスク管理にどのツールを使うか迷っている方がいればNotionを試してみることをおすすめします！

1-6. アイデア出し/選定

制作物のアイデアを決める際は、まずメンバーが持ち寄ったアイデアを系統ごとに列挙しました。そのうえで、制作物を決める際の方針について話し合いました。話し合いの結果、「自分たちの得意分野と関連があるもの」という意見や「作っていて楽しいもの」という意見が出ましたが、最終的に「プレゼン時の評価が高そうなもの」を選ぶことに決まりました。
以下は、私が制作物を選定する際に注意したことです。

同じ機能を備えている類似アプリはないか
類似アプリがある場合は差別化を図れるような機能を追加できるか
アプリ自体にわくわく感や目新しさがあるか

上記の基準で考えると、既に類似アプリが多数存在しているタスク管理アプリやメモアプリは差別化を図ることが難しいという理由で候補から外し、アプリ自体にわくわく感や目新しさがないものも候補から外しました。
最終的には、オリジナリティーが出せるものとして、メンバーが提案した「勉強系」アプリを制作することに決まりましたが、上記の選定基準をすべて満たしていたため異議なしでした。

1-7. 要件定義/制作物決定

その後、候補を以下の2つまで絞り、その2つに対して必要な機能を全て洗い出す「要件定義」を次週から前倒しで行いました。

OpenAIのAPIを利用して問題を自動生成する勉強アプリ（Webで実行できるようにする）
プログラミング関係の単語や文章が出題されるタイピングゲーム

以下は、要件定義で洗い出した機能です。

そして、要件定義で洗い出した機能が実現可能かをメンバー各々で調べた結果、候補1のアプリは、Webで実行できるようにするハードルが高いことやOpenAIのAPIを利用するのに料金がかかるという理由で候補から外れました。最終的に候補2の「プログラミング関係の単語や文章が出題されるタイピングゲーム」を制作することに決まりました。

良かった点

Notionを導入したことで、効率的にタスクを管理できるようになった
制作物のアイデアについて、様々な視点から考察することによりオリジナリティーのあるテーマを選ぶことができた

改善点

（個人として）良い制作物のアイデアを出すことができなかった。プログラミングに対する単純な知識不足とリサーチ不足が原因だと感じている。今後はプログラミングの経験を積み、日常生活で思いついたアイデアを逐一書き留めるようにしたい
要件定義での機能の洗い出し方が甘かった。今後は大きな機能だけでなく、細かな機能についても洗い出すことが必要だと感じた

2．12/25(月) - 1/7(日)　スライド作成/要件定義

2-1. タスク管理/ガントチャート作成

この週から私がプロジェクトマネージャーを務めることになりました。
私は1回目のミーティングの前に、この2週間でやりたいことをNotionにまとめ、それを基にガントチャートを作成しました。
これを行ったのには次の狙いがあります。
第一に、タスクの見える化をし、この週に解決すべき課題を明確にすること。
第二に、進捗管理を徹底することで、いつまでに誰が何を行うのかを明確にすること。
以下は、Notionへまとめた内容を簡略化したものです。

1回目

制作物のデザインイメージの統一化（かっこいい形、ポップ系、かわいい系等） ⇒　スライド全体のイメージを決める
背景、課題、コンセプトを明確にする　⇒　それを基に伊藤がスライドを作成する
要件定義を完成させる　⇒　「必須で実装する機能」「時間に余裕があれば実装する機能」「実装しない機能」を明確にする
発表時のデモで実践することを明確にする　⇒　それを基に伊藤がデモストーリーをテキストベースで作成する
制作物の名前を決める　⇒　キャッチーな名前を付けることでユーザーにインパクトを与えたい

2回目

伊藤がスライドとデモストーリーのたたき台をメンバーに共有する
全員でこうした方がもっと良くなる等の修正案を出し合う
修正案を基に伊藤がスライドとデモストーリーを修正する

3回目

伊藤が修正したスライドとデモストーリーをメンバーに共有する
全員でさらなる修正案を出し合う
修正案を基に伊藤がスライドとデモストーリーを修正する

4回目

伊藤が完成したスライドとデモストーリー共有をする
次週に向けての話し合い

以下は、作成したガントチャートの一部です。

2-2. スライド作成

1回目のミーティングは上記予定通り進行し、スライドを作成するための要素がほぼ全て出揃ったので、2回目のミーティングまでにはスライドの大部分を完成させることができました。
私はスライドを作成するのが初めてだったので、YouTube動画やWebサイトでパワポについて勉強しながらスライドを作成しました。
以下に、スライドを作成する際に意識したことをまとめます。

1スライド1メッセージで作成する
課題とコンセプトを明確にする
デモストーリーはテキストベースでスライドに書き起こす
制作物に合わせたデザインにする（フォント、画像、アニメーションなど）
強調したい部分は文字に色を付けるのではなく、フォントサイズの強弱によって表現する
頭の中でスライドを四角形のブロックに分け、そのブロックごとに文字や画像を配置する
常に聞き手のことを意識する

上記の点を意識してスライドを作成したことで、メンバーに共有した際も大きな修正案は出ませんでした。
スライドを早めに作成したことで、制作物のイメージの共有が早めにできたことは後の開発においても良い影響があったと思います。

以下は、作成したスライドの一部です。　※念のためメンバーの名前は隠してあります

アニメーションを設定したスライドもあります

画像や文字は必要最小限にとどめました

デモストーリーもテキストベースで書き起こしました

2-3. 要件定義のブラッシュアップ

この週では、前週に前倒しで行った「要件定義」を、さらに細かく「必須で実装する機能」「時間に余裕があれば実装する機能」「実装しない機能」に分ける作業を行いました。
以下は、Notionにまとめた内容です。

この作業で特に意識したことは「プレゼン時のデモで発表しない機能は実装しない」ということです。今回の私たちのチームの開発方針はあくまでも「プレゼンで評価される制作物を作る」だったので、無駄な機能は極力実装しないようにしました。ただし、これには良い面と悪い面があると後に気づきました。
良い面としては、実装の効率を最大限高められることが挙げられます。プレゼンに焦点を当てることで不必要な作業を省くことができるからです。
反対に悪い面としては、効率を求めるあまり、技術的にチャレンジすることが少なくなってしまうということです。私たちの例でいうと、最初はDockerで環境構築を行う予定でしたが、時間を浪費する可能性があるという理由で断念しました。また、MySQLでデータベースを作成する予定でもいましたが、今回は必ずしも必要ない機能ということで「時間に余裕があれば実装する機能」に割り振りました。フロントエンドとバックエンドの連携を学べる貴重な機会でしたが結局実装しませんでした。
今回のチーム開発では、Best Student Award を取ることができたので私たちの選んだ方針を決して否定するつもりはありません。しかし、成功の裏には上記のような反省点も多々あるということを肝に銘じておかなければならないと思いました。

2-4. プロジェクトマネージャーを務めて

兎にも角にも、今回プロジェクトマネージャーを経験したことにより、タスク管理の重要性を再認識するとともに、チームをマネジメントする面白さを実感することができました。また、制作物のイメージがより明確になったことで、チーム開発に対する意識が前週よりもさらに高まった気がします。

良かった点

初めにガントチャートを作成したことにより、タスクの見える化と進捗管理をすることができた
発表時にそのまま使用できるクオリティのスライドを早めに作成したことにより、制作物のイメージや方向性を早めにメンバーと共有できた
「必須で実装する機能」「時間に余裕があれば実装する機能」「実装しない機能」を明確にしたことにより実装時の迷いを取り除くことができた

改善点

作業効率を求めた結果、高度な技術への挑戦ができなかった。今後は多少リスクを冒してでも未知の事柄に挑戦していきたい
（個人として）プロジェクトマネージャーとしての責務を果たそうと気負いすぎるあまり、メンバーにあまりタスクを振ることができなかった。今後プロジェクトマネージャーを務める際には、チームとしての視点を持ち、チームの利益が最大になるようなタスクの割り振りをしたい

3．1/8(月) - 1/21(日)　設計/タスク出し/環境構築

この週は順番通り、Gさんがプロジェクトマネージャーを務めることになりました。
制作物の設計に関することはこの週で全て終わらせるため、会社員として働きながらチーム開発に参加しているGさんには負担が大きいのではないかと心配しましたが、Gさんの頑張りによってその心配は杞憂に終わりました。

3-1. タスク管理

Gさんは前週の私と同様、1回目のミーティングの前までに、この2週間でやりたいことをNotionにまとめてくださいました。
以下は、その内容を簡略化したものです。

1回目

業務フローの共有
画面遷移図の共有
ワイヤーフレーム素案の共有
テーブル定義書の共有
技術アーキテクチャの共有

2回目

ワイヤーフレームの修正（適宜）
環境構築（GitHubリポジトリ）
タスク出し（タスクの洗い出しと担当の割り振り）
テーマ

3回目

タスク共有（担当それぞれでタスクの見積を共有）

4回目

実装のスケジュール確認（担当部分についてガントチャートを作成）
実装の進め方について

3-2. 設計資料についての話し合い

１回目のミーティングでは、Gさんが作成した各資料に対して意見を出し合いました。以下は、各資料の役割と話し合いの結果です。

業務フロー
登場人物ごとに業務（行動）の流れを図にします。

今回は登場人物が「ユーザー」のみで、行動は「ゲームをプレイする」のみだったので、業務フローは作成しませんでした。

画面遷移図
必要なページを洗い出して、ページの流れを図にします。
FigmaやMiroなどのツールを使って作成します。

今回は、「トップ」→「設定」→「ゲーム」→「結果」というシンプルなものになりました。

ワイヤーフレーム
ページごとにワイヤーフレーム・機能・データをまとめます。
本番のレイアウト通りに文字だけでページを作成するイメージです。

今回はGさんが作成したワイヤーフレームの出来が良かったので、「制限時間部分を爆弾と導火線を使って表現する」や「問題の背景に映像を流す」などのより踏み込んだ内容について話し合うことができました。

テーブル定義書
データベースのテーブル構成を定義します。

今回は簡易的なテーブルを作成しましたが、実装時には使用しませんでした。

技術アーキテクチャ
使用する技術構成を決めます。

今回は「ローカルPC」「フロント：HTML/CSS/JavaScript」「Webサーバー：PHP」「DBサーバー：MySQL」で構成しました。

3-3. ゲームテーマの選定/BGM・SEの導入

2回目のミーティングでは、事前にメンバーがそれぞれ用意したゲームのテーマ（プレイ画面の背景など）を持ち寄りました。その結果、私が用意した「ドット絵を使用したRPG風のゲーム」が採用されました。私がこのテーマを選んだ理由は以下になります。

実際に自分が遊んで楽しいゲームは何かを考えたときに、RPGが真っ先に思い浮かんだ
ドット風の背景にすることにより、ゲーム感をより出せると思った
制作物のコンセプトの一つである「クイズ」との相性が良いと考えた

加えて、私は制作物にBGMとSEを導入するように提案しました。これは、アプレンティス2期生が制作したゲームの講評で、メンターの方が「音を使用するとより良いものになる」とおっしゃっていたことを参考にしました。結果的にBGMとSEを導入したことによって、よりキャッチーで楽しい雰囲気を演出できたので、導入したのは正解だったと思います。

3-4. デザインカンプの作成

また、私は「デザインカンプ」の作成も提案しました。実装するページのレイアウトを本番通りに作成することで、実装時に何をどのように実装するのか迷わなくて済むと考えたからです。最初、作成にはデザインカンプ専門ツールを使用しようと思いましたが、パワポでも作成できそうだったので、最終的にはパワポを使用しました。そして、作成したデザインカンプをメンバーに共有したところ、「何を実装すればよいか明確になった」や「ウェブアプリを作るうえでデザインカンプはやっぱり必要」といった声をいただけたので作成した甲斐がありました。
以下は、作成したデザインカンプの一部です。

トップ画面

難易度設定画面

言語設定画面

プレイ画面

得点表示画面

詳細解説画面

3-5. 実装時の担当タスクの割り振り

さらに、Gさんが事前に考えてくださったタスクの割り振り案を基に、実装する機能単位で担当者を決めました。タスクの割り振り方法としては、フロントエンドとバックエンドで分けるという考え方もありました。しかし、アプレンティス生の最終目標はフルスタックエンジニアになるというものだったので、最終的には、フロントエンドとバックエンドを全員が一通り経験できる機能単位でタスクを割り振ることに決まりました。

3～4回目のミーティングでは、メンバーごとに担当タスクの詳細をNotionに書き出しました。以下は、書き出した項目です。

「タスク」: 何の技術を使って、何を実装するのかを詳細に書き出す
「目安時間」: タスクの実装にどのくらい時間がかかりそうかの見積もりを出す　
※何かしらのトラブルが起こった場合に備え、見積もり時間には余裕を持たせる
「優先度」: タスクの優先度を「高」「中」「低」で設定する
「ステータス」: タスクの進捗具合を「停止中」「進行中」「完了」のいずれかで表す
「日付」: タスクを実装する日付を設定する
「オーナー」: タスクの所有者を表示する

上記項目をNotionの表にまとめると、自動で「ガントチャート」や「ボード」が作成されるので、タイパがかなり良かったです。Notion最高です！
以下は、Notionにまとめた内容の一部です。

ガントチャート

ボード

以上のことを行ったうえで実装週を迎えることになりました。
メンバー全員がプロジェクトマネージャーとしての責務をしっかりと果たしたことで、総合的に良い準備ができたと思います。

良かった点

「業務フロー」「画面遷移図」「ワイヤーフレーム」「テーブル定義書」「技術アーキテクチャー」を作成し、それを基に話し合うことができた
実装時の担当タスクを細かく分割してNotionにまとめることにより、タスクの見える化ができ、進捗確認が容易になった
（個人として）ゲームテーマのアイデアやBGM・SEの導入、デザインカンプの作成を提案し、チームに貢献することができた

改善点

テーブル定義書の詰めが甘かった。それは、データベースを「余裕があれば実装する機能」に振り分けていたからでもあるが、データベースはウェブアプリを作るうえでの基礎となるものなので、今後は必ず実装するようにしたい
（個人として）担当タスクの見積もり時間が、実際の時間と大幅にずれてしまう箇所があった。これについては、プログラミングの経験不足が原因だと思うので、今後はプログラミングの経験を積み、自分の能力を的確に判断できるようにしたい

4．1/22(月) - 1/28(日)　実装/プレゼン準備

この週では実際にコードを書いて、前週までに準備した機能を実装していきました。
この章では、実装時に私が取り組んだことやその中でぶち当たった課題などについて記述します。

4-1. 担当タスク

私が担当したタスクは以下になります。

ロゴの作成
トップ画面の作成
設定画面（難易度選択画面、言語選択画面）の作成
プレイ画面の背景アニメーションの作成
（追加）サウンドのON/OFF制御
スライドの修正

4-2. ロゴの作成

今回、ロゴの作成にはCanvaというグラフィックデザインツールを使用しました。ロゴの作成以外にもデザインに関する様々な機能があるのでぜひ利用してみてください！

今回作成したロゴは以下になります。

ロゴの構図はテンプレートを参考にしました。
色合いは楽しく、ポップな感じをイメージして、カラフルに仕上げました。
また、「ふぁん×くいず」だけだと何のゲームかイメージしにくいと思ったので、その上に「Function×Quiz」と載せることにより、関数のクイズゲームだということが一目でわかるようにしました。

4-3. トップ画面の作成

以下は実際に作成したトップ画面です。

プレイボタンにホバーするとフォントとデザインが変わります。

右上のボリュームアイコンと設定ボタンの歯車はFont AwesomeのCDNを利用しています。
フォントはGoogle FontsのCDNを利用し、丸みを帯びたポップな字体を設定しています。
プレイボタンは立体感と光沢感が出るように、CSSのborderプロパティやlinear-gradient関数を使用するなどしてデザインしました。
両端のキャラクターは、プレゼンの直前に思いつき設置したものですが、面白みのない配置やアニメーションになってしまいました。デザインカンプ作成時にもう少し詰めて考えておくべきだったと反省しています。

4-4. 設定画面の作成

以下は実際に作成した設定画面です。
モーダルウィンドウ風のデザインにしました。

難易度設定画面では各ボタンにホバーすると、ボタンの色がグレーに変わり、淵に色が付きます。その状態で決定ボタンをクリックすると、難易度が確定します。

言語設定画面では各ボタンにホバーすると、アイコンに色が付き、少し拡大して表示されるようにデザインしました。

上記デザインと処理はHTMLとCSS、JavaScriptの基本的なコードで実装しました。とは言っても当時の私には難易度が高く、実装にかなりの時間がかかってしまいました。しかし、この処理に時間をかけて取り組んだおかげでJavaScriptに対する理解が深まったことは大きな収穫となりました。

4-5. プレイ画面の背景アニメーションの作成

プレイ画面の背景アニメーションは実装当初、画像が徐々に拡大していくアニメーションのみを想定していました。
しかし、メンバーからの提案により、画像によっては横に移動するアニメーションを作成した方が良さそうということだったので、そのアニメーションも追加で作成することにしました。

以下は、徐々に拡大するアニメーションを設定した背景画像

以下は、徐々に左へ移動するアニメーションを設定した背景画像

アニメーションの作成は初の試みとなりましたが、JavaScriptのコード自体は比較的シンプルに作成することができました。
しかし、JavaScriptでアニメーションを作成したはいいものの、CSSで設定した幅と高さの範囲内にのみアニメーションを適用させることに苦労しました。
結果的には、overflowプロパティの値をhiddenに設定するだけで解決したのですが、知識の有無によって作業効率が大幅に変わるということを再確認した出来事でした。

4-6. サウンドのON/OFF制御

サウンドのON/OFFに連動して、右上のボリュームアイコンが切り替わるようにコードを記述しました。

OFF時

ON時

今回作成したサウンド制御はとてもシンプルなものですが、ユーザビリティを考えると、BGMとSEそれぞれの音量調節ができるとなお良かったと思います。

今回、私が担当したタスクは、主にフロントエンドの実装でした。実装を通して、自分が考えたデザインを具現化する楽しさを感じるとともに、フロントエンドの奥深さを思い知らされました。

良かった点

Font Awesome や Google Fonts を使用し、制作物をキャッチーなデザインにすることができた
プレイ画面の背景画像にアニメーションで動きをつけるなど新たな技術に挑戦することができた

改善点

実装を進めるうちに、デザインカンプで作成したデザインではカバーできない部分が出てきた。今後デザインカンプを作成する際は、デザインについてより熟慮する必要があると感じた
デザインの引き出しの無さを痛感した。今後は様々なウェブサイトを訪問し、良いと思ったサイトをNotionにまとめようと思う

6. 振り返り

今回のチーム開発では、上記の通り数多くのことを学ぶことができました。
フロントエンドの技術はもちろんのこと、Notionを利用してのタスク管理やパワポを利用してのスライド・デザインカンプの作成など新たな知識を身に付けることができました。その一方で、作業効率を求めすぎるあまり、新しい技術への挑戦に消極的になってしまったことなど反省点も多いです。次のチーム開発では、諸々の反省点を活かし、より良い制作物が作れるよう尽力したいと思います。

ここまで読み進めていただき、ありがとうございました！