はじめに
通っているプログラミングスクールと外部企業の合同企画で、約2週間のハッカソンに受講生3人のチームで参加しました。
| 項目 | 内容 |
|---|---|
| 期間 | 約2週間 |
| チーム | 受講生3人（チーム開発は全員初めて） |
| 作ったもの | 上司向けの日報管理アプリ |
| 技術 | Rails 7.2 / Ruby 3.3 / PostgreSQL 16 / Docker Compose（デプロイは Render + Neon） |
| 結果 | 5チーム中2位 |
理解度も経験もバラバラな3人。順調だったとは、とても言えません。意見がぶつかった夜も、しんどい日もありました。
それでも振り返ってみて、一番効いたと思うのは 「全員が同じものを見られる状態をつくる」 ことでした。この記事では、そのために試した3つの工夫と、うまくいかなかったこと、そして講評で問われたことを、正直にまとめます。
対象読者：初めてチーム開発をする人、少人数で進め方に悩んでいる人
最初につまずいたこと
- 言葉で説明しても、画面やデータのイメージがそろわない
- 会議で論点が広がり、なかなか決まらない
- 誰が何をどこまで進めているか見えない
一生懸命話しているのに、なぜか噛み合わない。あとから気づいたのは、どれも「同じものを見ていない」ことが原因だった、ということです。
工夫① クリックできるモックで、画面のイメージをそろえる
結論：Figmaでの清書をやめて、クリックで画面遷移できるHTML/CSSのモックを作りました。
理由：静止画だと「このボタンを押したら何が出るか」のイメージが、人によってバラバラのままでした。
効果：モックを見ながら話すと「この画面にはどのデータが必要か」が全員に具体的に見え、ER図・役割分担・Issue作成まで1回の会議で進みました。言葉では何度説明しても伝わらなかったことが、クリック1つで伝わる。あの瞬間の「通じた！」という感覚は、今でも覚えています。
モックは「見た目と流れは本物、中身は仮」のもの。あとから中身（データ）だけを本物に差し替えます。
さらに、コントローラからビューに渡すインスタンス変数の名前を先に決めておくと、画面担当はバックエンドの完成を待たずに、仮の値で作り進められます。
# 例：一覧画面で使う変数
# @date … 表示している日付
# @reports … その日に提出された日報（要確認が上）
# @missing_users … まだ提出していない部下
決めた名前は、READMEに「画面ごとに使える変数」の表としてまとめました。「名前を変えるときは定例で共有してから」と書き添えておくと、担当どうしで名前がずれません。
工夫② Issue＋看板と、議題の事前投稿で、進み具合と会議をそろえる
タスクはIssue＋看板にする
結論：タスクを文書ではなくGitHubのIssueにして、Projectの看板（ボード）に並べました。
効果：「誰が・何を・どこまで」が一目で分かり、進み具合の確認に時間を使わなくなりました。
チームのルールを短く決める
実際に決めたルールです。
開発のルール（READMEに記載）
- PRは開発用ブランチ（
development）に向けて出し、直接 push しない - PRを出す前に RuboCop を通す
- 実装者以外の1人がレビューして Approve してからマージする
最初は main に直接PRを出していましたが、レビューの中で「main ではなく開発用ブランチに出そう」という話になり、途中からこのルールにしました。
コミュニケーションのルール
- 意見や質問は、相手の話が終わってから
- 会議の議題はチャットにも貼り、全員そろってから話す
- READMEに反対意見があるときは、代案も出す
- チャットの投稿は、読んだらスタンプで反応する
最後のスタンプは小さなルールですが、効果は大きかったです。投稿してもシーンとしたままのチャットは、思っている以上に心細いものです。スタンプ1つで「ちゃんと届いている」と分かるだけで、ずいぶん気持ちが楽になりました。
実はこのうち「代案も出す」と「スタンプで反応する」の2つは、最初からあったルールではありません。開発の途中、定例で意見がぶつかり、運営のエンジニアの方に間に入っていただいたあとに決めたものです。
あの日の定例は、正直つらかったです。でも、ぶつかったからこそ、「反対だけで代案がない」「読んだかどうか分からない」が摩擦のもとになっていたと、はっきり言葉にできました。
議題は会議の前に投稿する
結論：毎日の定例の前に議題をチャットに貼り、返事で決まるものは先に決めました。
効果：会議で話し合う議題が1つに減り、定例が短くなりました。会議の前に準備をすれば、会議そのものを短くできます。
工夫③ PRは手元で動かしてレビューする
結論：PRはコードを読むだけでなく、自分の環境で起動して確認しました。
効果：最初のPRを手元で起動しようとしたら、.env が無くて起動できませんでした。cp .env.example .env の手順が必要だったのに、READMEにはまだその手順が入っていなかったのです。コードを読むだけでは見つからない抜けでした。
途中からは、起動して確かめるところをClaude Codeに任せました。毎回動かすのは手間ですが、任せたことで、すべてのPRで確かめられるようになりました。
詰まったときは「自分の環境だけで起きるか、誰でも起きるか」で分けると、レビューに書くべきことが整理できます。
| 詰まったこと | 原因 | レビューに書く？ |
|---|---|---|
compose.yml が無い |
別のブランチで実行していた | 書かない |
.env が無くて起動できない |
cp .env.example .env の手順がREADMEにまだ無かった |
書く |
| 3000番ポートが使用中 | 別のコンテナが起動していた | 書かない（自分の環境） |
権限まわりは「入ってはいけないURLを直接開いてみる」のが、一番早くて確実でした。上司・部下それぞれでログインして試すと、抜けが見つかります。実際に、部下でログインして上司用のカレンダーのURLを開いたら、開けてしまう抜けが見つかりました。試した結果は、PR本文に表で残しました。
| ログインする人 | 部下の日報を開く |
|---|---|
| 同じチームの上司 | 開ける |
| 別のチームの上司 | 404 |
| 同じチームの別の部下 | 404 |
また、コードの書き方のルールや基本的なセキュリティのチェック（RuboCop・Brakeman）はCIに任せました。PR本文に Closes #Issue番号 と書いておけば、マージと同時にIssueも閉じます。機械に任せられることを任せた分、人のレビューは「画面で動くか」「権限を越えていないか」に集中できました。
番外編：評価の基準は、思い込まずに主催者に聞く
発表の準備中、チーム全員が「リポジトリを見たうえで技術的な質問をされる」と思い込み、コードを深掘りしていました。ところが主催者に確認すると、審査で見るのはスライドと本番のURLだけ。「アピールしたい技術があれば、スライドに書いてほしい」とのことでした。
すぐにチームに共有し、質疑応答の準備を「スライドと画面で見せたものから聞かれそうなこと」に切り替えました。何で評価されるか分からないときは、推測で準備するより、一言聞いたほうが早いです。
うまくいかなかったこと
目指すゴールをそろえていなかった
話し合ってみると、このハッカソンで目指すところが「アプリを作りきる」「チーム開発から学ぶ」「ピッチを成功させる」と、人によって違っていました。ゴールが違えば、どこに時間をかけるかの判断も変わります。このあとに書くずれも、根っこはここにあったと思います。
「何を相談して決めるか」を決めていなかった
役割は決めましたが、「相談してから決めること」と「担当者に任せてよいこと」の線引きをしていませんでした。
たとえば、ある資料の作り直しが定例の場で決まったとき、受け取り方が分かれました。
- 「全員がいる会議で決めたのだから、改めて確認しなくてよい」
- 「その場にいても、決まりかけている流れに『待って』とは言いにくい。始める前に一言ほしい」
どちらも筋は通っていて、誰かが悪かったわけではありません。 前提がそろっていなかっただけです。毎日定例があっても、決め方が決まっていなければ、ずれは起きます。
自分の基準を、黙って相手に期待していた
進行役を引き受けていた私は、自分が頑張っている分、同じ熱量を相手にも期待していました。でも、その期待を口にしないまま、心の中に溜め込んでいました。溜まったものは、話し合いの場で一気にあふれてしまいました。
そのとき、間に入ってくださったエンジニアの方に言われたのが、この言葉です。
自分が頑張った分と同じものを、人に勝手に求めない
図星でした。頑張っていたこと自体は、間違いではなかったと思います。ただ、その頑張りを「相手も同じようにやって当然」の物差しにしてしまっていました。
それからは、気になったことは溜まる前に小さく出すこと、相手の事情を決めつけず「事実＋質問」の形で声をかけることを意識しました。期待は、持たないようにするものではなく、言葉にしてそろえるものなのだと思います。
決めたことを残す文章が長かった
決まったことを文章で残す習慣自体は良かったものの、一つひとつが長く、読む負担になっていました。
講評で問われたこと
発表後の講評で、主催企業の方から「社内には似た仕組みがすでにある。それでも、このツールを作る価値はあるか」という問いをいただきました。
正直、ぐさっときました。2位という結果に「報われた」と思った、そのすぐあとだったからです。
でも同時に、ありがたい問いだとも感じました。褒めて終わりにせず、本気で返してくださったからです。1位のチームの強みは、実体験に基づいた「課題の定義」でした。私たちが問われたのも、同じ「課題の定義」です。進め方をどれだけ工夫しても、「何を、なぜ作るか」が弱ければ届かない。それを、最後の最後に教えてもらいました。
次にやるなら
- キックオフで「何を目指すか」と「相談して決めること／任せてよいこと」を全員で言葉にする
- 迷ったときに誰が決めるか（決定役）を決める
- 作り始める前に「誰の、どんな課題を解くのか」を詰める時間をとる
- 気になったことは、溜まる前に「事実＋質問」で小さく出す
- 共有する文章は「1行目に結論、理由は1行、箇条書き3つまで」
おわりに
初めてのチーム開発は、思っていた以上に難しかったです。技術の難しさより、人と一緒に進める難しさのほうが、ずっと大きかった気がします。
それでも、少人数・初心者のチームほど、「話し合う量」より 「同じものを見られる状態」と「何をどこで決めるか」 が効く。ぶつかったことも含めて、この2週間がそれを教えてくれました。
うまくいったことも、いかなかったことも、まるごと次のチーム開発に持っていきます。
同じようにチーム開発に悩んでいる方の、小さなヒントになればうれしいです！
ここまで読んでくださってありがとうございました！