【DAY39】過去に初めてだったのに高度な作業を押し付けられ破綻した件
はじめに
これは、エンジニアとして駆け出しの頃、**「初めてやる作業なのに、妙に高度なことを一気に任されて破綻した」**経験の振り返りです。
自分にとっては貴重な失敗であり、今も「あのときどうすればよかったのか？」と定期的に問い直しています。
当時の状況
環境はLaravel。
やることは一見シンプルで、**「フォームの項目を1つ増やすだけ」**というタスク。
ところが実際は…
- バリデーションルールの更新
- データベースのマイグレーション変更
- Eloquentモデルの更新
- 保存処理（Controller）修正
- フロントのBladeファイル更新
- テストコードへの影響（手付かず）
と、ほぼ全方位での修正が必要だった。
それに加えて、当時の自分にはPHPとLaravelの知識がなく、マイグレーションのロールバックやルールの意図も曖昧。
結局、動いてはいるが信用できないコードをデプロイし、後で先輩に「これはだめだ」とやり直しを命じられた。
なぜ破綻したのか？
-
実装の「流れ」を分解していなかった
- 「フォームの見た目」だけを修正し、裏側の保存処理やDB設計を見落とした
-
バリデーションと保存処理の関係性を理解していなかった
-
Requestで受け取ったデータをそのままModel::create()しているだけでは動かないことがある
-
-
マイグレーションの変更 → ロールバックの手順が曖昧
-
migrate:rollbackの粒度を理解しておらず、テーブル構造が想定とズレたまま本番反映してしまった
-
学んだこと・改善点
✅ 1. 「項目追加」≠簡単、影響範囲を必ず書き出す
設計レベルでどういうファイルに波及するかを事前にリストアップ。
最低でも「モデル・バリデーション・DB・表示・保存・テスト」は必ず意識。
✅ 2. 実装前に「入力〜保存〜出力」のデータフロー図を描く
Blade → Controller → Request → Model → DB → API or View
この一連を紙に書くだけで、全体像がクリアになり、見落としが激減する。
✅ 3. 変更の粒度に対するテスト更新の重要性
特に既存のユニットテストやFeatureTestがある場合、**「項目追加で何が壊れるか」**を検証する視点が抜けていた。
今後の対策
- PR前に「変更点とその波及範囲」を簡潔にメモし、レビューしやすくする
-
RequestとModelの設計ルールを再確認し、「なぜその記述が必要か」を理解してから進める - 小さい変更でもブランチを分けて対応、デプロイ前にステージング環境で実地確認
まとめ
「フォームの項目を追加するだけ」という一見簡単なタスクでも、Laravelでは複数レイヤーにまたがる変更が必要。
知識不足のまま対応すれば、実装は破綻する。
特にMVCを正しく理解しないまま触ると、コードは動いても設計が崩壊していく。
今回の失敗から学んだことは、Laravelに限らず、全フレームワーク共通の設計リテラシーだと思っている。
Discussion