この記事は夏のブログリレー21日目の記事です
こんにちは、25Bのくあらんてぃんです。8/8から9/5にかけて開催された1-Monthonに、13班のリーダーとして参加しました。結果として、全体的な開発の進め方に反省があったと感じるので、それを書いていこうと思います。
「キーワードの一致」を「やりたいことの一致」と捉え違ってしまった
- 「講習会」に関するプロダクトを作りたいという案に多くのメンバーが賛同したが、対話を重ねていくと、講習会に関するどの問題について取り組みたいのかがメンバーによって異なっていた。
- 講習会の準備をサポートする「フロー」機能の実装に関する話し合いでも、柔軟性やどこまで多機能にするかについて、意見が対立した。
- 部内向けサービスを作るということで、ターゲットがメンバー自身に近いこともあり、運営がほしいアプリと自分がほしいアプリを混同した議論をしてしまったと感じる。
ChatGPTくんによると、
最初に機能案へ入る前に、「誰の・どの課題を・なぜ解決したいのか」を全員で言語化し、プロダクトの目的と非目的を揃えるべきだった。特に、自分が欲しいものと想定ユーザーが必要としているものを分けて議論する必要があった。
だそうです。
今回の場合、問題解決方法を吟味していく段階で、必要な機能がだんだん増えていった気がします。個人的には、実際の講習会運営経験者に話を聞くことを目標に、実装のスケジュールを組んでいけばよかったと感じています。講習会運営を数回経験した人数人のみでは、どれが最適かなんてわからないという謙虚さを持つべきでしょう。
設計という行為にこだわりすぎてしまった
- AIを持っているメンバーが4人、AIを持っていないメンバーが2人というチーム構成だったため、Vibe Coding 的な開発ループを回すと、AIを持っていないメンバーを蚊帳の外にしてしまうだろうと考えた。
- また、多くのメンバーの予定が忙しく、同期的な開発が難しそうだと思われたため、非同期・非対面でも進められる開発方法が必要そうに思えた。
- そのため、人間によって仕様をできる限り細かく決め、それを最終的にAIに流すようなウォーターフォール一辺倒の開発方法を推し進めてしまった。
- メンバーの経験をあまり考慮せず設計担当領域を割り当てたりしてしまったため、経験のあるメンバーが全容を把握するのが遅れたり、経験のないメンバーが何をやればいいのかわからなくなったりしてしまった。
- 何より細かい設計って別に楽しくないため、全体的にモチベーションが低下し、締切駆動の開発の原因になった。
ChatGPTくん：
仕様をすべて事前に固めようとせず、後から変えるコストが高い部分だけ先に決め、残りは小さな試作を通じて決めるべきだった。また、設計タスクは経験に応じて粒度を変え、AIは一部の人の実装手段ではなく、チーム全体の検証手段として使う方がよかった。
「試作」というのが僕に欠けていたキーワードだと感じていて、設計の段階でもAIによる恩恵を受けた進め方をすべきだったと思います。イメージがつかないもののリスクを考えるような設計より、具体的な実装の違和感を指摘していく方が、経験の浅いメンバーでも取り組みやすいでしょう。AIを、個人の成果を出すためのツールとしてではなく、試作品を素早く作成してチーム全体の議論材料にするためのツールとして活用する形も大切だな〜というふうに感じました。
チームメンバーへのアプローチが欠けていた
- 先述したように、非同期を推したせいで、他の人との認識の調整やタスクの割り当てなどのコミュニケーションもタスクになってしまった。
- これは対面で会う場合なら日程調整というタスクのみで済まされるものだと思う。対面の方が適しているタスクの場合は、面倒がらずに対面にすべきだった。
- また、全体的に、僕が採用したい方針や、なぜその方針を採用するかの説明を他のメンバーにあまりしていなかった気がする。
- 多様な組み合わせでペアプロすれば認識は勝手に揃っていくだろ、と思っていたが、そもそもVCに来るメンバーが限られていたし、ペアプロを活発化させる呼びかけも大してしていなかった。
- ハッカソン終了が近づいて対面が多くなったときにも(ときこそ)、ペアプロなどを用いればよかったのだろうが、時間に追われていてコミュニケーションのコストを割くという選択ができなかった。
ChatGPTくん：
開発プロセスだけでなく、誰が今どこで困っているか、誰と誰を組ませるべきか、なぜこの方針で進めるのかまで意識的に共有するべきだった。非同期に寄せすぎず、重要な認識合わせや設計判断は同期・対面で行い、ペアプロも自然発生に任せず意図的に組む必要があった。
まぁ大体僕が言及した通りですね。ハッカソン最終日とかでは、AI持ちメンバーが、iPadをサブモニターにして、AIなしメンバーとペアプロ風にマルチタスク？で作業を進めるという工夫をしていたのが印象的で、チーム全体として開発体制に関するアイデアをどんどん出していけたらよかったなと感じています。
ということで
全体を通して、開発をチームで楽しむという視点が抜けていたように思えます。良いサービスを作るために開発手法を工夫する以前に、まず「良いチームを作る」ことにもっと目を向けるべきだったな〜と思います。
僕たちがハッカソンで作ったものや、ハッカソンを通してよかった点、他のメンバーの感想などが気になった人は、班のハッカソンブログ記事もぜひ見てみてください！！
(ブログ記事が公開されていたらここに貼る)
明日の夏のブログリレーの投稿者は、@HokubuRailwayです。
