はじめに
今回、プログラミング初心者4人で行った初めてのチーム開発プロジェクトについての記事です。
テーマは『自分たちの役に立つものを開発する』
チーム開発の流れ
- アイデア決め
- スライド作成、要件定義
- 設計、タスク出し
- 環境構築
- 実装、プレゼン準備
- プレゼン
アイデア決め
まず、それぞれ一人が一つ抱えている課題のアイデアを出すことにしました。
私はFigmaを使うことを提案し、付箋を使ってアイデアを書き留め、その中から一つを選ぶことで決める流れになりました。
アイデアの課題、目新しさ、難易度で決めていく中で良い点、そうではない点がそれぞれにあり、賛同や衝突もありながら一つに決めるのが困難になりました。
そこで他のチーム開発ではどのようなアイデアがあったのかを見て、課題、目新しさ、実装難易度を改めました。
その後、4人の共通な新たな課題として「日々つけている日報をわかりやすく一目で振り返りたい。」ということが上げられました。
そこからはその課題を解決するためのアイデアがどんどん出てき方向性が決まっていきました。
ここで方向が決まらずバラバラだったチームが、少しずつまとまってきたように感じました。
要件定義
「日報アプリ」の機能として何ができるかをまとめることにしました。
私は要件がブレないように出てきたアイデアをまとめていきました。
それぞれがアイデアを出し、「こんな機能あると良い」「可能ならこんな機能も追加」とそれぞれが課題を解決するために必要な機能をだしていきました。
具体的な内容は
- トップページはカレンダー
- 月毎にその日、何を学習したか、自己評価が一目で確認できる
- 月、週でどのくらい学習したかの時間を一目で確認できる
- カレンダーの上部には目標を自由に記入できる
- カレンダーの日付のマスをクリックしたら詳細が見られる
- 詳細の画面には日報の内容が表示され、学習時間や日報で書く項目、日報を登録するための編集ボタンがある
- 編集ボタンから日報の登録画面にページ遷移
- 登録画面には日報のテンプレートと自己評価をつける項目がある
- 登録するとカレンダーの画面に戻る
徐々に制作するものの形が見えてき始めたことで意見の賛同が増え、チームがポジティブな方へ傾いていきました。
設計
ここからより具体的で細かな話し合いが行われました。
やることとして
- 業務フロー
- 画面遷移図
- ワイヤーフレーム
- テーブル定義書
- 技術アーキテクチャ
これらをチームで分担しました。
自分の担当はテーブル定義書でした。
チームで話し合いながらすぐに必要なテーブルを出し、項目を埋めていきました。
話し合いながら実際に実装することを考えると必要なテーブルが足りないことに気が付き、追加していく過程で本格的に実装を始めるのだと意識し始めました。
追加したテーブルを合わせて、テーブルの内容をチームメンバーに説明し、無事テーブル定義を完了することができました。
他のチームメンバーもワイヤーフレームを作成してくれたことでより明確なイメージを合わせることができました。
タスク出し
チームメンバーが必要なタスクを洗い出していき、担当を振り分けていきました。
当初の自分の担当は主にJavaScript担当でした。
- 日付ごとの詳細表示
- 詳細画面の表示内容
- 画面遷移
- 目標の表示 など
時間のあるチームメンバーの一人が分けられたタスクの大半を担ってくれましたが、私はチームで開発するからには助け合おうという心意気で、自分のタスクをこなして、他のチームメンバーのタスクを引き受けようと思いました。
環境構築
今回はローカルでの動作を前提に作るものとしました。
チームメンバーの一人が率先して開発環境の共有をしてくれたおかげでローカルでの動作環境を統一することができました。
自分もこの段階で早めに行動しようと、テーブル定義書を元にすぐにデータベースとテーブルの作成を済ませ、クエリを共有しました。
チームメンバーも早めにhtmlで画面表示を作ってくれたりと事前準備で実装が進んでいきました。
実装
一週間という短い期限で本格的に実装を開始しました。
まずは決められた自分のタスクを進めていきました。
事前準備もあってhtmlから要素を取得、足りなければ追加して表示、保存、遷移といった実装を難なく済ませることができました。
チームメンバーの様子を見ながら手伝えるところを探し、抜けやバグがないか確認をはじめました。
抜けがある場合は確認をして貰ったり、バグがあれば原因を見つけ解決策を模索して修正を行いました。
自分の実装範囲でも不具合が見つかりチームメンバーのコードの修正をしながら解決することができました。
プルリクを小まめに確認し、問題がなければマージ、コンフリクトが起きていたら解消しました。
チームメンバーからの追加の要望にも応えながら、チーム会で残りの未解決のタスクを引き受けました。
手間取りながらも実装することができ、チームメンバーに確認を求め、マージしましたが後にバグ報告があり、残りの時間で急ぎながら修正に取り掛かりました。原因は突きとめましたが要素の取得の仕方に問題があり修正に悩みました。トライアンドエラーの末に無事解決することができ、プレゼンまでに実装を終えることができました。コードも綺麗にまとめることができ安心しました。
他のチームメンバーもそれぞれのタスクに専念してくれた甲斐もあり、完成することができました。
まとめ
初めてのチーム開発ということで多くの課題に直面しましたが、最終的には目標を達成し、プロジェクトを完成させることができました。
学びと気づき
今回のチーム開発を通して、要件定義や設計の重要性を学びました。緻密な計画がチームの認識を合わせ、後の実装フェーズをスムーズに進めるために必要なことだと思えました。
また、チームでのコミュニケーションや話し合いの大切さも学ぶことができました。
- 情報は共有し、自己完結しないこと
- 相手の話を聞き理解を示すこと
- 相手にどのように捉えられるか考えて意見を伝えること
- 議題を明確にした上で話をすること など
以上のことを気を付けて話していましたが、それでも時折、議題からそれてしまったり、相手目線になって意見を伝えられていなかったかなと振り返ることがありました。
他にも、チームでしか得られない技術的なスキルの学びもありました。
開発環境の共有、チームでのGitHubの使用、人のコードへの干渉など。
特にGitHubの「ブランチを切る、プルリクエスト、レビュー、マージ」の流れのひとつひとつをチームで話し合って取り決めることが重要だと気づきました。
改善点と今後の課題
改善点として
- アイデア決めでは、アイデアの決め方を変えること
- 要件定義では、要件定義書を作りこみブレないこと
- 設計では、共通認識を揃えること
- 実装では、動作確認やバグチェックを抜け目なく行うこと
その他にも、チーム会での話を記録に残すため、議事録を取ること。
会話だけで決まったことの内容をきちんと記録し、形に残して振り返れるようにすること。
今後の課題として、GitHubの取り決めやアイデアをどのようにして決め、まとめるかなどの課題があるため、次回はこれを話し合って決めていきたいと思います。
最後に
個性があり、バランスのよい優しいチームメンバーの努力と協力に感謝します。この経験を通して得た知識やスキルを、今後のプロジェクトに活かしていきたいです。