😭
プログラミング歴2ヶ月の素人2人で挑戦したStudyTrack開発 〜小規模チームで学んだ設計とコミュニケーションの大切さ〜
今回は、プログラミング歴たった2ヶ月の素人2人で勉強時間管理アプリ「StudyTrack」を開発した際の失敗と学びを赤裸々にまとめます。
「初心者だからこそハマった落とし穴」や「こうすればよかった！」という反省を、これからチーム開発に挑戦する方へ向けてシェアします
🎯開発期間、プロジェクトの背景と目的
- メンバー：プログラミング歴2ヶ月ほどの素人2人（完全未経験からのスタート）
- 目的：勉強時間の記録＆タスク管理を一緒にできるWebアプリ
- 特徴：ユーザー登録なし、ローカルストレージ運用
- 実装期間: 1週間
🏗️ 実装した機能ざっくり
- タイマー（スタート/一時停止/リセット）
- 勉強記録（タイトル必須）
- 集計（1日/週/月）
- タスク管理（優先度・種別・完了フラグ付き）
- テーブル設計もしっかり定義
📝 振り返り（失敗談＆学び）
1. API設計を最初にやらなかったことでカオスに…
やってしまったこと
API仕様を決めず、「こんな感じで大丈夫だろう」と個々に実装を進めた。
結果…
- フロントとバックエンドでデータ形式のズレが多発
- 「この項目名、何型なの？必須なの？」が混乱
- お互いの思い込みで進めてしまい、バグの山
学び
- 小規模でも最初にAPI設計＆データスキーマのすり合わせは超重要
- 特に初心者こそ「言葉だけの認識合わせ」は通じない
- ドキュメントやサンプルJSONなど「見える形」に残しておくべき
2. タスクの完了判定で設計ミス。「finish_date」だけで管理は難しい
やったこと
タスクの「終わったかどうか」をfinish_date（完了日時）が入ってるかどうかで判定しようとした。
なぜダメだった？
- 「終了日時があるかどうか」判定は一見シンプルだけど、
UI/ロジック的に**「終了状態」＝「フラグ（true/false）」で明示**した方が圧倒的に扱いやすい！ - 例えば「タスクを一時的に未完了に戻す」ケースや、「終了日時だけ消して状態をリセットする」など、
状態操作を柔軟にしたい時、フラグの方が圧倒的に管理が楽 - 「finished_dateは記録用途」「finishedは状態管理」など、
役割分担ができて、バグりにくくなる
💡 なぜfinishedフラグを別に持つべきか
- 状態（完了/未完了）は“値の有無”じゃなく“状態そのもの”で管理
- 「日付が入ってるかどうか」判定だと、NULLや誤入力、手動編集などでバグりやすい
- 明示的に「今どういう状態か」をフラグで管理する方が、UI・バックエンドどちらでも見通しが良い
🔥 設計ミスその2：finish_dateのNULL許可設定をミスった
やったこと
DBテーブルでfinish_dateをNULL許可しなかった
（でもタスク追加時点では「まだ完了していない」＝終了日時は絶対入らない）
どうなったか
- タスク作成時、終了日時を入れないとエラーに…
- 「追加時点で絶対NULLになるカラム」なのに、NULL禁止は無理があった
学び
- 業務ロジック上、“まだ存在しない値”はNULLで管理すべき
- 「タスク追加時に終わっていることは絶対ない」なら、
finish_dateはNULL許可必須 - 無理に初期値を入れるのは逆にバグのもと
3. セキュリティ対策にこだわりすぎて開発が止まった
やってしまったこと
ローカル運用・2人だけの開発なのに、「SQLインジェクション対策」やモデル設計に過剰な抽象化を実装
結果…
- コードが複雑になりすぎ、開発仲間が「何をどう触ればいいかわからない」状態に
- 好きなようにデータ操作できず、実装が進まなくなった
学び
- 規模・目的・運用体制に合わせた“適切なセキュリティ”が大事
- 小規模・ローカル運用なら、シンプル設計＆分かりやすさ優先でOK
- セキュリティと可読性・開発スピードのバランスを意識する
💡 初心者チーム開発で得た教訓まとめ
- 最初にAPI設計・スキーマ設計は必ずやるべき
- 完了状態は「フラグ」で明示、記録用メタ情報（日付等）は別で管理
- 「NULLであるべきカラム」はNULL許可必須（無理な制約は逆効果）
- 必要以上のセキュリティは開発効率を大きく下げる（TPO重視）
- 「口頭で伝わる」は危険！何でもいいからドキュメント化・サンプル化
🚀 最後に
プログラミング歴2ヶ月、完全素人2人でも「アプリは完成できる」けど、
設計・認識合わせ・ドキュメント化の大切さは身に染みました。
小規模・初心者こそ「見える化」と「シンプル設計」を徹底すると、
実装もバグ修正もぐっと楽になります。
Discussion