「アプレンティス」に参加し、
カリキュラムの中で人生初のチーム開発を経験させていただきました。
とても楽しみにしていたカリキュラムであり、
新鮮な課題や発見があったため、学んだことを中心にまとめます。
はじめに
アプレンティスの第1回チーム開発は、
一言で言えば 未経験者が1か月で行うハッカソン です。
「自分たちの役に立つもの」をテーマに
・HTML/CSS
・JavaScript
・PHP/Ruby
・フレームワークの使用は禁止
という制約のもと、ローカルで動作するように開発し、5分以内でプレゼンを行います。
私たちのチームは当初2名から始まり、
途中で新たなメンバーが加わったことで最終的には3名で開発を行いました。
メンバーよりもカリキュラムが進んでいたこともあり、
自然と私が進行役を務めさせていただく形になりました。
多くの課題や反省点もありましたが、
結果として最優秀チームのみが獲得できるBest Awardを受賞することができたため、
良い思い出となりました。
まずは成功したことから振り返っていきます。
うまくいったこと
AIを活用したテーマ案の質向上
テーマ決めは、メンバーでアプリのアイデアを出し合い、お互いの良いと思うアイデアから絞っていくという方法で進めました。
当初から全員が完全に承諾できるテーマを決定することは難しいと考えたため、全員のマスト要件を決め、それ以外は妥協するか、統合案を考えてアイデアを練りました。
元々は「学習時間に応じて木が育っていく」という案でしたが、実装が難しそうということもあり、「良いアイデアは、多くのアイデアがある時に生まれる」と書籍*で学んだことがあったので、AIを使用してテーマ案の幅を広げることにしました。
結果、積み木の案から派生し「本棚に本が蓄積されていくのはどうか？」というアイデアが生まれました。
本は知識の象徴でもあり、本棚であれば定型的なため実装もできるだろうということで採用されました。加えて私のマスト条件だったChatGPTを、「偉人からの励ましの言葉」で使用することになりました。
実際に他のチームでは「木が育っていく」案が採用されており、ネタが被らなかったのもAIによる恩恵の一つだと思います。
*『アイデアの力』（原題: A Technique for Producing Ideas）ジェームズ・W・ヤング著
フィードバックをしやすい空気づくり
特にプレゼンに関してメンバーから率直なフィードバックをもらえたことは、
今でもとても感謝しています。
というのも、メンター陣含め5分のプレゼンで評価をするほかないため、
BestAwardを受賞するには、プレゼンの影響度が大きいためです。
実際に2回のフィードバック会を開き、
「この順番の方が分かりやすい」
「開発理由への遷移がやや遅く感じる」
「焦っているような感じがする」
など、多くの率直なフィードバックから改善することで、
より良いプレゼンへつながったと思います。
普段から言いたいことは率直に言い合える関係を保ちつつ、
ジョークをはさんで緊張感が高まりすぎないようにしながら、
相手をリスペクトした関係を作れていたことはチームの強みに直結したと思います。
常に全体スケジュールから進捗を確認していた
最終的には後ろ倒しになりましたが、
プロジェクトが遅れているという事実を認識し、解決策を考えられていた点においては、
Notionのガントチャートをもとに開発を進めたことは成功でした。
週2回行っていたチーム会では、警鐘を鳴らして対策などを話し合ったり、
メンバーが体調を崩した際はタスクを巻き取るなど、常に全体を俯瞰しながら立ち回るよう心掛けました。
人は使える資源(時間など)を使い切ってしまう（パーキンソンの法則）の観点から考えても、
期日を設けて厳守するように進行することは重要性があったと感じます。
不安要素の強いタスクは早めに手を付けた
・このような機能はどうやって実装すれば良いのか？
・GPTのAPIを使用するにはどのような手順が必要なのか？
など
所要時間の推測ができないタスクを優先したことは、
予定通りに進めるうえで役立ったと思います。
実際、GPTのAPIで権限の付与まわりで少し時間を使ったため、
後回しにしていればギリギリになっていた可能性もありました。
進捗をスムーズにするため、不安要素を早めに解消することは、
今後も心掛けたいと感じました。
チーム開発で起こりうる課題を前もって予測した
チーム開発でどのような課題が生まれるか予測できなかったため、
アプレンティスの先輩方によるチーム開発記事を読み、課題を予測したことは効果的でした。
特に
・データの受け渡し方法が曖昧だった
・Gitのルール不足による混沌化
・人に聞きづらい空気があった
などが多く挙げられていたため、
・データの受け渡しは多めに情報を用意
・Gitのコンフリクトが起きないようDiscordのチャットで宣言する
・困っている人がいれば自分から提案を申し出る
など、問題を未然に防ぐ対応をとることができました。
反省点
時間にストイックすぎたため初期に不満を抱かせてしまった
私は前職が施工管理で、全てを一人で管理する立場だったこともあり、プロジェクトを無事に完遂させたいという思いが強すぎたため、締め日や定例会の時間などに厳しかったことは私の失敗でした。
常に進捗を意識していたため、予定より遅れている場合はメンバーを急かしてしまうこともあり、その結果、コミュニケーション不足などの不満につながりました。
ご指摘をいただき、開発が終了する頃にはお互いを尊重しながら、率直な意見を出し合えるような空気を作ることができましたが、初期にストレスを与えてしまったことに関しては本当に申し訳ないという気持ちでいっぱいです。
次のチーム開発では信頼関係を築きつつ、より柔軟にコミュニケーションをできるよう心がけていきたいと思います。
設計資料の粒度不足
当初2名から始まったこともあり資料を詳細に作成していなかったため、
途中で加入したメンバーへ制作物を瞬時に説明できませんでした。
チームでの開発においてはボタン一つの仕様を説明するにも、
詳細な資料が必要であるということを痛感しました。
3名の開発ですらイメージや仕様の認識に齟齬がたびたび発生したため、
大規模な開発となれば、分かりやすい資料を作る技術は必須になるだろうと感じました。
次のチーム開発では、より粒度の高い資料を作成し、
誰が見ても同じものを制作できる ことを目標にします。
全員がどれだけプロジェクトに時間を使えるか考えなかった
アプレンティスのチーム開発はメインのカリキュラムと並行して実施されるのですが、
カリキュラムで提出物がある週はメンバー全員があまり時間を使えませんでした。
各メンバーがプロジェクトにどれだけ時間を使えるのか？ を想定せずにスケジュールを組んだため、全体的に後ろ倒しになったのは推測不足だったと感じます。
開発現場でも複数のプロジェクトを同時に進行することがあるため、
使える時間の正確な推測や、共有をする必要があると感じました。
Gitルールの甘さ
今回、Gitによるプルリクの際は、自分以外1名以上のレビューが必須という制限を設けていましたが、終盤になると時間が足りなかったこともあり、レビューが簡素になりがちという課題も出ていました。
根本としてプルリクのコード量が多すぎるという問題もあったため、
次回のチーム開発ではよりこまめにプルリクをできるような仕組みづくりも必要だと感じました。
プロダクトのクォリティ
当初2名、かつ時間や技術の制約が厳しかったこともありますが、
個人的にはもっと質の高いものを作ることもできたのではないかと感じました。
メンバーの中で私が最も時間を使うことができたため、
プロダクトへの影響度も大きかったのではないかと思います。
今回の反省点を活かし、次のチーム開発ではよりチーム全体の生産性を高められるよう立ち回り、レベルの高いプロダクトを創れるよう努めたいと思います。
おわりに
今回のチーム開発では情報伝達の難しさや
複数人で開発をすることの新鮮さを体験することができました。
今でも記憶に残っていますが、プレゼンのフィードバックが少なく不安になっていたとき、チームメンバーがかけてくれた
「佐藤さんならやれますよ、私は信じてます」
という胸が熱くなった励ましの言葉は、
生涯忘れられないチーム開発の思い出となりました。