はじめに
アプレンティスというエンジニアの学習サービスのカリキュラムの一環として行われた、同期3人でのチーム開発。この経験を通して得た学びと、直面した失敗談をまとめてみました。
チーム開発に挑戦する方、アプレンティスのカリキュラムに興味がある方の参考になれば幸いです。
アプレンティスについて、気になる方は👇のリンクから概要等見てみてください！
チーム開発の概要と流れ
今回のチーム開発は、 アプレンティスの同期3人が1組 となり、週ごとに定められたフェーズを進めていく形式でした。
具体的には、 「自分たちの役に立つもの」 を開発せよ。というお題のもと、要件定義、設計、環境構築、実装といった工程を各週で完了させ、最終週は開発のみを行う。
そして、その集大成として最終日にはアプリの発表を行う、というようなスケジュールでした。
開発アプリの内容
私たちのチームはStudy Trackという
勉強時間の計測✖️勉強目標の管理
を目的としたサービスを作成しました。
作成理由
アプレンティスでは、毎日の学習時間・学習内容・学習内容の詳細を日報にまとめるルールがあります。
特に勉強時間については、「だいたいこれぐらいかな！」と感覚で入力してしまい、詳細な時間を正確に把握できていませんでした。
また、勉強すべき項目が多すぎて、あれこれと手をつけた結果、 すべてが中途半端になってしまう という問題もありました。
そこで、勉強時間の集計・可視化と学習目標の管理をまとめて行えるツールがあれば便利だと感じ、Study Trackを作成しました。
サービスイメージ
メイン画面
勉強集計画面
タスク追加画面
機能概要
- 学習内容ごとの学習時間の計測
- 学習タスクの管理&優先度の管理
- 計測した学習時間の集計表示(日・週・月)
こだわった点
✅ 画面色などのデザインをなるべく 統一感を重視 しました。
✅ メイン画面(計測画面)に集計情報やタスク情報を表示し、 視覚的に登録内容をわかりやすく表示 するよう工夫しました。
✅ 学習時間の合計をグラフ表示することで、視覚的に勉強時間の推移を 直感的に把握 できるようにしました。
技術選定
- フロントエンド
- HTML
- CSS
- Java Script
- Chartjs(勉強時間のグラフ用)
- バックエンド
- Ruby
- MY SQL
- その他
- Git/Github
- Docker/Docker compose
- VSCode Dev container
アプレンティスでは、素の言語の理解を深めるために、１回目のチーム開発は、フレームワークなしで開発を行います。
チーム開発の中で意識したこと・率先して行動したこと
今回のチーム開発は、まさに「時間との戦い」でした。
実は、私たちのチームはスタート時点でメンバーが一人欠けていて、このままでは
「最終週のチーム開発期間だけじゃ絶対に間に合わない！」
と、危機感を抱いていました。
この状況を打開するため、私が特に意識し、率先して行動したポイントは以下の2つです。
開発環境の早期構築と環境統一
開発環境の構築を要件定義時点で着手しました。
なぜ環境構築を最初の方で行ったこというと、単純に画面作成などの実装を早期に始めたかった点と、相方がWindows、私がMacというOSの違いがあったためです。
OS間の差異による謎エラーが発生した際に時間を取られる可能性もあったため、迷わずDockerの導入を提案し、設定作業に奔走しました。
結果として、この「環境統一」という先手必勝の一手が見事にハマりました。
OSの違いによる理不尽なエラーに悩まされる心配を根こそぎ解消し、すぐに開発作業に突入できるよう準備することができました。この初期投資が、後の開発をスムーズにできたと思っています。
従来のカリキュラムと並行して、Dockerの学習や設定作業を行なっていたため、今思えばとてつもないハードワークでした💦
コミュニケーションの取り方
チーム開発において、私が何よりも重視したのは 「相方を絶対待たせない」 こと、そして 「同じ絵が描けているか、常に確認し合う」 ことでした。
この二つの意識の根底にあったのは、もちろん「時間効率の最大化」です。
特に「考えの共有」に関しては、Discordでのリアルタイム通話はもちろん、Notionを駆使して画像や画面共有をガンガン活用しました。
言葉だけでは伝わりにくいニュアンスも、視覚的に共有することで「ああ、それね！」と一発で認識を合わせることができ、無駄な手戻りを劇的に減らすことに成功し、二人で同じゴールを見据えてタスクをこなすことができました。
失敗したこと・改善していきたいこと
今回のチーム開発で失敗したこと、次回から気をつける必要があることがたくさんありました。特に気をつけたい点として、
- 甘かったスケジュール管理：時間は有限だった
- 不明瞭なAPI設計が招いた手戻りの嵐
- 放置されたコード品質：静的解析ツールやコードレビューの重要性
それぞれ何があったか、改善策をまとめていきます。
甘かったスケジュール管理：時間は有限だった
先ほど「時間効率」について熱く語ったばかりですが、まさかの時間が全然足りないという結末に陥りました。
主な原因は、タスクの 「ざっくり分割」 と 「事細かなスケジュールがない」 ことだったと思っています。
大まかなタスク分けはしたものの、
「これをいつまでに終わらせる！」
という具体的な期日が曖昧だったため、気づけば少しずつ、しかし確実に進捗が遅れていきました。💦
今回の失敗を踏まえて、開発着手前に画面の各機能単位ごとなどで分割したタスクをNotionなどのツールで管理し、隔週で終わらせるタスクに期限を設定し、細かい進捗管理をする必要があると感じました。
不明瞭なAPI設計が招いた手戻りの嵐
設計段階で、フロントエンドとバックエンド間で受け渡すデータの仕様を明確にしていなかったことが、開発中の大きな足かせとなりました。
これが原因で、無駄なコミュニケーションが頻発し、何度も手戻りが発生してしまったのです。
正直なところ、当時の私はAPIの認識自体があやふやな状態でコーディングを進めていました。これが根本的な問題だと思います。
この経験から、今後はAPIの基礎から設計手順まで、体系的に学習し直す必要があると強く感じています。正しい設計なくして、スムーズな連携はありえないと感じました。
放置されたコード品質：静的解析ツールやコードレビューの重要性
静的コードチェックツールのESLintやRuboCopを導入していなかったことも、大きな反省点です。
ツールを使っていなかったため、各ファイルでコードの書き方がバラバラになり、統一性のないコードが量産されてしまいました。
さらに厄介だったのは、コードレビューの段階です。
「動作はするけど、このコードが良いのか悪いのか」
を判断する明確な基準がなかったため、表面的な修正だけを行い、本質的な品質向上には繋がりませんでした。
品質の低いコードは、将来の負債になると思うので、今後は、レビューの基準を明確にし、ツールの力を借りてチーム全体のコード品質を底上げしていくことが不可欠だと感じました。
おわりに
今回のチーム開発は、まさに 失敗やアクシデントの連続 でした。しかし、そのひとつひとつの失敗が、今後の開発において非常に重要な学びを与えてくれました。
多くの課題に直面しながらも、チームで協力し、最終的にアプリを完成させ発表できたことは、何物にも代えがたい経験です。
この経験を通じて、単にコードを書くスキルだけでなく、チームでスムーズに動くためのソフトスキルや、作業効率をグッと上げるツールの活用術など、本当に多岐にわたる学びがあったと感じています。
長くなりましたが、最後までお付き合いいただき、本当にありがとうございます！
今回の経験で得た知見と反省を胸に、これからも精進を重ね、いつか
「あの時の私、よくやった！」
と未来の自分が褒めてくれるような、そんなエンジニアになれるよう頑張ります！