2回目のチーム開発で学んだこと

目次

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

1. はじめに

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

そのアプレンティスのカリキュラムの一つとしてチーム開発があります。
既に1回目のチーム開発は完了しており、今回は2回目の開発となります。
↓1回目のチーム開発の記事はこちら
https://qiita.com/itoh28/items/777faedf64e0cea1523a

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

今回、私のチームは残念ながら賞を受賞することができませんでした。しかし、開発を通してたくさんの収穫や課題を得ることができたので個人的には満足しています。

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

2. 期間

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

期間	内容
2/5(月) - 2/18(日)	アイデア決め
2/19(月) - 3/3(日)	スライド作成、要件定義
3/4(月) - 3/24(日)	設計、タスク出し、環境構築
3/25(月) - 3/31(日)	実装、プレゼン準備
3/31(日) 19:00 - 21:00	プレゼン

上記の通り、開発物の実装は1週間で行わなければならないので、アイデア出しと要件定義、設計をいかに効率的に行えるかがポイントとなりました。

3. ルール

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

• 『ワクワクするものを開発せよ』or『書きたくなる日報システムを開発せよ』がテーマ
• ベースとなる技術は HTML/CSS/MySQL/Rails or Laravel/React or Next.js
• ローカル（手元のPC上）で動くようにする
• プレゼン時間は3分

4. メンバー構成

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

• フロントエンドの実務経験があるSさん。受託開発での仕事をしながらアプレンティスに参加しています。フロントエンド（React、Next.js）の知識が豊富で、開発中にも幾度となく相談に乗っていただきました。とても感謝しています
• 組み込みエンジニアとして働いていた経験があるHさん。数少ない女性の参加者のうちの一人で、データベース設計やAPI設計など開発の肝となる部分を担当してくださいました。積極的に開発に参加してくださりとても頼りになりました
• そして私。会社員として働きながらアプレンティスに参加しています。今回は2回目のチーム開発ということで、1回目の時よりも良いものが作れるように気合いを入れて臨みました。その結果、気合いが空回りしてしまった部分もありますが、積極的に開発へ参加できたのは良かったと思います

前回のチーム開発では、全員が実務未経験だったのに対し、今回は実務経験者が2人もおり、非常に心強く感じました。また、今回はLaravelやReact、Next.jsといったフレームワークを使用できるので、開発するプロダクトに対しての期待感が高まりました。

5. 開発の流れ

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

1. 2/5(月) - 2/18(日)　自己紹介/アイデア決め/インセプションデッキ/要件定義

この期間では主に、自己紹介、ミーティング頻度/日時決め、プロダクトのアイデア決め、インセプションデッキの作成、要件定義を行いました。実装へ早めに入りたかったので、前倒しで開発を進めました。前回のチーム開発で一通りの流れは掴むことができていたので、この期間は比較的スムースに進行できたと思います。
また、タスク管理には前回のチーム開発と同じく、Notionを使用しました。

1-1. 自己紹介

今回も例にならって、まずお互いに自己紹介をしたあと、雑談タイムに入りました。お互いのことを知ることによって開発がスムースに進むということを前回のチーム開発で実感したので、今回も積極的にコミュニケーションを取るように意識しました。

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

ミーティングの開催頻度について、最初に開催日時を固定しない方法と開催日時を固定する方法のどちらが良いかという議論になりました。私は、前回のチーム開発の時に、後者の方法を採用し、タスク管理とミーティングへの準備がしやすいというメリットを感じていたのでそのメリットを伝えた結果、今回も後者の方法を採用することに決まりました。

1-3. プロダクトのアイデア決め

今回は、以下2つのテーマから1つを選択してプロダクトを開発することになりました。

• ワクワクするものを開発せよ
• 書きたくなる日報システムを開発せよ

後者のテーマについて、アプレンティス生は日報を毎日 Discord へ投稿する決まりがあるのですが、投稿をさぼってしまう人が散見される現状があります。そこで、Discord 上で日報を書くことをサポートするシステムを開発してくださいという主催者の想いから今回特別にテーマとして採用されたという背景があります。
そのため、出来が良いものを開発できれば、アプレンティスで実際に運用してもらえる可能性があり、前者のテーマよりも魅力的に感じたので、今回は後者のテーマで開発を進めることになりました。

1-4. インセプションデッキの作成

プロダクトのアイデアが決まった段階で、チームメンバー各々でインセプションデッキを作成し、持ち寄ることにしました。インセプションデッキとは、プロジェクトの全体像を記載し、チームで共有するドキュメントのことで、全体の方向性を共有するための10の質問に対する回答を考えます。開発の初期段階に行うことで、チームメンバーのプロダクトに対する認識を統一することができるので、その後の開発をスムースに進めることができます。

↓以下はインセプションデッキの参考サイトです
https://www.agile-studio.jp/post/apm-inception-deck

今回、メンバー各々がインセプションデッキを持ち寄ったことによって、プロダクトの方向性や開発のスケジュール感、最低限必要な機能の認識等を共有することができました。

1-5. 要件定義

要件定義についてもインセプションデッキと同様に、チームメンバー各々が作成したものを持ち寄りました。その結果、要件定義の抜け漏れ部分をお互いに補完することができました。しかし、裏を返せば、自身の要件定義の詰めが甘いということなので、今後他のプロダクトを開発する際はもっと要件について熟考しなければならないということを痛感しました。

↓以下は作成した要件定義の一部です

良かった点

• プロダクトのアイデアやインセプションデッキ、要件定義について、メンバー各々で作成したものを持ち寄ることにより、抜け漏れ部分を補完でき、よりよいクオリティのものを作ることができた

改善点

• オリジナルプロダクトの開発など、今後一人で開発する機会もあると思うので、要件定義に抜け漏れが出ないよう今まで以上に熟考する必要性を感じた

2．2/19(月) - 3/24(日)　スライド作成/設計/環境構築/タスク出し

この期間は、スライド作成、設計、環境構築、タスク出しを行いました。
一つ一つのタスクが重いので、チームメンバーで分担してタスクを進めました。
本来であれば、上記タスクを3/18までに終わらせたかったのですが、私の仕事の長期出張なども重なり、結局3/24まで取り組むことになってしまいました。
長期出張が決まった時点で全体の学習計画を見直せていれば、予定通り担当タスクを終わらせられていたと思うので、自身のタスク管理の甘さを反省するとともに、今後タスクばらしをする際にはもっと一つ一つのタスクを細かく分解する必要性を感じました。

2-1. スライド作成

スライド作成は私が担当しました。
前回のチーム開発でもスライド作成を担当したので、今回はスムースに作成を進めることができました。
スライドを作成する際に意識したことは以下になります。

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

↓作成したスライドは以下です
https://docs.google.com/presentation/d/1eUQ8_-5STAxiE5_f3DK8kJm-zQY4faiCOCUThRCma1U/edit?usp=sharing

前回はいらすとやの画像素材を使用しましたが、今回は趣向を変えてillust STAMPO（イラスト　スタンポ）というサイトの画像素材を使用してみました。いい感じのスタンプ風の素材がたくさんあるので、いらすとやに飽きた（いらすとやも素晴らしいサイトです笑）という方は使ってみることをおすすめします！

2-2. 設計

設計では、業務フロー、画面遷移図、ワイヤーフレーム、データベース設計、API設計、技術アーキテクチャーをチームメンバーで分担して作成しました。

Sさんは業務フローと技術アーキテクチャー、Hさんはデータベース設計とAPI設計、私は画面遷移図とワイヤーフレーム、デザインカンプを作成することに決まりました。

データベース設計の難しさ

データベース設計についてはプロダクトの根幹をなす部分なので、チームメンバーで意見を出し合いながら時間をかけて修正を行いましたが、後の実装段階に入ってから再度設計を見直す部分が出てきたりと、データベース設計の難しさを再認識しました。データベース設計がうまくできていないとその後の全ての実装に影響が及ぶということを実際に体験できたのは大きな収穫でしたが、同時にデータベース設計に対する理解の甘さを痛感しました。今後もデータベース設計について学び続ける必要性を強く実感しました。

画面遷移図、ワイヤーフレーム、デザインカンプ

前回のチーム開発でもデザインカンプの作成を担当しましたが、その際ツールはPowerPointを使用しました。今回は、より実務に近い形で開発を進めたかったので、Figmaというツールを使用して画面遷移図、ワイヤーフレーム、デザインカンプの作成を行いました。
今回初めてFigmaを使用してみてPowerPointにはないメリットをいくつか感じたので、以下に記します。

• 複数のメンバーが共有ファイルを同時に編集でき、変更がリアルタイムで全員に反映されるため、開発をスムースに進めることができる
• ブラウザ上でアクセスできるため、わざわぜ専用のデスクトップアプリを立ち上げる必要がない
• 幅広いプラグインがあるので機能の拡張性に優れている
• 幅や高さなど細かい部分の設定ができる
• 一度作成したデザインの使いまわしがしやすい
• ページ全体を俯瞰的に見ることができる

↓作成した画面遷移図兼ワイヤーフレーム、デザインカンプは以下になります。
画面遷移図兼ワイヤーフレーム
https://www.figma.com/file/rEmLanJzwGm4YL0ccvFk5x/%E7%94%BB%E9%9D%A2%E9%81%B7%E7%A7%BB%E5%9B%B3?type=design&node-id=0%3A1&mode=design&t=hWE1PxzNmTJtMHcB-1

デザインカンプ　※チームメンバーが作成、修正した部分有り
https://www.figma.com/file/ajlN2eIuHuFzYutLk6ksti/%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%82%AB%E3%83%B3%E3%83%97?type=design&node-id=0%3A1&mode=design&t=a04PgUSVrIc9hfYq-1

今回、画面遷移図、ワイヤーフレーム、デザインカンプを作成してみて、いくつか反省点があったので以下に記します。

• 初めは画面遷移図とワイヤーフレームを分けて作成する予定だったが、最終的には必要な機能を画面遷移図に盛り込む形で、ワイヤーフレームとの兼用ファイルを作成することにした。今思えば、ワイヤーフレームはワイヤーフレーム単体で作成し、機能とデータを各ページに明記することで、そのページでできることと必要なデータをより明確にできたと感じる
• デザインカンプでは各ページを16:9のアスペクト比で作成したが、ページ内の各要素の幅や高さまで正確に設定できれば尚良かったと思う。今回はデザインを作成するのに手一杯でそこまで気が回らなかった。次にデザインカンプを作成する際は、その部分にも気を付けたい
• 今回、ページの配色について模索する中で、一つのメインカラーを選択するとそれに合った色を自動で生成してくれるツールを使用し、その生成結果を基に配色を決めた。しかし、実際にはあまり良い配色とは言えず、チームメンバーに配色を修正してもらう部分がでてきてしまった。デザインカンプ作成中にも配色の違和感は感じていたが、ツールを信用しすぎるあまり配色の変更に踏み切れなかった。配色ツールに限らず今後も様々なツールを使用することになると思うが、決してそれを完璧なものとして考えず、少しでも違和感を感じたら他の案を考えて実行できるようにしたい

2-3. 環境構築

環境構築については、今回SさんがDockerで環境構築を行ってくださいました。前回のチーム開発では、Dockerを使用した環境構築ができなかったので、今回それができたことは今後のためにも良かったと思います。しかし、それはあくまでもチーム単位の話で、私個人として考えるとDockerについての知識不足を感じているので、今後も学習を継続して行っていきます。

2-4. タスク出し

タスク出しについては、Hさんが要件定義を基に一覧表を作成してくださいました。一覧表には、タスクやタスクの優先度、担当者を入力でき、終了したタスクにはチェックを入れられるようになっています。

↓以下はタスク一覧表の一部です。

良かった点

• Figmaを使用して、画面遷移図やワイヤーフレーム、デザインカンプを作成できるようになった。また、そのメリットを理解することができた

改善点

• データベース設計についての理解が甘いことがわかったので、再度学びなおさなければいけないと感じた
• ワイヤーフレームには、ページごとに機能とデータを記載した方が開発がスムースに進むことがわかった
• デザインカンプは、高さや幅など細かい部分もきっちり決めることで実装がより楽になることがわかった
• 今後各種ツールを使用する際は、ツールが出した結果を絶対のものとして考えるのではなく、少しでも違和感を感じたら再考し、新たな案を試すようにする

3．3/25(月) - 3/31(日)　実装/プレゼン準備

最終週は、チームメンバー各自で担当タスクの実装を進めました。
前述したとおり、私たちのチームは日報投稿の補助システムを開発することにしました。
その中で、私の担当タスクは主に、日報未投稿ユーザー表示欄の作成とタスク管理画面の作成でした。
この章では、開発したプロダクトの概要を説明した後に、担当タスク実装時に得た収穫や課題をまとめます。

3-1. プロダクトの概要

今回、開発したプロダクトに実装予定だった機能は、以下になります。

1. 認証機能
2. タスク管理機能（ガントチャートの実装）
3. ストップウォッチ機能（登録したタスクを計測できるようにする）
4. ストップウォッチ計測中ユーザーの一覧表示機能
5. 日報投稿機能
6. 日報未投稿ユーザーの一覧表示機能
7. カレンダー機能
8. 過去の投稿の一覧表示機能
9. 過去の学習時間をグラフで比較できる機能

上記機能のうち、実際にフロントエンドとバックエンドの連携まで実装できた機能は以下になります。

1. 認証機能
2. ストップウォッチ機能
3. ストップウォッチ計測中ユーザーの一覧表示機能
4. 日報未投稿ユーザーの一覧表示機能

↓実装した各機能（ページ）は以下です。
トップページ

新規登録ページ

ログインページ

HOMEページ

タスク管理ページ

日報投稿ページ

投稿一覧ページ

3-2. プロダクトが未完成に終わった要因

今回、全ての機能を実装できなかった要因として、以下が挙げられます。

• １週間という短い実装期間に対して、実装する機能の量を多くしすぎた
• 自身の技術力と照らし合わせて、各機能にどれくらいの実装時間がかかるのか、実装前に判断できなかった
• 機能の優先度の設定が甘かった。コア機能を全員で開発したうえで、その他の機能を実装していくべきだった

今回得た上記の教訓から今後は、以下のことを実践します。

• 自身の技術力と実装期間を照らし合わせたうえで、実装する機能を判断する。そのために、自身の技術力を正確に把握する
• コア機能以外の機能にも実装の優先度を設定し、優先度の高い順に実装を進める。その際、漠然と優先度を設定するのではなく、プロダクトがサービスとして成立するために最低限必要となる機能が何なのかを熟慮する

3-3. 今回の実装を通して得た収穫

1. 新たな機能の導入

バックエンドでは、Laravelのタスクスケジューリング機能やデータベースシーディング機能、フロントエンドでは、Axios、SWR等のデータ取得ライブラリの導入やアイコンのコンポーネント化など、実装を通して新たな機能に挑戦できたのは大きな収穫となりました。

2. tailwind cssでのスタイリング

今回の実装では、tailwind cssを使用してスタイリングを行いました。tailwind cssは初めて使いましたが、既存のユーティリティクラスをHTML要素に直接適用してスタイリングできるので、開発効率を上げることができました。
また、個人的にReact用CSSライブラリのChakra UIが気になっているので、今後挑戦したいと思います。

3. 外部ライブラリ（Frappe Gantt）をカスタマイズする難しさ

今回、タスク管理画面へガントチャートを実装するために、Frappe Ganttという外部ライブラリを使用しました。しかし、Frappe Ganttでは、ガントチャート部分の実装はできるものの、それに連動するタスク登録欄や登録したタスクの一覧表示欄を実装することができませんでした。そのため、上記機能を追加するために、Frappe Ganttをカスタマイズする必要性が出てきました。しかし、今回機能のカスタマイズに取り組んだは良いものの、満足のいく機能を実装することはできませんでした。
そこで、実装できなかった原因を私なりに考察してみました。

• ライブラリのソースコードを理解できていない状態で、カスタマイズを進めてしまった。カスタマイズで実装する機能はあくまでも既存のソースコードの上に成り立つため、ソースコードを理解できていないのに実装を進めるのはそもそも無謀だった
• カスタマイズで追加する機能の設計が曖昧だった。そのため、既存のコードを壊してしまったり、何を実装すればよいのか迷ってしまったりすることが多かった

以上から、外部ライブラリをカスタマイズする際には、ソースコードについての理解と、カスタマイズで追加する機能の設計が必須であることを理解しました。

良かった点

• 外部ライブラリの導入により、新たな機能の実装に挑戦することができた
• CSSのフレームワークを使用してスタイリングを行ったことで、その便利さとメリットについて理解することができた

改善点

• 今後オリジナルプロダクトの開発を行う際は、自身の技術力と実装期間を照らし合わせたうえで、実装する機能を判断する。そのために、自身の技術力を正確に把握する。ただし、新しい技術への挑戦は積極的に行う
• 外部ライブラリをカスタマイズする際は、既存のソースコードの理解と、追加する機能の設計が必須となる

6. 振り返り

この章では、前回のチーム開発と比べて今回成長できた点と今後の課題、チーム開発全体を通しての感想をまとめます。

成長できた点

• フロントエンドでは ReactとNext.js、バックエンドでは Laravelといったように、フレームワークを使用して実装を行えるようになった
• Figamaを使用して設計を行えるようになった
• 設計について、より詳細な部分まで話し合えるようになった
• 複数の外部ライブラリを使用し、開発の効率化を図ることができた

今後の課題

• 要件定義の要件に抜け漏れが発生しないようにする
• 後から手戻りが発生しないようなデータベース設計をできるようになる
• ワイヤーフレームやデザインカンプの完成度を上げる
• Dockerを使用した環境構築ができるようになる
• 実装する機能に正確な優先度を設定できるようになる
• 技術力を上げる
• デザインセンスを磨く

以上、長文となりましたが、今回のチーム開発で学んだことや良かった点、改善点等をまとめました。今回のチーム開発では、プロダクトの実装が中途半端に終わってしまい、正直悔しい気持ちでいっぱいです。しかし、開発を通してたくさんの収穫と課題を得るができたので、総じてとても有意義な時間を過ごすことができたと感じています。今回の経験を活かし、よりよいプロダクトを開発できるように今後も精進していきます。

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