1.はじめに
私はWEBエンジニアを目指す21歳です。
現在参加しているアプレンティスシップで、初めてのチーム開発を経験しました。わからないことも多く苦労しましたが、間違いなく今後のエンジニア人生の土台となる貴重な経験になったと感じています。技術的な学びに加え、グループ内での意思決定のあり方や、開発中の細かなコミュニケーションから得られた学びも大きかったです。
2.開発物
今回は料理の献立の提案とその作った料理を記録するアプリを作りました。
3.使用技術
- フロントエンド : HTML/CSS/JavaScript
- バックエンド : PHP
- 開発環境 : Docker
- ソース管理 : GitHub
4.開発の流れ
- アイデア決め
- スライド作成
- 要件定義
- 設計
- タスク出し
- 環境構築
- 実装
- プレゼン準備
大体アイディア出しからプレゼン発表まで合わせると2ヶ月弱の開発期間でした。
5.アイディア決め
チームの一人が栄養士として働いていたこともあり、「じゃあ栄養士直伝の献立提案アプリを作ろう!」という話で開発がスタートしました。ただ、それだと既存アプリとの差別化が難しかったんです。そこで僕が筋トレをしていることを話したところ、「いいね!じゃあ筋トレ特化の献立提案アプリにしよう!」となり、開発の方向性が決まりました。
学び:毎週チーム会を開いて、週替わりでPMを回していたんですが、自分の番になったときに正直どう振る舞えばいいのかわからず、話がまとまらないことが多かったです。本来PMはみんなから意見を引き出して整理して、最終的に方向性を決める役割だと認識していました。でもそのときの自分は、開発知識が足りないことや年齢差を気にしてしまって、うまく仕切れませんでした。
そこで考え方を変えて、とにかく「意見を出しやすい雰囲気を作ること」と「出てきた意見を整理して見える化すること」だけに集中するようにしました。自分が全部答えを持つ必要はなくて、流れを作るだけでチームが自然と動きやすくなるんだなと気づきました。
6.要件定義
- ゴール
- 筋トレをしているユーザーの献立を考える手間を減らす
- 食事のレパートリーを増やす
- 楽しみながら日々の食事記録ができる
7.設計
今回は画面から先に作り、ユースケース(ユーザーがシステムをどう使うかを具体的に描いたシナリオ)を洗い出し、そこから必要なデータを抽出していきました。
8.タスクだし
タスク出しにはNotionを使ったのですが、もちろんタスク管理だけでなく、各週の議事録やテーブル設計、プレゼン資料などを一元管理できたのでとても大活躍でした。
僕のタスクは主にユーザーの新規登録や再設定でした。
タスクだしに関してもっと細分化してまとめておけばよかったと後悔しています。例えば、
新規登録画面(メアド等)ではなく
• バリデーション実装
• エラーパターンの整理
• 成功時のリダイレクト処理
• DB保存処理
• テストコードの作成
といった形で分けておけば、自分のタスクが具体的にどこまで進んでいるのかが明確になり、進捗管理もしやすかったはずです。さらに、レビューをお願いするときにも「今回はバリデーション部分だけ見てほしい」と伝えられるので、チームとしてもレビューしやすくなると思います。今後は大きな機能単位ではなく、実装ステップごとにタスクを切り出して管理していきたいです。
9.実装
実装の期間は約一週間でした。初めは5日ぐらいで実装を終えてプレゼンに備えようと考えていましたが、結局最後の日までコードと睨めっこすることになりました。笑
僕が担当した機能は以下の通りです。
- 新規登録①(メールアドレス、ユーザネーム等)
- 新規登録②(なりたい体型、身体情報等)
- ログイン
- ユーザ情報再設定
迎えたチーム開発初日、何から手をつけていいかわかりませんでした。実はこのチーム開発より前にLaravelを使った開発をしていましたが、フレームワークはあらかじめファイルの役割が明確で整理されていてわかりやすかったのですが、フレームワークなしのPHPは更地からのスタートで本当に何から手をつければいいのかわかりませんでした。yamlってどうやって書くの?ルーティングはどこに書く?フロントエンドとバックエンドはどうやって繋がる?などいろんな疑問が出た初日でした。
ドキュメントなどの一次情報を見て開発するには初心者の僕には難しかったので、僕と同じ悩みを持っていた方たちがすでにこういったqiitaなどの技術ブログで発信しているの参考にできたのでとても役立ちました。特にdocker系の知識ではコマンドやマウントなど丁寧に解説してくれている記事があったので助かりました。
今回のチーム開発の反省
-
反省点
-
PRのコメントが「〇〇の実装」というふうに抽象的に書いていた。
→ PRを機能ごとではなく、もっと細かくして、なぜこの実装をしたのかとかどのように実装をしたのかとか書くべきだった -
タスクの解像度を低い(機能ごとに分けていた)
→ 1つのタスクが3時間以下になるまで細分化する&工数の見積もりで不確実な場合はバッファを持たせて考える
- 同じ処理をいろんなファイルで書いてしまい、冗長なコードを書いてしまった。
→ 親クラスを用いて共通のメソッドを書く
-
PRのコメントが「〇〇の実装」というふうに抽象的に書いていた。
-
よかった点
-
コミュニーケーションを欠かさず開発ができた
→もくもく会というエンジニアの間では有名なコミュニケーション文化を取り入れて、とても有意義なdiscordの使い方ができた -
何と言っても動くものが作れたこと
→開発初日は環境構築から躓いて不安ばかりだったが、協力しながら一つのプロジェクトを無事完了できたことが何よりも自信につながった
-
コミュニーケーションを欠かさず開発ができた
最後に
正直まだわからないことは多いですが、それでも知識が点と点でつながった瞬間や、自分の書いた処理が動いたときの小さな成功体験を積み重ねられたのは大きな収穫でした。こうした経験を通じて、「次はもっと高度な機能を実装したい」「より良いコードを書きたい」という気持ちが芽生えたことこそ、今回の開発で得られた一番の成果だと思います。これからも頑張ります!



