[Best Award 受賞] 初めてのチーム開発で誰かのためになるものを作った話

1. はじめに

本記事では、私が初めてチーム開発をした中で経験したこと、学んだことを書いていきます！

チーム開発ってどんなものなんだろう？と思われている方は特に参考になるかと思いますので、まだまだ未熟な私が書いた記事ですが、最後まで読んでいただけると幸いです🙇‍♂️

また、本記事では、私が開発途中に大事だなと感じた部分を

ポイント

としてまとめてあります。

2. 解決したい課題は？

今回のチーム開発では、テーマが決まっていました。
それは、

「自分たちの役に立つものを開発せよ」

というものです。
ですから、ターゲット,作るものは

• ターゲット： 自分たち
• 作るもの： 何かしらの課題を解決するもの

です。

これらを踏まえた上で、様々なアイデアを出していく中、現在のチーム開発で

チームのみんなが今何をしているかが不透明

という課題がありました。

その原因が、現在私たちが毎日行っている日報の投稿にありました。
日報はDiscordに毎晩投稿するのですが、そこでは他のチームの人たちも同じところに投稿しているため、

• チームメンバーの日報を探すのが大変💦　
  →チームメンバーの進捗が分からない

• SOSを出しずらい💦
  →メンバーの中でピンチの人が分からない

• 過去の日報を探すのが大変💦
  →過去との比較ができない

ということが実際に起こっていました。

そこで、上記の課題を解決するために

「チームでタスクの進捗を管理するアプリ」

を作ることに決まりました。

3.課題は解決できた？

結論から申し上げますと、

チームのみんなが今何をしているかが不透明

という課題は解決できました！

では、どのように解決したのか
それは、以下の課題の原因をつぶしていくことで解決に至りました。

原因1. チームメンバーの進捗が分からない

タスクごとに進捗度バーを作り、その進捗度に応じてバーの色が変化するようにしました。そうすることで、メンバーの進捗が一目でわかります。
また、プロジェクト全体の進捗度も表示することで、チーム全体の進捗も確認できるようにしました。

原因2. メンバーの中でピンチの人が分からない

進捗度が30%以下の場合はバーの色を赤で表示することで、ピンチを一目で分かるようにしました。
こうすることで、他のメンバーもすぐヘルプに入れます。

原因3. 過去との比較ができない

メンバーごとにタスクの管理をしているため、個人の振り返りも簡単にできます。

では、次から実際の開発の話をしていきます。

4. 使用技術

• フロントエンド：HTML／CSS／Javascript
• バックエンド：PHP
• データベース：DockerのMySQLコンテナ
• 開発環境：Docker／Docker compose
• ソース管理：Git／GitHub

今回のチーム開発は、「ローカル環境で動作するものをつくる」ということだったので、インフラの構築は行っていません。

5. 完成したアプリ

いきなりですが、まずは完成したアプリをご覧ください。

今回はとにかく、
「一目で、他の人が何をやっていて、どのくらい進んでいるのかが分かる」
を目指して作りました。

機能は大きく4つあります。

1. チームメンバーのタスクの内容と進捗を確認できる

メンバー全員のタスクとその進捗度を一覧で確認できます。
タスクをクリックすると、さらに詳しいタスクの内容と進捗を確認できます。

2. 自分のタスクを追加できる

左上の今日のタスクを追加ボタンを押すと、新たにタスクを追加できます。

タスクを追加する手順

1. タスク名を記入する　　例）データベース設計
2. 関連するタスクを記入する(複数記入可)　　例）正規化、ER図
3. 関連するタスクの進捗度を選択する　　例）正規化→100%　ER図→0%
4. 任意で、関連するタスクにコメントを記入する　　例）正規化→第三正規化まで
5. タスクの登録ボタンを押して登録

1.で記入したタスク名が一覧画面に表示されます。また、関連するタスクの進捗度を合算したものが一覧画面に表示されます。

3. 進捗度を変更できる

自分のタスクが進んだら、進捗度を変更しましょう。

進捗度を変更する手順

1. 進捗度を変更したいタスクをクリックする
2. 自分が進めた関連するタスクの進捗度を変更する
3. 変更を保存ボタンを押す

変更を反映し、関連するタスクの進捗度を合算したものが一覧画面に表示されます。

4. タスクを削除できる

必要のなくなったタスクは削除しましょう。

タスクを削除する手順

1. 削除したいタスクをクリックする
2. タスクを削除ボタンを押す

6. チーム開発の流れ

ここからは、どのように開発を進めていったかを具体的に説明していきます！

6-1. アイデア決め

先述した通り、今回のチーム開発は　「自分たちの役に立つものを開発せよ」　というものなので、 常にベクトルは自分たちに向けて、何かしらの課題を解決するものを考えました。

アイデア決めはFigJamで行いました。

今回のチーム開発での手順

1. 　ブレインストーミングでアイデアの種を出す
2. 　1.で出たアイデアの種をKJ法で整理(グルーピング)する
3. 　2.でグルーピングされた領域の課題を探る
4. 　3.の課題から解決策を考え、作るものの案を出す
5. 　4.の案から全員で決定する

ポイント

• アイデアで成否の半分が決まる
  →課題とコンセプトは明確か？
• ブレインストーミングでは質より量
  →単語ベースでもいいので、たくさんアイデアの種を出しましょう。そうすることで、新たなアイデアが生まれます。
• 全くのオリジナルアプリではなくていい
  →既存のアイデアに独自の改善点があればOK
  例）今回作ったアプリでは、
  　タスク ⊃ 関連するタスク
  という包含関係(親子関係)を作ることで、タスクごとに何をすべきかが明確になります。

6-2. スライド作成

もうスライド作成するの？と思われた方もいらっしゃると思いますが、
この段階でスライド作成をした理由は、

• チームで作るもののイメージを共有する
• プロダクトがイケていない💦と後から気付くことを防ぐ

ためです。

スライドは、Canvaで作りました。

スライド作成の手順

1. 背景、課題： 最初に背景、課題を明確にすることで、チーム内でイメージの共有ができました。
   

2. プロダクト説明： どのような課題が解決できるのかを簡潔にまとめています。
   

3. デモンストレーション： この時点で、実際に発表する時のデモストーリーも決めました。 そうすることで、優先して実装すべき機能が明確になりました。
   (補足：発表の際のデモは 5. 完成したアプリ のgifアニメーションのような感じでしました。)

4. まとめ： アプリのメリットを再度伝えることで、印象に残りやすくしています。
   

ポイント

• 課題とコンセプトを明確にする
  →チーム内でプロダクトの認識を共有する
• プロダクト説明はデモストーリーまで決める
  →実装すべき機能が明確になる

補足：スライドは、骨格となる部分以外開発途中で、更新していました。

ガントチャート導入

私はこの時チームマネージャーをしていたのですが、まだチーム内でチーム開発の全体的な流れを共有できていなかったので、ガントチャートを作成しました。
その結果、チーム開発の全体像が把握できるとともに、いつまでに何をすべきかが明確になり、 チームメンバーに感謝してもらえました！

6-3. 要件定義

次に、システムとして必要な要件をまとめるために、要件定義を行いました。
目的は、要件定義を行うことでゴールイメージを明確にすることです。
もしこれをしないと、要件が間違っていたり曖昧だと後から修正が大変になります。

今回は、以下3つの要件定義を行いました。

1. 業務フロー

この業務フローは私が作りました！

ポイント

• 登場人物を明確にする

2. 画面遷移図、ワイヤーフレーム

チームメンバーが画面遷移図、ワイヤーフレームをFigmaで作成して下さいました。

完成形

3. テーブル設計

チームメンバーがテーブル設計をして下さいました。

完成形

6-4. タスク出し

実装の前段階として、要件定義で具体化したものを細分化しタスクとして洗い出します。

また、この時に担当を割り振り、私はタスク一覧画面を担当することになりました。

(決まった時はメインの画面ということもあり、実装できるか少し不安でした💦)

6-5. 実装

ついに実装です！😃
ここでは、個人が担当するタスクを進めていきます。
私は、メイン画面の実装(フロント＋バック)を担当しました。

メイン画面実装の手順

1. データベースを構築する
   メイン画面に必要なサンプルデータの挿入、抽出クエリの記入を行いました。
2. HTMLで共通部分の画面を作成
   今回は実装できませんでしたが、評価一覧画面が存在するのでヘッダーやページネーションといった共通部分を作成しました。
3. CSSで共通部分の画面のスタイルを整える
4. HTMLでタスク一覧画面を作成
5. PHPでバックエンドの処理
   PHPでデータべ－スから必要な情報を取得してきます。今回は、PDOを利用してデータをモデル化することで、データを扱いやすくしました！また、トランザクション処理もしました。
6. CSSでタスク一覧画面のスタイルを整える
7. JSで動的なインターフェースの実装
   進捗度によってバーの色が変わるようにしたり、ホバーすると色が変わるようにしました。また、ボタンを押した時のアニメーションのつけ方も教えて頂きました。

実装した機能は5. 完成したアプリをご覧ください。

ポイント

• ひとつづつ機能を実装していく
  →一気にいろんなことを実装しようとすると、手が止まってしまいます！細かく分けて一つ一つ実装していきましょう。
  私は手が止まったら、いつも実装すべきことを紙に書いて、タスクを細分化しています。
• データベースは最初に構築しておくと便利
  →一旦サンプルデータを挿入しておくと、表示する際にイメージがつかみやすいのでおすすめです！

GitHubでの開発手順

1. リモートリポジトリのmainブランチをプル
2. ローカルでブランチを切る
   私は間違ってもmainブランチで作業しないように、プルしたらすぐに
   developブランチへ移動
   →mainをmerge
   →feature/~作業の内容~　ブランチを作成し移動
   →機能を追加
   この流れを体に染みつかせました。
3. ローカルで編集
   ここでは、新たな機能を追加したり、修正を加えたりします。
4. リモートリポジトリにプッシュ
5. チームメンバーからレビューを受ける
   修正があれば再度ローカルで編集します。
   LGTM(Looks good to me)とコメントがあればmainにmergeします。

1~5のサイクルを繰り返します。

ポイント

• GitHub Flow(上記の流れ)をマスターしよう
  →Gitには様々なコマンドがあって私も最初は困惑していました。ですから、まずはGitHub Flow(上記の流れ)に慣れましょう。

6-6. 発表

発表はチームメンバーの方がしてくださいました！
ギリギリまで実装をしていたので、15分しか発表の練習をする時間がなかったのですが、素晴らしい発表をしてくださいました！
本当に感謝です(__)

7. チームの振り返り

チームとしての振り返りを「・良かった点・改善点」と分けてしていこうと思います。

7-1. アイデア決め

良かった点

• ブレインストーミング、KJ法で多くのアイデアが出た
• 自分たちの役に立つアイデアが出た
• 競合の確認をした

改善点

• 本当に自分たちが使うのかと聞かれると、使わないと思うので、本当に使うものをつくる
• 競合のリサーチをもっとするべきだった
  →自分たちのアプリの強みを明確にする

7-2. スライド作成

良かった点

• 背景、課題を共有できた
• 期限を守れた

改善点

• 予め考えていたデモストーリと内容が異なった
  →どこを一番見せたいのかを明確にする

7-3. 要件定義

良かった点

• 実装までに認識のずれをすり合わせることができた
• 期限を守れた

改善点

• 決められた期限(今回は1週間)から逆算して、 絶対に実装するところ と 出来たら実装するところ をはっきりさせておくべきだった
• 画面遷移図、ワイヤーフレームを作る前にしっかりとメンバー間で機能(何ができる？)の共有をするべきだった
  →後から修正するのは大変💦

7-4. タスク出し

良かった点

• GitHubを利用したタスク管理

改善点

• タスクの出し方に規則性を持たせるべきだった
  →皆でタスク出しをしたのでタスクがバラバラだった
• 後からタスクを増やさない
  →後からこれが足りない💦となっていた。次回は要件定義を基に、これを全部やれば完成する！というタスク出しを行いたい。

7-5. 実装

良かった点

• 期日を守れた
• しっかりと動くものを作れた
• 絶対に実装するところ と 出来たら実装するところ を分けることができた

改善点

• もっと密に連絡をとるべきだった
  →報連相大事！
• 自分が実装したところは説明できるようにしておく(特にバックエンド)
  →メンバーごとにできることには差があるので何をしているのか説明できるようにする必要がある

7-6. プレゼン

良かった点

• 練習時間15分とは思えない発表の完成度

改善点

• 実装をもう少し早く終わらせて練習時間を担保すべきだった

反省ポイント

• アイデア出し： 本当に使ってもらえるようなものを考える
  →使われないと意味がない
• 要件定義： 認識のずれを100%なくす
  →作業効率を上げる
• タスク出し： ゴールから逆算してタスクを出す
  →全タスクが完了したら完成を目指す
• 実装： やりすぎくらいの 報連相 を意識する
  →できないことの差を埋める

8. 個人の振り返り

1. アイデア出し

自分で競合を調べる癖をつけたほうがいいと感じた。
競合を調べることで、他にはないものができ、その結果使ってもらえるものになる。

2. 要件定義

FigJam,Figmaなど初めて使うものが多く画面遷移図やワイヤーフレーム作成に少ししか関われなかったので次のチーム開発までに使いこなせるようになる！

3.実装

私が担当していた実装が早めに終わったので、他のメンバーの実装を一緒にすればよかった。私としてはあまり邪魔をしないほうがいいのかな？と遠慮気味になっていたが、自分の成長のためにも進んで実装すべきだった。

9. 最後に

なんと！今回作ったものがプロのエンジニアの方々に評価され、見事
「Best Award」
を受賞しました！
これは本当に嬉しかったです。(本当にチームの皆さんに感謝です)

Webエンジニアを目指し、学習を始めて3ヶ月と15日で始めて自分たちのためになるものを一から作りました。
きっとこれが自分の夢への小さな一歩目になると信じています。
この小さな一歩が後に大きな一歩だったと思えるようにこれからも学習に励んでいこうと思います！

ここまで読んでいただき本当にありがとうございました！