AIがコードを書いても、
チーム開発はなくならない
AIで減るのは「コードを書く作業」だけです。AIが進むほど、複数人で同じコードベースを安全に変えていく力の価値は高まります。
提供するのは、複数人でGitを扱う機会です。
「他人のコードを変更し、自分のコードをレビューされる」最初の経験を、レベルに合わせて積める場を用意しています。
個人開発だけでは、ここが埋まりません。
レビューが学びになる
一人だと自分の癖に気づきにくく、AIも本人の前提に沿って答えます。他の開発者からの指摘が、設計や責務の置き方を教えてくれます。
人からのレビュー ≠ AIの返答動くコードと、入れられるコードは違う
ローカルで動くだけでは、チームにマージできるとは限りません。整合性や可読性、既存機能への影響までを見て統合します。
マージできて、はじめて完成暗記ではなく理解
難しいGit操作はAIに聞けます。必要なのは、今どのブランチにいて、自分の差分が何かを理解し、安全に戻せる力です。
コマンド暗記より、状態の理解レベル別の、チーム開発。
レベルに応じた3つのチーム開発と、さらに挑戦したい人向けの発展プロジェクト。チームだからこそ、一人では避けがちな低レイヤーや、慣れない言語でのAPI設計にも踏み込めます。
-
2日間
Gitハンズオン最初の一歩
チームで1つのリポジトリを作り、CLIプログラムを分担して書きます。
参加条件コンピュータサイエンス初級 -
1週間
Webサイト制作
プルリクエストとレビューを回しながら、1つのWebサイトを作り上げます。
参加条件HTML/CSS/Tailwind -
2週間
Go言語でWebアプリ開発
GoでWeb APIを設計し、それを使うSPAまで作ります。
参加条件コンピュータサイエンス中級ほか -
3週間
デスクトップ・モバイルアプリ開発
メッセージをやり取りするネイティブアプリを、クライアントとサーバーの両方から作ります。
参加条件バックエンドプロジェクトほか -
2ヶ月
クラウドストレージ開発
複数台のサーバーと自前のCDNで、水平にスケールするストレージを構築します。
参加条件ロードマップの修了
一人では、気付けなかったこと。
チーム開発を終えた参加者が、うまくいったこととつまずいたことを振り返っています。設計の決め方や、人のコードを読む大切さなど、個人開発では得られない気付きばかりです。
Gitの使い方を基礎から学べました。設計書を書いて皆でレビューし、issueで適切にタスクを分けられるメンバーもいました。あとから機能の重複が見つかることもありましたが、柔軟に対応できたと思います。技術的に及ばない立場での参加だったので、「こうやるのか」がたくさんありました。
チーム開発の大まかな流れとGitの使い方を学び、コメントも含めて読みやすいコードが大事だと感じました。何より実感したのは、設計の大切さです。機能や関数の名前・引数・返り値をあらかじめ決めておくこと、機能別にファイルを分けて作業してコンフリクトを避けること、データの状態がどう変化するかを軸に設計を考えることを学びました。
チーム開発における大まかな流れと、共有することの重要性を学びました。チームメンバーの書いたコードを読んで理解する力も身に付きました。人の書いたコードから機能を拡張するときには、この力が欠かせないと感じています。
メンバーそれぞれが全力を尽くし、期限どおりに提出できたことが一番の成果だと思います。アプリも、最初に想定したとおりの成果物になりました。一方で稼働できる時間が短く、最後はチーム全員が夜遅くまで作業することになりました。「早め早め」に進め、適度なバッファを設ける工夫が必要だと学びました。
メンバーが自主的に取り組み、期限どおりに提出できました。レベルの高いメンバーから、APIの設計やフォルダ構成について新しい学びを得られました。反省点は、共通で決めるべきメソッドやstructの書き方を共有できていなかったことです。
初心者向けのチーム開発のときと比べて、メンバーと積極的にコミュニケーションを取りながら開発できました。今まで本格的なバックエンド開発をしたことがなかったので、APIの設計など未知だったものの経験を積めました。次はスピードだけを重視せず、システムの堅牢性もしっかり考えて開発したいです。
最初に全体の設計、クラス構造、役割分担をはっきりさせる大切さを学びました。曖昧なまま進めると、後でロジックの不整合や重複が起き、チームの負担が大きくなります。また、ブランチ戦略、コミットメッセージ、PRの流れなどの基本的なルールを最初に揃えると、作業効率やコミュニケーションの質が大きく上がることを実感しました。
正確な見積もりには、タスクの粒度を揃えることと、メンバー全員が稼働できる時間を共有しておくことが欠かせないと分かりました。最初の個人開発の期間が長くなりすぎたのも、この見通しが足りなかったからです。
この経験は、個人的にかなり大きかったです。「読みやすいコードにするには？」「バックエンドのアーキテクチャはどうあるべきか？」「プロジェクトを円滑に回すには？」と、ソフトウェアの質・設計・マネジメントに興味を持つきっかけになり、『リーダブルコード』や『クリーン・アーキテクチャ』などの名著も買いました。コードを書くだけでなく、周りに良い影響を与えられるエンジニアになりたいです。
技術力だけでなく、メンバーとコミュニケーションを取り、互いに共通認識を持ちながら開発を進める大切さを実感しました。チームプレーでプロジェクトを円滑に進められるエンジニアになりたいです。技術的には、バックエンド開発がとても面白いと感じたので、これから積極的に調べていきます。
チーム開発の経験は、
面接でよく聞かれる。
内定したRecursion生の体験記から、面接で聞かれたことを抜き出しました。
チーム開発の経験について、詳しく教えてください。
なぜそのアーキテクチャで開発することにしたのですか？
技術選定の理由と、チーム開発で工夫したことは？
チーム開発での苦労と、それをどう乗り越えたか教えてください。
質問は体験記の回答を元に、話し言葉に整えています。