[これは何]
登竜門Hack2025 共同開発講座の資料
[外部公開にあたって]
この記事は初学者向けに短時間でツール群や概念を説明するために、意図的に言葉の解像度を落としたり、誇張した表現を行なっている箇所があります
自己紹介
Yuma Satake
- 名前：佐竹友真
- 所属：名古屋工学院専門学校
- 領域：Web 開発
- 趣味：車・旅行
- Twitter：Yuma Satake
- 受賞歴（
講師なんて、こんなもんなんぼ書いてあってもええですからねぇ）- 技育CAMP Vol.10（入賞）
- 技育CAMP Vol.11（入賞）
- 関西ビギナーズハッカソン（最優秀賞）
- 技育CAMPアドバンス Vol.1 （大賞）
- カラビナハッカソン （カラビナ賞受賞）
- マイナポータルハッカソン （本戦出場）
- 技育CAMP Vol.5（最優秀賞）
- 名古屋Web3ハッカソン（4冠）
- 技育CAMPアドバンス Vol.3（GMO賞）
- 技育展2023（サイバーエージェント賞受賞）
- 技育CAMP Vol.5（DeNA賞）
- etc...
はじめに
皆さんこのゲームにご参加頂きありがとうございます。
皆様にはこれから "複数のエンジニアによる共同開発" をしてもらいます。
人月の神話
一般的な業務のプロダクト開発では開発工数（開発の作業量の多さ）を人月（1人月=1人のエンジニアが1ヶ月で開発できる工数）と呼ばれる単位で表します。
つまり、100人月のプロジェクトは100人のエンジニアで開発すれば1ヶ月で終わるということです！！！最高！！！
....嘘つきましたそんなことはありません。
なぜ開発は人数を増やしても早くならないのか
これらをはじめとした様々な要因から、単純に人数を増やしても開発が早くならないという話を「人月の神話」と呼びます
①コミュニケーションコストの増大
人数が増えるほど「どんなコードを書くか」「どうやって分担するか」などを決めるために時間がかかってしまう
②コードを理解する時間が必要
他人が書いたコードを理解するには時間がかかり、人数が増えるほど自分以外のコードを読む時間が増えてしまう
③タスクの分割の難しさ
小さなタスクをさらに分割しようとすると、作業が重複したり進め方のずれが発生し、開発のスピードをかえって遅くしてしまう
▼エンジニアの人数を増やしても開発が早くならないという有名な話
それを世界はハッカソンと呼ぶんだぜー！！！
そうした問題を解決するために多くの手法やツールが開発されています。
しかしながらここはハッカソン...!
参加者は初学者ばかり！未だ共同開発の苦しみを知らない雛の群れ...!!
そこでこの講座では、私の経験した「ハッカソンでの共同開発の失敗」を踏まえながら、共同開発におけるTipsを紹介していこうと思います。
①タスク管理ツール？そんなものはなかった。
📌事象
初日に用意したGithubProjectsが３日目から全く使われなくなり、Discordで各自が連絡する仕様に😇
🔍原因
- 1週間という短い開発期間の中で厳重にチケット管理をするモチベーションがメンバーになかった
- わざわざ Projects 開いてチケット管理めんどくさいよね...（今でも思う）
✅どうした/どうすればよかった
Discordにフロントエンド・バックエンドのチャネルを切り、それぞれで進捗を定期的に報告するようにした
→ チケット管理ツールを使うことが銀の弾丸ではない。そのチーム・開発期間に合ったツールを選ぶことが重要
当時のやつが見つけられなかったので何かの残骸
②壊して学ぶ、本番環境のすすめ
📌事象
いけるいけるー！！とマージして本番に挙げたところ見事に動かずコードフリーズ直前に本番を落とす
🔍原因
事前にローカルでビルドが通っているか、リンターが鳴っていないかを確認していなかった
✅どうした/どうすればよかった
CI/CDは最初に作ろう
CI/CDとは
要するに「自動でチェックして、自動で反映させる仕組み」
ハッカソンにおいては
- ミスで壊せなくなる
- コードフリーズ0秒まで開発できるようになる
というメリットがある(白目)
③あの日見たPRのデカさを僕達はまだ知らない
📌事象
20ファイル以上の変更のあるPRを発行してレビュワーをキレさせる
🔍原因
複数機能をまとめて開発してしまい、PRを分割しなかった
✅どうした/どうすればよかった
- 一つの小さな機能単位でPRを作成して依頼する
- レビュワーもこまめにレビューをしてあげる体制をとる
PRを小さくすると何がいい？
PRを小さくすることは高速な開発においてはいくつかメリットがあります
- レビュワーの負担が減る：１つの機能を実装するための変更を確認するだけで良くなる
- コンフリクトが減る：早くdevelopに取り込まれることで、他の人が変更を拾いやすくなり、コンフリクトが減る
▼小さな変更でも切り出してPRを出してあげることで、他の人の手元やpreview環境に早く反映させることができます
④AIコードに答えを求めるのは間違っているだろうか
📌事象
開発終盤になって全てAIが書いた動かないコードがPRとして発行された
🔍原因
- 分からないことを分からないと言えないチームの心理的安全性の低さ
- AIを使って開発したこと❌（AIを使って開発することに問題はない）
✅どうした/どうすればよかった
- チームの心理的安全性を高める
- 進捗を見える化する
心理的安全性とは
自分の意見・疑問・ミスなどをチーム内で忌憚なく発言できる環境のこと
心理的安全性が高い/低い
- 課題やアイデアを気軽に発言できる/発言しづらい
- ミスや失敗を気軽に認められる/認められない
- 進捗などを発信しやすくなる/発信しにくい
心理的安全性を高めるためには
ハッカソンという短い期間で心理的安全性を高めるために、個人的には以下のことを行なっています
- timesを生やす；気軽に発言できるようにする
- ミスを責めない：ミスを認めカバーする姿勢を示す
▼疲れなどもtimesに気軽に普段投げてます（急に連絡つかなくなるより良い）
⑤これって仕様どうなってますか？忙しいですか？教えてもらっていいですか？
📌事象
仕様などを口頭で決めており、特定のメンバーに聞かないと分からない
🔍原因
- 仕様や担当をドキュメンテーションしていなかった
- Swaggerなどを使わずmarkdownでAPI定義書を中途半端に作っていた
✅どうした/どうすればよかった
- 綺麗じゃなくていい、整ってなくていい。最低限決めたことはメモっておこう
ハッカソンでの共同開発のポイント
まとめ
- 有名なツールを使えばいい訳ではない（タスク管理）
- 壊さないように気を付ける、ではなく壊れないようにする（CI/CD）
- 開発スピードは大事！でもチームのことを考えてね（PR/Commit）
- 話すより、残す（ドキュメンテーション）
あなたのチームが、"ちゃんと前に進める"ことを願ってます 🚀
最後に
今回は
- 講師が過去に経験した失敗とその対策
- ハッカソンでの共同開発のポイント
について見ていきました。
短い開発期間をチームで乗り越え、良いプロダクトを作っていってください！！
ぜひTwitterフォローして下さい👋