0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

初めてのチーム開発でやったこと&反省点

Last updated at Posted at 2023-12-10

2023/12/03に、APPRENTICE生のハッカソンに参加しました。
APPRENTICEとは

APPRENTICEでプログラミングを本格的に初めて約1ヶ月半でのハッカソン。
結果的に、受賞はできませんでしたが、得るものはたくさんありました。
そこで、今回のチーム開発で反省したこと、どうすれば良かったかを記録しようと思います。
初めてチーム開発をしようとしている方、そして何より未来の自分が、よりよいチーム開発ができるような参考になれば幸いです。

目次

ハッカソンについて
ハッカソンまでに勉強したこと
作成したサービスについて
スケジュール・実施したこと
チーム開発中の問題点
振り返り
次にすること
まとめ

ハッカソンについて

今回のハッカソンのテーマは「自分たちの役に立つものを開発せよ」
フレームワークを使用せず作成することがルールでした。

ハッカソンまでに勉強したこと

言語 勉強期間
PHP/オブジェクト指向 2週間
データベース/SQL 2週間
HTML/CSS/JavaScript 2週間

作成したサービスについて

どんなサービスか

「corette(コレッテ)」自分や人の好みを記録しておくサービスです。
correte.png

coretteのコンセプト

好きも嫌いもポケットに
「前に職場の人の苦手な物聞いたはずなのに忘れちゃった…」
「友達とご飯にいくお店探したいけど、あの人何が好きだったっけ」
なんてこと、日常生活でありませんか?
相手の情報を忘れてるのも失礼な気がするし、確認し直せないなあなんてこと私はよくありました。
それに加えて、前に買った嗜好に合わないものを、もう一回買ってしまうなんて自分の好みすら忘れる始末…。
coretteは、そんな日常の困ったを解決し、自分も周りも喜ぶ買い物を実現する為に作成しました。

スケジュール・実施したこと

APPRENTICEの課題と並行して6週間 + チーム開発に集中する期間が1週間です。
チーム開発は以下のような流れ・期間で進めていきました。

項目 期間
①アイデア決め・深める 11/1
②要件定義 11/2
③設計 11/2~11/3
④タスク出し 11/4
⑤環境構築 11/5~11/12
⑥実装 11/13~12/2
⑦プレゼン準備 12/1~12/3

決めたこと・意識して取り組んだこと

①-1 アイデア決め

日常で困っていることや、欲しいものを挙げていきました。

  • 行った店を記録しておくサービス
  • 家にあるストックを管理するサービス
  • 毎日目標が通知されるサービス
  • 自分の好き嫌いを記録しておくサービス

などなど、様々なアイデアが出ましたが、チームメンバー共通で困っていた、
「人の好みも、自分の好みも忘れちゃうよね」ということを課題にサービスを作ることに決定しました。

①-2 アイデアを深める

インセプションデッキを使用して、チーム内で全体の方向性を共有しました。
現行のサービスでは、以下の2点を課題としました。

  1. 登録情報が多く煩雑
  2. 好き嫌いだけを登録するサービスがない為、情報の確認が難しい

この課題から、シンプルかつ味覚に特化したメモを特徴に、皆も自分も幸せにするお買い物を体験してもらえるサービスにすることを目標にしました。

【意識して取り組んだこと】

役割:書記、進行
ここでは、意見を出しやすい空気作りや、出た意見を深めたいという目的をもっていました。そのため、「そのアイデア面白い!」「どんな機能があったらいいかな」などチームメンバーの意見への理解、深めていけるような反応・質問を意識しました。

② 要件定義

必要な要件の決定し、機能を列挙していきました。

【意識して取り組んだこと】

役割:書記、進行
実装のときに修正が発生しないように、漏れの無い要件定義を意識しました。
その為、チーム会議前に以下のように行動しました。

  • 実際に使うところを思い浮かべながら必要な機能をメモしてみる
  • 今世の中にある類似のサービスを使用して、機能を確認

③ 設計

以下5つを決めていきました。

  • 業務フロー
  • 画面遷移図
  • ワイヤーフレーム
  • テーブル定義
  • 技術アーキテクチャ

【意識して取り組んだこと】

役割:書記、進行
実装時に困らないように、会議をしながら図を作って可視化。
チームメンバーにも見ていただき、漏れが起こらないようにしました。

④ タスク出し

  • チームメンバーの担当タスクの決定
  • タスクの締め切り日を決定

私たちのチームはサービスのページごとにタスクを分けて、チームメンバ-それぞれがフロントエンド・バックエンド・データベースを経験できるようにしました。

【意識して取り組んだこと】

役割:書記、進行
チームメンバー内で、タスクの重さが偏らないように意識し、提案。
また、スケジュールに余裕を持てるような日程調整をしました。

⑥ 実装

【意識して取り組んだこと】

  • デザイン
    デザインを担当することに。他のアプリを参考にしながら以下の視点で考えました。

    1. どのようにボタンを配置すると使いやすいか
    2. アイコンを使用するにあたって、どんなアイコンを選べば使用者に誤解を生まないデザインにできるか
  • プログラム
    自分の担当ページだけではなく全体の動作を見て、計画には入れていなかったが必要な機能の実装などを行いました。
    例)ページリンクで、URLにユーザーIDを受け渡す機能など。
    また、チームメンバーが作成したプログラムを確認し、実装漏れ・CSS崩れの修正を行いました。

⑦ プレゼン準備

実装で手の空いたチームメンバーが、スライドの作成をしてくれました。

【意識して取り組んだこと】

スライドが見やすいか、現在の順番で伝わるかを確認。発表の原稿を作成。
人に伝わるようなものにできるように作成していきました。

チーム開発中の問題点

起こった問題・原因・解決の為にした行動

問題1:スケジュールに遅れが出ている!

原因

① チーム内で役割を明確にしていなかった
プロジェクトマネージャーを明確に決めておらず、進捗管理がうまくできていませんでした。
あらかじめ、チーム内でタスクの締め切りを決めていたものの、それが遅れたときの対応や巻き返し方法を決めていなかったです。
プロジェクトマネージャーを明確にしていなかった為、締め切りの巻き返し方やタスクの優先が各々の判断に任されることになり、チーム内の連携がうまくいきませんでした。

② 各々の作業に透明性がなかった
①でのマネージャーが決められていなかったことにも関わりますが、チームメンバーが今どんな作業をしていて、どこに詰まっているのかが共有できていませんでした。
週2回のチーム会議でしか作業の進捗を確認できず、フォローが遅くなりました。

③ 要件定義の段階で、デザインの詳細を決めていなかった
デザイン案は作成していましたが、余白・フォントサイズを決めておらず、後々修正が必要になってしまいました。

解決の為にした行動

  • 原因①②について
    • マネージャの役割がいないなら、自分が担おうと考えた。
    • 各々のタスクを再度洗い出した
    • チーム会議で、完成させる日から逆算し、いつまでに何のタスクを終わらせるか共有
    • タスクの進捗状況を具体的に日を決めて共有することを提案
    • 各自のタスクがいつまでに終わらなければ、誰がフォローするかを考えて提案
  • 原因③について
    • デザイン案を考えたのが自分だったので、自分でCSSを修正した。

問題2:発表当日本番前にエラーが!

原因

① スケジュールがギリギリで、テストが不十分だった
進捗管理の不十分さがここにも影響。全体を通しての動作確認をするタイミングが遅くなってしまいました。

解決の為にした行動

  • 自分の担当箇所が終了次第、チームメンバーのページの動作確認。
  • エラー箇所、CSS崩れている部分を修正。

振り返り

良かった点

  • エラーが起こった際に解決することができた
    自分の担当しているページ以外も動作を確認し、本番までにエラーを見つけることができました。また、それに対しての修正もすることができたと思います。
  • 問題に対して、何か行動を起こすことができた
    チーム開発の進め方において、問題がありました。それに気付いて、チームメンバーへの働きかけなど、問題を放置することなく解決に向けて行動することができました。

反省点

  • 問題をチームで解決する働きかけができていなかった
    • プロジェクトマネージャーが不明確
      私たちのチームでは、プロジェクトマネージャを明確にできていませんでした。
      それに気付いたとき私は、プロジェクトマネージャ-の役割を担おうとして、行動しました。
      ですが、本当に最初にすべきだったのは役割を勝手に担うことではなく、チームメンバーとこの問題を共有して話し合うことだったと考えています。
      そうすれば、もっとチームメンバーを巻き込んだ進め方ができたのではないかと思います。

    • 動作やデザインの崩れなどの修正点に気付いた時に自分で修正した
      修正点を見つけたときに、「気付いた自分が直せば良いか」と考えてしまいました。修正点があることを共有して、この修正を誰が担うか相談する必要があったと思います。

  • サービスを考える時に「自分たちに今作れるものは何か」で考えてしまった
    自分たちの能力で作れる物という前提で話し合いをしてしまった。もっと自由に、作りたい物に自分たちの能力を追いつかせていく、くらいの気持ちでアイデアを出した方がもっと面白いものができたのではないかと今振り返ると思います。

次にすること

  • チーム内での役割を明確にする
  • 進捗管理は具体的に、正確に
  • 作業の透明性を担保→そのためにどうするかをチームで決める
  • CSSを作るまでにデザインの詳細は決めておく
  • 問題が起こったときは、自分だけで解決しようとせずチームに相談!
  • 自分の技術が不足していても、作りながら技術を伸ばすという気持ちで取り組む!

まとめ

初めてのチーム開発は、本当に勉強になりました。
他のチームの発表を見て、私もこんな風なものを作りたい!と思うと同時に、
ものすごく悔しい気持ちにもなりましたし、反省もたくさんしました。
この気持ちをバネに、もっともっと成長できるように学習していきます。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?