先日、2021年のCivictech Challenge Cupに参加し、初めてのチーム開発にかなり苦戦しました。結果は散々なものでしたが個人的にはかなり得るものがありましたので、この記事では、なぜ失敗したのか、改善点、感想などを挙げていこうと思います。
Civictech Challenge Cupとは
エントリーした学生がチームを組成し、自分たちの身近にある地域課題や解決したい社会課題を解決するアイディアを考え、実際にその解決に向けたサービスのプロトタイプを開発する実践的な開発コンテストです。
参加のエントリー時もしくはその後に、チーム(2人〜6人)を組み、協力して開発することが求められます。
Windows・macOS上で動作するソフトウェア、Android・iOS上で動作するアプリ、Webアプリ、その他、IoTデバイス等を利用した作品のいずれかもしくは複数の組み合わせを提出するもの
という学生コンテストです。
私たちのチームは、皆知らない人同士で、「何か身近に困っている声を解決しよう」という意思のもとに声を掛け合い、チームを結成しました。
チームの構成は、リーダー(進捗管理等)、デザイナー1人、エンジニア4人という構成でした。
エンジニアのレベルとしては、1人がWeb制作経験者、1人(私)が２、３回Web制作をしたことがある程度、2人が初心者という構成でした。
作品決めから開発着手までの失敗点
1.ゆるい意志を持って集まったために作品決めに時間を多く使ってしまったこと
チームが決まった後から約２ヶ月間あったのですが、テーマが決まり、制作が始まるまでが遅く、実際の開発期間は３〜４週間程度でした。
初期は１週間に一回の話し合いだったため、何をやるのかということに２週間、ペルソナの選定に１週間、技術選定に１週間程度かかっていました。
誰になんのためにどのようにするのかという制作の作品決めは非常に大切でしっかりしていないと後々困るものですが、それに時間をかけすぎてもいい結果にはなりませんでした。ある程度何を作るのかということ早めに決める必要がありました。
2.制作途中でユーザー調査し、作品の方向性を転換させてしまった。
１でしっかり話し合ったはずの作品の土台ですが、改めてユーザーの調査をしてみると現在作っているサービスに魅力を感じないという意見が多く、開発半ばで大きく方向転換をしてしまったことです。
残り３週間の時点で作品を転換させてしまったため、開発時間が足りないように感じました。
チーム開発が初めてだったこともあり、制作の流れを正しく認識していなかったため、後でそういえばユーザーの意見聞いてないよ！聞かなきゃ！となってしまった。その影響で、UIなどが完成され、ワイアーフレームが出来上がったのは締め切りの１週間前くらいになっていました。
開発時の失敗点
1.エンジニアの技術力の差
エンジニアの構成が、1人がWeb制作経験者、1人(私)が２、３回Web制作をしたことがある程度、2人が初心者という構成だったため、参加時の技術力の差は大きくありました。
本来なら制作物を作っていない前半の１ヶ月で、私や経験者の方が使用するフレームワークの勉強会を開いて初心者の方々の技術力の底上げを図るべきでした。しかし、それができなかったため、途中から2人のみで開発が進むことになってしまい時間不足につながりました。
改善点として、何か新しい言語等に挑戦する際は必ず勉強期間を設けること、どこまでできるのか、何ができるようになったのかをアウトプットしてもらい、能力の把握を行い、仕事を割り振っていくことが大切だと感じました。
1.5 技術力の差からくるコミュニケーションの齟齬
初心者の方が「〇〇ってどうやるんですか？」と質問してきたとき、「公式ドキュメントの〇〇見ればわかりますよ！」という回答では不親切すぎるということがわかりました。
大概のことは公式ドキュメントで解決することも多いですが、初心者にとっては公式ドキュメントはかなりハードルが高いものです。なので、公式ドキュメントのここ見れば解決しますという回答ではなく、(具体的に)〇〇と書けばいいですよ！や類似の方法で書かれたコードの載っているサイトを提示してあげる必要があるということを学びました。
相手のレベルに合わせて質問の回答をするということの難しさを学べました。
2.2つ以上の言語の同時勉強は無理
技術選定のミスですが、今回、使ってみたいという理由でLaravel + Reactで開発していました。私は、Laravelは少し齧っていたので若干理解していましたがドキュメントを見ながらようやく実装できる程度の能力でした。Reactは未経験でTypescriptもJavascriptもほぼ触ったことがなかったです。
私ですらReactの勉強で精一杯になり苦しんでいました。初心者の方がいきなり2つの言語を使えるようになれと言われてもできるわけもなく、全員の学習負荷を考えて、身の丈にあった技術選定をする必要があるのだと学びました。
3.人に見てもらうコードという意識を持つこと
個人制作をしているとあまり意識にないことですが、変数の命名規則やテストコードをコメントアウトで残さないなどのコーディング規約を最初に作る必要があったということです。経験者の方に言われたのですが、コメントはできるだけわかりやすくすることやコーディングスタイル、commitの内容の書き方などをチーム全体で統一する必要がありました。誰がコードを読んでも統一感が持てるように書けるルールを作るということを学びました。
4.コミュニケーション能力の不足
1.5のコミュニケーションの齟齬にも共通することですが、全体的なコミュニケーションが不足していました。
実際には、結成初期はほぼ１週間に一度しか顔合わせをせず、あまりコミュニケーションも取れていませんでした。また、開発初期も3日に1回程度進捗を確認する程度でお互いがどのタスクをしているのかなどの確認頻度が足りていませんでした。例えば、〇〇のissueにアサインしていても最低1日一回はどこで詰まっていて何ができないのかなどの把握が困難になって、結局あれってどこまでいけてるの？という状況になってしまいました。
開発末期には、毎日顔合わせして進捗確認し、そこから比較的スムーズに開発をすることができたので、もっと早くから行うべきだったなと感じました。
また、進捗確認以外にも私的なコミュニケーションをもっと行うべきだったと思いました。
理由は、4人中2人しか開発できていませんでしたが、交流を深めることで初心者の人ももっと気軽に質問する雰囲気作りも可能であったし、また2人の開発の負担の重さからくる不満も解消することもできたはずだと思いました。
全てリモートワークだったわけですが、自分がいかに人との関係で現実でのコミュニケーションに頼っていたのかを実感しました。リモートでもうまく人間関係を築けるように頑張りたいと思います。
参加する前に読んでおきたかった記事
最後に
今回、初めてコンテストに参加してみたのですが、苦労はありましたが非常に楽しく、勉強になったと感じています。また、いろんなコンテストに出てみたいと思っているのでその際には学んだことを生かせるように頑張りたいです。