こんにちは。初めて開発案件に入って、毎日ドタバタしながら学んだことをまとめました。大事なのは「エラーの向き合い方」「DBの重要性」「Gitの使い方」「早くて具体的な報告」です。
すぐ使える形で4つに絞って書きます。
エラー：再現固定→観測→粗細切り
エラーはヒントです。怖がる必要はありません。エラーが出たら大まかにバックエンド、フロントエンド、通信まわりで原因を分けます。大から小に細かく切って原因を特定していきます。
手順
- まず同じやり方で毎回エラーが出るか確認する
例：同じボタン、同じ入力、同じ環境（Stagingなど）で試す - どこまで動いているかを見る目印を置く
例：処理の入口・出口にログを仕込む、画面のコンソールを開いてエラーを見る - 大ざっぱに原因の場所を決める
例：「画面側（フロント）」「サーバ側（バックエンド）」「通信や設定」のどれっぽいかを判断 - 粗→細：ネットワーク/権限/データ整合のどれか→具体的なIFやJOINへ
UIよりDBが重要
今は考えられませんが開発初期はDBを確認しないまま開発を進めていました。DBを確認しないままAIにcodingを任せてしまうとどうなるかというと、モデルとDBの生合成が取れなくなってエラーが絶えず出るようになります。まともに開発が進められませんでした。
UIは見た目、真実はDB。これを心得て開発がスムーズに進むようになりました。
私は基本的に以下のクエリでデータを確認しますがより詳しいクエリを書く際はAIに聞いたりします。
- SELECT * FROM — WHERE—-;
- count(*)
例：DBに値はあるのに画面が空→フロントのデータ参照先とカラムが不整合
Git：小粒ブランチ/小PR/戻せる設計
はじめてgithubを使用したときはコマンドを覚えるのに必死で苦労していましたが今やAIがcommitやプッシュをしてくれます。そこで大事なのはPR分けのルール、コミットの粒度です。
直しは小さく安全に。目的ごとに分けて、小さいPRで出し、いつでも戻せる形に。
ルール
- 1目的1ブランチ(PR)
- 小PR（before/afterと戻し方を書く、 機密情報を含まないログのみ残す）
- 戻せる設計（Feature flag/環境変数、マイグレーションはDownあり）
コミュ力：速く具体に、型で報告、前倒し
技術的に学んだことが多い開発でしたが最後に大事なのはコミュ力です。伝える力と質問する力です。自分が置かれている状況を適切に把握し、事実を確認、仮説と正しい質問方法を心得ることが重要です。
「早く/具体的に/型どおり」で伝えると開発の進みが速くなります。
報告テンプレ
- 状況：今やっていること、詰まっている点
- 事実：再現手順、ログ/DB結果（画像や抜粋）
- 仮説：原因候補と検証予定
- 依頼：レビュー/権限/判断が必要なこと
- yes or noで答えられる質問
まとめ
「大→小」「再現→観測→切る」「DB優先」「小さくcommit」「早く具体に報告」。この5つを回すだけで、未経験でも安定して開発を前に進めます。完璧より、小さく試して共有です。
コメント